I very nearly titled this a “post-mortem”, before realising that that’d have implied that I wasn’t going to do more Game in a Weeks.

I’d like to talk for a bit about the Game in a Week process;  about what it was intended for, and about how it has worked out, and maybe about what I want to do with it in the future.

From the start, Game in a Week was supposed to be a game design exercise, not a game making exercise.  Yes, I was supposed to produce something playable by the end, but the real goal of the exercise was to get more practice at designing games — particularly unconventional, experimental games;  I already have heaps of experience implementing games, it’s breaking out of the box that I need practice at.  What’s more, it was supposed to be a low-stress activity and have low-impact on my other development;  the idea was that I’d do what I could do for a week, and then stop.  No matter what state the game was in at the end of the week, I would release it in that state and never spend time working on it or maintaining it again.

One of my unstated goals from the start was that each design for a Game in a Week should be interesting and unconventional in some way.  I didn’t want to just create a variation on somebody else’s game design.  I definitely didn’t want to make (for example) a fancier version of Asteroids.

With that said, let’s run down the list and talk about each game I’ve made as a “Game in a Week” project.

Ill-Timed Petition Damsel

In many ways, Ill-Timed Petition Damsel is my favourite of the Game in a Weeks.  It definitely had the best theme statement to select from, and it turned into a really interesting, unconventional game design.

The design here was that you were attempting to get signatures for your petition about road safety.  The trick was that each copy of your petition was somewhat cursed — after a certain period of time, an out-of-control car would smash through it and anyone nearby.  So your goal was to get the petition close to as many people as possible within the time limit (thus gaining lots of signatures), and then get rid of it again in such a way as to avoid any people being hurt by the out-of-control car.  If people did get hit by the car, police would appear and try to apprehend you, one police for each person hit by a car.  The game ran until the player was caught by a member of the police.

Stripped of the theme, the game was really a “push your luck” sort of game, where you want to get into a high concentration of pedestrians for as long as possible, and then get far, far away from them before the consequences hit.  As pedestrians (inevitably) get hit, you also have to evade chasers, which threaten to end the game.  It’s actually a very simple design, but not one that we see used often.  I can’t think of another game I’ve played which is structured this way.

I’m very proud of this one.

The Muncher’s Labyrinth

The second game went just as well as the first — maybe better.

The Muncher’s Labyrinth, at its core (although I wasn’t thinking about this), is a reversal of Pac-Man.  It’s a game in which the player must defend the dots in a maze from invaders.

My original design for this game was completely different;  it was almost a variant on pachinko;  you were attacking an enemy castle by using a cannon to fling a Muncher over the castle walls.  The trick was that the user had no control over the cannon’s angle or power.  Instead, the player needed to position a series of panels for the muncher to ‘bounce off’ from in mid-air, in the hopes of getting it to land inside the castle walls.

But partway through the week, that ‘pachinko’ approach just wasn’t feeling fun to me.  So I switched the design.  And this was much better.

One element I really love in this game is the ability to break down walls, which provides a short-term benefit (catch a fleeing thief), but long-term penalty (thieves can move around the maze more freely).  The charge mechanic feels really solid to me as well;  the time it has to build up before activating just makes it really satisfying when you manage to time a charge right.

The one little issue I have with this game was that while I was developing it, it felt like it dragged on for far too long if you played until every gem was stolen.  So I put a five minute time limit on it, and scored the player based on how many gems were left at the end of five minutes.  Now, I intensely dislike that choice.

In retrospect, I should have had a positive goal for the player, instead of only negative ones.  That is, in addition to “stop the thieves from achieving their objectives”, there should have been an objective for the player to achieve.  This probably would have been to visit some number of points within the maze (my instincts say four), and once those four points were visited, the invasions would stop and the game would end.  This would have made a much more sensible duration on the game, and put another interesting choice into the player’s hands:  charge off to hit his own objectives, or stop the thieves from achieving theirs?  This would have been much better.

Trivia:

• Each thief has a 1/256 chance of spawning using the Petition Damsel graphics, instead of the usual thief graphics.
• This was the first VectorStorm game to render a filled triangle, which was used to give the impression of bright light flooding in from the entrances to the maze.

Overall, I’m extremely pleased with how this game went.  The Muncher is still the unofficial mascot for VectorStorm games, often showing up in credit scrolls and elsewhere.

ThunderStorm

This was an interesting one.

The big design question I was playing around with in this one was about whether an arcade game could be made in which a player controlled a process, rather than controlling a specific character.

In the game, the player starts out with one angry storm cloud.  In his rage, the player shoots thunderbolts at happy clouds.  If a happy cloud is hit by a thunderbolt, it turns into an angry storm cloud.  The players controls affect all storm clouds simultaneously.  That is, they all shoot at once, in the same direction, and they all move at once, in the same direction.

Happy clouds, controlled by AI, attempt to merely touch the storm clouds, which would calm them down and take them back away from player control.

There were lots of variations of this game.  I had versions where hitting a stormcloud with a thunderbolt would destroy the stormcloud, I had versions where you could use mouse control so that all stormclouds would fire at a single position, instead of all firing in the same direction, etc.  In the end, I really like the zero-sum, closed-circle feel to the game.  There’s always the same number of clouds, and at the title screen they’re all happy clouds.  Starting the game just makes one angry, and then there’s a brief swirl of activity of clouds making other clouds angry, until finally everyone calms down again, and then we’re back at the title screen again, where we can start another game.  This wasn’t consciously my goal going into it, but I think there are some interesting messages in here about the nature of many modern social interactions.

And there were lots of different reactions from different people about how easily they were able to cope with the rapidly shifting “which clouds do I control right now, and how do I develop a strategy to cope with that?” challenges.  I call this game a huge success, in terms of being an interesting game.

Trivia:

• This was the first VectorStorm game to use Box2D physics.  The VectorStorm library’s Box2D bindings would later be set up based upon the code that I wrote for this game.
• This was the first VectorStorm game to render with no glow shader.
• This is the only non-testbed VectorStorm game in which the player can “shoot”.

The Incomparable Deductions of Police Constable Sir Nicholas Spratt

This was an intriguing idea.  I still love the concept.  Murder mysteries are good fun, and nobody really makes them any more.

But I made a mistake in doing this as a Game in a Week.  See, I’d already been thinking about making a murder mystery game at the time.  And so when the theme quote “In the first room of Mystery House, seven people are initially seen.” came up, I decided to use it to make the game I’d already been thinking about — the murder mystery game.  Which was too big, too complex a game to actually be designed and implemented in a week.  And I think that really showed in what was released at the end of the week.

The core idea — that I could run a simulation of the events of a murder mystery, rewrite the memories of one participant, and that the result would be a compelling game.. well.. I think that simply doesn’t work.  And this game really demonstrated how murder mysteries which were constructed this way would often not actually be solveable.

The thing I need to remember is that a “Game in a Week” is not about implementing a game within a week (although that’s part of it), but that at its core, it’s about designing a game within that week.  When I use a quote to justify making a game which I had already been designing in my head, I’ve completely missed the point of the exercise.

With that said, I’d still like to make a real game like this someday.  Make it properly, in a way that each mystery is solvable.  I have about 10% of such a game implemented at the moment, but it’s run into the same problems that this GiaW did;  how to construct the murder events in a way which makes the puzzle solvable.

Robot Finds Ice Cream

Oddly enough, this was probably the best design of all the games I’ve done for Game in a Week.  And one of the ugliest implementations.

The design is simple and clean and elegant; you control one character on a strict tile grid;  that one character must remain adjacent to a second character.  If you directly away from the second character, you will move one step in that direction.  If you move directly toward the second character, you and that second character will move until the second character hits an obstruction.  The goal is to get the second character onto a particular tile.  (Within the terms of the theme, this is getting the robot to the ice cream machine)

But yikes, this game was visually ugly.  Even by my standards.  I don’t know what I was thinking, trying to make an isometric view game when I needed a human and a robot, and with my art skills, and using vector graphics which involved typing vertex positions into a text file by hand, with no art tools involved whatsoever.  This really, really ought to have been implemented from an overhead view.  And honestly, it needed textures.  Which didn’t exist in the VectorStorm library at this time.

Of all the Game in a Week games, this is the one which could most easily be turned into a mobile phone game.  Just hire an artist and make a lot more levels, and it could actually be quite a clever little game.  That would be worth doing someday, now that I think about it.  And I dearly love having names and messages attached to levels, as I did in this game.  Named levels are a fantastic thing;  a direct, explicit communication between author and player, without any attempt at all to filter it through an in-world mechanism.  If you are a game developer, name your rooms and/or levels.  Just do it.  You’ll be amazed at the difference it makes to how people relate to you and to your game.

Lord, Save Us From This Horrible Land

This is where things really started to go seriously bad for Game in a Week.

I had recently added support for 3D to the VectorStorm library, and so I thought “what better way to stress-test the 3D rendering than to do a Game in a Week game?”  Which was me completely missing the point — “Game in a Week” isn’t for testing technology;  it’s for practicing game design.

As those who were reading this blog at the time know, it turned out that VectorStorm’s 3D rendering wasn’t actually ready to be used.  I had huge problems just getting a 3D planet rendering properly.

The design I came up with was a five-phase thing;  in essence, five games in one.  The game began with a meteor crashing into the planet and the player working to contain a spreading extraterrestrial plant species.  Each subsequent phase added a new game mechanic, with the flora slipping through the successful defense the player had mounted in the previous phase, and eventually resulting in the flora creating a new seed pod which would fire another ‘meteor’ off to some other planet.

Have you noticed that many of my game designs work in circles?  I like games which end where they begin.

Anyway.  In practice, if I had been thinking, I would have realised that no, I couldn’t implement five different games in a single week.  I couldn’t even implement five terrible games in a single week, much less five good ones.  And especially not when I couldn’t even make my 3D camera point at the planet successfully.

To make matters worse, rather than actually end the Game in a Week after a week and just post what I had, and get on with my life, I felt that I could salvage things;  if I just spent a little more time on it, I could actually make the game that I had wanted to make…

In the end, I released a substantially cut-down version of Lord after seven weeks, rather than seven days.  It wasn’t the game I wanted to have made, it was still very buggy, and it was extremely not fun.  And it completely killed my confidence and my motivation for a very long time.

It was more than two years before I’d try another Game in a Week.

GoGoGo!

Steven Lavelle challenged me to create a game before 2011.  He sent me the challenge about ten hours from the end of 2010.  This wasn’t really a “Game in a Week” by any normal perspective, but I decided to treat it as one, just because I didn’t have anywhere else obvious to put it on the site.  And it was implemented in under a week, so that sort of counted, right?

Well.. the more I’ve thought about it, the more I’ve felt that it sort of shouldn’t have been counted this way.  It was really a very different beast.

In practice, I just decided to make an infinite racer.  One game I’ve always wanted to write is a home computer version of Virtual World Entertainment’s Red Planet;  a location-based racing game.  In practice, that’s not actually what I made here, but it’s where the inspiration about zooming down a corridor at breakneck speeds, with solid rocket boosters which make you fly even faster, but with less control.  (I dearly love that “solid rocket booster” idea from Red Planet.  It’s something that shows up frequently in my games, since it’s such a perfect risk/reward mechanic that can be dropped into almost any sort of speed/distance-based game)

I don’t have a whole lot to say about this game;  it really is very simple.

Trivia:

• The game’s level geometry is all built by the same technology that was creating buildings, trees, and other geometry for MMORPG Tycoon 2 at the time, just turned inside-out.  The tunnel exists for about 2km in front of the player, and about 200 meters behind the player (I assumed the player wouldn’t be able to turn around without crashing, and so they wouldn’t notice the tunnel vanishing behind them)
• I was originally planning for the game to be played from a third-person viewpoint, behind a procedurally generated vehicle.  Silly me, I only had ten hours.  What was I thinking?

C4 Ten-Four

I have conflicted feelings about C4 Ten-Four.  On the one hand, this was my first real, proper Game in a Week game in many years, and it was fantastic to get back to what the process was really supposed to be about.

This particular design, though.. while I really like it, it turns out that it wasn’t as original as I thought it was.  Turns out that there’s a whole genre of games (mostly written in Flash) which involve transporting a fragile load on the back of a flatbed truck, and I never found out them about until shortly before the end of the week.  So.. in terms of design, there isn’t really a lot to talk about here;  it had all been done before.  The only really interesting bit which I added to the already-common design was that I used the rocket booster idea again (here expressed as a turbo charge).

Trivia:

• This is the only Game in a Week game (so far) which uses VectorStorm’s built-in Box2D bindings.
• This is the only Game in a Week game which my mother has mentioned to me in conversation.

Atop

And I’ve done it again — I completely ignored the point of the Game in a Week process and made a pre-designed game, instead of using the week to design a new game.

I don’t have a whole lot to say, here.  The code was mostly an adaptation of MMORPG Tycoon 2.  Almost everything visible in the game was taken and modified from the MMORPG Tycoon 2 codebase, apart from the terrain itself.  The sky and clouds are exactly the same, the water is only slightly modified, all the objects in the games use the MMORPG Tycoon 2 geometry generation code.. and the design came from an existing game design.

And the design was definitely a ‘cover’ of somebody else’s design.  I’m uncomfortable about the wholesale copying of other people’s designs.  I think in the case of The Sentinel it’s kind of reasonable since it’s such a historically important design, and since there’s no official version of the game available these days.  But.. definitely not as a Game in a Week.

And honestly, I have more useful things I could be doing with my time than re-implementing other people’s designs.

Ten(unnamed)

This is the game which I was working on last week.  And it was going badly.  And with stresses coming up in life, I realised that I simply wasn’t going to be able to present anything at the end of the week.  So for the first time ever, I out-and-out cancelled a Game in a Week project.  And given the option between this and what happened with Lord, I think it was completely the right choice.

See, I realised toward the end that not only would I have no time to implement my design, but also that my design wasn’t the sort of design I wanted to be dealing with for a Game in a Week, anyway.  It involved huge expanses of space,  it involved shooting, it involved enemies, and it involved having lots and lots of complicated AI.  It sounded like a traditional, mainstream game design.  Not like something experimental.

I’ll make another attempt at Ten sometime.  Maybe in a few weeks time.  But I need to get it into my head that I’m not trying to make a mainstream design that sort-of-fits into the random theme — I’m trying to use the random theme to force myself not to generate a mainstream design.

Somebody hit me if I forget that again, okay?  :)