Hello again, fellow gamedev! We already had some talk about controls, specially on how they can affect and benefit mechanics reuse. Today I want to complete some of the ideas that were left open and also talk about the important elements to consider when designing a controls system.
The Main Idea
If you are wondering why should you care so much about the controls in your game, why don’t we just give the player something arbitrary and ask them to suck it up and use them as we thought was fine, it’s because bad controllers set up can be the only physical and tangible barrier between your great game and the player. If your controls don’t feel right, your player will probably chose not to play your game again or is going to be pulled out of the experience every time his fingers hurt or he forgets where was the key for the action he wants to perform.
Something that a lot of people (including me) didn’t like about Flinthook was the lack of controls customization. You need to learn to play with the keys they set. The only problem is that these keys aren’t very intuitive or comfortable. According to some steam reviews, they later added an additional “pro” controller set up which feels a lot better (I bought the game when that update was live, thank God) but it still can’t be modified. Another example is Super Meat Boy. It’s funny that it constantly claims that “Controller wins vs. Keyboard” when the keyboard is set in a very uncomfortable way and can’t be changed in-game.
Engine Limitations (?)
I’m not an Unreal Engine super experienced dev but making Foreigners’ prototype (using Blueprints) on UE4 showed me that it’s way more complicated to allow controllers customization than it has been in Unity for Office Chair Death Match. Maybe now things have changed, hopefully.
Our design choice in Unity was based on controller profiles. Each profile is essentially a named set of bindings for the game buttons and they can be on whatever device you want (you could even combine devices). The profiles can be created in the settings menu, but to avoid making players return to it too frequently, we let them select or create the profile when the new game is being created.
Just a validation of overlapping keys was added and that’s it!
This is kind of an obvious advice, but just incase: if you want your game to have any kind of local multiplayer (split screen), controllers customization is a feature you can’t avoid IMO.
As I mentioned on the last post, something I do is imagine the controllers before implementing the functionality, which basically means to carefully plan the set of buttons that your player will be using in different scenarios, looking for simplicity, coherence and comfort.
Now, if your game is going to have different control modes—lets say, walking controls and spaceship controls—then try to keep the similar functions in the same buttons: forward, steering, fire, etc . This is a lot more challenging when you’re creating two control modes that use a completely different set of buttons because one is more complex than the other. That’s exactly why I mentioned spaceships, which usually require at least twice the buttons than walking does because they are (depending on your implementation) complex to move. Same as submarines or any other vehicle that freely moves in X, Y and Z.
The questions in this cases are: how much adjustment your player requires to switch between modes: does he needs to change the position of his hands? Is a functionality of a mode set to a different key in the other mode? Testing your controls frequently will help you to keep your game on the right path, especially if your game is going to have complex control modes.
It’s always a great idea to have a couple of friends—not directly involved in the project if possible—to test your controls system: how it feels and how intuitive it is.
Especially in early development, your testers might throw some unexpected results at you that you need to read properly. I tested Foreigners’ prototype with 5 friends. They loved the feeling of the spaceship and how different it was from other games. However…asking the right questions revealed that none of them was able to finish the first circuit (ultra easy, for me of course). I knew it was something new and different…but having 5/5 with the same results and after 2 game sessions was definitely a warning.
For Office Chair Death Match happened something similar. The feedback about the movement feeling was good but the difficulty was high. After a second game session, the perception changed drastically. They completed some laps, fought each other and more importantly, they had fun. At that moment I had a single test level of medium difficulty with all of the mechanics available since the beginning. It was honestly a bit overwhelming for them. It was a reminder of how important the progression is not only in the mechanics but in level design and controls implementation.
I’m not a big fan of them but tutorials can be useful when your controls are complex since the beginning of the game, like if your game is only about flying a spaceship. You will, of course, add difficulty as the game advances through level design but the basic functionality—something like “combine the thrusters to turn the ship”—must be taught. More advanced mechanics probably won’t need the tutorial, like when you attach your first weapon once you know how to move.
Hopefully these ideas will help you to design the best controls for your game and your players. Just remember that easy for you (the dev) is not easy for the newcomers. Speaking of which, next post will be about Difficulty!