So I'm trying to ultimately create a melee system similar to prince of persia (the original). meaning that when an enemy is supposed to react to the player getting close to it (or the enemy getting close to the player) and then attack / deflect in according to some conditions I will set.
I hit a very silly snag, however. I have an animation for attack that is supposed to play when the player is inside a certain range (I calculate the distance between player and the enemy). In the debug mode it's saying that all the triggers work perfectly, and also says the sprite has switched to the correct animation (attack), but the animations stops on frame 0 and I don't know why.
I have attached the CAPX with the little test inside, if anyone is kind enough to have a look and tell me what am I missing?https://gofile.io/d/06xwz9. Here is a screenshot of the events as well. Note: the "skelletongStates" group only has the states defined for "idle", "left" and "right" in regards to the sprite moving. The image is here: gofile.io/d/YrmujO
Thanks in advance for anybody willing to throw an idea around :)
Hi there, I checked your code and there are some fundamental flaws in the logic and the hitboxes of the actors that may compromise their behavior slightly. Do you mind if I rewrite the code at least for you to use as maybe a reference?
Also I would recommend looking at some tutorials on the matter. I don't exactly have a specific one to recommend.
ps: what a f****** beautiful art, congratulations!
Thanks for the reply! first of all the art is not mine, I googled it, it;s free to use, just using it to test these things
By all means, modify and correct away, I want to learn what I'm doing wrong.
There is a lot of work to be done still. This is nothing but the simplest possible resolution to your problem, but I had to do a lot of work to get here. Mainly notice that every animation had their hitboxes "fixed", by that I mean they are all rectangular and that is incredibly good for movement.
You can see that now the skeletons move to the left without stutter. This is because every point in their hitbox is a round number. Before you had a lot of floating numbers as points and it causes many weird behaviors.
The player also had a lot of work. I moved each frame to a point where the "face" of the hitbox hit 33 pixels always, it helps when jumping an falling back down. If they had been different, those animations could trigger each other and create a loop of doom, as I like to call it. Its funny as hell, but undesirable.
Also, I believe you were not using the "Line of Sight" behavior, I might be wrong, but I used it now.
Hope it helps. Feel free to further discuss this project, because there are still many challenges awaiting you.
Best of luck!
EDIT: Another detail about the player's animation is that the jumping and falling frames don't necessarily need to be higher and/or lower than the Idle animation, it's best to keep them linear because the jump action is enough to create the effect. It also avoids weird behavior on landing.
Develop games in your browser. Powerful, performant & highly capable.
Thanks for all the work you put into this! You didn't have to, I wasn't really bothered about it (again, all of this is just a test for now), unless you'll tell me that that was the reason for the animation fault! :)
I was using the Line of Sight to detect the player first, but the thing I found out I was doing wrong was that I made it very complicated for the "AI" to attack by setting all these conditions, except the correct ones, so the "AI" was trying to do multiple things at the same time. Also, I think your way of detecting the range is way simpler and more efficient.
A couple of points, however: your method is indeed simple and efficient, however, I don't see it being useful in the long run. At present, whenever the skeleton attacks, it just basically loops and also is still moving towards the player. By having a boolean called "following" I could control the movement states of the skeleton and stop it from moving when attacking. I also had the states created for the skeleton to deal with that. Do you have a better idea instead?
My idea was to create a function (or a group) that would handle the attack routine by itself, and then call the function or enable the group when the skeleton is inside the melee range (your Reach variable works just as well). I was having the issue with the animation, because the conditions set for it to play were very confusing.
Ultimately, I want the skeleton to be able to follow the player a certain range, to attack the player when inside a certain range, and when attacking, to be able to set other conditions as well (to deflect incoming attack, for example).
Are there any tips or insights you may want to share as well? I have looked at tutorials, but for some reason, tutorials that cover melee combat are not that many, and usually are pretty basic.
Thanks again for all the help so far!
Honestly, I was incapable of finding where the flaw was in your code because ultimately I was unable to untangle the code in my head. It was very nested and maybe not so organized, so I can't properly say to you what went wrong, sorry about that.
On the skeleton note, you can still stop them from moving when attacking, since you have the boolean called "attacking", so... just make it not move when "attacking = true".
The skeleton follows the player from a certain "Range" already, this is defined by the "Line of Sight" behavior. It also only attacks from a certain "Range", this one defined by the instance variable inside each skeleton.
Also it's hard to properly give any insights on the matter because when it comes to combat, every behavior and every move is unique in their own way, and each game may handle them differently. I would suggest only for you to take your time and work the logic gates the best you can to avoid convoluted code, also make it modular. Treat movements apart from animations for instance, and in this way it will be easier to debug when things go south.
Glad I could help, but keep me posted on your evolution. If anything comes up just continue this thread.
EDIT: You also already have something like your old "following" boolean, which is "Has LOS to object" from the "Line of Sight" behavior. If it has LOS, it is following, so no need for adding an unnecessary variable.
The boolean "following" was made only so that I can disable the movement of the sprite when the attack was happening. I have not used a simple "platform disable" when "attack" animation is playing.
I wanted to make it "convoluted" as I wanted to give myself options when setting conditions for different actions I was going to have the sprite do. I guess I'm not already there, I need to study logic gates more, as I don't think I've quite understood them.
I am also learning pixel art in the meantime and also have a day job. I understand that this is going to take some time :)
As a last request, would have any links to any construct 2/3 articles that deal specifically with game logic / AI setup ? I do not have a background in programming, so it's hard to wrap my head around some concepts or the way logic is used, etc. I have read the documentation provided, and followed a bunch of tutorials from start to finish, but the thing with these tutorials is that they all explain the same basic stuff, but none of the things are required to take this basic stuff a step further. For non-programmers like me is sort of a dead-end, because I cannot follow through when I don't know how I can follow through.
For example there are loads of tutorials on how to make a sprite follow your character sprite. But I couldn't find any tutorials on how to handle what comes next, other than the rudimentary "overlapping object".
Thanks again for all your insight!
Unfortunately I'm not familiar with tutorials on the matter. I could ask dop2000 who is a true Construct guru for something for you to grab on to maybe. He also has this website howtoconstructdemos.com which features MANY awesome examples, maybe some of them may shed some light on your game.
On another note I would propose that you build a pseudo-code, which means just a general map of features you would like to have in the game and then if possible share it with the community so we can help you achieve what you want.
If you can describe your goals I can totally help you with the logic, and I believe many other people too.
We are here for you, never give up!
Thanks for the link, there are some really neat examples in there, I will take the time to study them.
I have also sort of decided to put off working on "AI" for now, as it seems I need to learn more stuff in the meantime. I will concentrate on making the run&jump part of platforming and add more things incrementally, as I learn how to make them, like wall jumping, grappling hooks, effects, maybe some easy physics stuff. I'm a hands on kind of guy so the idea is that I can get comfortable with game logic, logic gates by following specific examples and then trying to tailor them to my needs/wishes. I am pretty set in making this little project, so not giving up so easily :P (plus I've just bought Spriter Pro as well, so I have to commit!)
I will definitely ask for more help in the (near) future, so thanks for the offer! :)
just an addendum... some of the construct demo's are also explained in video's, and more of them are coming every week. Check out my youtube channel for more examples of how to implement clones of existing games
Thanks for the suggestion, will do :)