为什么要构建原型.ppt

* * Of course while you’re putting together the team and the tools you’ll be using be sure that you’re matching up what you’re doing with the project. If your game is about dancing then make sure you have an expert hip hop dancer/choreographer. If dynamic audio is pivotal to design you probably want a designer that gets audio or an audio guy that gets design. If your game features dinosaurs then it’s probably worth taking the time to, you know, go and build some dinosaurs. In a nutshell, if you’re worried about nails, make sure you have a hammer. Conversely, be aware that “when all you have is a hammer, everything starts looking like a nail”. So if your team is heavy in a certain area (perhaps you are strong in 3D but weak in 2D, or programmer centric), then you probably want to start experimenting in the space that you’re strong in. * * This next one is a bit counter-intuitive, so bear with me. I recommend deliberately using a code base for prototyping that you know won’t be used in the final game. This means that at the end of the prototyping phase, when you have your vertical slice, you will have to rewrite everything from scratch in the actual engine and code base you’ll be using for the game. Here’s why this is a good idea. Making a scalable code base with smart architecture is antithetical to fast, quick and dirty hacking. You want the latter in prototyping. Coders will be more likely to just plow through and get stuff in if they know their stuff will get thrown out later Regardless of what you do, you’re likely to throw out your code base at the end of prototyping anyway, so you might as well get people used to the idea from the get go. You should note that I recommended earlier to “go with what you know”, so of course if you have a pre-existing code base that should be your first choice. Even if you know that the prototype and the final game will be in the same language and ending you still might want to consider throwing what you have out. This all goe