VectorStorm Blog

I’ve now put a first pass implementation of very basic networking into the core VectorStorm engine.  This is only a very, very rudimentary implementation (and will currently only work under UNIX operating systems;  I need to load it up under Windows and add the necessary extra WinSock calls.  Shouldn’t take but a few minutes).

Here’s a screenshot of the Testbed game, which talks to a special server I was running on vectorstorm.org for a short while.  It’s not doing anything fancy, but it’s passing data back and forth.  Network packets are constructed using memStores (which were already being stored in network byte order, in preparation for this), and you use one or more vsNetClients and a vsSocket to specify where packets should be delivered.

Eventually, I’ll build cryptography in.  But this was a nice first step.  And it’s in the public SVN repository now. 

In other news, I’ve also added what I call “String Mode” to the input system.  Put the input system into “String Mode”, and the keyboard will stop acting as an emulated gamepad, but will instead construct a text string as though you were typing into a text editor.  This is in preparation for TIG’s all-but-inevitable “Procedural” competition, where I’ll want to accept a string input by the player in order to initialise my world generation algorithm.  This also is now in the public SVN repository.  (Though it’s kind of ugly;  right now it only supports basic alphanumerics and spaces.  No punctuation or unicode characters.)

So it sounds like the upcoming TIG competition is likely to be focused around procedural content.  I’d recently decided that I’ll need to rewrite Nicholas Spratt from scratch anyway, so I’ve decided not to start on Spratt 2.0 just yet;  instead, I’ll wait until the start of the upcoming TIG competition, which will presumably be sometime in May. 

In the meantime, I’ll work on a different project.  In fact, I’m pretty sure that I’m going to do another Game in a Week this coming week.  But since I’ll be away from home for the start of the week (and lose about a day due to plane travel), I’m going to make it easy on myself and select my own topic to complete, rather than go for the more traditional randomly selected topic.

But I’m still not sure about just exactly what I’ll be doing;  I’ll choose the final topic on Sunday night, as usual.  But I can say that the two GiaW topics I’m considering right now are:

1. Pulling StarShot out of the testbed games and turning it into a full GiaW game.
2. Making a MMORPG game.

And no, I’m not pulling your leg.  If I decide against doing the game-in-a-week MMORPG game this coming week, then it’ll be somewhere soon further down the line.

C’mon, you all knew I was going there when I mentioned networking a week or so ago, right? 

The Game-in-a-Week version of Nicholas Spratt (the downloadable one available from the sidebar) had a reasonably simple murder timeline generation system.  Basically, it picked a murderer and someone to be murdered, and picked a time during the day when the murder would be committed, then “locked” the room in that moment so that no other characters could blunder in and disturb the action.  It then picked an earlier time for the murderer to be alone in the room with the murder weapon, and locked the room so that no one else could be in the study at that time, either.  And then it used a pseudo-random system to have the remaining characters wander about between the game’s 24 turns, and recorded what everyone saw, and who was in the room with them.  (There was also a 2% chance of a mistaken memory, where a particular guest wouldn’t notice someone or would remember the wrong person, etc)

And that’s basically all there was to it.

For Spratt 2.0, I’m thinking about dramatically expanding on this.  Here’s the list of changes I want to make:

• Give all guests a randomly selected motive for wanting to murder the victim.  This is just for flavour.
• Randomise the mansion floorplan.  At least one room per guest (including the victim).
• Add doors to the mansion, to show how to move from room to room and from room to hallway.  Doors may be open or closed.
• Add multiple possible murder weapons.  Probably one murder weapon per mansion room
• Change the murder timeline from using 15-minute timeslices to 5-second timeslices, for finer grained accuracy on guest vs guest visibility.  Guest memories remain labelled according to 15-minute timeslices, but multiple things can now happen within a single timeslice.  Guests may move only a single grid space per five second timeslice.  Two or more guests may occupy the same grid space as long as all or all but one are still walking.
• When guests are in a hallway, they can see any other guest within line of sight, including those on the other sides of open doors.
• Add collision to the mansion walls, and let the player walk around inside the mansion.  one guest will be in each room, either stationary or pacing.  Talking to a living guest will let you examine their memories as in the GiaW version.  “Talking” to the dead guest will provide details about how he died (gunshot wound, bruising, etc, to help the player determine the murder weapon).
• Grandfather clock in the entrance hall, so those in the entrance hall will know the exact time, while others only know the last 15 minute bell that has chimed.  This is probably just flavour;  probably won’t matter to actually solving the mystery.
• Have two or more guests planning to perform the murder, and gather/return murder weapons, instead of only one guest doing this.
• Consider witnesses during the murder generation phase, and actually make sure that there are witnesses present to see particular key moments.  (Someone’s opportunity to get a murder weapon, etc.)

