Refactor game input to use Unity's new Input System package

[nucleartide]

JIRA Ticket

Sorry folks, this is internal to my Notion workspace!

https://www.notion.so/nucleartide/Refactor-using-Input-System-package-87c54792efb846149bfebe389b9ff9de?pvs=4

Changelog

Provide a bulleted list of changes that were made in this pull request.

• Install and enable new Input System package
• Create PlayerInputActions asset
• Create GameInput MonoBehaviour for encapsulating player input
• Update PlayerController and PlayerShoulderTarget to rely on GameInput values
• Move some URP assets into Settings/ for tidiness
• Add support for keyboard and mouse, as well as gamepad (Xbox controller)

How it works

Explain what you did, how you did it, and why you did it. Also any lessons that might be useful to others.

There's an opportunity cost between learning the new Input System, and moving onto bigger and greater things (like coding the meat of the game's gameplay systems), but I wanted to do things the 2023 way in Unity.

So I spent the last day learning Unity's new Input System package. While there are many online that complain about how complex it is to use, I thought it clicked pretty quickly.

The issue with Unity tutorials is that you need to find the good stuff amidst all the well-intentioned (but non-ideal) YouTube tutorials out there. After some false starts, I found an official Unite Copenhagen talk from Unity to be the best resource for learning the Input System's why and how:

The Input System 1.5.0 documentation is also far better than previous versions, and simply reading the first few paragraphs of each page gives you a good bird's eye view of the package’s capabilities, leaving the details of UI/API properties for later reading if needed.

If I had to summarize Input System's primary benefits, they'd be:

1. Abstraction over inputs. Instead of the old way of one controller input per axis (for instance, Input.GetAxis(“HorizontalKeyboard”) and Input.GetAxis(“HorizontalJoystick”)), Input System adds a layer of abstraction called “actions”, and you “bind” inputs to these actions at editor time and runtime.
   1. This has one really cool benefit: it’s a no-brainer to hook up a wireless Xbox controller to your Mac, and see your game being played with an actual controller. Woah.
2. Programming model. You don't poll input in Update(); instead, you attach inputs to EventHandlers in C#. This is awesome; C# events serve as a great communication mechanism between MonoBehaviours and ScriptableObjects.
3. Type safety. I love how this package doesn’t depend on hard-coded strings; there's a Generate C# Code button that generates a C# class from your PlayerInputActions asset, so that you can reference action names as C# properties. If you make a typo, the compiler complains so you can fix your bug early.
4. Slick action editor. Once you get the hang of the Action editor, you'll love how easy it is to bind different inputs to game actions. The grouping of “action maps” and “control schemes” allows you to selectively enable or disable groups of controls whenever you wish.
   
   
5. Open source. The code is open source on GitHub, and you can easily submit upstream PRs to get things fixed faster.

But more than anything, it's just really cool to see your game played with an Xbox controller. 😄

Highly recommend migrating over. Watch the Unite Copenhagen talk to get started, then jump right in for one of your Unity projects.

Quality Assurance

Take some screenshots as confirmation of quality assurance.

Look Mom, Dad — I'm making games! 😁