It's not the design, it's the details.

2007, October 19th 4:47 PM

It's honestly amazing how many little fiddly things show up when you start trying to do reasonable PR.

See, first off, I've submitted my game to the IGF – the Independent Games Festival. For those who don't yet know, it's called Devastation Net, and it's designed for a lot of players to blow each other up using tanks, played on a projector. It's nowhere near finished (it has no single-player capabilities, for example), but it's fun and is making huge progress.

However, this brings up a few more issues. The IGF requires a website (and, honestly, even if it didn't require one, I'd provide one.) In theory, people might visit this website from links. And that's cool. Visitors are good. Traffic is good. But this all means I need to finally unearth my company website and make it vaguely palatable. And that means, once I have that up, that I can't just let it rest. I have to post once in a while, otherwise it dies and there goes all the goodwill I've gathered.

And that means I need to make my dev journal functional, and I need to make sure the site and link structure stay sane so I can start accumulating pagerank and Google love, and hopefully draw more readers – which means a lot of fiddly server issues, like making sure that https://www.mandible.net and http://mandible.net not only both work but one actually redirects to the other so I can keep consistent single URLs. And it involves setting up some kind of 404 tracking so I can pin down future issues that might occur, and planning properly so I don't end up needing a new URL structure and wasting all the search-engine-fu I've built up, and blah blah blah oh god the pain.

In some ways having worked at Google helps in that I know what sort of things to watch out for ("someone help, all my google pagerank went away overnight! I mean all I did was move a few pages around and change the entire directory structure of my site, and also I installed a new content manager and completely changed all the content and the look, and I changed domains too and the old one is down because the server's crashed, but Google should somehow know that this happened and give me the same pagerank!") but it also makes things tougher because I really don't have any excuses if I fuck it up.

Oh well. Here goes. Let's see how many days it takes before I irrevocably break someone's links.

So. Hi. I'm Zorba. I'm starting a game studio named Mandible Games. I'm making a game called Devastation Net, which I'll be posting more about in the future. It's a pretty huge experiment, but it's what I want to do – so, here we are. Hope you enjoy reading.

Sometimes I feel like I spend all my time grumbling about badly-designed games. The reason for this is the unfortunately inevitable unavoidable Sturgeon's Law: 90% of anything is crap. And it's true. 90% of all games are crap, just like 90% of all movies are crap or 90% of all books are crap.

That's not to say all games are crap, of course. There are always gems, and there are companies which are absolutely brilliant at putting out consistent gems.

The two companies that impress me the most, that consistently release high-quality and polished products, are Blizzard and Valve. It's worth comparing them, because their design styles are very, very different.

Valve is one of the more interesting game companies out right now. They're possibly the youngest of the known-by-name game studio behemoths, as they date back merely to 1998. They also had a truly astonishing start, releasing Half-Life as their very first game to incredible reviews. From 2002 to 2005 they were involved in a complex legal battle over publishing, which they won, and much of Valve's games are now distributed over the Steam Network – an online distribution system, designed, written, and run by Valve, with over 200 games now available (the vast majority of which were not developed by Valve).

Blizzard is one of, if not the, most well-known game company in the world. It dates back as far as 1991, and its first hit (and its fifth release) was Warcraft. Blizzard, along with the ill-fated Westwood, is credited with essentially inventing the realtime strategy genre. Warcraft was turned into a franchise thanks to the rapid release of Warcraft II. Within a few years Blizzard had released Diablo and Starcraft, spawning another pair of successful franchises. Today they are undoubtably known best for World of Warcraft, the MMORPG with the most subscribers by a huge margin (an estimated factor of four over the second-largest, and approximately the same subscriber count as the entire rest of the MMORPG market added together.)

It's worth noting that Valve is actually the same age as Blizzard's youngest franchise, Starcraft – and is two years younger, if you count Starcraft as a Warcraft spinoff. Every single game released by Blizzard since 1998 has been a sequel, expansion pack, or spinoff. While Valve is best known and most concerned with their Half-Life series, they now also produce the Counter-Strike and Team Fortress serieses, as well as the standalone Day of Defeat. While all of these started as Half-Life mods, none of them are related to Half-Life in any way beyond the engine.

