Welcome to another exciting devlog. This time we’re going to talk about input, how I completely borked it the first time and how I rectified my early mistakes.

Let’s take a trip back in time to when I was just starting what would eventually become Gun Soul and I knew I’d need a player object to run around and respond to input so I just made it use keyboard controls. Nice and easy! Then I added a menu object and that needed to respond to the keyboard too. Ok, no problem. Then I wanted gamepad controls too. At some point I made the lobby screen where you choose player characters...from another menu list. Uh oh. And then I added a qwerty keyboard object for creating new character’s names. And I had to track which player was using which input device which would mean reading different data and using it in different ways using different functions. Things were getting complicated!

Now, you might remember from my last devlog that the Amazon FireTv was one of my chosen platforms and it comes with a FireTv Remote controller. This awkward device registers as a gamepad but triggers keyboard events when you press the buttons. So I have to go and amend my code to cater for this hiccup...and I have to do it in all these different places.

The final straw was when I found that some generic bluetooth gamepads don’t have proper layouts setup and I needed to allow the player to rebind buttons. At this point it all went haywire and I may have passed out!

So I had to tidy up and organise my spaghetti code. I had to bring it to heel! But how?

As luck would have it, at about this time, the Gamemaker blog had recently published an entry about exactly this problem: https://www.yoyogames.com/en/blog/buttery-smooth-tech-inputs

It was exactly what I needed and I set about implementing its ideas and modifying them somewhat to allow features that I needed, like the re-bindable buttons.

In this new model there is one object that handles all input. It recognises new gamepads that are attached, it configures different sets of keyboard keys (that I’ve called keysets), it reads their states and it organises which inputs are allocated to which players. It even allows rebinding of buttons - It’s all singing, all dancing and I love it! And as it manages all input it seemed only right to call it the InputManager object.

No other object type needs to even know about the existence of gamepads and keysets and things. They just need to query the InputManager to ask questions like “has my jump action been triggered?” or “has my fire action been triggered?”. They do this using some public functions which will then return a yes/no answer or whatever data is required.

Using this new centralised set of input code means I only need to make any future changes in one place. And I’ll no longer wake up screaming in the middle of the night with my wife asking if it’s the Vietnam flashbacks again only to confuse her when I reply it’s about Amazon FireTv remotes.

If anyone is interested to see the InputManager then post a comment below and I’ll upload a link to the GML object code for your perusal.

Thanks for reading and I’ll see you in the next one.