This “design journal” is made up of posts I wrote on my public-facing blog while making PONGS.
The new game I’ve been making is so far called PONGS and it’s… a whole lot of_ PONG_s. So to speak. On the plane-ride home from Greece a while back I amused myself by trying to come up with ten different versions of PONG. Mostly I thought of it as trying to think of a whole lot of “gags” based on the mechanics and appearance of the original PONG (though I think it’s evolved in a little more than that now). When I got to ten I wasn’t back in Copenhagen yet, so I kept going. Eventually I made it to 25, which I was pretty pleased with. Now, after culling a couple and adding a couple, I have 26. The whole thing has been an interesting experiment in trying to work in terms of variations instead of one monolithic idea, it’s been quite a pleasing challenging. I have a few more things to do yet, but figure PONGS will be all done in a week or so.
So I’ve been toiling away at PONGS. I made 26 variations on PONG and then thought I was finished with it and would polish and release by next week. But then I was talking to Rilla and we thought of a couple more variants that simply had to be part of the collection. And once there were two more there really needed to be ten more. You know, for the children. But this led to a bit of an issue, because the way I coded the first 26 was a massive pain in the ass…
You see, I watched this pretty cool talk by Jonathan Blow where he talks about how you really shouldn’t bother with making your code “nice” as you go. Instead of thinking up clever data structures and efficient algorithms you should just do what works there and then so you can keep surging forwards. He makes a pretty nice case for the whole thing and I certainly found myself more or less convinced by the time all was said and done.
The problem is I think I got a little too into the message of “surge ahead”, so I adopting a particularly crappy way of writing my PONG variants. In particular, I wrote a “standard” version of PONG, and then I cut and paste all the code into a new file and then hacked it into each variant. That is, each file bears no relationship whatsoever to any other. Want to change the fonts used? Change all 26 files. Want to change how fast the ball moves? Change all 26 files. And so on.
And of course programming has, for a rather long time, had a specific solution to exactly this ridiculous situation. It’s called inheritance, and it’s pretty goddamn fundamental to object oriented programming. I didn’t use it because I was momentarily blinded my what I can only assume is my misinterpretation of Blow’s talk. Of course you should make 26 variants on PONG by using inheritance from a standard PONG. Good god man!
And so today I went back through it all and did just that, streamlining all the code so it inherits from the standard PONG code and just makes the changes necessary. Files that were a few hundred lines long shrunk to 10% or less of their size. The code actually made sense to read. I could now change fonts whenever I damned well pleased. It was pretty magical. I’m actually glad I didn’t used inheritance in the beginning just so I could see explicitly how wonderful it is to use inheritance by changing over. Not to mention how nice it has been starting work on the “final” 10 variants this evening and adding them to the inheritance structure. My my.
In short, it’s totally cool to forge ahead and code “what works”, but that probably shouldn’t include absolutely fundamental programming concepts. Just a heads up.
Today I found myself lying on the couch feeling maudlin about sprite collision detection and resolution. It was not unlike speaking to my silent (and admittedly non-existent) therapist when I gave a small speech about how I wished I was smarter and knew how to things like collision. I fervently wished at that moment I was a mathematician or physicist or, damnit, just a better programmer! But no, I’m none of these things and so have been battling away with some collision stuff for PONGS for a good chunk of today.
I’m using Photonstorm’s awesome pixel perfect collision checking to find out if the ball is hitting certain falling shapes in a particular level of PONGS. That all works like a dream, but the problem is that the Photonstorm code doesn’t actually help you to resolve the collision. That is, you know that things hit each other, but not what to do about it in response. I’ve spent time looking at how Flixel resolves collisions between simple bounding boxes, but even that kind of zooms over my head. I get bits of it, then maybe some other bits, but by then the original bits are all gone again. Hopeless.
I solved one problem just before starting to write this, but the larger problem of the ball itself is proving super problematic. Sometimes it behaves itself. But sometimes it passes through solid objects, or bounces off them at entirely the wrong handle. And just when I’ve plugged one problem up, another springs loose. Most annoyingly, because PONGS is so simple, I don’t think I can afford to include any minigame in it that isn’t mostly “perfect” in its behaviour, so I need to get this right or abandon the idea. Gah.
So anyway, wish I was a physics whiz is all.
I pretty much wound up my work on PONGS today. There are 36 variations on classic PONG in there, out of I suppose around almost 50 that I thought of and often even implemented before throwing away. The game started with me challenging myself to come up with multiple versions of PONG while flying from Athens to Copenhagen and I was super excited about it right from the beginning. Now it’s done, I feel kind of sad.
To some extent it’s par for the course. Whenever you finish a project there can be that weird lull and depression. After all, you don’t have that project to work on any more. With PONGS though it seems particularly disappointing. Basically, PONGS was just so much fun to make. The combination of a really simple base level with the chance to just come up with super random ideas for how to alter it was great. Making snack size games turns out to be pretty wonderful, in short. Now that the snacks are finished, I feel I’m having a bit of a sugar crash.
Definitely suggests to me that working on another minigame collection some time in the near future would be a good idea. Look for PONGS in the next couple of days!
So I released PONGS today, just two weeks after Epic Sax Game. There was some talk of delaying putting it out for a bit longer, to give myself (and possibly the Internet itself!) a break from my games production line, but in the end… no, it was a bit too exciting and I didn’t want to just hold onto it. In fact, PONGS is something I’m genuinely proud of.
Not that I’m not proud of the other games, but PONGS has been close to my heart. Perhaps because it’s been such a Spring Fling of a game, over in two weeks, hot and tawdry while it lasted… or something. Perhaps not that. But at the very least it was the most fun I’ve had making a game from start to finish in a fair while. It’s certainly another one of those nice “this game needs to exist” games, which is always a pleasure to put together and insert into reality – frankly it seems important that such games are made. Perhaps they fill some kind of gap in the space-time continuum. Or perhaps I just find them really funny.
As per usual, I think about PONGS in a couple of ways. First of all, a lot the ideas in there make me chuckle to think about and to experience when I play them. There’s plenty of good-natured ribbing of game design trends (serious games, edutainment) and tributes to existing games (Shit Snake, B.U.T.T.O.N., and more classic games like Tetris), and plenty of the games just “feel funny” to play for other reasons: perhaps the mechanics or the controls themselves are comical? Your mileage may vary, you stony-faced son of a gun!
Second, I’m really pleased to claim that (at least for myself and a couple of testers) a number of the variants are actually fun to play! This is kind of virgin territory for me in a lot of ways – it’s never been my objective to make games that are enjoyable in the traditional sense, so it’s with great interest that I found myself enjoying some of PONGS. LASER PONG and MEMORIES OF PONG are examples of this strange new phenomenon. Once again, your mileage may vary.
Finally, as with all these projects, PONGS has come to symbolise certain “larger” issues of game design for me. In particular, making variants of something as simple as PONG helped me to distill in some way what games might be made of. Or rather than that, perhaps, it has been in playing the games and seeing how much of a difference a tiny rule change makes to the experience (and strategies and all that) of play that have been illustrative. I’m not clear that it’s helped me perceive any deeper truths about “what games are” or anything, but experientially, at least, it has felt interesting and worthwhile. You mileage will almost certainly vary.
And, after all, isn’t it all about variable mileage in the end?