Category: gw3 engine

A lot has changed since we wrote the first line of code in 2003 for the g0/g1 (g-zero/g-one) engine, for what ultimately became Lost Legends.

Back in those days, Microsoft Windows was the big operating system by far, and the engine used Microsoft Direct3D for graphics, and Microsoft DirectSound for sound effects and music.

Most computers had a single CPU, so the implementation of the engine was fairly straightforward.

Ghostwood Games' Lost Legends, gzero engine architecture

Over the course of programming Lost Legends we learned a lot. And, a lot has changed in computers since then.

We spent some time upgrade the engine, but ultimately, we decided that in order to address some core game design issues, core implementation, issues, and how computers have changed, we went back to the drawing board and rewrote everything from the ground up.

To begin with, the new gw3 engine is based on crossplatform technologies for easier implementation and porting.

Graphics are implemented in OpenGL, and sound effects and music use OpenAL. And, the gw3 engine currently uses SDL to abstract out platform level differences in window, input, and event handling. STL, well STLport specifically, and the boost library are used to provide crossplatform containers and base additional functionality.

The new engine architecture is also built assuming 2 – 4 CPU cores.

Ghost Games' gw3 base engine architecture

Processing is broken into 4 key, independent threads of execution. Each thread runs fully asynchronously at a different maximum rate, and inter-thread communication at this level is handled using thread safe queue’s implemented using boost.

The main thread which is started when the engine runs also handles processing and dispatching input and operating system events, as well as updates to the UI, and management of the local player character.

Rendering in OpenGL and operating system (OS) messages and events are handled together due to the thread requirements of OpenGL and OS window management.

Audio effects and music playback are handled in their own thread using OpenAL, with effects stored as WAV files, and music as Ogg Vorbis.

The simulation thread drives the whole system and runs the world generation and management, mob AI, and authoritative world state.

A simplified example of how these components work together:

Player presses the attack button on the mouse to cast their current magic spell

OS generates an event for the mouse button

Renderer thread asynchronously detects the OS event and sends the event information to the Main thread

Main thread receives the message and determines that this should translate into an attack

Main thread sends the request for an attack to the Simulation thread

Simulation thread receives the request from the player, and determines this is a valid attack and can be carried out

Simulation thread executes the attack causing an audio event for the spell firing to be sent to the Audio thread, and a visual event for the spell to be sent to the Renderer thread

Audio thread receives the request to play the spell firing sound, and so it loads and plays the sound

Renderer thread receives the request to display a new visual which happens to be a burst of particles indicating the spell

Beyond these core threads, there are also other secondary threads as well.

Ghostwood Games' gw3 engine architecture

These additional threads handle network communication to other players, gameplay and visual physics for the simulation and renderer threads, and loading of large files off the file system.

So, technically the engine will scale to at least an 8 CPU core system.

As with the previous engines, the heart of the gw3 engine is the ability to procedurally generate and modify the game world dynamically.

With this new architecture it’s possible, although unnecessary in the short term, to continue to evolve the threaded engine architecture to include an arbitrary number of data generation threads.