31 Aug 2008

Design

Here is the design and reason behind the decisions. I should stick to this and keep it simple. The past project experience has shown me that sometimes I can have a new idea, or few feature I want to add in. At first it's simple. But then it becomes difficult with later implementation of the game. (Example: multiple layers in a stage, with stairs, causing difficulties with AI path finding, 3D model creation cost, large code to setup the tiles in flexible ways, complexity in editors,...etc). This time I will keep it simple. If a new feature needs to be added, it should be just cosmetic. The reasons will also be given to keep remind myself of my thought process so I won't let my mind wonder and blow the later design out of proportion. This design in a sense are both guidelines and restrictions, that I should abide by myself to keep the project in check.

1. Single layer, with background: a stage consist of a single layer of obstacle course or maze, which the player has to navigate through. Some background can be put in for looks. Of course, if more "background/foreground" cosmetic layer is required, they can be added. But the principle of player and AI playing on just 1 layer should not be changed.
Reasons: Multiple layers might not be that hard to implement, but when you have multiple layered (floors) stage, other implementation also become difficult. For example, you will need to worry if those thing obstruct the player's view. You will need to worry about the AI path finding more. You will need to worry about extra axis. Plus a bunch of cosmetic questions like how to make the stage look nice etc. Camera also a big issue. So to put all these concerns aside, just stick with single layer.

2. Tiles should be 2D: The tile sets etc should be in 2D. No 3D models should be involved.
Reasons: While the 3DLTS was flexible, and I believe it could also create some amazing stage, the cost of it is too high. And like one of those designer in Blizzard said, randomness cost a lot (not exact words but I remember that's what he meant). With 3DLTS, the stage needs some "randomness" to look interesting. To create with randomness the system also needs to be flexible, and all these cost time and effort exponentially, in my opinion.

3. Animated Unit in 3D, Static Unit could be in 2D: Both 3D and 2D unit should work. Although it's also possible to have 3D model posing as 2D (flat 3D model). Although ideally all units should be in 3D, allowing 2D units to be placed can cut down the cost.

4. General Control: The game will be a side-scroll action shooter. The player control a robot, moving freely in X and Y direction (no Z direction). There will be obstacle (tiles), which the player can not go past by. The player control movement of robot using WASD, control the direction of the shooting and the firing using the mouse. The view will be from the side (directly). The direction should be 360 degrees. If 360 degrees is not possible (due to animation etc), it should be proximately 45 degree up and 45 degree down for both the left and right hand side.
Alt 1: it might also be possible to let the player shoot in 8 different directon, but no more. This way, the animation is easier. Plus it might simplified the control a bit.

Those are the guidelines for now. More might be added in later. Simplicity should be a major concern of these project. Complex design or design that require big change should be disregarded. Design that can simplified the development should be implemented.

No comments: