Thanks for the feedback!!

And ah, I love the topic of input delay, so excuse me for going on a bit of a rant:

Super Smash TV was actually the primary game I looked at to see how 4-way shooting could be implemented.

One issue I had with Smash TV was that when you shoot diagonally, so pressing say both X and A, the first bullet will either go straight up or to the right instead of going diagonal, since your thumb won’t press both buttons at exactly the same time. With Smash TV that’s ok because you can just rain lots of bullets one after the other.

For a versus game like Unarmed, I found out that doesn’t work so well, because if you saturate the level with bullets, players can’t react anymore, and the game won’t be fun.

So I figured I needed to limit the amount of bullets by rate limiting. But if you do that, you want every bullet to go the way the player intended to. For this I implemented a slight delay between the first time a press is registered and actually firing the bullet so that the other button can catch up before we decide on in what direction to shoot. I set this variable to 2 frames, but after looking at the code again, it turns out this mechanism adds 3 frames of lag. So 50 miliseconds. I just checked this in the debugger, which can step through individual frames, and I can confirm that it is indeed exactly 3 frames.

For comparison 50ms is generally within the accepted range of online lag for an FPS or fighting game. I can try to experiment with less, or even make it a configurable option. I’m probably less prone to notice the lag as my reaction times aren’t great to begin with. But I can believe that 3 frames might be noticeable.

Another reason for the lag could just be that you’re using an emulator. This bit me a couple of times, while developing the game, where it turned out my OS was introducing quite a bit of lag, or worse when my bluetooth headset was introducing a loooot of lag between game and game sound. Testing on HW made that go away. But I’m guessing you noticed that the lag wasn’t there when jumping for example.

As for button layout, I guess you mean ‘shoulder button to jump’ instead of ‘shoulder button to shoot’: yea I already abstracted the code to allow for different input methods. But there was just so much to improve and I had so little time to come up with an interface. I did do some play testing with some people, and I was a bit surprised myself that they didn’t seem to bothered by the mapping of jump to R. Even after I prodded them on it. So that also meant that the feature tumbled down a bit on the list of priorities. Although I wouldn’t have time regardless I think.

But your feedback has put it back on the map :) And yea, mapping to up might be a good solution.