|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Understanding The Big Picture After digging in deep to the programming side of the tools, I now feel justified in pointing the spyglass to the other side of the team. Production had every right to hate the tools but this is not a good reason for not using the tools. Many members of the production team lacked any serious knowledge of the engine or the tools used to create worlds. This included people who were designing gameplay on paper without any real understanding as to the construction pipeline for their ideas. However, both of the interns we hired halfway through the project became quite proficient at navigating the mine field that was our tool suite. How is it that people who were around for years while the engine was being first developed understood so little, while our newest people were able to grasp the concepts in a matter of weeks. I believe it comes down to who wants to make games and who wants to make art. But don't we all want to make games? That is why were are all in the industry, right? Well, yes and no. Some of us study all sides of games. From script writing, to programming, from interface design, to production management, I've gotten my hands dirty in everything at one time or another. I don't do this because I feel that I must be an expert in all these skills, but I do feel like I need to be proficient enough in these skills in order to work intelligently with everyone on the team. While one purpose cogs can work effectively in large development houses, small teams often require members with much more generalized skills. Everyone should understand on at least a fundamental level how what they do will affect other team members and in turn the final product. And being able to do this requires basic problem solving skills. If you do not enjoy fixing problems then you most likely will always be frustrated making games. Conceptual Design vs. Level Construction Possibly our worst decision in making Star Trek was our separation of level design and level construction. The decision came from the company's experiences with it's previous graphic adventure products. In this design setting, having one artist create the visual and mechanical concept of the level and another model the level from the drawings is a perfectly viable pipeline. However, in a game with real-time navigation and combat, trying to design something for beauty will not necessarily get you something that is entertaining. When our two interns started experimenting with our tools and engine, they developed scenarios that our conceptual designers never could. Scenarios that were not only exciting but were easily implemented due to the innate nature of our technology. Knowing the tools is one of the most important skills any person involved in level design can have.
Our product pipeline was made inefficient due to our separation between design and construction. By halfway through the project, we had created entire levels without ever setting up combat scenarios or even attempting to walk the hero through the environments. Our camera shots were chosen for their aesthetic qualities and not for their effectiveness during action scenes. And whenever a problem was found in the placement of a crate or a camera, it required getting into prerendered Electric Image files, making changes, rerendering, and then trying out the new scene often with the result being that we didn't change it enough or we changed it too much. The pipeline from concept to execution was simply too long. Prototyping our levels with visible collision geometry would have been a much shorter pipeline involving only changing a small file in 3DSMax and exporting it to the engine. One person could have experiment with dozens of setups every day instead of one setup every couple of days. Technical Design As You Go Poor design is not just a problem for artists. Programmers need to design systems before incorporating them into a project especially when there are other programmers. We suffered from the no-design mentality quite a bit on the Star Trek project. Since we were essentially building the game and the engine at the same time, we were constantly running into time conflicts where we needed a new feature right now in order to meet a deadline next week. This resulted in what is often the standard in game programming: design as you go. Our basic game play elements such as path followers and rotators were built up piece by piece often by different programmers, none of which had a full understanding of how the system would or should behave in relation to the rest of the code base. Ambiguities were created, partially functional code was activated, nothing good came from it. Except for our current dedication to make sure that this never happens again. We have now incorporated design meetings and multiple stage code reviews into our daily routine. The results have already been astounding. One interesting example of the opposite problem arose in our custom interface system: we had too much design. Our interface system is the library of code that handles our front end interface and our in-game heads up display. The code was written by a programmer with extensive experience in C++ object oriented design and loved to use it. He spent many weeks designing and crafting an interface system which was extremely... well... designed. Private data fields were placed into private headers. The "const" operator was used everywhere. Void pointers hiding internal data structures made debugging a nightmare. The entire system was designed with the idea of keeping "the client" from changing system internals or even from being able to understand them. And while that style of programming has its place in a production team with 200 programmers whose goal is to sell a simulation library, it has a tendency to slow down the work of three programmers working together on closely spaced milestones. In other words, for the other programmers on the team the smallest change to the system required hours of exploring and debugging and usually resulted in them throwing up their hands, cursing loudly, and hacking in a variable called yet_another_interface_hack_for_inventory_menu_hot_keys. Not a pretty sight. There are extremes at both ends of the design spectrum and either one can seriously damage overall productivity. Make sure that you spend time designing what is important. Cutting A Story Based Game When creating a game based on story, you will always run into the following problem throughout the project. How can you cut that, now the story doesn't make sense. The first problem was that we had to cut so much from the game. There were two primary reasons why we had to cut so much. First, we were running out of time with such a short production schedule and we had to finish in time for Christmas. However, beyond that, many cuts were made simply because the story was too static. In a game, the player is in control of the small details. When a camera cuts, how a combat unfolds, these are details that are mostly out of the hands of the level designer. This is actually the whole reason why people play computer games. They want to control these things. If they didn't, they would go to the movies and save forty dollars. Therefore, designing a scenario in a game that spells out every single detail is never going to work. If you hear a pitch for a game scene and it's filled with sentences like, "And then the hero pushes the killer down the stairs, runs to the desk, pulls out the knife, but when he returns the killer is no longer at the bottom of the stairs."; that's not a game, that's a movie. (And seems like a bad one at that.) In a game, you give the player options and it's up to them to select what they want to do. If you want the player to be able to push someone, you have to work that control into their standard control interface. It needs to be something that can be done repeatedly. There is no point is spending the time designing and building something that the player can only do once. This means that this action has to stand the test of repetition. Can it be done over and over again and still be fun? Do not try to script out combat situations except for the initial trigger. Once the bullets (or phaser blasts) start flying it's up to the player and the game logic to determine what happens next. You cannot assume that the hero will run here or there. Who's to say that he'll run at all. Maybe he'll walk slowly away from the action. Maybe he'll just stand there. It's up to the player and that's what makes games unique. It's one of the only mass market entertainment formats where the buyer can truly interact with the product. After removing many scenes from the game, we needed to repair the holes left in the story. Our solution for many of these cuts was to create a prescripted cut scene. Some of them showed basic actions or events but most fell into the category of "data dump." These are scenes that obviously exist for no purpose other than to convey information to the player. The result in Star Trek was one or two minute dialogues with characters standing around talking, sometimes over communicators which really doesn't create an energetic scene. Our use of dialogue to convey information breaks one of the fundamental rules of visual entertainment, convey information with images. Instead of watching someone tell you about a level, why not listen to the voice over while watching a fly-by of the level on your tricorder. In Conclusion The current state here at Presto Studios is one of excitement. No one is really too concerned over the amount that went right or even the amount that went wrong on Star Trek, the final result is that we finished a good product on time. However, I am thrilled over the amount that everyone here has learned. Our initial steps towards the "next big thing" have been quite promising. Our production team is now more focused and organized towards real-time engine development. Our coding staff is working intelligently towards next generation tools and engine technology. Those people that did not share in the vision have left for jobs that better suit them and we wish them luck. I have been through many projects in my career and many of them have never seen the light of day. But never in my experience have I ever seen a group of people learn so much so quickly from their mistakes. I hope that this look into our project, Star Trek : Hidden Evil, has allowed you to see some possible flaws in your own team. And maybe give you an idea or two on how to reorganize and move towards a more cohesive team environment.
|
|||||||||||
|
|
Features