Blizzard succeeds for two major, extremely important reasons. Their games are carefully balanced, and they polish more than any other studio on the planet. While no modern games are bugfree on the day of release, Blizzard succeeds far better than any others do – their games are invariably smooth-running, functional, and fun, even version 1.0. World of Warcraft's original launch was probably the rockiest launch Blizzard has had in a decade, and despite being Blizzard's first MMORPG, with astronomically more success than Blizzard had ever expected, it was still the smoothest MMORPG launch in history up to that date. Think about what that says – despite abnormal stressful circumstances, they still did better than anyone else ever had.

On top of that, World of Warcraft is simply a well-built game. The interface, while not perfect, certainly takes long strides towards that state. Quests are easy to find, combat is simple to understand, leveling is not too difficult but also not too easy, both mistakes that other games have made. Blizzard has been very careful to ensure that there's always something for you to do – it learned many lessons with Diablo and Diablo II, which could be considered single-player MMORPGs, and those lessons have been well-applied. No matter where you are in the game, there's always one more quest, one more equipment upgrade, and for the majority of players there's also one more level.

Valve is a grittier company in some ways. They are often not as polished as Blizzard – while they're making great strides, they've had extremely rocky game launches. Half-Life 2, in many ways their flagship game, had quite a few curious bugs on release – to say nothing of the total repeated collapse of Steam under the load, making Half-Life 2 impossible to play and antagonizing a large number of gamers. (While World of Warcraft had similar issues, it's worth noting that WoW is actually an online game, while Half-Life 2 largely isn't. Despite this, Half-Life 2 required that Steam be running.) Their gameplay tends to be somewhat esoteric – it's quite possible in Half-Life games to get "stuck" and have to consult a walkthrough.

Valve does make truly beautiful games. They don't always push the bounds of technology too far, but their games always compare to the state-of-the-art favorably, at the very least. They are always pushing the bounds of what AI can achieve and pushing the bounds of plot and character development in video games. And those are bounds that aren't easy to push – they're stealing pages from movies, stealing pages from improvisation and theatre, and still ending up writing a good chunk of the book themselves. They're probably making the single biggest, most resource-intensive push towards Games As Interactive Fiction in the entire gaming world at the moment.

Most of what I've said here, with both companies, could be applied in reverse to the other company. Blizzard's games are always intuitive. Valve's games are not as polished. Blizzard does not make state-of-the-art beautiful games. Valve sometimes has interface issues. These are simple things.

But the most important, biggest difference, is that Blizzard fundamentally does not innovate. World of Warcraft does not have a single major original gameplay concept in it. Everything has been done before, often many times. Warcraft III has some mildly original gimmicks, but fundamentally Warcraft III is a clear successor to Warcraft II which is a clear successor to Warcraft I which, itself, is pretty much a direct knockoff of Dune 2, with obviously a lot of scenery changed. Blizzard polishes, and Blizzard balances, but if you go to the forefront of modern game research you won't find Blizzard anywhere near it.

(I want to make very clear that this is not an insult to Blizzard. Blizzard makes extremely, extremely good games. Saying that Blizzard does not innovate is a comment on the same level as saying that the Wii is, in terms of sheer performance and graphics quality, a rather anemic console. It's true, but it doesn't mean it's ineffective – it just means they've chosen a different development tactic.)

Meanwhile, Valve . . . well, Valve has just released Portal.

Portal is a curious, curious beast. It originated as a student project named Narbacular Drop (screenshot). You played as a princess who has been captured by a demon and placed within a sentient dungeon, who has the power to make connecting portals open on his walls. The dungeon joins forces with you to defeat the demon and escape.

I don't know the exact details on this, but I've heard that Narbacular Drop was demoed at an event that Gabe Newell attended. Gabe Newell is the co-founder and director of Valve. Apparently, he hired the Narbacular Drop team on the spot, and set them to work on a game titled simply Portal.

Portal is, needless to say, slightly more polished (screenshot). It is also probably one of the most novel and fun games in quite some time. Its gameplay, while absolutely headache-inducing (and motion-sickness-inducing), is extremely fun, and the plot development is nothing short of extraordinary for a game with such a minimal amount of character interaction. On top of that, it feels like more than just a portal puzzle game – many people are already declaring it one of the most satisfying game endings in years, and I'm one of them. The end of the game practically screams "we did this because it was awesome" – they were certainly under no requirement to, and nobody ever would have faulted them for providing a less perfect ending (or, in fact, even realized one was missing.) And yet, they went to the not-insignificant trouble to provide it. (I'm being intentionally vague in order to avoid giving away spoilers. Suffice to say, if you enjoy games, play this one.)

