MMO Development Experiences

What’s it all about?


This article is based on a post was that was originally made on, at the blog forums. It triggered quite a debate there, and so I decided to improve it a bit, taking on some of the conclusions and clarifications made there. While the title is “MMO Development” it’s only because it originated from discussing the development of an MMO game, Ballerium, however most of the issues can be adapted to any large-scale game development.

The trigger to the article was that, after a very long and troublesome journey, Ballerium, the massively multiplayer game that I helped make in Majorem, got aired. It didn’t last long, though, as it didn’t have the financial backing required to nurture a game (and community) of this magnitude.

The Ballerium we ended up with, was very different from what we originally planned for it to be. Most of the changes are for the better, but some of the changes were forced upon us due to the circumstances of the development as I will shortly describe.

While all in all we got a very nice game up in the air, a game that’s fun to play and addictive enough to stay, it still suffered from several problems. If you are what they call a hard-core gamer, you will get over the confusing interface and the sometimes strange (even if not completely senseless) design decisions, however if you are a casual gamer you will find the game difficult over the first hour or two, which is also what kept most of the cash-generating public off the game.

So I guess the big question is: how did we come to that? What good decisions were made, what bad decisions were made throughout the game’s development history?

In order to spare you guys from having to go through the same mistakes (someone once said that a smart man learns from his mistakes, but the smarter man learns from others’) – I thought to maybe tip you guys regarding some of the obstacles on the way to making your great game, so that you can avoid them.

How it got started?

To understand things in their right context, let me tell you just a bit about the game and how it all began.

It’s name is, as I said, Ballerium and it’s a very innovative mmo-rts game – innovative in more than one way, both in concepts and technology. Development started somewhere in 2000 or even a bit before, while we were only incorporated as a company and started to kick in, on 2001 when we got financed.

We wanted to make a Massively Multiplayer Realtime Strategy game as there were none on the market at the time, and as we figured MMO was going to come up strong while RTS is one of the already-strong game genres out there. We (and our investors) also hoped that once the genre would prove its value, we could also build up based on the large set of technologies that we would be developing for the game. We didn’t have a lot of money to develop, but we were willing to heavily cut back on our own salaries to make this happen.

Naturally, I can’t cover years of development with one short story so I’ll only focus on some of the things, and if there’s demand, I’ll go on with more tips next time.

It’s hard to pick where to start, so I’ll start with the issue of people.

Picking people

That’s so obvious that I thought not to write it, but then again it’s so obvious that it had to be on this list. Picking the right people to work with is maybe the most important decision you make, and it’s even more crucial early on when you start.

Here are some thoughts and pitfalls:

- Sure, you like to work with your friends – but do all of them qualify? In some cases, adding another person to the group will just slow it down.

- Sure, you like to work with experts, but can you guys be friends (or, at the very least, get along smoothly)? During development, issues will arise that you guys would think differently about. X likes the default dwarf weapon to be Green and do 3 damage every 4 seconds while Z doesn’t want any dwarfs in the game, because they just don’t suit a space game, or so she thinks. How would you settle this without proper communication?

It isn’t pleasant to admit but at times in Majorem we had arguments so loud that 15 people slowed down to 20% just because 2 others were shouting how something should or shouldn’t be implemented. In worse cases, 2 others did not shout. One wrote a spec for a system in the game and another sat down and implemented a totally different mechanism that doesn’t live with the first. Despite that, and luckily for Majorem, in most of the cases people were very good friends and were dedicated to the same goals. However had we made slightly better choices in that respect, we might have had come closer towards our goals.

Picking and Defining Goals

This leads to another issue: picking your Goals and clearly defining them. Everybody in Majorem knew we were developing an MMORTS, and that’s a fine goal. Everybody were also rather committed to that goal. It’s just that early in the development, not everybody understood that goal the same way. For example, some expected more RPG elements in the games, others less. This led to a confused design that tried to please both and ended pleasing very few. It also led to the development of support to unneeded functionality in the game that resulted in waste of time developing them and then more waste of time debugging them or removing them from the game to make it more efficient.

When I originally posted this article on, a strong debate occurred around the issue of detailed design. The person who argued against me held that a detailed design and research done in advance, could have saved us.

