VectorStorm Blog

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”