VectorStorm Blog

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!

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.

(I’ve uploaded updated builds of ThunderStorm, which allow users to remap their gamepads’ right analog stick. I encountered a gamepad today which had mapped the right analog stick to axes 4 and 5, bizarrely enough. If you’re having this sort of trouble with your gamepad, you might want to download 1.0.2. If not, there’s nothing new in the build.)

So that’s another Game in a Week in the bag. For a while on Sunday, I was seriously contemplating what I’d do when I missed the deadline; whether I’d relabel it as a “Game in Another Week” and work on it for a second week, or whether I’d release what I had and put it in a different category.. perhaps “The Space Under the Stairs”, or some such. Thankfully, I don’t have to figure that eventuality out yet. And with any luck, the things I’ve learned will help keep me from coming as close as I came on ThunderStorm.

What I did right:

• Last-minute hustle to put the game together, when I did finally stumble onto a viable game design.
• Willingness to step away from the computer, even late on Sunday, when I needed to think about design issues. Being close to the computer makes design issues feel like they can be solved by more physics, when they really can’t.
• Having the online commitment to actually produce a game within the week is what made it happen in the end. If I hadn’t been posting and blogging about it all week, I’d have given up and gone to watch television. If you want to do something that requires creativity and a lot of work, I can testify that the best way to force yourself to get it done is to post a deadline for yourself online, and make sure all your friends know about it.

What I did wrong:

• By far the biggest mistake I made was that when I selected the “cloud” theme, I didn’t brainstorm about the right things; I brainstormed about situations I could put clouds into, and about ways that I could use Box2D, and about ways that I could use the work I did on VectorPhysics in a cloud-based game. This lead me into a lot of interesting physics ideas which turned out not to be fun in an actual game.
• What I should have done is follow the tenets of experimental gameplay programming; I should have started by brainstorming about the properties of clouds. Once I started in that direction (in desperation on Sunday afternoon), it was actually pretty quick to reach the basics of ThunderStorm.
• Didn’t step away from the computer often enough. Those who have looked at the source code will have seen how much stuff I did that never got used. There’s VectorPhysics-like drawing of objects, there’s a run & jump control scheme, there’s a grappling hook, there’s all sorts of stuff that I was desperately making when I was searching for a design. That was all wasted time that I should have spent thinking about a correct design, instead of straining my brain trying to use technology as a replacement for design.
• In retrospect, I’m not sure what I think of the graphic style. It looks a little like a really cheap Flash game. I’m certainly not getting much value for the graphic engine under the hood. I suspect I may have strayed a bit too far from the core “vector graphics” look that I’ve generally been going for. But I’ll admit that it’s nice to finally have something that doesn’t have a flat black background, at least.

In retrospect, I’m quite happy with how ThunderStorm turned out. I’ve had some fun with a co-worker, trying to work out an optimal play strategy (Our favourite strategy involves getting all your thunderclouds lined up on one edge of the screen, and firing as fast as you can toward the opposite side of the playfield. It’s pretty effective, but very dangerous, as if a single happy cloud makes it through, the happiness will spread almost instantly through your closely-packed thunderclouds), and another tried to convince me to continue development on the core “controlling multiple agents simultaneously” idea behind ThunderStorm. And I may do that.

But probably not until after I revisit Muncher’s Labyrinth. And I’m not planning on doing that any time soon, either.

Wow. Who’d have thought that I’d go from design to fully playable game, including intro sequence, title screen, instructions, and credits scroll in just over seven hours?

Granted, there’s an awful lot of code copy and pasted from elsewhere, but still.

I’m making binary builds now; should have them up and ready for download within about an hour. Will post when they’re ready.

Update:  Binary builds for Win32 and OSX are now available from the “ThunderStorm”  page in the sidebar!  Please leave comments on the static ThunderStorm page. 

There probably won’t be a second playable (owing to a total lack of time), but here it is.  I’m currently calling it “ThunderStorm”, and it’s a somewhat wild and madcap shooter, which is probably way too generous to the player (total death comes quickly and unexpectedly, but very, very infrequently.  There is likely to be an optimum strategy which would lead to infinite playtime.  But that never stopped E4, so who am I to complain, as long as the game’s fun?)

But honestly, at this stage, I’m just happy to have something that makes me smile when I play it. 

Now I just need to fit in an initial menu screen, instructions, and maybe find some sound and music.

And I need to implement a control scheme that doesn’t require a two-analog-stick controller.  Probably using the mouse.

Note the time.

And yes, I’m insane.

My mouse is kept on the right, and is plugged into the USB port on the left side of my laptop.

My gamepad is kept on the left, and is plugged into the USB port on the right side of my laptop.

Once again, I’m amazed at what my mind gets up to when I really ought to be focused on coding.

Also, I now have a functioning grappling hook, which is sticking to “clouds” and letting the player swing around like mad. If I was really desperate, I could generate a “target” cloud to land on, put in a ground, some basic level progression, and call it a day. But I feel like there’s more that should be done.

Well, I didn’t see this one coming! I had my brilliant idea which was both cunning and simple to implement, and after work yesterday I quickly banged it out in just a half hour and..

It wasn’t fun.

I called the idea “Cloud Racer”, and it revolved around the fictional, highly competitive sport of hotted-up racing clouds (although ‘racing’ really had no place in the game concept). In effect, you’re centered on a particular cloud racer, which is zooming across the sky, raining all the way. As the cloud is raining, it is shrinking. As in Vector Physics, you are able to draw solid and rope objects, and your goal is to catch nearby clouds as you travel past them, to try to capture their moisture and add it to that of your own cloud, and thereby be able to rain and race for longer.

In effect, it’s basically a version of Crayon Physics where instead of trying to get a ball to a star, you’re trying to catch objects that are being algorithmically generated by the game. Simple to code, but as it turns out, it isn’t actually any fun to play. The simple joy that you get from the wide open “draw whatever you want” physics playground games is simply lost when you try to focus it down into tighter goals.

Of course, a game prototype being ‘non-fun’ has never stopped me before, but upon retrospect, it was also a time-limited game (which I previously stated that I didn’t want this game to be), and also a “look, I have physics!” game (which I also previously stated that I didn’t want this game to be). So I find myself without a viable game idea on the Saturday afternoon. What to do now?

Well, honestly? The new Sam and Max episode, Night of the Raving Dead, is sitting on my hard disk right now, looking awful lonely. But I’m going to be good and not play it until I have something out the door. So without that, I’m off into experimental gameplay land, searching for something fun for the player to do. Right now, I’m starting with generic movement mechanics. First order of business: a grappling hook. Yes, it has nothing to do with clouds, but at this point I’ll be perfectly happy to put something out which has only a passing connection to the chosen theme. And maybe if/when I find something that’s fun to do, I’ll be able to bend it back toward being relevant to clouds.

So I got home after work tonight, and realised that I was out of fresh milk. So I decided to wander down to the corner shops to buy milk, and as I walked, I thought about cloud-based game designs.

And during that walk, I think I finally broke through, and came up with a real game mechanic. It’s reasonably simple and easy to code, and I’m hoping to have a gameplay prototype worked out by tomorrow night. The screenshot here is just a quick rendering test, experimenting with cloud rendering.

Of course, in the actual game, clouds will be a bit more rounded off than these rectangles; this was just a test of the basic concept. And yes, it’s rendering using ordinary VectorStorm rendering. It’s rendering normally instead of additively, and with the bloom shader turned off. And with an overlay for the sky, and for each cloud, to make the nice gradients.

Hopefully I’ll have a much more representative screenshot to show off tomorrow!

So here it is, Wednesday evening, and I don’t have a solid gameplay idea yet. To be fair, with Muncher’s Labyrinth I didn’t get the final gameplay idea until Saturday morning. But I’d still be a lot happier if I had a good idea to get started on right now.

When I’m working on a very wide-open game design like this, my general approach is always very visual; I try to get a mental image of what the game looks like on screen. Once I have that mental image, I try to invent gameplay mechanics that fit within that mental image. Sometimes it’s easy, like with Muncher’s, and sometimes it’s really hard, like with Petition Damsel.

With that said, I do have two vague images in my head, running with the ‘Cloud’ word, but I don’t quite have gameplay to fit with those images.

The first image is of a person who lives on a cloud. This person lives in a little house, built on the top of the cloud, and there’s a small smokestack that puffs out smaller clouds; the whole thing would be viewed from the side. I think that this mental image is heavily inspired by the illustrations from The Little Prince. This is, for me, the stronger of the two mental images.

The other mental image I have is a top-down view of someone flying in the sky, dodging between or flying through clouds, with a simulated ground in the background, potentially getting the effect of flying ‘up’ and ‘down’ by scaling that background. I’m not sure exactly what the player would be trying to do here, though. Perhaps the player would constantly be losing altitude, but gathering clouds would buoy him up, allowing him to last longer. For me, this is a pretty weak mental image, but it does at least suggest some vague gameplay mechanics.

So I’m not entirely happy with either of the concepts I’ve been working with so far.. I’d love to do something freeform and open like the Cloud game, but I feel that you’d really want a full 3D environment to really deliver on that sort of promise, and VectorStorm isn’t that..

Anyhow, with any luck, I’ll have a solid gameplay idea worked out by tomorrow, and will be able to start implementing. Crossing my fingers.