Book Image

Mastering Unity 5.x

By : Alan Thorn
Book Image

Mastering Unity 5.x

By: Alan Thorn

Overview of this book

Mastering Unity 5.x is for developers wishing to optimize the features of Unity 5.x. With an in-depth focus on a practical project, learn all about Unity architecture and impressive animation techniques. With this book, produce fun games with confidence.
Table of Contents (16 chapters)
Mastering Unity 5.x
Credits
About the Author
Acknowledgment
About the Reviewer
www.PacktPub.com
Customer Feedback
Preface

Getting clear on design


To build games professionally and maximize productivity, always develop from a clear design, whether on paper or in digital form. Ensure that the design is stated and expressed in a way that's intelligible to others, and not just to yourself. It's easy for anybody to jump excitedly into Unity without a design plan, assuming you know your own mind best of all, and then to find yourself wandering aimlessly from option to option without any direction. Without a clear plan, your project quickly descends into drift and chaos. Thus, first produce a coherent game design document (GDD) for a general audience of game designers who may not be familiar with the technicalities of development. In that document, you will get clarity about some very important points before using development software, making assets, or building levels. These points, and a description, are listed in the following sections, along with examples that apply to the project we'll be developing.

Note

A GDD is a written document created by designers detailing (through words, diagrams, and pictures) a clear outline of a complete game. More information on GDD can be found online at https://en.wikipedia.org/wiki/Game_design_document.

Target Platforms

Target Platforms

The Target Platform specifies the device, or range of devices, on which your game runs natively, such as Windows, Mac, Android, iOS, and so on. This is the full range of hardware on which a potential gamer can play your game. The Target Platforms for DK include Windows, Mac, Android, and iOS.

Reaching decisions about which platforms to support is an important logistical and technical as well as political matter. Ideally, a developer wants to support as many platforms as possible, making their game available to the largest customer base. However, whatever the ideals may be, supporting every platform is almost never feasible, and so, practical choices have to be made. Each supported platform involves considerable time, effort, and money of the developer, even though Unity makes multi-platform support easier by doing a lot of low-level work for you. Developing for multiple platforms normally means creating meshes, textures, and audio files of varying sizes and detail levels as well as adapting user interfaces to different screen layouts and aspect ratios, and also being sensitive to the hardware specifics of each platform.

Platform support also influences core game mechanics; for example, touch-screen games behave and feel radically different from keyboard-based games and motion controls behave differently from mouse-based controls. Thus, a platform always constrains and limits the field of possibilities as to what can be achieved, not just technically, but also for content. App Store submission guidelines place strict requirements upon permissible content, language, and representations in games and allowed in-app purchases and access to external, user-created content.

The upshot is that Target Platforms should, for the most part, always be chosen in advance. That decision will heavily influence core game mechanics and how the design is implemented in a playable way. Sometimes, the decision to defer support for a particular platform can, and should, be made for technical or economic reasons. However, when such a decision is made, be aware that it can heavily increase development time further along the cycle, as reasonable adjustment and redevelopment may be needed to properly support the nuances of the platform.

Intended audience

Deciding on an Intended Audience

The intended audience is like a personality profile. It defines in summary who you're making the game for. Using some stereotyping, it specifies who is supposed to play your game: casual gamers, action gamers, or hardcore gamers; children or adults; English speakers or non-English speakers; or someone else. This decision is important especially for establishing the suitability of the game content and characters and difficulty of gameplay. Suitability is not just a matter of hiding nudity, violence, and profanity from younger gamers. It's about engaging your audience with relevant content: issues and stories, ideas that are resonant with them and encourage them to keep playing. Similarly, difficulty is not simply about making games easier for younger gamers. It's about balancing rewards and punishments and timings to match audience expectations, whatever their age.

As with Target Platform, you should have a target audience in mind when designing your game. This matters especially for keeping focused when including new ideas in your game. Coming up with fun ideas is great, but will they actually work for your audience in this case? If your target audience lacks sufficient focus, then some problems such as the following will emerge:

  • Your game will feel conceptually messy (a jumble of disconnected ideas)

  • You'll struggle to answer how your game is fun or interesting

  • You'll keep making big and important changes to the design during its development

For these reasons, and more, narrow your target audience as precisely as possible, as early as possible.

For Dead Keys, the target audience will be over 15 years of age and Shoot 'Em Up fans who also enjoy quirky gameplay that deviates from the mainstream. A secondary audience may include casual gamers who enjoy time-critical word games.

Genre

Genre is primarily about the game content: what type of game is it? Is it RPG, first-person shooter, adventure, or any other type? Genres can be even narrower than this, such as fantasy MMORPG and cyberpunk, competitive, deathmatch and first-person-shooter. Sometimes, you'll want the genre to be very specific, and other times you'll not, depending on your aims. Be specific when building a game in the truest and most genuine spirit of a traditional, well-established genre. The idea in this case is to do a good job at a tried and tested formula. In contrast, avoid too narrow of a definition when seeking to innovate and push boundaries. Feel free to combine existing genres in new ways or, if you really want a challenge, to invent a completely new genre.

Innovation can be fun and interesting, but it's also risky. It's easy to think your latest idea is clever and compelling, but always try it out on other people to assess their reactions and learn to take constructive criticism from an early stage. Ask them to play what you've made or to play a prototype based on the design. However, avoid relying too heavily on document-based designs when assessing fun and playability, as the experience of playing is radically different from reading and the thoughts it generates.

For Dead Keys, the genre will be a cinematic first-person zombie-typer! Here, our genre takes the existing and well-established first-person shooter tradition, but (in an effort to innovate) replaces the defining element of shooting with typing.

Game mode

The term game mode, might mean many things, but in this case, we'll focus on the difference between single-player and multi-player game modes. Dead Keys will be single player, but there's nothing intrinsic about its design that indicates it is for a single player only. It could be adapted to both local co-op multiplayer and Internet-based multiplayer (using the Unity networking features). More information on Unity network, for the interested reader, can be found online at https://docs.unity3d.com/Manual/UNet.html.

It's important to decide on this technical question very early in development, as it heavily impacts how the game is constructed and the features it supports.

Game objective

Every game (except for experimental and experiential games) need an objective for the player; something they must strive to do, not just within specific levels, but across the game overall. This objective is important not just for the player (to make the game fun), but also for the developer to decide how challenge, diversity, and interest can be added to the mix. Before starting development, have a clearly stated and identified objective in mind.

Challenges are introduced primarily as obstacles to the objective, and bonuses are things that facilitate the objective-that make it possible and easier to achieve. For Dead Keys, the primary objective is to survive and reach the level end. Zombies threaten that objective by attacking and damaging the player, and bonuses exist along the way to make things more interesting.

Note

I highly recommend that you use project management and team collaboration tools to chart, document, and time-track tasks within your project. Also, you can do this for free; some online tools for this include Trello (https://trello.com), Bitrix24 (https://www.bitrix24.com), Basecamp (https://basecamp.com), Freedcamp (https://freedcamp.com), Unfuddle TEN (https://unfuddle.com), Bitbucket (https://bitbucket.org), Microsoft Visual Studio Team Services (https://www.visualstudio.com/en-us/products/visual-studio-team-services-vs.aspx), and Concord Contract Management (http://www.concordnow.com).