|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Things That Went Wrong 1. Young and naïve. Ritual is a new company and it went through a lot of growing pains during SIN’s development. Many new faces came into the company, and many left. Actually, it is only now that the dust has settled that any real sense of a bona fide team can be seen. Our newly formed tribe felt little sense of cohesion, as most members were basically strangers to each other. A real team requires lot of faith and trust in order to act as a unit while performing something as creative as game design. This fact was especially evident in our decision-making processes. A clear vision was often muddled by too many inputs; settling on specifics often became impossible.
We’ve also identified an almost crippling realization that comes to all game developers during their first full game: We call it the Making Games Isn’t a Totally Cool Job Syndrome. Crunch time sets in far too early, and a game’s development cycle soon becomes a 24-hour-a-day, 7-day-a-week ordeal that lasts a year or more. Only hardened veterans know that the effort will prove worthwhile in the end, and that the end can be a long way off from the seemingly endless now. 2. Integration of the Quake 2 source code late in the project. Sin was originally scheduled for a Spring 1998 release, and we didn’t get the Quake II source until late December 1997. We started the porting in early January, and it took a lot longer than we had anticipated. Because the Quake II source was drastically different from the original Quake engine that we started with, major systems were rewritten instead of ported. We rewrote the scripting system three times during the course of development. This was a major setback — finding issues with levels after they had been completed forced the level designers to rework each level, and in most cases, they just started over from scratch. We definitely learned our lesson in regard to trying to implement a major technology change midstream in a project. We also had problems using Quake II’s new tools (qbsp3, qvis3, and qrad3) with our maps. A lot of changes went into the tools before any of the old levels could be compiled and used in the game. We had to write a complete texture grabber utility because our texture and surface properties format was so different than Quake’s. Major additions were made to Quake’s level editor (QE4), which we then renamed SINED. 3. Overcomplicated systems. Developers at Ritual are very sensitive to the needs of the first-person shooter gaming community, and one the reasons that Quake has been such a success is that it is easily changed and modified by the end user. Nonprofessionals in this community made hundreds of modifications and total conversions, and we wanted SIN to be just as flexible. Most of the major systems in SIN can be changed without rewriting any source code. Just make a simple change to a plain text file, and voilà, you have new behavior and effects. However, writing generalized source code is a lot harder than writing special case functions just to perform one task. Accommodating our goal of an easily modifiable game added a lot of extra development time to the new systems that we’d created. An example of this is the console system, which we developed from scratch. This system had major ramifications in the game, and took about three to four man-months of programming time. We had not planned for consoles during SIN’s design stage, and each level designer was responsible for the console content. It took a lot of planning and work to make a console, because the text messages were presented using a full layout language (like HTML). Something as seemingly simple as an ATM machine in a bank required tweaking over the course of several months. Moreover, the level designers already had a lot of information to absorb in creating a SIN level. Add 100 more console commands to the 400 script and AI commands, and you are just asking for trouble. Because consoles took so much work and effort, when crunch mode hit, consoles were underutilized and in some cases dropped out from the level and replaced with a push button. 4. Inconsistency and too many assets. We lacked a standardized method of texturing models from the outset. We started out using the Quake method of planar projecting the front and back of a character. Planar projection worked well, but about halfway thorough the project, it became apparent that this method wasted a lot of texture space and wasn’t the right way to map, especially with less organic models. When we got per-face mapping and 3D Studio Max 2, we took more care to unwrap the models carefully and use the texture space better. Most of the original models were redone, but a few slipped through due to time constraints.
Because it was our first major project as a team, we spent quite a bit of time just seeing what worked and looked good in the engine. We created over 3,000 textures, but many simply didn’t look good in the game or were too general; we only used about a third of the original texture library. We also built over 400 in-game models, including around 35 characters. This huge model library made for some very diverse and interesting environments, but the overwhelming number of models represented a lot of work; sometimes, the quality suffered because of the sheer quantity of content that had to get done. 5. Too many cool things isn’t too cool. The more that’s in a game, the more there is to go wrong. Although creating the gadgets and gizmos and character AI and environment interactions and such are some of the best aspects of level designing, level designing in particular has become far too complicated for any single individual to control. Level designing isn’t simply making square rooms with connecting hallways anymore, and gone are the days of simply placing characters on a map and relying on their inherent AI to control them. The demand for realism has requires almost unattainable detailing to successful levels. Each and every character must be placed with paths and directions to escape points and attacking advantages, and most all their behavior must be scripted. Environmental interaction (entities) is also growing exponentially as level designers now have control over just about everything in their levels. A normal level can now take more than two months to complete, and play testing all of these added enhancements can be a nightmare. Lighting and sound have also become complicated and burdening. Level designing will soon become a multidisciplined department due to these increasing demands. We actually tried this organizational approach, but being a totally new concept, its actual implementation may have hindered more than helped SIN. |
|
|
Features
