|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
The Introduction of New Blood Every now and then, a company makes a decision that just happens to turn everything around. Or at the very least, makes the impossible possible again. This is how I would describe our hiring of two interns, Andy Schatz and Narayan Brooks. Half way through the project we realized that we did not have the manpower to finish our level instancing. (Level instancing is how we refer to level construction, setting up doors, placing enemies, etc...) Now while this might sound odd to those that come from companies creating Quake clones, remember that Presto Studios has been making prerendered Myst style games for years. Until we ventured into real-time 3D, creating levels was the job of artists who worked on scenes with millions of polygons. Creating low level geometry and placing door logic requires different, more engine specific skills. So we hired two people who were working towards their degrees in computer science to help us lay down the logic needed to make our 3D worlds come to life. Since they both were given the very specific task of using our tools to make the worlds come to life, they were able to experiment. This was the first time that anyone really sat down and explored what our tools could do. Add this to the fact that they both seemed to love making the game, it was a perfect solution to multiple problems. All of a sudden we had people who wanted to not just construct what they were told but were actually forging ahead with new ideas. Creating scenarios that the level designers had never considered. Their excitement soon caught on to others on the team and really helped propel the project towards its final goal. Making The Hard Decisions One of the hardest decisions any game company can make is when to cut the dream. Can those in charge decide before it's too late that the game as designed is simply too big? Luckily, the answer to this question was "yes" at Presto Studios. The initial game design was a mammoth undertaking especially when you consider the one year timeline. As we watched ourselves fall behind early with milestones, we knew that unless we changed the project significantly we would completely miss our gold master date and Christmas with it. It was decided that cuts had to be made. The entire team sat down for nearly a week doing a complete walk through of the game. Discussing every level, every scene, every event, and making sure that everyone involved understood what needed to be done. Many items were axed immediately as people heard, sometimes for the first time, about a situation that needed to take place for the story to progress during the game. Other ideas were stripped down and rebuilt in order to use the engine technology better. By the time we were done, an entire level had been removed and all others had been significantly reduced. We sugar coated certain cuts with the phrase, "If we have time at the end", but as everyone knows that means it's dead. No one in the history of game production has ever had time at the end. And this was by no means the end of the cutting. We still had five more months of cuts to come. Over the rest of the project, the occasional snag would develop. Perhaps the engine couldn't perform some task the way the designer had envisioned. Perhaps the schedule was getting too tight and we just did not have the manpower to animate a given cut scene. Across the board, if the feature was threatening our release date, it was cut. Nothing mattered more than shipping on time and we all agreed that shipping a small solid game was better than shipping a large unstable one. Plus, the Activision play testers never noticed that anything had been cut. The missing sections are only visible to those of us that knew they were once suppose to be there. The Rendering Engine Some say I am a programmer. Well, in order to support that idea, I guess I should talk about a programming task that went right in a big way... the rendering engine. The initial concept of the engine was simple enough, prerendered backgrounds and real-time objects mixed with per-pixel depth sorting. We already had a real-time rendering engine which was used for creating Beneath, a real-time 3D action/adventure game which was put on extended hold. However, the addition of the prerendered backgrounds proved to involve far more code than most suspected at first.
I chose a depth buffering algorithm in order to handle the per-pixel sorting. Electric Image could export it's z-buffers which I then converted to our own custom depth format. I had to write an entirely new renderer since the Beneath renderer used a span based hidden surface removal algorithm. This required rewriting all the pipelines including transparency, translucency, shaded, etc... A camera subsystem was created which could handle loading backgrounds when needed. I wrote a dirty region update system based on scanlines which could rebuild damaged parts of the background and depth buffer as real-time objects passed over them. (Add in the translucent heads up display which overlaid both the backgrounds and the real time geometry and we had quite an interesting task in optimizing the updating.) However, the most interesting part of the code in my opinion was our solution for hardware rendering. We needed to follow the same concept with prebuilt depth buffers that could be blit copied over to the card and then have the card render triangles correctly into them. My initial thought was that I would need to reverse engineer every card on the market in order to determine how they handled depth buffers. Would this card use some floating point format, would this card use w-buffering, would this card use greater numbers as the object got closer to the camera? The result of my experiments surprised me. Of all the depth buffering cards we tested, none of them cared what information you stored in their depth buffers as long as you sent the appropriate data through the triangle renderer. My final solution has all cards being loaded with the same 1/z fixed point depth data. As long as the values I blitted into the depth buffer matched up with the values I sent to the card in the triangle vertex block, everything worked. In other words, cards don't perform any magic when you send z values through Direct3D or Glide. They simply interpolate the values across the polygon (in a perspective corrected fashion) and store the results in the depth buffer. Writing a value straight into the card's depth buffer is like drawing a single pixel triangle at that screen location at whatever depth you send. It's All About The Tools In the real-time 3D arena, it's all about the tools. What's the point of a brilliant rendering engine that is faster and more beautiful than everything else on the market if your own production team cannot get anything done. It'll be a great demo, but not a game. The first generation of tools at Presto was practically a step-by-step course in how to not create tools. The incremental design ate away at all sides until the whole structure threatened to fall in on itself. The code for the tools was bad in that they never were crash proof. And in our mad rush to get in more features, we never seemed to be able to spend the time to fix these sporadic problems. So bad code was covered up with more bad code and the situation grew worse as time progressed. All of the programmers at the office, except for the one that wrote the tools, viewed them as some sort of black magic that has been written in another language. The production team was left with little help when something did not work. Only one programmer could help them and he never had time. It was not a good solution. You must never allow one programmer to be so critical. Multiple programmers should be able to handle any given system. One of the best things a tool can do for both the production team and the programming team is to explain with errors and warnings when something goes wrong. Unfortunately, our tools programmer did not quite see the importance of this. Serious flaws in the data being exported would go unannounced while other warnings were actually used by artists as signs that they had exported something successfully. Giving incorrect warnings is worse than giving no warnings because now you are training the user to ignore them. Proper error checking would have saved everyone weeks of time spent debugging broken game logic that ended up being an improperly setup item in 3DSMax that the tools should have reported. To make the situation worse for the production team, the interface was designed by the programmer as he went. Once again, incremental design reared it's ugly head and bit off a large chunk of our productivity. And the fact that a left brained programmer was creating a graphic interface for right brained artists is a mistake that I'm sure most game makers have seen at one time or another. It just does not work. Without any good pipeline for requests from the production team to get the programmer, the tools continued to become unusable. In one of the tools, a button marked "Destroy All Data" sits directly next to the "OK" button. With no "Are You Sure" check on either, this perfectly personifies our first generation tools. ________________________________________________________ |
|||||||||
|
|
Features
