The Speed of a Keyboard, in Controller Form

As an indie developer I’ve been very fortunate to have my game, “Cook, Serve, Delicious!” do well enough for me that not only can I make games full time, but fund my next project as well. But I have also found it a valuable tool alongside Game Maker Studio in experimenting with different platforms, processes and experiences. So when YoYo Games asked if I would be interested in bringing CSD onto the PlayStation 4 as part of their demo at GDC in March, I readily accepted. But then came the obvious question: how was I going to convert a keyboard/typing based game onto a controller without dramatically changing the experience?

It was easy enough to come up with some visually good looking ideas, but in practice the experience made me so much more aware of the complex nature of controllers verses other forms of input.

Types of Controls

“Cook, Serve, Delicious!” is a game where you must quickly fill out food orders from customers and get them out the door perfectly satisfied. It is a difficult game if players strive for perfection- one small mis-typed letter, and their bonus for achieving the perfect day is gone. The keyboard is the perfect control input for this type of game- it provides not only the speed players need, but also the pin point accuracy.

There are two other control methods: mouse, which allows you to click the letters instead, and touch, which is obviously the mobile standard. While a mouse is similarly accurate, the speed is rapidly decreased by the movements the player has to make on the screen vs the keyboard. Touch works similarly, but with bigger buttons and much faster responses with the hand vs moving a mouse.

The original idea was to have a radial menu for ingredients, so that the player could rotate the joystick to the ingredient of their choice, press a button, and move on to the next ingredient. It seemed like an easy choice, as radial menus are very easy to navigate, easy to understand, and fast compared to, say, having a highlighted box moving up and down with the d-pad.

The original radial menu test for controllers.

In practice however, this did not work. No matter how much I practiced, in fact, it wasn’t working at all. I was not able to blast out the ingredients for foods in any kind of quick manner. It was slow, in a way that seemed impossible for me to improve on. Was this because I was so used to mouse/keyboard controls that it was too jarring to move into this kind of control scheme? Did I need more practice? With GDC coming up and the deadline for controller support coming in just a few days, there was no time to try and get accustomed to the controls. I had to figure out why this wasn’t working.

Input Response Times

To figure out whether or not the slow controller inputs were a result of a flawed design or my flaws as a gamer (I am a fairly average game player in terms of skill), I thought the best thing to do was figure out why keyboard, touch and mouse controls worked so well.

The three control inputs, which in the order of speed and accuracy would be keyboard, touch and mouse, had a basic line of steps that could be shortened upon playing the game and memorizing ingredient hot keys and recipes. I broke down the steps needed to input the first ingredient for each method:

Keyboard (3-4 steps): the player brings up the order by typing the number it is served under (1). The player then reads the recipe (2). If needed, the player refreshes themselves with the hot keys for the ingredients (3). If not, the player skips step 3 and goes straight to typing the letter that corresponds with the ingredient or action listed first (4).

Mouse/Touch (4 steps): the player brings up the order by tapping it on the left (1). The player then reads the recipe (2). The player then scans the ingredients on the right side of the screen to see which one needs to be tapped (3). Because it is a visual button that must be tapped, this step cannot be skipped. Once the player finds the ingredient, they tap it immediately (4).

Radial Menu 2.0

Controller (6 steps): the player scrolls to the corresponding order if it is not currently highlighted (1). Once reached, the player presses the button to bring up the order (2). The player then reads the recipe (3). The player then scans the ingredients to see how they’re displayed (4). The analog stick is rotated to the ingredient of their choice (5). Once highlighted, the player presses the button to dispense that ingredient (6). An additional step is needed if the player overshoots the ingredient with the analog stick and must do fine adjustments to highlight the appropriate ingredient.

Now that the player has their first ingredient on the food, let’s see the steps in placing more ingredients until the order is finished:

Keyboard: read the recipe again if needed (1), type the corresponding letter (2).

Mouse/Touch: read the recipe again if needed (1), tap the corresponding button (2).

Controller: read the recipe again if needed (1), move the analog stick to the appropriate ingredient (2), press the button to dispense ingredient (3), additional step may be needed if the analog stick needs to be adjusted to highlight the appropriate ingredient.

