What Grid?

I just read my last post and then flicked through my earlier ones and I noticed that I haven't actually said anything about what Mod Wars actually is and how it will work so I thought I'd drop in a little interlude...

I may not have actually done any design or implementation yet, but one thing I have done - and done lots of, is write down ideas for how I want the game to play. So far, I have 18 pages of documentation describing all aspects of the game that I can think of! I like to plan ahead ;-)

This is taken from the section 'Basic Premise':

"In Mod Wars players take control of a module that resides within a global computer system known only as “The Grid”. The grid is visually represented on screen and players “run” the grid by controlling their avatar along the grid lines with the keyboard.

Mod Wars could be considered as a kind of RPG as modules can grow in power over time and can diversify with different play styles. A module occupies a certain amount of storage within the computer system and the power of the module is related to the amount of storage that it occupies. The storage occupied by the module can be loaded with programs which are then used in combat against other modules. As the storage capacity of the module increases, so does the relative power of the programs that can be loaded."

Visually, imagine a dark background with blue gridlines all over it and then imagine little coloured blobs running along those lines - thats my players 'running the grid'! Of course this is all still in my head as I haven't even drawn any graphics yet.

From a gameplay perspective, Mod Wars is basically an RPG (Role-Playing Game). Player modules have stats which define how strong they are and what they can do. The programs that are loaded into the modules can be thought of as a kind of spell system that you might find in a fantasy game. Being a multi-player game, I'll allow players to get together in short-term groups called LAN's and more permanent arrangements (like a Guild/Clan) called a WAN. Yup this game is chock full of silly, geeky computer words. That's the benefit of being a computer geek that likes games and also happens to be a software engineer :-D

Phase 1 Plan

Over the last couple of months or so I've done virtually nothing on Mod Wars and although a large part of the reason for this was lack of time, in reality I was just putting off getting started.

I put together a little 'activity list' for things that I could be getting on with such as learning some more about Linux, working through some tutorials for a GUI package wxWidgets that I want to try out, drawing some simple graphics for the game etc. These are all things that will need to be done, but they are all 'non-core' activities. None of them actually move me forwards in my design or implementation in any way so they're still just another delay tactic and yet, I still didn't manage to do any of them!

Today I had a day off work and decided to try and do something positive to just get me going! I sat and thought about what I would like to implement as a very minimum for the first phase of development and it's quite simple: Just allow a player to connect to the server and nagivate around the grid. That's it! Still, because it's the first iteration there are a bunch of things that have to be done before anything else such as writing some basic networking code to allow the server to accept connections, and decide upon a message-passing mechanism for data between client and server. I'll want some logging functionality, configuration etc. These could be added later I suppose but because I absolutely know that I want them I'd rather just get them done first.

I knocked up a list of items and it came to 19 in all which was quite surprising considering how little there will be to show for it. Here's a snapshot of my little plan. As you can see I haven't bothered to put any timescales on it as they are meaningless when all I have is the odd hour here and there.

Experiments with Linux

In my last entry I asked myself a lot of questions mainly pertaining to the architecture of the project. The first of these was "Should I make the code platform-independent, including the client?" Morde was designed for Windows and I had no real means to test it on anything else. I never did much with it other than connect up a handful of clients to my server on my LAN. For Mod Wars, I'd like people to actually play it! That would require getting the server hosted, and after searching the web for games hosting companies, I found that all of them run Linux / Unix boxes unless you are hosting a Windows-specific game such as a Counter-Strike server or something.

So that solidified the decision to at least make the server cross-platform but what about the client? From a coding perspective, all the libraries I intend to use are already cross-platform. For example, SDL, boost etc. The main difficulty is getting started with a Linux build, having a single code-base that could be built on both Linux and Windows etc but I would have to deal with all this stuff for the server anyway so its just a natural extension to make the client cross-platform also. Plus, it widens the potential player base.