While to this day I make a significant part of my income from game design, I want to set expectations right. I argued against his view saying that while design and research are the most cost-effective parts of the project, it is (A) impossible to foresee everything in advance in large projects such as this, (B) Some of the technological solutions thought of in the research phase could prove wrong / not good enough due to the many dependencies each of the subsystems of an MMO game has, and that (C) in some projects, Ballerium included, sometimes the development itself IS the research, since new technologies are involved. I compared it to Thomas Edison’s search development of the light bulb. The fact that he had hundreds of experiments before getting it right does not indicate that he had done poor research prior to developing the bulb. These experiments were the research of it as much as they were the development of the light bulb, at the same time.

It’s not that we didn’t have a detailed design document. And as for research – I think it took us about a year of discussions and experiments before we really started to kick in with the real code. It’s just that due to the size of the project we sometimes got lost in the details. Until very late in development we lacked a much shorter and clearer definition of what the game is and what the game isn’t, and the general goal got sometimes lost in the details.

Under the (unacceptable) justification of “It’s a 300 page book, so it’ll take me two full month just to read and understand it”, some developers just read whatever they thought was relevant to them, losing sight of the bigger picture with the ability to suggest improvements or detect problems early on.

Had we also done a brief version of the design document, the bigger picture would have been much clearer, and some design mistakes might have been saved – such as the will to try and please both RTS and RPG gamers.

Picking The Right Focus

Once you selected and defined your goals, it’s also very important to balance their weight in the game properly. Drawing on the RPG/RTS conflict mentioned above, we came too late to realize that we gave too much weight to the RPG dimension of the game, and that we need to tone it down a bit.

Eventually we ended up having an interesting and innovative design, but at what cost!

Here’s one feature we didn’t remove: Any unit in Ballerium can level up, have its own weapons, and later even be managed as a hero with full RPG characteristics.

Of the top of my head, here’s just a short list of issues that the integration of RPG characteristics caused:

- Higher bandwidth consumed

- Slower server response time

- Players now got attached to all of their units while you’re not supposed to in an RTS, which caused some players to leave the game after losing a big battle

- Many more code lines = Many^2 more bugs

- A more complicated battle system

- A more complicated pathfinding

- A Game that is more difficult to understand

- An interface that is more difficult to manage

- Graphic issues (instead of “molded” models we had to configure models that could carry any weapon etc)

So this is a classic example of an extra feature that seems nice and maybe also simple but ends up risking the entire project by forcing you to focus on less important (if not un-needed) corners instead of the core issues.

Need another example? We started developing an innovative quest system that would add content (theoretically: even user-generated content) to the game by gathering and using a lot of in-game information, such as who conquered what city, what special item was discovered where, which units saw other units etc.

