Category: Game Design

Quake 4

November 30, 2005
Game DesignGames
0 Comment

I just played the Quake 4 single player demo.

If this were an SAT test, you could sum up Quake 4 as

Quake 4 : Quake 2 :: Doom 3 : Doom 2

Basically, Quake 4 is Quake 2 prettified and given a new situation. You’ll even fight some of the same enemies from Quake 2 early on in 4.

This makes me sad, because the original Quake remains my favorite in the Quake series. I enjoyed the fact that the game jumped back and forth between military installations and gothic castles – it felt like you were jumping between two realities, ours and another that was attempting to take over. I am aware that this was because the Id guys never really finalized a design for the game, but I still liked it. I’d like to see a more direct sequel to the original Quake, perhaps with a feature where levels morph from realistic to fantastic and back while the player is running through them.

40 Hour RPG (Take 2)

October 14, 2005
Game DesignGame ProgrammingInaria
1 Comment

Well, things have kind of slacked off a bit…

Oh, so Hit & Myth shipped?

No, it’s kind of in limbo…

Really? What’s all that about then?

It’s part of the Story I Can’t Tell Yet, which hopefully I’ll be able to tell soon.

You cop-out! Tell us what’s going on right now with Hit & Myth!

Look, this post isn’t about Hit & Myth, okay? It’s about me trying again to make an RPG in 40 hours. I learned a lot last time, and I hope I’ll learn even more this time.

Unfortunately, what I learned was this: making an RPG of the kind I’d really like to make in 40 hours is nigh-impossible.

I could write a completely text-based engine that allows the player to buy equipment, go down into a “dungeon” which was basically one room with progressively harder monsters, fight them, level up, and come back up to buy new equipment. I could certainly do this in 40 hours. (Heck, I might be able to do it in ten.) But that’s not really an RPG; it’s just an RPG combat/advancement engine.

I could write a game very similar to the above, except that, instead of a text-based one-room “dungeon” I could create a randomly created dungeon level that the player could explore. His job would be to go in, kill everything and then come back up to get better equipment. He could then re-enter the dungeon, which would give him a new randomly-created level to explore. Basically, a very simple quick-and-dirty Roguelike. I might be able to pull that off in 40 hours; the real question is how long it would take to figure out (or research) how to randomly generate a dungeon level. This is basically what Jay Barnson did when he made his 40-hour RPG.

Or I could write a game with an overworld, towns and dungeons, with NPCs that you can talk to and can give you quests, an inventory that allows you to keep and store quest items, and an overarching plot for the game where you end up saving the world at the end.

This is what I tried last time, and you just can’t make that kind of RPG in 40 hours. But that’s the kind of RPG I want to make…

So I’ve got a choice – either scale back my game or give myself more than 40 hours. I think I might be able to write a simple RPG of the style I want in 80 hours…

I’ll have to think about this.

The Non-Update Update

August 19, 2005
Game DesignGame ProgrammingThe Game Biz
0 Comment

Lots of stuff has happened involving Gizmondo (the company), the Gizmondo hardware platform, Gizmondo Texas, and me personally.

Unfortunately, the story isn’t over, so I can’t really tell it yet.

All I can say is that we’re working hard on Hit & Myth (like we have been for months) and we are planning to submit our first gold candidate sometime next week. I really like how the game ended up – it’s fun and funny, and should be a good time for anyone who buys it.

Deconstructing RPGs

August 18, 2005
Game Design
0 Comment

This may be kind of stream-of-consciousness, but I was thinking about how RPGs (especially Japanese console RPGs) are structured.

First, there’s the tutorial area. This area is designed to give the player a chance to get used to the game mechanics. The player usually isn’t in a lot of danger in this area, and typically can’t leave until they’ve accomplished the quests in this area (and the quests are designed to “prove” to the game that the player understands the basic mechanics).

Then the player leaves the tutorial area. Typically, this is when the player encounters the game’s villain for the first time. This is done so that the player can understand the nature of the threat he is up against. Sometimes the player will be forced to fight the villain, and will lose. If this happens, the villain won’t kill the player. Better games find better ways to demonstrate the villain’s power level without putting the player into direct conflict with the villain at this time (Final Fantasy VII’s flashback where the player plays alongside Sephiroth comes to mind).

