Elder Game: Indie Games, Prototyping, and Fun Finding

This Blog Post was part of the Elder Game blog. It was posted by Citan on June 14, 2010.

Previous Post: None

Next Post: Elder Game: New Year, New Method

Additional Blog entries can be found on the Developers page or in Category:Game Blogs

Our indie MMORPG development continues! Together, Sandra and I are able to put about 20 hours a week toward the game, which isn’t much, but makes continuous progress. It’s coming along well, and it’s been very exciting to get past the nuts and bolts and start prototyping gameplay.

I’ve been avoiding talking about it because, well, it’s a little indie project and I normally like to talk about much bigger games. But this experience just has too many interesting bloggable topics — as well as funny moments during prototyping — that I can’t help but talk about some of them!

First of all, the biggest early risk in an indie MMO is having the wrong mindset.

Prototyping and Guerilla Development

When you’re just a couple of people trying to make a big game, every day of development time is precious. You have to choose what to focus on: graphics, technology, or gameplay. But that’s a trick question. You should choose “gameplay” because that’s the only one a small team can compete on. You need to spend most of your effort on making a fun game, and just the barest possible amount of time on the underlying technology. Making an indie MMO means cutting corners — cutting every corner you possibly can — to save time and cost.

Repeat after me: nobody cares how cool my server tech is. Say it! If you don’t believe that mantra, then there’s no sense trying to make an indie MMO. You will get stuck in technology limbo like everybody else does.

I mentioned earlier that we’re using SmartFoxServer as the base of our server, and several people have asked us why. For instance, in a recent blog comment, ‘Jason’ said:

I’ve done commercial work with SFS. I’d say it’s just as I described it as well. if you want to chat, it’s probably fine for that. But it really is junk for anything more.

Everything it does can be replicated by a good server side Java programmer in a couple of weeks and not suck.

Jason is right: there is no magical goodness inside SFS; it’s kind of clunky and mucky inside, and all it really has is a fast messaging-relay system written in Java. But let’s assume Jason’s estimate is right: one engineer needs two weeks to replace it. Eighty hours! TEN FULL DAYS of development time, just to replace a cheap off-the-shelf component! This sort of comment reflects the dangerous technology-limbo scenario I’m talking about (no offense, Jason). It reveals an all-too-common tech-centric mindset that is not going to help you ship a game.

One of the best engineers I know started working on his own MMO when he was out of work. But all he ended up with was some cool streaming technology, because that was the part that was interesting to him. And I too have fallen into this trap myself on several previous attempts — our home SVN repository is littered with the husks of MMO’s that will never be, each with one kick-ass technological feature, and nothing else.

We’ve found that the best mindset to have is very similar to the mindset you would have if you were making a commercial MMO prototype (that would later get rewritten into a full commercial release): focus on making sure the game is fun first. Fun is the most important thing. Only then do you even consider how the technology should be tuned.

Of course, the difference between a commercial prototype and an indie MMO is that when the prototype is done, a team of 12+ engineers rewrites everything from scratch to get the highest performance and the best-looking graphics possible. For an indie MMO, the prototype is the game. You refine the prototype, caulk up the seams as best you can, maybe strap some more motors on here and there, and ship it!

So this is a very tricky balancing act. It means being agile as hell, and it means that 90% of the time you skip worrying about the technological details until you’re sure you need them… but at the same time, you don’t have the luxury of rewriting it from scratch later, so in a few places, you really do need to plan your tech ahead of time to make sure your game can float. No amount of caulk and spit can save an MMO engine that is intrinsically tied to failed underlying components.

Unfortunately, the best advice I can give you is “work on a commercial MMO or two, and then you will know where you can cut corners and where you can’t.” I don’t have a list or corners not to cut (though maybe I will try to make one now that the thought has crossed my mind). For instance, you need to insulate yourself from your serialization solution, and you need to isolate your game code from your networking code. But don’t go overboard! When I tell people to insulate their networking, they inevitably reply with, “Oh I totally did that, check out this wicked six-layer class hierarchy that perfectly encapsulates…” no. Wrong, bad. You need to isolate it JUST ENOUGH that you will be able to replace the subcomponents later. Spend a few hours, then move on. You don’t want to PERFECTLY wrapper anything because that wastes time. You don’t even know what’s going to be important yet!

