Conquest is a simultaneously executed turn-based tactical combat game placed in a dark and distant future. Play the role of a futuristic commander. Divide your armies and conquer the world. Position satellites to reveal your opponents. Launch missiles to annihilate large troop formations, but watch out for incoming drop pods behind your back. Standing in your path to victory are other commanders like yourself. Fight them off one by one and prove you are the greatest of the great. The combination of fast gameplay and randomly generated maps equals to long, restless nights of battles for cities. Drag and drop your way to victory. Divide and conquer!
Some highlights of the inner workings of Conquest.
Posted by SephiRok on Dec 13th, 2010
Conquest uses our fully custom-built platform-independent Proxy Engine, which is primarily based on OpenGL, OpenAL, and boost, along with a couple minor utility libraries like SDL and curl. Our main design goal for this engine is to keep things as simple as possible with a "minimal and complete" interface. A lot of engines and programs out there introduce unnecessary difficulty due to fancy naming and abundant interfaces, trying to predict every possible usage scenario and complementing it with a corresponding interface - while we try to strip things to their bare essentials. We also achieve this with 0 cost, since all our tools are free or open-source.
Currently there are eight sub-modules represented by their different shared libraries:
To compensate a lack of manpower concerning content creation, Conquest uses a powerful system for generation of attractive random worlds. Different raw heightfield tiles (insular shape) are randomly combined, scaled based on terrain type (plains, mountains), then smoothed with a gaussian kernel. Based on ground characteristics like height and slope, texture maps are rendered out via texture splatting, storing the ground texture distribution in the color channels (which then get blent together in realtime). All geometry is stored in vertex buffer objects for increased performance, culling is performed on a per-territory basis.
We create a new process for the server when a user creates a game, be it single- or multi-player. This allows us to fully split the client and server logic and makes for cleaner code and more defined interfaces. The local client communicates with the server through TCP, the same way as every other client, but we also have shared memory allocated for signaling completed initialization to the client.
For scalability and to prevent unnecessary resource usage we dynamically spawn official game server processes.
For example, currently we are running 6 different official server world configurations. With no one on any of the official servers, that means 6 processes running. If a player joins one, another one would go up with the same configuration (if the maximum amount of servers with that configuration is not reached and none are empty). If the player then leaves the server, the new spawned one would go down in 5 minutes (max).
This is accomplished using shared memory and process control. Using boost::interprocess we keep an array of process IDs and "server empty" flags in shared memory for each configuration. When a process first starts it finds the first unused slot of its configuration and sets it to its own process ID. When a player joins a server, the server checks if there are no empty servers of the same configuration running and the limit is not reached, and potentially starts a new process using our process control class. Every fixed interval each empty server checks if there are any other empty server, if so, it removes itself from the shared memory slot and dies. The shared memory array is also regularly cross-checked with the process list to free slots of processes which did not remove themselves.
We have a build system in place, which can build and update Conquest for Windows, Mac OS X and Linux with a one-liner:
Resources/Unix/MakeUpdate.sh && Resources/Unix/UpdateLive.sh && Resources/Unix/PublishUpdate.sh
This requires no manual user interaction, but it does need a specific Mac connected to the network for the OS X build, since (as of our knowledge) there is no solid OS X cross-compiler for Linux. Some details follow.