Introducing: Crimild’s Sandbox

I’ve been in autopilot mode during the last month or so and thus it was hard for me to keep the blog updated. A lot of exiting things have been added to Crimild lately (and to everyone’s surprise, just one or two little refactors) and I promise I will describe them during the following weeks. But for now let’s focus on the newest addition to the engine: the Sandbox

The Sandbox
The Sandbox

What is the Sandbox?

While we we’re discussing about our next project at Building Brothers, we realized that a tool was needed in order to speed up development process, not only on the technical aspects, but also on level design, assets and gameplay. Our Game Designer needs a tool to create a level and test any new feature, making changes in real-time if needed without having to wait to developer to implement them. Artists needed a way to update models and textures and verify that they look correctly without the need of a new build. And developers needed a tool to implement and test new features as fast as possible through the use of scripting and shader editors. And so the Sandbox was born.

Crimild’s Sandbox is a desktop application which goal is to help developers and designers alike by including a WYSIWYG scene editor, scripting and debugging tools and some other features that will be disclosed as they’re implemented. It currently runs only on Mac OS X, but it will be available on Windows and Linux as soon as I have the time to do so.

Loading and displaying a scene in the Sandbox
Loading and displaying scenes in the Sandbox

Is the Sandbox a Game Editor?

The short answer is “no” (although a more optimistic one would be “not yet”). As it is right now, the Sandbox is more of a testing tool than an editor. Of course, you can use it to build scenes and later import them into your projects. But the whole idea of the Sandbox is to be able to experiment with any new feature and then see how it behaves in real-time. Since the Sandbox uses the same rendering techniques as any other Crimild-based app, you can rest assure that if something works in the Sandbox, there is a pretty big chance that it will work on your program. Of course, platform-specific constrains may still be an issue but the Sandbox will help you isolate them.

What’s included in the box?

The Sandbox is still in a very early stage of development, with only a couple of features already working. Among them we have a Scene Hierarchy Viewer that let us understand how a scene is composed by displaying a tree of nodes. In addition, a Node Inspector displays information about a selected node in the scene, along with a list of components attached to it. If a ScriptComponent is found, a Script Editor is available for the user to edit the script in real-time without having to restart the application. A simple Pathfinding tool is also included, allowing level designers to place waypoints comforming a walkable path for characters.

Script Editor
Editing Lua scripts in real-time

The Sandbox has two modes: Editor Mode and Simulation Mode. The former one will let you create and change a scene using any of the available tools. You can add new nodes, components, cameras, scripts, etc. Once you have your scene ready, you enter Simulation Mode by clicking the Start Simulation button. In this mode, scripts and other behaviors are executed. It is possible to edit scripts while the simulation is running and see the changes take place in real-time.

Path edition tool
Path edition mode

New Crimild features

I’m going to dedicate full posts to each of the latest changes in Crimild, but here’s a brief introduction to the ones related to the Sandbox:

HTML interfaces with WebKit/Awesomium

This is perhaps the most interesting of the newest additions. I integrated the Awesomium framework in order to create HTML based user interfaces for the Sandbox. By using HTML, CSS and Javascript we can create new panels and editors in minutes instead of having to code an entire UI library for Crimild. Right now, all panels in the Sandbox are actually HTML Divs that can be dragged around the screen if needed. Awesomium is based on Chrome’s WebKit and renders all output into a memory buffer that can be later used as a texture. It’s very simple to use and the results are incredible (no, I’m not going to say “awesome”. Oh, I just did).

XML Scene Factory

The Scene Factory is a new addition to Crimild that let developers define new scenes using XML, declaring nodes and custom components, in addition to Lua scripts and OpenGL shaders. New scenes can be created and used in your programs without having to wait for a new build.


I mentioned this several times in this post: Crimild has support for Lua scripts. Yeah!! A new ScriptComponent class has been added to the engine that handles script compilation and execution. Scripts can be created on the Sandbox and built on the fly without having to restart the application. Scripting support is a huge speed boost for the development process

Closing comments

Even in its current state, the Sandbox has proven to be a great tool for rapid prototyping of scenes. I successfully managed to position cameras and make them behave as I commanded by using Lua scripts. Also some simple pathfinding techniques have been tested on the Sandbox to be later used in our next projects.

As for the future, I’m planning on adding a lot of debugging tools and probably a shader program editor. Some sort of binary file format specification will be needed at some point in order to save our scene and import it in another project, but we can manage with XML so far. There are too many features that can be added in future iterations that is hard to tell how big this thing can become.

Forcing i386 architecture in Xcode 4.0.2 SDK

So I decided to upgrade to the new Xcode SDK on my Mac. And I did it during the weekend just in case something go wrong. And of course, something went wrong [Note: I’m not going to rant about the new Xcode interface. I just don’t like it. That’s it.]

Anyways, it seems the new SDK (Xcode 4.0.2) does not include the old gcc 4.0 compiler anymore. Instead, we’re left with gcc 4.2 which is optimized for 64bits compiling. The problem is that Crimild and some of the third-party libraries that I’m using do not yet support 64bits. I knew about this beforehand and my mistake was to trust that there will be no side-effect after the upgrade.

It turns out that after installing the new SDK, all sources files were built for the x86_64  architecture instead of i386, even when my CMake configuration was forcing a specific configuration:

SET ( CMAKE_CXX_COMPILER /usr/bin/g++-4.2 )
SET ( CMAKE_C_COMPILER /usr/bin/gcc-4.2 )

After a lot of try and error (and a little bit of reading), a verbose make all process indicated that the -arch i386 compiler flag was correctly set at compile time, but there was no sign of it in the link phase. Then, I changed CMake to look like this:

SET ( CMAKE_CXX_COMPILER /usr/bin/g++-4.2 )
SET ( CMAKE_CXX_FLAGS “-arch i386” )
SET ( LINK_FLAGS “-arch i386” )
SET ( CMAKE_C_COMPILER /usr/bin/gcc-4.2 )

It seems a little bit redundant to me, but then again, this is the configuration that worked on both Eclipse and the Terminal. So I changed the CMakeLists.txt file with the new flags, cleaned up the CMake cache and regenerate the Makefiles. And everything worked again and all developers lived happily ever after (or at least until July, when the next SDK comes out).

I’m not sure if other people had the same issue (I couldn’t find anything relevant out there), so I’m leaving this here just in case someone needs it. Guys at Google, I know you’re reading this 🙂