Technical Considerations

Don't worry; we aren't going to try to make a definitive statement in this section on just what technology you should be using to make an online game. Let it be said that if you're working with some flavor of C/C++ with a compatible compiler, DirectX for Graphics functions, Linux, or Windows NT/2000/XP, and one of several art packages like Maya or 3D Studio, you're in good company.

What we hope to do here is give you some guidelines on what others are using, list some of the tradeoffs they consider when picking software and deciding which world-building tools to use, and discuss whether it matters in what order the worlds are built. The tradeoffs can be critical; for example, do you choose cutting-edge 3D first-person models and objects with many polygons and textures, knowing that these have the potential to create perceived latency on the player's computer, or do you opt for something a little less intensive in the hopes of creating less perceived lag for the player? What you do here and now, at the beginning of the project, determines whether the post-launch live team is going to need a Prozac dispenser in the coffee room five years from now.

There are also business tradeoffs to be considered . For example, consider the Asian market that is heavily into isolinear/God's-eye-view games . The first/ third-person style persistent world (PW) is untested there as yet, although EQ should be available in Korea and China by the time this book is printed.

Planning to Extend the Game for Years

All other factors being equal, there is no reason an online game can't and shouldn't have years of life. Unless, of course, when you get down to choosing the technology and designing the software, you forget to make it easy to add features and content to the game.

This seems like common sense, doesn't it? Yet you'd be surprised how often this necessity is ignored. Up to this point in the history of commercial online game development, forgetting about making it easy to add content and patch the game has been the rule, not the exception. Some of that has been pure business; a publisher would rather sell an expansion disc than just download little bits of new content here and there. In some ways, that is penny-wise and pound -foolish; the money in PWs is in the subscription fees, not the retail package. Being able to easily refresh content without requiring a trip to the software store can help keep players subscribing to your game for years.

On the other hand, lack of forethought has been the major contributor to this state of affairs. For some reason, developers have had a hard time getting out of the "designed, developed, tested , finished!" state of mind. Since your development team is unlikely to be the same team that manages the game after launch, you have to continually remind them that the process is more one of "design, develop, test, install, wash, rinse, and repeat until retirement."

What this means is that a PW development team must pick core technology and design database arrays that enhance the virtue of content and feature addition with as minimally small client patches as you can get. Without considering this, you'll be creating problems the live team (the people who support and update the game after it goes live) will have to deal with for years.

You also need to understand that if you don't make changes to the game over its lifetime, you are seriously limiting the extent of that life. Constant refreshment of the content, upgrades, and additional features are all necessary to keep the veteran player interested. Without them, you won't have the retention rate necessary to sustain the game long- term , and loyal players will move on to the next new thing sooner than later. That means you have to plan for this in the design and make sure the process of adding content and features is going to be an easy one.

Comments? What Comments?

In this day and age, when most programmers recognize the need to comment their code so that those coming after them know why any particular piece of it was written and what it is supposed to do, you'll find many game developers who don't comment their code at all. This is even more prevalent in the online game industry; there are hideously complex PWs in operation today without a single comment anywhere in the source code. There is a school of thought in the game industry, in fact, that says commenting code is just a time- waster , for sloppy programmers who can't write elegant code that is easily understood . This ignores the fact that most programmers can't agree on what "elegant" code is, much less write an example of it.

It is insanity of the first order not to insist on comments. Ours is one of the most mobile areas of the job market. People change jobs and move to new companies every couple of years, on average. Much of this has to do with the fact that publishers are constantly laying off employees at the end of the year, scheduling many projects to finish just in time to ship for the Christmas selling season . They tend to staff up again for new projects in the spring, and one has to wonder if the reason why so many projects are late to ship is an unconscious (or not) attempt by some programmers to extend the paycheck cycle a bit.

Whatever the reason, it is a safe bet that not every programmer who starts a project will finish it. If that programmer's code is not commented, whoever the replacement is could spend a considerable length of time figuring out the code and its effects on other pieces of code. In projects that can easily exceed 800,000 lines of code, knowing how the pieces interact with each other is a requirement, not a luxury. There is nothing worse than having to replace a critical coder at a touchy stage of development and then finding out it will take three to six months for the replacement to fully understand the legacy code because it is uncommented.

So, a cardinal rule for the team must be comment the code. It is up to the team leaders to establish the standards (Comment algorithms, data, or both? Comment by line or by blocks?) and follow up on them by checking the code and ensuring that the team is, indeed, commenting the code.