Once the initial confrontation with the villain is over, the Journey begins. The player cannot go directly to the final confrontation with the villain, typically because the villain does not even exist in the gamespace at this point. Instead, the player travels from area to area in the game world. In each area the player meets new and different people with new and different problems, problems that have typically been caused by the villain. Thus, the player sees the villain’s malice firsthand and tries to undo as much of it as he can. He is rewarded for this with an increase in his power level. The game usually forces the player to explore every area of the game world before allowing him to proceed to the final confrontation with the villain.

In order to defeat the final villain, the player usually needs two things: a “key” object that either allows the player to get to the villain or makes the villain vulnerable, and an appropriate power level so that the player can survive the actual battle. Once the player defeats the villain the game is over, though some games allow the player to continue to play and see how his actions have affected the game world.

That, in a nutshell, is how an RPG’s gameplay is typically structured.

AP

August 5, 2005
Game DesignGames
2 Comments

Speaking of turn-based strategy, today I’d like to talk about combat-oriented turn-based strategy games, specifically games that use the action point (AP) system.

In these games, you control a small group of individual units (usually soldiers). Each unit is rated differently in various categories like weapon skill, speed, hitpoints, etc. The players (or the player and the computer) take turns, and on a player’s turn he gets to move all his pieces based on how much AP they have. Typically one AP will move a unit one square or hex on the map, so units with more AP will move across the map faster. They may also be able to make more attacks in combat because each attack typically costs a set amount of AP. Some examples of these games are the Jagged Alliance series of games, the Front Mission series, the Final Fantasy Tactics series, and the X-COM series.

So, where did the AP system come from? Who first invented it?

If you trace the roots of these games, they all come back to the same parent. Readers with a knowledge of game history are probably nodding and saying, “Yep – they all come back to X-COM!” But the roots go deeper than that. While X-COM was the first tactical combat game to be a big hit, it wasn’t the first, by a mile.

You see, several years before Julian Gallop designed X-COM, he designed a little game for the ZX Spectrum called Laser Squad. (Shall I mention yet again how much we missed out because the Spectrum didn’t go over well here in the States?) Anyone who plays Laser Squad will instantly recognize it as an X-COM prototype. So Julian invented the AP system, right?

Nope. Laser Squad was basically just a computerized version of one of Julian’s favorite board games – a game very few people have heard of, called Snapshot. Snapshot (and its sequel, Azhanti High Lightning) were actually boardgame supplements to the Traveller series of science fiction roleplaying games. They were designed to be broken out whenever the party of Traveller adventurers boarded some derelict alien spacecraft, so that any ensuing combat could be played out in boardgame fashion. Julian programmed it in and created some custom scenarios for it and created Laser Squad (and its sequel, Rebelstar). And in doing so he invented the computerized AP-based tactical combat game.

Well, now that I’ve expressed my appreciation and documented some of the history of these games, I’m going to talk about the two biggest problems these games have. The two problems are related, and both stem from the boardgame roots of these games.

The first problem is, what do you do with units that still have AP at the end of their turn?

The second problem is that having one side move all its units, then the other side move all its units brings up some very unrealistic results. In both Snapshot and Azhanti High Lightning, if you had a unit with enough AP he could step out from behind a corner, fire his weapon up to three times, and then retreat back behind the corner without any opponents being able to do anything. And guess what, you can sometimes do the same thing in Jagged Alliance 2.

Designers have fought these two problems in various ways. Fallout, for instance, kept the total number of AP you had to spend on a turn very low (ten was the highest, if I remember correctly), and then added the number of unused AP you had at the end of your turn to your armor class, thus making you harder to hit. This wasn’t bad, but in Fallout you only controlled one character. The same system wasn’t as effective when you used it for a whole group, as Fallout Tactics proved.

Both the Front Mission and the Jagged Alliance series fought this problem with interrupts or counterattacks, which were cases under which you could spend your units’ AP on your opponent’s turn. But in both cases, your units needed a lot of AP to be able to interrupt, and in the case of Jagged Alliance they also had to make a perception roll just to get the interrupt.

Most recently, Front Mission 4 tried a different tactic – allowing units to be linked together by the player. Therefore, if one unit attacks, all linked units with AP attack, and if one unit counterattacks, all linked units with AP join in the counterattack. It’s too confusing, and improperly linking your units will cause them to waste AP. But in the end it was just another attempt by designers to find a way to allow all units to use all their AP on every turn.

