{"id":2794,"date":"2013-03-02T11:59:39","date_gmt":"2013-03-02T01:59:39","guid":{"rendered":"http:\/\/www.vectorstorm.org\/?p=2794"},"modified":"2013-03-02T23:19:55","modified_gmt":"2013-03-02T13:19:55","slug":"retrospective-on-game-in-a-week","status":"publish","type":"post","link":"https:\/\/www.vectorstorm.com.au\/2013\/03\/02\/retrospective-on-game-in-a-week\/","title":{"rendered":"Retrospective on Game in a Week"},"content":{"rendered":"

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.<\/p>\n

I’d like to talk for a bit about the Game in a Week process;\u00a0 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.<\/p>\n

From the start, Game in a Week was supposed to be a game design<\/strong> exercise, not a game making<\/strong> exercise.\u00a0 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;\u00a0 I already have heaps of experience implementing games, it’s breaking out of the box that I need practice at.\u00a0 What’s more, it was supposed to be a low-stress activity and have low-impact on my other development;\u00a0 the idea was that I’d do what I could do for a week, and then stop.\u00a0 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.<\/p>\n

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.\u00a0 I didn’t want to just create a variation on somebody else’s game design.\u00a0 I definitely didn’t want to make (for example) a fancier version of Asteroids.<\/p>\n

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

Ill-Timed Petition Damsel<\/h2>\n

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

The design here was that you were attempting to get signatures for your petition about road safety.\u00a0 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.\u00a0 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.\u00a0 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.\u00a0 The game ran until the player was caught by a member of the police.<\/p>\n

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.\u00a0 As pedestrians (inevitably) get hit, you also have to evade chasers, which threaten to end the game.\u00a0 It’s actually a very simple design, but not one that we see used often.\u00a0 I can’t think of another game I’ve played which is structured this way.<\/p>\n

I’m very proud of this one.<\/p>\n

<\/p>\n

The Muncher’s Labyrinth<\/h2>\n

\"munchergameplay2\"<\/a>The second game went just as well as the first — maybe better.<\/p>\n

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

My original design for this game was completely different;\u00a0 it was almost a variant on pachinko;\u00a0 you were attacking an enemy castle by using a cannon to fling a Muncher over the castle walls.\u00a0 The trick was that the user had no control over the cannon’s angle or power.\u00a0 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.<\/p>\n

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

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).\u00a0 The charge mechanic feels really solid to me as well;\u00a0 the time it has to build up before activating just makes it really satisfying when you manage to time a charge right.<\/p>\n

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.\u00a0 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.\u00a0 Now, I intensely dislike that choice.<\/p>\n

In retrospect, I should have had a positive goal for the player, instead of only negative ones.\u00a0 That is, in addition to “stop the thieves from achieving their objectives”, there should have been an objective for the player to achieve.\u00a0 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.\u00a0 This would have made a much more sensible duration on the game, and put another interesting choice into the player’s hands:\u00a0 charge off to hit his own objectives, or stop the thieves from achieving theirs?\u00a0 This would have been much better.<\/p>\n

Trivia:<\/p>\n