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.

Start Anew

Ha, I have decided to start from scratch. The current project is just too troublesome to handle. Plus I want to learn more about direct x.
This time I will keep things as simple as possible. And with the previous experiment, I should be able to do things in better way. Of course some codes and data could be reused from previous project, but I should do a lot of things in simpler way. Keep it to the essential stuff.

Aha

Currently I am stuck with an access violation exception running the Level editor. The cause is still unknown. I also tried to compile the program in debug mode but for some reason it has problems with dll etc. Makes me wonder...why do they always make things so complicated.

Inclusion of Windows Form

I have setup the new Windows Form project as the new editor executable, and the original LevelEditor project as a library. Now I think I have to do is to transfer the control from the LevelEditor old Windows App GUI to the new one, which I don't think would cause too much trouble.
With Windows Form I can have much more features without too much trouble. For example, I can setup the light color using the color selection dialog. I think this is going to work out great. Now if only I could concentrate and find more time for this crap...

Messed up Graphics

I have been thinking about this for a while. I realized that the graphics doesn't look that sharp on the game, especially the model, colors and lighting doesn't seem right. Here is some notes that I think might help:

1. Use more vibrant colors. The current greyish, darkish color doesn't seem to work
2. Use ambient lights. I wanted to have large contrast, but I think the constrast is just way too much without any ambient light
3. Fix those problems. I still have problems with shadows etc. Maybe I just shouldn't use it. But still, it's better to fix it.

There might be other stuff I can do but these are what I can think of right now.

Observation On Space Siege

I haven't played the game Space Siege, and from the reviews that came out I probably won't ever play it. The game seems to have a good background story, but the game play proves to be too limited.
A lot of people complaints and suggested the game play should perhaps be more like running and gunning. For me these comments suggest that I am on the right track in terms of my game design and philosophy behind it. I think if I have the time, budget and skills to make it into a full, it might actually be good.

Rolling Along

Update on the development: Fixed some compile problems, and setup the added tile indicators. The plan is to have the indicator to indicate where the tile is placed (might even use different color to indicate different set), and when the user press refresh or change level etc, the stage will reconstruct with the new tile setup.
I have also decided to use Windows Form for the editor instead of the old WinAPI. It's much easier to use and has much more support. Yesterday I just thought of how to make a easy switch. I will just add in new forms, and slowly transfer the functionality from the current windows to it. That way I can avoid a lot of hassle like setting up a new project etc. Hope this scheme will work.
But it also makes me realize that the new tools etc keep rolling out, and I have to stay updated on what is available and what can be utilized and integrated etc. This process of scouting and evaluating etc I would say is a difficult task in itself. Yet again I feel I could have moved the development much faster if I can work on it full time. It would be easier to move into a zone etc. Perhaps what I need is to concentrate on it during weekend, when I have most of the free time. Sometimes though there are a lot more work than meet the eyes. There are a lot of design decision etc that I have to make, which all takes time and efforts, unfortunately.