It's also worth mentioning that Portal – this bizarre half-sequel to a student game project – is not only placed in the Half-Life 2 universe, but is integrated with it to an extent where it seems it will have a lasting impact on that universe. This isn't just a standalone tech demo, this is being sold as a complete, albeit short, game – and a truly strange one.

And this is the other fundamental difference beween Blizzard and Valve. Blizzard polishes. Blizzard shines, and buffs, and makes sure every single surface is as smooth and friendly as humanly possible.

Valve sharpens. And then it goes back and draws graffiti.

I've been thinking deeply about ways to classify game studios (there's another entry on this in the future, I imagine) and one of the basic classifications I like is rather simple. "Are the people at this company writing games they want to play?"

I don't honestly know if Blizzard is. They make very good games, but they make lowest-common-denominator games. There are many, many people there, and it would not surprise me if many of them find WoW quite dull. Valve, though? I have absolutely no doubt that everyone on the Portal team was excited about finishing the game. The entire game absolutely exudes dedication and care, in a very different sense from World of Warcraft.

They're both great companies. They both make great games. And Blizzard gets more sales, and makes a truly frightening amount of profit. But I have to say, as someone who wants to see the newest and greatest in game design and concept, I'm always far more interested in whatever Valve is working on.

On good, evil, and reputation

2007, October 7th 7:33 PM

For some reason Fable and KOTOR's reputation systems keep coming up among my group of friends. I personally think those were an interesting try, but ultimately unsuccessful. The problem I have with them is that they come really close, but every once in a while the good/evil system kind of . . . breaks down.

The best example I have is with the beginning of Fable. My friend was playing at the time. There's a wife who tells you to go find her husband. If you find him then come back to tell her where he is, she'll give you a coin. Yay. So you go find him, and he's making out with another girl. He says if you don't tell anyone, he'll give you a coin.

Now, first off, the game is making the assumption that the husband is the bad guy. Second, the game is making the assumption that the husband doesn't deserve his privacy, because he's being the bad guy. I'd argue with both of those (or, at least, argue with it being an obvious assumption), but that's a moral position.

The big issue is that the game assumes your actions are motivated by the results for the participants, and not for cold hard cash. Well, my friend wanted the cash. So he promised he wouldn't tell the wife, and got a coin, and then promptly went and ratted the guy out, and got another coin. Amusingly, grabbing the first coin caused him to become more evil, but the second caused him to become more good – despite the fact that he was playing "I don't care who I hurt, I just want cashola".

The developer can't solve this problem. The only possible "solution" is to quiz the player, at every step, on why they're doing the thing that they're currently doing. And, as entertaining as the idea is, that's not really a solution.

The best fix to this is convenient, because it's actually practical, more realistic, and more interesting. Reputation shouldn't be a global number. It's not a single axis, where priests love you on one side and Hitler loves you on the other. Reputation is a personal thing and a group thing, but not a global thing. Luckily computers are now powerful enough that we can manage this without much trouble at all.

What should have happened is surprisingly simple. Let's assume, for the sake of argument, that the husband is a jerk and that the wife is really in the right. You promise the wife that you'll help her out, and she thinks slightly more of you. You promise the husband that you'll keep his secret, and he thinks a lot more of you. Now you go back and rat him out, the wife thinks a lot more of you (I presume you don't mention "oh yeah I took his money first), but once he finds out – well, the husband hates you.

Now add in communication. The husband probably talks to his friends. He might mention "that kid who ratted me out, after taking my money!" Now they won't like you as much. Now, the husband's friends are probably a bunch of lowlifes, since like attracts like. So now you've got all the scum disliking you. No problem here, right?

The wife is thankful that you helped out. She'll probably mention that to her friends. So now her friends like you a bit (and, incidentally, like the husband quite a lot less – we may as well be thorough here). No problem here either.

But when the two groups meet up and compare notes, if they in fact ever do, they might realize that, okay, so you did tell the truth – but you're also not to be trusted. And neither of them are going to appreciate that – the wife's side, or the husband's side. There's the proper penalty, and it's simply not a single axis.