So this weekend, I took a big plunge! I've had an old PC sitting under my desk now for several months. A while ago I tried re-installing it (with Windows) to get it ready to sell but I kept getting the BSOD and I couldn't re-install it because it didn't like my SATA drive, despite me repeating the same steps as I took the first time I installed it. Anyway, I thought this would make a fine and dandy Linux box so I downloaded a copy of Fedora 5, burnt it to a DVD and booted it up...

First time around I had some issues setting up drive partitions (I was trying to be too complicated I think), so I re-did that bit just creating a few largish partitions for the /home and /usr directories. The DVD came with Gnome & KDE and had a whole bunch of development stuff like KDevelop, boost libraries, SDL and lots more. All in all, a quick and smooth install.

I haven't done much with it yet other than have a play and try to find my way around it. I loaded up KDevelop and tried to build a hello world application. I was a bit confused to find that the default hello world project created about 20 files in the project directory but I guess thats the linux way :-)

Connecting to the internet was simply a matter of plugging in an ethernet cable that was connected to my router. I was even able to get the Linux box to see the Windows machines that I had on the network; something that didn't work the other way around! I need to get a new monitor before I can really do much, as at the moment I'm just switching between my Linux and Windows boxes but I had a good start anyway.

Idea Dump & Name Change

Over the last week or so I’ve had lots of ideas for the game and I’ve been typing away furiously to get them all down on paper. I even had a name change! I was originally going to call the game Code Wars as I envisaged players doing things like throwing unhandled exceptions at their opponents and silly things like that! Although the idea of programming constructs is still in there, it has now become part of the crafting system rather than the core game itself, so it’s Mod Wars now.

Decisions, Decisions!

I’ve been thinking about Mod Wars so much lately that I’ve actually managed to totally overwhelm myself before I’ve even got started. I have all these questions running around in my head and many of them I’ve written down. Questions such as:

• Should I make the code platform-independent, including the client?
• What Gui library should I use?
• What about a networking library?
• A transport protocol for network traffic?
• Compression of traffic?
• How should I store my server data – database or files?
• If I went for database storage, what one?
• How could I get my server hosted?
• And on, and on…

All of these questions are valid and they will all need to be addressed at one point or another but thankfully I have been able to spot the trap that I was about to fall into…

Avoid the Analysis Paralysis Trap!

This is me all over; I get an idea for something I want to do, whether it’s a business I want to start, a game I want to write, a website I was to run etc. I get all these cool ideas and start writing them down and at first all is good. Then as my ideas unfold, I start reading up on the topics that I think I need to know about. The internet being what it is overloads me with information and very soon I have far more than I can handle.

I feel a need to get all the details right before implementation because of that old adage “failing to plan is planning to fail!”, which is something I believe in but the problem here is that you can get so bogged down in details (that you probably are not in a position to solve at the beginning) that you never get started. This is called ‘Analysis Paralysis’ and can be particularly rife amongst software projects.

Agile development methods such as Extreme Programming try to avoid this problem (and other development problems) by limiting the amount of documentation produced, focusing on incremental development of only small features at a time, on-going testing and so on. When I worked on Morde, I pretty much took this approach and I always asked myself, “what’s the smallest thing I could implement that I could build and test?” and I would do it. But I hit a big problem with Morde… Because it was so new to me, I simply didn’t anticipate around 60% of the development that I would end up having to do, and I only scratched the surface of my initial feature list. Because the code was built up day by day with no real foresight, it became a maintenance nightmare, almost impossible to extend.

So, what’s the solution? Well, I don’t know the answer to that as I’m not an expert! However I have some ideas that I am going to use for Mod Wars to enable me to get started without losing my sanity:

• Write a basic feature list of all the things I can think of that I want Mod Wars to have
• From that feature list, try to put together an idea for a basic framework that will support those features
• This is the important one – in any area where I have unanswered questions, find away to encapsulate that part of the code into its own area so that I can make decisions later and be able to change the code accordingly
• When I have a design for the whole framework, which uses abstraction to encapsulate all of my unanswered questions then I can use the “what’s the smallest thing…” approach to actually get started.
• When in development, I’ll always be asking myself, “what could cause this code to change?” and “would it be easy to change this code if I had to?”

