Sunday, September 17, 2006

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.

Thursday, September 14, 2006

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?”

Sunday, September 10, 2006

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?”

Sunday, September 03, 2006

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! :-)