Start Page » Game Development with the Drag[en]gine » Drag[en]gine Integrated Game Development Environment » Project Editor/Runner
The project editor allows to set up Profiles, Test-Running the game and building Distribution Files for delivery to testers or customers.
The editor window composes of different views selected by the tab switcher on the top left corner of the window.
In this view the Profiles are edited and distribution files can be build.
Each game project has basic parameters which are the same for example the game definition file to use. All other parameters can be adjusted by using profiles. Different profiles can be used for various purposes:
The parameters of the selected profile are shown in the content area of the window.
The Name parameter is the unique profile name.
The Description parameter contains the description of the profile.
The Script Directory parameters defines the Virtual File System path under which the Game Scripts can be found. The Scripting Module of your choice defines how the scripts have to be organized to be runnable. This directory is located under the Game Data Directory.
The Game Object parameter defines the game object to run. The Scripting Module of your choice defines what a Game Object is and how this parameter has to be specified. In general this is a Class Name or a Function Name. Using a different game object for Debug and Release builds is a typical way to activate debug code.
The Config Path parameter defines the Virtual File System path where your game scripts is storing Configuration and Save States. By default the content of the Virtual File System is read-only. Launchers will mount a writeable disc directory from the user home directory in this location. Everything written to this path will be persisted across different game runs.
The Project Editor does not use a directory from the user home directory for this path for test-running. Instead the directory is located in cache/testrun/config inside the project directory.
Launchers will store this data in a location of the home directory which is typically persisted. For windows for example this means the data is located in the Remote App Data section of the user directory and thus will be stored on server login profiles. You should not store large data in this location or it can slow down start/shutdown times for users.
The Capture Path parameter defines the Virtual File System path where the game scripts is storing Screenshots, Videos and other kinds of captured content to. Launchers will mount a writeable disc directory from the user cache directory in this location. Everything written to this path will be persisted across different game runs but can be deleted any time by the user or platform discretion.
The Project Editor does not use a directory from the user home directory for this path for test-running. Instead the directory is located in cache/testrun/captuire inside the project directory.
Launchers will store this data in a location of the home directory which is typically transient and is allowed to be deleted without warning. For windows for example this means the data is located in the Local App Data section of the user directory. This directory is never stored on server login profiles and can be volatile. You should store large data in this location to not slow down start/shutdown times for users.
The Identifier parameter defines the Unique Identifier of the game. Launchers use this identifier to uniquely identify Games and Patches. The value has to be a Random UUID.
It is highly recommended to not change this value or game configuration and save states will not work anymore because they are linked to game identifiers. Different profiles should also use the same identifier unless they are different in a way that makes their configuration and save states incompatible. Keep in mind that *.delga files are platform independent. Players can use configuration and save states from one platform on any other platform as long as the game has the same identifier.
Hence again, if you think you need to change the identifier think hard again if you really need to change it.
The Alias Identifier parameter defines an alias identifier the user can use to identify the installed game on his computer. This value should be short composing of lowercase letters, numbers and '-'/'_' only but any character is allowed. Using this format makes it easier for the user to use on command lines and shortcuts. Alias identifiers are not guaranteed to be unique. Launchers can handle the situation of two or more games using the same alias identifier as long as their unique identifier is different.
The Title parameter is the the Display Name of the game. It will be shown by Launchers in game listings or might be used for game shortcuts.
The Description parameter is the Display Description of the game. It will be shown by Launchers on game detail pages or can be used on large icon view modes. A couple of lines of text are usually enough. If you need lengthy descriptions better place them on a website where you have all kinds of formatting options at your disposal.
The Creator parameter contains your Company, Team or Individual Developer name. It helps users to recognize projects to originate from the same production team.
The Website parameter contains the URL under which the user can find more information about the game. Launchers can use this to send users to your website if the user looks for more information about a game.
The Window Size parameter defines the desired window size for your game. Use (0,0) to make launchers run your game in full screen mode. Using an explicit size is usually only recommended for games not Capturing Input Devices.
The Icons list defines a list of image files (*.png or else depending on used image modules) which launchers should use to represent your game. Icons should be square in size and can be of any size. At least one icon should be specified. Adding multiple icons allows launchers to pick the best suited icon before scaling. The order of the icons is not important.
The Exclude Patterns defines a list of path patterns to exclude from distribution. Use this on release profiles to ensure development or debug files are not present in the release build. The best way to handle this is to add development and debug content to a single sub directory of the Game Data Directory. This way you can exclude all development and debug files with a single pattern. Any number of patterns can be used. If a pattern matches a directory all content below the directory as well as the directory itself are excluded.
The Required Extensions defines a list of additional file extensions your game needs. While building the distribution file the project editor examines all included files (after exclusion patterns have been applied) for used file extensions. Only file extensions matching Resource Modules present on the development machine are automatically included. If you need file extensions the project editor can not see (for example because you download them at run-time) then you have to add them to this list manually. Launchers use the required extension list to ensure all required resource modules are present so your game can be launched.
The DELGA File defines the filename to write the distribution DELGA file to.
The Distribute button starts building the distribution DELGA file for the selected profile. A dialog will be shown with the progress of the building. Once finished you can close the dialog or optionally open a file browser with the directory the DELGA file is located in.
The Test-Run button switches to the Test-Run view so you can test your game.
In this view game can be Test-Run using a Game Profile and Launcher Profile. The launcher profiles are stored by launchers like the Drag[en]gine GUI Launcher. Launcher profiles can be used to simulate different user module configurations. You can test for example how the game behaves if a user uses a strong or weak Graphic Module. The game logs are shown in real-time in the content area of the window.
The game is run directly from the Game Data Directory. Run-time data is stored in the cache directory in the Project Directory. The last run logs are stored in the file testRun.log located in the Project Directory.