This isn't even particularly hard to orchestrate. You can simulate it pretty easily by sending "knowledge packets" between characters. Husband knows "kid cannot be trusted", and that knowledge has a chance of duplicating itself every time someone with it interacts with someone else. Wife knows "kid helped me out", and that also has a chance of duplicating on each interaction. Give both of those infopackets some effect on how people think of you ("cannot be trusted" might actually be a good thing in some circles!) and then add in some broad strokes of who-talks-to-who – which can be very simple and vague, to the point of "people in this village tend to talk to each other and people tend to talk to their spouses" and still be effective – and you've got a system where things like that actually can hurt you later on.

Throw in a few ways to assemble text and you're golden. Player talks to NPC, asks for favor, NPC checks its databases and sees it doesn't like player. Why not? Randomly pick one of its reasons, weighted based on importance. "Well, I'd like to help you out, but I heard about {what you did to Jeffrey off in Smalltown} . . . and I just don't think I can trust you, can I?"

And remember, "kid can't be trusted" might endear you to some certain groups. You might have honorable thieves, sure, but it's entirely possible you could have dishonorable thieves too, who slap you on the back and buy you a drink if you tell the story of How I Got Two Coins Instead Of Just One (right before spiking your drink and stealing your wallet.) You can code this into them without too much trouble – just set it up so that "this person is low on trustworthiness to me" is a good thing. I imagine you'd have several major axes of opinion – "trustworthiness", "helpfulness", "power" – and certain people could easily react differently to each axis. In fact there's probably a fascinating research paper to figure out what major axes people actually think of each other on – in real life, the phrase "he's a nice guy, but he's just not very bright" shows up quite often, and that's just a simple example.

Is that cool? I think it's cool. And it neatly avoids trying to divide every action into "good" and "evil" – your actions will be important, not based on the nature of the action, but based on how the characters around you regard that action.

Going public.

2007, September 19th 5:48 PM

I keep putting this off, but it's time to finally open this site up. I'm going to be submitting D-Net to the 2008 Independent Games Festival contest. With any luck that will drive some readers to my site . . . and, well, for that, I kind of need a site, don't I?

So welcome to the official, still-under-construction website of Mandible Games. I'm planning on posting entries every week at most, and I'll be talking about game development in general and my game development specifically. I'm still unknotting a few kinks from the website – let me know if you have issues with anything, includng comments.

Also, wish me luck in the competition. There are some very, very skilled people submitting games that are currently more finished than mine – but if I don't do well this year, there's always next year, when I'm hoping to have this whole thing wrapped up.

Emergent behavior is a curious, curious thing. Take a bunch of very simple processes of some kind – birds, ants, or humans, for example. Put them in a situation with some basic rules. Then watch in amazement as more complex behaviors evolve out of those. Traffic jams are a good example. The basic rules of the road are pretty simple. "Go where you want to go, stay in the right lines, and don't run into anyone." Nowhere in there does it say "come to a grinding halt every day at 4pm going southbound" – it turns out traffic jams just happen when you have the rest of the rules in place. Traffic jams emerge from the basic rules. Emergent behavior.

Well, D-Net turns out to have some of that. There are new forces and new gameplay techniques evolving out of the basic rules I set down. And some of them are pretty irritating.

One of the basic D-Net Rules is that weapons get more and more powerful, exponentially so, the more you play. And tanks also get exponentially more powerful, but in "stairstep" patterns. What this means is that at some points you're blasting away at your enemies and it takes ten or fifteen seconds to kill them, even at full power, and later on you can annihilate them in about three seconds.

What hadn't occured to me is how this affects weapons that depend on range. See, if it takes fifteen seconds to kill someone, and you're using a long-range weapon, you'll get a third of the way there and they'll be in your face tearing you to pieces. Whereas if it takes three seconds to kill someone, you'll be able to just incinerate them before they can even get out of the way, let alone advance to a range more favorable to them.

Which means that certain weapons have advantages at different times in the tank cycle. That's cool. It means that if you pick up an autocannon early, then shift to a laser later, you'll do better than someone who's just relying on one weapon or another. Which is extremely, extremely neat, and suddenly a lot of the difficulty I've been having in balancing weapons makes sense. (Including why lasers are now too weak, when they used to be just right.)

