Picking a scripting language

We are planning to make the BitSquid engine largely scripting language agnostic. We will expose a generic scripting interface from the engine and it should be relatively easy to bind that to whatever scripting language you desire.

Still, we have to pick some language to use for our own internal projects and recommend to others. I'm currently considering three candidates:

C/C++

• Use regular C/C++ for scripting.
• Run it dynamically either by recompiling and relinking DLLs or by running an x86 interpreter in the game engine and loading compiled libs directly.
• + Static typing
• + Syntax checking & compiling can be done with an ordinary compiler
• + When releasing the game we can compile to machine code and get full native speed
• - C is not that nice for scripting
• - Huge performance differences between "fully compiled" and "interactive" code makes it difficult for the gameplay programmers to do performance estimates.

Lua

• Lua has the same feature set as Python and Ruby, but is smaller, more elegant and faster.
• Other scripting langues such as Squirrel, AngelScript offer reference counting and static typing, but are not as well known / used
• + Dynamic, elegant, small
• + Something of a standard as a game scripting language
• + LuaJIT is very fast
• - Non-native objects are forced to live on the heap
• - Garbage collection can be costly for a realtime app
• - Speed can be an issue compared to native code
• - Cannot use LuaJIT on consoles

Mono

• Use the Mono runtime and write scripts in C#, Boo, etc.
• + Static typing
• + Popular, fast
• - Huge, scary runtime
• - Garbage collection
• - Requires license to run on console
• - Can probably not JIT on console

First profiler screenshot

We now have the BitSquid thread profiler up and running. The profiler is a C# application that receives profiler events from the engine over a TCP pipe.

The screen shot above shows a screen capture from a test scene with 1 000 individually animated 90-bone characters running on a four core machine. The black horizontal lines are the threads. The bars are profiler scopes. Multiple bars below each other represent nested scopes (so Application::update is calling MyGame::update for instance). Color represents the core that the scope started running on (we do not detect core switches within scopes).

In the screen shot above, you can see AnimationPlayer::update starting up 10 animation_player_kernel jobs to evaluate the animations. Similarly SceneGraphManager::update runs five parallel jobs to update the scene graph. SceneGraphAnimators only copies the animation data from the animation output into the scene graphs. But even this takes some time, since we are copying 90 000 matrices.

(Of course if we would make a 1 000 people crowd in a game we would use clever instancing, rather than run 1 000 animation and scene graph evaluations. This workload was just used to test the threading.)

Parallel rendering

I've spent the last week designing and implementing the low-level parts of the renderer used in our new engine. One of the key design principles of the engine is to go as wide / parallel as possible whenever possible. To be able to do that in a clean and efficient way a good data streaming model with minimal pointer chasing is key.

With the rendering I've tackled that by splitting the batch processing in three passes: batch gathering, merge-n-sort and display list building.

In the batch gathering pass we walk over the visible objects (objects that have survived visibility culling) and let them queue their draw calls to a RenderContext. A RenderContext is a platform independent package stream that holds all data needed for draw calls (and other render jobs/events/state changes etc). This step is easily divided into any number of jobs, by letting each job have its own RenderContext.

After the batch gathering is done we have all data needed to draw the scene in n number of RenderContexts. The purpose of the merge-n-sort step is to take those RenderContexts, merge them to one while at the same time sorting all batches into the desired order (with respect to "layers", minimizing state changes, depth sorting etc).

We now have one sorted package stream containing all the draw calls that we can send off to the rendering back-end. At this point we can again go wide and build the display list in parallel. Here's a small sketch illustrating the data flow:

Red sections belongs to the platform independent renderer. Blue sections belongs to the rendering back-end (in this illustration D3D11).

Simplified JSON notation

JSON is human-editable, but not necessarily human-friendly. A typical JSON configuration file:

{
    "ip" : "127.0.0.1",
    "port" : 666
}

A more Lua-inspired syntax is friendlier:

ip = "127.0.0.1"
port = 666

This syntax corresponds 1-1 with regular JSON syntax and can be trivially converted back and forth with the following rules:

• Assume an object definition at the root level (no need to surround entire file with { } ).
• Commas are optional
• Quotes around object keys are optional if the keys are valid identifiers
• Replace : with =

On the other hand, all syntax wars are pointless and will only send us into an early grave.

Multithreaded gameplay

How do we multithread gameplay without driving gameplay programmers insane?

My current idea is:

• Do all gameplay processing as events reacting to stuff (such as collide_with_pickup_object), not through a generic update() call.
• Each event concerns a number of entities (e.g., [player, ammo_pack]). The processing function for an event is allowed to touch the entities it concerns freely, but not any other entities.
• Each frame, consider all events. Let two entities being in the same event define an equivalence relation between those two entities. The corresponding equivalence classes then define "islands" of entities that can be processed safely on separate cores.
• Assign each island to a core, process the events for that island one by one on the core.
• Provide a thread-safe interface to any global entitites that the event processors may need to touch for effect spawning, sound play, etc. (Preferrably through a queue so that the global entities don't have to be touched directly from the event processors.)

Some concerns:

• Will the islands become "too big". I.e., if almost everything interacts with the player, there is a risk that everything ends up in a single big "player island".
• Will it be reasonable for gameplay programmers to write code that follows these restrictions.

Two way serialization function

A trick to avoid having to keep the serialization code for input and output in sync is to use the same code for both input and output:

struct Object {

template <>

STREAM & serialize(STREAM & stream) {

return stream & a & b & c;

}

int a, b, c;

};

Here we have used & as our serialization operator. We could use any operator we like.

We then just implement the operator to do the right thing for our input and output streams:

template < > InputArchive & operator &(InputArchive &a, int &v) {

a.read(&v, sizeof(v));

return a;

}




template < > OutputArchive & operator & (OutputArchive &a, int &v) {

a.write(&v, sizeof(v));

return a;

}

These are both template specializations of a generic streaming template.

template <>

STREAM & operator &(STREAM & stream, T & t) {

t.serialize(stream);

}

Now we can stream all kinds of types either by implementing serialize in the type or by defining a template specialization of operator & for that type.