One of those old discussions about scope came up recently at work, so I was interested to see how long it would take to make something in as small a scope as possible.
So I made Pong, you can play it via the link above. It probably still has a few bugs, but should be mostly stable. You can play it in a browser in either singleplayer or a couch multiplayer mode, side by side. It uses keyboard controls but should also support XBox and Playstation controllers
It took me probably a couple of hours (if that even) to get a simple working version of it up and running. But I ended up taking it further, and over the next few evenings I coded in some pretty basic AI for a singleplayer mode, a menu to choose between the two, some audio, and fixed a load of bugs.
Pong was an obvious candidate for a small scope game: the controls are simply up and down, and any modern engine (I used Unity) can handle the ball’s physics movement and collisions pretty easily. Creating a game as small as Pong is also a great exercise in experiencing the process of creating and releasing a full game. And is, as most game developers will already know (and are always eager to drill into students), eye opening in terms of what proportion of time is spent on developing the various aspects of an entire game.
Bugs probably took up most of my time, which was mostly down to getting the ball’s physics to behave properly, and some UI issues with selection and click sounds. Aside from bugs, it was the extra features I decided to implement that took up the rest of the time. The AI for the singleplayer mode is pretty rudimentary and can still definitely be improved. Despite this it still took up a fair proportion of the time.
The AI predicts the path of the ball by first checking if the ball is heading towards them. It then casts a ray from the ball’s position, along the ball’s forward direction, until the ray hits a point on the right edge of the screen. It takes the Y position of the point hit, then moves towards it (at the same speed a human player could for fairness) in order to block the ball. Obviously this would produce a perfect block every time, provided that the AI could reach the blocking point in time, so I introduced a random factor of error by adding or subtracting a random amount into the Y position to try and simulate a real player not quite guessing the path of the ball correctly. This process is then repeated after a short time (also randomised within a range) for correction as the ball is continuing to travel towards the AI.
The AI could still do with some improvement. As of yet it does not correct itself for the ball’s position more accurately as the ball gets closer (just as a human player would), but this is pretty easy to fix. It also only tries to predict the ball’s final position when the ball is facing towards the right edge of the screen, it cannot predict the direction of the ball before a bounce from one of the top edges. This is trickier to fix as I have to calculate the ball’s direction vector after the bounce. It’s possible of course, but I’ll have to dig into some more physics maths.
While Pong is a simple game, there are strategies and mechanics that permit more skilled play, and deepen its gameplay somewhat. By changing the direction of the ball depending on what part of the paddle it hit, we can add some player control to its velocity. In my version (and I think this is similar for the original) if the ball hits the very centre of the paddle it will move horizontally back across the screen. However, if the ball hits anywhere between the centre and the top edge of the paddle, its direction will be altered according to how far it is from the centre, up to a maximum angle of 45 degrees.
So if the ball hits the very top edge of the paddle it will be fired upwards at a 45 degree angle. If it hits the bottom edge it will be fired downwards at 45 degrees. If it hit exactly between the centre and the top edge it would be fired upwards 22.5 degrees and so on.
The mechanic also provides a nice risk/reward balance. Hitting the ball closer to the top or bottom edge of the paddle is harder to pull off and you risk losing the ball. However managing to do it, and hitting the ball off at an extreme angle, makes it harder for your opponent to catch.
All in all, it’s a good exercise in creating and releasing a full game, and all the pitfalls and challenges that come with it. The basic (probably buggy) version took me an hour or two, but that version had no win conditions or anything that could define it as a complete game. Everything else took me a few more evenings to create, package, and release a full game. If anything it’s a reminder of that old maxim that the last 10 percent is 90 percent of the work.
Now that it’s done though, I could still improve it more, but I might start making other classic games just to see what the process is, and there’s always something new to learn even from the smallest of titles.