So making an indie MMO is like prototyping a game, yet mysteriously knowing just how to code your prototype so that it can later be made to work under live loads. I… I need to figure out how to define this better in future blog posts, don’t I?

Of course it’s inevitably going fail in some ways, and you’re going to have to scramble to fix things, painfully. But the alternative is having clean tech but no game. That is what most people end up with.

But you know what? It is incredibly tempting to rewrite SmartFoxServer from scratch. I could do it so much better! But I’m not falling for that trap again. We may very well need to replace it, possibly with ElectroServer or some other similar product, or possibly with a home-brew solution. But that will not happen until we have a fun game prototyped, so that we know precisely WHY we’re replacing it and what the goals are. First, we have to make it fun.

See If It’s Fun First, Stupid!

I just have to keep reminding myself: don’t code infrastructure until you know the basic premise is fun. That seems like common sense, but it’s very hard to do! For instance, when we implemented combat, what’s the first thing I added? I implemented WoW-like combat statistics and all the things that go with it, like armor ratings and stat buffs and so on, because of course that’s where combat starts. Dumb, dumb, dumb!

Only then did we start exploring exactly how combat should work for the game we want to make. The first thing we threw out was WoW-style armor ratings. It’s boring. So all that code went out the door.

Admittedly that’s not a lot of code in this case… but if it was, would we have been willing to throw it all away in the name of fun? I’m not sure. That’s the other danger of writing code that isn’t fun: you get attached to it. You don’t want to throw away hard work!

So try not to write infrastructure until you’re sure you need it. Not always possible, but something to strive for.

Follow The Fun

What's that icon mean? Oh he's vulnerable to fire! Better use the fireball power.

Of course it’s not as simple as “sit down and code something fun”: you need to know who your target audience is and what each game system is trying to achieve. (This is extra important for an indie game!)

I’ll go into our target-audience analysis some other time, but we used that information to decide how combat should be: mostly soloing, no PvP, and as engaging as possible. While combat shouldn’t be necessarily HARD, fighting monsters should require a bit of thinking and reacting; there shouldn’t be a perfect order of abilities that works the same for every fight. So we’re exploring ways to achieve this.

But we want the goals to be a guide, not a straight jacket. Follow the fun — if you accidentally stumble upon something interesting, explore it and see where it takes you.

For example, right now monsters have “spontaneous vulnerabilities.” When an icon suddenly starts flashing over a monster’s head, that means he’s vulnerable to some type of attack. Better use that attack type quickly to kill him fast! This has proven to be a fun mechanic because it keeps you on your toes. So far so good — a basic mechanic that meets our goals.

I discovered this skeleton's weakness! It's... oh... that's not too useful. Also, TMI, skeleton dude. But that is kinda funny... Let's explore this idea...

I wanted to expand on this mechanic, so I added an ability you can use to make a monster become vulnerable immediately, so you can take advantage of it when you want to. That was interesting, but not quite right: it needed to only work sometimes. But having it “miss” is boring. (Missing is always boring, unless you’re the one doing the dodging!)

So now the skill always finds a vulnerability… but sometimes that vulnerability isn’t something you can use in combat. I rebranded the ability as “Psychoanalyze”, and now monsters have phobias and quirks that you might discover. For instance, sometimes a monster is afraid of spiders, or heights, or success. I just tried it out on a whim, and it was fun and funny. Now I’m exploring how an entire Combat Psychology subsystem might work.

Will any of this be in the final game? I don’t know yet. But I suspect some element of it will, because even after many hours of play I still laugh when I fight a giant wasp whose only weakness is a crippling fear of success. Tuned just right, this might be the sort of offbeat, indie, niche fun we’re looking for. (And “Psychology” wouldn’t be too out of place, given our other prototype skills like Mycology, Acupuncture, and Chutzpah. This is going to be an unusual game, I think.)

I don’t want to make it sound like we just sit down and go “let’s code stuff and see if it’s fun!” Our goals for the combat aspect of our game constantly inform our decisions to either explore or abandon an idea… but we still poke in corners to see what we find.

I guess the summary of this blog post is: making an indie MMO is crazily hard, so remember to cut every corner you can, focus on making fun gameplay, and try not to implement things you don’t end up needing.