Added basic attachment system.
21 Aug 2014
20 Aug 2014
Restart
Haha...restart. 3D requires too much time. I will try a 2D game and see what happens.
The problem with 3D is...you need to model, setup animation etc. That is just a lot of art work. Too expensive. So I will just do 2D, and probably keep animation to a minimum, to simplify the process, making a finished game more feasible.
18 Mar 2009
Enemy Unit Intergration
Finally, I integrated the enemy entities into the game. Actually I don't have to do anything. But I forgot to tell the GameLogic class to load the DataManager as well, which result in empty enemy model paths. Took me a while to debug but now it's fine...Once again I guess it shows a good low level software design can save a lot of headache and time, but I would also say nothing is without flaws, especially in software...But I wonder would software development experience help in this? But in the past it seems to show the older software developers have a disadvantage because they cannot learn as fast also the mental power of the brain just cannot compete with the younger people...This is indeed an interesting question. So I would guess...the better programmers are probably those that have already acquire substantial experience and knowledge in software development but is also very young...hmm...sounds more like athletes...That sucks.
16 Mar 2009
Enemy Units Setup
Last week was able to setup the enemy unit setup function in the editor. Now the editor allow the user to select an unit type and then put it into place. I am now working on the loading part of system, but was unable to work on it for a while due to other things I have to do.
The nice thing about it is the user can see the units right on the screen of the editor. I am quite convinced that a good game requires a good editor now.
UPDATE: The load function is completed...what I should do now is probably to make sure the game can load all these in.
24 Feb 2009
Load Complete
I think next I will attempt to add in the enemies. Also have to scale the model into the right size...hmm...I should be able to do this with proper export setup though.
After that I should try to add the weapons...and projectiles...that is going to be interesting. This part is probably going to be another big section though...although weapons and projectile looks like small things but they can be a totally separated system on their own...perhaps I need to separate this into finer tasks:
- particle and explosion animation system
- weapon and equipment model attachment
- weapon control
- projectile and projectile collision calculations
19 Feb 2009
Editor Stage Save and Load
Right now I am still working on the save and load feature of the editor and application. But so far it doesn't look complicated. Each object will save its own data. When loading though, object might need to be created with those data as parameter so it's probably not possible every object loads its own data.
One thing I did significantly different on the editor from the last game is the way the program determine which tile block to put, and it seems to work out much better. The way I am doing now is "dynamically" determine the block to use when each time a tile is added to the stage. The way I have set it up (adding 4 tile at a time), each time a tile is added, the tiles around it and itself has to determine which block to use (2 border, no border, 1 border etc). The important thing is: the recalculation does not traverse beyond the immediate surrounding tiles. Even if it does, it's actually ease to use recursive functions algorithm to go beyond the surrounding tiles, which is much more CPU intensive, but I am 99% certain that is not necessary. To be 100% sure I probably need to do a mathematical proof on this lol...that would be a nice computer science exam question, but hey, I am just trying to make a game here.
The algorithm I used last time is to do the block determination after all the tiles placement has been determined. Doing it this way has 2 disadvantage:
- The determining functions became long and complex. Very difficult to manage. Although I am not totally sure, but I think the new way will actually cut the complexity down.
- The user cannot see exactly what they will see in game when they are using the editor. Obviously it can be remanded with a refresh button or just do recalculation of the whole thing when the user add a tile. But both are inferior to the new one, in which the user has immediate feed back with much less recalculation resource.
Interesting, 10 Commandments for Management from Capcom
- Keep staff turnover below 10 percent per year
- Maintain ability and cash reserves to increase personnel by 10 percent each year
- Keep development cost fluctuations within 10 percent
- Investment in new IP needs to be kept within 20 percent of company-wide development budget
- The structure and organization of the company needs the flexibility to change in response to growth; goals and objectives must constantly be reviewed
- Goals and objectives must be adaptable to external forces (see Square Enix's decision to move its Dragon Quest series to the Nintendo DS)
- Objectives and aims must be set from the top-down
- Reform must always be undertaken from the bottom-up
- There should be no taboo areas when it comes to reform. Reform must be undertaken at all costs. (This lesson from Toyota, where management and developers worked together to create a problem-free work environment.)
- Set achievable targets; unachievable goals bring down motivation
Interesting Stuff...