So someone pointed me at an entry to the recent Ludum Dare entry, The Butler Did It by Surrealix. Butler is another interpretation of the “randomised murder mystery” genre, like my own Nicholas Spratt project which I’ve been poking at on and off for the better part of a month, now. While I was unable to get Butler to run on my computer (the Windows port crashes at startup for me), I did take a quick glance at the source code to see roughly what it’s doing, and how it compares to Spratt.

For those who haven’t heard of it before, Ludum Dare is a 48 hour programming competition which
takes place twice a year, where the theme is announced at the start and then you have 48 hours to complete a game based upon that theme. It’s a bit like my “Game in a Week” thing, only even more compressed.

The thing that impresses me most about The Butler Did It is how much went into the game (developed in under 48 hours) that I had to cut from my Game-in-a-Week-edition of Nicholas Spratt due to implementation time issues. For example, Butler has a randomly generated mansion layout, whereas that was the very first thing I decided not to do in Spratt. I have some serious issues with the particular algorithm that Butler uses for level generation, but it’s extremely impressive to see it working at all in a game which was developed under such a short time deadline.

In addition to that, Butler actually has its characters pathfinding and moving between rooms, so that travel time becomes another way to eliminate possible suspects. That is, if someone has an alibi that proves they were on one side of the mansion at time ‘x’, then you can be sure that they couldn’t have made it to the opposite side of the mansion at time ‘x+1′, simply due to travel time. In Spratt, this sort of deduction was the second thing I cut; I just made my time slices large enough that a character could reasonably be assumed to be able to get anywhere they wanted to go within the 15 minute period between ‘turns’.

Finally, the murder generation itself. Butler is using a very similar murder generation system to the one I wrote for Game-in-a-Week Spratt; it divides the timeline up into slices, and each guest is in a single room in each slice. It starts by randomly selecting a murderer and victim and places them into the timeline first, and then starts filling out what the rest of the guests see and do. But it has some very significant improvements over how I did this in Spratt.

Most notably, it takes steps to ensure that the necessary witnesses are present at appropriate times such that every mystery it generates is actually solvable along a single line of reasoning, whereas Spratt just provided several different ways that a mystery could potentially be solved, and quietly hoped that through random chance, enough witnesses would be around to provide evidence for at least one of those approaches to work (and thus, Spratt’s mysteries were not always solvable). I should really take this extra step, to ensure that witnesses are present where they’re really needed, to ensure that cases are always solvable. Additionally, Butler intentionally and explicitly plants a third character; the “red herring”, as a second likely murder suspect.

In fact, I’d say that about the only major thing that Spratt does that Butler doesn’t do is track the movement of the murder weapon after the murder is committed. In Spratt, the murderer tries to find a place to hide the murder weapon, and in some cases, knowing where the murder weapon was eventually found and approximately when the murder occurred, you can really narrow down the list of people who could have had the murder weapon.

For the last few days, I’ve been struggling trying to figure out how to ramp up Spratt’s timeline and murder generation system for a revision 2 release. I know that I’m not happy with the characters randomly bouncing between rooms the way that they do right now, but I’ve been trying to figure out how to fix it; whether I need to set up a timeline on a much smaller scale (say, a 5 minute increment instead of 15 minutes? Or maybe as little as 1-2 minutes?), or whether to stop using timeslices at all, and move to a more event-driven system. I know that I want characters to move through the mansion at a reasonable rate, but I don’t want the player to have to scroll through 72 data points per witness just to find out where they were during the evening (as would happen if I dropped to five minute increments). That just doesn’t sound like much fun.

It’s very interesting to see that Butler treats its hallways the same as rooms, and has a movement rule that a character can only move one room per timeslice. That makes an awful lot of sense for the way its mansions are laid out, but not so much for the way I’m laying out mine; Butler has a lot of discrete, disconnected short hallways, whereas Spratt has just one long winding hallway that all the rooms adjoin. The more I think about it, the more I think that I’m going to need to make use of the underlying grid pattern, and set some speed with which characters can move. But that’s going to require a bit more thought. It’d be a full rewrite of my current generation algorithm, and so I probably don’t want to do it unless I’m certain.