So what’s the solution?

Well, it doesn’t appear that there is “a” solution. One solution is to allow all units to move in the order of their speed scores. But this has the problem of the double reward – faster units move sooner and get to do more on their move. Okay, then couple it with interrupts…except that this has the effect of making combat feel very choppy; a character will barely get started doing their thing before somebody else gets to butt in. This is realistic, but may not be that playable.

What I’d like to try is creating a system where everyone moves simultaneously. When one of your units needs input, the game pauses, allowing you to give that input – but the input isn’t acted on until the game unpauses, at which point everybody starts moving again. Combat might not be broken up so badly because you could tell a unit, “Run over here to the other side of the map” and that unit won’t require any new orders until he gets there. You could also tell a unit, “Fire at this enemy using aimed headshots until he is dead” and that unit also won’t require additional orders until his situation changes. I’ll need to prototype this to see if I can get it to work.

Basically, although the boardgame roots of this series have served us well, it’s time to discard them and truly use the new medium of the computer to transcend the previous games in this genre.

Iron GameDev

August 2, 2005
Cool PeopleGame DesignGame ProgrammingGames
3 Comments

Voiceover: One year ago, a man’s fantasy became reality in a form never seen before: Coding Stadium. The motivation for spending his fortune to create Coding Stadium was to inspire innovation in game development, and observe the making of games which could be called true artistic creations.

To realize his dream, he sent invitations to the top men and women in the field of game development, challenging them to claim the title of Iron GameDev. The challengers have just forty-eight hours to create a complete game from start to finish. Using all their skills, senses and creativity, they are to create games never experienced before!

And if they emerge victorious, they will claim the title of Iron GameDev and receive the people’s ovation and fame forever! Every battle, reputations are on the line, where master game developers pit their artistic creations against each other. The heat will be on!

Chairman Kaga: If I recall correctly, it was just one year ago that, having experienced fifteen years worth of exquisite cuisine, my palate became bored and I turned my attention to that other obsession of my people: video games! My mind began to turn as I imagined how I might be able to do for the development of games what my Kitchen Stadium had done for cuisine, and I realized that a similar format might produce similar results. Thus, this is our first battle in Coding Stadium. The format of the competition is simple – using provided computers and resources, two teams of three developers each will have only forty-eight consecutive hours to produce new games that I have never experienced before.

Now it is time to introduce the teams that will compete for the title of Iron GameDev. I could not be more pleased with the response I received from the game industry, and I have two superb teams today.

I present to you…TEAM ENSEMBLE!

(The curtain rises and smoke billows out, obscuring the forms of three men. They are ROB FERMIER, SANDY PETERSON and LANCE HOKE. They step forward and cross their arms.)

Chairman Kaga: Rob Fermier, programmer on System Shock and lead programmer of Age of Mythology. Sandy Peterson, designer of the Call of Cthulhu role-playing game, designer on Doom, designer on Quake, and designer on all three of the Age series of games. Lance Hoke, lead artist of Age of Mythology. They will represent Ensemble Studios in this battle. They are worthy warriors, with many excellent games under their belts. They deserve a worthy opponent, and I believe I have found one.

I present…TEAM BLIZZARD!

(The right curtain rises and three men step out of the backlit smoke. They are ANDY BOND, ROB PARDO and SAM DIDIER.)

Chairman Kaga: Andy Bond, programmer on Diablo II, Warcraft III, and World of Warcraft. Rob Pardo, designer on Warcraft II, StarCraft, Warcraft III and World of Warcraft. Sam Didier, the artist who came up with Warcraft’s unique look. These men will represent Blizzard.

Fukui-San: And now let’s introduce today’s judges. In the first chair we have Richard Garriott, founder of Origin Systems and creator of the Ultima series of games.

Richard Garriott: Great to be here.

Fukui-San: In the second chair we have Alex Seropian, one of the founders of Bungie.

Alex Seropian: It’s an honor to be here.

Fukui-San: And in the third we have Chris Taylor, founder of Cavedog and creator of Total Annihilation.

Chris Taylor: I’ve really been looking forward to this.

