Designing Itsy-bitsy Games for Mobile Browsers

1

Index

Stats

3,251 visits, 5,054 views

Tools

Translations

This tutorial hasn't been translated.

License

This tutorial is licensed under CC BY 4.0. Please refer to the license text if you wish to reuse, share or remix the content contained within this tutorial.

Published on 12 Mar, 2016. Last updated 19 Feb, 2019

11. Keep controls simple and intuitive

Single taps or one finger dragging/flicking is best - avoid any inputs that require multiple inputs or virtual buttons as this will take the player time to learn and distract them from the core experience.

Where possible, relate the input action to the target object’s behaviour e.g. the user will expect to be able to flick/bat balls, pop bubbles, tap buttons etc.

12. Every action should have a reaction

Each interactive object should exhibit a response when its state changes or it is interacted with, even if it is to indicate that it can’t currently be interacted with. The response should, where possible, be both visual and audio.

Reactions should be proportional to the action e.g. higher scoring actions should result in a more dramatic response.

13. Every object should have at least three states: in, loop, out

These three basic states define what happens when an object enters and exits a scene, and its neutral behaviour whilst it is present in a scene.

Signal each state with a clear, unique, animation, so that it is obvious which state the object is in.

Objects with similar behaviours should exhibit similar state transitions so that the player can understand that the objects behave in a similar way.

Usually an object requires more than three states; for example, most buttons require: in, inactive, normal (loop), over, pressed, released, active and out.

14. Objects should exhibit affordance

Buttons, avatars, sliders etc should look like they can be touched, and their graphic design should reflect their function - this doesn’t mean that they have to be skeuomorphic (i.e. looking like a real world, physical object) rather that the icons, colours and shape are suggestive of their behaviour.

Use “danger” colours (red, black/yellow) and aggressive shapes (spikes, harsh/straight/jagged edges) on hazards to indicate that they should be avoided.

Use warm, inviting colours (green, gold, yellow, light blues) and soft shapes (curves, circles, “fluffy”) on pick-ups, buttons, switches etc to entice the user to interact with them.

Ensure that interactive objects (including walls, platforms etc.) stand out from the background by using contrasting colour hues, thicker border lines, different textures.

Where it is sensible, animate interactive objects to draw the user’s eye to them.

Objects that share behaviours should share graphic design features so that the users will associate the object’s form with its functions.

15. Make interactive objects large enough to be touched easily

Objects should be large enough that changes in state are at least partially visible when touched, and are not completely obscured by the finger.

16. Longer games require mechanics progression

For games of 30 seconds or more (and sometimes for shorter games too) there should be a change in the mechanics and difficulty in response to the players performance; for example, this can take the form of speeding up gameplay, increasing the number of hazards (and pickups), increasing the complexity of the challenges/puzzles etc.

Accompany an increase in difficulty with an increase in potential reward e.g. more frequent or more valuable pickups/scoring.

17. Provide clear feedback for extremes of performance

If the user is performing well (e.g. a long chain of correct answers) then provide strong visual and audio feedback to indicate this. Escalate the feedback the longer the chain continues.

If the user is performing badly use feedback to indicate that an error has been made and, where possible, indicate what the error is - e.g. put a cross over the incorrect input/answer, highlight the correct answer, display a text message to indicate the error.

18. Use goal conflict to create tension and excitement

Goal conflict is the process of having two or more objectives, and the pursuit of one makes it less likely that the others can be achieved. For example: goal_a = avoid the spikes; goal_b = collect the coins; if the coins are positioned near the spikes then the achievement of goal_b makes goal_a much harder to accomplish - the player will have to find a strategy to reduce the risk of failing goal_a if they want those coins!

19. Reward core skills

Performance can usually be graded by combining three metrics: accuracy, consistency and speed; the relevance of each of these should be taken into account when designing scoring and progression mechanics, weighted against the difficulty of the challenge.

20. Focus test from the start

For small games it is critical that the player can understand the interface and gameplay right from the first play - as soon as you have something playable, even just the bare bones mechanics, get some fresh eyes on it. Watch your test subject play, don't offer any advice, and see how quickly they work it out. If they don't get it after a few attempts, ask them what they thought they were meant to be doing and make a note, explain what the intended gameplay was and ask what they feel would aid comprehension. Test with a number of players to gather a consensus on changes to your next iteration.

  • 0 Comments

Want to leave a comment? Login or Register an account!