This post was originally published at www.isotx.com/wordpress/?p=118
Great post - thanks dev's for sharing your experiences on the game.
What’s it all about?
This article is based on a post was that was originally made on www.isotx.com, 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 is that, after a very long and troublesome journey, Ballerium, the massively multiplayer game that I helped make, got aired (on www.ballerium.com). If you find this article interesting, I suggest that you go and download it, to better understand the things I’m going to discuss.
Today’s Ballerium is very different from what we originally planned for it. Most of these 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.
Chiki-Kah
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 suffers 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 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’ mistakes) - 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 invested in.
We wanted to make a Massively Multiplayer Realtime Strategy game as there was 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 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 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. Luckily for Majorem, in most of the cases people were very good friends and were dedicated to the same goals.
War!
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 www.isotx.com, 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. I argued against 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 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 ׂintimately׃ 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.
Ballerium
Picking The Right Technology or Solution
Ballerium is 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. You can see the results, and if you keep in mind that the game was initially intended to run on Geforce 2 cards, that’s not all too bad, however the price for 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 do games.