Fukui-San: Gentlemen, welcome to GameDev Stadium! I’d say there’s just as much talent up here as there is down there; you guys could form a team of your own!

Richard, Alex and Chris: (LAUGHTER)

Fukui-San: And of course, our commentator, Dr. Yukio Hattori.

Hattori-San: Always a pleasure.

Fukui-San: Doc, the change in format here has been dramatic! Since this is our first battle in Coding Stadium, let’s go over what the new competition entails.

Hattori-San: Very well. Instead of choosing a stable of game developers, like he did Iron Chefs, the Chairman has chosen to invite game development companies to send teams of three people each to compete in the stadium. We recommend a mix of one coder, one designer and one artist, but the actual makeup of the team is up to the company.

We have outfitted the stadium with three identical computers for each team, each preloaded with an identical loadout of the most popular compilers, 3D modeling software, image processing software, music creation software and level editors. The developers must use what is on the machines – they are not allowed to bring in anything from the outside. Nor will they be allowed internet access for the duration of the battle.

Since the competition takes so long, we have also provided places for the teams to eat, sleep, watch TV and play video games. Once the competition is over and the winner has been announced, both games, along with their sources, will be available on the internet.

And yes, the teams will be given a theme for their games by the Chairman that they must follow.

Fukui-San: That sounds fantastic, but I gotta ask: with so little time, won’t the developers just come up with derivative games using tried-and-true mechanics?

Hattori-San: Well, that’s always a risk, just like it was in Kitchen Stadium, but the Chairman is hoping that the severe time limit will force developers to boil their games down to their essences, allowing the purest form of the art to shine through – as often happened in Kitchen Stadium. Okay, the Chairman is ready to announce today’s theme.

Chairman Kaga: I thought long and hard about today’s theme. Both of your companies specialize in real-time strategy games, so it was my initial decision to give you something completely unrelated, like first-person shooters. But that would have been…too obvious. I finally decided on a theme related to your specialities, but with its own quirks. Today’s theme is…TURN-BASED STRATEGY!

(DRAMATIC MUSIC plays. The members of both teams look SHOCKED.)

Fukui-San: All right, a definite change of pace in the battle today, the Chairman choosing turn-based strategy as the theme, the teams are in place, let’s get it on!

Chairman Kaga: ALLEZ FONT DES JEUX!

And then I wake up 🙁

Something’s Percolating

June 20, 2005
Game DesignGame ProgrammingGames
0 Comment

My brain is chewing over several things, and I think I’m going to end up coming to some sort of realization about the game industry, like I did in my Innovate post. But I don’t know what it is yet. So I’m kind of going to write down all the various bits that are coming together…just to kind of get my thoughts straight. Perhaps as I write, the realization will come to me.

First, I recently watched Scratch, an excellent documentary about the birth of hip-hop. I’ve also been reading Jeff Minter‘s History of Llamasoft series of articles over at Way of the Rodent, and I can’t help but notice parallels. In both cases, a small group of young men are presented with a new artistic medium and start using this medium to do “cool stuff” for their own enjoyment and to impress their friends (often to the chagrin of their parents), with no thought whatsoever that what they are doing might actually be profitable…and accidentally create a billion-dollar industry.

Second, I’ve been listening to the absolute hysterics surrounding the unveiling of the new consoles, as developers cry, “My god, these boxes are so powerful that we’re going to have to invent TIME TRAVEL in order to make games for them!” Please. Not every game has to look like that (obviously pre-rendered) Killzone 2 movie in order to succeed. I mean, the GTA games are still using RenderWare, for crying out loud, and they were outstanding successes.

Third, I’ve been thinking about the Golden Age. Ask just about any game developer and they’ll tell you that the golden age of PC gaming was about ten to fifteen years ago. But why then? Why not before then, or after then?

There were two converging factors that make 1990-1995 the “Golden Age”: barriers to entry and player expectations.

In the 1980’s, there were really only two ways to get into the game industry: learn assembly language for a popular computer and write the game yourself, or get hired by Atari, Mattel, Coleco, or one of the other first-generation console companies. Needless to say, doing either of these was damn hard, which kept the number of game developers low. But towards the end of the 80’s, the PC revolution was driving the price of hardware down, and Borland was coming out with excellent, inexpensive compilers, which meant that games could easily be written in C on the cheap. Thus, the number of game developers rose.