But it's an absolute bitch to balance.

One thing I'm really hating about D-Net is the emergent behavior.

I hate naming things.

2007, July 2nd 9:16 PM

I'm trying to come up with a few more Exotic weapons for D-Net. After some terrible ideas I came up with the concept of having half a dozen little drones following the player around, shooting at enemy tanks with rifles. It's a cool idea. I'm not yet sure how it will work, but I do like the idea.

The problem is that I already have a weapon class called "drones". They were originally called "rockets", but they also did exotic damage and rockets sound explosive. Now I needed a new exotic weapon name. Argh.

I eventually settled on Automaton. That sounds neat. I can live with Automaton. I'm certain I'm going to regret this decision eventually when I want to call something else "automaton", but hey! At least I have a name.

Now I'm trying to figure out what to do with Beam. I've got two weapons called Conversion Beam, one being a satellite weapon and one being a normal energy weapon. I guess I could rename the satellite version "Conversion Satellite", but it's part of a larger group which is all satellites, and there's no way I'm renaming them all "Satellite". On top of that, one of those subcategories – the Mines From Space – isn't consistent either – every other weapon type is "Variant Type", like "Heavy Railgun" or "Eliminator Drone", and mines are sometimes swapped.

So I either need to come up with a new term for "awesome-sounding laser weapon", or I need to come up with a new term for "lasers fired from space", and in any case I need to come up with three more terms for awesome mines from space. To say nothing of another half-dozen exotic and trap weapons I need to come up with, and another three or four special-purpose kinetic, energy, and explosive weapons.

I dunno, maybe Automatons should be trap weapons. I am considering having them hang around the area, even though there isn't much of a surprise component in them.

Argh.

Finally I've got the tank graphics done, or at least mostly done.

There's a lot of challenges and subtleties in these images that might not be obvious. Here's a list of things that you might not have noticed.

  • The tank models are divided into tiers. As you go further down, the tanks both become more powerful and gain more vertices.
  • The OTEK II has no variations. Most tank types have one variation, which is considered to be in the next tier. CARA II and SEKA I are in the same tier, for example. The highest-end tanks have two variations.
  • A tank variation should be noticably different from the original tank, but still related. This is harder than it sounds.
  • Tank abilities should be approximately clear from the graphic. Pointier sharper more aerodynamic tanks are faster. Wider bulkier tanks are better armored. Tanks with more pointy bits in the front tend to have better offensive capabilities, and tanks with complex detailed sides are more upgradable. There are other things to distinguish tanks, but most of them don't have to be worried about unless you're piloting it.
  • Note that, in this layout, the leftmost tanks are the fastest and the rightmost tanks are the heaviest. In most cases the leftmost tank is also the flimsiest and the rightmost tank is the sturdiest, but there are some exceptions. TUVU is a sturdier tank than MARI, and the GUPE/BORA/HIMO line is backwards. (Yes, the GUPE is both a heavy tank and a fast tank. Relatively speaking, its weapons suck. The HIMO is exactly backwards.)
  • I'm working the number 6 into gameplay in a lot of places. Every weapon has six increasing-power versions. There are six rounds between shop phases. I could argue that there are six tank variations in each chunk, but that would be a stretch. Note that there are 7 tank tiers. This is intentional. Still trying to figure out more places to put the number 6. Right now there are 5 damage types, but I want to keep that, so maybe I'll add a "typeless damage" series of weapons.

If there are tanks that you think look too similar, or suggestions, I'd love to hear them. But I'm mostly posting this because I think they look neat.

Also I'm pretty sure that none of them look like penises. It turns out that this is a recurring problem when you're trying to build war vehicles.

It's far more subtle than you think.

2007, February 2nd 1:27 PM

User interface design is hard.

Not because it's hard to invent interfaces. Oh no, it's easy to invent interfaces. You can throw the suckers together in minutes once you've gotten a little practice. And not because it's hard to invent usable interfaces. That part is hard, actually, but with a little introspection and a lot of blind testing and a whole hell of a lot of agonizing and rewriting, you can make them work. No, the problem is to invent intuitive interfaces. Because intuitive interfaces are usually far, far more complicated than anyone would expect – since, after all, they're intuitive, and they look so easy.

