Hi everybody. Someone asked to see more post mortem stuff. So here goes.
It’s probably about time I acknowledged that Pond Wars is done and complete. Time to do people the honour of discussing what I learned. I’m going to focus on the design stuff but if anyone wants a full blown technical explanation let me know.
Oh, and if on the off chance you haven’t checked out the game yet you can play it on the webplayer on my website. Or you can download it from itch.io.
Inspirations
Pond Wars was my first original completed game. Prior to that I’d built flappy bird cones, space invaders clones, and made a variety of starts on my big dream project. (That’s a story for another post. My dream project makes the average forum noob with an MMO look like childs play.)
I spent a lot of time on answers. This question in particular struck a chord with me. At our local game dev meetup the next day I brought the question up, and we spent most of the night discussing how to build a system of water physics (and very little time on actually developing any games). That night I went home and built the first prototype, which was basically a cube floating on waves. At this point it was more of a technical exercise then a playable game.
Enter Starbase Battles. Starbase battles was a game one of the other devs at our meet up night was developing. A key feature of the game is passive play. Players can control the rotation of the base, but the base has no direct movement capacity. Movement is achieved by recoil from firing missiles. The key to success in the game is all about precise timing. Check out a video of the game below (download link in the description). It will take about five minutes to play and get a feel for what I’m talking about.
The final source of inspiration was a discussion with my wife. She saw my box floating on water and said the obvious things like “Why a box, make it into a boat”, “Why not make it two player” and “Who cares if the physics is wrong, you are making a game, it’s meant to be fun”. She was also responsible for the artwork you see in game.
Key design choices
The game was to be two player single screen. This decision falls back to my days playing mortal combat and wacky wheels as a kid. The game play should feel like an old street fighter game. Short fun rounds, and half of the fun coming from the social experience of being crowded around the keyboard
Shots cannot be aimed. This is one of the key points of difference in the game. The game doesn’t go to the player with the fastest reactions or the one who can remember the moves. The game is meant to reward patience and timing. Often not firing and waiting for a clearer shot is the best decision.
Shots are slow. The point is not to be able to machine gun fire willy-nilly and hope you hit the target. Shots are precious. So along with rewarding the player that waits, the timed shot mechanism penalises the player that spams the fire key.
Game Design Document
I’m not a huge fan of big GDDs. This is pretty much what I used in its place.
Key design surprises
Accurate physics is not fun. This was an eye opener to me. The first prototype had the crazy wave physics you see now. I built some basic player controllers and played it with my wife. The game was fun. So I went back and tuned the wave physics to be more real. We played the game again. This was not as fun as the first time around. This was a huge eye opener for me. More realism != more fun.
Several iterations later I invited my five year old daughter to play with me. She is much less aggressive than my wife, and spent more time avoiding me then trying to kill me. After about fifteen minutes I realised that the game was no longer fun. Hence the timer mechanism that you see now (heads up, latest play testing indicates the timer is still too long, in a future iteration rounds will probably be shorter). Key takeaway, ensure different play styles don’t break your game
Turns out that the artwork you use does make a difference. The current shape of the rocks on the edges of the map allow for players to get stuck (This is another one that will be fixed in a future iteration of the game). This was another revelation for me. Art and physics place constraints on each other, and sometimes in weird ways.
Technical challenges
I know I said this was mostly about design, but I’m going to hit a few key technical challenges as well. Surprisingly the basic wave and buoyancy physics were fairly straight forward. They are built directly on top of Unity’s built in physics.
It turns out that my wave model is subject to first order harmonics under some play conditions. As my four year old play tester expressed succinctly “Daddy, where has all the water gone?” In extreme conditions the water level can drop below the bottom of the lake. The solution was pretty simple, put in some intermediate nodes with more constraints. But discovering the conditions to produce the bug was trickier. It’s worth deliberately trying to break a game with corner cases before letting it out into the wild.
There was one persistent bug that didn’t get caught before release. In some circumstances a cannon ball could get stuck between colliders on a boat, basically making the boat unmanoeuvrable. The solution was simple, separate the buoyancy colliders and the collision colliders onto different layers. But it took explaining the problem to another dev in detail to come up with the idea. It’s important to share bugs as well as successes.
Perhaps the dumbest technical decision of the project was using a try catch block to deal with objects that went out of the playing area. The code ran something like this.
try {
// buoyancy code
} catch {
Destroy(gameObject);
}
Needless to say catching everything and destroying the object that threw the error was something I came to regret much later. I made some changes to the buoyancy model. The code stopped working, but without throwing an error. I had to manually trace the stack line by line to figure out what was going on. Yeah, enough said, just don’t do this.
The last technical challenge was boat’s capsizing. Once you were flipped over it became very difficult to flip back up again. While that was accurate, it wasn’t exactly fun. The solution to this was to offset the centre of mass. If you look closely the centre of mass for the boats is actually about a centimetre below the bottom of the boat. The centre of buoyancy is on the boat, where you would expect it to be. This means the boats have a preference to be upright. It’s a small change, but it’s enough to make the game feel fair.
Monetisation
Initially I focused on launching on monetised platforms, and on figuring out ways to incorporate ads in game. I burnt a lot of hours and energy on implementing various ad networks.
Several months later the game had brought in a grand total of 0.22 cents. I realised that selling the game for money wasn’t working. And worrying about how much money it was making was actually harming its distribution and uptake. There was that little article called don’t monetise your games that made me realise I was doing it all backwards. I need to get famous first, and then charge people to come see me play**.**
I hope you enjoyed this. Please discuss thoughts on the design and my choices below. And as usual I’m happy to write more about myself if people ask.
