If you're interested, here's where you can wishlist Isadora's Edge on Steam! store.steampowered.com/app/3125320/Isadoras_Edge/ And you can follow the Kickstarter here: www.kickstarter.com/projects/inboundshovel/isadoras-edge Thank you!
I love in-depth gamedev content, even though I only play games, never made anything serious. It's just so cool to know the thinking and engenering that goes into it. Makes me appreciate the game more.
as far as stretch goals, DO NOT UNDER ANY CIRCUMSTANCES do any physical rewards for your stretch goals. Alex Preston from Heart Machine in an interview mentioned that he regretted doing physical rewards for his stretch goals
I mean... Could you specify why so I don't have to see if I can find that interview and then watch the whole thing to get context? I can think of a few reasons, shipping costs for one, but if it's something like stickers you could probably mail it really easily and cheaply. But even something like keychains or enamel pins start having a pretty high cost after all of the manufacturing and shipping so I do understand there's a limit.
@@boomgoesthedynamite69 Because you have to get the rewards manufactured, shipped and distributed around the globe which is a ton of work that will be taxing on your budget and time.
I find it extremely funny that this video came out literally THE DAY that I am implementing hitboxes in a fighting game I'm working on. I gotta say that I really love your videos and specifically, that they provide a bit of insight in how professional game devs go about implementing certain systems. I find it tough that so much of game dev tutorials and such target absolute beginners, and often have solutions that are easy to understand, yet don't scale well with actual game development, so i've actually been looking toward this channel specifically for help in the conceptual aspects of implementing systems like this! :)
Worth noting that fighting games apply hitstop on a per-entity basis, not for the whole game e.g if you block a projectile, only character blocking and the projectile itself are affected not the opponent who threw the projectile, some games change the amount of hitstop based on special properties e.g. in Guilty Gear hitting a Counter Hit will apply more hitstop to the enemy than to the player.
Hollow Knight applies hit stops globally for any attacks that hit the player, which makes hits on the player feel especially horrific. But also gives you a moment to register your mistake and hopefully recover from it.
for 1p and 2p games it makes sense but in a 4-player game of Smash you don't want player 1's hitstop from player 2 to freeze the action for players 3 & 4
i have a friend that is making a fighting platformer to, different style and stuff but ive send him almost every single one of your videos because they are so informative on the subject
Im working in my indie game and I always watched your vids for fun. Its now in a new light because its fun and informative for my game dev. Thanks for the great videos 👍
On that note, having one character being in comparatively less "sexy" clothes in a game with a lot of sexy characters does give a certain kind of appeal. *For better or for worse, the Internet will handle the rest.*
Great video! But I just wanted to point out a few things that you should be careful with this type of hitbox system. One problem that may arise is "going through attacks without getting hit". Is similar to the problem of movement collisions going through walls. This is usually fixed by either automatically interpolating hitboxes (Smash bros does this) or simply covering the space of the frame that came before with the hitbox. Another problem that is similar is how the attack looks v.s. how it feels. Using your example of the frog kick, think that the legs didn't just teleport from the ground to that elevated position, they moved there, so in theory if I stand next to the legs before they kick, I should be kicked by the strong part. However, with the example you showed, if there is a sweetspot on the tip but not on the legs and the animation is so fast it only happens in 1 or 2 frames, the chartacter may only be hit by the weak part even though it feels like it should have been hit by the strong one, which feels wrong. Basically what I'm trying to say is, look at how hitboxes are placed in games and you will notice they don't "look right" frame by frame, but when you are playing, they "feel right", because the whole is greater than the sum of its parts (the attack is more than each individual frame). Some attack hitboxes are very simple and work great. Also, smash hitboxes have a priority system so that if you happen to be hit by more than one hitbox of the same attack in the same frame, only one of them will be the one that deals the hit, useful for when you have sweet and sour spots so it is easier/harder to be hit by those (and the obvious one of not dealing more damage than intended). Also also, maybe consider giving the hitboxes their unique player invincibility value so, for example, you can make weak attacks grant less invincibility and stronger attacks more, allowing you to make attacks that can hit you multiple times in quick succession without the invincibility messing it up or, like you mentioned, balancing the fact that players could take the weak hit to gain long invincibility frames. Sorry if my message was too long and overwhelming or it feels as if I'm badly criticizing or the comment simply sounds rude, I hope your game is a great success! (Final) also, a question, since you are handling this frame by frame (and sorry if you have already answered this in a video I haven't watched), is your game always going to run at the same frame rate? if not, how are you going to handle frame data if the game runs at 15 fps in my PC? or at 144? Fighting games are designed to always run at a fixed frame rate exactly because everything is measured in frames. I may be wrong but I think Smash is an exception, however as I mentioned before they interpolate the hitboxes so it doesn't really become a problem (and only runs in a console so they know 99% of the time it will run at its intended frame rate).
Thank you for this write-up, it's super helpful! You're right - I don't have much experience placing my hitboxes, so this is really useful advice! I've seen plenty of "disjointed" hitboxes in Smash, and I never really critically thought about those are useful to cover the "implied motion" of the frame, so that's really important for me to keep in mind when I'm actually placing the hitboxes! I've really only hooked up hitboxes for like, 3 or 4 attacks since I made the system (I have a biiiig to-do list of attacks to build), and boy I'm happy I read this comment before I did all those attacks, you probably single-handedly just /massively/ improved the framedata in my indie game with your comment LOL I might also try interpolating the hitbox, but I think just having the hitboxes built out to incorporate the movement feels nicer to me, I'll play with it and figure out what works best, feeling wise! For the priority, that's something I had already been thinking about, and will definitely add as a field for each piece of frame data, but I hadn't considered the implications of having unique player invincibility values - I'll definitely play with that too! For the frame by frame, right now the animation player runs on idle time (rather than on physics ticks), but I could change that so that the animation players run on physics ticks to avoid any issues with hitbox activation due to low FPS - although the callback style is all deferred, so it /shouldn't/ be an issue. And might even be better because running the AnimationPlayer on physics ticks could theoretically result in the player getting hit by an attack that exclusively happened during frames that didn't even happen on screen, so that's probably something I'll just have to solve if it comes up in playtesting, heh But seriously, thank you so much for your comment - it was really, really helpful!
@@InboundShovelI'm not sure if you covered this specifically, but one other thing worth considering (depending on your design requirements) is grouping hit boxes and hit frames into attack groups and/or having a hit cool downs on those groups (not just on the enemy). This would allow you to have attacks that can hit multiple times without having to rely on a character's i-frames to space out the hits, which could be different from character to character and reaction to reaction. Say for example you want an upwards air attack that can hit up to three times over the duration of a single constant action (maybe a drill spinning upwards that "juggles" the enemy in the air). Well, you have to be able to distinguish those hits from each other, while not relying on enemy i-frames, and you also can't accomplish it by having periodic gaps in your hit boxes, because then you could miss incidental hits on enemies that enter the attack in the middle of the sequence. So you have to be able to say: this set of hit boxes over this duration is part of "X" attack group, which has a hit cool down of "Y" seconds/frames. Then when you detect a collision, before you apply the hit/damage you say "has this enemy already registered a collision from this group, and if so, has the cool down period been expended, and if so, only then take the hit." Hopefully that all made sense. If not, let me know, and I'll try to explain it better. I've got a lot of experience in this area.
As someone who's just starting to learn godot and starting my solo dev journey, this is super helpful and has me motivated to explore this method. I love and appreciate the attention to detail in your videos!
Regarding proration and risc gain, Someone's probably mentioned this already but I haven't seen a comment. Proration is a system that drops the amount of damage the next attack in a combo does so that you can deal decent damage with stray hits without the combos nuking people's health bars. The lower the proration the less damage. (Idk the exact math of how it works) Risc is a system in guilty gear that builds up when you block an attack. Different attacks and characters build different amounts of risc. Once the guage is full the next hit is a counter hit (very sorry I miswrote this I initially put "immediately breaks you out of blocking" instead oops), basically a system to stop people from standing there and blocking for too long.
I really appreciate your explanations on creating your systems. This is an area of development that I struggle with and have been trying to improve on.
23:32 The variation in damage on parts of attacks has interesting speedrunning applications. Routing has to account for what attacks you should tank, what can't you tank, what part of the attack should be used for a damage boost, etc... keep it, it's awesome.
I think that you made a really successful game and content. And I mean this for real, It's my first time watching you outside of shorts, but just your thumbnail and that art style, I immediately recognized this video is made by that guy.
Man I’ve just started game dev and really want to make just a simple fighting game like smash but you explaining it makes me realize how far I am from that
It's a long journey, but it's a fun one! Best of luck - and make sure you link me that Smash-inspired game once you finish it, I'll definitely try it out ;D
This is cool! I'm looking into improving my own attack frame system, soon! I'm in Unity + Aseprite, so I've got a pretty different set of solutions, but it seems like our workflows end up largely similar. Happy to hear your demo and and Kickstarter are coming along, that's so exciting! I'm still months away from even thinking about those things, but I'm looking into the potential of dev vlogging eventually, and find myself taking notes when watching you, so thank you!
On the bit about running tool scripts on the animation player, why not do the opposite. Create a tool script that reads the animation data, list it down and play it on the inspector scene. Kind of like an "animation inspection" tool. I already saw a bunch of games that do this, including games i've worked on. This was based in unity, but we got the animator and read the animation state machine state by state, layer by layer, and created an array of all the animations of that animator, listing it on scene view. We could then click on the animation name to play it on the model in the inspection view. I think it's possible to fuse a system like that to your frame data system.
The animation player node is pretty extensive but i also wanted to find ways to implement a more thorough hitbox system. It was very inspiring to see your implementation of it!
One idea for the taking weaker hits to avoid stronger hits problem. Identify the attacker so that I-frames make you invinsible to other attackers, but if the same enemy/source has other hitboxes that come out while you're in knockback, those ones still hit.
23:30 one possible solution would be to give some hitboxes an additional "juggle" variable, which basically tells the game "don't activate I-frames when this attack connects, because it's here to put them in position for the haymaker"
As someone who's just learning Unity in hopes of one day making my own platfighter a la Smash, this might be one of the most important videos that ive accidentally found! Thanks for giving me hope and showing me that this kind of thing IS possible
whao, this video properly made me understand fighting game frame data methods of hitboxes, thanks! (now imma go sit and deeply think about wtf im gonna do with my game's combat collision systems XD)
Man I recently discovered your channel through shorts, and as a competitive fighting game player and indie game dev I love that you're bringing this topic up. Frighting games are such important study material for any game designer. From risk reward scenarios, to how interactions function - they are a gold mine.
6:49 proration is typically a modifier that drops down the damage of attacks that come after to said percentage (for example if you hit an attack that does 1000 damage with 80% proration and then do the same attack directly after (assuming it does combo) the second time you hit you'll do 800 damage).
I will say one thing. As a single player this is great but if it was multiplayer, you probably would have to use fill in colliders for those empty gaps between hit boxes. You would have to let the next frame have hitboxes that are behind the whip to cover the gap
I hope this is helpful, as I think the way I do it fulfills all of your requirements but is even more simple and easy to manage. What I do is simply make the hitbox its own scene which inherits from a generic hitbox Area2D. I have a generic "spawn hitbox" function on the character which takes a packed scene. So when the attack animation needs its hitbox I use the animation player's call method track so simply spawn it. The hitbox scene handles everything else itself, again via an animation player with an autoplay animation. There you can add anything you need like VFX, enabling/disabling any monitoring or collision areas, changing any sprite frames, or whatever. Finally, when the hitbox animation is finished it calls queue free on the node via another call method track and cleans itself up. As far as I can tell this is frame perfect and requires no communication or setup on the character other than the animation needing a packed scene to call.
Silly question, why isn't the frame data just encoded as an animation? With 24bit images you could encode just about everything there could be into the image itself and wouldn't be limited to hitbox shapes but could use pixel perfect hitboxes. Damage could be encoded in R channel, thus giving 255 different options, with logarithmic damage it would scale well, also you could have hitboxes with gradient damage. G channel could encode effects like push/pull, allowing easily 16 effects with 16 parameters, like pull and 4 directions and 3 strenghts, or using G and B channels for this, you can easily have 256 effects/options with each 256 different options. You could even encode things likes, passes thru walls etc into the bits. Or for more fun, have simple encoding but allow animation to have multiple effect layers. This would be nice too as you can use the same effects in other game objects and even backgrounds or level art. Need a damaging block, just draw damage halo around it. Need slippery walls, just add ice halo around the blocks etc. To allow multiple effects from multiple objects, it is easy to add dithering, that is only required if you wanna make a shader that computes the hits and effects. If you do the check per enemy vs player basis, you only need to compare those two objects.
Collisions are still being processed by Godot's internal physics system, which uses "mathematically-defined" collision shapes (in 2D they're vector shapes, in 3D they're CSGs and other simple functions), as well as triangulated meshes (2D and 3D). Using sprites for collisions (similar to how Rivals of Aether works) is a really cool idea, but needs custom implementation. The closest I got to doing that was an editor script that took image frames and computed tri meshes that _roughly fit_ the pixels, to be used as collision shapes. I'd also not recommend using different values per pixel because most collision algos (AABBs, OOBs, CSG collisions, Mesh collisions) test if a collision happens, but not _what parts of the shape are inside or outside_. You can't seek which pixels are inside or outside the collision zone to get an average or sum of the damage (you can, but that's not doable for real time, that's gradient simulation).
@ with per pixel collision shader you get overlapping number of pixels per sprite pair for free (well 8 or 16 bits per sprite pair depending how many values you want)
o7 Mango. I hope they feel better soon!! Edit: I really want to draw pixel art and stuff... BUT fractured both of my bones in my right arm (Dominant arm), so issues have emerged...
I love the system, I'm a big sucker for easily customizable and consistent systems. But for the one attack that hits with different effects on different places, it could mess with the player's expectations. Because when they got hit once by the attack and got one effect and then get hit with same attack and get a different one it could lead to frustration if it's not obvious why. So that's definitely sth to watch out for
I'm glad I didn't see this video when I was doing my summer project or I would never have finished cause I'd be trying to perfect it XD However, I definitely will try to implement this in my new project! Thank you so much!
I've been following you for a while now and I really gotta compliment you and your team here. There's so much thinking and consideration involved when making decisions. As a developer I'm so happy seeing this from an indie game (actually seeing this in any kind of project is awesome!) A little suggestion on the framedata and i.frames, perhaps you could set a i.frame duration after getting hit by a certain hitbox, combine that with a knockback duration, you could set up for a combo for the enemy. I imagine getting sucked in by a sourspot hit from the whip, only to get launched back after a big swing forward. Also, I would love to play the demo and show it on youtube if that's allowed? (though I don't have a big channel, I'd really love to showcase it) Awesome work and looking forward to your next update! ♥️
Great video! It reminds me of a similar system I made for Linked Mask in Unity, where the animation would be done in aseprite, with some of the layers having the collision frame data of each animation frame, this included the collision boxes, the hurt boxes and the damage boxes. Since aseprite lets you export as json I would have the main sprites form the spritesheet and then a json file for the boxes data. I remember it was pretty flexible, even allowing to add where and what particle effect you wanted for each frame and so on.
I’m so excited for this, I’m totally gonna steam it when it’s out. Gives very faint Celeste vibes (my favorite game) but any female lead pixel platformer kinda will
Regarding stretch goals and rewards, consider making use of assets that you already have, such as music and artworks, that can be compiled into an ost and artbook in digital forms with minimal extra work on your part. As someone pointed out already, physical rewards can be a headache to figure out the logistic of, and since they involve more links in the production chain they are prone to delays if even one thing goes wrong. One cool thing that you could try is one thing hollow knight did, where many bugs in the game were voiced by contributors. If this applies to your game and it's not fully voiced then it could be a thing to set up for higher tiers donations? They also have the graveyard area with the contibutors, so you could try something along those lines as well, though it's more work. The Ratatan kickstarter had some simillar ideas, if I remember correctly (it's closed but you can check it out for reference), where a limitted numbers of spots allowed contributors to name an ennemy, have their names engraved in a tombstone in game, or even design an enemy. Those were all limitted in numbers, and expensive tiers of contributions, but it's something that would otherwise be manageable even on your scale, I think. Concerning your current lack of background artist, you could try to use your platform to make an appeal, with a link to where to send their portfolio and/or a google doc referencing what you're looking for. It's fine to look for them, but if you put an offer then you can also have them come to you. If you do, though, be as precise as you can regarding what you're looking for and what the work will entail, it'll save time for everyone involved (source: I'm an illustrator). Still, I hope Mango does gets better and is able to come back.
Stretch goal ideas for ya: 1: A boss rush/challenge mode. 2: A rougelike mode that can randomly give things per encounter. 3: New Game Plus mode. 4: Colorization for the Main Character that can be unlocked via some internal goals. 5: An "cheat" mode, that gives some goofy things you can unlock, ala old NES, PS1, and XBOX days. (Big head mode is something I can think of but doesn't really fit in this game, but gives the idea that I'm talking about. But maybe something that swaps the sounds of the attacks out for some goofy sounds like Cat meows, Cow sounds, or quacks. XD) I've yet to get to the building part of my game, but this shows something I had been worried about for a while. I honestly wish I could get my hands on that system you're using, but fully understand that it is all yours and is for your game. Awesome AWESOME stuff all the same though. I hope your Background artist heals up fully before coming back, and I hope your kickstarter goes over well. So far, it seems you've got the solid points of a game locked down and don't seem to be willing to SUDDENLY shifting things at a moment's notice. (Daikatana comes to mind.) So I know the game will be a good one when it comes out, I just hope luck will be on your side when it does. ^^
Dude this is fucking dope, I love how this looks and how intuitive it is. I wish I was still using Godot 4 so I could take advantage of this beautiful plugin! ❤
Oh with the status thing, you could add a placeholder 'Status A' / b / c which would allow you to, say, tip your sword with poison, which then makes all your 'Status A' attacks deal poison for a short time...
You mentioned the idea of different hitboxes in an animation dealing different amounts of damage (so there might be a 1 damage hitbox and a 3 damage hitbox in the same attack). I think it's a neat idea, but as you say with I-frames it may incentivize damage boosting with light hits, or it may make attacks feel inconsistent. The best solution I can think of is to let the bigger damage frames of attacks still hit and deal partial damage even if you have I-frames from a previous frame of the same attack.
i would love to see how to implement and like actually use this system for other projects ngl, looks like something that would make making complex real time 2d fighting systems a lot nicer to make and stuff
Fun fact, not even a closed source game engine can allow building directly to game consoles either, they have to first ensure that you've signed the NDAs before they can allow that legally. So in essence, it doesn't actually make much difference if it's a FOSS engine or not. Well, not with the MIT license like Godot has at least. For GPL style engines you wouldn't actually be allowed to make the necessary changes since you'd be forced to release the source code which would break the required console licensing.
Said this in another comment but wanna spread it as wide as possible: a group of devs released FOSS build tools for Godot that they distribute freely but only to approved Nintendo developers. From what I understand the legality is only that you need to be approved and agree to Nintendo's license to be allowed to see any code written for their hardware.
@Sylfa and @hotworlds Great info! I saw there were some efforts going into getting Godot able to build to console directly, but I haven't read too much into it myself, so thanks for putting this on my radar! :D Maybe it'll be more possible to release on console than I was thinking, heh heh
The system seems nice. But what would you do if you want to double the damage of a weapon? Would you need to change all data frame by frame, attack by attack...?
10:11 What's "ugly" about your script? What do you think all software runs with? Code! You would have nothing without code and compilers! You made the best "looking" (not that that's important) script possible for the purpose! Don't be weird about code!
That's definitely just something all coders go through, I think. I'm definitely guilty of calling my own ugly and an ungodly abomination when, in reality, it's just fine
I love the idea of taking a weaker hit to avoid the stronger hit, but I don't think it should invincible through it all the time. I think it would be better to have less damaging hits give less invincibility so the weak hit could potentially combo into the strong hit based on how the player reacts, the knockback of the attack and the environment around them.
I guess the best way to do this would be to give the hitboxes a custom invincibility frame number to give the player. This would also open up opportunities for enemies to have multi hit attacks that the player could potential DI (directional input) out of part way through to reduce damage.
Wouldn"t be too difficult to add to 3d looking at it. Could make for some very dynamic combat. Wonder if any other games outside of fighting games use this kind of system.
To start, I love how open you are with the tech side and the info that most wouldn't say. Thank you for that. As for goals... would you like a 3D model to be made of your character for 3D printing and Selling? I'm pretty good at modeling character and your design seems easy enough. I had to go to sleep, but after seeing and hearing this I had to do some theory crafting for my game. Lol I looked at the time 20mins in, "Forget it, I may as well stay up." XD So, the system you have is very easy and completely adjustable from all the things you've showed, it seems that you have very good understanding and skills on editing code, now if only you worked with Unreal Engine I could learn something I could potentially use myself. Seems like you gave all your ducks in a row, not much feedback I could give for this lesson on your work unlike your slope problems. keep it up, I'd like to see more of this truly. Oh, and don't shy away from showing things that's not in the demo, it'd make more people want the full game. o(^ v
The way i would go is making a single PoligonCollider and animating the properties disabled and `poligon` (which is a PackedVector2Array). Since this Node doesnt use a resource you can freely modify and keyframe the shape and even count of vertexes of the polygons and it would not affect other instances of the same enemy. Still would try to precent many enemies spaming animations of this kind all at the same time. Is also important to set playing the animation in physics process instead of process
Btw, one way to execute code from animation player is puttin a setter to a property and animating the property, if the script is a @tool script it will execute
you said in a couple of devlogs and in the kickstarter page that isadora's edge is "Inspired by games like Hollow Knight, Megaman X, and Castlevania" which when you explain yourself in devlogs is fine but on the kickstarter page it is kinda misleading because saying a game is inspired by hollow knight and castlevania gives people the idea of a metroidvania which your game isn't so i think to avoid misleading wording you should spell out the genre more clearly
You gave Dahyun a voice and responded to you in the video you now legally have to make her a video mascot who occasionally pops in and talks shit about Isadora
![The question I get asked the most often as a Game Dev... [Q&A]](http://i.ytimg.com/vi/4dFBQtZMeqs/mqdefault.jpg)
If you're interested, here's where you can wishlist Isadora's Edge on Steam! store.steampowered.com/app/3125320/Isadoras_Edge/
And you can follow the Kickstarter here: www.kickstarter.com/projects/inboundshovel/isadoras-edge
Thank you!
can't wait for it! 😁
Have you considered releasing the game on GOG?
I'd love to buy it there.
im actuaIIy a 3d artist and i have a technique that i couId use for environment art
As someone who's in the works of fighting games, this was really fun to learn and see!
Glad you enjoyed it!
Where can i see your work if you dont mind ?
@@yamjianthewolf8031 do ur own research
I love in-depth gamedev content, even though I only play games, never made anything serious. It's just so cool to know the thinking and engenering that goes into it. Makes me appreciate the game more.
as far as stretch goals, DO NOT UNDER ANY CIRCUMSTANCES do any physical rewards for your stretch goals. Alex Preston from Heart Machine in an interview mentioned that he regretted doing physical rewards for his stretch goals
I mean... Could you specify why so I don't have to see if I can find that interview and then watch the whole thing to get context?
I can think of a few reasons, shipping costs for one, but if it's something like stickers you could probably mail it really easily and cheaply. But even something like keychains or enamel pins start having a pretty high cost after all of the manufacturing and shipping so I do understand there's a limit.
"A guy said he regretted it" isn't advice... Why did he regret it? What specific physical rewards caused problems and why?
Given that a short "what" has already been written. It's quite reasonable to add a short "why" for clarity. To see whether it's general or specific.
@@boomgoesthedynamite69 Because you have to get the rewards manufactured, shipped and distributed around the globe which is a ton of work that will be taxing on your budget and time.
It’s been 9 days, if only he hadn’t given physical rewards, he might still be alive with us today to tell us the reason
I find it extremely funny that this video came out literally THE DAY that I am implementing hitboxes in a fighting game I'm working on. I gotta say that I really love your videos and specifically, that they provide a bit of insight in how professional game devs go about implementing certain systems. I find it tough that so much of game dev tutorials and such target absolute beginners, and often have solutions that are easy to understand, yet don't scale well with actual game development, so i've actually been looking toward this channel specifically for help in the conceptual aspects of implementing systems like this! :)
Worth noting that fighting games apply hitstop on a per-entity basis, not for the whole game e.g if you block a projectile, only character blocking and the projectile itself are affected not the opponent who threw the projectile, some games change the amount of hitstop based on special properties e.g. in Guilty Gear hitting a Counter Hit will apply more hitstop to the enemy than to the player.
Oh, that's a great point - I hadn't even thought about varying hitstop across entities! Thank you! :D
Hollow Knight applies hit stops globally for any attacks that hit the player, which makes hits on the player feel especially horrific. But also gives you a moment to register your mistake and hopefully recover from it.
for 1p and 2p games it makes sense but in a 4-player game of Smash you don't want player 1's hitstop from player 2 to freeze the action for players 3 & 4
i have a friend that is making a fighting platformer to, different style and stuff but ive send him almost every single one of your videos because they are so informative on the subject
Im working in my indie game and I always watched your vids for fun. Its now in a new light because its fun and informative for my game dev. Thanks for the great videos 👍
Internal demon: You should be sexier.
Isadora: Fuck that, I'm slaying mushroom infected monsters!
But that's the neat part about art. It isn't bound by logical limitations so emphasis CAN be put onto aesthetics.
On that note, having one character being in comparatively less "sexy" clothes in a game with a lot of sexy characters does give a certain kind of appeal. *For better or for worse, the Internet will handle the rest.*
Great video! But I just wanted to point out a few things that you should be careful with this type of hitbox system.
One problem that may arise is "going through attacks without getting hit". Is similar to the problem of movement collisions going through walls. This is usually fixed by either automatically interpolating hitboxes (Smash bros does this) or simply covering the space of the frame that came before with the hitbox.
Another problem that is similar is how the attack looks v.s. how it feels. Using your example of the frog kick, think that the legs didn't just teleport from the ground to that elevated position, they moved there, so in theory if I stand next to the legs before they kick, I should be kicked by the strong part. However, with the example you showed, if there is a sweetspot on the tip but not on the legs and the animation is so fast it only happens in 1 or 2 frames, the chartacter may only be hit by the weak part even though it feels like it should have been hit by the strong one, which feels wrong.
Basically what I'm trying to say is, look at how hitboxes are placed in games and you will notice they don't "look right" frame by frame, but when you are playing, they "feel right", because the whole is greater than the sum of its parts (the attack is more than each individual frame). Some attack hitboxes are very simple and work great.
Also, smash hitboxes have a priority system so that if you happen to be hit by more than one hitbox of the same attack in the same frame, only one of them will be the one that deals the hit, useful for when you have sweet and sour spots so it is easier/harder to be hit by those (and the obvious one of not dealing more damage than intended). Also also, maybe consider giving the hitboxes their unique player invincibility value so, for example, you can make weak attacks grant less invincibility and stronger attacks more, allowing you to make attacks that can hit you multiple times in quick succession without the invincibility messing it up or, like you mentioned, balancing the fact that players could take the weak hit to gain long invincibility frames.
Sorry if my message was too long and overwhelming or it feels as if I'm badly criticizing or the comment simply sounds rude, I hope your game is a great success!
(Final) also, a question, since you are handling this frame by frame (and sorry if you have already answered this in a video I haven't watched), is your game always going to run at the same frame rate? if not, how are you going to handle frame data if the game runs at 15 fps in my PC? or at 144? Fighting games are designed to always run at a fixed frame rate exactly because everything is measured in frames. I may be wrong but I think Smash is an exception, however as I mentioned before they interpolate the hitboxes so it doesn't really become a problem (and only runs in a console so they know 99% of the time it will run at its intended frame rate).
Thank you for this write-up, it's super helpful!
You're right - I don't have much experience placing my hitboxes, so this is really useful advice! I've seen plenty of "disjointed" hitboxes in Smash, and I never really critically thought about those are useful to cover the "implied motion" of the frame, so that's really important for me to keep in mind when I'm actually placing the hitboxes! I've really only hooked up hitboxes for like, 3 or 4 attacks since I made the system (I have a biiiig to-do list of attacks to build), and boy I'm happy I read this comment before I did all those attacks, you probably single-handedly just /massively/ improved the framedata in my indie game with your comment LOL
I might also try interpolating the hitbox, but I think just having the hitboxes built out to incorporate the movement feels nicer to me, I'll play with it and figure out what works best, feeling wise!
For the priority, that's something I had already been thinking about, and will definitely add as a field for each piece of frame data, but I hadn't considered the implications of having unique player invincibility values - I'll definitely play with that too!
For the frame by frame, right now the animation player runs on idle time (rather than on physics ticks), but I could change that so that the animation players run on physics ticks to avoid any issues with hitbox activation due to low FPS - although the callback style is all deferred, so it /shouldn't/ be an issue. And might even be better because running the AnimationPlayer on physics ticks could theoretically result in the player getting hit by an attack that exclusively happened during frames that didn't even happen on screen, so that's probably something I'll just have to solve if it comes up in playtesting, heh
But seriously, thank you so much for your comment - it was really, really helpful!
I came to the comments to give this exact write-up, but looks like you beat me to it! 🙃
@@InboundShovelI'm not sure if you covered this specifically, but one other thing worth considering (depending on your design requirements) is grouping hit boxes and hit frames into attack groups and/or having a hit cool downs on those groups (not just on the enemy). This would allow you to have attacks that can hit multiple times without having to rely on a character's i-frames to space out the hits, which could be different from character to character and reaction to reaction.
Say for example you want an upwards air attack that can hit up to three times over the duration of a single constant action (maybe a drill spinning upwards that "juggles" the enemy in the air). Well, you have to be able to distinguish those hits from each other, while not relying on enemy i-frames, and you also can't accomplish it by having periodic gaps in your hit boxes, because then you could miss incidental hits on enemies that enter the attack in the middle of the sequence. So you have to be able to say: this set of hit boxes over this duration is part of "X" attack group, which has a hit cool down of "Y" seconds/frames.
Then when you detect a collision, before you apply the hit/damage you say "has this enemy already registered a collision from this group, and if so, has the cool down period been expended, and if so, only then take the hit."
Hopefully that all made sense. If not, let me know, and I'll try to explain it better. I've got a lot of experience in this area.
As someone who's just starting to learn godot and starting my solo dev journey, this is super helpful and has me motivated to explore this method. I love and appreciate the attention to detail in your videos!
Regarding proration and risc gain, Someone's probably mentioned this already but I haven't seen a comment.
Proration is a system that drops the amount of damage the next attack in a combo does so that you can deal decent damage with stray hits without the combos nuking people's health bars. The lower the proration the less damage. (Idk the exact math of how it works)
Risc is a system in guilty gear that builds up when you block an attack. Different attacks and characters build different amounts of risc. Once the guage is full the next hit is a counter hit (very sorry I miswrote this I initially put "immediately breaks you out of blocking" instead oops), basically a system to stop people from standing there and blocking for too long.
Full risc doesn't break you out of blocking, I don't know if older games have that but certainly not the latest one.
@@sleepfgc yeah I wrote the wrong thing should be fixed now
I really appreciate your explanations on creating your systems. This is an area of development that I struggle with and have been trying to improve on.
23:32 The variation in damage on parts of attacks has interesting speedrunning applications. Routing has to account for what attacks you should tank, what can't you tank, what part of the attack should be used for a damage boost, etc... keep it, it's awesome.
I think that you made a really successful game and content. And I mean this for real, It's my first time watching you outside of shorts, but just your thumbnail and that art style, I immediately recognized this video is made by that guy.
Bro can rap faster than m&m!!
Amazing video. Your shorts was one of the reasons I started to get into game development... So thanks and I wish you the best.
LMAO I loved the apology to the sprite.
Man I’ve just started game dev and really want to make just a simple fighting game like smash but you explaining it makes me realize how far I am from that
Also literally liked and left this comment right before the part where you assume I already did those things 😅
It's a long journey, but it's a fun one! Best of luck - and make sure you link me that Smash-inspired game once you finish it, I'll definitely try it out ;D
This is cool! I'm looking into improving my own attack frame system, soon! I'm in Unity + Aseprite, so I've got a pretty different set of solutions, but it seems like our workflows end up largely similar.
Happy to hear your demo and and Kickstarter are coming along, that's so exciting! I'm still months away from even thinking about those things, but I'm looking into the potential of dev vlogging eventually, and find myself taking notes when watching you, so thank you!
On the bit about running tool scripts on the animation player, why not do the opposite.
Create a tool script that reads the animation data, list it down and play it on the inspector scene.
Kind of like an "animation inspection" tool.
I already saw a bunch of games that do this, including games i've worked on.
This was based in unity, but we got the animator and read the animation state machine state by state, layer by layer, and created an array of all the animations of that animator, listing it on scene view. We could then click on the animation name to play it on the model in the inspection view.
I think it's possible to fuse a system like that to your frame data system.
Oh wow, this is a fantastic suggestion - thank you!
Glad to have helped!!! :D
Hope it's feasable on Godot and in your project! ^.^
Nice work! Consider to open source the frame data system as a Godot addon!
This was a fantastic breakdown and there are many helpful comments! If you improve upon this system I would love to see an update video :)
Very cool, super detailed video! Absolutely loved the thoroughness of this one!
a system like this feels like its getting close to something youd be able to release as its own plugin. awesome work
I've been following JD for quiiite a while now and JD is a machine gun of art. So talented...
I love your channel and thanks for your videos! They're a great source of motivation and I can't wait to play your game one day
Woah 15 seconds ago thats crazy! Looking forward to this game!
The animation player node is pretty extensive but i also wanted to find ways to implement a more thorough hitbox system. It was very inspiring to see your implementation of it!
One idea for the taking weaker hits to avoid stronger hits problem.
Identify the attacker so that I-frames make you invinsible to other attackers, but if the same enemy/source has other hitboxes that come out while you're in knockback, those ones still hit.
23:30 one possible solution would be to give some hitboxes an additional "juggle" variable, which basically tells the game "don't activate I-frames when this attack connects, because it's here to put them in position for the haymaker"
one day I'll learn how to do this fancy frame data stuff, untill there now I have a video to use as inspiration! good work!
As someone who's just learning Unity in hopes of one day making my own platfighter a la Smash, this might be one of the most important videos that ive accidentally found! Thanks for giving me hope and showing me that this kind of thing IS possible
Great video! Worth the watch, many insights that will help me and others when considering hitbox data implementations.
Goodluck!
Yeah, I love these videos where you really into the weeds! Keep it up! :D
First I've heard about @tool in Godot, definitely going to be implementing this for my own project. Great devlog!
Absolutely amazing.
Thanks again mate. ❤
Hope mango gets well soon 🔜
whao, this video properly made me understand fighting game frame data methods of hitboxes, thanks! (now imma go sit and deeply think about wtf im gonna do with my game's combat collision systems XD)
This was an amazing video! Thank you!
Man I recently discovered your channel through shorts, and as a competitive fighting game player and indie game dev I love that you're bringing this topic up. Frighting games are such important study material for any game designer. From risk reward scenarios, to how interactions function - they are a gold mine.
You've inspired me to start working on a game project that I've had in mind for a while
6:49 proration is typically a modifier that drops down the damage of attacks that come after to said percentage (for example if you hit an attack that does 1000 damage with 80% proration and then do the same attack directly after (assuming it does combo) the second time you hit you'll do 800 damage).
I've been waiting on something like this for a long time. I have to implement something like this soon.
Dang G you're doing so much in so little time, great job staying focused on your game's development!
This is really interesting! And keep making great content
A
W
E
S
O
M
E
!
This was awesome. Very cool to see the implementation of this.
I will say one thing. As a single player this is great but if it was multiplayer, you probably would have to use fill in colliders for those empty gaps between hit boxes. You would have to let the next frame have hitboxes that are behind the whip to cover the gap
I hope this is helpful, as I think the way I do it fulfills all of your requirements but is even more simple and easy to manage.
What I do is simply make the hitbox its own scene which inherits from a generic hitbox Area2D. I have a generic "spawn hitbox" function on the character which takes a packed scene. So when the attack animation needs its hitbox I use the animation player's call method track so simply spawn it. The hitbox scene handles everything else itself, again via an animation player with an autoplay animation. There you can add anything you need like VFX, enabling/disabling any monitoring or collision areas, changing any sprite frames, or whatever. Finally, when the hitbox animation is finished it calls queue free on the node via another call method track and cleans itself up.
As far as I can tell this is frame perfect and requires no communication or setup on the character other than the animation needing a packed scene to call.
Silly question, why isn't the frame data just encoded as an animation? With 24bit images you could encode just about everything there could be into the image itself and wouldn't be limited to hitbox shapes but could use pixel perfect hitboxes. Damage could be encoded in R channel, thus giving 255 different options, with logarithmic damage it would scale well, also you could have hitboxes with gradient damage. G channel could encode effects like push/pull, allowing easily 16 effects with 16 parameters, like pull and 4 directions and 3 strenghts, or using G and B channels for this, you can easily have 256 effects/options with each 256 different options. You could even encode things likes, passes thru walls etc into the bits. Or for more fun, have simple encoding but allow animation to have multiple effect layers. This would be nice too as you can use the same effects in other game objects and even backgrounds or level art. Need a damaging block, just draw damage halo around it. Need slippery walls, just add ice halo around the blocks etc.
To allow multiple effects from multiple objects, it is easy to add dithering, that is only required if you wanna make a shader that computes the hits and effects. If you do the check per enemy vs player basis, you only need to compare those two objects.
Collisions are still being processed by Godot's internal physics system, which uses "mathematically-defined" collision shapes (in 2D they're vector shapes, in 3D they're CSGs and other simple functions), as well as triangulated meshes (2D and 3D).
Using sprites for collisions (similar to how Rivals of Aether works) is a really cool idea, but needs custom implementation. The closest I got to doing that was an editor script that took image frames and computed tri meshes that _roughly fit_ the pixels, to be used as collision shapes.
I'd also not recommend using different values per pixel because most collision algos (AABBs, OOBs, CSG collisions, Mesh collisions) test if a collision happens, but not _what parts of the shape are inside or outside_. You can't seek which pixels are inside or outside the collision zone to get an average or sum of the damage (you can, but that's not doable for real time, that's gradient simulation).
@ with per pixel collision shader you get overlapping number of pixels per sprite pair for free (well 8 or 16 bits per sprite pair depending how many values you want)
fantastic content
o7 Mango. I hope they feel better soon!!
Edit: I really want to draw pixel art and stuff... BUT fractured both of my bones in my right arm (Dominant arm), so issues have emerged...
I love the system, I'm a big sucker for easily customizable and consistent systems. But for the one attack that hits with different effects on different places, it could mess with the player's expectations. Because when they got hit once by the attack and got one effect and then get hit with same attack and get a different one it could lead to frustration if it's not obvious why. So that's definitely sth to watch out for
For folks. The Fighting game Frame data system starts at 5:55 .:.
0:00 Random things
5:55 Frame data system
I hope mango gets better!
I'm glad I didn't see this video when I was doing my summer project or I would never have finished cause I'd be trying to perfect it XD
However, I definitely will try to implement this in my new project! Thank you so much!
I've been following you for a while now and I really gotta compliment you and your team here. There's so much thinking and consideration involved when making decisions. As a developer I'm so happy seeing this from an indie game (actually seeing this in any kind of project is awesome!)
A little suggestion on the framedata and i.frames, perhaps you could set a i.frame duration after getting hit by a certain hitbox, combine that with a knockback duration, you could set up for a combo for the enemy. I imagine getting sucked in by a sourspot hit from the whip, only to get launched back after a big swing forward.
Also, I would love to play the demo and show it on youtube if that's allowed? (though I don't have a big channel, I'd really love to showcase it)
Awesome work and looking forward to your next update! ♥️
Great video! It reminds me of a similar system I made for Linked Mask in Unity, where the animation would be done in aseprite, with some of the layers having the collision frame data of each animation frame, this included the collision boxes, the hurt boxes and the damage boxes. Since aseprite lets you export as json I would have the main sprites form the spritesheet and then a json file for the boxes data. I remember it was pretty flexible, even allowing to add where and what particle effect you wanted for each frame and so on.
I’m so excited for this, I’m totally gonna steam it when it’s out. Gives very faint Celeste vibes (my favorite game) but any female lead pixel platformer kinda will
Really really helpful! love ya videos.
Go into as much detail as you want, big dog. That was fascinating.
Multiplayer as a goal pleaseeeeeeeeeeee
Regarding stretch goals and rewards, consider making use of assets that you already have, such as music and artworks, that can be compiled into an ost and artbook in digital forms with minimal extra work on your part.
As someone pointed out already, physical rewards can be a headache to figure out the logistic of, and since they involve more links in the production chain they are prone to delays if even one thing goes wrong.
One cool thing that you could try is one thing hollow knight did, where many bugs in the game were voiced by contributors. If this applies to your game and it's not fully voiced then it could be a thing to set up for higher tiers donations? They also have the graveyard area with the contibutors, so you could try something along those lines as well, though it's more work.
The Ratatan kickstarter had some simillar ideas, if I remember correctly (it's closed but you can check it out for reference), where a limitted numbers of spots allowed contributors to name an ennemy, have their names engraved in a tombstone in game, or even design an enemy. Those were all limitted in numbers, and expensive tiers of contributions, but it's something that would otherwise be manageable even on your scale, I think.
Concerning your current lack of background artist, you could try to use your platform to make an appeal, with a link to where to send their portfolio and/or a google doc referencing what you're looking for. It's fine to look for them, but if you put an offer then you can also have them come to you. If you do, though, be as precise as you can regarding what you're looking for and what the work will entail, it'll save time for everyone involved (source: I'm an illustrator).
Still, I hope Mango does gets better and is able to come back.
To me you should go more in-depth into the technical details , I'm just starting with Godot and it really helps me out !!
Hey that's so cool !
Stretch goal ideas for ya:
1: A boss rush/challenge mode.
2: A rougelike mode that can randomly give things per encounter.
3: New Game Plus mode.
4: Colorization for the Main Character that can be unlocked via some internal goals.
5: An "cheat" mode, that gives some goofy things you can unlock, ala old NES, PS1, and XBOX days. (Big head mode is something I can think of but doesn't really fit in this game, but gives the idea that I'm talking about. But maybe something that swaps the sounds of the attacks out for some goofy sounds like Cat meows, Cow sounds, or quacks. XD)
I've yet to get to the building part of my game, but this shows something I had been worried about for a while. I honestly wish I could get my hands on that system you're using, but fully understand that it is all yours and is for your game. Awesome AWESOME stuff all the same though.
I hope your Background artist heals up fully before coming back, and I hope your kickstarter goes over well. So far, it seems you've got the solid points of a game locked down and don't seem to be willing to SUDDENLY shifting things at a moment's notice. (Daikatana comes to mind.) So I know the game will be a good one when it comes out, I just hope luck will be on your side when it does. ^^
Those stretch goals are really great ideas, I'll definitely note them down for later use, haha!
And thank you, I really appreciate your comment!
Dude this is fucking dope, I love how this looks and how intuitive it is.
I wish I was still using Godot 4 so I could take advantage of this beautiful plugin! ❤
This is a a BANGER video
if the key art's isadora existed as human in real life i would marry her
I feel the simps will come fast now (nothing against you in particular, just people with questionable morals simping over Isadora)
@@DJCosmas lol
Oh with the status thing, you could add a placeholder 'Status A' / b / c which would allow you to, say, tip your sword with poison, which then makes all your 'Status A' attacks deal poison for a short time...
the art (both pixel and the game art) reminds me of The Messenger's art.
Stretch goals. In terms of goals, if you eventually get to make console ports, a physical edition of the game would be nice.
Oh yeah, that would be awesome!
You mentioned the idea of different hitboxes in an animation dealing different amounts of damage (so there might be a 1 damage hitbox and a 3 damage hitbox in the same attack). I think it's a neat idea, but as you say with I-frames it may incentivize damage boosting with light hits, or it may make attacks feel inconsistent. The best solution I can think of is to let the bigger damage frames of attacks still hit and deal partial damage even if you have I-frames from a previous frame of the same attack.
i would love to see how to implement and like actually use this system for other projects ngl, looks like something that would make making complex real time 2d fighting systems a lot nicer to make and stuff
Fun fact, not even a closed source game engine can allow building directly to game consoles either, they have to first ensure that you've signed the NDAs before they can allow that legally.
So in essence, it doesn't actually make much difference if it's a FOSS engine or not. Well, not with the MIT license like Godot has at least. For GPL style engines you wouldn't actually be allowed to make the necessary changes since you'd be forced to release the source code which would break the required console licensing.
Said this in another comment but wanna spread it as wide as possible: a group of devs released FOSS build tools for Godot that they distribute freely but only to approved Nintendo developers. From what I understand the legality is only that you need to be approved and agree to Nintendo's license to be allowed to see any code written for their hardware.
@Sylfa and @hotworlds
Great info! I saw there were some efforts going into getting Godot able to build to console directly, but I haven't read too much into it myself, so thanks for putting this on my radar! :D
Maybe it'll be more possible to release on console than I was thinking, heh heh
The system seems nice. But what would you do if you want to double the damage of a weapon? Would you need to change all data frame by frame, attack by attack...?
Yeah this was super helpful Great video
I’m going to make an action rpg blended with real competitive fighting game mechanics. Ima be using this video
pull a shovel knight and have 2nd playable campaign as a stretch goal!
60% a joke
That's a really interesting idea! I'll think about it! :D
You sir, caught my attention
ooooh might want to use something like this
takes notes
OKay but like, I literally need your frame data system xD
10:11 What's "ugly" about your script?
What do you think all software runs with? Code!
You would have nothing without code and compilers!
You made the best "looking" (not that that's important) script possible for the purpose!
Don't be weird about code!
That's definitely just something all coders go through, I think. I'm definitely guilty of calling my own ugly and an ungodly abomination when, in reality, it's just fine
I love the idea of taking a weaker hit to avoid the stronger hit, but I don't think it should invincible through it all the time. I think it would be better to have less damaging hits give less invincibility so the weak hit could potentially combo into the strong hit based on how the player reacts, the knockback of the attack and the environment around them.
I guess the best way to do this would be to give the hitboxes a custom invincibility frame number to give the player. This would also open up opportunities for enemies to have multi hit attacks that the player could potential DI (directional input) out of part way through to reduce damage.
i gagged when you said dommy mommy and im so glad you acknowledged it
I love how hollow knight just has (* frame hit with simple box*)
Definitely has some room for even more streamlining, but overall this is cool as hell
Okay now you're really cooking
This clarified one thing, I'm never making a fighting game
Wouldn"t be too difficult to add to 3d looking at it. Could make for some very dynamic combat. Wonder if any other games outside of fighting games use this kind of system.
all love
To start, I love how open you are with the tech side and the info that most wouldn't say. Thank you for that. As for goals... would you like a 3D model to be made of your character for 3D printing and Selling? I'm pretty good at modeling character and your design seems easy enough.
I had to go to sleep, but after seeing and hearing this I had to do some theory crafting for my game. Lol I looked at the time 20mins in, "Forget it, I may as well stay up." XD
So, the system you have is very easy and completely adjustable from all the things you've showed, it seems that you have very good understanding and skills on editing code, now if only you worked with Unreal Engine I could learn something I could potentially use myself. Seems like you gave all your ducks in a row, not much feedback I could give for this lesson on your work unlike your slope problems. keep it up, I'd like to see more of this truly. Oh, and don't shy away from showing things that's not in the demo, it'd make more people want the full game. o(^ v
The way i would go is making a single PoligonCollider and animating the properties disabled and `poligon` (which is a PackedVector2Array).
Since this Node doesnt use a resource you can freely modify and keyframe the shape and even count of vertexes of the polygons and it would not affect other instances of the same enemy.
Still would try to precent many enemies spaming animations of this kind all at the same time. Is also important to set playing the animation in physics process instead of process
Btw, one way to execute code from animation player is puttin a setter to a property and animating the property, if the script is a @tool script it will execute
you said in a couple of devlogs and in the kickstarter page that isadora's edge is "Inspired by games like Hollow Knight, Megaman X, and Castlevania" which when you explain yourself in devlogs is fine but on the kickstarter page it is kinda misleading because saying a game is inspired by hollow knight and castlevania gives people the idea of a metroidvania which your game isn't so i think to avoid misleading wording you should spell out the genre more clearly
Greenlighting comparisons on oneself and predecessors requires careful considerations. It's not just words. It's power words for expectations.
Art boxer by follow the fun on steam could be useful for making all that resolution stuff a bit easier
You gave Dahyun a voice and responded to you in the video you now legally have to make her a video mascot who occasionally pops in and talks shit about Isadora
This is a great suggestion, heh heh heh
How are you handling hitbox priority? Essentially which hitboxes hit when a hurtbox overlaps multiple hitboxes.
Can someone explain the dimensions to the key art and how that works?
Like the dimensions and layers and everything that he explained please!