Right now I'm designing a level editor. It's a 2d editor, used to create curves and paths. It doesn't have very many general classes of "thing" it has to deal with yet. There are paths which have centers. Paths are made up of nodes. Nodes may have curve controls on them. Lines connect the nodes in a loop, either curved or straight depending on the curve controls.

Fundamentally it's quite simple. Here's a screenshot, and I imagine most people feel they could jump right in and start moving points around easily.

Well, you're right. You could. You could grab a point, and drag it, and it would move (and, in fact, the point on the other side of the figure would move too – this particular path is set up with vertical symmetry, which the editor will happily preserve for you. Classy, no?) Note that one point is selected right now – the one that's red, in the upper left – but really that doesn't matter much, you can drag any node around at will, and if there are multiple nodes on top of each other you can just click multiple times until you have the one you want selected. You could also right-click a line to toggle it from "curved" to "straight", and the curve handles will automatically go away. And come back if needed. Pretty neat, huh?

You have no idea how complicated all this stuff is.

Imagine the actual code behind it. The user clicks on a node. The program must select this node. Now the user drags the mouse, and the node moves with the mouse. That's easy.

But what happens if the user clicks on the node again? I've mentioned that you can cycle through nodes by clicking, so we could just have it select the "next" node at that position, whatever that means. Sounds reasonable. Except then the user selects a node, and drags it coincidentally on top of a second node, and changes his mind, and drags it further . . . but whoops, he got the wrong node. The program changed to the next node when he clicked. That wasn't supposed to happen.

Instead, we could make it so the node change happens when the user lets go of the button. Only now we have a different problem – the user selects a node, moves it coincidentally over another node, and lets go . . . and it selects the other node. That's not the right behavior either! We shouldn't change nodes in that case. And, in fact, there's a further problem – if I select a new node that happens to be in a stack of three or four nodes, then let go of the mouse button, it will change to the second node in the stack when I let go of the button.

After some thought, you can come up with the following process to solve these problems:

  • The user clicks. If the currently selected item is not underneath the mouse button, it selects whatever is underneath the mouse.
  • The user may or may not drag the mouse. If they do, move the currently selected item.
  • The user releases the mouse button. If an item was not selected, and the user did not drag the mouse, and there is a second item under the mouse that can be selected, select that one instead.

Note that I still haven't defined "second node" or "next node" or anything like that. Oh, also, there's a bug in that process, which I'm not going to point out. (Find it! It's a challenge!)

But we're not even done. Remember, there's four things in this universe that can be selected – and lines aren't draggable! But you can right-click them to change if they're curved. Or you can right-click nodes to lock their curve controls to "straight", so there are no obvious angles to that node. But curve controls, or the path center itself, can't be right-clicked (even though they can be dragged.) And if the "add node" button at the top is selected, then clicking a curve creates a new node at that position. What happens if you click "add node" and then click a curve control? What if it's a curve control on top of a line? What if you right-click it?

And now I have to go, rip out a hundred lines of code, and rewrite it, because my current approach just doesn't work.

User interface design is hard.

On end boss design

2006, December 16th 4:17 PM

Game end bosses are fun. They're not realistic. In terms of realism they're usually stupid. Why am I fighting against a muscled cybernetic black guy who can withstand a hundred machinegun rounds to the face? What's with the four-story-tall tank? If the bad guys have a giant spider which is invulnerable to almost everything, why did they choose to deploy it next to the one thing which can hurt it?

They're not realistic, but let's face it – after we've spent ten hours slogging through wastelands filled with hundreds of monsters, we want something big to blow up. Or something fast. Or something tough. We want something which, once we finally defeat it, will allow us to shout "Yeah! Owned, bitch!" at the television. I mean, even in puzzle games, although the cry of victory may sound somewhat different.

The problem is that bosses are hard. Not to fight – but to design. Let's break bosses into a few categories.

We can get the easy one over with fast – the No-Boss. You wrestle through the entire game, fight your way to the Doomsday Machine, defeat the 817th group of faceless grunts, and the cutscene begins! You step towards the machine, a shadow falls across your face, and with a swoop . . . you turn the machine off and the credits roll. Wait what? Where's the climax? Sorry – you need something to happen at the end. Now, you can get away with the building/castle/planet/dimension falling down around you while you escape, or some nasty timed deal where you have to rescue the princess before she's eaten by zombies. But honestly, most people want a big fight at the end, or something they can use to demonstrate all the neato skills they've gotten dodging barrels for ten hours.