The controller always seems to have a few extra steps in its path to serving that ingredient. Breaking it down even further, you can start to understand just how far the controller was in bringing the kind of twitch game control needed for this type of game. If I read “tomatoes” on the recipe, I would instantly know to press T. Or for the mouse/touch controls, I would glance at the ingredients and my hand or mouse would already be moving to the exact location where I need to tap. For the controller, my brain would need to first know where I’m moving the analog stick (left or right), move it while making adjustments to the speed of how fast I’m getting to the desired ingredient (so I don’t overshoot it), and then once I have confirmed visually that the highlighted ingredient is what I want, press the button. In a game where speed and accuracy are crucial, the method of radial menus seemed like a complete opposite solution. It provided a good degree of accuracy, at the cost of severely impacting speed in a way that didn’t exist for any of the other control methods.

In practice, it felt less like putting meat on a burger yourself and more like guiding a robot with an RC controller to put the meat on the burger. The controller was getting in the way of the game, and I didn’t have a more elegant solution. Frustrated, I thought I would have to tone down the speed of the gameplay to accommodate controller support, which to me would be a complete failure of design. But with just a few days left, I didn’t have much of a choice.

Treating Controllers as Hotkeys

Livestreams and videos of my game have become an invaluable tool. I get to see the player’s frustrations, excitements and what they think of the game in an unfiltered form. One player loved the lasagna because it had one recipe that consisted of inputting PSCR three times. Every time the lasagna order came up, he chanted, “PSCRPSCRPSCR!”

That’s when it hit me: the control method I was using for controllers had no form of input like this. There was not a way to “blind” place ingredients. I needed both the visual guide on screen and the analog stick movement to help me place an ingredient. This is what was slowing down everything.

There are forms of “blind input” in this style for controllers, like codes and fighting game style controls. Everyone knew the button presses to get some Konami lives, or the sequence to pull off a fireball. This is what I needed. Imagine seeing a recipe and knowing how to pull it off like a Sub Zero freeze, maybe something like quarter-circle back, B, A, X. The inherent problem with that is the sheer number of recipes in the game- over 300 recipes, which was a crazy amount of memorization. And while the idea of inputting a fighting move to do a recipe sounded great, it didn’t feel much like cooking. It felt more like a minigame within a minigame of pressing the right buttons to make an order correctly. The challenge wasn’t reading the recipe anymore, it was pressing the right buttons in the right sequence, and the game lost a large amount of charm as a result. I had solved the speed problem, while removing the challenge of making a perfect recipe entirely, which is the essence of the entire game.

But, I was definitely closer. What if I could use the controller as a hot key system much like a keyboard? Stop using the controller as a way to visually control things on screen, but use it like a keyboard so that the player could press the A button for tomatoes, flick the stick for onions, and so forth? This seemed like a solid solution.

The controls were mapped right onto the original design layout for keyboard inputs.

Working with Limitations

With little time left, I knew I had to stick with some key components already built into the game. First, it would take too much time to re-organize the ingredients menu, so I had to leave them as they were. This meant I needed twelve points of control on the controller exclusively for placing ingredients (twelve being the maximum number of ingredients a food could display at one time, though by pressing a button the player can display another set of twelve ingredients if the food has it). 

At that time I was using an Xbox 360 controller for gameplay tests, and I realized that the d-pad was not going to be a practical option. It had a reputation for being shaky in making accurate inputs (and the test runs I did certainly proved that) and quite literally the only thing I could depend on it for would be two inputs- either left and right OR up and down. Those were inputs that I at least had the confidence of being 100% right every time. So I relegated that to highlighting the prep stations on the left side for selecting orders. I knew the Dualshock 4 didn’t have those d-pad issues, but the 360 controller would also be supported for the eventual PC/Mac/Linux patch and would likely be the majority input device on those platforms, so I had to lead with the 360 pad.

The first plan was to use the analog stick as an eight way input device: the four basic directions, plus the diagonals in between. This also didn’t work for accuracy, as if you’re not actually looking down at the controller, it’s incredibly hard to make a movement with the stick that is 100% correct. This is fine in, say, an FPS, where you only need to press the analog stick up, down, left or right, with little attention to diagonals, or even in overhead shooters where the player can move in 360 degree freedom, and the player can quickly adjust the stick if the character is moving slightly off to where they want to go.

