Welcome. You are at the beginning of your journey into the world of 2D game development. Throughout this book, we will explore many things that the world of 2D games can offer and how to design exciting adventures. This book not only explains what to do in Unity but also what is involved in the game design process. In this way, you will have a solid foundation in game design and development.
In some instances throughout this chapter and the rest of the book, there are various links to resources (such as Unity documentation). In many of these instances, both the link and a QR code are provided. The intention here is to save time entering the URL into your browser if you are reading a hard copy of this book. Now with that said, this is what we will cover in this chapter:
- Game design
- The game design process
- Developing 2D games
- Unity Engine
- Creating new projects in Unity
- Preparing for the projects in this book
- Key tips and best practices for 2D (and general) game development
- Additional game design exercises to develop your skills as a game designer
By the end of this chapter, you will have achieved the following:
- Have a general understanding of game design and the processes involved in making a game
- Know how to download and set up Unity
- Know how to configure Unity for a 2D game project
Now, let's begin our journey.
Game design is an exciting adventure that draws from many different disciplines, such as programming, art, design, audio, and creative writing. This may be overwhelming, especially if you're new to game design. You may think "but I am neither a programmer nor a creative writer, and I can't draw to save my life!" If you have a passion for games, then game design is possible. However, it is not for the weary. Game design will challenge you and it will test your patience. However, I promise you that the feeling you get from learning how to make your first character move with text in a script, to having that character collect coins, shoot enemies, and finish a level is an extremely rewarding experience.
This book does not assume that you know anything about creating games or any of the skills that are associated with game development. Over the course of the book, you will learn the basics of programming in C#, how to create three different types of 2D games in Unity, and a whole lot more about the game design process in general. Fear not about the art or the sound, as we will be using some free asset packages and sounds so that you can create something magical. Of course, if you dare to push yourself, I encourage you to dabble in these areas, as even a basic level of understanding goes a long way.
We can think of game designers like chemists, except chemists that create mixtures of entertainment, emotionally driven narratives, and exciting experiences. If you think back to chemistry in high school, we all learned that some things make smoke, other things make bubbles, and a few things when combined make explosions; games work in a similar way, just with different substances (for example, game elements and mechanics).
When it comes to the distinction between these substances, namely game elements, and mechanics, there are many interpretations of what they are and what they are made up of. For the purpose of this book, when a player performs an action, they are likely to get something. This could range from a Badge, Point(s), Levels, or part of a Story. The "thing" that the player gets is what we will define as a "game element". Of course, there are many different examples of and perspectives on what game elements are, but for the purposes of this book, this will be our definition.
On the other hand, since game elements are the outcome, then the process of how we get them is what we will define as game mechanics. This could be anything from trading with other players, exploring mysterious worlds, and even Winning or Losing. Performing or engaging in these actions will result in obtaining game elements.
Games are enjoyable to play, we play them to entertain ourselves and friends. Over many decades, as games have developed along with the technologies that make them available, the context of their uses has also evolved. For example, most games are created to entertain us (for example, Assassin's Creed). That is, there is no underlying intention, such as to supplement/support curriculum material or teach us about science (for example, Ludwig) all the way to operational health and safety. Finally, there are games that have been developed for entertainment but have ended up being used for more intuitive reasons. This is because of the educational potential that they afford (for example, Minecraft and Sid Meier's Civilization series) some games that have been created for entertainment purposes have provided ways for students to learn and practice various topics. Lastly, there are game-like experiences or "gamified" experiences that apply game design principles to achieve everyday tasks, from becoming more productive at work, eating better and maintaining a healthier lifestyle, to managing finances and developing new skills (for example, Habitica).
Now that we have a brief understanding of what games are made of and their use in different contexts, it's time to understand the game design process.
As I mentioned before, there are many things that define what is game design. For example, it is an opportunity to transport players to realities that we can only imagine to be people that we may only dream of. However, just as important as what it is and isn't, is how it is done. Generally speaking there is a systematic approach that game designers follow to create a game. It begins with the "idea"—the concept of what the game will be. This is usually not static and will change over the course of a game's development. From there, and depending on who is on your team, it will go through many design phases before becoming a prototype. Beyond the prototype phase, the actual game will enter the development process where the actual assets (and not placeholders) will be created and implemented. From this point, the game will go through an iterative cycle, where the game will undergo playtesting, changes, more playtesting, more changes, and then eventually it will be refined to the point where it will enter the last stages. Here, we will briefly explore each of these stages.
The workflow process of game design is linear in the sense that there is an order that it takes place: concept development, prototyping, implementation, testing, and hitting release. This concept is illustrated here:
Of course, the diagram only outlines the process in general. As you develop games and work with others, you will find that this process loops in many other parts. Sometimes, through designing and prototyping your concept, you may end up having to change the initial idea. The important thing to remember is that while to some extent game design is a linear process, in terms of developmental stages, these stages do and will often form iterative cycles.
We begin the process of game design by first brainstorming and then designing and prototyping a concept. The ideas at this stage can be adventurous, out there, and completely bizarre, because anything goes. It may be useful to get yourself a small notebook to write down your thoughts because they will come to you at any moment. Another thing to think about is who you are designing this game for. Do you know enough about them or do you need to do a bit more research? Defining your demographics early on can help when it comes to refining your idea. For example, if the people you are designing play role-playing games (RPGs) then they are likely to prefer a detailed narrative and character customizations, as opposed to premade characters and a simple story. Therefore, the kind of environment, what kind of narrative that it can afford, and the characters that you will create (and possible options for them) will need to be thought about while you're brainstorming ideas.
Some useful tips when it comes to concept development are listed here:
- Keep all your ideas in a journal or somewhere safe so that you can refer to them later.
- Challenge yourself if you're stuck with ideas on what kind of game to create. Choose the first thing that comes to your mind, flip a dictionary and choose a word at random; there are many ways to really push your creativity.
- Play games that you wouldn't normally play, and if you don't play, then start!
By playing more games in different contexts and on different platforms (mobile, PC, PlayStation, and so on), you will begin to learn how experiences change depending on the hardware you're using to interact with. Pay attention to how the player controls differ between a mobile and console game. These little things will help you later when you start to design and prototype your game.
- Deconstruct games, identify the core features, and remake them. At the end of this chapter, there is a nice exercise for doing this but really think outside of the box. The aim is to be inventive, to create something new with the same concept.
- Learn about games! Don't just become the game designer, become a researcher, an explorer of games. Invest a little bit of time to learn what other game designers have done, how they have done it, what worked or didn't. There are many postmortem videos about games that explain the development process. In addition, it also gives you a bit more insight into the overall game design process and the roles and responsibility that each team member has. In this way, if you're thinking about creating a small (or large) team, you can understand what's involved.
- Be critical, be judgmental! If you played a game and didn't like, identify why that was. Was it the controls, perhaps the story was boring? Then take the guise of the designer, and think about how you would fix it: would you change or remove something, how would you make it better?
This is where those crazy ideas become a bit more refined. You begin to weed through all your ideas, deciding which ones are feasible, which ones are not appropriate for your intended audiences, and so on. Start with pen and paper and draw out your game. You don't need to be an artist; prototyping is rough, it's messy, it is completely raw. Don't get caught up in how neat it looks. The point at this stage is to get what's in your head out on paper. Other things that you might find useful during the prototyping stage are post-it notes, colored pens, scissors, dice, counters (for example, beads, buttons, stones, and so on), other game bits and pieces (for example, Monopoly money, figurines, and so on). During the prototyping stage, you will want to also see how the interaction flows through the game. For example, does the interaction feel difficult in the sense you can't do or get something that you want to? Perhaps the game feels a bit too easy or hard? At this stage, these are considerations that you will also need to iron out when it comes to properly playtesting your game, so don't worry too much if they still don't feel completely right.
This is where you will transfer what you've conceptualized, designed, and prototyped into the actual game. Generally, this is where you begin integrating it into the game engine, working on the actual models that will feature in the game. At this point, you're no longer prototyping, but developing the game. From here on out, you should have a clear idea of what your game is and how it will work from beginning to end. Once you have begun implementing your assets into the actual game, you will go through various iterations. These iterations will often occur after playtesting, albeit informal or formally done (for example, open/closed alpha, beta testing). The projects in this book will start at this stage. This is because we already have assets ready for you to use. But it is important to know at what stage of the game development process that implementation is at.
This is probably the most important part. If you haven't already been doing this, then I would suggest that you stop what you're doing and start. Testing is such an important step in the process because it helps to make sure that your game runs smoothly and efficiently. Not only this, it can raise issues relating to player engagement, glitches/bugs/exploits within your game that can give other players an advantage when it comes to game time (especially in multiplayer games). We will cover playtesting in a later chapter, so we won't go into too much detail now.
While you're testing, you will also need to iterate your design. Iterations may be minor, such as the location of objects, others may be large, such as changing the structure of a level or redoing the animation of a character. At this stage, it's about refining what your game is to make it what you want it to become. Each iteration is an improvement that will come with more testing. This is why testing is also very important because, without it, you're not able to refine and improve, or even fix part of your game, so that it gets to the stage that you envisioned it at from the beginning. Of course, you will get to a point where you find a minor change here and another one there, and you may even get caught up in the pursuit of perfection. All game designers have reached that point, so it's a common feeling of wanting "completeness" to the point of perfection, but it rarely comes. So when you get to this stage, you need to let go and move on. Otherwise, you will never complete any game, ever!
This is the polishing stage where you will begin to fine-tune what has already been implemented. This can include a range of different things from tweaking post-processing effects to character speeds. This is the final stage before you release your game on your targeted platform to the public. We will discuss this as we go with each of the three games, and in the final chapter so that your game will be ready to go.
Who you have as part of your team can also impact the overall design and development of your game. Having the right resources, skill set, and even personalities can have a large influence on a game's success. Generally, a game development team consists of many different people: artists, designers, animators, programmers, and sound designers. Each of these roles will be sub-divided, for instance between character artists, texture artists, level designers, AI programmers, gameplay programmers, and so on. However, having a range of different skill sets allows for each part of the game's design to be developed in a concentrated environment by someone who has experience in the relevant field. However, not every game is lucky enough to feature an expansive team; you might even be reading this book without knowing anyone from any of these fields, which is why this book is here to guide you through the process and to support and expand your knowledge.
There are some major and subtle differences between 2D and 3D game development, as well as some misconceptions. Here, we'll go through the most common ones, and touch on other relevant ones throughout the book. While you don't need a complete understanding of these differences, the ones here are important to keep in mind if you're new to 2D game development.
The first obvious difference between 2D and 3D is that 2D utilizes only two axes: X and Y; whereas 3D has an additional Z-axis. To explain how this works from a games perspective, see the following diagram:
Generally speaking, the z-axis is used for depth and is utilized so that the player can explore an environment like they would in reality whether it is from a third person or first-person perspective camera. The z-axis allows the added third dimension to an environment. 2.5D games utilize the z-axis to provide a sense of depth because the game is still fixed to the x and y-axes.
In saying that, it is important to know the differences between 2D, 2.5D, and 3D games. While there are many different stories, quests, and adventures that games can take us on, these experiences, at least in terms of their appearance and design, will differ depending on what axis they are using—x, y, or z. Before we start creating any game in this book, we'll just briefly go through some examples of 3D and various types of 2D style games. In this way, you will learn about the differences between the two and what types of experiences that they can afford.
These games are everything from Assassin's Creed (featured in the following screenshot to Skyrim and everything in between. They are completely 3D immersive, explorable, and interactable environments. When you think about the design of a 3D game, you need to think about what the physical environment will look like. What kind of objects will be in it? How does the player navigate around them and through the world? For example, think about where you are right now.
If you had to turn your current environment into one that would be in a video game, what kinds of objects would you need to create? Perhaps a desk or chair, maybe a lamp? Then, how would players interact with these objects? What kind of effects would occur, such as a player turning the lamp on or off?
There are many basic and intricate details that go into making a 3D environment. Of course, they are not exclusive to 3D environments, as we will see in the other types of games, but these are some fundamental considerations.
Just like the name suggests, orthographic 3D is a 3D game that is played from an orthographic perspective. Sometimes, these are also referred to as Isometric games and are given this name because of the perspective that they are played in. Some popular orthographic games include Diablo, Q*bert, Clash of Clans, and Monument Valley (featured next).
Unlike 3D, and depending on the type of gameplay that is required (for example, can the player rotate the environment?), the player will more than likely not see all sides of the game environment.
Think of 2.5D simply as a 3D environment constrained to a 2D plane (for example, x, y-axis). In other words, the player can only move up and down, left or right; they are not able to move on the z-axis. The use of 3D is merely used mostly for an aesthetic purpose, such as to show the depth of an environment. An example is shown next, with a screenshot taken from the game New'n'Tasty. In this screenshot, you can see the characters are constricted to a platform, with various levels (depths) of environmental assets visible in the background. When designing for 2.5D games, only a portion of the environmental assets are seen, as if you walked into a room and that is it, you can walk no further.
There are different practices and approaches to modeling assets for games like this, so I encourage you to explore them if 2.5D is something that piques your interest. Some other great examples of 2.5D games are Little Big Planet, Trine, Bastion, and Raymond Origins.
Games that are restricted to the x and y-axis (and don't show any depth) are what we call 2D games, such as Pac Man (featured next). They can be top-down or side-scrolling (up/down/left/right). Unlike 3D games, players only see one side of the game object at any given moment. Sometimes this can be quite linear in the sense that there is no perception of depth (with the exclusion of parallax).
Often though, sprites can be brought to life, as can the environment, with beautiful (frame-by-frame) animations and effects. Other popular examples of 2D games are Mario, Donkey Kong, Space Invaders, Monaco: What's Yours Is Mine, Mark of the Ninja, and Castlevania: Symphony of the Night.
Like 2.5D games, 2D games can also utilize "depth" by using a perspective camera or utilizing a concept known as parallax, while not having any 3D assets within the environment. To understand the concept of the parallax effect at a more scientific level, let us look at the following diagram:
Depending on where you are, certain items are in view instead of others. If a player is at viewpoint 1, then they will see the black circle and blue hexagon; if they are at viewpoint 2 then they will see the black circle and a red hexagon. Moreover, you can also think of it like this as well, when you move within a game space, the "background" that is closest to you moves faster than the "background" that is further away. It is the same when you're driving in an area, such as the country, and you can see the mountains moving slower than the fence. There are many games that use 2D with a perspective camera/parallax effect, such as Braid (featured next).
Other great examples of 2D games that feature parallax environments include Terraria and Limbo.
You've made it, you've decided you want to learn Unity, good for you! There are a few things that we need to do before we even open Unity (assuming you haven't downloaded it or used it before). If you have already downloaded Unity and set it up, you can skip the next section: An overview of built-in features in Unity; if you haven't please read on.
Now, let's start getting everything set up to create our games.
To begin, you can grab your own free copy of Unity by heading to the following URL: https://unity3d.com/get-unity/download.
Each plan has its own benefits, some with more added features than others. Depending on your long-term needs, a pro or plus plan might be useful. However, for all the projects in this book, we will be using the personal (free) version of Unity. Once you have chosen the version that suits your needs the most, download and install it.
- Tutorials https://unity3d.com/learn/tutorials
- Documentation https://docs.unity3d.com/2017.3/Documentation/Manual/
- Community https://unity3d.com/community
- Social (for example, Twitter, Facebook groups, and so on)
Once you have installed Unity, you will be required to log in. If you haven't created an account, don't fret, it's a straightforward process. Simply click on the create one link to do it. The process is simple, free, and will take little time to go through. Once you're done, come back and enter your login details, and click Sign In.
Once you've done this, there will be a short survey about you (basic demographic information) and your intended use of Unity. This is the final step before we will use Unity. When you have submitted the survey response, you will see a screen with three different options: Projects, Learn, and Activity, like this:
Projects simply show all your current projects that are either found on your computer (On Disk) or online (In the Cloud). However, what I want to draw your attention to is the Learn tab, which is shown here:
There are several types of tutorials that you can explore at your own pace, like the ones in this book, which will teach you some interesting things about Unity. You will need to download each tutorial to go through it and depending on your connection, it may take a little to no time. Here is an example of the Survival shooter tutorial, along with the instructions within the browser (left):
Unity has some great built-in features. Let's begin by exploring some of the basics. Unity has many fantastic features, and we don't have enough time to cover them all. However, as we venture further into this book we will start to cover the fundamental and important ones. As you progress through the projects, we will begin to cover more advanced features.
To begin a new project within Unity, we first need set up the project files. When you open Unity, be sure to click on the New icon in the top navigation menu, on the right. Once you have done this, you will see a screen like this:
Do these things first:
- Give your project a unique name, something that isn't too long, but also descriptive enough.
- Next, in this window, we need to specify a location for your project that has enough space available and isn't going to be modified by other people (other than team members). This is more the case when it comes to shared workspaces and networks.
- Once you have done that, click on the radio button for 2D as shown in the preceding screenshot.
- Now, click Create Project. We don't need to add any asset packages at this stage as we will be adding them manually later for each project.
Once you have done this, unity will open the project space, which we will discuss in more detail in the next section.
Unity will begin setting up the project and once it's completed, you will see a screen like this:
This might be a bit overwhelming if you're new to Unity, but don't worry, you will be up to speed in no time. We'll go through each part of it in more detail later in this chapter and throughout the book, starting in the top left corner with Hierarchy, Scene, Game, Inspector, Console, and finishing in the bottom left corner, with the Project panel.
These are the main "default" components that you will see. By default, this means they are here once you launch Unity for the first time or when you reset the workspace; we'll discuss how to do this later.
The Hierarchy Window contains all of the GameObject within the current Scene. A GameObject can be anything from a prop or character to the scenery. In essence, GameObjects are like a container that we can place things into what we refer to Component. In Unity, Component can be for lighting, animation, character control, rendering, physics, colliders, and so on. It is these that give GameObject functionality. An example of the default Hierarchy window is this:
To put it simply, GameObject contain Component, which provides the functionality for GameObject within a Scene. As we begin to add and remove GameObject from the Scene, they will appear and disappear from the Hierarchy window as well. In addition, another handy thing to know is that anything within the Hierarchy window can be parented. Parenting simply establishes a hierarchy when it comes to the connection between GameObject. For example, a 3D asset may contain various parts that need to be moved and scaled together.
Therefore, the main GameObject becomes a Parent and all the other objects become Children. You can easily parent and unparent GameObject by simply selecting the main object and dragging it to where you want it to sit within the hierarchical structure. You can see this process illustrated here:
Lastly, it is possible to have more than one Scene opened in the Hierarchy window, but we won't need to do this in the projects in the book. If you would like to know more about it, head on over to the official Unity documentation by going to this link or scanning the QR code: https://docs.unity3d.com/Manual/MultiSceneEditing.html
Next, we will look at the "big picture" or the Scene View within Unity.
The Scene View is where all the magic happens. In here is where you will create your game. You can see this part of the Unity UI, in the following screenshot. This is an interactive space where you can select, rearrange, and position all the GameObject within your project. We will cover Scene View navigation and how to move GameObject around in the next chapters.
The Game View is very similar to the Scene View, giving a window into your game. In particular, the Game View shows which is the final result, what the player will see in your game. Also, the Game View can simulate different screen ratios. This allows you to control how your game will look on the different screens on which your game will run. Although this is a good preview, before a final release, you should still test on as many as real screens possible to ensure the best quality of your game. This is how it looks in Unity:
The Inspector window is where all the information related to the selected GameObject is presented. It will become one of the most used windows within the Unity UI. As we have already discussed, Scenes contain GameObject and these contain Component, and it is in the Inspector window (like in the following screenshot) that all the information of this Component is visible. This information relates to the properties and settings of not just GameObject, but to pretty much everything else within Unity, such as assets, materials, audio, and so on.
We will go into more details about properties that are listed within the Inspector window throughout the book, but for now, this is just an overview of what it does.
To get an idea of how it looks like when an object is selected here is an example of the Inspector when the default camera is selected:
The Console window, which is shown next, shows errors, warnings, and other messages either generated by Unity or your own game code that relate to various parts of the project. These messages can be simple syntax errors within code or more problematic issues relating to performance. We will go into more detail about the different types of errors, how to resolve common ones, and how to run checks known as Debugging—to check where errors are occurring, in later chapters.
You will notice these errors as you play a Scene or try to run scripts. Each error will present itself with a name and a brief description of what the error is, and where it can be found within the script (for example, line number within a code file). Here is an example of a simple log:
The Project window will display every file within your project that you have either imported or created within Unity, such as models, scripts, plugins, and so on. Everything within your Unity project is (and should be) contained within a folder structure, with the Assets folder being the root—or parent folder, like in the following screenshot:
When you select a folder within the Project window the contents will be shown in the panel to the right, like in this screenshot:
It is quite easy to customize the layout of the workspace within Unity. There are many different panels which serve different purposes: the Window menu item in the top bar can be navigated to open additional panels or panels that have been closed earlier. To change the layout, move the mouse cursor over the panel's name you want to move and then press and hold the left mouse button. Holding down, drag the tab where you would like it to be. It can be a floating (for example, separate window, see the following screenshot) or anchored to another part of the Unity UI.
You can see the difference between floating (image on the left) and anchored next to the Hierarchy tab (image on the right) of the Project panel:
If you have rearranged the workspace and don't like it, you can reset to Unity's default layout. To do this, go to Window | Layouts | Revert Factory Settings..., as here:
You will be prompted with a confirmation box, as shown here, click Continue and the layout will be reset.
From the same menu, It is also possible to save and load custom layouts. By doing this, you can switch between your favorites layouts when you need to work on different aspects of your game.
We all like to take shortcuts from time to time, and working with Unity, hotkeys can help make performing simple tasks a whole lot more efficient. Here is a list of useful hotkeys for actions that you'll perform on a regular basis throughout this book. Feel free to make a copy of this page or print it to reference later (the list has been taken from the official documentation of Unity at the following link: https://docs.unity3d.com/Manual/UnityHotkeys.html). Here are the most used ones:
|Z||Pivot Mode toggle|
|X||Pivot Rotation Toggle|
|Ctrl/command + LMB||Snap|
|Ctrl/command + Shift + N||New empty game object|
|Alt + Shift + N||New empty child to selected game object|
|Ctrl/command + Alt + F||Move to view|
|Ctrl/command + Shift + F||Align with view|
|Shift + F or double-F||Locks the scene view camera to the selected GameObject|
|Ctrl/command + 1||Scene|
|Ctrl/command + 2||Game|
|Ctrl/command + 3||Inspector|
|Ctrl/command + 4||Hierarchy|
|Ctrl/command + 5||Project|
|Ctrl/command + 6||Animation|
|Ctrl/command + 7||Profiler|
|Ctrl/command + 9||Asset store|
|Ctrl/command + 0||Version control|
|Ctrl/command + Shift + C||Console|
When it comes to working with assets in Unity, there are some things specific to asset types to keep in mind. Below, we will go through different types of assets that are used within Unity and how they should be handled. We will also discuss some of these assets in more detail as we use them within our projects later in the book.
When you first start to build levels in Unity, primitive and placeholder objects can help you "block out" your level or use as player characters. Blocking out is simply just placing objects within the environment where the final version (even if it's not yet created) is intended to go.
These objects are a cube, sphere, plane, capsule, cylinder, and quad, and they are displayed here:
(arrows located in the center point to each of the 3 axis - x, y, and z).
You can add them by navigating through the top bar GameObject / 3D Object. Since these are 3D objects, we won't be discussing them in this book, but you can read more about these objects by visiting the link in the official documentation at https://docs.unity3d.com/Manual/PrimitiveObjects.html or by scanning this QR code:
In general, the most common image files types are BMP, TIF, TGA, PNG, JPG, and PSD (photoshop file). Each file format serves a different purpose, with different settings, and varying file sizes. For example, PNG file formats allow you to have an alpha channel, which allows part of an image to be transparent, where a JPG does not. These are important things to keep in mind when deciding on what image format that you will need to export from your graphics program. We will cover how to import images with alpha channels, as well as sprite sheets and tilemaps later in the book.
Whether you're a user of Maya, Max, Blender or anything in between, Unity can import a range of different 3D model file types (for example, .fbx, .dae (Collada), .3ds, .dxf, .obj, .blend, and .skp).
Some 3D models just remain static—they don't move; others, like characters, do. Importing meshes (3D models) with animations in Unity is a pretty straightforward process. We won't go into much detail about it here since this relates to 3D games, but you can read more about 3D meshes online by visiting this link https://docs.unity3d.com/Manual/HOWTO-importObject.html or by scanning the QR code here:
If you would like to find out more information about importing animations, you can do so by visiting this link to the official documentation https://docs.unity3d.com/460/Documentation/Manual/AnimationsImport.html or by scanning the QR code:
Whether it is background music or sound effects, games often feature sounds. In Unity, just about every common audio file format can be imported (for example, .mp3, .ogg, .wav, and so on). We will discuss audio in more detail in Chapter 3, Let's Make Some Prefabs.
You are free to create and use your own naming conventions, but to get you started, I encourage you to explore whatever kinds of naming conventions exist and find one that suits you and/or your team. We will explain the one that we will use in more detail in Chapter 2, Working with Assets.
Most assets that are used within Unity have been created externally, such as sprites, tilemaps, audio files, models, and so on. There is the possibility to save the source files in the actual Unity file so that whenever updates are made, they are automatically updated within Unity. You can learn more about this in detail by visiting the link the official documentation https://docs.unity3d.com/Manual/ImportingAssets.html or by scanning the QR code:
Usually, when you create a project you will also need to create various folders to keep everything organized within the Project window. However, when naming your folders, there are a few names that Unity will interpret as an instruction for the folder's contents to be treated in a certain way. For example, for Editor scripts to work you must place them in a folder named Editor.
The folders Assets, Editor, Editor Default Resources, Resources, Gizmos, Plugins, Standard Assets, StreamingAssets, and Hidden Assets, which are described in more detail later, are not automatically created within Unity. Therefore, each time that you create a new project, you will need to create them manually. Keep in mind the names will trigger Unity to treat them accordingly, so be sure to not use them if they're not going to do what you intend them to. Here is a screenshot of what the Unity Project window would look like if you have created all the special folders.
To begin, the Assets folder is the main folder. Think of it as the root directory, the parent folder, folder number one. The Assets folder contains the Assets (models, audio files, and so on) used in a Unity project. It will also contain any other folders, including the other special folders listed beneath Assets folder. Most API functions assume that everything is in the Assets folder, and therefore don't require it to be mentioned explicitly. This can be an oversight for game designers new to Unity, who may name the Assets folder differently. As you are likely to learn over time, there are some functions need to have the Assets folder, which is part of a file's pathname. For example, certain functions in the AssetDatabase class require that the Assets folder is included in the pathname. As a result, it is better to include this from the beginning of your path to Unity and your project structure.
Scripts placed in a folder called Editor are treated as Editor scripts rather than runtime scripts. In their essence, Editor scripts add or improve functionality within Unity, which is particularly relevant during development. In their essence Editor scripts extend Unity to suit your needs by implementing additional functionality (for example, new menus). On the other hand, Runtime scripts execute during gameplay and are the essence of your gameplay. We will focus more on runtime scripts during the rest of this book (for curiosity, you can keep reading this section, if you don't understand at first, that is fine; in fact, Editor scripts are an advanced topic in Unity development).
Lastly, like the location, the important thing to know is that Unity does not allow components inside the Editor folder to be assigned to a GameObject even if they derive from MonoBehaviour. What this means is that all runtime scripts that will be used in your game (for example, movement scripts), should be kept outside of the Editor folder.
It is important to keep in mind that where you place your Editor folder makes a difference with respect to other scripts that you have in your project. There is an order that Unity compiles and runs scripts, it is as follows:
- Phase 1: Runtime scripts are in folders called Standard Assets, Pro Standard Assets, and Plugins
- Phase 2: Editor scripts in folders named Editor that are anywhere inside top-level folders called Standard Assets, Pro Standard Assets, and Plugins
- Phase 3: All other scripts that are not in a folder/subfolder called Editor
- Phase 4: All remaining scripts (those that are inside a folder called Editor)
Since we won't be needing to create any Editor scripts, this will not be an issue, but if you want to know more about the script compilation order, then check out this link: https://docs.unity3d.com/Manual/ScriptCompileOrderFolders.html
Lastly, if this has peaked your curiosity, then there are some (intermediate) tutorials in the official documentation about Editor Scripting (among others), which can be found here: https://unity3d.com/learn/tutorials/s/scripting
Editor Scripts can make use of Asset files loaded on-demand. This is done by using the EditorGUIUtility.Load function. This function looks directly at the Asset files in a folder called Editor Default Resources.
Place the needed Asset files in the Editor Default Resources folder (or an appropriate subfolder within it). Remember, if your Asset files are in subfolders, always include the subfolder path in the path passed to the EditorGUIUtility.Load function.
You can add plugins to your project so that you can extend many features in Unity as well as improve your own efficiency and workflow processes. Essentially, Plugins access third-party code libraries, system calls, and other Unity built-in functionality.
We won't cover much 1of these things within our book, so don't worry. Furthermore, they are often easy to implement and use, especially if the plugin is well-done. The key thing to remember is that when you get a new plugin be sure to place it in a folder called Plugins. In this way, Unity will know how to handle them.
Gizmos allow you to add graphics to the Scene View. By doing so, they help you to visualize design details that are otherwise invisible. There are various Gizmos that can be displayed within the Scene View, which can be selected or deselected via the Gizmos menu. You can find the Gizmos menu at the top-right of the Scene View toolbar, like here:
Once you have clicked on this, a drop-down menu will be displayed:
The Gizmos.DrawIcon function places an icon in the Scene to act as a marker for a special object or position. You must place the image file, which is used to draw this icon, directly in a folder called Gizmos. Otherwise, it cannot be located by the DrawIcon function.
Place the needed Asset files in this Gizmos folder or a subfolder within it. If you are placing an asset within a subfolder, remember to include the path in the Gizmos.DrawIcon function.
An example of Gizmos within Unity can be seen in the following screenshot (and their keyboard shortcuts):
When you first import a Standard Asset package into Unity (Assets | Import Package) they will be automatically placed into a folder titled Standard Assets. This is also the case when you create a new project in Unity and opt to import Standard Assets, such as a first-person controller, skyboxes, lens flares, Water prefabs, Image Effects, and so on. As we saw earlier, when it comes to script compilation, these folders are also affected by that order.
Some other important things to keep in mind about the Standard Assets folder is that depending on what version of Unity that you used to create your project, the assets may or may not be the same because Standard Assets that are included when you select them for a new project are only relevant to the build of Unity that you are using. Therefore, if you update/upgrade Unity, the assets won't update along with it, and you will have to do it manually. You can do this easily by following these steps:
- Open your project
- In the Project window, right-click on Assets and then select Import Package submenu
- Select from the list the Assets that you wish to replace, and click Import
It is important to remember that when you update your assets it will replace files with the newer version. However, it will not remove obsolete files from the earlier version of the Standard Assets. For projects where you are not using all the files, you may want to consider backing up and then removing the old Standard Assets from the project before installing the updated version. This will also help to keep things clean and organized once your project gets larger and you're working with a large number of files. One thing to keep in mind, which we will discuss in a later chapter is that when we will be packaging our games, Unity has a nifty feature that only includes assets that are being used within the project. That way when your project is built it will not have any assets that aren't being used reducing the file size, among other things.
The first thing that I want you to notice is that the name of this folder is one word. This is because we have used camel casing to name the folder. Camel casing is writing words or phrases (without spaces) with each word begging with a capital letter. Often, the beginning of a camel casing name begins with a lower case letter. For example, camelCasingIsWrittenLikeThis. Of course, you can write it like so, CamelCasingIsWrittenLikeThis. Just be sure to remain consistent. Lastly, the StreamingAssets folder is the only special folder that uses camel casing, so no need to worry about the others.
What this special folder allows you is to stream an asset, such as a video, on the device. Keeping the example of the video, it will be copied as it is in the package game (and not like other assets, such as MovieTextures). As a result, you will be able to play (using streaming) that video on your device, for instance on an iOS device.
Unlike the previous folder, you can have as many Resources folders as you wish and they can be placed anywhere in your project (keep in mind that if they are sub-folder of an Editor folder, that resources will be available only to Editor Scripts). However, when you load assets from this folder, they will all be merged, and they will seem like a single folder.
What this folder allows you to do is to load assets on demand, so they are not in memory (RAM) until you explicitly load them with the Resources.Load function.
When you begin to import files into Unity, it is important to know that some files and folders are completely ignored by Unity. The reason for this is to avoid importing special and/or temporary files that are created by the operating system (for example, Windows, OSX) and other applications. The types of files and folders that are ignored are those:
- That start with '.'
- That end with '~'
- Named .cvs
- That contains the extension .tmp
By the end of this book, you will have three pretty cool projects to add to either your own portfolio or show your friends and family. Each project will build on the skills learned in the previous one. In this way, you will not only be consolidating your own skills but also adapting them to different situations—a versatile skill for anyone who truly wants to grasp game design. All the assets that we will be using are free and links will be provided to you to download all the content for each game. Here, I have included a brief description of each of these projects to give you an idea of what we will be tackling throughout the rest of this book.
Our first project is titled Angel Cakes and as you can guess there are an Angel and Cake. In this game, you will control a little angel that will navigate around the environment. Similar to Pac-Man, you will also collect little cakes in order to progress to harder and more challenging levels. There will be enemies, power-ups, and health should you need to collect it. Think of this game as an intro to the basics of setting up a 2D Unity game project.
You can download the asset package for Angel Cakes here: http://player26.com/product/angelcakes/.
Our second project will be a simple intergalactic shooter that will have us controlling a small spaceship shooting at nearby planets and enemies to score as high as possible within the time limit. It is quite arcade-like and very basic, but it will draw upon the skills that you learned from Angel Cakes while also extending on them to create more complex interaction.
You can download the asset package for Quark here: http://player26.com/product/quark/.
Our third and final game will be a platformer game titled RETROformer. In this final game, the player can collect coins, shoot enemies, and explore the environment. Essentially, this project will combine everything that you have learned previously with Angel Cakes and Quark, and build upon it. By the end of the project, you will have developed a strong understanding of what is involved in making games in different genres with different game elements and mechanics.
You can download the asset package for RETROformer here: http://player26.com/product/retroformer/
Throughout this chapter, we have explored what games are made up of and how they are developed and learned about the processes involved in making a game. From brainstorming to publishing, this chapter has provided you with a brief overview of the process of developing a game either by yourself or within a team. In addition, this chapter has shown you how to download, install, and get Unity ready for a 2D game project, while also covering some general features.
In Chapter 2, Working With Assets, we will begin using Unity to develop our first project, Angel Cakes. You will learn how to import various delectable game assets and get them ready to use and apply scripts to. So what are you waiting for, turn the page!