Indie Games, Prototyping, and Fun Finding

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.

This entry was posted in Design. Bookmark the permalink.

15 Responses to Indie Games, Prototyping, and Fun Finding

  1. Jason says:

    No offense taken. :)

    However, I do take your point. My root problem is that my MMO concept isn’t that simple. It’s also unfortunately the only one I like enough to motivate myself to actually do.

    There’s a few reasons I’m going for technological robustness. I like to think after almost 20 years of doing this for a living, that one of them isn’t the fact that the infrastructure part is the fun, sexy part. Unfortunately for me, it’s not right now. It’s a freaking hard slog, but I know from past experience that if I hadn’t done that work up front that I would be in serious pain later.

    So the reasons:

    First – plan for success. It’s just something I like to do in general. That doesn’t mean I am preemptively optimizing things so much as I have a performance requirement and am trying to hit it. This leads me to the second bit.

    Second – Have a backup plan. In my case the backup plan is the MMO itself. I’m actually addressing some pretty gross technical problems that I’m in a fairly unique situation to address – My day job is working on an uber-scale backend, my previous project was a highly scalable MMO, and my current MMO project is a design that in the success case, requires the technology to succeed.

    That said, the primary plan is actually to get funding and license the backend engine. I’m actually not doing too badly on this front, and when I have the first proof of concept working for the major tech involved (hasn’t been done yet, in the games space anyway), I’m going to be actively pursuing investors. It’s actually looking good, there’s already interest.

    This is of course the exact opposite of your approach, but I respect yours. Yours is by far the more correct way to do it, if you’ve got a game design you love (and thus can motivate yourself to do). Mine unfortunately won’t work with junk like SFS. Hell it might not even get made, but the core requirements will drive the backend requirements and make a hell of a good MMO engine.

  2. Jason says:

    Didn’t mean to sound too secretive there, but don’t want to talk about it in public yet. Feel free to email if you want to discuss it more.

  3. Stabs says:

    It’s interesting watching you two lock horns over this. I suspect from my uninformed perspective that it’s like writing a novel where some novelists insist that the best way is to just write right away and some will argue that it’s best to plan everything out first. Different techniques work for different people and for different projects.

    A MMO is a complex creation and it may be too reductionist to say find the fun first then develop the engine. For a Mario type game sure, you define a fun simple gameplay (jumping over stuff) then run it through a simple engine. But for an Eve type game? The fun is the complex interaction of multiple systems any one of which would be less fun without the others to support it. And that’s more or less true of any MMO, otherwise they’d be equally fun offline.

  4. Kriss says:

    Actually my advice against smart fox would be that java is slow to write and the opposite of agile development. :)

    A dumb server is literally a page of code.

    The only important tech is making the servers side code fast and easy to create, the speed it runs at or the scaling problems it might face in the future are inconsequential.

    Much of an MMO sits server side and is human interface code that needs to be reworked constantly as humans interface with it. Human interface code belongs in a sloppy language.

    I’m not advising you to change, just agreeing with your reasoning but disagreeing with your conclusion :)

  5. Mike Hillyer says:

    When I was doing my research I looked at NetDog:

    They now have an affordable indy price, and integration for Unity built in.

  6. Pingback: Invisible Processes « Something Shiny!

  7. Cat says:

    I laughed until I had tears in my eyes about the wasp with a crippling fear of success. I do think you have found something to explore. I am now imagining fighting said wasp, allowing it to believe it might win and thus causing it to sabotage its own efforts.

    It’s the perfect essence of the two of you and a great way to re-imagine MMO combat. I like your niche so far. :)

  8. Todd Berkebile says:

    “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.”

    This is the core Catch-22. Only by having the experience of having done this many times can you know which things are critically important and which things are excessive. I completely agree with Eric’s statements here. In fact I’ll go even further, if in doubt assume you don’t need it. Don’t code any tech until the game forces you to make the new technology.

    But having said all that, personally I just love coding tech more than designing games. ;) I’m not delusional enough to think that’s the path to success, but it sure is fun.

    And Jason, my other advice would be don’t waste your time trying to make MMO middleware. The big players in the market like Hero and Big World are slowly failing after millions of dollars spent. Other companies are working their way towards bankruptcy trying to provide offerings for this market. The middleware that is surviving is the middleware that is more generic and supports a wide range of games. The MMO-specific middleware market is all dried up. Besides, the most successful middleware companies all started by making a game and then later realized others might be able to use their tech.

  9. Todd Berkebile says:

    “I don’t have a list or corners not to cut…”

    How about “version everything” as a corner not to cut? Then you can more easily fix your inevitable mistakes by bumping the version number. It’s better to have a few useless versions that never change scattered about than to get stuck with no way to fix or tweak some important element later on.

  10. Darrin West says:

    I’m thinking there is a lot more similarities than people might think between an Indie MMO development and a well-financed studio that will wind up shipping on time, on budget. I’m also thinking about the adage that art is about economy: doing a lot with only a little (time, supplies, movement…). Austerity. I’m always amazed by how well a game designer can design their way around a technical limitation. We developers need to put our ego on hold and admit that we can’t build something better. Not because we suck at building stuff, but that we don’t have the time or resources. Trust that the designers can design around that.

    Getting the game fun is always more important than a perfect infrastructure. You can’t make money if no one plays your game. But you can make *some* money if your server doesn’t support twice as many players, or if it has to be rebooted twice a day.

    Publishers don’t care how cool your server tech is. Publishers give you money if they think the game will succeed. That is based on how fun the game is, and whether there is something they can see (or better yet, can play).

    Content developers don’t care how cool your server tech is either. They care how easy it is to get content into the game at shippable quality. And there are a lot more content developers on a reasonable sized game team than anyone else.

    The flip side is: build your server to be loosely coupled so you can replace parts that measurably don’t perform (there will be lots of “important” parts that just don’t show up on the critical path, and you probably don’t know the difference to begin with, so don’t optimize everything). Make your server scale-*able*, but not necessarily large-scale to begin with. Then, even if you don’ t have time to replace software, if you wind up hugely successful, you have the option of throwing hardware at the problem.

    Have you ever thought about how the Portal team found the fun? Before or after the cool tech was finished?

    BTW, Eric, I’m now working on a game that makes use of Smartfox. (I have just about eaten all the humble-pie in the fridge. :)

  11. Wayne Riddle says:

    Nice post, glad to see the development is coming along. Good to see the insight from you and others in building an indie game.

    Fun is the main thing. Fancy graphics can catch your eye but to keep your attention it has to be fun.

  12. Mike: NetDog looks cool, but sadly its Unity mode requires you bundle it with a downloadable Unity game — it’s not compatible with the Unity web plugin, which is what we’re targeting to start.

    Stabs: Sure, having lots of people do the same things as you definitely increases the fun level, and sometimes you can only find a synergistic fun when you have a lot of people playing a game. However… I think that’s a lot more rare than you’d expect. I mean, imagine how much more popular EVE would be if they had taken the time to make the minute-to-minute details of mining and trading actually fun! (Yeah, I went there.)

    Todd: that’s a good one for the list.

    Darrin: I… I’m sorry to hear that :)

  13. Pingback: Indie Games, Prototyping, and Fun Finding : iOpixels

  14. ashkan says:

    take a look at and it’s great photon product. it’s udp based fast MMO server engine with support for C# scripting for the serverside code. it works on most platforms.

  15. Faust says:

    I found the screenshot about the skeleton archer hilarious. This is a really interesting and funny mechanic. Keep up the good work!