The key difference with my game was, if the player wants to press up on the stick and they press the stick in a few degrees off from up so that it registers a diagonal, they have lost. It is literally over. All of their perfect hard work for the current in game day is for nothing, because that perfect combo score is now over. Every single form of input from the controller absolutely, positively must be 100% accurate or the game doesn’t work, period. There are no exceptions.

Analog sticks weren’t designed for this type of accuracy. It was not possible to depend on them for eight way inputs, so I had to go down to four. This lead to using the right stick as well, and because the ingredients were already listed in column form, I thought it would be perfect to split the analog sticks naturally as they were listed in the ingredients panel- the left side for the left stick, and the right side for the right stick. It was still hard to get the hang of inputting ingredients quickly, but I knew at this point it was my experience as a gamer and less a problem for the inputs, and sure enough after a few rounds I was making pizzas like crazy. But that’s when I came across a new problem- despite the analog sticks only having four possible inputs, I was still getting inaccurate orders.

The answer was adjusting the deadzone so that the game would register an ingredient when the stick passed a certain radius outside the non-input zone. The degrees of inaccuracy would lessen the further I pushed the stick out. The problem here was that the longer I took to push the stick, the more time it would take to push it elsewhere for other ingredients. I decided to take it to about 75% outside before registering it as an input.

In standard games, a slight press in a direction from the stick registers input. In CSD, the stick must be pressed nearly 100% in a direction before escaping the "deadzone" or area where input is not registered. The deadzone is massive in CSD, but in this type of game it works as the sticks are used only as input, and not as gauging the degrees of input, such as walking vs running, etc.

But then another problem emerged altogether. Analog sticks were made for traveling along the edge. If I’m pressing the stick up, and I want to go right, I slide the stick to the right without bring the stick back to the default position. Likewise, if I was pressing up and then went right, and suddenly realized to go left, a more natural response would be to slide the stick over the bottom position into the left, like a 180 degree rotation.

To do that in this game would mean the player would accidentally input an ingredient that wasn’t listed, resulting in the perfect combo being broken. Again, this was unacceptable, but this time it wasn’t the controller nor the player’s fault- it is how we’ve been taught to use the stick. I couldn’t tell the player not to do that. To do so would bring a whole new set of issues the player would have to run through their brains each time they want to input an ingredient. I had to solve this on my end, and the way I did that was locking out any form of input as soon as the controller registers a direction, and forcing the player to “reset” the stick before pressing another direction.

When the player extends the analog stick into the register area, the game locks in the UP command (1) and will not register any more analog stick inputs until the stick is guided back to the default center position (2).

This sounds unnatural, and at first that’s what it felt like, but over time you get used to the idea of “flicking” the stick for an ingredient instead of rotations, which actually improved input speed altogether.

But yet another problem came up. I wanted the player to have a similar experience with the lasagna and other foods that the keyboard controls gave them- instead of PSCR PSCR PSCR, the controller could allow three full rotations of the analog stick to input all the ingredients since there were four. But with this lockout method, that proved impossible. So I had a separate control scheme for lasagna that allowed for rotation of the sticks, since the game could predict exactly what the player needed to do with the controller to make a perfect order quickly.

The player can rapidly rotate the stick since the lock out feature of the analog stick has been removed from this type of food.

After GDC when I had more time to refine the controls for the Steam patch, I carried this form of input over to foods that had recipes which called for all ingredients. Those recipes essentially demand the player to mash all the buttons listed on screen, and for the analog stick it is highly likely the player would do a quick rotation to place all the ingredients. Again, I had to predict the player’s movements, and because accuracy for that recipe is out the window I temporarily switched the control input to the same as the lasagna, so that there wouldn’t be a need to “reset” the stick. It is extremely satisfying to place a ton of ingredients onto a food by rotating the stick like that, and I wish I had it in the build at GDC, but I’m glad it made it into the Steam version.

Rumble

