Common Gameplay Programming Pitfalls and How to Avoid Them
Updated a year ago
For a little context, I am about to begin a new project (an action game) and want to review some of the things I have learned on previous projects so I don’t make the same mistakes twice. In particular I want to focus on some of the intricacies of character controls, and how small things can make a big difference for players.

Skating and the Importance of Communicating Player Input

One of the projects I worked on in the past was an interactive holiday card, where you skate around and cut holes in the ice to sink enemies. For this I had to create skating controls that feel responsive to the player, while still feeling like skating.
My first attempt at the controls involved having the character turn and move towards the player's input direction. Turning speed and acceleration were low to make it feel like you were sliding around on ice. When testing this with players I had a quite negative response. There appeared to be too much of a disconnect between where the player was pointing with their input and what their character was doing. This resulted in people struggling to control their skating.
My second attempt, suggested by many of my play-testers at the time, was making something more akin to tank controls; so you have a button to accelerate, and two buttons to rotate. Some players found this to be a better solution, but people who were not used to this type of control scheme found it quite disorienting. The audience for the holiday card was going to be mostly non-gamers so I didn’t want to stop there.
The solution I came to was a modification on the original controls, but this time trying to give a better indication of the players input. To do this, I separated the direction the character was facing from the direction that they are moving. The actual movement stayed the same, acceleration and turning was still slow, but this time the character would instantly face the direction of player input. This gave players a visual indicator of how their own actions are affecting the game, as well as the added benefit of making it look like the player was drifting at times ( ). After playtesting this with players, it turned out to be by far the best controls of the three solutions and was maneuverable for gamers and non-gamers alike.
The main take-away I had from this was the importance of visual feedback. The movement was almost exactly the same but the visual adjustments made all of the difference. You can see these same techniques in many games that need to ride that line between being responsive but also giving the characters a specific weight and physicality. Dark Souls for example, your character may not swing a sword right away after hitting a button, but there is still the immediate visual feedback of your character stepping back in preparation for their swing. I have found from my own experience, that unresponsive controls stem from a miscommunication of the effect the player’s input has on their character.

Bravetail and Considering Venue and Audience

Another former project I worked on, was a public display called Bravetail. It was a Kinect-based archery game, made to promote the Pan-Am games coming to Toronto. I was contracted as the main developer on the project, and had about a month to make it. I am proud of the final result, and enjoyed my time with the project; but as with any project it had its hiccups.
The short development cycle made it difficult to implement a system for very accurate body tracking, as well as finding out late in development that it was meant to be displayed outdoors (the sun being very bad for Kinect tracking). We handled it well given the circumstances, but inevitably people still had trouble with the controls more often than not.
We were not the only game contracted for the event however, and there was a very simple soccer game that far outperformed our own game. It would simply display the player(s) on the screen in front of a net, and shoot a cluster of soccer-balls at them. The game would then take pictures of the player(s), looking ridiculous as they tried to defend their net.
The tracking wasn’t much better than the tech we were using, and they had much less gameplay and features than Bravetail. Their focus however was on the social aspect of the setting, people did not care about having complex gameplay, or accurate tracking; they just wanted to see themselves looking funny with their friends.
My main takeaway from this project was to pick design considerations carefully. Things like: Who is playing my game? What do they care about? Why are they playing my game? These questions lead to a better game, as well as help to focus development resources in the right area. Often the most difficult technical issues can be solved by design thinking rather than technical know-how.
Joshua Cappelli
Director - Owner