On the other hand, ALL games were written for a VGA screen – 320×200, 256 colors. Real, polygonal 3D was a novelty used by flight sims that were only played by hardcore sim fanatics willing to put up with 5-10 frames a second. Making content for such a setup wasn’t that hard and didn’t take that much time. Player expectations could still be fulfilled with a small team in a few months (or heck, even one talented programmer/artist). We went from high cost to entry and low player expectations to low cost to entry and still reasonably low player expectations. Thus, the Golden Age.

And then Quake came out.

I think I am only now beginning to truly understand the impact Quake had on the game industry. Yes, it made first-person shooters even more popular and spawned a hojillion imitators. Yes, it made mods easy and fun to make, creating the mod scene. Yes, it made internet play easy and fun. All this I’ve covered before.

But what Quake really did was raise player expectations through the roof. We players were very forgiving of 2D games; we were aware of the limitations of that system and thus we didn’t complain when Link’s sword mysteriously changed hands as you moved him around. Suddenly we could move around a 3D space and interact with 3D entities, and since we live in a 3D space and continually interact with real 3D entities, we know how that is supposed to look and feel, and thus billions of dollars have been spent by hardware and software developers in an effort to bring the look and feel of their 3D games closer to reality, so that player expectations can be fulfilled. And so we have the Killzone 2 movie.

(Oddly enough, almost all players have no problem falling back into “2D mode”, even now, lowering their expectations when they play a 2D game. And they do it without even realizing it. The same thing happens when we watch an animated movie as opposed to a live-action movie.)

And now we’re spending so much time making sure our in-game characters have smooth transition animations between sitting, standing, walking, running, leaning, fidgeting, idling, talking and dying that we can’t seem to spare any time to make sure they don’t run into walls – or enemy gunfire.

Is this bad?

I think it just “is”. There wasn’t any getting around it; somebody was going to do it. And yes, we are in for some growing pains as we figure our way around this new hardware.

But there really isn’t anywhere to go from here. Graphics are quickly topping out (and may already have). Both CPUs and GPUs are showing diminishing returns. Eventually all the really hard stuff we have to do right now will be handled by middleware.

What do we do then?

(Jeez. I just realized that all I’ve done is reiterated Jason Rubin’s main point from his GDC talk a few years ago. Of course, that doesn’t make me (or him) wrong.)

Game developers will have to turn back to the other, neglected fields of game development in order to set their games apart. Perhaps we will finally get an RPG that is better than Ultima VII in the world modelling department. Perhaps we will finally get a first-person shooter that has AI demonstrably better than Half-Life‘s. Perhaps we will finally get an RTS that is truly better than Starcraft, Total Annihilation or Age of Kings.

Instead of panicking and screaming about the “death of innovation”, I’m looking forward to a new Golden Age.

Hit & Myth

May 25, 2005
Cool PeopleGame DesignGame ProgrammingGames
0 Comment

Now that E3 is over, I can finally talk about my game. It’s called Hit & Myth, and it’s the brainchild of two talented people I’m working with.

The first is Ryan Clark, who created the basic engine for the game and also came up with a technique that allows us to get some realistic-looking lighting very cheaply. It allows us to get content in the game quickly, and you can read all about the technique at his webpage, Zarria.net.

The second is Wynne McLaughlin, the lead designer, who has been writing for games and TV for years. He got this job by creating a couple of very good Neverwinter Nights modules. Wynne is adding a really funny, sarcastic sense to the game, as evidenced by this screenshot.

Me? I’m the secondary coder (and we also have one more coder/designer named John Sripan). We also have a bunch of great artists on the project (as the screenshots should attest).

The game uses Robotron/Smash TV mechanics – the left pad moves your character and the right buttons control the fire direction. There’s tons of weapon pickups that make you more powerful, and you can cast spells (we have a nice spellcasting mechanic that allows you to cast spells very quickly once you get used to it). Basically, you run through the levels, shooting everything that moves, until you get to the boss, which says something snarky and then tries to eat you. So you kill the boss, too.

Now, I’m fully aware that I’m not working on a Game of the Year here. I’m also aware that the platform the game is for is new and shaky and has a lot of competition. But in the end, the game is going to be a whole lot of cheap, blasty fun and I hope that the people who do buy it get a kick out of it (and oddly enough, Ryan recently said almost exactly the same thing to me).

