One of the more unique aspects of mobile gaming is the input system. Unlike most other devices for gaming, mobile devices are not designed to take input (such as traditional gaming systems) and are instead in the spectrum of an entertainment device, meaning they are not solely used to play games. This means that we have to observe how the player is going to interact with the game differently as compared to devices specific to gaming—which have either dedicated or what you'd call standard input schemes that allow the player to have a pleasing experience.
The most successful games on the mobile platform do one thing well: they give the player a simple and responsive input. For example, games focused on puzzles such as connect three items of one type in a row by swiping types between each other, a slot machine, and casino games, which require the touch of a single button, or even the more complex games (such as the endless runner) where the player can control the game with taps and swipes that have a much better chance of being successful than a game that uses arrows or joysticks to move and multiple buttons to cause the character to do something. It's not to say that you can't have complex movement of the character in a game; it is more to say that if you do, solve the issue with the most basic input scheme possible.
For the game in this book, the only input will be of a swipe. The player will swipe to have the character on screen to jump. If on a wall, jump to another wall, continue forward, or swipe down. Swiping down while already jumping will also cause the character to fall to the ground faster.
For the sake of teaching, the code represented in this chapter will also detect when the player taps on the screen. This is included here in the hope of teaching you how to include different types of input if you were to make another game after following along with the instructions here.
To sum up, we will cover the following topics:
Touch
struct, and how we will use it to create our own struct called SimpleTouch
The very first step is to create the C# class that will calculate the input from the player. To start, open Unity with the following steps:
Scripts
; you can give it any name you like, although I recommend something that keeps you organized.PlayerInput
.Unity ships with its own Integrated Development
Environment (IDE) called MonoDevelop. When you double-click on PlayerInput
, this is what will open.
Now, double-click on PlayerInput.
When PlayerInput opens, it will have a default structure that Unity uses for classes created in the engine, as shown in the following code:
using UnityEngine; using System.Collections; public class PlayerInput : MonoBehaviour { /* Use this for initialization */ void Start () { } /* Update is called once per frame */ void Update () { } }
This code is the very basis of what Unity gives you.
Start()
: This is called when an instance of this class is created. It is generally used to set up references or other variables when the class first starts running in the game.Update()
: This is called for every tick of the game. A tick is the time it takes for a device to render a frame. This means that if the game is running at 30 frames-per-second, Update()
will be called 30 times in that second. Update()
is what we will use to calculate the types of input the player will use.Before we start coding, we must include something in the class for a feature that is not defaulted. Enter using System;
at the top of the input class under the following code:
using UnityEngine; using System.Collections;
Make sure to have all three of these included in the class.
Before we begin, we must first understand what Unity will give us when we look for the Touch input from the player.