Project overview and structure

Before you start your project, you should consider how you intend to set it up and architect your project in the long term. Far too many developers 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 regard 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 game development and should not be overlooked. What follows are some of the best practices you can use from day one 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 this book, wherever applicable.

Project overview

Before we can start discussing how to structure our game's project, we need to discuss what features the game we will be creating will actually include.

We will be creating a 2D RPG with the following key attributes:

• A 2.5D town
• A conversation system
• A shop with an inventory system
• A character inventory system
• A top-down overworld with random encounter battles
• A turn-based battle system with character animations

Now that we have a general idea of what type of game we will be creating, we can start structuring our project and implementing some if its features.

Structure

When you start a new Unity project, Unity places the Assets folder within the folder you designate for the project. Many Unity projects have all their assets in the root Assets folder or are organized by how the game works. This isn't particularly wrong, but as the 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 does and guiding yourself to use a more component-based design. Each scene is built up of many assets 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 asset, there is no need to divide them further.

Asset naming

There are no specific patterns for how you should name each of your assets. 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.

While it is not required that you follow a naming pattern, some of the more common patterns include the following:

• Prefixing the name with a three letter acronym for its type: scn for a scene, efx for 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:

Unity script examples