Earlier in the month I had played a beta of Titanfall on the PC, even though I don’t use my PC much for AAA gaming. As I used a controller I was struck by the severe amount of rumble feedback I got for using a gun, something that I hadn’t quite felt before. It was intense and fantastic, and the only difference from most games was that the rumble motors felt like they were at max rumble.

That always stuck with me, because rumble itself is such a passive experience that there’s not much you can do these days that players would pay any attention to, but the TF beta inspired me. If that was the most powerful rumble the Xbox 360 could generate (and it certainly felt like it), what else can you do with rumble that would call attention to itself like that?

As I started to input the controller code into the game I took at a look at what Game Maker Studio could provide for rumble. As it turns out, I had independent control over two rumble motors (left and right), their strength, and the duration. That was plenty to make some interesting experiments.

My first idea was to have some strong “punches” and “jabs” in the form of rumble when the player cuts an ingredient, or tenderizes the chicken, etc. What I quickly found out was that the rumble motor itself took a half second or so to start spinning up, and a similar amount of time to power down. To do a quick jab was impossible given the lag between starting up the motor and powering down. So, I had to settle for standard vibrations for basic ingredients, which was a little disappointing.

When it came to the fryer where the player would dip the fries/sopapillas/chicken into the fryer for a length of time, I had an idea: spin both motors up but decrease and increase both motors independently so that one would be at 50% power with the other at a 100%, then as the power decreased on the right, the power would be gained on the left. This resulted in feedback that I haven’t quite felt before, almost as if the rumble is moving back and forth between the sides of the controller. That, coupled with the friar sounds of the grease boiling, made for some fun rumble feedback.

The other experiment I had was with the soup. I wanted to get the sensation of the water boiling into the controller, so that the player would feel tiny bubbles popping with the rumble. Again, this wasn’t possible due to the length of time it took for the motors to power up. So instead I had a very small amount of rumble on at all times (10% or so) so that the motors would take less time powering up to deliver a jolt. Then I had a random gauge that would input different levels of rumble for just a short fraction of time to the left and right side, independently. The result was an unpredictable feeling of rumble that nicely emulated the sounds of boiling water. 

(Upon testing it with a Dualshock 4 I was a bit disappointed that the rumble was much more subdued, though that’s mostly due to the unofficial drivers at the moment. )

Again, it’s nothing major, and most players won’t even notice it or feel a difference (and is limited to Windows only support for the Steam patch), but it was surprisingly fun to code.

GDC and Steam

After almost twenty straight hours of coding, at 5am the game was ready to deliver to YoYo Games. In just a few days it was up and running on PS4 and the week after was alongside a ton of games demoed at the YoYo booth at GDC, and though I wasn’t there it was such a great experience to get feedback and be part of such a big announcement.

YoYo Games at GDC 2014

Because Game Maker makes it so easy to shift a single build into anything you need to export to, I used the code for GDC as part of a larger update to have the entire game be played with a controller for Steam, as well as be ready for any future possibilities with console ports.

Should there be a console port, I’d love to dive even deeper into adjusting the control inputs. Should one recipe call for everything on the left side of the ingredients column but just a few on the right, for example, I think the controls would benefit from the left stick being unlocked and the right stick requiring a reset per ingredient. But would the player benefit from something like that? By the time they realize the entire column was necessary for the recipe, it would be too late to utilize the analog rotation. It’s really hard to say until I get a lot of feedback from the new controller patch.

What I do know is that the process of porting a game’s controls over to a controller can be a fairly big task in itself, and doing so while retaining the speed and accuracy of a game like this was incredibly challenging. I think there can still be refinements to the control, but overall I’m very happy with the results. The new Extreme Difficulty, built with keyboard control in mind, was handled fairly well with a controller (about :20 into the video):

Full disclosure: it took me about twenty tries to get a perfect string of combos for that video, during which most of the time I felt like I was having a heart attack (gotta love the new difficulty!). While I don’t think I could go up against a keyboard with a controller and win in terms of speed and accuracy, I think I could hold my own pretty well. Considering I made zero adjustments to the intensity and demands of the game for controller input, that’s not too shabby.

Controller art by @twobitart