diff --git a/pages/docs/appendix/library-structure.md b/pages/docs/appendix/library-structure.md index ca62574..b8a1f0b 100644 --- a/pages/docs/appendix/library-structure.md +++ b/pages/docs/appendix/library-structure.md @@ -14,7 +14,7 @@ The **Core** library is built on top of Foundation. This library contains engine The **TestFramework** library implements code to manage our unit-tests. You can ignore this entirely. -**GameEngine** builds on top of all the other libraries, including the rendering code. It contains the most high-level code for a game engine, such as AI and Animation, [ezGameApplication (TODO)](../runtime/application/application.md) and [ezGameState](../runtime/application/game-state.md), which are the basis for any game application built with EZ, the prefab system, the visual scripting and much more. +**GameEngine** builds on top of all the other libraries, including the rendering code. It contains the most high-level code for a game engine, such as AI and Animation, [ezGameApplication](../runtime/application/application.md) and [ezGameState](../runtime/application/game-state.md), which are the basis for any game application built with EZ, the prefab system, the visual scripting and much more. In general the most interesting libraries to look at are **Foundation**, **Core** and **GameEngine**. @@ -82,7 +82,7 @@ In **GameEngine** you will find all the high-level code needed in a game engine. **GameEngine\\Console** contains code for a Quake-like in-game console that can be used for changing the game configuration (through `ezCVar` or custom functions) and to see the `ezLog` output. -**GameEngine\\GameApplication** contains [ezGameApplication (TODO)](../runtime/application/application.md), which extends `ezApplication` with higher-level, more game specific functionality. This is one of the most important high-level classes to look at and extend when writing your own, stand-alone game application (assuming you can't do so with `ezGameState` alone). +**GameEngine\\GameApplication** contains [ezGameApplication](../runtime/application/application.md), which extends `ezApplication` with higher-level, more game specific functionality. This is one of the most important high-level classes to look at and extend when writing your own, stand-alone game application (assuming you can't do so with `ezGameState` alone). In **GameEngine\\GameState** you find [ezGameState](../runtime/application/game-state.md), which is the most important class to extend when writing your own game code, especially if you want to be able to run your code within the editor. diff --git a/pages/docs/build/sdk-root.md b/pages/docs/build/sdk-root.md index 57fca57..1e8123c 100644 --- a/pages/docs/build/sdk-root.md +++ b/pages/docs/build/sdk-root.md @@ -37,7 +37,7 @@ Using a redirection file is the least invasive method and it works for all EZ ap ## Custom SDK Root -You can fully control where the SDK root should be and how it is found, if you write your own [application (TODO)](../runtime/application/application.md). During early startup you can simply set the path of the SDK root folder with `ezFileSystem::SetSdkRootDirectory()`. +You can fully control where the SDK root should be and how it is found, if you write your own [application](../runtime/application/application.md). During early startup you can simply set the path of the SDK root folder with `ezFileSystem::SetSdkRootDirectory()`. This can be preferable when you use a very different structure. diff --git a/pages/docs/custom-code/cpp/cpp-overview.md b/pages/docs/custom-code/cpp/cpp-overview.md index a138add..99f7250 100644 --- a/pages/docs/custom-code/cpp/cpp-overview.md +++ b/pages/docs/custom-code/cpp/cpp-overview.md @@ -36,7 +36,7 @@ Finally, have a look at [profiling](../../performance/profiling.md), to know whe ## Standalone App -If you want to write your own stand-alone application, have a look at the [application (TODO)](../../runtime/application/application.md) chapter. However, we encourage you to have your entire game code in a plugin, otherwise you can't use any of it in the editor. You would mostly need your own application for the finishing touches of how you present the main menu, etc, and a good starting point is to just copy the [ezPlayer](../../tools/player.md) and make adjustments. +If you want to write your own stand-alone application, have a look at the [application](../../runtime/application/application.md) chapter. However, we encourage you to have your entire game code in a plugin, otherwise you can't use any of it in the editor. You would mostly need your own application for the finishing touches of how you present the main menu, etc, and a good starting point is to just copy the [ezPlayer](../../tools/player.md) and make adjustments. ## See Also diff --git a/pages/docs/custom-code/cpp/engine-plugins.md b/pages/docs/custom-code/cpp/engine-plugins.md index c0c1d29..0ca784f 100644 --- a/pages/docs/custom-code/cpp/engine-plugins.md +++ b/pages/docs/custom-code/cpp/engine-plugins.md @@ -2,7 +2,7 @@ Engine plugins are the best way to get your custom code into the engine, such that it is accessible by the editor and also [ezPlayer](../../tools/player.md). -Contrary to using a plugin, you could also build your own [application (TODO)](../../runtime/application/application.md), which may link to static libraries that contain your code. However, that approach means that your code cannot be loaded into the editor process and therefore you won't be able to leverage those tools to their full extent. We strongly advise against that. +Contrary to using a plugin, you could also build your own [application](../../runtime/application/application.md), which may link to static libraries that contain your code. However, that approach means that your code cannot be loaded into the editor process and therefore you won't be able to leverage those tools to their full extent. We strongly advise against that. ## Creating a Plugin @@ -67,7 +67,7 @@ These callbacks are optional, though in some cases you may want to register and If you want to load a plugin from code, you would use `ezPlugin::LoadPlugin()` and provide only the name (no path) of your plugin. Make sure that the DLL is stored in the same directory as all other DLLs and EXEs. -The more convenient way to load your game plugin, though, is to enable it in the [project settings](../../projects/plugin-selection.md). Then it will be automatically loaded by every [application (TODO)](../../runtime/application/application.md). +The more convenient way to load your game plugin, though, is to enable it in the [project settings](../../projects/plugin-selection.md). Then it will be automatically loaded by every [application](../../runtime/application/application.md). ## Add Custom Code diff --git a/pages/docs/debugging/logging.md b/pages/docs/debugging/logging.md index 8ced8d9..74bf39c 100644 --- a/pages/docs/debugging/logging.md +++ b/pages/docs/debugging/logging.md @@ -26,7 +26,7 @@ There are multiple ways to see the content of the log: * In the [ezEditor](../../getting-started/editor-overview.md) you can open *Panels > Log* to see two logs, the one for the editor and the one from the engine process. * [ezInspector](../tools/inspector.md) shows the log of the connected process. * The in-game [console](console.md) outputs the log messages. -* By default all EZ [applications (TODO)](../runtime/application/application.md) also write the log output to a `Log.htm` file in the application's *appdata* folder. +* By default all EZ [applications](../runtime/application/application.md) also write the log output to a `Log.htm` file in the application's *appdata* folder. ## Thread-local logging diff --git a/pages/docs/debugging/renderdoc.md b/pages/docs/debugging/renderdoc.md index 976e8b3..25a26c8 100644 --- a/pages/docs/debugging/renderdoc.md +++ b/pages/docs/debugging/renderdoc.md @@ -6,7 +6,7 @@ ezEngine has a dedicated *RenderDocPlugin*, to integrate RenderDoc support even ## Taking Captures -If you write your own [application (TODO)](../runtime/application/application.md) you can hook up RenderDoc in different ways, however, by default these methods are available: +If you write your own [application](../runtime/application/application.md) you can hook up RenderDoc in different ways, however, by default these methods are available: * **Press F11:** The `F11` key will take a capture of the current frame. * Type `CaptureFrame()` into the game [console](console.md). diff --git a/pages/docs/performance/profiling.md b/pages/docs/performance/profiling.md index 7e25617..383715a 100644 --- a/pages/docs/performance/profiling.md +++ b/pages/docs/performance/profiling.md @@ -4,7 +4,7 @@ Profiling an application means to record information about its performance to an ## Capturing Profiling Data -ezEngine has a built in profiling system with which you can record the function call graph, across all active threads, with precise timing information. The profiling system is very efficient, which is why in development builds it is constantly recording data to a ring buffer, which allows you to write recent profiling data to disk at any time. That means whenever you encounter a situation with bad performance, you can just press a button (in stock [applications (TODO)](../runtime/application/application.md) such as [ezPlayer](../tools/player.md) it's the `F8` key) to save a snapshot. +ezEngine has a built in profiling system with which you can record the function call graph, across all active threads, with precise timing information. The profiling system is very efficient, which is why in development builds it is constantly recording data to a ring buffer, which allows you to write recent profiling data to disk at any time. That means whenever you encounter a situation with bad performance, you can just press a button (in stock [applications](../runtime/application/application.md) such as [ezPlayer](../tools/player.md) it's the `F8` key) to save a snapshot. The application will write to the [log](../debugging/logging.md) where it stored the profiling snapshot. You can see this in the [console](../debugging/console.md): diff --git a/pages/docs/projects/data-directories.md b/pages/docs/projects/data-directories.md index 30b946d..041290c 100644 --- a/pages/docs/projects/data-directories.md +++ b/pages/docs/projects/data-directories.md @@ -20,7 +20,7 @@ You may notice the `>sdk` and `>project` prefixes. These are *special directory* ### From Custom Code -You can also mount data directories from code. Usually you would do this either in a custom [application (TODO)](../runtime/application/application.md) class or in a [game state](../runtime/application/game-state.md). Either way, you should do this early at game startup. For more more information, see the [filesystem documentation](../runtime/filesystem.md#data-directories). +You can also mount data directories from code. Usually you would do this either in a custom [application](../runtime/application/application.md) class or in a [game state](../runtime/application/game-state.md). Either way, you should do this early at game startup. For more more information, see the [filesystem documentation](../runtime/filesystem.md#data-directories). ## See Also @@ -28,5 +28,5 @@ You can also mount data directories from code. Usually you would do this either * [FileSystem](../runtime/filesystem.md) * [FileServe](../tools/fileserve.md) * [Projects](projects-overview.md) -* [Application (TODO)](../runtime/application/application.md) +* [Application](../runtime/application/application.md) * [Game States](../runtime/application/game-state.md) diff --git a/pages/docs/projects/project-settings.md b/pages/docs/projects/project-settings.md index dbc34ed..b649d01 100644 --- a/pages/docs/projects/project-settings.md +++ b/pages/docs/projects/project-settings.md @@ -22,7 +22,7 @@ In the editor you will find the project settings under *Project > Project Settin ![Window Configuration](media/editor-window-config.png) -These settings allow you to configure basic window settings for Play-the-Game mode and when running an exported scene in [ezPlayer](../tools/player.md). A proper game would typically implement this logic in a custom [application (TODO)](../runtime/application/application.md) and should allow the user to choose settings such as the resolution. The window configuration dialog is mainly for use during development. +These settings allow you to configure basic window settings for Play-the-Game mode and when running an exported scene in [ezPlayer](../tools/player.md). A proper game would typically implement this logic in a custom [application](../runtime/application/application.md) and should allow the user to choose settings such as the resolution. The window configuration dialog is mainly for use during development. There are two separately stored configurations: @@ -44,7 +44,7 @@ If plugins provide additional editor options, they are typically found under *Pr ### Loading Plugins from Code -A custom [application (TODO)](../runtime/application/application.md) or [game state](../runtime/application/game-state.md) can load plugins directly from code if necessary. For example the `ezInspectorPlugin` is automatically loaded for you by stock EZ applications, when building the code for development. +A custom [application](../runtime/application/application.md) or [game state](../runtime/application/game-state.md) can load plugins directly from code if necessary. For example the `ezInspectorPlugin` is automatically loaded for you by stock EZ applications, when building the code for development. ## FMOD diff --git a/pages/docs/projects/projects-overview.md b/pages/docs/projects/projects-overview.md index a1af12d..d444d8c 100644 --- a/pages/docs/projects/projects-overview.md +++ b/pages/docs/projects/projects-overview.md @@ -8,7 +8,7 @@ The term *project* refers to one game or application, its global settings, and a ## Creating a Project -You can use ezEngine entirely without the editor. In that case, you do not need to create a project, at all. Your [application (TODO)](../runtime/application/application.md) is your project and you set up things like the [fileSystem](../runtime/filesystem.md), the [plugins](../custom-code/cpp/engine-plugins.md) and so on, entirely from code. +You can use ezEngine entirely without the editor. In that case, you do not need to create a project, at all. Your [application](../runtime/application/application.md) is your project and you set up things like the [fileSystem](../runtime/filesystem.md), the [plugins](../custom-code/cpp/engine-plugins.md) and so on, entirely from code. It is more convenient, though, to maintain your project through the editor. To create a new project, open the editor's [dashboard](../editor/dashboard.md) (*Project > Show Dashboard*) and select **New** from the top-right corner: diff --git a/pages/docs/runtime/application/application.md b/pages/docs/runtime/application/application.md index fd3c22d..de123e3 100644 --- a/pages/docs/runtime/application/application.md +++ b/pages/docs/runtime/application/application.md @@ -1,10 +1,107 @@ # Application -See [Game States](game-state.md) +Every C++ application has one function that is the entry point for running the application. The name, signature and behavior of this function can differ across platforms. As a game developer you rarely care about interacting with the system on the lowest level. However, depending on what kind of application you write (for example a tool, rather than a game), you may either want to get a fully setup engine where all you add is your custom game code, or you may prefer to have a rather bare bones application, where you have full control. - +Therefore EZ uses a number of abstraction layers, where each layer adds some functionality, and thus convenience for making a game. You build your application by overriding the layer that makes most sense for the intended use case. -The classes `ezApplication`, `ezGameApplicationBase` and `ezGameApplication` are fully functional, but currently undocumented. +> **NOTE** +> +> This is an *advanced* topic for people who are either building custom tools, using a completely custom renderer or are close to shipping and want a custom binary (rather than using [ezPlayer](../../tools/player.md)). As long as you only want to write game code, add a [custom game state](game-state.md) inside an [engine plugin](../../custom-code/cpp/engine-plugins.md). See [C++ Project Generation](../../custom-code/cpp/cpp-project-generation.md) for the most convenient way to get started with this. + +## Custom Application Use Cases + +> **ATTENTION** +> +> Don't put game functionality into a custom application. If you do so, you'll lose the ability to test your game logic inside the editor. Only use a custom application to polish the overall game presentation. + +There are two main situations in which you'll need to write your own application: + +1. You want to write a custom tool. Usually a command line application to process some data. +1. You are preparing you game for shipping and don't want to run it through [ezPlayer](../../tools/player.md) anymore. + +In the first case, you'll typically build your application on top of `ezApplication` which gives you a streamlined entry point similar to to a regular C++ `main` function. + +In the second case you usually build your application on top of `ezGameApplication`. It is assumed that you already have a custom [Game State](game-state.md) anyway. The easiest way to get started, is simply to copy the [ezPlayer](../../tools/player.md) application and modify it to suit your needs, such as: + +* Custom binary name +* Custom icon +* Startup videos +* Way to select graphics and other options +* Pause / mute game when it doesn't have focus + +## Application Structure Diagram + +The diagram below shows the structure that ezEngine uses. The chapters below describe each aspect in detail. + +![Application Structure Diagram](media/application.png) + +## Application Entry Point Macro + +On the lowest C++ level platforms differ significantly how they execute an application. Therefore EZ uses the macro `EZ_APPLICATION_ENTRY_POINT` to generate the necessary, platform-specific code. This needs to be put into some cpp file of your application and you have to pass in the class name of your custom application. This class must be derived from `ezApplication` or `ezGameApplication`. + +**Example:** + +```cpp +class ezPlayerApplication : public ezGameApplication +{ + // ... +}; + +EZ_APPLICATION_ENTRY_POINT(ezPlayerApplication); +``` + +Some platforms (mainly Windows) differentiate between *console apps* and *window apps*. Console apps are executed inside a command prompt and typically do not have graphical output, whereas *window apps* create their own window to display output and interact with. + +By default, applications are treated as *console apps* and thus show a command prompt on these platforms. This can be convenient for debugging, as you see the [log output](../../debugging/logging.md) there. To remove the command prompt, you need to configure you application as a *window app*. To do so, the *CMakeLists.txt* file for your application has to call `ez_make_windowapp`: + +```cmake +ez_create_target(APPLICATION ${PROJECT_NAME}) +ez_make_windowapp(${PROJECT_NAME}) +``` + +## ezApplication Based Apps + +If you are building an application that doesn't need the full engine, derive you application class directly from `ezApplication`. + +The most important functions to override are the following: + +* `ezApplication::AfterCoreSystemsStartup()` - to set configure systems. +* `ezApplication::Run()` - the main loop + +Note that `Run` will be called repeatedly until you call `RequestApplicationQuit()`. + +For applications that process data and may be integrated into automatic build chains, it is also useful to use: + +* `ezApplication::SetReturnCode()` - to set the return code passed to the operating system +* `ezApplication::TranslateReturnCode()` - to provide a human readable string for each return code + +## ezGameApplication Based Apps + +`ezGameApplicationBase` is built on top of `ezApplication` and implements the actual setup of the engine. It also adds the [Game State](game-state.md) functionality and other [common application features](common-application-features.md). `ezGameApplication` further adds functionality to setup the EZ renderer. In theory you can build a game that doesn't use the EZ renderer, by deriving from `ezGameApplicationBase`, but this is a very advanced topic and only makes sense in very specific circumstances. + +In practice you should derive your game class from `ezGameApplication`, but be aware that there are additional virtual functions in `ezGameApplicationBase` that you can (and may need to) override. + +These functions are of particular interest: + +* `ezGameApplicationBase::CreateGameState()` - to hardcode which game state to use for your game +* `ezGameApplicationBase::FindProjectDirectory()` - to adjust where your project data is located +* `ezGameApplicationBase::Init_...()` - these init functions configure all sorts of aspects of the engine +* `ezGameApplicationBase::Init_ConfigureInput()` - you may need to set up input mappings for the main menu and closing the app +* `ezGameApplicationBase::Run_ProcessApplicationInput()` - handle input for the application + +The best way to go about writing your own game application, is to copy the [ezPlayer](../../tools/player.md) code and adjust it to fit your needs. + +If all you have is a game state, but you want to build a dedicated binary for your game, you can also do it like the [Asteroids sample](../../../samples/asteroids.md) which simply uses `ezGameApplication` directly to create an application instance with a single line of code: + +```cpp +EZ_APPLICATION_ENTRY_POINT(ezGameApplication, "Asteroids", "Data/Samples/Asteroids"); +``` + +## Game State vs. Application + +[Game States](game-state.md) play the role of encapsulating all of your game logic. Application classes are used to define how your app behaves within the operating system environment. The two are very clearly separated in what they are meant to do, thus there should never be the question whether you use a custom game state or a custom application. Everything that relates to the game logic should go into the game state. Only the few things that cannot be done there, should go into the application class. + +The intended effect is, that you can [run your game](../../editor/run-scene.md) in the editor or through [ezPlayer](../../tools/player.md) and thus have multiple convenient ways to test it. ## See Also diff --git a/pages/docs/runtime/application/common-application-features.md b/pages/docs/runtime/application/common-application-features.md index 15a4ccc..9a26c02 100644 --- a/pages/docs/runtime/application/common-application-features.md +++ b/pages/docs/runtime/application/common-application-features.md @@ -31,7 +31,7 @@ Reloading resources works for all assets that are used directly by the engine (e ## See Also -* [Application (TODO)](application.md) +* [Application](application.md) * [ezPlayer](../../tools/player.md) * [Profiling](../../performance/profiling.md) * [RenderDoc Integration](../../debugging/renderdoc.md) diff --git a/pages/docs/runtime/application/game-state.md b/pages/docs/runtime/application/game-state.md index 9742bb5..1270047 100644 --- a/pages/docs/runtime/application/game-state.md +++ b/pages/docs/runtime/application/game-state.md @@ -4,7 +4,7 @@ Most game code is implemented by writing custom [components](../world/components However, for a full game you need a layer of control that is outside the world, where you can do logic like what level to load, what to do when the player dies or reaches their goal, how to display a main menu for the game settings and level selection, and so on. Most of these things would be possible with world components alone, but it would be cumbersome. Especially switching from one level to another is difficult, if some of your overall game logic has to be transitioned as well. -*Game States* are this extra layer. A game state sits between the [application (TODO)](application.md) layer and the [world](../world/worlds.md). +*Game States* are this extra layer. A game state sits between the [application](application.md) layer and the [world](../world/worlds.md). ![Code Hierarchy](media/code-hierarchy.png) @@ -35,7 +35,7 @@ As you can see, by implementing a custom game state, you can gain control over m ## Game State Instantiation -It is the responsibility of the `ezGameApplication` to instantiate a game state. By default this is done right at application startup, but if you write your own [application (TODO)](application.md) you could handle this differently. For example the editor only instantiates the game state for play-the-game mode. +It is the responsibility of the `ezGameApplication` to instantiate a game state. By default this is done right at application startup, but if you write your own [application](application.md) you could handle this differently. For example the editor only instantiates the game state for play-the-game mode. The application knows what game states are available through the [reflection information](../reflection-system.md). When a game state is needed, it instantiates either your custom game state, or a fallback one. So your game plugin should only contain a single custom game state. @@ -48,4 +48,4 @@ For all the details, read the [API Docs](../../api-docs.md) for `ezGameState`. ## See Also * [Custom Code](../../custom-code/custom-code-overview.md) -* [Application (TODO)](application.md) +* [Application](application.md) diff --git a/pages/docs/runtime/application/media/application.png b/pages/docs/runtime/application/media/application.png new file mode 100644 index 0000000..ba8ec65 Binary files /dev/null and b/pages/docs/runtime/application/media/application.png differ diff --git a/pages/docs/runtime/application/media/application.pptx b/pages/docs/runtime/application/media/application.pptx new file mode 100644 index 0000000..946d1b8 Binary files /dev/null and b/pages/docs/runtime/application/media/application.pptx differ diff --git a/pages/docs/toc.md b/pages/docs/toc.md index d1aa3c8..1497068 100644 --- a/pages/docs/toc.md +++ b/pages/docs/toc.md @@ -297,7 +297,7 @@ ### [Trigger Delay Modifier Component](custom-code/game-logic/trigger-delay-modifier-component.md) # Runtime ## Application -### [Application (TODO)](runtime/application/application.md) +### [Application](runtime/application/application.md) ### [Common Application Features](runtime/application/common-application-features.md) ### [Game States](runtime/application/game-state.md) ## Configuration diff --git a/pages/docs/tools/fileserve.md b/pages/docs/tools/fileserve.md index 9f00d7e..7dfd7e0 100644 --- a/pages/docs/tools/fileserve.md +++ b/pages/docs/tools/fileserve.md @@ -22,7 +22,7 @@ Note that there is also [ezInspector](inspector.md), that you can also connect t Generally the fileserve functionality is added to the engine through the `ezFileservePlugin`. Enabling it is thus just a matter of loading that plugin during engine initialization. If your game is built on top of `ezGameApplication` (such as [ezPlayer](player.md)), it is automatically enabled in development builds for platforms that have file access restrictions (see `ezGameApplication::Init_LoadRequiredPlugins()` for details). This is also true for [ezInspector](inspector.md) support. -If your game is [using a custom application class (TODO)](../runtime/application/application.md), make sure this is set up in your code. The [Shader Explorer Sample](../../samples/shader-explorer.md) is such an application and should be used as reference. +If your game is [using a custom application class](../runtime/application/application.md), make sure this is set up in your code. The [Shader Explorer Sample](../../samples/shader-explorer.md) is such an application and should be used as reference. If you want more control over the fileserve connection in your application, have a look at `ezFileserveClient`. diff --git a/pages/docs/tools/player.md b/pages/docs/tools/player.md index db0afc1..3c0974d 100644 --- a/pages/docs/tools/player.md +++ b/pages/docs/tools/player.md @@ -27,7 +27,7 @@ Pressing **Escape** will close the Player application (unless overridden by a cu ## Common Application Features -Since ezPlayer is built on the [application (TODO)](../runtime/application/application.md) framework, it provides a set of useful features common to all EZ applications. +Since ezPlayer is built on the [application](../runtime/application/application.md) framework, it provides a set of useful features common to all EZ applications. See [this page](../runtime/application/common-application-features.md) for details. diff --git a/pages/samples/asteroids.md b/pages/samples/asteroids.md index a0c1f06..f9c5e27 100644 --- a/pages/samples/asteroids.md +++ b/pages/samples/asteroids.md @@ -9,7 +9,7 @@ The **Asteroids Sample** is a small game that shows how to use various component **Note:** The project is only available when the solution is built with **EZ_BUILD_SAMPLES** activated. -The game itself is a stand-alone [application (TODO)](../docs/runtime/application/application.md), but the assets that it uses need to be transformed by [ezEditor](../getting-started/editor-overview.md). Open the editor project in *Data/Samples/Asteroids* with ezEditor, then open the [asset browser](../docs/assets/asset-browser.md) and click the *Transform All* button (white box with red arrow). Afterwards you can run the Asteroids application. +The game itself is a stand-alone [application](../docs/runtime/application/application.md), but the assets that it uses need to be transformed by [ezEditor](../getting-started/editor-overview.md). Open the editor project in *Data/Samples/Asteroids* with ezEditor, then open the [asset browser](../docs/assets/asset-browser.md) and click the *Transform All* button (white box with red arrow). Afterwards you can run the Asteroids application. ## Code