Sumo Squash Development

I thought I'd take the opportunity to talk a little about the development of Sumo Squash for DBP for anyone who may be interested.

Even though the game output hadn't got anywhere practical after Herriman: Under Pressure, I started developing a 2D framework sometime after, with one of my friends and colleagues. This involved a data-driven architecture, that was designed to provide a standardised interface for Sprite Management, Animation, setting values, Resource Management, Input Management, Level Management. After we created a stable version, I also started on a very early version of a compatible Level Editor.

Anyway ... back to Sumo Squash. So we started on getting a basic character up and running. As I remember I started off with some basic programmer art of some blocks for the level and a block for the character, with this I got the basic collision response of a platformer. Gaz later animated an early version of the Sumo and this spurred me on to better refine the control and collision response. These were suprisingly difficult to get right, this was the first platformer I had done - they were later refined even more as the feel came along for the game. At this early stage, Gaz and me debated the layout of the levels and started with the idea of a retro feel for the game and some corresponding levels. We liked the idea of block based levels, where the 'state' of the blocks could change. Gaz liked the idea of having 'procedural' levels that were created randomly within some parameters; where the position, state (such as Ice, friction) would change, and we also thought about some blocks that could have different stages of breakability. After some thought, we realised that there must be some rules to constrain the random blocks, but I couldn't foresee a simple way to do this. After some more work to polish this build/prototype of the game, as well as after the development of an early level editor (that could basically just place objects) we showed this to our good friend an trusted artiste, David Faulkner. He was luckily, up for collaborating on the project!

It was around this time, we were reading about the development and playing Braid, and as you may see this influenced the level design for the game, it also inspired us in the way to do the collision (ie. for slopes) and how to integrate it into the editor. Dave started coming up with amazing design for level objects and backgrounds. Seeing Braid (gamasutra article by David Hellman, artist for Braid) and Dave's designs made us, thankfully re-think the block idea.

It was shortly before this that the Dream Build Play competition reared its head and made us notice. We have to confess, we first entered to get the free creators club memership (we'd always planned to develop something with the Xbox 360 in mind), but we thought what the hell, lets step development up a gear and try get something playale for the competition. Although we were about 2-3 months away from the deadline, we thought we could get something up and running that was at least half fun.


For the next few months, we put our all into the project. I kept improving the editor so it was more useful, collision could be added and modified and the way it was displayed was more helpful. I added a delete and clone option and removed some annoying bugs (development of the tool was far from ideal and it was never more than the bare essentials to help the game). Me and Gaz worked after work hours when we had the energy and all weekend when we could. Dave built many levels on Snow and a more seasonal theme. Gaz designed and went through a few iterations of the UI, including the menus and the in-game display.

As all the team are distributed around the country we took advantage of Subversion (Tortoise SVN), google docs and lots of e-mail. I only had the idea or inclination to set-up SVN access midway into the project as we needed to synchronize and exchange our work more and more. I took the decision to make access read-only to simplify matters; this was the way Dave and Gaz updated their local build. Access to SVN was made available through VPN and Hamachi. It soon becomes apparent that when working over the internet that the transfer speed makes things difficult.

With Google Docs, I set-up a very rough Game Document with:
- Basic design overview/explanation
- A brief explanation of the aesthetics, control and general gameplay
- Ideas for characters, moves, pickups, game modes
- Basic, and Desired features
- A few pie in the sky ideas
I also set-up a Task list document, for both the game and the level editor. This became a visible area for anyone to see what I was up to and what I had done. I used this area to keep any notes about task and continually updated it.

When the competition was nearing the submission date, we had a few play-test sessions. They were all absolutely essential, the first one was useful in revealing many bugs. The game was played, and options chosen that were different to what I had tested by myself. A number of visual and gameplay points were discussed, by the end we all had very long list of changes. The next few play tests allowed us to improve the level design, the controls and more visual points. By the last play-test we were a few days away from submission, although we felt some features could be added, we were fairly confident with what we had made following the requirements we set out for it. Any new features by this point could have potentially introduced bugs or been a detriment to the game mechanics.