This article outlines the various main folders and files of a standard CRYENGINE build.
The "root directory" of CRYENGINE means the folder where you extracted the CRYENGINE .zip archive contents to. As a common example, this is probably something like
c:\cryengine\. For example, if your folder path looks something like
c:\ce3sdk\bin32\editor.exe then c
:\ce3sdk\ is your root path and from there any references to "
<root>\" in the documentation should make sense.
The root directory (commonly referred to as
<root>\) contains several sub-folders which are explained further on in this article. Furthermore, it can also contain the configuration files system.cfg and editor.cfg which are used to configure console variable settings. Multiple log files also will be written in the root directory when the engine is run. Instead of these logs being overwritten, they're moved to the
\LogBackups folder and a new version is created.
The root path should not contain spaces or non-latin characters. The asset pipeline does not support this sort of naming. You can use Basic Latin and Latin-1 Supplement (Underscores are allowed too).
Bin32 and Bin64
The Bin32 and Bin64 directories contain the 32 bit and 64 bit Sandbox executables (Editor.exe), the game launcher (GameSDK.exe), and all required engine DLL's.
The Bin32 directory also contains a sub-directory called rc. The Using the Resource Compiler (RC) can be called by the engine on demand to transform source assets to an optimized format (e.g. TIF textures to DDS).
Note with CRYENGINE 3.6 EaaS, the 32-bit Editor is discontinued. See CRYENGINE Basics for more information.
All C++ source code as well as solution and project files are located in the Code directory.
The main solution of the engine is
Code/Solutions/CryEngineGfx.sln, depending on whether you have an SDK with support for Scaleform or not.
For more information on the source code, please see Getting Started with Game Code. If you have access to Engine source code, you'll find information on that in the appropriate section.
The code folder contains several tools, which are described in the chapter Tools Description.
The Editor folder contains resources that are used by Sandbox, like icons and other UI data, settings and templates.
When redistributing a stand-alone application or game using CRYENGINE, it is not needed to redistribute the Editor directory.
This directory contains various objects used by the Editor, such as helper objects which are rendered in the viewport.
This Time of Day is loaded for new levels upon creation.
Text file containing Tips, accessible from Help -> Tip of the Day menu option.
Records events from Sandbox for debugging purposes.
This contains the default settings for the Environment Panel.
Config script for use with the Minimap Tool.
New Modular Behavior Tree nodes can be declared here.
The Engine directory has many redistributable files which are required by the Renderer and other systems.
Configuration in text files to set the different engine settings for low/high PC settings, consoles.
Basic materials and textures required by the shaders.
Default TrueType font used by the engine (i.e. the in-game console).
All the shader source and binaries.
All game specific data and assets are usually stored in the GameSDK directory. It is possible to change the name of the game folder or have several game folders at the same time in a single CRYENGINE root directory.
The game folder and game DLL to be used can be configured with the console variables sys_game_folder and sys_dll_game that can be set in the system.cfg. Please see Using Different Game Folders for more information.
Animation assets and
Config files to alter gameplay based on difficulty level chosen. Easy is selected by the Engine by default.
.ent files which instruct the Entity System about which script entity class should be registered.
All the game levels should be in this directory.
Multiple data files to support different game systems.
Global XML Material files used by levels.
All the static objects and skinned characters along with materials and textures required by them.
XML Prefabs files created in Sandbox.
Lua scripts for Script Entity classes, AI and different game systems.
All sounds assets.
All other textures required by levels or other textures re-used by multiple objects.
Video assets in .USM format (i.e; videos not played through Scaleform).
DEPRECATED - Flowgraph saved in .xml format to be used with the AI System.
DEPRECATED - Templates used by the Animation Graphs that allows special interaction.
See Body Damage and Destruction for more information.
.xml files used for cloud sprites. See Setting Up Weather Effects for more information on their creation.
.xml files used to implement the different in-game dialogs.
Default action maps templates.
Entity Archetype libraries, used to specify predefined entity parameters or to provide new alias names to existing entity classes.
Pre-defined equipment packages used by actors on level startup or changed dynamically via Flow Graph.
Lens flare .xml libraries which store settings used by the Lens Flare Editor.
Location to save custom flowgraph modules.
Flow Graph templates.
Audio scripts used to define preloaded audio, audio events and music setup.
Script used by the Engine to define custom rumble effects for gamepads.
Used by the GameTokens system to maintain persistent values across multiple levels.
See Hit and Death Reactions System for more information.
Script containing custom parameters used by the Lightning Arc system.
Define custom effects (particles, decals, sounds) based on interactions with different surface types. Some files should be opened with Excel.
.xml data saved by the MusicLogic system.
Particle Effect libraries created by the Particle Editor Overview.
Engine data files used for sky elements such as the stars.
Assets and scripts needed for the User Interface.
Scripts needed by the AI system, including behavior scripts and goal pipes.
GameEffects.xml stores custom visual effects and overrides for gameplay related events, such as killcams.
Script based entity class. Here you'll find scripts for things such as weapons, vehicles and many more items.
Script data used by the Feature Tests system.
.lua implementation of Flow Nodes.
Script side implementations for the GameRules.
Script to control filtering options for Multiplayer Killcam.
.xml data used by the Procedural system in Mannequin Overview 3.5.
Properties script to control Matchmaking system in Multiplayer.
.xml data to support the network system; including scheduler and compression policies defined for the entity classes.
.xml data for the Playlist system for Multiplayer. See PlaylistManager.cpp for more information.
.xml data used by the Progression system for Multiplayer. See ProgressionUnlocks.cpp for more information.
Sound events triggered by gameplay events, such as announcements and battle chatter.
General purpose script functions for math operations, etc.
See here for more information on the Localization System.
Pak files are essentially zip files. They can be extracted with an archive program such as 7zip on WinRAR. It is possible to store most of the content of the game inside Pak files. The only exceptions are level files which should be stored outside of the Pak files.
It is recommended to use the Resource Compiler to generate Pak files. The RC Jobs can used to automate this process along with converting intermediate files to optimized platform specific files.
The console variable sys_pakPriority controls priority between opening files from the filesystem and from within pak files.
Pak files are loaded alphabetically. If you wish for a particular pak file to be loaded after another one, you should prefix the filename with a letter that comes later in the alphabet.
For example, say you have a small game package you want to release and it contains files a user may already have inside existing pak files. Take for example:
If you have changed this file in your own package then you want yours to be loaded afterwards to ensure the user gets your version and not the original version.
This object appears by default inside the
GameSDK\Objects.pak file. To make sure yours gets loaded, place yours inside
GameSDK\z_Objects.pak, with the z_ prefix ensuring that it's loaded last.
This folder is used to place user-generated files that may be created when using console commands like SaveLevelStats or when benchmarking performance.
Multiple stand-alone tools and exporters for CRYENGINE can be found in the
\Tools directory. When redistributing a stand-alone application or game using CRYENGINE, it is not needed to redistribute the
Find more information about what the tools do in chapter Tools Description.
This directory is creating during run-time to store files generated by CRYENGINE or Sandbox. This include User profiles, compiled shader combination and some temporary files created by Sandbox. It's safe to delete this directory when CRYENGINE is not running.