Apart from forcing us to use an explosive DB that would be difficult to handle even with today’s servers, we also made the mistake of focusing on nifty technology systems of following data and spreading it (i.e. unit that “sees” another unit was considered to have spoken with it, causing it to “know” quest-related information - well we could have just faked this system with little to no effect on the user, while focusing instead on generating a more interesting game-mobilizing quests, such as “The god of the Blue sun would give you a 10% Karma boost if you hit on player X” (which is twice stronger than you). These are the things that would have caused interesting, not boring decisions, triggering addiction to the game. We just focused on the technology and ended up freezing that feature for the number of bugs and complications that were involved with it.

Picking The Right Technology or Solution

Ballerium was a 3D game. Due to some of the game features, back in 2001, 2002 we didn’t find a 3D engine that provided what we needed (for example in terms of dynamic map of this size).

We chose to deal with it by developing our own 3D engine. If you look around in the web you can still see the results in articles or even utube clips, and if you keep in mind that the game was initially intended to run on Geforce 2 cards, that’s not all too bad graphics for hardware, however the price for making this was high and if we weren’t so lucky to have the 3D expert that we had on board from relatively early in th project, things could have been much worse. Also, even as it is the game’s 3D engine sometimes messed up just when we needed it the most: in trade shows, where it was presented on laptop computers with odd graphic cards.

Looking back I think there could have been several other ways to engage this issue that would probably be better, and who knows, maybe that one presentation that went wrong, would have gone smoothly and the game would have received a better development budget.

Some examples to picking an alternative solution:

- We could have used 2D technology. As we were looking into the Asian market anyhow, this choice would not be taken so badly, as even today some of the 2d MMOs are successful in southeast Asia.

- We could have adjusted the game design to match existing engines. Back then we were so convinced that we needed the map to be able to scale endlessly (In large part, it was my mistake), that we overlooked solutions for very large yet limited worlds.

Picking either of these could have saved us a lot of time and money.

Although there’s more, here’s just another small thing to end this “what went wrong” section: Picking a name.. Ballerium? Majorem? C’mon! We could have done better! No one remembered “Majorem” because it didn’t connect or say anything to anyone. And Ballerium sounded to many like a game that has something to do with balls…

Picking Right

I feel I must stress again that despite all of the above (and much more that I can dwell on in future articles), Ballerium turns out to be a very nice game, addictive even, if you manage to get over the total chaos of the first hour. How did this happen? Well obviously, we made some very bright picks as well. For example:

- We picked some great people, most of the time. Some of the people we hired earn twice or more than they used to earn in Majorem. They knew they could get it on the market even then, but they identified with Majorem so much that they stayed with us. Our 3D expert was indeed an expert. Our CTO is one of the best software engineers in Israel. Our content programmer was so much more than just a content programmer. Our artists made the impossible with almost no means. And the list goes on.

- We picked the right exhibitions to show in. (Although now I think that we might have spent too much on on or two of these, generally speaking it gave us great coverage, and a great publishing deal that funded the game development for most of the time.

- We picked a great, unexplored game genre to develop. A niche just right for a company our size.

- We picked great solutions to many of the design problems that the new genre posed (maybe more on that later on).

We picked to make games.

Posted in My Theory
RSS 2.0 | Trackback | Comment

7 Responses to “MMO Development Experiences”

  1. many of the things you can say about other fields that not related to games.

    do you realy think a game in this genre could succeed today?

    one more thing I think about from my experience, you need to think about how getting money from the game from the start.
    If you can’t make profit from it, specially from a game in this scale, you can’t support it. and you can’t make more games for living.

  2. “do you realy think a game in this genre could succeed today?”

    The best shortr answer I can think of is, “Why not?”
    The long answer says that strategy still is a strong genre and MMO is more than 10 times stronger than it has been when we started developing Ballerium. If done right, and if published with a strong publisher, MMORTS can go very strong.

    as for thinking about the money from day one – That is for granted. And this is also how it has been for Ballerium. The vision was accompanied with a lot of business thought side by side with the thoughts about the technology, design, and inplementation of the game. The fact that we couldn’t raise the required funding does not indicate that we did not think we need that funding, or did not expect to return it, on the contrary.

  3. Are the people who play RTS are the same who play MMOs?

    from experience from a total different field, I think that you should think about other solutions of getting money instead of funding.
    funding is still a big option, but you should be prepared for a situation of not getting funding

  4. Shepherd

    “Are the people who play RTS are the same who play MMOs?”

    I would definitely say so. I enjoy both RTS and RPG games, online and off. Most RTS games get their longevity through online play, not single-player combat. A RTS game could fit perfectly into the MMO format. Someone just has to figure out the proper way to take advantage of that.

  5. Well, I do agree that there are many who like either RTS or MMO but not the other, but I also think that many like both genres, and also that some who are not particularly thrilled about either genre, can be find this combination more thrilling.
    My wild guess is that potential people who would pay for an MMORTS if they came upon a nicely done one, is somewhere in the ballpark of 100,000 to 500,000.

    As for De-Panther’s latest remark on funding, I believe that while the game, when done, can be a healthy source of income, it still requires a lot of resources to get there. If you don’t have them upfront then you’ve gotta get it funded somehow. The game won’t pay for itself during development, and serious MMO games can’t just get done in garage – Majorem’s Ballerium was the closest attempt to that, and it was really pushing the line with regards to how much it required from how many people.
    MMOs usually require large and stable teams, and such teams can’t hold for long without an appropriate funding (unlike small teams making casual games, for instance; also see

  6. My name is Piter Jankovich. oOnly want to tell, that your blog is really cool
    And want to ask you: is this blog your hobby?
    P.S. Sorry for my bad english

  7. A hobby and my work.
    (And thanks for the compliment).