In this entry I will discuss my experience of making a tennis game for the PUTT contest.

Architecture
The whole project was written in JavaScript as a web application. Mainly because I have worked with web technologies before, but also because I wanted to see what I could do with it. The architecture was to have a global Game() object that contained a Renderer() and Simulator(). The game stepped the simulator one step forward and then moved data to the renderer to draw it. I liked this approach because it seemed simple and the domains would not mess with each other. However, when I tried to implement more complex game-logic such as victory/defeat and powerups it became complicated. A powerup has both graphics and affects the simulator. As a result I scattered these functions both in the global scope and in the Game/Renderer/Simulator objects. It was very messy! In the future I will need to think more about how I implement these things in such a way that it is more modular. I need to use arrays in which I push modifiers and graphics as well as some form database perhaps. Javscript is kind of built to do chaining and modules, so I should look into how I could facilitate that.

Even though I referenced all game-related variables such as ball-size and initial velocities into a Level() object, it was still hard to create different levels. I tried but it became hard to maintain and compare levels as they were represented in really long lists. A much better approach is to store all level variables in a local browser database and then load/unload data from there.

I started out with using paper.js to render the objects. The framework is built for vector graphics and is ill suited for rasters (sprites). Also it's method for animation was conflicting with the methods of stepping the game. As I removed paper.js from the game I decided not to use any frameworks, I wrote everything from scratch. If I would have gone for a framework I would have had to learn that framework first, before getting productive. In the end I think skipping frameworks was the right thing to do this time. In the future I will need something. Both a DOM manager and also a animations and asset loader. I think I will go for CreateJS, it seems well adapted for Web games.

From a simulation point of view the whole games was frame based and not time based. I thought this would be easier and it was. However it becomes tricky to regulate the pace of the game, which is important if you want to regulate difficulty level. For physics it could be hard to do a time based system from scratch (with my skills), so I would again have to use a framework. Anmations are easier though, so I would probably do something time-based there.

Physics
I used simplified AABB collision detection without corner checks and no gravity. Speed was done simply by having a 2d position and a 2d movement vector. It think it was good enough this time, but I need to find a way to include the corner checks in my next game. It made the balls slide in a glitch manner.

Animations and graphics
I made a very blunt home made animation system, based on frames. My graphics pipeline was pretty efficient in the beginning, but as the project grew and continued in scope it became very tedious. I worked like this:

• Make placeholder sprite in paint and bind it into the game.
  
• Sketch cars and items with pen/paper based on books and alter their designs to prevent copyright problems.
  
• Draw them in Inkscape and export high-resolution .pngs
  
• For animations: make N frame-boxes (squares) and draw animation in them. Export whole strip as one image and step through it with javascript where one frame at a time is rendered.
  
• For background: make 6 big squares and paint entire background in each frame (the 500x500x9 image became quite big!).
  

This was not good because if I wanted to do a small change and see how it played out in the game I would have to repeat lot's of irritating steps (exporting/moving files/cropping) to get it working. I have to look for a more professional way of producing sprites and managing them. Also, I did not make any resource loader, which made some sprites load slower then others. This in return could result in the game starting without all sprites not ready.

Music and sound effects
I found an article that described how to sculpt explosions out of white noise. I also found an old tune I made in Garage Band. I used these assets as sound effects. I knew I would not be able to make a fantastic job in this area so I decided to leave it at the most simple level. Implementing it into the code became a little problem. HTML5 and Javascript supports sound, but the variables that handled the music and sounds went in as global variables. This was bad so in the future I hope I can find some kind of sound manager. I had the same problem as with the images - they were downloaded asynchronously (in the background) and some of them started to play too late. Furthermore, a sound object in JavaScript can not be played more then one time at the same time. In the future, I definitely need to find a framework that can handle the downloading and sound effect stacking properly.

Feedback and Help
I should have asked for more help about physics and collision testing. I was too proud and thought I could handle vector calculations and understand the concepts just by reading about it and drawing on my experience from university classes. I was wrong (I never really understood the courses) and it resulted in one and a half day wasted on nothing while working in a groked up mode. In another case I asked for help just to get attention to get me motivated to continue. This was childish and I need to channel this need in some other way in the future. Perhaps have a twitter feed like the rest of the self-absorbed netizens.

Publicity
I was posting too many pictures in the gallery. One per day (at some times) was too much. I should have shown more restraint in this area. One of the rules in the article 'How NOT to Market Your Indie Game' (Dushan Chaciej) was that you should not publish every step of progress. I think I will post stuff in a twitter feed instead, If I feel like it.

Meeting targets
I think I managed to include the mandatory features of the PUTT contest. It remains to be seen... :/ I can see how could improve the game now, but then I would need to rewrite the key structures. It's more fun to move on to another project, but reuse bits and pieces from this game.

Motivation and self management
The fact that the project was so well specified helped a lot. In the future I will work hard on the initial game design document. The fact it was an entry to a competition part was also important. Not because I necessarily want to win, but because it was a deadline to work against. Featurecreep was certainly a problem like it always is, but the deadline helped my prune the chaos quite a bit. Finally: here is an illustration that I think describe the development process:

[sharedmedia=gallery:images:4398]