Be the Controller, not the Puppet.
The attentive among you will have noticed us talking about gamepads and controller builds recently. What is this dark magic you ask?! Well, essentially we’ve been busy getting the game to work with a controller. This is a pretty big deal for us, especially as it wasn’t something we were planning on doing until we had finished making the game. This blog is going to look at why that would have been a BAD idea and a proper indie NOOB mistake.
Firstly, let’s go back in time a little. Up until the end of last year, we were perfectly happy developing the game with mouse and keyboard controls. We liked it. Other people liked it, so we saw no reason to change. We also (stupidly) thought that adding controller functionality would be fairly trivial. However, once we started demoing at the start of this year, we realised we were talking about the possibility of bringing the game to console without being able to demonstrate a control setup to support it. ‘Quick’ we thought, let’s just add that into the build.
Cut to many hours work getting that implemented. Here are some of the things we didn’t think about, that we really should have.
1. Walking between cameras needs to have directional flow.
This basically means that if you’re walking to the right, don’t suddenly cut the camera and expect the player to walk upwards because they’ll still be pressing right. Most times this will end up with them walking into a wall. FAIL. This one is kind of obvious, but not when using a mouse. The act of clicking in front of the character is not something you can carry across a camera cut. Essentially you click before and after. This therefore gives the player enough time to get their bearings and avoid those pesky walls. Not so with controllers.
2. Interactions have to be physically accessible by the player.
In the mouse version we have a cursor. The cursor is clever and powerful and can explore the entire screen space without an effort. The cursor is all seeing. By contrast, the controller build uses the player vicinity as the cursor. The player is not clever and powerful. The player can only access things they can walk to. The player subsequently demands that all interactions be brought down to their level. In a nutshell this means rethinking the layout of things we want to the player to look at, so that they are all easily accessible. Adding too many of these things into a tight space (like drawers) also presents problems over which interaction to offer first. We found it was easier to just spread them out around the scene instead.
Adding an open interaction to the window is problematic due to all the boxes blocking Tove's ability to get to it.
3. Object pickups don’t need player repositioning.
In the world of the mouse, you could click on an object on the other side of the screen from the player. The game will then walk the player to the object and pick it up. Job done. In the controller world, the player has to walk over to the object to even be given the option to pick it up. When they do decide to grab it, they’re already next to it, so moving them into position isn’t necessary. Simple right? No, not if you haven’t set this up from the start to check what the control input is. Imagine having to go through the entire game from start to finish changing every pickup action. Not cool.
4. Your collision game needs to be tight yo!
With a cursor, players will click somewhere in the world. If they can’t move there, they’ll be no click marker effect and the character won’t move. It doesn’t feel odd and just works. End of discussion. With a controller, players will try and run anywhere, smashing into everything as they go. This all needs a pretty robust collision mesh that must block the player, but not trap them when they need to move to a point during a cutscene.
5. UI or die.
Your UI suddenly needs button prompts, which changes how your UI needs to look. Oh, and you’ll need different button prompts for different controllers. Plus the way you tutorialise it will be different. Good times :/
So what does this all mean? Well, now we build all of our scenes with this in mind, so that we are able to switch controls method at any point. We make design decisions where we don’t put interactions out of reach, or we don’t change the camera too harshly. We also implement all pickups and UI swaps as we go, so they are effectively now just part of the pipeline and don’t take any extra time. All of these things are pretty simple, BUT would have been a mountain of work to do at the end of the project.
Soooo if any of you out there are thinking about different control schemes for your game, our advice would be to do it early. We’ve done it more out of luck than judgement, but it’s only been through doing it that we realised how screwed we’d have been if we'd left it until later.
Cheers,
Tom & Alex