Adapting a New System to the Old Way

While working on a project, I was tasked with implementing Unity's new input system into our game. Our game is a top down strategy game with low player input, so I was only remapping a few of the inputs. We were mainly doing it to be able to implement key rebinding in a future update for the players to be able to remap their own inputs.

When refactoring self contained code like this, I wasn't expecting a super huge challenge. All of the main buttons went off without a hitch, but there was one method that was being used that didn't have a counterpart in Unity's new input system. GetKeyUp(). This very quickly turned into one of my largest problems in the project. I couldn't fathom the refactoring I would have to do to get this to work. The hardest part was that GetKeyUp() was built pretty deeply into our algorithm. I had to find a way to get the same functionality without using GetKeyUp().

I started by looking at the documentation for GetKeyUp() and seeing what it did. It said that it returned true during the frame the user released the key. This was a good start, but I needed to know more. I started by looking at the documentation for the Input System. I found that there was a method called InputAction.Get(). This method returned a float, which was the value of the input. I could use this to check if the key was pressed or not. I could also subscribe the button to the .performed event that supposedly ran whenever the key is released. This ended up not really going anywhere, and I quickly repeatedly found myself back at this same square one where nothing was really fixed, and I had put in a lot of effort with almost no reward. Something had to change.

That's when I had this epiphany, Why keep doing things the the new way? The old way was fine. That's when I found out the solution to my problem was not to rebuild the logic for player input, but to leave it the same and recreate any methods I couldn't use. I went back to my research and realized I could just remake the GetKeyUp() method. I achieved this by keeping track of the last frame a button was pressed and then returning true if the button is no long being pressed the next frame.

Was this solution the most elegant? No. Was it the most efficient? No. But it worked. And that's what matters. I was able to get the job done, and I was able to do it in a way that was easy to understand and easy to implement. I was able to deliver progress to my team and advance our project quicker and in a way that still improves the overall code health of our project, but still wasn't too difficult to fix in the end.