Anyhow. I’m keeping my eyes on Butler, and am hoping that the author notices and fixes whatever my crash bug turns out to have been. I’d love to get a chance to actually play it!

I took a little break from the murder mystery game today, and instead have been spending time on the VectorStorm renderer. I’ve added the ability to switch between additive mode (the way that vector graphic displays traditionally have rendered in the past), and opaque mode (the way that raster graphic displays traditionally have rendered in the past). This basically means that it’s now possible to fully obscure something that you’ve drawn earlier in the frame, rather than just drawing straight over it, further brightening the display.

The shot here is of the mystery game; the new thing is that there’s a 90% opaque black background behind the timeline interface at the top of the screen, which makes it much easier to read when the camera has moved in such a way that the timeline interface is overlapping with the mansion graphics. But you can still see the brighter lines from under that background.

(You’ll also notice that I’ve avoided taking any screenshots where the zoomed Mansion graphics overlapped the timeline interface up until now — that situation was pretty ugly, before!)

And while I’m here, I’ll just mention.. in many of my recent screenshots, you may have noticed the little green and red bar at the bottom left of the screen, which don’t show up in the released builds I’ve put up on the site. Unless you’ve grabbed the source code and had a play with it, you’re probably wondering what that coloured bar is all about.

Well, that bar is actually a standard VectorStorm thing during development; it displays timing information. The horizontal bar has three segments; first is blue (CPU update time — not visible in this shot), then green (virtual machine GPU time), and then red (OpenGL time; or in other words, real GPU time). If the horizontal bar reaches the first vertical blue line, then the game is running at 60fps. If it reaches the second, it’s running at 30fps. If it doesn’t stop at either of those vertical lines, then it probably means that you’ve told your 3D driver not to wait for vsync even if the game has specifically requested it do so, you mean person.  (That won’t cause problems;  it’ll just make VectorStorm games consume a lot more of your computing resources as they try to render as many frames as possible, instead of waiting for your video card to actually be ready to draw a new frame to screen)

So I’ve been doing some more work on Nicholas Spratt today. It’s mostly been housekeeping, trying to clean up some of the uglier things that went in during the last few hours of development in the “Game in a Week” version. But I’ve begun modifying the mansion rendering and camera behaviour in preparation for allowing the player to actually walk around within the mansion, questioning suspects who will have been separated into the different rooms of the mansion.

You can see that compared to the “Game in a Week” version, the camera is much closer in to the action, and there’s a soft gradient given to the floors, hinting at the grid pattern underneath (which will become integral to the mystery, in the next revision of the game).

My current thinking is that in the next version, the hallways will become locations just like the rooms were in the last one, and guests will be able to see each other if their view is unobstructed. Guest movement will still not really take geography into account, except in terms of who they’re able to see. Visually, when the player is examining a suspect’s testimony, the character will actually travel from place to place using simple pathfinding (probably copied directly from the “meat” pathfinding I wrote for Muncher’s Labyrinth), but that will probably be purely visual.

Of course, there will also be huge improvements to the murder mystery generation algorithm. But that’s a topic for a different post.

In part one, I said that I was going to focus on awesome gameplay, as opposed to awesome graphics or sound or etc.  And since awesome gameplay rests on having an interesting and unusual gameplay mechanic, this means that we need to think about ideas.

It’s often said that in the game industry that ideas are a dime a dozen;  they’re virtually worthless on their own.  And to a certain extent, this is true.  In terms of time and manpower, implementation details are far more costly and make a far greater impact in the bottom line;  that is, whether or not a game is good.

People say this because there is no shortage of good or even great ideas. Brainstorm for a minute or two and anybody even vaguely familiar with the gaming industry can generate a dozen or more, just by copying and recombining elements of existing games in a slightly new way.

But if our goal is to make an awesome game — not just a good or popular one (and let’s not kid ourselves;  awesome games frequently do not do well in the market, despite rave reviews) — then we need an awesome idea to start with.  I’m going to assert that the difference between a good game and an awesome game rests entirely in the quality of the initial idea.

