I won't be working on the game this coming weekend. So, instead, I thought I'd try to explain a little why it is that I am taking all this time to work on the engine rather then add all kinds of new things. I also felt like writing my mind for a change
There are three mayor changes I'm trying to realise.
1. Implement a new damage system.
Previously all enemies did a fixed amount of damage to Link (which would diminish based on Link's tunic), a hp value and variables per possible hit against it (like a damage multiplier for fire or to turn arrows ineffective etc). This was the earlier situation.
Now the enemies are build of three prime components: Creator, Control, Sprite (with death sprite and shadow as support). These main objects are uniform for all enemies. When the enemy sprite and hero sprite connect the hero gets hurt, but no longer by a set amount of damage. Damage from the enemy to the hero is set in classes. A class holds a value of damage per tunic and a distance the hero gets pushed back. The enemy only stores the index to the damageclass for this. Special damage features (like fire/ice/stone/lightning/stun) will be dealt with through an additional variable. All of this has been been programmed a while back, except for the special damage. There are now enemies/sources to deal special damage yet, so there is no need to build already.
The character structure also needed to be redone. I'm in the middle of that right now. There is a control tile and there is the sprite. Sprites work with a parent tree. There is an object for sprites "attached" to the control tile and sprites with unattached locations. Under these is an object for the body and shield because they have unique features. The way the character hurts an enemy is if a character sprite collides with an enemy's. If the character has character sprites has it's variable turn on to interact with enemy sprites then that takes precedence over the enemy hurting the hero.
All of Link's attack types are also grouped into classes. The icerod is a class with only one weapon, because an iceattack is unique. Using the first sword in a default swing and throwing a bush share a class because there damage has the same nature and the damage value is comparable. Each enemy possesses a damage variable per class. So if you hit an enemy with a boomerang then that would be damage class 1. The enemy's damage value in that class is 1 so he takes 1 damage (and is thrown back a distance also in relation to the class). And if I want the enemy stunned then, instead of a damage value like 1, I could have the enemy variable hold a value like 101. 101 could be stunning, 102 getting frozen etc.
The damage mechanic is finished. There are 20 classes in total. 9 classes are being worked on or (almost) finished. The character structure is about halfway done, but it's still a lot of work. Special status attacks are not yet in effect, but will be added sometime after the character structure is finished. All enemy stats are default, meaning all weapons deal equal damage and all enemies have equal health. Tweaking the stats will be done at a later date, but if anybody is interested in stuff like that feel free to send me a message.
2. Restructure the enemy / hero build up
As stated in point 1 and especially 3, the enemy and character structures needed to be changed. The enemies needed to become more uniform to make it more manageable to add new enemies with more ease. Enemies can now share AI segments slightly easier (like movement scripts), and can be part of an class (projectile / non-projectile). All enemies now use one single sprite which is immensely valuable because you can now manipulate those with one piece of coding. I'm talking about the flickering colorschemes you see when an enemy gets hurt. That is now for all enemies the same. Finally (almost) all enemy sprites are broken down into layers (one per color in there original sprite). In other words, I've implemented the use of colorpallets for the enemy sprites. This makes the just mentioned possible, but also frozen or stone enemies. The before mentioned has all be finished. Who knows. I might one day even use all of this to implement my crazy idea of making the tint of the enemy dependant on the shading he is standing in etc.
The character structure needed to be changes for roughly the same reasons as the enemies. It elimated a whole lot of objects, adds more uniform coding and makes damage and sprite manipulation a whole lot easier. Not to mention adding new items/actions. The hero sprite will also be using a colorpallet. The advantage of this is obviously an easier way of changing Link's tunic, but also to let Link be frozen or turned to stone. And I can do small details like color the gloves based on the gloves you've actually collected. Finally I separated the head sprites from the body sprites to help clear overlap. Most of what is mentioned here is still being implemented. To give you an idea of the work: I've just added my 40th head and 155th body sprite, and still counting. That comes done to about 300-400 subimages of previous sprites replaced by this new method not mentioning swords and shield.
3. Restructure depth system
And finally the change I won't be finishing before the next demo, but which I'm preparing for all the same. Namely a new visual depth system.
I encourage programmers to read this bit as advise, because it'll save you time in the long run if you haven't come to a similar conclusion already.
In my game currently all enemies have depth x1 or x2 (based on lower floor or upper floor). This is the simple version. So if you create two bats then one will always be drawn in front of another. I could have handled that pretty easily, but there is another problem. In my game there are statues. They have a base of 16x16 pixels and you can walk either in front or around back. Naturally you expect to stand behind it when behind and in front when you are standing in front right. Doing so in normal circumstances is also easy. However, when you give the character the ability to pick stuff up his height increases. Now comes the question of depth for the container above his head. Simple trickery won't cut it anymore. When you are standing in front you really to do need to give the container/character a depth that is lower then that of the statue. Otherwise you will get ugly depth issues. (BTW: the original also has these problems. If you hold a container below and next to some specific pillars the top of the container will be draw under the top of the pillar).
So what I plan on doing is have the depth be variable based on the y coordinate of an object's sprite's lowest border. It's simple really. Just took me a long to realise it
There are some small issues left, like what if you objects (enemy/character/statue/etc) share an y value. In that case you first need to add priority like Character > Statue. Secondly you can use creation order.
This last point has not been programmed yet, nor will it be before the next demo. It's too much work and I really do want to show some result for a while now. I'm also afraid that means you'll see some depth issues in the next demo
What I am doing however is a bridging. Each character and enemy can have sprite components that already have a depth relation to one another. Like a sword being in front of a shield. Previously these depths where constant, now I'm basing all depths on the control object's depth. So each control tile gets a personal range of +5 and -5 to manipulate it's personal sprites in. When I want to implement this new depth system I can manipulate all the character sprites as well as every single enemy with just a single piece of code.
-------------------
Sorry for the spelling and possible ranting. It's really late right now. I hope someone amongst you has found it interesting enough to read it till to the end.
Even better would be if someone found it usefull.
). Maybe you need to bring it somewhere but I can also imagine you'd need to break the chest by throwing it against something. Like a specific type of enemy maybe.
