I dunno if people remember my post about making a fighting game engine on the previous forum but that’s still a thing, and after years it’s slowly on the way to having a decent feature set.
Including a kinda janky but quite functional scripting language (here the stuff needed for a hadoken, upper left is the condition for getting into the right state, down left is the character state that throws it, right is the hadoken itself. The language for the quarter circle movement is probably familiar to mugen scripters):
EDIT: forgot to post it because that’s not the bit I’ve been working on recently but there’s a hitbox editor too, that you can trigger from inside training mode:
The rock-paper-scissors aspect of which moves hit what is a huge aspect of fighting game balance, and entirely the result of the tetris game of collision interactions, and so as moves are balanced you may need collision geometry to drift significantly from what it was in the first place. That means collisions might differ significantly from where the displayed character geometry is!
If you take that uppercut in my screeenshot, how safe that move is can be greatly controlled by the relative sizes of the red hitbox and its immediately surrounding hurtbox or even the directions in which they do or don’t overlap. If the hurtbox were smaller than the hitbox this would be a significantly safer move than it is now and it’d affect the feel of the move and game (the stereotype goes that capcom hitboxes are usually like the one displayed here while SNK hitboxes tend to extend beyond hurtboxes for example).
The extreme example would be dragon punches, where the upper half or even all of your character may be devoid of hurtboxes for a couple frames because it’s an anti-air move. A more discreet example would be how having your reel animations use the same hitboxes as your idle pose will make combos more consistent and thus easier to learn.
This is something Capcom learned the hard way in the early SF4 days, where all kinds of balance and feel problems came to be because they thought having hitboxes be closely based on the animations would be a good thing. As new versions were made hitboxes came to be much more disconnected.
What’s more, because balance may be iterated on quite a bit, it’s a huge advantage to have collision authoring that doesn’t require an animator and can instead be entirely handled by a designer. With that dependency gone animations and collisions can be worked on and touched up without affecting each other. In some production structures where animations are outsourced to another team this might even be critical because you may not have access to an animator at all when balancing moves.
That isn’t to say the initial collision geometry will never be generated from animations in the beginning, though. It’s just that it may drift significantly as things are iterated on.
In that context 2d hitboxes are pretty much the easiest to author and visualize, too, as anyone who’s ever dragged a selection box knows how they work, plus you can study and directly apply collision design patterns from older fighting games.
On top of that they’re also super cheap computationally which might come in handy if you need your main update loop to be super fast (for rollbacks for example).
Animation principles (bounce and stretch) and tunneling (physics objects not registering collisions when moved too quickly) are also good reasons to move colliders by hand.
Riffing real heavy on Capcom’s Little Mermaid NES game, which I’ve kind of always wanted to do. The game will absolutely not be called “Mermaid Souls,” but I needed a placeholder and it was the least embarrassing one I came up with (still pretty embarrassing though).
After the debate about SFV’s netcode in recent weeks I decided to take the plunge and add online versus to my fighting game engine. Right now it’s delay based (although adding rollbacks is definitely planned) and has mostly been tested in low ping conditions (localhost as pictured here or my two PCs through a mere tiny hop over the net) but I’m really happy with how well it works so far (as I had at least taken care to make the whole thing deterministic from the get go, which had already payed off with replays).
I can’t wait to see my hopes crushed by testing it in a less ideal environment.
It’s got a number of perks (adding rollback (there’s rollback now!) is nowhere as tricky as it’d have been with a ready made engine, I suspect) but also a number of cons, like how right now there’s only three computers in the world I know it runs on for sure, so there’ll be lots of surprises once I reach my desired feature set (the sound system’s full of holes) and release a demo. That being said the main purpose of that hobby project is more for me to learn about how things work in games I like, which also explains why it’s not progressing as fast as it could.
I spent quite a bit of time jumping around in various games to figure out how cameras works, but more visibly just added support for stage models. I’m gonna need some other model soon though or at least a less agressive placeholder texture because this one is giving me headaches.
it doesn’t feel like an appropriate time to be posting dev screenshots to twitter like i normally would, so here is a dump from my latest – extremely orange – level.