(I’ll also assert that the difference between a good game and a great game is entirely unrelated to the core idea.  And since great games sell better than awesome games, most game makers don’t even attempt to make awesome games — awesome games usually require a lot more work, and usually earn a lot less!)

So what separates a good idea from an awesome one, and how can you distinguish between them?  More beneath the fold.
Continue reading “How to design an awesome game, part two : Ideas are a dime a dozen”

Just a quick note to everyone that I’ve just modified the RSS feed to act like the front page of the web site;  it now displays the same amount of story as is displayed on the front page, instead of being truncated at a ridiculously short length.

It also adds a single line footer with Copyright and other information about the post.  Unfortunately, this means that those reading via an RSS reader will have all those old posts they’ve already read showing up as ‘unread’ again.  Sorry about that, guys!  Mark them all as read, and I’ll try not to change the footer format again. 

I’ve been thinking more and more about adding network classes to the VectorStorm library, and I expect that I’ll do so sometime within the next few days.

However, there’s always a risk involved when doing networked games in an open-source game; it makes it really easy for people to cheat. Just modify your copy of the game to make you faster or invulnerable or whatever, and you can basically do whatever you want. And I’d really rather not have that problem.

Thinking it over, I’ve made a list of things that I want to somehow allow and disallow:

• I want people to be able to play against each other in networked games.
• I want people to be able to modify games I’ve written, and play against other people who are also using those modified games, but not to be able to play against people using different modified games.
• I don’t want anyone who’s using a modified game to be able to access the official Leaderboards.
• I do absolutely want to stand by my “everyone should be able to see and learn from or improve upon this code if they wish” policy that I’ve been using so far, and so all of the code must be visible in the code repository, under the same GPLv3 license as the rest of VectorStorm.

(If you disagree with any of the above, or have additional policies to suggest, I’d love to hear from you in the comments!)

My initial feeling is that I’ll need to incorporate cryptography into VectorStorm. I’ll probably use libtomcrypt rather than OpenSSL, just because I’ve used libtomcrypt before and found it to be much easier to work with, and very cross-platform. I’ll embed some data into the binary network-enabled games on this site, to make them “blessed” builds, and only allow the “blessed” builds to talk to an eventual leaderboard network server, to dissuade cheaters from corrupting them.

And I’m not completely certain whether using “blessed builds” to lock out access to the leaderboards is actually an allowed thing to do under the GPLv3’s section 6 (often called the “anti-tivoization” clause). I’m pretty certain that it’ll be fine since it won’t actually stop the user from making modifications and playing with them, but I’ll need to consult with the GNU guys to make absolutely sure before I do anything in that direction.

Well, it’s a few days late, but I finally got to the game design musings. In the interest of the common good, I’m going to try to lay down some simple and easy principles that show how to design an awesome game. This first article discusses some basic types of Awesomeness, in an effort to work out a more reliable system to develop great games.

Of course, the easiest way to create an awesome game is to already have an awesome game, and to just make a sequel which is exactly like the original, only more so (God of War 2, Halo 2, Guitar Hero 2, etc). Or alternately, to make a game which is exactly like somebody else’s awesome game, only more so (Duke Nukem 3D, Rock Band, etc).

It’s interesting to notice that both Guitar Hero 3 and Rock Band were attempting to make something like Guitar Hero 2, only more so, but ended up with very different offerings; The Guitar Hero 3 developers said “What’s awesome about Guitar Hero 2?”, came up with the answer of “the music tracks” (Awesome Music, below), and so decided that “the same thing but more” meant adding more tracks, whereas the Rock Band guys said “What’s awesome about Guitar Hero 2?”, came up with the answer of “the guitar controller” (Awesome Gimmick, below), and so decided that “the same thing but more” meant adding more types of instrument controllers.

Being able to spot the quality in an awesome game which actually makes it awesome is very, very important (and is often also surprisingly difficult)! And you need to keep an open mind. As software people, we’re generally biased toward seeing the awesome part as being something in the software, when it very well might not be. In fact, many extremely popular games are awesome for reasons which have very little to do with the game mechanics themselves. But I’m getting ahead of myself.

Let’s assume that we’re not going to rip off an existing awesome game, and must instead start from scratch with our own, original game design, and that the only constraint on our design is that it must be Awesome.

So where do we start? More beneath the fold.

Continue reading “How to design an awesome game, Part One”