Porting to AirConsole: Making 10 fps input work
In today’s blog I will describe the techniques that we used to make Basher Beatdown, a fast paced game, work with 10 fps. A lot of info will be about the way we handle data on the controller itself but in the end we will also go over some gameplay changes that were made.
1. Optimizing data send
Sending data every 100ms (10fps)
Because we make use of a joystick, which is permanently used by the user and feels the worst if it doesn’t work properly, the most sensible thing to do at first is sending the input with the max fps allowed. The big problem here is that especially when a button is pressed the player can feel this delay.
Pros
- Fastest possible stable input
Cons
- Buttons aren’t responsive
- Joystick data no equal to data when button was pressed
| Min fps | Max fps | Worst delay | Best delay | |
|---|---|---|---|---|
| Button press | 100ms | 100ms | ||
| Joystick change | 10 | 10 | 100ms | 100ms |
| Quick joystick change | 100ms | 100ms |
Sending data every 125ms (8fps) and send 2 buttons/sec immediately
Because having to wait 100ms + send delay + 1 frame before the game notices that you pressed jump doesn’t really feel good, we changed the fps of the joystick to 8 so we had 2 fps to send a button when it’s pressed. Of course we also send the joystick data with the button data.
Pros
- Button input is now as fast as possible
- Joystick data equal to data when button was pressed
Cons
- Joystick becomes less responsive
| Min fps | Max fps | Worst delay | Best delay | |
|---|---|---|---|---|
| Button press | 0 | 2 | 1ms | 1ms |
| Joystick change | 8 | 8 | 125ms | 125ms |
| Quick joystick change | 125ms | 125ms |
Reset joystick timer when button send
With the previous rules the following could happen; 124ms after the last data was send we press a button after which the joystick and button data get send. Then 1ms later it’s been 125ms since the last joystick data was send so it gets send again. Since that isn’t needed we can optimize the data send by resetting the last send timer for the joystick
Pros
- Button input is now as fast as possible
- Joystick data equal to data when button was pressed
- Possible room for extra button when joystick fps is saved by resetting timer
Cons
- Joystick not responsive
| Min fps | Max fps | Worst delay | Best delay | |
|---|---|---|---|---|
| Button press | 0 | 2 + joystick send saved | 1ms | 1ms |
| Joystick change | 8 – saved by button send | 8 | 125ms | 125ms |
| Quick joystick change | 125ms | 125ms |
Only send data when direction angle difference > X
When playing I noticed that in general a user doesn’t change the joystick all the time but quite often has the joystick pointed in the same direction for a while. By making sure that we don’t send (almost) identical data we can save 1 or 2 sending every second. (which leaves more room for buttons)
Pros
- Button input is now as fast as possible
- Joystick data equal to data when button was pressed
- Possible room for extra button when joystick fps is saved by resetting timer
- Possible room for extra button when joystick fps is saved by not sending duplicate data
Cons
- Joystick not responsive
| Min fps | Max fps | Worst delay | Best delay | |
|---|---|---|---|---|
| Button press | 0 | 2 + joystick send saved | 1ms | 1ms |
| Joystick change | 8 – saved by button send – saved by duplicate data | 8 | 125ms | 125ms |
| Quick joystick change | 125ms | 125ms |
Don’t reset the last send timer when the data isn’t send because the angle was lower than X degree
The biggest problem that we currently have is that the joystick still has a fastest response time of 125ms (except when send with a button). We can lower the ‘best delay’ of the joystick to 1ms if we don’t reset the last send timer but instead just keep waiting when the angle difference between the last set angle is > X.
Pros
- Button input is now as fast as possible
- Joystick data equal to data when button was pressed
- Possible room for extra button when joystick fps is saved by resetting timer
- Possible room for extra button when joystick fps is saved by not sending duplicate data
- Certain cases where the joystick input becomes more responsive
Cons
- Joystick not responsive
| Min fps | Max fps | Worst delay | Best delay | |
|---|---|---|---|---|
| Button press | 0 | 2 + joystick send saved | 1ms | 1ms |
| Joystick change | 8 – saved by button send – saved by duplicate data | 8 | 125ms | 1ms |
| Quick joystick change | 125ms | 1ms |
Immediately send data when big angle change is detected
When playing the game with the previous rules feels much better than what we started with but there is still something that we must improve to make the game feel as good as we can; When doing a big change in direction it’s most notable that there’s a delay in what direction the character is going, since the delay can still be 124ms + delay + 1fps worst case. In order to fix this we handle the joystick input the same as a button when a big change in direction is detected.
Pros
- Button input is now as fast as possible
- Joystick data equal to data when button was pressed
- Possible room for extra button when joystick fps is saved by resetting timer
- Possible room for extra button when joystick fps is saved by not sending duplicate data
- Certain cases where the joystick input becomes more responsive
- Quick direction changes are send immediately
Cons
- Still not truely 60fps?
| Min fps | Max fps | Worst delay | Best delay | |
|---|---|---|---|---|
| Button press | 0 | 2 + joystick send saved | 1ms | 1ms |
| Joystick change | 8 – saved by button send – saved by duplicate data | 8 | 125ms | 1ms |
| Quick joystick change | 1ms | 1ms |
2. Adjusting gameplay
Dealing with input delay
When playing the game it became apparent that navigating through the levels was quite hard because of the input delay, most notably it caused the players to just walk of platforms instead of jumping off the end. The fact that a virtual joystick isn’t as accurate as a normal joystick also made it much harder to navigate through the levels, especially because it would happen quite often that we would just hit the end of a platform when dashing.
Fixing the jump
In order to fix the jump we implemented some techniques described in this excelent blog by Yoann Pignole on Gamasutra. Most notable the “remember to jump” and the “still jump after drop” fixed the problems that we had.
Fixing the dash
In order to fix the dash we implemented Aim help in the game. When the user performs a dash we do a raycast in that direction, if the player is about to dash into a wall/platform but this can be prevented by a couple of degree that’s the direction the player jumps.
Redesigning the levels
Even with the jump and dash help it was still quite hard to navigate through the original Basher Beatdown levels (which were designed for the PC version with controllers. We decided to create special levels for AirConsole that included easier gameplay and that were easier to navigate by making bigger platforms and leaving bigger gaps between them. You can see the difference clearly in the below level comparison:
The original level
The AirConsole version