Project: Inorganic Maize

I’m making a Procedural Death Labyrinth (PDL) for the Procedural Death Jam. It will, of course, double as my One Game A Month entry for March.

The title of this one will be The Quest for some Inorganic Maize, and it will eventually turn into a sequel to The Quest for the Oblong Conglomerate, but that won’t happen until 2.0 or so.

The Procedural Part

With the exception of a small town in which the player starts out, the whole world will be procedurally generated. Not only that, but the world will hardly be persistent at all; individual rooms will be generated anew whenever you leave them alone for too long.

Specifically, here’s how it will work: Rooms can be persistent or non-persistent. Persistent rooms are the town and possibly some special, quest-critical rooms (once found, but only until beaten). Additionally, any room the player just left is temporarily treated as persistent. All other rooms are non-persistent. When the player enters a non-persistent room, it will be procedurally generated based on any persistent rooms surrounding it, plus a small increase in difficulty. Some rooms may only ever appear next to specific neighbouring rooms, while others may require a certain difficulty level or the completion of a quest before they will enter the pool.

Other aspects of the game will also be randomised to some degree, but I haven’t put too much thought into how that will work, just yet.

The Death Part

Death will be permanent as far as individual player characters are concerned, but there will be some kind of feature in place to soften the blow to some extent. Unlockables, perhaps, or the promotion of player-killing enemies to quasi-boss status, with a subset of the lost character’s equipment as a reward for defeating them. We’ll see.

The Labyrinth Part

The “confined area” aspect of the game will be purely aesthetic. The world will be effectively infinite in size; even the computer’s memory shouldn’t be a limiting factor, since unused rooms will be discarded. I suppose there is a theoretical possibility of the room coordinates themselves overwhelming the player’s machine, but good luck travelling that far.

The Map

To facilitate more intimate interaction with the non-persistent world system, the player will have a magical map, allowing her to make an active choice to make certain areas persistent. Doing so will require pencil items that can be found or bought from town NPCs. Each pencil is only good for a limited number of uses, so the player will have to weigh the pros and cons of adding a room to the map.

Additionally, there will (probably) be a NPC who’ll buy maps off the player, paying more for maps containing interesting or distant areas. I may even make this part of the main quest: after finding the Inorganic Maize, the player’s objective could be to return to town and turn in the map showing its location.

Quests

Some of the town NPCs will offer the player quests, which will be randomised based on a few different templates (find an object, kill a boss enemy, etc.). Completing the quests and returning to town will result in some kind of a reward, as is the case in every other game ever made.

Quests will typically add extra items, enemies or even rooms to the randomisation pool, which would not otherwise be generated.

The Town

The town, being a perpetually persistent area, will not move or change on subsequent visits, at least not in the manner of other areas; however, to keep up with the needs of the developing player character, there may have to be some kind of level progression with regard to quests and shop inventory. This will likely be based on the highest achieved difficulty level, rather than that of a neighbouring room.

I will also have to give some thought to the effect of the town, effectively a room with difficulty level 0, on neighbouring areas. Should difficulty be reset to the absolute minimum whenever the player returns home, relying on the player to create short-cuts to more challenging areas using the map? Hmm.

Project: Prismatic Zealotry

And here’s another project I’m considering for February. This is less complex than Clockwork Clusterfuck, and so may be a better choice.

Prismatic Zealotry

Like the previous one, this project is also based on one of the vague themes I’ve been wanting to explore. The keyword is Colours, and notable influences include Tetris and every single match-three game that isn’t about sugary sweets.

If I hadn’t missed the Candy Jam, things might have been different.

As for a genre, Prismatic Zealotry will be a hybrid between a match-three puzzle game and… something else. I’m leaning toward a top-down action RPG almost, but not quite, entirely unlike The Legend of Zelda.

There will be a lesser focus on combat than in most action RPGs, or maybe the protagonist will just be a lousy fighter. Whatever the case, direct confrontation will not be the primary means of dispatching one’s opponents. In fact, that is where the match-three puzzle gameplay enters the picture. Most objects and creatures in the game world will have one of a limited number of hues, and if three similarly coloured entities happen to line up, they will spontaneously disintegrate or even explode. The player’s main weapon, then, is to push blocks around and lure enemies into spots where they will become part of a match, all the while avoiding the same fate eirself.

I can think of several extensions of the base concept. There could be equipment that changes the player’s hue while worn, or paint to change the colour of blocks and enemies. How far I’ll take it is really a matter of how much time I have to spare when the basics are in place.

The art style will be simple and cartoonish, to facilitate the use of an unambiguous colour theme for each entity. That is, pink characters will really be pink, and medium slate blue blocks will be obviously medium slate blue. Realistic graphics really aren’t going to fool anyone with a premise like this, anyway.

The plot will be… tacked on. Maybe I’ll base it on something by Shakespeare just for the hell of it.

I can’t think of any real challenges in this case. I know how to do everything I need to do, and none of it should take all that long. I guess I can afford to make a game I want to make once in a while, even if I don’t learn anything in the process.

Tools, then. Python, obviously, and probably pyglet since I already know exactly how to implement this thing using that library.

Maybe I’ll record a live soundtrack. Learning to play an instrument shouldn’t take more than a couple of weeks, right?

Project: Clockwork Clusterfuck

It’s a new month, and so I’ve started sketching out a new project for One Game A Month. Several, in fact, but this is the first one.

Clockwork Clusterfuck

The central idea of this project is one of the vague themes from my list of secondary goalsTime as Space.

The project name, Clockwork Clusterfuck, refers to a Noodle Incident mentioned in two of my NaNoWriMo novels. It really doesn’t fit the mood I’m going for, but I haven’t thought of a proper title just yet. Knowing me, though, I’ll probably run out of time and decide to stick with it, mood dissonance be damned.

This one will be a point-and-click adventure game, a murder mystery in the vein of the novels of Agatha Christie and others. An investigator (the player) attempts to unravel the plots surrounding the death of an extraordinarily unpopular individual. The twist is that the player character’s timeline is not aligned with that of the rest of the world; as ey moves between areas, ey also skips back and forth through time. As a consequence, eir mission is not only to find the truth, but also to be in the right place at the right time—literally.

Without a doubt, the biggest challenge in creating this game will be the plot. I have never written a murder mystery, even a regular one, and a non-linear timeline won’t make it any easier. Who is the murderer? How and when did it happen? And no less importantly, how do I limit the time travel feature so as not to ruin the challenge? Is the temporal anomaly connected to the case, or is it incidental? Do the other characters notice, and how do they react? I have some thoughts on the nature of the time travel itself, but I will elaborate on those in a future post.

The time travel mechanic also raises technical considerations. How do I model a game world in which there are multiple versions of the same room, each of which may have an impact on later versions? The same question applies to characters, their actions, and their knowledge. Carrying items around, a staple of most adventure games, is trivial as long as the player moves forward in time—an object disappearing and then reappearing an hour later is no more strange than the player character eirself performing the same feat—but things quickly become less obvious when we view the same scenario in reverse. Do I allow the temporary duplication of items by carrying them back in time, perhaps going as far as to make this a part of the solution? So many questions!

The setting will be a Victorian manor of some kind, though it may not actually take place during that particular era.

Once again, I plan to write the game in Python. I don’t know whether to use pyglet again, or give Pygame a shot. Probably the former, as I lack the time and motivation to learn another library right now. Other than that, I will use the same tools.

While this is a February project, it may not turn into the project of the month. To be honest, I doubt my ability to both plan and implement it in a single month. A more likely scenario is that I’ll let it sit for a while at the back of my mind while I make one or two simpler games. We’ll see.

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.

#1GAM Secondary Goals

One Game a Month is rather an ambitious goal all by itself, and I doubt that I will need any additional challenges to make it interesting. However, to get the most out of the endeavour, I have decided to create and maintain a list of secondary goals I may try to fulfil on the way, such as genres I would like to explore, functionality I would like to implement and tools I would like to learn.

Assets

Functionality

  • Save function
  • Replay function
  • Endless game
  • Crafting/mixing/upgrading system
  • Procedurally generated content

Genres

  • Roguelike
  • Puzzle game (prismatic-zealotry)
  • FPS
  • Metroidvania-style platformer
  • Danmaku shooter
  • Side-scrolling rhythm fighter
  • Card game
  • Stealth game
  • Turn-based platformer

Themes

  • Time as space (clockwork-clusterfuck)
  • Limited resources
  • Reverse unlockables
  • Colours (prismatic-zealotry)
  • Poetry

Tools/technologies

  • Pygame
  • Ren’Py
  • Inform7
  • Browser-based game
  • LAN Multiplayer
  • Asynchronous multiplayer
  • Touch devices
  • Unity3D? (Maybe not this year)

Vague ideas

  • Cellular automata
  • Glitches part of gameplay
  • Squidi’s Three Hundred
  • Absurdly long title
  • Strange or unpredictable physics
  • Blurred line between the game world and GUI
  • Polar coordinates
  • Infinite Tetris
  • Randomness

Oblong Conglomerate: Maps

Spent some time drawing tile sets and designing prototype maps for this month’s project, The Quest for the Oblong Conglomerate. So far, I’ve got a town exterior and three wilderness/cave maps.

Stage 1 - Actual size

Yes, those are 4×4 pixel tiles. Suffice to say, aesthetics are not among my top priorities for this project. Still, I think they look decent enough for now, with the possible exception of the town.

Town

Of course, I expect to have to tweak the maps a bit once they’re in the actual game—I can’t even vouch for their playability at this point.

Stage 3Stage 2

As prototypes go, they will suffice for now. This leaves the town interior, but I’ll do that later. I haven’t even figured out what purpose the town will serve, yet.

I’m using Grafx2 for the tilesets and Tiled to turn them into maps.

Project: Oblong Conglomerate

So I’ve decided to join the One Game a Month challenge. I figure it will make for a good excuse to explore some of the stupid ideas starting to pile up in my Google Keep, and to try out some new tools and frameworks.

My problem when it comes to game design—and just about every other creative endeavour—has always been that my projects grow too large, causing me to lose interest before ever finishing anything. To combat this tendency, I have begun experimenting with self-imposed, arbitrary restraints to keep myself in line: a limit of five game screens, for instance, or monochrome 16×16 pixel character sprites. Unfortunately, that plan hasn’t worked as intended; where I used to have too large and unwieldy projects, I have now become plagued with too many small ones, with no good way of choosing between them.

So, forcing myself to finish one game a month seems like an interesting approach to striking some of those projects off my list. It’s worth a shot, at least.

Oblong Conglomerate

With the first half of January (and then some) having already passed, I am left with precious little time to finish my first game. As such, my goal for January is simply this: Make something playable.

The project name is Oblong Conglomerate, and the finished product will have a slightly longer title: The Quest for the Oblong Conglomerate.

I will write the game in python, using pyglet and possibly Rabbyt. Exploring other frameworks is one of my goals this year, but… not this month.

It will be a simple platformer with a short, somewhat absurd plot about self-discovery and heroic deeds. There will be no cut scenes, but character interactions and story elements will be presented as text and a few static images.

The player character’s capabilities will be limited to running and jumping. Opponents will be evaded rather than fought.

The game world will consist of a town (interior and exterior) and three unique stages. However, the player will visit some areas more than once.

There will be one player character, two unique enemy types and two NPC types, though I may add recoloured versions of the above as needed.

Everything about the game will be tiny, with 8×8 pixel character sprites and 4×4 pixel background tiles. If I choose to add a soundtrack, it will be a simple loop no longer than 20 seconds or so.

Anything beyond that is for version 2.0.

bad games for bad people