There's the Non Sequitur Boss. Sure, maybe you thought this was a first-person shooter. Maybe you bought it thinking that, like it said on the box, it was a platformer. Nope! The end boss shows up, your trusty sidekick hands you a spaceship key, and suddenly you're flying through space wrestling with controls you've never used before and never wanted to. Or maybe there's two bosses, both of which you must defeat simultaneously with half of your group available, switching between parties with a badly designed and kludgy interface that was clearly tacked on about three days before the game was released. This boss type is awful and has no redeeming features whatsoever. Seriously. If you want to frustrate the player, go for it. If you want a good game? Make the end boss at least tangentially related to the gameplay. Again, people want to demonstrate their skills! Let them!

Now that we've gotten the Crummy Bosses out of the way, I can go over the main categories of Good Boss I've seen.

First off, there's the Firepower Boss. He's like a normal bad guy. Only he's really, really tough. He's got big guns, lots of hit points, and is probably significantly larger than you are. Kill method: shoot him with everything you have, and then some. Avoid dying until he does. Problem solved. Firepower bosses are fun. The problem with firepower bosses is that we're kind of used to them. For a while, we had the problem that people would simply conserve their big ammo when they sensed they were getting near the end of the game. The final boss would show up and be hit in the face with all the most powerful bits of arsenal you'd found in the last five hours. (I think I killed the Quake 2 boss in under five seconds. Unreal's boss was famous because it could be killed in a single shot. Bad design, guys.) Luckily, we're solving this problem now. Modern first-person shooters don't let you carry a small army on your back and they avoid having one weapon far more powerful than any other – at least without major downsides to that weapon. So, the Firepower Boss is good. We enjoy it. But sometimes, we want a little more challenge than "do precisely the same things you've been doing for half the game." Hell, there are often standard creatures that can't be defeated solely with extensive firepower – why should the boss be universally weak?

On the other end of the scale is the Puzzle Boss. He can't he hurt with your weapons – and I mean at all. If you want to hurt the Puzzle Boss, you've got to figure out how to hurt him. Perhaps this will involve shooting four vulnerable points in a particular order (no, it doesn't matter what weapon you use, they'll all do the same amount of damage). Maybe you'll have to run from Point A to Point B rapidly while the boss attempts to annihilate you (get good at dodging!) and then jump through a giant hoop – repeat four times. Don't pick the wrong hoop. You'll figure it out. Or possibly the boss will cleverly have placed an enormous stone block directly above his head, suspended by a thin steel chain. Just get up there and shoot it with your blaster. We'll call it natural selection. Unfortunately, this boss has similar trouble as the Non Sequitur Boss. Let's face it, if we're playing through an entire game dedicated towards blowing things up, we probably want something at the end to blow up. On top of that, sometimes people aren't very good at puzzles. You either need to give them hints – in which case the puzzle is trivial – or you run the risk of your entire playerbase getting angry at you because, what the fuck, I shoot him and nothing happens! What now!

And then there's the Hybrid Boss. Yeah, you need to shoot him a lot to kill him – but generally, he's invincible until you do something clever. Hit him with an explosive so his shield goes away, for example. Dodge precisely so he gets hit by his own wall-mounted fusion cannons. And then, once he's reeling from that – that's when you pull out the portable nuke launcher and fire a few rounds down his gullet. Of course, this has some of the problems of both the previous bosses. People might not figure out the trick. People might not be great at fighting. People might be annoyed that there is a trick. Luckily, none of these are as crucial. You can give hints, because the puzzle isn't everything. You can tone down the combat a little because the combat isn't everything. Whatever part the player finds tough, they'll be content that they were clever enough to bypass it, and we'll just ignore the fact that the other one wasn't all that tough. Add some pyrotechnics and you're golden!

Well, not quite. There's one critical issue that the Hybrid Boss has. Being able to tell you're doing damage.

See, it's easy to tell you're damaging Firepower Boss because you're shooting him, and Firepower Boss has no defenses. Once you've shot him enough, he's done. Meanwhile, Puzzle Boss is similarly easy – if he's dead, you've solved the puzzle. If he's not dead, you still have to work on the puzzle. Meanwhile, Hybrid Boss is a lot more complicated. You might have solved the puzzle and just not shot him enough. He takes a lot of damage, see, but you've figured out how to do it, you just have to keep hammering on him until he dies. Don't give up. Or, maybe, you're doing fine on the shooting him part, but you're no longer actually doing damage. Perhaps the puzzle resets and it's time to solve it again. Perhaps you now have a new puzzle to solve. Or maybe you're just not shooting him in the right way – yes, you can eventually blow him away with your semiautomatic pistol, but you should probably take a look at the tactical plasma turret sitting on the wall behind you. Yeah, that one, over there. I mean, these things happen.

And this is a much tougher problem to solve.

Games where it's possible to "do no damage" usually have a way to tell which is the case. Arcadey games tend to have targets flash when you damage them. Non-arcadey games have the targets bleed. They both work. But you can't tell how much damage you're doing. If you're getting him down to 10% health that just means you need to be lucky to win – but if he's killing you while at 90%, it's time to find an entirely different strategy. And after ten or fifteen tries, if you don't know which is the case, you're going to be pretty damn frustrated. Of course, you could add a health bar, and some games do. But with others that would break immersion horribly. (I'm sorry, but soldiers in World War II didn't get a Hitler Health Bar on their heads-up display.) You can give hints, but hints kind of suck – if they show up too early they annoy people, if they show up too late they also annoy people, and everyone's "too early" vs "too late" is different. You can try to show damage in some graphical way, but it's difficult to manage something which is simultaneously visible, not irritating, and not game-effecting. (For examples of things which fail on different levels, you could show physical damage on the boss itself which they're simply not likely to see in the carnage, you could show little "oh god I'm hurting" cutscenes which will really piss the player off the fourth time he's forced to watch them, or you could make the boss start limping and lose weapons, which turns what could be a cinematic last-second win into a horrible positive feedback "okay I've clearly won but I still have to shoot him a lot to finish him off" situation.)

All of this is what gives rise to multi-phase bosses – it's easy to tell you're making progress when half the boss explodes every two minutes and you have new attack patterns to deal with. But those aren't suitable in "realistic" games, considering that we're already stretching the bounds of credibility by having a boss – no less a boss that is apparently designed to detonate repeatedly.

Super-Robo-Hitler will have to restrict himself to less realistic games. But don't worry – he'll be well-received there.

Accept mission?

2006, October 31st 6:32 PM

I've been playing an MMORPG beta lately (I technically can't tell you which one, so I won't). It's fun. They've done some very novel things with combat.

They haven't done particularly novel things with missions. It's all the same old deal. Talk to person, accept mission, mission goes into mission log, go kill bad guys, repeat. So naturally, I've been walking around accepting all the missions I can because, hey, why the hell not? And I've got a huge pile of missions that I really don't know much about, but I'll just go select the next one and do the next one when I feel ready.

World of Warcraft "solved" this problem by limiting the number of accepted missions you could have. I think it maxed out at 20. This didn't actually change anything – it just meant you had a text file open while playing, writing things down like "elf girl, felwood forest, 3 missions". And it meant that you couldn't just wander around and do all your missions when it was convenient – more than once I found myself saying "oh man, I have missions here! Except I don't have them in my mission list because I had that giant group of missions in Gadgetzan that I needed to free up space for and I guess I didn't get them back dammit."

Obviously, IMHO, this isn't ideal. I like the limitless mission journal. It's more realistic. I don't have to delete "learn guitar someday" when I realize I have an unexpected stop at Trader Joe's.

But then, if we have a limitless mission journal, why bother with "accept this mission"? Why have "missions offered" to begin with? Perhaps I should just walk up to someone, and he says "Oh god, they've taken my shovel, I loved that shovel, please has anyone seen my shovel" and bam, mission. He doesn't have to say "you should go find my shovel! I shall give you a reward if you do. Do you accept the mission?"

There's no mission. There's just a guy who's lost his shovel. And your character writes it down in your notebook because, hey, the guy's lost his shovel, maybe you can find it.

I find this a little cleaner, more elegant, and more engaging.