My Latest Project

May 18, 2005
Game DesignGame ProgrammingGamesInariaSelf-Improvement
0 Comment

Okay, purely for my own edification, I intend to write an RPG in 40 hours.

I was, of course, inspired by this blog post, and also by the fact that I really, really wanted to participate in the most recent Ludum Dare challenge, but couldn’t. So I’m sort of doing it on my own. Now you know why I was researching Roguelikes; 40 hours is too short to do just about anything graphical. Text mode will allow me to get the most out of my time.

Here’s the rules:

1. This will be a project created in Visual Studio .NET, using C++. It will be a console application, and it should run on both Win2K and Win9x.

2. The timer starts when I first create the project (which I haven’t yet).

3. Since I am a father of three and employed full-time, I can’t do something stupid like work on this for 40 hours straight. Instead, I will work on it whenever I have time, rigorously keeping track of my time. When the 40 hours is up, I will post whatever I’ve got, even if it’s not playable (though I will do my best to make sure that it is).

4. Time designing, coding and creating content counts against my 40 hours; time thinking about the project and writing blog entries about its progress do not. Thus, I can do some “mental preproduction” work on it as long as I don’t code anything or write any design down.

5. Failsafe. I have 40 hours to do this project, and I can spread them as thin as I want, but if the project is not done within 30 days (that is, it is not done by midnight, June 18th, 2005) the rest of my time is forfeited and I must post what I have.

Currently my thinking is that I will break the project up into two 20-hour chunks – one for coding the engine and one for creating content that runs on the engine. This should (note the word “should”) ensure that I ship something a bit more robust than just a hack & slash engine. My fears are that I will either overestimate the difficulty of the project and set my sights too low, resulting in a completed game so simplictic that no one wants to play it, or that I will conversely bite off far more than I can chew, resulting in no functioning game at all.

Oooh, this is going to be fun. I think.

Roguelikes

May 18, 2005
Game DesignGame ProgrammingGames
0 Comment

I’ve had a real love/hate relationship with Roguelikes. (Quick definition if you don’t want to follow that link: a Roguelike is a turn-based RPG with a map that is usually constructed from the ASCII character set. They derive their name from Rogue, the first game of this type on record.) The thing is, now that I’ve thought about it, most of the advantages of a Roguelike are inherent, and most of the things I don’t like about them are a part of how they’ve been constructed.

The main advantage of Roguelikes is that while they do have a map, they are not rigorously representational. They inherit this from text adventures. If you want the player to be attacked by a gorgeous bird with a six-foot wingspan, a pearl beak, feathers that shift colors as it moves, and glowing white eyes, you can simply put a B on the screen (or whatever letter or symbol you decide represents “birds”) and say, “You see a gorgeous bird with a six-foot wingspan, a pearl beak, feathers that shift colors as it moves, and glowing white eyes.” This takes all of 30 seconds, unlike the two weeks actually creating such a bird in a 3D game would take.

This also means that you can code tons of interactions that can only exist in text. Sure, let the player wield lockpicks or dead monster bodies as weapons! Let the player drink from fountains, fill canteens from fountains, dip swords from fountains, kick fountains! Let them wear hats on their feet! It’s all just text! You’re not required for it to make any visual sense!

Another way Roguelikes aren’t rigorously representational is that the player is not bound to any sort of normal walking speed. A square on a Roguelike map typically represents six to ten square feet, and you move by jumping from one square to another (and typically you can move as fast as you can press a key). Thus, it doesn’t take long to get places in a Roguelike.

So Roguelikes can avoid lots of the annoyances of modern RPGs and stimulate the imagination, at the cost of a lack of visual…impact. What are the downsides?

Like I said, most of the downsides of Roguelikes I’ve played stem from how they are implemented, not the style itself. Roguelikes are typically arbitrary, difficult and frustrating, but that’s only because that’s how they’ve been programmed. One true downside of Roguelikes is that the user will have to constantly refer back to the manual or a cheatsheet to figure out exactly what symbol means what on the screen, but this can, perhaps, be minimized.

So why exactly am I analyzing Roguelikes? Ah, see the next post.