|
||||
|
Deer
Hunter's |
||||
|
By
Originally |
It's better to keep the game plan simple and
understandable. You don't necessarily have to code the entire game on paper.
I've found that the most important aspect of the initial design lies in
clearly delegating responsibilities for the project components. Instead
of delving into the inner workings of how individual components are going
to work, focus on how the major components are going to work together. Again,
these don't necessarily have to be completely set in stone. Rather, let
the programmers who are dealing with those components work with each other
to figure out how their components should communicate. Because they are
the only ones the problem affects, it makes sense that they should facilitate
the solution, both in design and in code. As long as their solution is solid
and well documented, there's no reason to involve other members of the team
in the decision process. Planning by committee in cases such as this is
both unnecessary and inefficient.
Note that I'm not talking about a complete graphical mock-up. I'm referring to a functional mock-up. I use CorelDraw to roughly position all elements on the various screens. I print each screen on a separate page. I label all buttons and explain their functions. I make no attempt to create an aesthetically pleasing screen. The artist's job is to arrange and beautify the various controls except where noted on the document. A solid interface design not only helps to solidify the flow of the game, it also frees those responsible for its implementation to begin coding and illustrating while the finer points of game play continue to be debated. As the game evolves, this document is updated to reflect the latest changes. |
|||
| On
to Lesson 2...
|
||||