Jump buffering with New Unity Input system

Kurt-Dekker · October 19, 2023, 3:22pm

Absolutely NOTHING about coyote jumping or any of your game logic should care where the input comes from.

Separating input concerns from game logic concerns:

make variables to represent possible player input intent

Each frame:

gather input:
→ clear those intents
→ load input into those variables from input sources <---- this is the ONLY part that cares where the input comes from
process input from those variables: (note how NONE of this cares where the input came from)
→ movement
→ jumping (regular, coyote, whatever)
→ shoot bullets?
→ change weapons?
→ other???

All games should use this approach. Unfortunately far too many tutorials commingle the input and the processing, making it very hard to retrofit other input sources.

Here is an example of the above:

github.com

kurtdekker/proximity_buttons/blob/master/proximity_buttons/Assets/DemoCoyoteTimeJumping/DemoCoyoteTimeJumping.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.UI;

// from this forum post, just curious about this coyote jump stuff and acme anvils.
// https://forum.unity.com/threads/coyote-time-variable-height-jump-with-touch-controls.1192519/
//
// NOTE: you need to make and set what you consider "Ground layer"
//
// NOTE: you should probably turn down Default Contact Offset in Physics2D setup
//

public partial class DemoCoyoteTimeJumping : MonoBehaviour
{
	[Tooltip( "Lateral walk speed.")]
	public float LateralSpeed = 5.0f;
	[Tooltip( "Lateral walk acceleration.")]
	public float LateralAcceleration = 20.0f;

This file has been truncated. show original

Look for functions called UpdateGatherInputs() and those beginning with Process*

Full source at:

proximity_buttons is presently hosted at these locations:

https://bitbucket.org/kurtdekker/proximity_buttons

https://github.com/kurtdekker/proximity_buttons