Oblong Conglomerate: Retrospective

January is over, and The Quest for the Oblong Conglomerate is fini compl operational. As an excuse to put off work on my February project, I have decided to summarise the experience, for my own benefit and that of whoever typed the wrong URL into the address bar and ended up in this cesspit.

The Game

The Quest for the Oblong Conglomerate is an epic tale of self-discovery. It may charitably be thought of as a game, and is almost certainly a platformer for exactly one human player. A playthrough takes about five minutes if you have ever played a platformer before, and has a documented 32‰ probability of making you a better person[citation needed].

The Quest for the Oblong Conglomerate (1GAM version 0.9.1) is available on GitHub.

Gameplay

This is a very basic platformer, in which the player’s options are limited to walking (left and right, though each individual stage requires only one of those), jumping, climbing ladders, and talking to interacting with using NPCs and large, rectangular McGuffins.

There are four maps in total, made to act as 13 playable stages through the magic of backtracking and artificial padding. The plan was to make each visit to a given map fresh and interesting by changing the configuration of enemies and moving obstacles, which would have worked just fine if I hadn’t cut those features to make the deadline. Oh, well. If MMORPGs have proven anything, it’s that player’s don’t mind doing the same crap over and over.

Graphics

The game plays in an upscaled 64×48 pixel window (with a scaling factor that I can’t recall and can’t be arsed to open up the source to check), with 8×8 pixel character sprites and 4×4 pixel tiles for the background. The low resolution has nothing to do with nostalgia, and everything to do with my being a terrible artist.

Sound

Not included, but players are encouraged to make their own sound effects while playing. Whoosh! Bang!

Challenges

I knew that creating one game a month would be difficult, an assumption that has yet to be proven wrong, but the exact areas that challenge me the most will inevitably differ from game to game. As far as The Quest for the Oblong Conglomerate goes, then, these are the main things that have tripped me up.

First game

The goal of One Game a Month is to finish one game per month; in contrast to certain other challenges in which I have a habit of participating, there is no rule stating that you have to start from scratch at the beginning of each month. As such, I have every intention of recycling code, art and knowledge gained in one project to leverage my efforts in later months.

With this being my January project, though, I had to make it without the benefit of any work already done.

One Game a Half-Month?!

I had never heard of One Game a Month until about halfway through January, and didn’t get started until the 17th. Under these circumstances and those outlined above, even The Quest for the Oblong Conglomerate, designed with the explicit goal of being short and simple, wasn’t small enough that I could finish it without cutting features.

Platforming and collision handling

The code that allows the player to stand on the ground is actually version 3 of something I’ve found unexpectedly difficult to grasp. The solution that finally worked for me is pretty much a step-by-step implementation of the approach described in Rodrigo Monteiro’s excellent article on the subject. The worst part is that I don’t even understand why my own implementations didn’t work, but I guess that’s something I’ll look into later.

Cut features

The lack of time, experience and pre-made assets forced me to settle for something less than my (already modest) original vision for the game. These are the main things I’ll have to add to a future “1.0” release.

NPCs

The version I managed to complete in January has only one NPC: the Wise Old King. However, I’ve made sprites and dialogue for four additional characters that would make the game slightly less boring.

Enemies

I deliberately made very few maps for the game, intending to add variety by altering the number, position and behaviour of enemy characters in each map upon repeated visits. However, I ended up running out of time before implementing enemy characters at all, so you really just make your way back and forth across the same featureless maps over and over again. As a direct consequence, a game that’s over in about five minutes still manages to feel like a chore. Considering my mission statement, that should probably be regarded as an epic win.

Multiple endings

Seriously.

Animations

I’ve got spritesheets for animated characters, and could very easily implement that functionality with the help of pyglet, but still settled for using the first frame as a still image for each sprite because I ran out of time.

Lessons learned

Terrible though it may be, this game has been a great lesson in what (not) to do.

Order sub-tasks by importance

I ended up spending so much time drawing sprites and writing dialogue that I never got around to putting it all in the actual game. Everyone recommends using dummy/placeholder assets until you’ve got the gameplay under control, and I ignored their advice. Good going, Namida.

Next time, I will make the game work first, and make it look (and sound?) decent second.

Adhere to Worst Practices

While I’m sure there are seasoned developers capable of putting together a great product in a month, for an amateur such as myself there is little hope of churning out anything better than a prototype or an early alpha in such a limited time frame. When you know that you’ll end up rewriting the whole thing anyway, the only “good code” is code that’s quick to write.

For my next project, I will hard-code as much as possible from the get-go, and never shy away from short-cuts, no matter how ugly.

Tools and assets

The part where I acknowledge the giants from atop whose shoulders I relieve myself upon the world.

Python (programming language)

The whole game is written in Python. I positively adore this language, so expect this to be the case for most of the games I make this year. I want to make the transition to Python 3.x, but always seem to end up using the version I’ve got pre-installed. This may not be a problem for much longer, but as far as this project goes, I can only vouch for its compatibility with Python 2.7.x.

pyglet (Python library)

I’ve been using pyglet for all my projects since the day I decided to write games in Python. It’s reasonably easy to use, and takes care of most of the stuff I don’t want to do myself. Still, one of my reasons for taking on the One Game a Month challenge was to broaden my horizons, so this may be the only pyglet-based game I make this year.

Stani’s Python Editor (IDE)

SPE is a wonderful editor that only does Python, but does it well enough that I’m not going to bother looking for looking for anything else.

GrafX2 (bitmap graphics editor)

GrafX2 is not perfect, but has a tight enough focus on pixel art that I’ve chosen to use it for all my low-res art needs.