Development on Mod Wars is now
On Hold!
I didn't want to have to do that but I simply found myself in a situation where I had so much going on in my life that I was spreading myself too thinly. I was logging the hours spent and I was literally only working on this for a couple of hours a week. That simply isn't enough for a project of this size.
Instead I've decided to focus my development efforts on just one thing, which is a web development project for the moment and I'll pick up Mod Wars only when I can spend at least an hour a day on it.
I've now put up a new blog about my development in general and I've split up another blog I had into several more specialised ones. Here they are:
Until next time... happy coding :)
Saturday, May 26, 2007
Sunday, March 18, 2007
Platform Specific Graphics Issues
Today I did a little more work on the grid. I thought the lines looked too thick before so I changed them to single pixel thickness lines and implemented them using the line drawing functions of the SDL_gfx library. Previously they had been drawn as filled rectangles.
I also realised today that I had a problem with colours. The red and blue components of my RGB colours were being reversed. So where I was trying to draw grid lines in a darkish blue colour, they were coming out as orange. I did some investigation to no avail so I logged it as a bug and put together a quick workaround.
At the end of my dev day, I checked in my changes, did an update on my linux box and checked the build. Its a good job I did as I found two problems. Firstly I'd hard coded backward slashes in a pathname - must always use forward slashes to be platform-independent. That was an easy fix. The second issue was that the display was completely screwed up. I show the two screenshots below.
I also realised today that I had a problem with colours. The red and blue components of my RGB colours were being reversed. So where I was trying to draw grid lines in a darkish blue colour, they were coming out as orange. I did some investigation to no avail so I logged it as a bug and put together a quick workaround.
At the end of my dev day, I checked in my changes, did an update on my linux box and checked the build. Its a good job I did as I found two problems. Firstly I'd hard coded backward slashes in a pathname - must always use forward slashes to be platform-independent. That was an easy fix. The second issue was that the display was completely screwed up. I show the two screenshots below.
Linux:
Windows:
Note that on Linix, you can just about make out that the colours are reversed. Hmmm, I got some weirdness going on, I'm not looking forward to fixing this bug! Oh well, no time to fix it now, I've logged a showstopper bug for another day.
To Be Or Not To Be? (Agile)
Over the last couple of weeks I've been doing some work setting up the tools I want to use and this weekend I had the chance to get back to coding. So far all I have is a very simple grid being displayed on the screen; there is no interaction with the player so the next step is to pick a starting position for the player and let him move around the grid using the keyboard.
Now this presents me with a slight problem. At the moment I am only working with a client application; there is no server so any navigation logic will have to be implemented solely on the client. However, one of the problems prevalent in any online game, especially a persistent one, is that of cheating. A common form of cheating is to hack client side data.
For example, lets say the grid contained obstacles that prevented player movement. Indeed later versions of the game will allow individual grid lines to be live or dead and players may only navigate live grid lines. If the client software contained data about the grid (which it must, otherwise how can it render it?) and a player was to hack that data, he may hack it in such a way as to make all the grid lines live. With all navigation logic on the client, this would allow the rogue player to access parts of the grid which he should not be allowed to reach. This of course could wreak havoc on the game.
A general rule to follow when developing an online game is to make the client code as dumb as possible and implement all logic on the server. Thus, one way in which I could do this in terms of navigation is to allow the client to handle keyboard input but once the player reaches a grid cell intersection, send a message over to the server asking if the player may move along that grid line. The server examines its own copy of the data (which of course must be secure) and sends back a response to the client.
Now the client does not necessarily have to wait for a response from the server before allowing the player to move. This would most likely cause a noticeable delay and sluggish experience for the player. A common technique is to have the logic duplicated on the client so the client assumes its data is valid, but once the response is received from the server, any necessary corrections are made. This is known as client-side prediction.
Now all of this sounds like quite a lot of work, and right now all I want to do is let a player move around my grid with the keyboard. I don't really want to implement the server right now. So here's my dilemma. Do I go ahead and just start coding on the client alone, knowing that the navigation functionality is going to change radically when the server is implemented (the agile choice), or do I just take the time now to write the server and do all of the work necessary to implement navigation properly (the traditional route)?
I've decided to go with the agile route knowing that I'll need to re-work lots, if not all of the code. I'm glad I made this choice as I ran into various niggly issues throughout the day so I still haven't finished yet! If I had started on the server code that would have caused even more delays.
As I only get to work on this project for the odd couple of hours here and there I think its important to try and keep the functionality moving forward so that I don't start to feel like I've been working for weeks and making no progress.
Now this presents me with a slight problem. At the moment I am only working with a client application; there is no server so any navigation logic will have to be implemented solely on the client. However, one of the problems prevalent in any online game, especially a persistent one, is that of cheating. A common form of cheating is to hack client side data.
For example, lets say the grid contained obstacles that prevented player movement. Indeed later versions of the game will allow individual grid lines to be live or dead and players may only navigate live grid lines. If the client software contained data about the grid (which it must, otherwise how can it render it?) and a player was to hack that data, he may hack it in such a way as to make all the grid lines live. With all navigation logic on the client, this would allow the rogue player to access parts of the grid which he should not be allowed to reach. This of course could wreak havoc on the game.
A general rule to follow when developing an online game is to make the client code as dumb as possible and implement all logic on the server. Thus, one way in which I could do this in terms of navigation is to allow the client to handle keyboard input but once the player reaches a grid cell intersection, send a message over to the server asking if the player may move along that grid line. The server examines its own copy of the data (which of course must be secure) and sends back a response to the client.
Now the client does not necessarily have to wait for a response from the server before allowing the player to move. This would most likely cause a noticeable delay and sluggish experience for the player. A common technique is to have the logic duplicated on the client so the client assumes its data is valid, but once the response is received from the server, any necessary corrections are made. This is known as client-side prediction.
Now all of this sounds like quite a lot of work, and right now all I want to do is let a player move around my grid with the keyboard. I don't really want to implement the server right now. So here's my dilemma. Do I go ahead and just start coding on the client alone, knowing that the navigation functionality is going to change radically when the server is implemented (the agile choice), or do I just take the time now to write the server and do all of the work necessary to implement navigation properly (the traditional route)?
I've decided to go with the agile route knowing that I'll need to re-work lots, if not all of the code. I'm glad I made this choice as I ran into various niggly issues throughout the day so I still haven't finished yet! If I had started on the server code that would have caused even more delays.
As I only get to work on this project for the odd couple of hours here and there I think its important to try and keep the functionality moving forward so that I don't start to feel like I've been working for weeks and making no progress.
Wednesday, March 14, 2007
Bug / Feature Tracking System
A couple of posts back I said that I wanted to setup various tools that could help me work like a professional dev shop. Incidentally I have since learned of the term "MicroISV" which is an Independent Software Vendor comprising less than 5 people, usually only one. Isn't that cool that there's a name for it now? There's even a book! (On my wishlist, oh yeah!)
Where was I? Tools! Yes, next on the list was a bug tracking system which I wanted to use not so much to track bugs but to track features. I want to keep my development agile which means that as I'm working I often find something I'd like to do, such as write a nice smart pointer to wrap an SDL_Surface pointer which will free it automatically. But nice as this sort of thing is, it is not essential to my goals right now and will only slow me down. But I don't want to lose the idea. So instead, I'd raise an issue in a tracking system and store it for later. When I'm doing new work I'll do a mixture of new features, infrastructure type work, refactoring and so on.
I thought finding such a system would be easy. It had to be free and I wanted it simple because I am the only person using it. I did a quick search and came up with a shortlist:
The first one I tried was Issue Tracker. I got this working reasonably easily but I had to use it within something called Zope which was a bit bizarre and it just didn't seem very configurable. When I entered some issues I couldnt see a number, only a list of the titles and I'd like to be able to easily see a reference number for hooking up to subversion for instance.
Next... Mantis. This thing is written in Php. They're not kidding. When I "installed" it I simply had a bunch of php files on my hard drive. The documentation left me clueless. I figured I could have persisted but the screenshots didn't inspire me with awe so I moved on.
BugTracker.NET. Ugh more dodgy pre-requisistes - I needed IIS installed and configured to ASP.NET 2.0. I just didn't want to go there so I searched again and found a nice list on Dmoz. After looking at about a dozen of obviusly highly commercial systems I noticed that my dmoz list I was looking at had a filter for free systems so I tried that :-)
I eventually found Roundup and installation was reasonably straight forward. The documentation was comprehensive and above all, correct. I managed to configure the database with my own preferences for Priority, Status etc and it works nicely and I also know that if I need to do more with it, it's highly configurable and I just have to invest more time with the documentation.
Here's a pic:
Where was I? Tools! Yes, next on the list was a bug tracking system which I wanted to use not so much to track bugs but to track features. I want to keep my development agile which means that as I'm working I often find something I'd like to do, such as write a nice smart pointer to wrap an SDL_Surface pointer which will free it automatically. But nice as this sort of thing is, it is not essential to my goals right now and will only slow me down. But I don't want to lose the idea. So instead, I'd raise an issue in a tracking system and store it for later. When I'm doing new work I'll do a mixture of new features, infrastructure type work, refactoring and so on.
I thought finding such a system would be easy. It had to be free and I wanted it simple because I am the only person using it. I did a quick search and came up with a shortlist:
- Bugzilla - industry standard giant: http://www.bugzilla.org/
- Issue Tracker - looked pretty: http://www.issuetrackerproduct.com/
- Mantis - looked simple: http://www.mantisbt.org/
- BugTracker.NET: http://www.ifdefined.com/bugtrackernet.html
The first one I tried was Issue Tracker. I got this working reasonably easily but I had to use it within something called Zope which was a bit bizarre and it just didn't seem very configurable. When I entered some issues I couldnt see a number, only a list of the titles and I'd like to be able to easily see a reference number for hooking up to subversion for instance.
Next... Mantis. This thing is written in Php. They're not kidding. When I "installed" it I simply had a bunch of php files on my hard drive. The documentation left me clueless. I figured I could have persisted but the screenshots didn't inspire me with awe so I moved on.
BugTracker.NET. Ugh more dodgy pre-requisistes - I needed IIS installed and configured to ASP.NET 2.0. I just didn't want to go there so I searched again and found a nice list on Dmoz. After looking at about a dozen of obviusly highly commercial systems I noticed that my dmoz list I was looking at had a filter for free systems so I tried that :-)
I eventually found Roundup and installation was reasonably straight forward. The documentation was comprehensive and above all, correct. I managed to configure the database with my own preferences for Priority, Status etc and it works nicely and I also know that if I need to do more with it, it's highly configurable and I just have to invest more time with the documentation.
Here's a pic:
Sunday, March 11, 2007
Client Architecture
Some time ago I was thinking about the client and how I was going to design with Gui flexibility in mind. I put together a little design diagram which used the bridge pattern to help me vary Gui libraries alongside variations in screens being rendered.
However, once I started looking at the code for wxWidgets I realised that this design would not be sufficient because Gui libraries such as wxWidgets are not just libraries of widgets that you plug into your existing applications - they are complete application frameworks within which you develop your code. What this means is that changing from say wxWidgets to Guichan (the one I used whilst developing Morde) is not just a matter of swapping out a few classes. It's involves reworking the architecture of the client code completely.
In addition to the possibility of supporting multiple Gui libraries in case I should want to switch at some time, I also want a front end that does not have any graphics and just outputs to a console. I could use this for unit-testing. For example, rather than manually testing my Gui by loading it up, moving a module around and checking it works, I can develop unit tests which will call functions that simulate the user having pressed navigation buttons to the same effect. Thus, I can automate the testing of pushing a module to the boundaries for example.
If I wanted to get really clever, I could put this kind of behaviour into a script, give it some basic intelligence and I have myself a 'bot' that can play the game according to its scripted rules. Now why would I want bots? Well, for starters I could create bots that perform a complex set of steps for more thorough testing. Secondly, but adding some randomness I may expose bugs that I hadn't uncovered via my hand-crafted bots. Lastly, it could form the basis for scripted NPC modules which will act as enemies in the game.
So, I need at least two completely different front ends. In the case of graphical one, no matter what Gui library I use, I want to use SDL for my underlying drawing code so any SDL code can sit in its own library and thus I can make my real client very thin in architecture. Here is a new diagram that I knocked up:
I've just made up names for classes here, none of them are in place yet. The common library is common to both server and client code.
However, once I started looking at the code for wxWidgets I realised that this design would not be sufficient because Gui libraries such as wxWidgets are not just libraries of widgets that you plug into your existing applications - they are complete application frameworks within which you develop your code. What this means is that changing from say wxWidgets to Guichan (the one I used whilst developing Morde) is not just a matter of swapping out a few classes. It's involves reworking the architecture of the client code completely.
In addition to the possibility of supporting multiple Gui libraries in case I should want to switch at some time, I also want a front end that does not have any graphics and just outputs to a console. I could use this for unit-testing. For example, rather than manually testing my Gui by loading it up, moving a module around and checking it works, I can develop unit tests which will call functions that simulate the user having pressed navigation buttons to the same effect. Thus, I can automate the testing of pushing a module to the boundaries for example.
If I wanted to get really clever, I could put this kind of behaviour into a script, give it some basic intelligence and I have myself a 'bot' that can play the game according to its scripted rules. Now why would I want bots? Well, for starters I could create bots that perform a complex set of steps for more thorough testing. Secondly, but adding some randomness I may expose bugs that I hadn't uncovered via my hand-crafted bots. Lastly, it could form the basis for scripted NPC modules which will act as enemies in the game.
So, I need at least two completely different front ends. In the case of graphical one, no matter what Gui library I use, I want to use SDL for my underlying drawing code so any SDL code can sit in its own library and thus I can make my real client very thin in architecture. Here is a new diagram that I knocked up:
I've just made up names for classes here, none of them are in place yet. The common library is common to both server and client code.
Saturday, March 10, 2007
Installer for Mod Wars
One of the things I want to do with this project is setup all sorts of tools that you'd expect to find in a commercial development shop such as version control, bug / feature tracking, automated builds, continuous integration, unit tests, and installers.
Setting up all of these systems will be a ttime consuming process because:
I looked at several tools:
1) Inno Setup: http://www.jrsoftware.org/isinfo.php
2) Nullsoft Scriptable Installer: http://nsis.sourceforge.net/Main_Page
3) MSBuild: http://msdn2.microsoft.com/en-us/library/wea2sca5.aspx
4) WiX: http://wix.sourceforge.net/
5) Spoon Installer: http://sourceforge.net/projects/spoon-installer
Actually, after a cursory look at their respective websites the only tools I looked at in any detail were Inno and Nullsoft (NSIS). I looked at Inno first and quickly got a bit stuck due to lack of documentation. NSIS on the other hand came with a full manual and I found a whole bunch of tutorials on the web so I had a bash at that one.
An hour later I have a fully working installer with corresponding uninstaller. Cool eh :-) Here's the code:
Setting up all of these systems will be a ttime consuming process because:
- There are lots of tools available, so evaluation time is needed
- Whichever tools I pick, there will be a learning curve
- Will this tool / system affect the player?
- Will this tool / system become more difficult to implement as time passes?
- Installer for the client
- Bug / Feature tracking system
- Automated build tools
- Continuous integration system
- Unit testing
- Code coverage tools
- Logging
- Code verification tools
I looked at several tools:
1) Inno Setup: http://www.jrsoftware.org/isinfo.php
2) Nullsoft Scriptable Installer: http://nsis.sourceforge.net/Main_Page
3) MSBuild: http://msdn2.microsoft.com/en-us/library/wea2sca5.aspx
4) WiX: http://wix.sourceforge.net/
5) Spoon Installer: http://sourceforge.net/projects/spoon-installer
Actually, after a cursory look at their respective websites the only tools I looked at in any detail were Inno and Nullsoft (NSIS). I looked at Inno first and quickly got a bit stuck due to lack of documentation. NSIS on the other hand came with a full manual and I found a whole bunch of tutorials on the web so I had a bash at that one.
An hour later I have a fully working installer with corresponding uninstaller. Cool eh :-) Here's the code:
; name the installer
Name "Mod Wars Setup"
;the install program
OutFile "mw_setup.exe"
;installation directory
InstallDir "$PROGRAMFILES\Mod Wars\"
; define a variable for the bin directory
;==============================================================================
; Install section
;==============================================================================
Section
; set install directory
SetOutPath $INSTDIR
;Files to install
File "/oname=modwars.exe" "..\..\bin\mw_client_wx.exe"
File "..\..\bin\SDL.dll"
File "..\..\bin\SDL_gfx.dll"
; create uninstaller file
WriteUninstaller "$INSTDIR\unins_mw.exe"
; create shortcuts
CreateDirectory "$SMPROGRAMS\Mod Wars\"
CreateShortCut "$SMPROGRAMS\Mod Wars\Mod Wars.lnk" "$INSTDIR\modwars.exe"
CreateShortCut "$SMPROGRAMS\Mod Wars\Uninstall Mod Wars.lnk" "$INSTDIR\unins_mw.exe"
; default section end
SectionEnd
;==============================================================================
;Uninstall section
;==============================================================================
Section "Uninstall"
; always delete uninstaller first
Delete "$INSTDIR\unins_mw.exe"
; delete all installed files
Delete "$INSTDIR\modwars.exe"
Delete "$INSTDIR\SDL.dll"
Delete "$INSTDIR\SDL_gfx.dll"
;delete shortcuts
Delete "$SMPROGRAMS\Mod Wars\Mod Wars.lnk"
Delete "$SMPROGRAMS\Mod Wars\Uninstall Mod Wars.lnk"
RMDir "$SMPROGRAMS\Mod Wars\"
; finally, remove install directory
RMDir "$INSTDIR"
SectionEnd
Saturday, March 03, 2007
Slow Progress?
I look back at this blog and I'm quite discouraged at just how little I have done considering how long I have been working on the project. But over the last couple of months I have been using a great little utility called Slim Timer to track all I time I spent on it. I ran some reports today and I was horrified to find that in both January and February I had only spent 13 hours working on Mod Wars each month! That's shocking! Ideally, I'd like to be working towards that kind of number on a weekly basis though thats probably overly ambitious right now. But still, I'm now making a concerted effort to do more!
Subscribe to:
Posts (Atom)
