the reason you write clean code

(02:26:08) Eric Heimburg: the reason you write clean code isn’t to be awesome, it’s so that you can spend that cleanliness at the proper moment of desperation. Like at the end of Plum Mountain’s 200 hour development, I had elegant code systems, which meant I could shit all over them to glue “place any number of things that are vaguely like flowers” logic onto it, and then the Kongregate API, and then loading and saving, and now… it’s crap. But I spent it well

(02:26:34) srand: You should post that.

Posted in Programming | 7 Comments

A Psychologist, a Fire Mage, and a Dickweed Walk Into a Bar…

[This is about Project Gorgon, a fantasy MMO I am making all by my lonesome. It is an insanely difficult project and easily the most ambitious undertaking I have ever made. Join me, won't you, as I descend slowly into madness?]

You may remember a couple weeks ago when I was trying to figure out if I should have hordes of monsters or just one big monster: after some thought, I realized that 4th edition D&D had the right approach for me here.

4th edition D&D has a pretty well-done combat system. (Shame about the roleplaying parts!) The combats are usually pretty intense and interesting, and more importantly (for my purposes) they are easy to snap together from parts.

Continue reading

Posted in Project Gorgon | 15 Comments

The Stamina Bar

[I'm not working on the game this week, instead I'm doubling up on my other work so I can spend a full week on the game next week. But I've had one little anecdote bubbling around in my head. Indulge me, it's short.]

I had been hired at Turbine to work on the sequel to Asheron’s Call. I was an engineer through and through; I’d been coding (non-games) for nearly a decade and I was pretty good at it. I was hired as a senior engineer, and I got right to work on coding the game engine.

But the game had a troubled development cycle with lots of changes of direction. As the vision of the game changed, the team got less excited. “This isn’t a sequel to Asheron’s Call at all!” became a quiet undercurrent. It was around this time that one of the producers grabbed me at random as I was coming back from lunch one day and asked me to preview his presentation. He was working on a pitch that explained what Asheron’s Call 2 was all about, and he needed to refine it by getting feedback from people like me. I was happy to oblige, so I followed him into his office.

He then closed the door and began his impassioned pitch about why the new game direction was fun. I was a bit of a hard sell: I had specifically come to Turbine to work on the sequel to the game I loved, not to just “make a good game.” But I was willing to hear him out.

At one point, he mentioned that they were removing the Stamina bar. “In Asheron’s Call 1, you have three bars: Health, Stamina, and Mana. That’s dumb. You just end up using spells to convert stamina to mana to health to stamina to health and so on. We’re simplifying…”

I interrupted there, and said, “but that’s fun!”

He looked a little taken aback. “No it isn’t! Why is it fun?”

And… I couldn’t explain why it was fun. I was an engineer, not a game designer, and I hadn’t spent years thinking about why things are fun. I just knew that it was fun.

He figured it was because Asheron’s Call 1 was my first MMO. “People always get stuck on what their first MMO did.” But no, I corrected him: Asheron’s Call was my third MMO. I’d played a little bit of UO and a ton of EverQuest. I knew what else was out there, and I knew that Asheron’s Call 1 was fun in different ways. I just couldn’t explain why.

That was an important day for me. I don’t believe I could have changed the course of the game at that point — it made no difference what I said or didn’t say. (All I did was cause him to focus on other design elements for his presentation.) But it was important because I realized I wasn’t a game designer, despite thinking I was. I’d played tons of games, I knew all the mechanics they used. But here I was, unable to defend the simplest concept. It was frustrating.

It changed how I played games forever, and not necessarily for the better — when you study everything to see “why is this fun”, you sap some of the fun out of it — but I think it’s the critical skill that game designers must develop. Just that. The rest of the job is details, but you have to be able to articulate why something is fun… or at least why it could be fun.

Nothing is fun for everybody, and nothing is fun in every game. A lot of times I can only recognize fun by watching others: there’s plenty of genres I don’t enjoy, so I can only hypothesize about why they’re fun. And I may often be wrong. But the act of thinking about it is what’s important. If you don’t even think about it, all you can do is unconsciously mirror what you’ve seen before. You can’t put disparate elements together (let alone try brand new things) with much hope of them being fun.

I think I can now defend why Asheron’s Call 1′s three separate energy bars were fun, but I’m not going to bother doing so. It’s beside the point. The point is… screw that producer. My MMO’s going to have three bars. No — four bars. No. Five.

Posted in Design, Project Gorgon | 15 Comments

Thinking about Gorgon Combat

[This post is about Project Gorgon, an indie MMO in development.]

Pop quiz time: say you have two attacks that do the same damage, but one hits a single target and the other hits multiple targets in a small area burst. How much better is the area attack than the single-target attack?

If your initial instinct is “oh, maybe 150% to 250% better”, you’re probably imagining a game with mostly one-on-one combat:

Duke it out against a single dangerous foe, throwing a barrage of attacks against it until it dies. With friends, you each work together to kill this foe, perhaps taking the classic MMO roles of tanks and healers and damage-dealers.

In this sort of game, you work hard to avoid fighting lots of enemies at a time, so an area-effect attack isn’t particularly powerful.

But of course this was a trick question because a typical combat might instead look like this:

Face off against a large number of foes, trying to take out the most dangerous first and keeping them from attacking your vulnerable flank sides. When fighting with friends, you both wade into a mob and start duking it out, helping each other when then going gets too tough.

In this sort of game, an area-effect attack would be incredibly powerful and probably hard to balance.

Project Gorgon is based on an earlier MMO effort called Project Frontier, so I’ve inherited the earlier combat system which was designed for one-on-one fights. (Or, more exactly, one-group-of-players-versus-one-or-two-monsters fights.) So when I started fleshing out the combat system with unique new fighting mechanics, I just automatically kept that assumption.

That was dumb. My favorite MMO was Asheron’s Call, which featured hordes of enemies that you had to wade through. Those combats were often epic, terrifying, and adrenaline-pumping. Why haven’t I even considered using hordes of monsters before now?

Frankly, I just didn’t think about it. It’s hard to examine every assumption, and incredibly time-consuming to have to think about every detail before you implement it. There’s a reason other MMOs steal existing combat systems: new stuff is slow and risky. That’s even more noticeable for me, because every day I prototype is a day I can’t add content.

So I simply can’t question every assumption about my MMO. A vast amount of it will be “old hat”. But this question feels a lot more important: “what sorts of combat encounters do I want to support?”

My natural answer to that is “both!” I want your band of adventurers to wade through hordes of monsters, fighting a war of attrition, only to reach the tough monsters at the bottom of the dungeon and have to muster your last resources — and fight in an entirely different way, working together against solitary tough foes.

Is that an achievable goal? I’m not sure yet… I’m still digging. Here’s what I’m digging into.

Technical challenges of hordes:

Asheron’s Call was way ahead of its time. Fifteen years ago, this MMO could easily handle 100 monsters in a dungeon, and 30+ of them in a single epic encounter room. How did they manage to get all these 3D creatures in one dungeon?

Well first of all, each monster had about 50 polygons, tops. (This was fifteen years ago, though. When the monsters were revamped, they got 200 polygons! That’s still 1/50th of what’s in a AAA game monster.)

Second, the monsters were dumb as can be. There was no path-planning involved: monsters simply ran straight at you, and if they can’t reach you, they just stood there running headfirst into a wall. (This provided a large part of the strategy of the game, as you had to carefully manage the number of monsters that could reach you at any given moment!)

They also had extremely simple decision-making abilities. Finally, they had exceptionally tight networking code (remember, this stuff ran on dial-up modems).

I’m okay with horde monsters being dumb as hell and running in straight lines. But I don’t know if my engine can handle the bandwidth, physics calculations, or even the rendering requirements of having tons of monsters in one area.

It’s a little sad to think that a fifteen-year-old game engine may still be better than mine, but it may well be. I need to do some stress-testing to find out if I’m even in the right ballpark to make hordes of monsters happen.

So I need to get the game up on my live server in order to see what realistic lag feels like and let some friends jump in to help me test. I spent some time working on that this week, but I ran into some snags and haven’t gotten it live yet.

Is It Too Much For Players?

The next big question is, even if I can support both hordes and tough monster encounters, can players switch gears enough to deal with these two types of encounters successfully, given that they will have completely different strategies?

My big worry is that players will get used to one of them and over-optimize for it, so that the other kind becomes very tedious and/or deadly. If they’re used to WoW combat, which is relatively mindless, they may be flummoxed and unhappy having to switch gears and pay a lot of attention to what’s going on.

Not everybody likes having to think about their fights. Some players think it’s poor design if they even have to switch weapons between fights, let alone switching entire strategies.

My instinct is that I’ll have to constrain the variation a lot more than I personally would need in order to reach a large enough audience. So the question becomes, will both hordes and tough solo monsters fit into the mindspace of people playing the game?

I don’t know how to find an answer that one. But my instinct is that I’m probably expecting too much of players to rapidly switch combat styles over and over. But maybe if it’s just those two scenarios I could teach them… provide enough in-game help… hmm…

Does It Make Overly Restrict Mechanics?

The last big question is, does it obsolete too many game mechanics? Players can only select a certain number of “active” abilities at any given time, so you have to load up your character with the skills you expect to use for a given dungeon or whatever.

If the abilities become too specialized, it becomes impractical to use them. Area-effect attacks are a good example: they will probably be very effective against hordes but very weak against solo monsters. If that’s the case, should you bother bringing them at all, or did I just implement a dud mechanic that nobody will use?

And it’s far from the only example: taunting, debuffing, armor-bypassing, knock-back: nearly all combat mechanics end up being significantly better against either hordes or strong solo monsters.

Maybe it will be fine. Or maybe it will be a little too tough, so I’ll add some more slots to the active skill bar, and tada, no big deal. Or maybe it’s just going to be too much specialization and I have to throw out a lot of mechanics. That would suck, and would make me reconsider this whole plan.

More Questions Than Answers

So this week has brought more questions than answers. Nevertheless, I’ve been plugging ahead with coding up some dungeons and monsters and skills and pets and so on, fleshing out the existing combat engine.

I can’t figure out the right answers just by thinking about them real hard: I need to see this stuff, get a feel for how it will play out.

And I can always hear the timer ticking in the background. At some point very soon I’ll have to lock down the sorts of combat encounters the game supports, and that will be that. So there’s a manic feeling of desperation to these tests and experiments I’m doing…

More about combat next week! (Hopefully I’ll get a chance to talk about the Gorgon-specific game mechanics… if they’re still in scope by the time I write the next post!)

Posted in Project Gorgon | 17 Comments

Creating a backstory for the game

I had intended to write about combat this week but it turns out that all my writing time is being taken up by the game itself, so I’ll keep this really brief!

Basically, my story flopped on me. I’d borrowed the elaborate back-story from the previous MMO incarnation, code-named Frontier, because the target audience is much the same: it’s aimed at systems explorers; people who like complexity in their world; people who want to be invested and involved in the world.

But the Frontier storyline is an onion-skin design: you start out with a very typical fantasy world, and then you discover things aren’t quite as they seem. And as you dig deeper and deeper, your view of the world — and who is “good” and who is “bad” — changes repeatedly in interesting ways.

I’m proud of the Frontier world-building I’ve done, but I can’t use it here. The problem is it’s too hard to get invested in a world where nothing is as it seems. Imagine, just as an example, that it turns out the moon is really a space vessel for an alien race. That takes a lot of the magic out of being a werewolf, with their strong ties to the moon. Or suppose it turns out that the land was created artificially just a few hundred years ago… that takes the excitement out of the Geology profession, doesn’t it?

There’s a constant struggle in a traditional MMO: you want players to invest in your world quickly and easily so that they can have fun and get into it. But at the same time, you want surprises around every corner. In my game, because it’s exploration-based, the surprises need to come from the world and its environment, not from e.g. a warring tribe that betrays the players or a dragon that shows up and destroys cities. Most of the story needs to be revealed through discoveries players make at their own pace, not via a “story event.”

To achieve this, Frontier used the “not really” story technique: “The mountain is the home of the dwarves. NOT REALLY! It’s a weapon of mass destruction aimed at the moon!” (None of these are real examples, BTW, they’re too silly even for me.)

Instead of “not really”, I’m now relying heavily on the “and also” technique: “The mountain is the home of the dwarves. AND ALSO it’s the ancient prison of a demon!” This gives me the surprises I need but lets the world stay “real.” The surprises aren’t as impressive, but hopefully they’re still interesting enough.

I’ve done some fiction writing before, and I enjoy it, but I do admit that my strength is in systems design, not story design. So if you have suggestions on how to create an MMO story, or what you like to see in an MMO story, I’m all ears! (Just post quick, ‘cuz I’m knee-deep in story elements as I write this…)

Posted in Project Gorgon | 10 Comments

NPCs as Systems Nexus

My plans for NPCs have been refined a bit. At first, what I envisioned sounds similar to the “Storybricks system” recently announced by Namaste. I’ve abandoned that, now, though, because it’s too convoluted given my time/resource constraints.

But there’s a lot of different things you can do with NPCs depending on your goals. I want NPCs that are memorable and that tie into the rest of the game’s mechanics elegantly. And in fact by dropping a lot of the extraneous stuff, it’s become a lot easier to see how to do that.

Every game has to figure out where NPCs fit for them. For a pure-action MMO like World of Warcraft, NPCs don’t have much role to play. But my game has lots of non-combat skills, and NPCs need to be a big part of how those work.

Examining (and Skipping) the Classic Answers

I started out by looking at some of the traditional computer game NPC systems. A classic one is schedules — giving every person a “life” beyond just waiting for you to show up and buy their crap.

Coding it? Not so bad. But it needs a whole lot of content work. (“Okay, so the town has 33 NPCs. I need to make sure there’s 33 beds, or at least that they can sleep in shifts…”) But more than that, it’s not very fun in an MMO.

In a single-player game, you can just push a button to “advance the clock two hours” when you’re waiting for a shop to open. In an MMO, you might be waiting several real-time minutes for a shop to reopen. Ugh.

I’m interested to see what the Storybricks system comes up with to avoid the annoyances of NPC schedules. But this isn’t a problem I want to try to solve for my game.

Another classic mechanic is talk trees. I do have talk trees, but they aren’t a major aspect of the game, because they are incredibly expensive to write. (They have to be interesting enough to read, or else you end up with boring talk trees like EverQuest 2 had when it first started… and that’s worse than no talk trees at all.)

In the end, I decided the best way to interact with NPCs in my game is to use verbs on them. For instance, you can use the Show Item verb to show something to an NPC and see how they react. Or you can Give Gift, or Shop, or so on. You unlock verbs by mastering skills, so eventually you will have Psychoanalyze, Entertain, Flirt, Control Mind, and others. These all affect the NPC game systems in simple ways.

Interaction Mechanics: Friendliness, Favors, Gifts

In my mind, NPCs and the skill system have a symbiotic relationship. The skill system gets a big jolt of entertainment from interacting with NPCs. And NPCs are fun specifically because of how you can use skills on them.

But in order to make NPCs fun to interact with, they need some custom mechanics.

First off, every NPC has a hidden number that represents how much they like or hate you. If you do nice things for them, this number goes up. What are “nice things”? Well, if you save the town from certain doom, it goes up for everybody in the town. But you can also give gifts to people. (You’d need to use social skills to figure out the perfect gift.)

Of course, you can’t give gifts to strangers, that’s just creepy. You need a certain amount of Friendliness before the NPC will be willing to accept a gift. And of course, when you’re friends, the NPC will sometimes offer you gifts in return.

You can increase friendliness even more by doing Favors. These are just simple quests. (They may still be very difficult in some cases, but in terms of mechanics, they’re just get-me-some-item(s) quests.) Every single NPC in the game has at least three Favor quests that you can unlock by making friends with them.

Favors, of course, don’t come with direct material rewards… they’re favors! But there are many benefits to friendship. NPCs who are skilled in certain things can help you in lots of ways, such as by teaching you new things, giving/selling raw materials or recipes, or even just buying your junk items that nobody else is interested in.

There’s also the romance angle, a la Harvest Moon: some NPCs can be “married”, wherein they appear in your house. (Of course, it’s possible for lots of players to be married to the same NPC! But who cares?)

Although Friendliness is a hidden number, the game does give you a general idea of their friendliness level at all times. I want to make it easy to “game” the mechanic. It’s not like real life, where people can be impenetrable and illogical. Game mechanics are only fun if you can see what you’re doing and how you’re affecting things.

Friendliness Rating is very simple, as you can see — that’s true of all these systems. But it can still have far-reaching implications, and when combined with a few other mechanics it can get interesting. For instance, I’ve been experimenting with “happiness factor.”

Happiness Factor

If an NPC shopkeeper is making a lot of sales and piling up a good income, they’ll be happier than if they’ve been standing around bored all day. But if a player with a good Barter skill gets an NPC to pay too much for some loot items, the NPC might get buyer’s remorse, becoming less happy for a while.

An unhappy NPC is less likely to do favors for friends, give good deals on items, and so on. However, you can increase their happiness by doing things like dancing for them, using social skills to cheer them up, or even using mental magic to force them to be happier (but watch out if the NPC realizes you’re doing that!)

Is this a fun mechanic? Eh, it’s okay, but its real purpose is to be part of the gestalt. Emergent gameplay comes from the combination of systems. Without other systems around it, this system would just be odd. But it combines with other mechanics to tie into skills, quests, combat, and crafting.

I have to admit that the main reason I like this mechanic is that it gives players ways to affect each other, indirectly — an NPC’s happiness level is global, so you can go around pissing people off or making them happy. (It’s a lot easier to make an NPC “happy” than to make them “sad”, so that griefing potential is low… but the effect is still noticeable.)

With a few more of these simple mechanics tied together, we get a nice meaty base for skills to interact with.

But Are They Memorable?

If NPCs are just sets of numbers, that can still be fun to interact with. But if the NPCs are memorable, the impact of manipulating their numbers is greatly enhanced. Ideally players will remember the names of many of them, might be willing to do favors for them, and would even care if they got kidnapped by frog men or smote dead by an evil curse.

My plan actually calls for a lot of text — probably about 60 lines per NPC — but they’re mostly terse reaction statements based on what skill you’re using on them and their current game state. So the volume of text is high, but it’s not anything like having to write compelling talk trees.

But this text gives me room to give them simple personalities. As I’ve said before, I think we should all be striving for two-dimensional personalities for our NPCs. Practically speaking, this usually translates into “quirks”. The pirate that hates rum and secretly drinks apple juice. The matronly older lady who runs a tailor shop, and secretly also runs a brothel. The troll under the bridge who likes candy. You shouldn’t always discover their quirks right away, either: they should have enough surprises that there’s some meat for players to discover via interactions.

I don’t expect the NPCs’ personalities to be so compelling that you remember them right off the bat, though. Remember that the game systems push you toward visiting the same NPCs repeatedly, so that I can take advantage of face time.

The Magic of Being There a Lot

Remember Final Fantasy 7, when Aeris died? This character’s personality was wilting, boring, and cliched. The reason we were shocked and saddened is because Aeris had been a foil in the story for hours and hours.

If the game had introduced Aeris just a few hours before she was killed off, even an incredibly interesting personality wouldn’t have made the death matter as much. I didn’t cry when Aeris died (I felt manipulated by the author, so I was pissed off more than anything else) but for a lot of gamers, this was an extremely important moment.

Yet if you asked them to write a paragraph about Aeris’s personality, I don’t think many people could. She wasn’t memorable because she was that interesting. She wasn’t memorable because of her story or the logic of the world, either. (Hell, given the laws of the Final Fantasy universe, a $100 item should have fixed her right up.) She mattered because of face time.

Now Aeris did have some personality, or otherwise the few dozen hours of face-time she got wouldn’t have been enough.

I think you can always use face-time to make someone memorable, even if they are lacking any trace of personality… but it might take a lot more time. If you watched enough Stargate SG-1, you’ll remember the guy who called out “Chevron 6 is locked!” whenever the Stargate opened. But you probably don’t even know his name. However, if he’d gotten murdered by a Villain of the Week, longtime fans would have been quite upset. Not because he was important, but because he was… well, on screen for literally hundreds of episodes of TV. But a bit of personality definitely helps speed up this process.

So my game systems increase the face time for NPCs, which helps give them importance to players, which in turn increases the importance of the game systems they’re being interacted with. That’s the plan, at least.

Keeping It Simple and Focused

All in all, the systems are very game-able — it is a game, after all. I want it to be fun. Players should be able to figure out how it works, and even if it’s a bit of a puzzle how to approach some NPCs, players should ultimately be successful, given enough time and effort. One trap that’s easy to fall into is opacity: it’s easy to make NPC systems that players can’t understand. When that happens, players aren’t having as much fun as if they understood what was going on.

I also realize that not every player will be excited about befriending NPCs. It’s not very heroic, at least in the classic “dragon murdering” vein. That’s okay; there’s enough things to do in the game that you don’t need to chat up every NPC to have fun. But even if you’re purely combat-focused, you’ll find that some combat skills also give you interesting NPC interactions, and then you may find you’re enjoying it more than you expected…

Next Week

I’m trying to maximize impact with only low-cost game systems — systems that are easy to code, balance, and create content for. Hopefully I can achieve that for NPCs (there’s some worry about the text needed for NPCs, but I think it’ll be okay… I just need to write some more of them to see if I can really sustain that efficiently). If it doesn’t work, I’ll change it until it does.

Next week I’ll talk about how I’m using this idea of “low-cost, high-impact” in the combat system. It has different bottlenecks and problems, but I’m excited about how it’s turning out.

Posted in Design, Project Gorgon | 13 Comments

Notes From The Coding Pit

[This week I haven't done any design philosophizing... I've been busy coding game systems for the MMO, so I haven't gotten a chance to write anything too clever. These are just some notes that you may or may not find interesting.]

Transforming into beasts is inherently kind of fun

One of the game systems I’ve been working on is the transformation system, so that you can turn into something you aren’t. This turns out to be a lot of fun to play around with. There are some wild pigs and deer in the forest that I’m working on, and I often find myself absentmindedly turning into a wolf and chasing terrified pigs through the trees. There’s something inherently cool about being low to the ground, attacking with jaws and claws.

I think being a werewolf will be a lot of fun if I can manage to capture and enhance this underlying “feral” vibe. The problem is that when killing something more ferocious than a deer, the wolf suddenly feels like just another DPS class, as you stand there trading blows with your enemies. I have some ideas on how to avoid that fate, but I really don’t know if they’ll work out yet.

Sometimes sample code gets around

I mentioned that Gorgon is based on an earlier MMO project. My earlier MMO’s client synchronization code (that lets players see and interact with each other) was borrowed from an old SmartFoxServer demo. It worked okay under optimal conditions… but in certain lag conditions, clients would get permanently out of sync. That old demo code was always meant to be a temporary thing anyway, so this week I finally got around to rewriting it.

But as I researched other implementations on the web, I kept finding the same demo code I’d borrowed. It’s a simple algorithm, so not every implementation was borrowed from the same source, but I could tell that four or five Unity demo scripts must have been direct descendants. Some of them literally had the same problem, but most of them had a band-aid hacked onto them to fix it.

This made the code kind of silly: it has a fancy buffer system, and the idea is it will speed up or slow down to play the data back in a way that makes it seem smooth. But this code doesn’t do the speed-up part right. When it’s getting out of sync, the band-aid fix is to just dump data out of the buffer until it’s back to normal. This means that people end up appearing to “blip” around more than they need to. (Or walk through solid objects, depending on which version of the band-aid you used.)

After talking with a friend who’s done a lot of this sort of thing for other MMOs, I started over from scratch using a slightly different approach. The net result isn’t much different from the old code, but my code’s a lot easier to follow, since it doesn’t have all the vestigial stuff lying around.

There are some tricky timing elements when doing synchronization, so I certainly think it’s smart to study existing code. But I find it kind of funny that someone must have swiped this demo code wholesale, then realized the code was buggy, but not really understood precisely how it worked, and just slapped a band-aid on it. Then they released their code, and it got ported to other APIs and versions and so on, propagating around. I guess the moral is… be careful what you swipe off the internet?

Mixamo is cool, but glitchy

A few months back, a Unity3D newsletter proudly announced that they would soon have a whole bunch of animation data available for free from the Unity Asset Store. (I think this is old mo-cap data that was made public by MIT a few years ago.) Unfortunately… that newsletter seems to have been premature, as there’s still no sign of all this cool free animation data.

On the other hand, Mixamo.com has a very nice Unity plug in that lets you shop for animations directly from within Unity. You can apply the animations to your model right in the editor, tweak various sliders until they look good, and then buy the animation. Each animation costs $10 if purchased through the Unity store, which is a steal considering that they’re more than twice that much if you buy them from Mixamo.com directly.

I certainly don’t feel that $10 is too much per animation, but I do wish I could tweak the animations for free after I buy them — or at least get some sort of discount for re-buying the same animation. Once I’ve paid for the animations, I inevitably want to adjust things ever so slightly this way or that… but once it’s bought, it’s over. If you want to change anything even slightly, you have to pay $10 again. That payment model is really frustrating. But given the quality of the animations, it hasn’t stopped me from picking up an animation or two, and planning to pick up more in the near future… if I can get my elves to sync up with Mixamo’s system.

See, the tricky part with using Mixamo is that you have to get your 3D model to sync up with their server, because their server will bake the animations to fit your particular model. This is sometimes very easy, and sometimes not. I often buy models from people who don’t speak English natively, so their models aren’t rigged using English names. This confuses the automatic mapping tool, which seems to use bone names as heuristics.

But even on models that look very standard to me, the importer is just not super robust yet. It can get really confused and spit out error messages that I can’t make heads or tails of. In these cases, the tech support guys have been phenomenal, though, so I can’t complain too much. Hopefully they can fix my female elves — the male ones imported without a problem, but I can’t get the females in for some reason.

Groovy: the only cool thing about Java?

The server code is written in Java. I prefer C# by a large margin, but Java is just a lot more “everywhere”. It’s easy to find different socket-level implementations to plug into my game if I use Java — and more elaborate solutions like SmartFoxServer or ElectroServer. A lot of cool technology can be dropped into Java apps that don’t have good C# analogs yet. (I’m also a little scared of running a linux server farm with the game written in the “Mono” version of C#. Mono seems great, but I still worry that it’s going to have weird problems under linux that take tons of time to figure out.)

I don’t especially like coding in Java, though. It’s missing a lot of conveniences, and it can be pretty ugly to code in. I’m still irked that it doesn’t support unsigned integers, too.

There’s one thing I do like about having written it in Java, though: the Groovy programming language. Mainly what I like about it is that it compiles to Java bytecodes. This means that I can use it as a simple scripting language for my NPCs and other behaviors, but it gets compiled to run at the same level that the actual server does. (Instead of other scripting languages, where they get interpreted by Java code, so it’s a VM running a VM.) It’s still not as efficient as regular Java, but it’s not bad either, and Groovy has a lot of syntactic tricks that make it easy to kind of “sculpt” it to fit particular scripting situations, such as for NPCs in my game.

(Where a game written in C++ might use Lua, I think Groovy fits that role for Java games.)

Next week: NPCs

My last post lamented that I don’t have time to do everything I want to. Several people let me know that if I needed to cut something, it should be NPC features. I don’t think it’s so easy a choice as that, and next week I’ll explain a little bit about what I have in mind. (It’s less about stuff like scripted movement or animatronics, and more about how NPCs can be the heart of interesting game mechanics that we just don’t see often in MMOs.)

Posted in Project Gorgon | 4 Comments

Go Big or Go Home

“Go Big or Go Home.” I hate this phrase. But this comic made me realize it’s less intimidating than it sounds.  Of course you can just go home! You don’t have to fight every battle. Sometimes it’s smarter not to go at all.

PvP: Hard to Do Well

PvP is a great example: if you’re going to have PvP in your game, it’s going to suck unless you Go Big. You need to invest a lot of time and thought and effort into it. If you don’t, you shouldn’t even bother: the PvP will be unappealing and it will hurt the rest of the game in the attempt.

That’s why my MMO “Gorgon” has no PvP. I can’t afford to “Go Big” on PvP. It’s not something I have any expertise in creating, it’s not something I particularly enjoy in an MMO… so it ended up being cut out of the schedule entirely. This will limit my audience, but that’s okay. I can’t make a game for everyone.

(Hey, I guess cutting features isn’t that hard after all! As long as they aren’t features you’re personally excited about…)

Item Systems: Hard to Do Well

In the discussion about item decay, it was pointed out that item decay is hard to do well. This is very true. I’d go so far as to say treasure systems in general are hard to do well. Most MMOs, including WoW, have rather boring item systems that don’t try very hard. They aren’t the heart of the game. A game like Diablo 2, on the other hand, where the item system is a large part of the game itself, tries very hard indeed.

A great item system requires random loot in many varieties, interesting trade-offs that are nonetheless easy to understand, the ability to customize and enhance your items, and a built in reason to keep looking for more loot. This is a very tall order. It’s easy to say you’re gonna do that, but it takes an incredibly long time to get the details right.

My current feeling is that I have to “Go Big” on my item/treasure system because the game has so many non-combat mechanics. All my systems need to feed into each other in intricate ways. Mushroom farmers, animal skinners, herbalists, necromancers, geologists — they’re all collecting or generating “stuff”, and it’s not always going to be directly useful to the skill they got it from.

At the moment, I think the item system ties the game mechanics together, so it needs to be deep… really deep. But I know firsthand how long that will really take to make happen, and I know it will be quite difficult to pull off.

Trade-Offs: Short-term vs. Long-term

Whenever I spend a day designing a system, that’s a day that I didn’t code a game mechanic or create a new quest or write a new NPC’s dialog. Being just one guy means no delegation of responsibilities. So can I really afford to “go big” on my item system? Well, not nearly as big as I want to.

But I also really hate the idea of launching the game without a robust item system — because that’s not something you can patch in later. I could launch with very little content and patch content in later (assuming the lack of content doesn’t kill the game outright). But the big-ticket game systems, like PvP or complex item systems, don’t get to change that much later, especially if your game is centered around emergent gameplay like mine is. Changing something so fundamental will alter everything, and players don’t generally enjoy this, because it destroys everybody’s game knowledge and treats them like paying beta-testers.

what I’m really deciding is: how good can my game ultimately be? When I examine each game system, I ask myself: “If the game is successful and gets thousands of paying players, am I going to hate myself for not having implemented this before the game launched?”

Go Big or Go Inevitably Sad But What Can You Do

Unfortunately, that doesn’t narrow it down enough. In my game, I want to focus on the skill system, the item system, the combat mechanics, and the NPC interaction system. If I short-change any one of these areas, I’ll be sad later. But I can’t give all four of these areas the attention they deserve.

This is a place where having a producer would be helpful: someone who could see the forest for the trees and help me decide how to spend my resources best.

I’ve talked about this problem many times on the blog: designers can’t make the best choices for the long-term when they get too invested in their game. And I’m just as susceptible to this as anyone else.

My natural inclination is to say “all four of those systems are critical. I just have to do them all to 100% perfection!” But were I to succumb to that, the game would fail. I don’t have time to implement all of those, and even if I did, it would mean the game lacked content or critical infrastructure. Something precious to me has to get cut. Many things, actually.

Seek External Help

At least I realize that I’m not able to make the best decisions in this case. So I’m not going to work on any of these systems this week: I’m going to code some other things to get my mind to switch gears. Then I’ll sit down with Sandra and pitch the problems in detail, discuss the exact plan, and get her to help me figure out what to cut.

I may have a slight advantage over the average indie developer here… but even if your wife isn’t an experienced MMO producer, I bet you can still find someone to pitch your problem to and get feedback from. It needs to be someone whose opinion you respect, and someone who can take the time to fully understand the problem. And you need to be detached enough from the problem to be able to deal with the feedback.

Not Just For Indies

I just want to reiterate that every MMO team I’ve ever seen has fallen victim to this, and sometimes they pull themselves together… and sometimes they can’t. If you’ve read this blog for any length of time you’ve seen me ranting about WoW going off the rails: biting off more than they can chew, overpromising and underdelivering. If a game with the size and success of WoW can succumb to this problem, it’s not about money or team size.

Nobody wants to make the painful cuts, the ones that make your game less perfect than what you had in your head. This is true in any MMO, be it a AAA box title, a web game, or anywhere in between.

Sometimes ignoring the resource-allocation problem works out fine. Sometimes you get lucky. But lest we forget, only one in four MMOs gets from start to completion. And that’s announced MMOs. Who knows how many MMOs die before they even make a whimper? The odds are stacked heavily against you, and part of the problem is how hard it is to allocate resources.

If you think you’re immune, you’re probably wrong. (In my experience, the sort of personalities who are immune to this problem are not the sort of people who become game designers.)

If you think it doesn’t apply to your game, you’re probably wrong, too: you just don’t realize what you’re trading off yet!

 

Next Week: Can Talking About Engineering Ever Be Interesting?

So I’m currently working on low-level stuff that has to get done, like chat and persistence and generators and GUI. Join me next week when I desperately attempt to make networking code sound interesting!

Posted in Design, Production, Project Gorgon | 11 Comments

Item Decay Redux

There’s been some great replies to my last post, and I want to thank you for the ideas. I’m still sifting through them and figuring out what I can realistically make work, but I particularly liked these tidbits:

  • The “rune” metaphor to explain item decay: it’s a lot more elegant than “sharpening swords” and it allows for infinite diversity of power-ups. Because sharpening a sword just makes it sharp. But a rune is maaagggicccc so it could do anything at all.
  • The idea that items can be “melted down” somehow to provide temporary power-ups for other items. More directly, raw items may even be prerequisites for creating certain runes.
  • The need to use different weapons for different problems (already a part of the combat design)
  • Legendary items that are permanent and require no repair/allow no runes to be installed/etc. They’re very powerful but very specialized — so for instance you might find the epic sword of frog-man stabbing which is the best frog-man stabber that could ever be… it doesn’t ever need repairing. But it’s also not ver good against anything but frog-men.

And several others. I think a lot of people described what I already had pictured in my head, which means I didn’t explain what was in my head very well!

This all brings us around to the elephant in the room, though: given such finite resources, can I make this system as exciting as it should be? If I can’t do it really well, it should probably not be done: a half-assed item-decay system is far worse than no item-decay system at all. This is one of those mechanics where you need to “go big or go home.” Which I’ll talk about in another post shortly…

Posted in Design, Project Gorgon | 4 Comments

We Can’t Have Nice Things (They Keep Decaying)

[This article is about my upcoming 3D fantasy MMO code-named "Project Gorgon."]

One of the many design elements I haven’t fully figured out yet is item decay. This is a tough one.

Item decay is when your weapons and armor and tools can get “used up” and disappear after some amount of use. It’s very different from “item damage”, where the items can be completely repaired. Decay is permanent, and is thus a much more complex topic.

The Case for Item Decay

Why would you have item decay in your game? There are lots of reasons to use this mechanic:

  • It gives crafters more to do. If people need to buy new swords regularly, then blacksmiths have more to do. If swords don’t wear out, then blacksmiths obviously don’t need to make as many.
  • It reduces twinking. A big problem in games with random loot systems is “hand-me-down weapons.” In these games, players tend to find more weapons than they personally need. They hoard these weapons and hand them down to other players. This doesn’t hurt much of anything if it’s done for an “alt” character, but when a brand new player is given a bunch of top-tier gear, it can really hurt their enjoyment of the game, and hence their retention. What seems like a nice gesture from players can really hurt the game overall. But if weapons decay, there will be fewer top-end weapons to give to others, and anyway, the twinked player won’t be permanently overpowered.
  • It lets you keep your power escalation low. In most games you want players to experience the thrill of finding new equipment often. In a game with a steep level curve (like WoW for instance), you’ll get new weapons all the time as you level up. But in a game like mine where people don’t get a ton more powerful as they level up, higher-level weapons can’t get much more powerful than lower-level weapons, so what’s the point of switching weapons? Well, if your weapons keep decaying, you’re forced to switch weapons. Problem solved!

The Case Against Item Decay

The case against item decay is really simple, and really damning: human beings are ridiculously averse to loss. There’s more psychological studies about this than you can shake a library at, but for me it can be summed up in this one principle: Human beings fear loss, even more than they should. They predict that the loss of an item will hurt more than it actually does, and they go out of their way to avoid it.

In a game with item loss, there are two ways humans deal with this fear: either they refuse to use amazing items because they don’t want them to go away, or they become clinically detached from all items.

Probably the most common thing is that they just refuse to use items. You see this in any MMO that has one-use super items. I don’t know about you, but when I get a “Potion of Being Amazing For 3 Minutes”, I hoard that sucker forever. In most games, I won’t even use it to save myself from dying, because the death penalty is less painful than losing the item! (In WoW or EQ2, I wouldn’t use rare irreplaceable items unless I was in a really good group/raid and we were going to wipe… and even then, I’d have to think about it pretty hard.)

But this isn’t a big deal — who cares if people hoard their one-use quest rewards? I don’t. It gets to be a bigger deal when all items in your game can decay. Suddenly you never want to use any high-quality item ever!

Let’s unpack that idea of “high-quality items” for a moment, because it’s important. An item is not high-quality if it’s “just good enough to get the job done.” You’ll be happy to have such an item (especially if you were struggling with dangerously underpowered equipment prior to that) but you won’t think of it as particularly super-powered.

By definition, a top-tier item has to be more powerful than is strictly necessary to survive. And that means it’s never actually needed. And if it’s not needed, and is going to decay when used, that means it’s going to get hoarded.

And if you try make top-tier items mandatory in order to survive, what you’re really doing is making all lower-tier items into junk, and you’re back to square one: nobody’s excited about loot because everybody has to use the very best items already.

(I’m oversimplifying here, because it’s actually possible to create items that are “kinda crappy” without being suicidally underpowered. But I also know from experience how really hard it is to find that sweet spot for consumable items, and how hard it is to maintain that balance over a long period of game updates. It almost always falls down into items either being “junk”, “the thing we have to use”, or “the thing that’s too good to ever bother using”.)

Clinical Detachment

I said there were two scenarios that happen when you have item decay. One is that people hoard the best stuff because it’s too valuable to use. The other is even worse, though: emotional detachment from loot.

You see this in games with particularly heavy item turnover. Nobody gets too excited about even the most amazing items. “It’s nice, sure, <yawn>, but it’ll be gone soon enough.”

This means you (the designer) have a much harder time getting players excited. The game also tends to feel more like a treadmill: players can see more easily that they’re just collecting money in order to buy the same old stuff so they can collect money to buy the same old stuff so they can…

(Not that there’s not actually any more “treadmill” than any other MMO design. It’s just that item decay makes it a little easier to see.)

So once again we’re back to the same problem: we can’t have nice things, because there’s no things in the universe that are nice enough to get excited about.

If players aren’t going to be excited about loot, why bother having it? You’re better off leaving it out and focusing on something else. If you’re gonna have a complex item system, players need to be excited about items!

Gorgon Needs a Different Approach

So from a logical perspective, item decay is a great mechanic. Those problems I mentioned at the beginning are real problems, and very much worth fixing. But the psychology of loss is just too painful to me to want to do an item-decay game.

But since my main complaint is the psychology of it, maybe I can find a replacement design that fits psychology better.

And really, isn’t that what every game does? The reason your sword’s damage keeps going up and up in WoW is to force you to keep getting new weapons. It isn’t really much different than if your sword just decayed every few levels, forcing you to get a new weapon. But it feels so much less painful!

And WoW solves the problem of “hand me down items” with the trick of literally making it impossible to give great items to other people. The items become attuned to you as soon as you pick them up, and voila! No more hand me down items. It’s ham-fisted but it sure works.

But all hybrid solutions seem to have their own problems. In the WoW model, the power level has to keep escalating up and up and up forever, and at a pretty fast pace, too. If you ever get the very best set of items in the whole game, the treadmill breaks. There’s no reason to care about items anymore.

Hybrid Solution: “Permanent Plus Temporary”

I’ve been looking at different hybrid solutions for Project Gorgon. I’m calling my current plan “Permanent Plus Temporary.”

It’s a two-stage approach. Weapons, armors, and tools are permanent. So you can quest for the very best items in the game, and get excited when you find them. Hooray, you’re permanently better than before!

But by itself, the sword is kind of crap. It has to be magically sharpened (or maybe “enchanted”, or “have a new hilt put on”, or whatever — something has to be done to the item. I’m just using “sharpened” as an example).

So sharpening is not optional. An unsharp sword does so little damage that you won’t survive if you try to use it. You have to get your item sharpened, either from a professional sharpener or with a one-use do-it-yourself sharpening kit. And the sharpening “wears off” over time, requiring you to sharpen it again and again.

That solved one of the three problems I mentioned at the outset: it makes sure crafters always have enough to do. And I can fix the hand-me-down problem the same way WoW does it: for the very best items, you simply can never give them away. That’s not a particularly immersive or elegant solution, but it works.

But I still have problems with power escalation. Once you have the best item, you don’t need to look for loot anymore!

Lower Power-Escalation From Randomized Loot

In order to keep my items’ power levels from cranking through the roof, I’m using randomly-generated treasure. The idea behind randomly-generated treasure is that it uses a different reward schedule than fixed-design treasure. You have to look at every sword you get because one of them is going to be amazing. And when you find an amazing sword, there’s still a chance that you’ll find an even more amazing random item later.

So with random items, players rapidly reach a “sweet spot” of power (a little higher than the average quality level for items of that type), and then very slowly (on average) find better and better items. They have to keep looking because who knows when the randomly-better item will show up?

Lots of games have random treasure (and a few have random crafted items), but often the results are not amazing. Making a fun random loot system is a lot harder than it sounds! I remember that we struggled mightily to make Asheron’s Call 2′s treasure system the equal of AC1′s. In the end it was very cool… but it sure took a ton of time and tweaking, and it never quite had the elegance of AC1′s system.

The problem is that you can’t just graft a random treasure system onto a game; it has to be designed around it very heavily, and with a lot of subtlety. I’ll talk about random treasure another time, though, since this post seems never-ending…

(Random loot still doesn’t actually “solve” the power progression problem. It just slows the progression down a bit so it doesn’t have to keep going up and up and up every damned day.)

Better Plan Forthcoming?

I don’t feel like I’ve necessarily got the best plan yet. I’m still a ways away from actually implementing a treasure system (beyond the static loot that I have now for testing purposes), so I still have time to bat ideas around.

I’m interested to hear your thoughts on the pros and cons. There are a lot of different angles you can look at this problem from — the trick is figuring out what angles are the most important.

Posted in Design, Project Gorgon | 47 Comments