|
Nuts and Boltsby Dave Rickey So when Terra Nova invited me to become one of their contributors, I decided to take them up on their offer. With their academic focus it's a more appropriate forum for theoretical and philosophical discussions, and the format will let me write those pieces when I feel the urge, while being able to let someone else carry the ball when I really don't have anything worth saying. So on that note, I'm going to focus this column on a very "nuts and bolts" issue: Engines. An amazing amount of the work that goes into developing an MMO is typically spent developing fundamental technology: graphics engines, network support, server-side data storage, user interface API's, and other basic pieces of the games. Of all the major games out there, only one did not build their technology from scratch; my former home, Dark Age of Camelot, liscensed the NetImmerse (now Gamebryo) graphics engine from NDL, built their server on top of the text MUD engine they had been using for more than a decade, and adapted UI technology they had used for other games. The sum result of this was that the game went from prototype to store shelves in 18 months, less than half the typical time for an MMO (and comparing well with most AAA single-player titles). As I have been alluding, MMO games don't need a single engine, they need several, and developing all that technology from scratch is expensive, time-consuming, and potentially a stumbling block for the entire project. It can take a year or more to develop the core technology for an MMO, and at the end of that time you still don't have a game--you have (if you're lucky) a framework you hope you can build a game on. Meanwhile, your designers have had a year of operating in a vacuum, keeping themselves occupied by building ever more elaborate and complicated plans, with no way of connecting what they want with what the core technology will be able to do. Once the technology is finally ready, the race is on to actually build the game and have something to show for all that work, and those elaborate plans rarely have fallback positions to allow for the inevitable compromises. The thing is, we're not in the technology business, we're in the entertainment business. Our entertainment product is inherently technological in nature, but it's not the technology that sells the boxes anymore. It's time we stop re-inventing the wheel for every project, and start buying them off the rack. Fortunately, there are a variety of wheels on the market for us to choose from. For our purposes, there are basically three core pieces of technology an MMO needs, that they don't neccessarily have to build:
Graphics Engines Odds are extremely high that you are not John Carmack (I don't think he reads my column). Odd are almost as high that you are not a graphics programmer in John Carmack's league (there are no more than a few dozen in the world). And it's pretty likely that you don't work with anybody that is really that good. So, given that the expectations for graphics engine performance the customer has are set by those who are operating on that rarified plane, can you really expect to deliver what the customer expects in terms of capability, performance, and stability? Not completely a rhetorical question; some of you can honestly answer "Yes", but odds are you can't. Given that high-quality graphics engines are such a black art, it's probably better to buy the capability from specialists than to try to build it. The obvious first place to look is at the Quake 3 Arena engine from the man himself. That engine represents the "Gold Standard" against which all others are judged. Unfortunately, the number of licensees is capped, so you probably can't get it. I'm not going to try to give a comprehensive list of alternatives, or a full discussion of their capabilities, but just hit some of the high points: Gamebryo, formerly NetImmerse. Obviously I have a bias towards this engine, it's been at the core of my last two projects. It's a very flexible engine that has been used for everything from FPS to RTS to Racing titles. The license does cost a significant amount, but the support is excellent and the engine is solid. In addition to Camelot, Gamebryo is being used by my current employer and by Codemasters for Dragon Empires, making it the most used engine for MMO's. This has its drawbacks: all three games show a similarity of appearance that probably derives from how the engine handles animated models. Jupiter, formerly "LithTech". This is a fully featured engine, but like most it was developed primarily for FPS games with an emphasis on extremely high quality animated models and comparatively low geometry counts. However, it has been used for one lesser-known MMO, Rubies of Eventide, so the technology is adaptable to the purpose. As I understand, it has some of the more flexible licensing terms and more capable integrated tools. This is a major engine that is available for license, but it has been used almost exclusively for FPS titles, and has all of the limitations that go with the type. For the right title, it could certainly deliver visuals and performance comparable to anything on the market, but the client, server, and network code are tightly integrated and would probably require significant rebuilding for the needs of an MMO. Originally developed for Tribes 2, unlike most FPS engines T2 was mostly set in an outdoor setting with both ground and air vehicles. It also has the lowest up-front cost of any of the commercial engines: $100 per seat. The one catch is that the royalty structure for MMO games would have to be negotiated, and Garage Games primary focus is on "Independent" games with lower volumes. Assuming reasonable license terms could be worked out, the engine could probably be adapted to a large variety of MMO types. You can't get cheaper than free. The catch with Crystal Space is that it is liscensed under the LGPL, which means that any game built using it would have to distribute its source code for the client to any player that asked, and probably the source code for the server to any partners that operated servers (unless the server was separately developed from scratch, rather than adapted). However, for small scale independent projects involving small budgets and small staffs, this engines might be an attractive alternative to the Torque engine. Also, the OSS process has the potential to significantly improve this engine, and it may become a much more solid platform in the fairly near future. Data Storage In my discussion of graphic engines, some may feel I slighted the open source alternatives to commercial products. I suspect OSS advocates will be somewhat more pleased with my assessment of data storage alternatives: There's little question that Oracle is the best performing RDBMS system on the market. It runs on platforms ranging from X86 to custom-built supercomputers, and is the most feature-complete options available for any data-management function. It is also the most expensive, and requires expensive specialists for administration. I would dismiss Oracle out of hand as a Cadillac solution for pickup truck problem, but it was used for Star Wars Galaxies. Those without the LucasArts deep pockets to draw on will probably want to look elsewhere. Not as high-performance, high-reliability, or feature-complete as Oracle, the Microsoft SQL Server is a lot cheaper and much easier to license. You can buy it off the shelf and use it as a commodity solution without much fear of complications. It's a workable choice, and at least one MMO game I am contractually obligated not to specify used it for their game server data storage. However, its primary recommendation for use is "No one ever got fired for buying Microsoft". MySQL is an OSS product that also comes in a commercially licensed and supported version. In either form, it has both strengths and weaknesses. High on the list of strengths is low cost and good performance for certain kinds of data access, on the down side it is fairly limited in features and requires a particular kind of programmer with the right skills to get the best performance from it. The greatest strength is that if your architecture is set up right, you can stretch performance a long way simply by throwing more hardware at the problem. (Out of the money you saved vs. buying one of the above, you can buy a lot of hardware.) Dark Age of Camelot uses MySQL for a variety of functions. Another OSS product with a commercial variant, PostgreSQL is somewhat richer in features but lower in overall performance than MySQL. In my personal judgement as a former client/server programmer, the tradeoff comes down in favor of PostgreSQL, but the case can be made for either and the specific implementation could tip the balance either way. Game Server There used to be a proven MMO game server architecture on the market from Turbine. However, it has apparently been withdrawn and no proven MMO server engine is now available. Backed by IBM's Grid architecture, Butterfly has impressive technology, but a potentially restrictive set of conditions. The grid itself is owned by IBM, and there is potential trouble down the road when it is time to renegotiate contracts. (You can't exactly threaten to take your customers to some other implementation of Butterfly on someone else's grid computing infrastructure.) To solve the chicken-or-egg problem, an initiative to offer free service and support for academics who want to use games for research was recently announced. Potentially this is a huge opportunity to leverage the assets of one of the world's largest technology companies. TeraZona was all over GDC last year, sponsoring a special track on MMO technology. However, since no-one I've spoken with seems to have attended, I know almost nothing about their technology. (Disclosure Note: Not only does Wish use ICE for its server, but several of the programmers and executives are former employees of ZeroC, the company that developed it) Another OSS+Commercial product, ICE is a general-purpose distributed-computing architecture that can be adapted for MMO servers. It's a mixture of C++ and Java, and runs natively on Linux. Conclusion Of these three, there's absolutely no reason you should build your own for anything but the server architecture. It simply makes no sense to spend money rebuilding the core functionality essential to a game, when making the game is quite difficult enough in itself. For the server architecture, the needs of an MMO are unique enough that rolling your own may be justified, if you have the budget to support it. Even there, the option of using an outside package should be considered.
[ <— #11: Pursuit of Knowledge | #13: Plan Your Fight —> ]
|
