It allows to expose variables and functions to be used in the editor. That is, the game creation tool will use a form of reflection (or similar) on the code provided by the developers, which then allows it to expose parts of it in editors for designers.

For example, let us say a developer has created a class of objects (created as source code) to be placed in game by the level designers. However, there are some properties the developer wants to allow the designer to tweak. To do this, the tool will have to expose these properties to the level designer in the editor.

Similarly, functions/methods could be exposed. Which may allow to use them in scripting (including visual scripting, for example “blueprints”) or even allow to call them from an in-game debug console.

Since the editor cannot know the type information before hand (the editor was created before the game). Instead the editor will need a manifest with this information. To get this manifest, the editor (uses a tool that) generates it, either directly from the source (this could be part of the built process) or from a binary. The developer might have to mark what to expose.

This is similar to how Visual Studio form designer shows you a property panel where you can edit the properties of the controls you place... and that the controls had been built beforehand.

See also Unreal Property System (Reflection).

We might also find reflection and emission to generate bindings for different languages. That is, the engine has main supported language, yet we want to provide the ability to write code for the engine in other languages... then we need an SDK for those languages. Well, we can generate code for those languages by doing reflection on the API and emitting the SDK code. Add this to continuous integration, and this ensures that the SDK code is always up to date.

Yet another place where we might find reflection is when loading plugins or mods.

It allows to expose variables and functions to be used in the editor. That is, the game creation tool will use a form of reflection (or similar) on the code provided by the developers, which then allows it to expose parts of it in editors for designers.

For example, let us say a developer has created a class of objects (created as source code) to be placed in game by the level designers. However, there are some properties the developer wants to allow the designer to tweak. To do this, the tool will have to expose these properties to the level designer in the editor.

Similarly, functions/methods could be exposed. Which may allow to use them in scripting (including visual scripting, for example “blueprints”) or even allow to call them from an in-game debug console.

Since the editor cannot know the type information before hand (the editor was created before the game). Instead the editor will need a manifest with this information. To get this manifest, the editor (uses a tool that) generates it, either directly from the source (this could be part of the built process) or from a binary. The developer might have to mark what to expose.

This is similar to how Visual Studio form designer shows you a property panel where you can edit the properties of the controls you place... and that the controls had been built beforehand.

See also Unreal Property System (Reflection).

We might also find reflection and emission to generate bindings for different languages. That is, the engine has main supported language, yet the developers of the engine want to provide the ability to write code for the engine in other languages... if they are not integrating a compiler for those languages, then they need an SDK for those languages. Well, they can generate code for those languages by doing reflection on their API and emitting the SDK interop code. Add this to continuous integration, and this ensures that the SDK code is always up to date.

Yet another place where we might find reflection is when loading plugins or mods.

It allows to expose variables and functions to be used in the editor. That is, the game creation tool will use a form of reflection (or similar) on the code provided by the developers, which then allows it to expose parts of it in editors for designers.

For example, let us say a developer has created a class of objects (created as source code) to be placed in game by the level designers. However, there are some properties the developer wants to allow the designer to tweak. To do this, the tool will have to expose these properties to the level designer in the editor.

Similarly, functions/methods could be exposed. Which may allow to use them in scripting (including visual scripting, for example “blueprints”) or even allow to call them from an in-game debug console.

Since the editor cannot know the type information before hand (the editor was created before the game). Instead the editor will need a manifest with this information. To get this manifest, the editor (uses a tool that) generates it, either directly from the source (this could be part of the built process) or from a binary. The developer might have to mark what to expose.

It allows to expose variables and functions to be used in the editor. That is, the game creation tool will use a form of reflection (or similar) on the code provided by the developers, which then allows it to expose parts of it in editors for designers.

For example, let us say a developer has created a class of objects (created as source code) to be placed in game by the level designers. However, there are some properties the developer wants to allow the designer to tweak. To do this, the tool will have to expose these properties to the level designer in the editor.

Similarly, functions/methods could be exposed. Which may allow to use them in scripting (including visual scripting, for example “blueprints”) or even allow to call them from an in-game debug console.

Since the editor cannot know the type information before hand (the editor was created before the game). Instead the editor will need a manifest with this information. To get this manifest, the editor (uses a tool that) generates it, either directly from the source (this could be part of the built process) or from a binary. The developer might have to mark what to expose.

This is similar to how Visual Studio form designer shows you a property panel where you can edit the properties of the controls you place... and that the controls had been built beforehand.

See also Unreal Property System (Reflection).

We might also find reflection and emission to generate bindings for different languages. That is, the engine has main supported language, yet we want to provide the ability to write code for the engine in other languages... then we need an SDK for those languages. Well, we can generate code for those languages by doing reflection on the API and emitting the SDK code. Add this to continuous integration, and this ensures that the SDK code is always up to date.

Yet another place where we might find reflection is when loading plugins or mods.