I read on a forum somewhere that the screenshot I show of Containment looks like either a ‘Snake’ or ‘Light cycle’ game and while it might be fun to write one of those it aint one of those 
Basically the player’s viewpoint in Containment is one of a ‘radar’ style blueprint of an installation so the lines you can see below are the walls of a room that shimmer in the same way that the holograms do in films like Star Wars (where the idea was sparked from). There are two flavours of Containment being toyed with at the moment. The first was originally intended for single player and would have been the version written for WiiWare and the second is a Multiplayer RPG type affair.
Containment comes in three parts. The first part is the C++ DirectX application. This serves as the main user interface for the player. The second part is the MySQL database that contains the world and status of Containment and the final part is the PHP scripts that allow the user interface application to manipulate the Containment database. All three components make up Containment and all three are a fun programming challenge all of their own - okay, technically you are not programming a database but you get what I mean.
The C++ application had to be multi-threaded. The reasoning behind this was that http requests and responses are not real-time, it can takes seconds to process one transaction. I couldn’t have a 3D display pause while the app went off and updated the database so I put the actual database communication code into another thread. When something is needed from the database or the database needs to be updated a transaction is sent to the comms thread which processes it and gets the result. The comms thread itself blocks while waiting for the results but it means the main thread of the application can proceed. The user still has to wait for the results but at least the simulation continues smoothly while those results are coming in. Each communication is a transaction and each transaction is a C++ class derived from a base Transaction class. They all share a common interface composed of three functions called:
Begin
Update
FInish
Update is the actual function that performs the http communication with the server while Begin and Finish are used to provide house keeping tasks. An example of this is player registration. Currently to join the game the player has to register with the Containment Computer and this is done like:
Register user password
While this transaction is being processed we don’t want the player to be able to type the same line in again so in the Begin function the keyboard console is turned off and in the Finish function it is turned on again. So as you can see those functions can be used to provide a measure of serial flow in the game execution. The alternative would have been to deal with duplicate transactions going through at the same time.
Incoming transactions are placed into an ‘in’ list while processed transactions are placed on an ‘out’ list with critical sections being employed to stop concurrency issues raising their ugly little heads. The critical section is entered, the item removed from the list and the critical section is left and the transaction is then processed. This means that very little time is spent in the critical section which hopefully means very little stalls in the main thread or the communications thread.
I spent most of this evening trying to figure out why a particular PHP script was reporting obscure errors. I kid you not - I spent at least 2 hours modifying, uploading and modifying again, inserting echo statements etc.. all in aid of tracking down a strange parsing bug. I found out what it was in the end and I could have kicked myself when I found out what it was. I had:
#include “test.inc”
when it should have been:
#include “test.inc”;
Can you spot the difference? Cunning eh?
It’s amazing. Rather than tell me there was a problem with this line it reported strange errors to do with variable declarations and turned out to be a bitch to find. Of course, what this really boils down to is that I really depend on the compiler to catch stupid syntax errors for me and when I don’t have a compiler such as in this situation I get stupid errors.
You live and learn.
Containment contains a lot of text parsing with a very limited Natural Language Understanding system which it turn leads to a problem - localisation. Because the parser is looking for english it obeys the rules of english which means it is very unlikely that the game can ever be localised to any other language since the parser would have to be coded to match that language. It’s for this very reason that I struggled long and hard over the parser concept since including it is essential for the core of the game but it does mean that only english speaking people can play the game. I had thought about using a made-up symbolic based language instead but decided that it would present too much of a learning curve to begin with and would probably put many people off.
I have been working for a while on a game concept called ‘Containment’ but got side-tracked into writing small flash games that while were fun didn’t really lead anywhere useful. I may still continue to do them in the future but for now I need to concentrate on Containment otherwise it will never get finished. At the same time I finally found a blog style that I like (it’s the one that Cliffski found for his blog) and over time I will modify it to suit my purposes since it’s a little too white for me at the moment - but I love the clean style it presents.
To get things started here is an image of the test app for Containment that I created over a year ago and sparked off the game as it is now:
