Tag Archives: concept

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 goals: Time 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.

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.