VectorStorm Blog

And now for the bit that I didn’t have time to type out last night.

Twisty Little Passages is a neat history of interactive fiction; the genre that has grown out of text adventures. I bought my hardback copy from a bookshop stall at GDC in 2005, and have to confess that I still haven’t read the whole thing; it’s been on my “to be finished the next time I take a flight somewhere” list for ages, but keeps being passed over at the last moment, since it’s a reasonably sizable hardback book. In any case, the book is copyright 2003, and is published by The MIT Press.

I used to be heavily into interactive fiction, to the point that I had a few games of my own in progress, one of which was a tiny little experimental game entitled “The Jaws of Victory”, which I’d intended to finish up and enter in three different IFComp competitions, but was completely stuck for a satisfying endgame sequence. Oh well. But I do still play the IFComp entries each year, though often not in time for the voting deadline.

Since it was mentioned in the quote providing the theme for the GiaW, I spent some time looking at Mystery House today, as well as a few of the revamps and spoofs over at Mystery House Taken Over. I’d not seen the game before, and as it turns out, it’s really an interesting piece of gaming history. I’m going to need to make a few nods to it in my game.

Anyhow. My plan now is to start prototyping the basic gameplay using a static set of data, both level geometry and events. Once I have a basic gameplay prototype, I’ll return to random generation of the game data, to make it play differently each time. Hopefully I’ll have a few concept screenshots within a day or two.

Going to be a very quick post, today.

Nobody’s going to believe this quote, but it’s true. The book is “Twisty Little Passages,” by Nick Montfort (hardback), the randomly selected page is 170, and the first complete sentence on the page is: “In the first room of Mystery House, seven people are initially seen.”

The quote is so perfect for the murder mystery game I’ve been contemplating, that I’d feel silly not to use it for this. But I don’t know whether I actually have enough time to implement such a large project in just a week. Maybe I need to simplify it for the GiaW, and perhaps use a static mansion layout or something.

Or maybe I’ll just make a game about “people”, or the number seven. But that’d feel like wimping out. Anyhow, GiaW4 starts tomorrow!

Now in the svn repository:  This initial “Draw-In” shader, which over time will cause a vector object to be “drawn in”.  In this case, it has been applied to the game names in the main menu;  this screenshot was taken as the names are in the middle of “drawing in”, which roughly happens from left to right (in this case;  the shader just draws in the vectors in the order they’re drawn in the display list)

As it turns out, my “try to place a room in a square bordering two used squares” algorithm works extremely well; far better than I’d expected! However, the code required to make the system not get locked up repeatedly trying to place a room which simply won’t fit isn’t exactly trivial. the above is the first successful mansion floorplan I managed to generate; the previous attempts all ran into problems and ended up in infinite loops partway through the process. The algorithm will need an awful lot more smarts to avoid those infinite loops.

Some interesting points. I’ve found that hallways need to be only one square wide or high; they just didn’t look like they were the correct size at one square width. (Of course, that probably just means that my rooms are too small, which also means that my mansion grounds are too small, which they certainly are)

After having played with this for a little while, I’m starting to think that I should really grow a series of hallways after growing the entrance hall, and then grow rooms after that, to try to fill in the gaps, instead of trying to grow it all at once. Mansion floorplans look really unnatural if you have several hallways that aren’t actually connected to each other.

Still, I’m pleased to have been able to focus enough to put the code together today. Must mean that I’m getting better!

So in my last post, I rhetorically asked when would be a better time to post game design thoughts than after working a twelve hour day on a weekend while feeling vaguely ill. Well, I have an answer for myself.

I’ve managed to get about two hours of sleep since then, as my brain just wouldn’t settle down to let me fall asleep (it was stuck in a little loop of trying to debug an issue that doesn’t actually exist; and no matter how much I told myself that the issue didn’t exist, my brain refused to stop obsessing over how to debug it). Plus, I’m quite definitely ill. So I’m trying to take it very easy for the next few days.

But even so, I’m also going to continue writing about procedurally generated murder mysteries (although it’d probably be better for all involved if I didn’t try to write any code right now). I want to start by stating that everything I’ve been writing thus far are guidelines; they’re intended as sign-posts and touchstones during the development of the game, which are returned to to help in making the hundreds of tiny decisions that need to be made during the construction of any game, in order to keep the game on track.

So with that caveat out of the way, I’d like to talk about my current thinking about how our randomly generated mansion will be generated.

The key thing that distinguishes the construction of a house or mansion from (for example) a network of caverns as seen in randomly generated games such as NetHack, is that its living areas are tightly packed together, with very little wasted space between rooms, so it’s important that our construction algorithm pack rooms very closely together.

