It's time to start putting in the building blocks that will make up your game, starting with the setting up the project and then on to main character. It's an important first step as most of your game's core logic and framework generally centers on the main protagonist and highlights exactly how the player will interact with the game.
Here, we are aiming to create a 2.5D style in-game world where the player can explore each town and have random encounter scenes to fight off those pesky bad guys. So, first we need to get our character in and moving.
The following is the list of topics that will be covered in this chapter:
- Designing a good class structure
- Planning and designing behaviors
- Importing sprites
- Setting up user control effectively
Note
For this game, we will use the excellent, free Unity games starter kit resources, which can be found at http://wootstudio.ca/win8platstarter (towards the bottom of the page).
There are several different themed sets of assets for use in any game (commercial or otherwise). For the purposes of this book, we will use the Fantasy pack and its associated Backgrounds.
Additional assets that I have created myself will be included with the associated code bundle of this title.
Before you start your project for real, you should consider how you intend to set it up and architect your project in the long term. I've looked at or worked with far too many projects that have created problems for themselves by just diving in rather than designing the outline for the project at the start.
Your game and your assets are not the only things to consider when starting a fresh project. Sure, you can start importing assets, creating scripts, and getting things running; most Proof of Concept (POC) projects start this way. Once your project is of a sufficient size and you start expanding on your initial concept, you'll realize that you have issues with regards to picking up items and putting them together. Then, you will start devising new ways to organize your project and eventually find that it's an unmanageable mess; nevertheless, you will stride on, taking longer and longer to produce new content or add new features.
The best advice one can give is to think about your entire project and how you organize it as an asset in itself, and accordingly, design it correctly from the beginning. So, what follows are a few short tricks that you can learn to get started on the right foot.
Architecture is a point that is often missed out in any game development and should not be overlooked. What follows are some of the best practices you can use from day 1 to design your game and thereby save a lot of time to fix or change and reorder things later. These lessons will be used throughout the course of the book wherever applicable.
Note
As this chapter focuses on the implementation of the 2D sprite system, we will return to these lessons later in Chapter 5, NPCs and Interactions; however, they are critical at this juncture, that is, before we write the code.
When building games with Unity, especially when you are prototyping, you will find that most projects have all their assets in the root of their Unity project folder or are organized by how your game works. This isn't particularly wrong, but as your project gets larger, this will eventually cause problems.
The best way in which Unity advises you to organize your project (as also shown in all of their own examples) is to group objects by their type in the root Assets folder, as shown in the following screenshot:
This ensures that you will find assets for your entire project that are ready for reuse in every scene or level according to the type of object. You can then subdivide these appropriately depending on their use, such as the following:
- Separating animation clips from all the controllers that may act on them or on your models:
- Grouping audio by its intended use in your game, such as enemies, special effects, and background music:
- Grouping prefabs by layer or their intended use:
- Sprites can also be structured in the same way; you can order them according to how they should be used in your project:
By following the preceding patterns, you are organizing your project effectively in the same way Unity itself does under the covers and guides you to use a more component-based design. Each scene is built up of many components through the lifetime of your project, so organizing your assets this way will help in the long run.
You can set this level of subgrouping for scripts, scenes, fonts, materials, and so on. However, as these are generally distinct things that apply to every component, there is no need to divide them further.
There are no specific patterns for how you should name each object/component in your asset library as such. Generally, this is left to your preference, and more importantly, how you recognize each part of your game. There is no need to give something a really long and complicated name in the preceding structure, only so long that you can find it later.
Many of the other tutorials I have read or watched tend to lean on a few patterns for naming, most of which seem to follow the usual coding standards such as the following:
- Prefixing the name with a three letter acronym for its type:
scnfor a scene,efxfor an effect, and so on - Suffixing an underscore plus the same three letter acronym to the end of an asset's name
- Using a path-like name such as
playerScene1BounceToWallScript
From experience, these are useful, but my advice is to name things plainly based on what it is. Using the structure mentioned earlier, you have already organized your assets to overcome a lot of the issues that the preceding patterns try to solve.
Plan ahead before you even start your game and set a standard that works for you. You should be able to identify what each asset is and what it does just by looking at the name. However, remember that each asset will most likely be used many times on many different game objects, so plan accordingly. Add prefixes and suffixes only when a script or asset is intended to be limited to a certain type of game object.
The Unity examples are another good place to look for inspiration here. See the following screenshot and decide whether you can tell what these scripts are and what they are used for just by looking at them:
