Making of Sandox, the Cryengine Game Editor

If you are a game developer, you are probably aware that there are many game engines out there. However, only a few of them made the history of game development. Among them, there are software like Unreal Engine, Unity or Source Engine that have been used in a plethora of games. Another great game engine is Cryengine, developed by Crytek and used for the development of a great video game like Far Cry and Crysis.

While the game engine is one of the most important components, developing good games also requires proper tools and, in particular, game editors have a crucial role. During Codemotion Rome 2019, Alessandro Osima, Tools Engineer at Crytek, delivered a speech about the development of Sandbox, the game editor for Cryengine. In this article we will provide an overview about such a game editor, starting from the history of its development and highlighting some of the crucial choices taken by the Sandbox development team, based on the story narrated by Osima during his talk.

Overview of Sandbox

Sandbox was originally created 15 years ago, with the specific goal of supporting the development of Far Cry. From its origin, it has continuously evolved and many games were created with it, ranging from Crysis to VR games such as The Climb.

As with many other game editors, Sandbox is coded mostly in C++ and offers a set of WYSIWYG tools like material editor, trackview (used to create cutscenes), particle editor and many others. In addition to this, Sandbox also offers an extensive set of Python bindings that tech artists can use to script simple tools.

In general, every tool that is included in Sandbox is actually a plugin, making such an editor highly modular. The Core API implements basic things like Asset Management, Windowing, Serialization and Plugin Management. Then, at startup, the engine loads all the plugins. This design choice allow developers and game teams to easily create their own plugins, with an extremely flexible approach.

Sandbox is available along with Cryengine from the official website, where you can find both the executable files (for Windows 64-bit and 32-bit) and the full source code.

Development of Sandbox

During his talk, Osima discussed how Sandbox has been developed, starting from the first publicly available version of it, released in 2004. As already stated, it was developed in C++, based on the Microsoft Foundation Classes (MFC), forming a simple, monolithic level editor with basic tools. In this first release, the game engine, the editor and the game code were all in the same directory tree.

After the success of Far Cry, Cryengine was significantly revised and readapted for Crysis. New tools were added, including primitive versions of the material editor, flowgraph, trackview and character editor. All these tools proved to be extremely useful to support designers and developers working on Crysis.

From Crysis 2 onward, Sandbox was available only as a modding tool for Crysis and Far Cry. We had to wait until 2011, when a free SDK for non-commercial games was released by Crytek.

The development model was based on improving on the previous version of the game editor (as well as the engine) and kept going on through many games.

By the end of the development cycle that ended with the release of Cryengine 3, the Sandbox team started focusing on the main critical issues to be improved. They thus identified two main areas of improvement:

• User Experience (UX): the team noted a quite steep learning curve, due to difficulties in following the workflow
• API: due to the growth of tools, API did not scale. The consequence was low stability, performance issues and also some inconsistent data handling, resulting in fragmented tools development over the years

To address these issues, Osima explained that the first main choice was to focus on UX, by introducing a new UX-driven development process. It consisted of translating any request for a new feature or improvement in a short-term or long-term development task. Then, a UX team evaluates potential solutions to the described problem, designing them and finally transferring them to the development team.

The second fundamental choice was to update the UI. The main problems derived from Microsoft’s choice of not developing MFC anymore. Moreover, MFC was complicated to programme and did not lead to consistent visual appearance. Finally, MFC only allows us to develop applications for Windows, which translates into a significant difficulty in supporting an eventual cross-platform implementation of Sandbox.

On the other hand, MFC was performant and could handle lots of data. It also provides many assets and widgets, which make it extensible and stylable.

The solution tackled by the Sandbox team was to opt for Qt, one of the most common open source C++ frameworks for GUI development. Qt is indeed a modern and multiplatform framework, easier than MFC, as well as very well documented and widely used in many applications. In addition, the team also developed a MFCToolsPlugin, aimed at supporting tools already developed with MFC. This choice was crucial in order to support an incremental switch from MFC to Qt. For instance, the material editor is still written in MFC, and has been included in Cryengine V, thanks to the MFCToolsPlugin, thus being embedded in a Qt window.

Takeaways

The current versions of Cryengine and Sandbox are embedding the results of all the aforementioned design choices. Analysing them in the context of the development process is useful to illustrate how such big projects are managed. Two aspects are particularly interesting here. First, incorporating UX evaluation in the development process allows us to include developers’ preferences in identifying new features and required improvements, which can significantly reduce the gradient of the learning curve, thus easing game development. Second, using a modern UI framework might be not enough; something that is good today may become obsolete after one, two or three years. The crucial choice is not just in the ability of replacing obsolete components, but in doing it by allowing incremental transitions between old and new components. The development of the MFCToolsPlugin is a great example of this, representing a winning choice for the Sandbox development team.