As a starting point, we’ll assume that our mansion is a single story. Our mansion will be built on a grid; the precise dimensions of the grid don’t matter. There are two types of rooms that we can place on the grid. The first are regular “rooms”, which are a minimum of 3×3 in size, but may be anything up to about 5×6. The second type are “hallways”, which are always either two or three grid squares wide, and will be at least twice that in length (but can be longer than that).

When building the mansion, the first room placed is always at one of the edges of the grid, and is labelled as the Entrance Hall.

After placing the entrance hall, the mansion construction approach works this way: First, we search the grid for unused grid squares which border two used grid squares. If we find any, then we randomly select one of these to begin placing our next room or hall. If not, then we randomly select any unused grid square bordering one used grid square.

We then try to place a new room, starting from the selected grid square. If we can’t fit one (it’s conceivable that we could have a 2×2 dead space which can’t contain either a room or a hallway, for example), then we just select a new unused grid square and try again. Eventually we’ll reach the desired number of rooms, and will be able to stop.

This gives us our base floorplan. Once we have rooms and hallways placed, we start placing doors. The general rule of thumb is that every room that borders a hallway will get a doorway to the hall. Any room that touches another room has a 50% chance of having a door to that other room.

Once we’ve placed the doors, we’re almost done; just do one more pass over the map to make sure that every room is reachable from every other room (that is, that there are no little groups of rooms entirely cut off and inaccessible from the rest of the mansion) , and add extra doors as required until that condition is fulfilled.

Or at least, that’s my initial idea. I’m sure that once I eventually get around to implementing it, I’ll find problems with the approach. I’m particularly worried about whether in practice, the “select a random grid square that borders two used grid squares” heuristic will actually produce tightly packed floorplans the way that I hope it will, without moving to a more complicated and intelligent room selection mechanic.

I might actually have a go at implementing this, tonight. See whether I can get something working as a proof of concept, despite my fever.

So I’ve just spent twelve hours at work on a holiday weekend, and I’m vaguely ill.  When better than now to post game design musings?  

The big problem with the “randomly generated murder mystery” idea I mentioned in an earlier post is that it’s too big and nebulous;  as a brief pitch it’s fine, but I need to actually start to work out a real design.

As such, I’m going to start with the most important things:  the target market, and the gameplay duration.   The murder mystery game will be a casual game aimed squarely at the casual gaming market (at its core, it’ll be a puzzle solving exercise, so I don’t want to try to target hardcore twitch-gamers), and a single standard game session should have a duration of between ten and twenty minutes (an “easy” mode may be much shorter).

With that in mind, we also need our core gameplay mechanic;  the thing that we’ll be doing the most during the game.  In this case, the core gameplay mechanic will be interviewing suspects as to what they did before and after the crime, and then comparing the information they give you compared against the information other suspects have given you, so you can figure out which suspects are telling the truth, and which are lying.

I’m imagining the interface for this as being a schematic view of the building, with a timeline that you can scrub forward and backward through, to see where the current suspect claims to have been and what they claim to have seen.  The player will have their own working area which acts as an overlay on top of this, where they can accumulate information about what others have told them, make notes for themselves, etc.

I’m currently leaning toward a Phoenix Wright-style “find conflicts between what different people remember, and present those disagreements to jog their memories” approach.  That seems like it’d provide a nice level of involvement for the player.

In fact, the player should probably be one of the guests himself, so he’ll have his own memories which he can use as a starting point for figuring out who’s telling the truth and who isn’t.  In terms of game mechanics, he could “interview himself” exactly like anyone else, but just know that he’s definitely not lying to himself, whereas any other character might be trustworthy or not at any given moment.  Having an objective “this much, at least, is True” point would probably make the game more accessible (much like how having more starting points in a game of Sudoku can make the puzzle much easier to solve)

Anyway, that’s enough for one evening.  This is just trying to get some broad brush strokes out about the direction the murder mystery game might be going;  I’ll start thinking about more gritty details tomorrow.

Just a very quick note that due to a recent spate of hot weather and an extremely busy work schedule, I’ve been feeling pretty run down for the last week, and so didn’t feel up to starting a “Game in a Week” this week, as I’d suggested earlier.

Luckily, things should be slowing down an awful lot over the coming weeks. I’ll either do the “Game in a Week”, or maybe I’ll try to do something faster; maybe the first step in a larger project. Not sure yet. I’ll think about it tomorrow, when I’m more awake.

