This is the log of a sample project from a small band of software engineers eager to learn better ways of working and new technologies. We've decided to use .NET 3.0 to create a Battleships game.

The Quest For The Perfect Project

Friday, 23 February 2007

Evolutionary Design - keep it simple

Multiplayer Battleships is giving us an avenue to play around with some Agile techniques that have interested us. One of those is surrounding how we design the modules we're implementing. The idea is to only do as much design as necessary to get a task completed. You shouldn't design for the future, we do need to be aware of the direction that we're heading in, but we shouldn't start churning out all this code to cover the "what if" scenario.

I'm starting to see the benefits of this way of thinking already. At the beginning of a project, you can't really expect to fully understand all the implications that lie ahead so having a mammoth design task to plan the whole system is often flawed. I'm using the technique to have evolutionary design and already I've started to see why this is better than spending weeks planning and designing early on. I'm new to writing games, especially games that have the added complexity of being multiplayer. The last game I wrote was some little console C++ horse racing game 10 years ago when I was learning to program (whoa, I feel old!).

I'm starting to realise that you need to think in a different mindset when trying to develop a multiplayer game and I'm very fortunate that my other half loves developing games, so I've got someone to bounce my ideas off of. Last night we had a chat because I keep finding that I'm having to refactor continually because something I initially thought was a great implementation, suddenly started to fall over when I considered how it would work in a multiplayer environment. I've identified that my design has been subtly flawed for a while, so it's great that I had designed the whole game from day 1 because at the end of the day, I've got several learning curves going on here. I'm starting to think my lack of knowledge around multiplayer games is the biggest.

For example:

I came up with this basic idea about a ship having health and whenever it received an attack, the health would decrease. I was happily testing the process attack code when I started to dream up more complex tests that verified several players attacking the same ship. I needed a way to model this in code and as it currently stood, my design was flawed. It wasn't a terrible design, but it was just wrong for the multiplayer aspect.

A similar issue arose when I started thinking about the board representation. I couldn't stop players from placing ships on certain coordinates because it would alert them to the probability of there being another ship there. As a result, ships can occupy the same coordinates in Multiplayer Battleships. I'd initially not really thought about this and found myself once again revisiting the design board to make this possible in a multiplayer environment.

The list goes on, but I'm finally turning the corner and realising that I need to approach my evolving design from a multiplayer perspective early on, otherwise I'll spend a lot more of my limited time rewriting and rewriting.

A great article that has helped me along the way is: "Is Design Dead by Martin Fowler"

Labels: ,


In your last paragraph you say that you can't stop players from placing ships in the same spots. That might need re-thinking. The way I would imagine a multiplayer version of battleships is that you have one large sea (your board) and a whole bunch of ship owners with ships in the sea and they're all trying to blow each other out of the water. But the key concept being that there is still only one board, and only one ship can occupy one position on that board.

If you want to allow multiple players to have a ship that overlaps the same position, you'll need to consider carefully if that is actually the behaviour you want.
I think battleships in one "physical" space just doesn't work as a game - there are too many oddities around. Certainly for two-player battleships, the players' areas are completely independent. This makes logical sense apart from anything else - if I were right next to your battleship, I wouldn't have to guess where you were, I'd be able to see you!

Personally I favour extending that approach to more players. It could work in a variety of ways, and there could even be extra features. For instance, normally you'd pick the player to attack and the co-ordinates, but you might have three "clone bombs" where you just say which co-ordinates you want to hit and it drops bombs on all players' boards at those co-ordinates.

Obviously, it's worth keeping simple to start with though :)
How about submarines? ;-)

Do you allow 3D play?
3D stuff, submarines etc are all possible - but at that stage I'd suggest it's not really the same game any more.

Also, a simple 3D equivalent of normal battleships would be very boring, unless you made each dimension smaller than normal. For instance, if there are 20 "occupied" spaces on a 10x10 board, you've got a 20% chance of hitting something. If you make the board 10x10x10, you've got a 2% chance unless you start adding more ships - and finding that last destroyer would be incredibly tedious.

I think we'll try to keep it traditional to start with.
3D play is an interesting concept, but probably something that we're not quite ready for in this first release. Tackling the multiplayer aspect of Battleships is keeping us busy.

I would like to be a little creative though. I'm not a graphics genius but I'd like to make it pretty. Something simple could be a flat "top down" view of your board and then you'd have another "top down" view of the board that you are attacking. I'd like to make it 2D at least. If anyone has ever played "The Sims 2", then you may get a feel for my vision of how I'd like it to look. I'd like the play area to have little ships sticking up and I'd like the user to be able to maybe drag the play area around and view the board from different angles. Whether we could do that and how is a whole other issue :).
With WPF, it might well be fairly easy to do a 3D view of a 2D board, such that we can rotate it etc.

Probably best to do a "simple" version first (like Minesweeper) but then move onto either a "proper" 3D or an isometric view.

I'm still planning to do a console view first - no mucking around with threads etc. I'll get round to actually doing some work on it soon, with any luck...

Add a comment