Subversion Broke my Code!

Well, that’s not entirely true! The introduction of Subversion highlighted a problem with my code! In the last week I’ve been going through all of my existing source code and getting it into the Subversion repository. At the same time, I have migrated from Visual 2003 to Visual 2005 so I had to carefully ensure that everything still built properly. Nothing did; I had to change all of my projects.

The largest and most important project I have is called Morde and was my 3rd year project for University. It is a system for creating, hosting and playing online multiplayer RPG games. I was originally intending to continue work on that as my ‘pet project’ but decided against it for a few years. Still, there are a lot of similarities between Morde and Mod Wars so I certainly want to make sure that Morde is building and running properly.

I had to do quite a lot of work to get it working, mainly because the Gui library that I used for it no longer worked under VC8. The good news is that they had released a VC8 version, the bad news is that they had also updated the library (it’s a good thing really, just inconvenient for me at the time) and the changes broke all of my Gui code so I had to fix all that in the process.

However, I’ve still not mentioned how Subversion broke my code too! When a game session is running in Morde, the server application persists the state of the game world to disk on a regular basis. This data is reloaded to continue a session at a later date when the server is restarted. Subversion operates by putting a directory ‘.svn’ in every subdirectory under source control. In my code, I naively thought that because it was my code that created this particular directory structure, that I could make assumptions about what should be in it. I had a loop that loaded all files in the player directory and just to create players out them. The .svn file did not make a valid player and an exception was thrown! Bad, bad code!

Lessons Learned...

I learned two important things during this exercise:

1) Shield your code against changes to third party libraries

When you have to rely on third part code that you are not in control of (such as a third party library), try to minimise the impact on your code from potential changes to that library. This is the design principle “find what varies and encapsulate it” in action. In future projects I will highlight every third party library in use and in Mod Wars there will be several – graphics library, GUI library, XML library, Networking library and probably more. For each library, I will do my best to ensure that the code that calls into these libraries will be as encapsulated as possible, ideally in just one class.

That’s trickier to do on a Gui library that typically impacts a large part of the application but then the solution is to use another abstraction mechanism that at least treats the Gui as a separate layer of its own. In fact, I had such problems finding a suitable Gui for Morde that I have already tinkered with some designs for enabling the Gui to be completely switched out to an alternative one. Another reason for this is to allow me to create a fake Gui that isn’t even graphical but allows me to make a scripted Gui to help with testing, but that’s another story.

2) Don’t make assumptions about things beyond your control

The Subversion issue was purely the result of lazy coding and it was a very silly mistake. Who am I as a programmer, to make assumptions about files in the operating system? It’s not only possible that the directory structure will get changed but the possibility is really quite high! There are all sorts of programs that add files to a directory, and don’t forget the operating system itself! So when coding Mod Wars, I’ll always be thinking to myself, “What assumptions am I making here? Can I be sure that my assumptions are correct?”

What is Mod Wars?

Mod Wars is currently nothing more than a concept in my mind; a concept for a multiplayer online game set inside of a computer where the players take on the role of “modules” within the computer system and do battle against each other and against the corruption within the system.

It is really just a pet project for me to experiment with all the programming technologies and techniques that I am interested in. I work as a C++ developer and that is my preferred language but I would also like to play with C# & .NET, scripting languages, design patterns, refactoring, unit testing and anything else that springs to mind.

Where to Start?
I’ve got quite a few ideas about the basics of the game, the kind of architecture I am going to use and so on for example:

• Client / server architecture for main game
• C# 'Grid Editor utility for me to design the game world
• The game will have minimal graphics so will need creative gameplay
• I need a source control system before I do anything!
  
  I’m going to address the last point first and I’ve chosen Subversion as the source control system that I want to use. I use it at work and it’s pretty standard, not to mention free! :-)