Please look here to browse the state of this project.
Over the winter break of my senior year, I took on a project with two long-time friends of mine, Breck Fresen (CMU CS ‘09) and Erich Wolodzko (Stanford CS ‘09) [citations needed]. After completing the majority of our undergraduate degrees, we challenged ourselves to see what we could accomplish in 3 weeks time. We opted to attempt to create the system framework for a real-time strategy game (i.e. Starcraft, Age Of Empires, Command & Conquer) that is entirely data driven. Ideally, using the framework, one could play any number of style of RTS games that have completely different art, maps, units, etc. just by switching a config file. Our feature list included internet multi-player capability, 3D accelerated graphics, and OS portability.
These goals imposed many difficult design decisions on the structure of the system. In a collaborative effort, we designed the system to work on 3 separate threads: a main control thread, a game logic thread, and a network maintenance thread. The main control thread was in charge of the presentation layer and window/input handling. The network maintenance thread handled our unique strategy of synchronizing multiple players for game actions. The game logic thread took input from the control and network threads to progress the game forward.
To maintain synchronization across multiple computers, we decomposed all game logic into a set of “game commands,” specified by a game-time timestamp and meta-data depending on what the command represented. We turned all user input into a corresponding game command, and, depending on the length of network latency, elegantly broadcast a time-chunk of game commands to all other peers. Once all peers acknowledged receiving all game commands up to a particular game time, those commands were allowed to be executed at their appropriate time by the game logic thread. This strategy guaranteed no 2 peers falling out of sync with game commands, but could become jerky or locked depending on network instability.
I, personally, was a part of every design decision. Furthermore, I was in charge of the majority of the control thread’s responsibilities, wrote a custom GUI framework to work both as a menu-ing and in-game interface system, implemented all graphics work (OpenGL), and implemented my share of game logic.
The project was written entirely in C++. It has only been tested to compile under g++ and uses GLFW for portable windowing.
In 3 weeks we were able to successfully synchronize 3 computers across the nation to create, select, and move multiple units across a complex terrain. Hopefully one of us will breathe life into the project later when we have the time and energy to do so.
