Highway Tennis - development story
In this entry I will discuss my experience of making a tennis game for the PUTT contest.
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.
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 background: make 6 big squares and paint entire background in each frame (the 500x500x9 image became quite big!).
Music and sound effects
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.
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.
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: