Print

[Zaeranos]

Zaeranos

Combat System

EDIT: 22 - 11 - 2010

Okay, I have been working on the combat system a bit more. It is nowhere near finished, but there are a number of aspects that need to be made first. For example an Monster Character. This has been added to my latest addition. I have also been thinking about the hierarchy of characters, Monster Characters and Non Player Characters.

My idea is the following hierarchy:

parObstacle
 |
 |--> parCharacter
         |
         |--> parMC
         |        |-> parStaticMC
         |        |-> parDynamicMC -> Octorok
         |
         |--> parNPC
                  |-> parStaticNPC
                  |-> parDynamicNPC

For the MC I already made an Octorok. It's AI is connected to the state the Octorok is in.

--------------------------------------------------------------------------------------------------------------------------

Okay, I have been really busy lately with work and my Master Thesis. Starting work/study at 7:30 and end at after 18:00 leaves me very tired at the end of the day. With some chores to do before bedtime there is very little time left to work. This goes on about 6 or 7 days each week. In the time left I try to get somethings for the CP done and browse the forum.

Well with that said I like to present a bit of what I have been working on. My latest bit is a generic/base object for a handweapon. See the attachment. In the attachment I have made example implementations with the Lantern and Bow (mainly because these had ready available resources for me). The code of this new generic is as follows:

Code: Text

1. /***************************************************************
2.   State Variables
3. * script - is the script with the weapon code.
4. * state - to be used if the weapon has multiple stages.
5.  
6. ***************************************************************/
7. script = 0;
8. state = 0;
9.  
10. /***************************************************************
11.   Other Variables
12. * owner_id - the instance that is holding this weapon in its
13.         hands.
14. * timer - a counter for timing purposes.
15. * x_off - the x offset variable. How far from the x position the
16.         lantern has to be drawn.
17. * y_off - the y offset variable. How far from the y position the
18.         lantern has to be drawn.
19.  
20. ***************************************************************/
21. owner_id = 0;
22. timer = 0;
23. x_off = 0;
24. y_off = 0;
25.  

Code: Text

1. if(script != 0)
2.     script_execute(script, STEP);
3.  

Code: Text

1. if(script != 0)
2.     script_execute(script, DRAW);
3.  

As you will see the code is minimum at best. But the most interesting part is the CREATE event. As you'll see it does not contain anything usable for damaging enemies or in fights. This is because it is still in development, but before it can go any further I need to discuss how to deal with damaging and calculate hit point decrease.

I was thinking about letting the following aspects play a role:

• Link's base attack
• Weapon's base attack
• Link's attack modifier
• Weapon's charged modifier
• Receiver's base defense
• Receiver's defense modifier
• Weapon's element (fire,ice,magic,etc)
• Receiver's element resistance

The problem is that I am probably thinking way to complex here and probably could do with less variables. Thus I would love to hear what you guys think about it.




Note: You can also see some of the latest additions to the engine's future release but it still has some flaws and holes in it. I am working on it and it still has some things to do before a release.

[Martijn dh]

Martijn dh

Re: Generic Hand Weapon and discusion about dama...

The way I'm handling damage right now is as follows (short version):

If the enemy deals damage he does X[1] damage, X[2] magic damage with X[3] standing for effects like electrocute, freeze, poison, burn etc. When an enemy hits Link you get a switch command and you let loose the modifiers stored for each tunic. One variable per type of damage or effect stored in a matrix will be plenty.

When you hit an enemy I also use damage_classes. Check this link again for an example of how alttp did it.
http://www.gamefaqs.com/snes/588436-the-legend-of-zelda-a-link-to-the-past/faqs/39556
Each enemy has a value stored per damage class. You could use negative (or very high) values to indicate status effects.

One thing I can add is that you probably want to add a depth variable to your weapon object. Sometimes you want to hold it in front of Link (= when looking south) and sometimes you want it behind him (=when looking north). You'll eventually realise you don't want to edit it manually. Base it on the depth of Link and gice it something like a +1 or -5 value.

You can also join the "Horn of Balance" community on:
Free demo: https://hornofbalance.itch.io/horn-of-balance-pre-ks-demo
Discord: https://discord.gg/redHXyZ2Gc
Twitter: https://twitter.com/HornofBalance
Kickstarter: https://www.kickstarter.com/projects/hornofbalance/horn-of-balance

[Zaeranos]

Zaeranos

Re: Generic Hand Weapon and discusion about dama...

Actually, you bring up a very good point. Something that has to be considered is the depth of objects and Link. At the moment everything is still at a fixed depth, we could use various depth ranges for different aspects of the game, such as Link, surfaces and objects. But this does not work if characters need to walk in front and behind objects. In this case probably -y would be the best choice, although you might want Link to walk over and under bridges as well. I think one would need both things to deal with depth.

Nice source for theory. I could work for this game as well. To bad some off the numbers are quite meaningless to me, or I am not reading it correct. I had hoped some more people would share their thoughts. Alas, this is not the community for sharing.

[Theforeshadower]

Theforeshadower

Re: Generic Hand Weapon and discusion about dama...

I just tried this release(haven't really kept up with it so I figured I would give it a try).
There a couple bugs:
-Start to roll then hit enter to get to the menu.  The entire time you are in the menu, the game is creating many instances of the smoke/dirt object or whatever you are using whenever Link rolls.
-Use the bow and press enter to get to the menu while still holding the bow button.  Release the bow button while in the menu, then exit the menu.  You stay in a permanent "plucking the bow" state until you use the bow again.

I don't know if these were already known or not.

And, am I supposed to see arrows or not?  Because I don't see any.

• 

[Zaeranos]

Zaeranos

Re: Generic Hand Weapon and discusion about dama...

I just tried this release(haven't really kept up with it so I figured I would give it a try).
There a couple bugs:
-Start to roll then hit enter to get to the menu.  The entire time you are in the menu, the game is creating many instances of the smoke/dirt object or whatever you are using whenever Link rolls.

Jup this was a known problem. It has to do with the way it is calculated when a cloud needs to be created. But then again the instance of Link should be deactivated in the menu, it seems that draw might still be called after all, with the exception that nothing is drawn and the image_index is increased.

-Use the bow and press enter to get to the menu while still holding the bow button.  Release the bow button while in the menu, then exit the menu.  You stay in a permanent "plucking the bow" state until you use the bow again.

Thanks for noticing this that should not happen. This is something I need to look at when I implement the bow for a release. Or I could do just like Nintendo did in the Minish Cap and only allow the menu to pop up in a controlled state like LinkNormal and LinkSwim. Well, I don't know if they actually implemented this, but the position of the respective buttons kind of forces you to release the button first. Any suggestions.

And, am I supposed to see arrows or not?  Because I don't see any.

Nope the focus was on the hand weapon and not the projectile, thus I explicitly removed that part of the implementation.

[Zhello]

Zhello

Re: Generic Hand Weapon and discusion about dama...

I think this was brought up before, when the pushable object is place in front of a jump-pad, link gets stuck but in this version he ends up on top of the solid object.  Link should be able to continue his jump over the object that cant be destroyed.


Im looking for bugs too though I think some people found them already. 

The IT Guy
Intermediate Coder
Linux is a wonderful thing
~Linkwolf48/Gumstone1080~

The Legend of Zelda - New Beginnings

http://zfgc.com/forum/index.php?topic=34986.0
1.6 Demo -
https://www.dropbox.com/s/56km0iadaras56g/LoZNB%20Game%20Folder.rar?dl=0


Side Projects:

Dragon Diary - Cybernetic Threat
Story: http://wiki.zfgc.com/Cybernetic_Threat

Aero88
ZFGC is like the Hotel California.  You can come in but you can never leave!

devianart: http://linkwolf48.deviantart.com/

[Zaeranos]

Zaeranos

Re: Generic Hand Weapon and discusion about dama...

Yes that is known. But the question remains whether it should be taken care off as a feature or that it is about good level design. Good level designer would work around these awkwardness. But please stick to the handweapon concept and a discussion about doing damage. The rest of the engine can be discussed in the topic when it is released.

[Martijn dh]

Martijn dh

Re: Generic Hand Weapon and discusion about dama...

Actually, you bring up a very good point. Something that has to be considered is the depth of objects and Link. At the moment everything is still at a fixed depth, we could use various depth ranges for different aspects of the game, such as Link, surfaces and objects. But this does not work if characters need to walk in front and behind objects. In this case probably -y would be the best choice, although you might want Link to walk over and under bridges as well. I think one would need both things to deal with depth.

Nice source for theory. I could work for this game as well. To bad some off the numbers are quite meaningless to me, or I am not reading it correct. I had hoped some more people would share their thoughts. Alas, this is not the community for sharing.

The way I intend to handle it eventually is to give pretty much all visual objects a depth depending on their y position on the map. Like range 0-10000 is level A and 10001-20000 is level B etc. Link is at y position 200 so his depth becomes 10000 - 200 * 20 - 5 = 405. The depth range 400 - 410 is reserved for him and all other objects at y position 200. While facing down his body is at depth 200, his shield at depth 200 - 3, etc. The shadows obviously fall outside of this set-up. Since the range of level A is max 10000; that will be the depth for all shadows on that level. All backgrounds will be somewhere at 10000+.

You can also join the "Horn of Balance" community on:
Free demo: https://hornofbalance.itch.io/horn-of-balance-pre-ks-demo
Discord: https://discord.gg/redHXyZ2Gc
Twitter: https://twitter.com/HornofBalance
Kickstarter: https://www.kickstarter.com/projects/hornofbalance/horn-of-balance

[Zaeranos]

Zaeranos

Re: Combat System

Okay, I have been working on the combat system a bit more. It is nowhere near finished, but there are a number of aspects that need to be made first. For example an Monster Character. This has been added to my latest addition. I have also been thinking about the hierarchy of characters, Monster Characters and Non Player Characters.

My idea is the following hierarchy:

parObstacle
 |
 |--> parCharacter
         |
         |--> parMC
         |        |-> parStaticMC
         |        |-> parDynamicMC -> Octorok
         |
         |--> parNPC
                  |-> parStaticNPC
                  |-> parDynamicNPC

Dynamic MC and NPC are characters that move around. I have based them on the Link object and have an interface like the arrow keys to indicate direction. The parDynamicMC code then resolves all issues with environments and stuff. For example, when an object gets bumped over a Pit, the engine will deal with the state change to MCPit and drop the unit in. Thus anyone creating a monster character mostly has to set some variables in the create event (don't forget event_inherited), add the sprites and sounds. Write the scripts for the states, write an AI script if it is not integrated to the state, and they are done.

For the MC I already made an Octorok. It's AI is connected to the state the Octorok is in. The reason I used an Octorok is because it has bump damage and it shoots a projectile. I also added in the arrow again, thus the bow once more fires projectiles. The things I still need to add:
- A handweapon, like the sword.
- Damage done scripts to MC and the required variables.
- Damage done scripts to Link and the required variables.
- Creating collectible objects, like ruppees, arrows and hearts for rewards left behind by a defeated MC.
- MC destruction graphics.
- I still need an MC that either teleports for movement or is like a statue, to test the parStaticMC.
- Depth changes of the MC and Link.

- And maybe some Ledge jumping for the MC, but I don't know if they do that in Minish Cap as well.