For those watching the svn repo, Box2D 2.0.0 is now integrated with VectorStorm (with my own bugfix to work around a joint deletion issue;  hopefully an official fix for it will be coming soon!)

Projects I’ve been considering:

• Another Game in a Week
• A “Game in a Week”-style affair that’s compressed into just four days, to be done over the long Easter weekend.
• Implementing the “dinner party” game I discussed during the “Game in a Week” where I implemented Thunderstorm;  the little platformer which used the guests at a fancy soirée as the level geometry.
• I’ve also been thinking about procedurally generated games.  One possibility I’ve been thinking about more and more is a little game concept that I call “Every Shooter”, which generates a new shoot ‘em up every time you choose “Play Game”;  it randomly generates enemies, a player, and selects from amongst a large set of individual rules and control schemes to generate a unique shooter game each time you play.  This would be a much larger undertaking;  if I was to start on this, the first week would probably be taken just writing the basic random enemy generation systems..
• Also on the “procedurally generated games” point, I’ve been playing with the idea of algorithmically generated murder mysteries, which would be set inside randomly generated “worlds” (initially, isolated old mansions, and other “locked room” variants), in which the player would have to interview suspects and work out who was the murderer.  This also would be a much larger undertaking;  a week’s work on this might yield a good “isolated old mansion” generator.  Though I’ve never really done anything like this before, so it may turn out to be much quicker than I expect.

I just wanted to post an update on where things are at.

The current level of busyness at work will soon be easing off a bit; I’m hoping to have enough brainspace back to kick off another “Game in a Week” next week.

In other news.. Box2D version 2.0 has been released; I’ll be updating VectorStorm to that new version sometime very soon; I’ve already been playing with the new testbed examples that come with Box2D; lots of exciting new features in there! Can’t wait to adapt it all to the VectorStorm engine. Hopefully I should have that done sometime this weekend, just in time to not use it for anything meaningful in the Game in a Week, exactly like last time.

You’d think that this is self-evident, but many people (both inside and outside the industry) seem to be labouring under the confused impression that video games are in some way like movies. I’m writing this rambling little essay so that in the future I can point people to this page when they tell me that they have an idea for a game, and then proceed to tell me a cinematic story.

And also so that my friends can point and laugh at me, when I’m the one who makes that mistake.

I’ll confess in advance that this really has a lot more to do with professional games than independant ones, or the type of games that I tend to make here on the VectorStorm site. Sorry about that, but it’s my soapbox, so I can say what I like.

More beneath the fold.

Continue reading “Video games are not movies”

Very slow progress on VectorStorm lately. This is mostly because of being extremely busy at work, but also because I’ve been playing games rather than making them, the past week.

Stuff I’ve been playing this week: Sam and Max - The Raving Dead (excellent, for those following the Sam and Max series), Metroid Prime 3 (probably even better than the original Metroid Prime, for those who like exploration/puzzling action), Burnout: Paradise City (fantastic example of how to squeeze huge amounts of value out of a single set of level geometry), Phoenix Wright: Trials and Tribulations (I have a real weakness for this series), Oendan 2 (this game is going to ruin my eyes. Must.. remember.. to.. blink!), Professor Layton and the Curious Village (Casual game with stunningly high production values. And the setting is straight out of a platform game that I’ve been wanting to make for a long time, so I’m mildly annoyed that they got there first, and more fully-realised than I could possibly manage on my own), Patapon (I like its graphic style, but I’m not yet convinced by the gameplay), and just in case I somehow manage to finish all of the above, I also have the new “Apollo Justice” game in my “to be played” queue. And N+ on the 360 has more levels than I’ll ever manage to make it through. Especially bits of episode 14. Mean ol’ Metanet (they do apologise for that one, at least).

More independent stuff I’ve been playing this week includes Warning Forever (boss-centered sh’mup where later bosses are evolved based upon how well you dealt with earlier bosses), Tripline (deceptively simple puzzle game; I’m currently working on solving the very last level), and I’m immensely pleased to have finally beaten Cursor*10 (single-player cooperative game; outside-the-box game design!) At work, I’ve had a window open for the past week, with The Tall Stump running in it (I can’t really play it for more than a few minutes at a time; I find the controls to be painfully fiddly, but I also can’t simply stop playing it!) And of course, I can’t ignore Samurai Movers, which is simple, joyous mayhem (assist a nice old lady who’s moving house, through careful use of your trebuchet).

I’m hoping to get around to doing some more coding sometime soon; perhaps this weekend. But for right now, work and work-recuperation are taking my time. Things should ease off a lot, late next week.