Another month, another update. I meant to do this update earlier, but I kept putting it off until I could finally say that teching is 100% done. This ended up being a much more difficult process than I ever thought, but now it is completely done!
Before I dive into the explanation on why this took so long, here’s a list of some of the stuff I’ve done in the last month or two.
- Competed at another entrepreneurship pitch competition. I didn’t win, but the competition got me to sit down and really figure out some important business stuff, which I’m really grateful for. Stuff like realistic estimates of costs, timeline to completion, honestly looking beyond what happens if this game succeeds on Kickstarter and then again if it succeeds on Steam, etc. I got asked a lot of hard questions, and I’m happy to say I now feel good about my answers.
- Again, grounded teching (and grounded missed teching) is done. Here’s what grounded teching looks like, and as a bonus here’s a funny bug that came up when I was implementing tech rolling. Wait for it, it’ll be obvious. This was surprisingly hard to figure out how to fix, and took me a few days.
- Did a LOT of work getting bounced teching/missed teching working correctly, and generally made bouncing around the game look and feel better. Here’s a quick example.
- I added rotation changes during hitstun depending on knockback. Here’s an example of what I mean.
The biggest reason this was so tough was because of the way collision detection is handled in UE4. If you’ve kept up with this blog you might remember one of the early posts I made about how jumping into corners or sloped walls often made you bounce off in erratic ways. I’ve learned to expect trouble now pretty much any time collision detection is involved in a feature.
So first off, what is collision detection? If you want a character to not fall through the floor or be unable to walk through walls, you have to tell the game to make it impossible. In UE4 there are basically two types of collision detection: Hit collision and overlap collision. With hit collision, this fires off an event any time two objects touch each other. If you have hit collision turned on for both objects, the game will always try to keep them from overlapping. Overlapping collision is the opposite. In this case the game fires off an event whenever two objects overlap. For example, if you want the character to swim whenever he falls in water, you could use an overlap event for that.
As a refresher, almost all of the collision detection for the character is done with with this capsule pictured above. Whenever you walk or run into a wall, the game is actually only checking with this (normally) invisible capsule. Something I didn’t mention before is that this capsule can only use hit collision.
The information you get for overlapping and hit collision is somewhat different. With hit collision you get to find out exactly where a hit occurred, with what, what the normal angle was, and a handful of other nice things. One thing you notably cannot do is find out when you stop touching whatever you hit.
With overlap collision you don’t get nearly as much information about the thing you overlapped with, but you do get to find out exactly when the overlap ends.
The reason I say all this is that a problem kept coming up that took me 2 or 3 weeks to really chew through. Normally the way the code for teching works is that if you’re in hitstun and you hit a wall (hit collision), then it bounces you off of that wall based on the wall’s angle, your knockback, and some other information. What happens, then, if you are already touching a wall (or the floor) and you get hit into it? The game doesn’t register a hit event because you technically already hit it earlier, so you just end up gliding along the wall, not really going anywhere.
The very short version of how I fixed this is by creating a second capsule, very slightly bigger, that uses overlap collision. A careful combination of both collision data helps me to store information about any wall or floor you’re touching, just in case you get hit into it. This were a lot of fringe cases that took some serious work to get functional, such as if you walk over two different types of land (sloped or not) or if you’re touching a floor and wall at the same time.
Anyway, next up is polishing the movement during tech rolls as well as some of the animations. Afterwards is getting the falling state finished (easy, already mostly done), and then it’s onwards to blocking!