Tuesday 4 November 2008

Future

Me and Gaz had the opportunity to do a Show n' Tell with the XNA UK User Group alongside Beatnik Games and their project, Plain Sight. It was really great to meet the Beatnik guys, play their project and see a few more peeps play Sumo Squash. I had fun playing Plain Sight, I thought it had some great ideas and shows a lot of promise. Having since seing Plain Sight at the Eurogamer Expo, Alex at Beatnik Games told me that they had be beavering away for the Expo based on some of the feedback they recieved at the Show n' Tell, and I like where its headed!

The Show n' Tell also gave us a chance to get some feedback for our game, as small and simple it is compared to Plain Sight. When we show our game, people always seem to have a good time playing it, and this time it was no exception. After some drinks and chat with the people at the Show n' Tell, we decided that we should spend some time polishing and adding features that we had liked to put in, with the added possibility of submitting it to Community Games in a couple of months.

Whilst doing this, we are also thinking of other game ideas for future projects, using Sumo Squash as a stepping stone to them. For the next projects we plan to start making prototypes/ white box testing for game mechanics, so we know they work before developing a full game, and to refine mechanics that we can draw upon later.

Next up on the grand agenda are plans to improve the tools that we are using at the moment. First off, as mentioned in other posts, the LevelEditor only contains the barebones, I plan to spend some time refactoring and adding features. The idea is to make everyone's life easier and take some of the work from me, as it is all to easy for me to become a bottleneck. -So there plans to create tools, or make the Level editor support the visual creation of animations and menu UI's.

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.

Present: Announcing Sumo Squash


This is the new project I referred to in my previous post. After the previous project was put on hold, we spent some time and decided on doing something simple that we knew would definitely be fun and would be defnitely achievable. We had a random idea to do a game based around a great freeware game called Jump n' Bump.



We felt the core mechanic behind was very solid, but somewhat simple and under-utilised. As we hadn't created anything of much worth by then, we decided to go with something simple, achievable that would help us on the road to something more innovative, complex and altogether richer; once we had proved ourselves with a bigger project than Herriman: Under Pressure. The general idea was to make it wacky, so Gaz and his near infinite creativity came up with the plan to use sumos as the battling characters.

Once we had got a working prototype up and running, David who worked with us on the Herriman project agreed to join forces once again. Development was roughly about 3 months. Here's are link to a video.

Game object component system

In this system, the idea is to replace the traditional hierarchical game object system based on inheritance. The need for this system was inspired by the disadvantages of the traditional system, the biggest one being class explosion. Normally, you would start with a base Object or GameObject class, in a 2D game, you might call it Sprite. This would contain the basic functionality of a game object in the scene. Each time you want to have different or more specific behaviour, for example, you may want to Draw or Update an object differently, such as with a pickup, a collidable piece or the scenery etc., in this case you will override these equivalent methods with your own or added behaviour. In a complex game with many different types of objects you may have to start creating and subclassing from a myriad of classes. An example of this would be, where you might create a Character class than will move and collide a particular way in the world, you then might have a Player class for characters that users control, that inherits from Character, then you might also have a Enemy class that inherits from Player or Character. Then, when you want a new form of enemy, some people might create a new class for each. If you had an enemy that, say, tracks the player in the world and another than moves randomly, all though its not a good example, you might create a class for each, then you might later want one that has behaviours and inherits from each (a better way would be to use the Strategy pattern, and use composition rather than inheritance to determine the new behaviour; you just swap a MovementStrategy object that an enemy calls). This could apply to many game objects, and if you do this, your class hierarchy may become large and unmanagable. A big problem you might meet is the Diamond of Death, where you trap yourself into a corner. -In this case you might start duplicating code or hacking around, just so you can get your new game object type in the world. This is never a good situation to get in.

One solution to this is the aforementioned GOC system. The idea with this to use composition, rather than inheritance to form your game objects. In this design, you start with a base object that contains a list of components that will get called either when the base object is Updated or Drawn each frame. Here's a description of how the Tony Hawk team used it.

The way I tried to use this system was by having a hierarchy of components for movement, control, drawing. Also at this point, I was thinking about integrating a physics system in an engine, so there was a component type that governed how the phyics reacted with the composed object. I've always designed my games systems to be completely data driven, so the public properties of an object can be set from a data file, this allows integration with an editor, which was one of the things I was implemeting at the time (Winforms app with XNA window). The obvious use for this is to speed up creation of a game, enable re-usability and allow artists to design levels and games (if you start adding events) without digging into code.

While I still like the idea of this system, it is, in concept, the ultimate in flexibility, and its this generality that software designers aim for, to make the possibilties of an application all the more wider, data-driven, and re-usable. There were though, a number of problems I ran into with trying to implement the system. It was too flexible. I think all software systems are a comprimise between flexibility and specific function. Flexibilty allows the function of a system to be changeable, whereas specific functionality can be more targeted. Specific systems are easier to write, as you don't need to think about the general case, just the task that needs to be currently satisfied, this allows for more performant systems.

The problem I found, was that I had to start knowing specific things about my components, especially when physics were concerned. I was implementing it in C# at the time and came up with a system that used reflection create and initialise the properties of each component. For the games that I was intending to write at the time, and the same now, this system, (even though I got quite far on the implementation) would have been far too complicated for its own good. Coming up with a reliable interface so that components could reference and call each other, while keeping them independant would have taken me a long time to achieve, and I'm not sure if it is even possible with intertwined needs that are bought about by the use of things like physics. Maybe I will return to this system, sometime in the future, but I don't think my previous use of it beats the design of the current, traditional game object hierarchy.

Past, Present, Future

Past

After some free time on a train, I've decided to write a set of updates on the progress of the (yet un-named) team that I belong to, what I've done in the past, what we've done recently and what we've got planned for the future.

After Herriman, way back last year I started writing an admittedly overly complex engine and editor based around a component system, or GOCs (game object components). I'll post a bit more about this system and my experiences soon.

Sometime after trying to prototype a game with this system and it proving to be unfruitful, me and Gaz had came up with another idea. We are both big fans of 2D platformers, and Gaz is primarily a 2D artist and animator. We had the idea to cross the character, story of a traditional platformer with the speed of a top down shooter, as I never seen it done before. This evolved into an acrobatic lead protagonist with a whole backstory (who shall remain un-named for now). We came up with a prototype, which demonstrated (very roughly), the lead character, running and sliding around, climbing and grabbing platformers and shooting in directions that was reminiscent of Earthworm Jim.

By this time I had landed myself a job after the Herriman project and was working full time, as was Gaz (as well as through the Herriman Project). The general direction we were going, was very demanding on both of us. One of the biggest problems, was that, unlike Earthworm Jim, we wanted the player to be able to shoot in the air, while climbing and grabbing at all all times. The requirement for fluid movement was at odds with this requirement, so we put this project on hold for a while. I would very much like to re-visit this idea, perhaps with a simpler character and a prototype in the future, hopefully when we finish with the current project (more about this later). This also inspired us to think about a game that was more focused on puzzling and acrobatic platforming rather than shooting action ... but this is also an idea to concentrate on for the future.