Devlog #9
I've emboldened and titled paragraphs for easy skimming. Feel free to skip whatever you want ofc.
Over the past two months here are most of my commits for those interested. They don't go into detail.
__
Reason for Inactivity
The devlog wasn't active because, as you can see by the commit dates, I wasn't programming a whole lot. That and because it seems like only a few are interested in the devlog hehe. Despite that, I'm gonna try to keep this going.
Overall Info
I am currently working towards a new build for the team to see. I'm going to implement a few more things before I do so though, like articles(weapon props, like FLUDD for Mario or Bowser's Flame breath), hurt/flinch/launched hardcoded actions + bouncing off the level, defensive bubble shield, and the Brawling collision resolver thing (applies collision bubbles -> offensive,defensive, hurtboxes).
Articles
Articles are basically normal objects with "Moveset" data (Actions, Subactions + arbritrary data) but with a parent/child relationship between another object. The parent has access to all the properties of the article and vice versa right now. The parent can set Actions (change/force action) for the articles which is key. I'll try to show some GIF examples on this in a later devlog.
Attaching Articles
Articles sometimes have to be attached to the character. I just started working on this. The aim is for an article root bone to be binded to an arbitrary bone of the parent. This should be pretty easy and fast to do so expect to see an example soon.
Getting Hurt, Flinching, Launched
I've never coded any of the three above so at first I was unsure how to go about it. That's why it's taken so long to get to them. They're going to be hardcoded actions and subactions. We're aiming for a smash bros type of hurt response. More info on this later.
Collision Resolver
In order for me to work on correctly implement hut/flinch/launch states, I need a way of getting to that state. At first, offensive collision resolution was simple because the engine wasn't far enough in development. The only thing it did was tell the victim he was hit and the attacker that he hit something. I was going to leave all that code in the system and single class. However, that means, I have to also encode cases for when the target is even hittable, launchable (large bosses shouldn't be), and all collision pair cases (catch, throw, offensive->defensive, offensive->hurtbox). That didn't sound good to me at all. So, as it is right now, at the core, the brawler engine just handles adding, checking and parsing collisions (this might be delegated to a higher level, or just abstracted in a way that is less game specific but it's not required so w/e). It then delegates resolution to another system. The new system can be created at a higher level to be more game specific. Bosses will be added to a system that may just apply damage. Brawlers would be added to a system that applies damage, knockback and collision effects. Normal objects, like blocks that only need to respond to the fact that it got hit don't really need to be in a system. They can listen to that specific event through the necessary data.
Programming Misc
I try to keep things separated enough without much redundancy. Throughout this project, delegating things out for higher levels to figure out has seems to be powerful. At the lower level, some info is unknown and cannot be implicitly implied. At the higher levels, things are more known, arbitrarily implied and self-imposed so that shortcuts can be made. With that mindset, making the game has been relatively easier than anything I've done before. It's still hardwork, but there hasn't been a problem I couldn't figure out yet. That issue with passframing walking + shooting for mit is easily resolved through the use of articles. Mit can be split into a lower body walking animation and the upper body shooting animation. The upper body will be represented as an article which I can control. That simple and no need for passframing at all- which was a terrible misuse anyways.
Misc 2
It's taken me about 6 months to make this fighting engine. I don't think anything else will be as complicated and long-term. After implementing the above, I feel that the Fighting system will be solid and I can finally move on to other things. Hopefully, that means that more interesting stuff can be shown and done soon. I can start to work on actually game content and tools too. The only other thing I think would take a long time on the coding side is networking, which I've never done. But that's pretty much the last thing on the list so that game should be nearly done by the time I start working on that. If networking fails, then hehe I dunno.
TL;DR Read Overall Info to get a quick summary.
I've emboldened and titled paragraphs for easy skimming. Feel free to skip whatever you want ofc.
Over the past two months here are most of my commits for those interested. They don't go into detail.
__
![[+]](images/collapse_collapsed.png "[+]")
SpoilerReason for Inactivity
The devlog wasn't active because, as you can see by the commit dates, I wasn't programming a whole lot. That and because it seems like only a few are interested in the devlog hehe. Despite that, I'm gonna try to keep this going.
Overall Info
I am currently working towards a new build for the team to see. I'm going to implement a few more things before I do so though, like articles(weapon props, like FLUDD for Mario or Bowser's Flame breath), hurt/flinch/launched hardcoded actions + bouncing off the level, defensive bubble shield, and the Brawling collision resolver thing (applies collision bubbles -> offensive,defensive, hurtboxes).
Articles
Articles are basically normal objects with "Moveset" data (Actions, Subactions + arbritrary data) but with a parent/child relationship between another object. The parent has access to all the properties of the article and vice versa right now. The parent can set Actions (change/force action) for the articles which is key. I'll try to show some GIF examples on this in a later devlog.
Attaching Articles
Articles sometimes have to be attached to the character. I just started working on this. The aim is for an article root bone to be binded to an arbitrary bone of the parent. This should be pretty easy and fast to do so expect to see an example soon.
Getting Hurt, Flinching, Launched
I've never coded any of the three above so at first I was unsure how to go about it. That's why it's taken so long to get to them. They're going to be hardcoded actions and subactions. We're aiming for a smash bros type of hurt response. More info on this later.
Collision Resolver
In order for me to work on correctly implement hut/flinch/launch states, I need a way of getting to that state. At first, offensive collision resolution was simple because the engine wasn't far enough in development. The only thing it did was tell the victim he was hit and the attacker that he hit something. I was going to leave all that code in the system and single class. However, that means, I have to also encode cases for when the target is even hittable, launchable (large bosses shouldn't be), and all collision pair cases (catch, throw, offensive->defensive, offensive->hurtbox). That didn't sound good to me at all. So, as it is right now, at the core, the brawler engine just handles adding, checking and parsing collisions (this might be delegated to a higher level, or just abstracted in a way that is less game specific but it's not required so w/e). It then delegates resolution to another system. The new system can be created at a higher level to be more game specific. Bosses will be added to a system that may just apply damage. Brawlers would be added to a system that applies damage, knockback and collision effects. Normal objects, like blocks that only need to respond to the fact that it got hit don't really need to be in a system. They can listen to that specific event through the necessary data.
Programming Misc
I try to keep things separated enough without much redundancy. Throughout this project, delegating things out for higher levels to figure out has seems to be powerful. At the lower level, some info is unknown and cannot be implicitly implied. At the higher levels, things are more known, arbitrarily implied and self-imposed so that shortcuts can be made. With that mindset, making the game has been relatively easier than anything I've done before. It's still hardwork, but there hasn't been a problem I couldn't figure out yet. That issue with passframing walking + shooting for mit is easily resolved through the use of articles. Mit can be split into a lower body walking animation and the upper body shooting animation. The upper body will be represented as an article which I can control. That simple and no need for passframing at all- which was a terrible misuse anyways.
Misc 2
It's taken me about 6 months to make this fighting engine. I don't think anything else will be as complicated and long-term. After implementing the above, I feel that the Fighting system will be solid and I can finally move on to other things. Hopefully, that means that more interesting stuff can be shown and done soon. I can start to work on actually game content and tools too. The only other thing I think would take a long time on the coding side is networking, which I've never done. But that's pretty much the last thing on the list so that game should be nearly done by the time I start working on that. If networking fails, then hehe I dunno.
TL;DR Read Overall Info to get a quick summary.
![[Image: QUmE6.gif]](http://i.imgur.com/QUmE6.gif)