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.