Platform Game in Four Days
I was invited to be a juror in a programming competition Špongia. The competition is about programming computer games in several days. To understand how contestants feel, I challenged the organizer Dano Lovásko for a programming battle. One against one, time limit 4 days, more precisely 3½, topic "platform game", programming language of own choice. We have not found yet an independent jury to judge our results, but this is not so important. I am happy to have tried this, and here is my experience.
First a few words about the competition. Špongia is subtitled "sport-like programming of graphical interactive applications that don't repel the eyes", which means programming of computer games with emphasis on originality, playability, and aesthetic impression. The competition was established in year 2006 by students of Grammar school for extremely gifted children in Bratislava. In year 2007 students of two other grammar schools joined. (If you are a student of primary or secondary education, and would like to try this, please write me a comment.)
Typical programming competitions are focused on writing effective algorithms, and for a layman they are uninteresting and unintelligible. In Špongia the algorithm is only a tool for achieving the goal, and evaluation criteria are comprehensive for a layman (gamer). But this does not mean easier work for the programmer. Contrariwise, s/he must additionally process input from a keyboard and mouse, and display nice animated graphics. Participants come in teams up to 6 members. Larger team is not necessarily at advantage; it is more difficult to coördinate coöperation. Nonprogrammers can contribute by graphics and music. In the previous year the participants had 18 days to create a game. The exact settings are published at the beginning of the competition, in October. The previous years' topics were "water" and "puzzle".
(The homepage of Špongia is only in Slovak language.)
My advantage compared with the participants is 10 years of professional programming, preceded by another maybe ten years of amateur programming. On the other hand, I wrote a computer game last time maybe twelve years ago in Turbo Pascal programming language under MS DOS. Since then I have been mostly writing scipts, libraries, and websites. It was not a problem to study some graphical interface, but I had few time and lot of work. And I knew I would spend one day by some extra-computer activities; this is not an excuse, also the participants are normally attending school during the competition.
I chose the Java programming language. I wanted to write in a language I am very familiar with, so as the technical details would not hinder my coding. This could have been Java or Perl, but I never wrote an interactive graphical application in Perl, and Java has a great development environment Eclipse. I do not know how to make sound in Java, but because I cannot compose music and I did not want to waste time by looking for a nice free music on the internet, I decided that the game would be without sound. It decreases the overall impression, but I would have to balance it by something else.
As first step I created a screen 800×600 pixels large, which could be run in an application window or in a web page, and it would display a colored rectangle. Just for a good feeling that I already have a first advantage against my opponent coding in C++, and because it is relatively easy to do it in Java.
Then I painted a simple stick figure in graphical editor MS Paint. In game I loaded the figure from a file and displayed in on the screen. I added movement using keyboard arrows, so the figure was floating in the air. The screen with figure was repainted 50 times per second; the figure was blinking, so I added a virtual screen, where it was always removed and painted at another place, and only then was the result copied on the real screen. To add some content I painted a blue-green picture as a background, and some brick walls built from square tiles. The figure was still freely floating above the walls.
Before painting more pictures I wanted to decide how large should the figure be, and how quickly should it move. This decision would be easy to change later in program, but it would require painting new pictures and designing new rooms, which would be a waste of time; it was already a middle of the second day of four. When I was programing games twelve years ago, I always moved the figure by one pixel per 1/50th of second, which produced a nice fluent movement. But to move 800 pixels it would take 800÷50= 16 seconds, which seemed too much. But when I tried speeds larger than one pixel, the movement seemed like below a stroboscope. What should I do?
If the figure will move quickly, I probably cannot paint it using one pixel wide lines. So I used vector editor Inkscape, I constructed the figure from curves, and exported it as a bitmap. And despite using only the most simple shapes again, it looked much better than its previous version. It even had semitransparent pixels at the edges of curves, so it looked smooth on any background. It was obvious that I would paint all pictures like this.
I decided the dimensions of the figure to be 40×80 pixels, and I built the terrain as a mosaic of 40×40 pixels large tiles, which divided the area 800×600 pixels to a grid of 15×20 parts. In horizontal movement I let the figure gradually accelerate up to 7 pixels per 1/50th of second, which seemed fast enough and relatively smooth. Vertically it jumped at 16 pixels speed, to let it jump up three rows of the grid under gravitational acceleration of 1 pixel. I gained these values by experimenting until the movement of the figure seemed right.
In addition to walls I made a grassland. I had to completely change the collision algorithm. The wall is impermeable for the figure; it cannot fall through it, pass it from the side, nor penetrate it by head. The grassland is semipermeable; if the figure is above it, it cannot fall down through it, but if it is standing lower, it can walk in front of it, or jump on it from below. The wall right above the head is like a ceiling, which cannot be passed and must be circumvented; the grassland right above the head is like a step of the ladder, which can be jumped on.
I was pleasantly surprised that the whole screen can be refreshed 50 times per second. My computer could do it even 65 times per second, and this is a two years old cheaper machine (1 GB memory, 1.6 GHz processor). I knew that Java was a slow language, and I was planning to improve the program so that each 1/5th of second only the modified parts of the screen would be painted; but I postponed the improvement, and was surprised that the program works quickly anyway. Later I modified the program, just for the good feeling that I was not wasting computer power. Only after the programming battle was over and the results were sent, I have discovered that there was a logical mistake in that modification, so the whole screen kept always repainting yet. No problem, at least it worked. ;-)
I added an enemy snail, which moves using the same algorithm as the figure, only slower, and it cannot jump. I added apples collectable by the figure. I planned to add more enemies and collectable items later, but then I had no time for it. I also added a flying platform, which functions like a grassland, but it is moving horizontally, so the figure must walk on it carefully not to fall down.
During the last day I had less success, because I was afraid of the coming deadline, I was tired of programming, and I was looking forward to rest after the end. I extended the screen to 820×660 pixels; the inner 800×600 pixels contained the game, and there was a frame around with bottom part where I planned to display collected keys and other special items. If the figure collected all items, another room started; if it was touched by a snail, the room restarted. I added the commencing and final screens. It took me a few hours, so then I did not have enough time for programming the planned keys and unlockable doors, so some of these adaptations were useless for the competiton. The texts at the start and finish were saved like pictures; it is a waste of disk space, but it was the fastest way to do it. Originally they had to be in Slovak and English languages, but when Inkscape failed to display Slovak characters correctly, I wrote only the English text, because I had no time to find a fix.
The night started, so I quickly designed five rooms; in the first four I quickly introduce the game elements, and the last fifth one is difficult, to make some troubles to player, not to make the game seem too short. The rooms were edited directly into the source code; I did not have time to write a room editor. I zipped the result and sent it by e-mail.
So the programming battle is over, but I hope I will later find some time to finish this game, and possibly make some other games. When I consider how much have I learned during those years, and how powerful are computers today, it is a great challenge. (Today you could write in Java without problems a game like Warcraft 2.) And I am looking forward to Špongia 2008, where I cannot participate officially, but I will try to find some graphic designer to help me with an unofficial extracompetitive contribution.
I think that every individual or team who wants to create a game should try something like this. There are too many game projects on the internet which started by creating a web page, writing a story, and painting some example pictures, followed only by messages like "we are working on it, wait a moment", and possibly a few years later final message like "we are not working on the project anymore, it was postponed indefinitely". This sport-like style of programming will mercilessly check your team abilities, find your weaknesses, and show you what kind of result can you expect in what time. Regardless of what kind of game you are trying to make, try spending the first week making a complete microdemo. It is worth to sacrifice one week to find out if the following years will not be wasted.
The game "Platform 2008" (I could not find better name) can be downloaded from SourceForge.net under license GNU GPLv3 including the source code.
posted by Viliam Búr at
2:24 AM
2 Comments
