My name is Marshall Belew, and I’m the lead developer at Koios Works, LLC. Before Koios Works, I was a software designer at Hewlett-Packard.

My introduction into the game industry is typical. My position at HP had nothing to do with video games, but I was running home every night to work on my own personal game projects. I knew that entering the game industry is a tough road, so I solidified my credibility by joining a game development; program at the University of Washington.

Koios Works has been around since November 2003. Tin Soldiers: Alexander the Great is the first title.

Tin Soldiers happened through the vision of Koios Works’ founders Kevin Albright and Russ Pearlman. They saw an opportunity to take classic miniatures based war games and put them into a video game. Miniature gaming has been around for years, but the cost and time it takes to set up a game keeps casual gamers away.

Alexander loosely follows the popular DBM (De Bellis Multitudinis) rule set. We chose these because the hard core miniatures audience will feel right at home. Casual gamers will need to know nothing about the rule set because all dice rolls and table lookups are handled under the covers. The player can get right to the task of taking over the world.

The turn system is completely unique. We have been calling it simultaneous turn-based because the player does not take turns as in Checkers. All orders for the entire army are placed at the beginning of a turn. The AI places his orders at the same time. The player hits ‘Go’, and the armies begin to fight. Units may gain reaction bonuses so that the player (or AI) can change strategy mid-turn.

The decision to use Managed DirectX was not made over night. I am comfortable with C# as well as C++. I have also had experience with both DirectX and OpenGL. In the long run, the language was the deciding factor. C# tends to be very clean, easy to read, and easy to debug.

So far the best advantage is rapid tool development. I have been able to insert our rendering engine into a windows form and have a tool cranked out in days.

So far our performance bottlenecks are in the graphics pipeline. We’re doing some heavy alpha channel rendering that remains our primary load.

Most of the disadvantages of Managed DirectX are in the fact that the version we are using has some noticeable bugs. The Audio/Video library will hold on to resources and never let go. The built in Sprite class devours texture memory. The built in Line class seems to create random crashes. The Font class has a memory leak. Most of these have a work-around, but they always take a lot of time to discover.

Garbage collection is not generally a problem because our large resource objects are collected between levels.

Our source code isn’t exactly the caliber of Half Life, but we definitely obfuscate the code. Obfuscating brings its own challenges, so I highly suggest finding your obfuscation solution very early in the project. It will save you grief in the long run.

The good news for us is that our publisher built our installer. It will cleanly install .Net and Managed DirectX. Since we have a digital distribution model, it does add slightly to the overall download time.

I think the overall architecture would be very similar in C++. However, managed code gives you method and property attributes for serialization. Our save game objects can be (de)serialized without a lot of parsing and translation.

Some of the architecture revolves around our unit test structure. The game engine library is dynamically loaded up by csUnit. We are able to test a lot of the game without actually loading it and playing it.

I’m pretty sure you can do more in C++, but I will stress my argument that managed code looks better. First, here is a snippet from the DirectX SDK in C++:

// Texture stage states
m_pd3dDevice->SetTextureStageState(0, D3DTSS_COLORARG1, D3DTA_TEXTURE);
m_pd3dDevice->SetTextureStageState(0, D3DTSS_COLORARG2, D3DTA_DIFFUSE);  
 
m_pd3dDevice->SetTextureStageState(0, D3DTSS_COLOROP, D3DTOP_MODULATE);
 
m_pd3dDevice->SetTextureStageState(0, D3DTSS_ALPHAARG1, D3DTA_TEXTURE);
m_pd3dDevice->SetTextureStageState(0, D3DTSS_ALPHAARG2, D3DTA_DIFFUSE);

m_pd3dDevice->SetTextureStageState(0, D3DTSS_ALPHAOP, D3DTOP_MODULATE);

I use capitals for constants when I code, but when they are everywhere they are very ugly to read. Here’s something similar in managed code:

// Texture stage states
device.TextureState[0].ColorOperation = TextureOperation.Modulate;
device.TextureState[0].ColorArgument1 = TextureArgument.TextureColor;
device.TextureState[0].ColorArgument2 = TextureArgument.Diffuse;

device.TextureState[0].AlphaOperation = TextureOperation.SelectArg1;
device.TextureState[0].AlphaArgument1 = TextureArgument.TextureColor;

I realize I could wrap C++ to look like this, but who wants to do that all the live long day when there’s games to be made? The other benefit of this style is that IntelliSense’s hover-over tool tips and expansions are invaluable. I hardly ever have the SDK documentation open.

I can definitely say that we are working on another Tin Soldiers title. I cannot say much past that.

There are currently no plans for licensing the Tin Soldiers engine.

We started by creating a level. We then shopped that around to various publishers. The publisher search was definitely an emotional time for us. One can expect a publisher to respond anywhere between three to six months. For a startup company, this is an eternity. I was happy when Matrix Games finally picked us up because they have a solid history of publishing award winning war games.

We have had several questions about what it was for, but there has been not one negative comment about the choice to use managed code. Most people see the game rather than the technology behind it.