Unity 2017 2D Game Development Projects

5 (2 reviews total)
By Lauren S. Ferro , Francesco Sapio
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Press Start

About this book

2D games are everywhere! Timeless and popular, 2D games represent a substantial segment of the games market. The Unity engine has revolutionized the gaming industry, by making it easier for game developers to create quality games on a budget. If you are looking for a guide to create 2D games using Unity 2017, look no further. With this book, you will learn all the essentials of 2D game development by creating three epic games in a step-by-step manner throughout the course of this book.

The first game will have you collecting as many cakes as possible. The second will transport you to outer space to traverse as far as possible while avoiding enemy spaceships. The last game will have you running and jumping across platforms to collect coins and other exotic items.

Throughout all these three games, you will create characters, make them move, and create some enemies. And then, of course, write code to destroy them!. After showing you the necessities of creating a game, this book will then help you to porting the game to a mobile platform, and provide a path to publish it on the stores.

By the end of this book, you will not only have created three complete great games, but be able to apply your knowledge to create and deploy your own games.

Publication date:
January 2018
Publisher
Packt
Pages
338
ISBN
9781786460271

 

Chapter 1. Press Start

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. 

 

Atoms of games


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. 

Note

When you're playing games, think about things that you are receiving during gameplay and how you get them. By being a bit more conscious during your own experiences and reflecting on them, you not only develop an awareness of the "reactions" that certain game elements and mechanics afford, it also provides you with a way to consider implementing these into your own games. As a result, you will learn how different combinations create different outcomes.

 

Different approaches to games


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).

Note

If you want to learn all about gamification in Unity, I encourage you to have a look at Gamification with Unity 5.x. You can get an eBook or hardcopy version by going to the following link or scanning the QR code: https://www.packtpub.com/game-development/gamification-unity-5x.https://www.packtpub.com/game-development/gamification-unity-5x

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.

 

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.

Workflow

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. 

Concept development

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?

Note

Unfortunately, we won't be covering this stage in the book, as everything that we will be using in our projects is pre-made. However, what I do encourage you to do is that after you have learned about the projects that we will be doing in this book, brainstorm your own version of them. Instead of Angel Cakes (project 1), develop something that is to do with zombies or even fish! By doing this, you will be able to practice the first stage of game development and develop your brainstorming and conceptualization of game ideas.

Design and prototyping

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. 

Note

Since we won't be actively designing or prototyping the games in this book, you might want to think about how you would prototype them. One way to do this is to redesign them with your own ideas and then refine them through the design and prototype stage so that you can get a better understanding of this process.

Implementation

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. 

Testing

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.

Iteration

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!

Finalizing

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.

A-Team

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.

Note

There are many game developers that post information "behind the scenes" of how their games are developed. These sometimes include commentary and interviews with various members of their team. A lot of these videos touch on the challenges that they face during the development of their game and in some cases the heartache of not being able to complete certain features or the game at all. I encourage you to check them out. There is one about the Making of Assassin's Creed Unity you can watch by visiting this link or scanning the QR code https://www.youtube.com/watch?v=3OjVQBpQSEU:https://www.youtube.com/watch?v=3OjVQBpQSEU

 

Developing 2D games


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.

X, Y, and Z-axis

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.

Full 3D

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.

Screenshot of Assassin's Creed

Orthographic (3D)

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. 

Screenshot of Monument Valley

2D with 3D graphics, also known as 2.5D

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. 

Screenshot of New'n'Tasty

Full 2D

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.

Screenshot of Pac Man

2D with a perspective camera

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.

 

The Unity Engine


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.

Downloading Unity

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.

Note

If you choose to download Unity 2018 Beta, it should not affect anything that you will do in this book. However, it is possible that some things will be slightly different than they are presented here. Please keep this in mind when deciding on which version to download. For this book, we are going to use the latest stable version at the time of writing.

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.

Note

While this book aims to teach you the basics of 2D game development, I encourage you to check out these four things (all available on the official website):

  1. Tutorials https://unity3d.com/learn/tutorials
  2. Documentation https://docs.unity3d.com/2017.3/Documentation/Manual/
  3. Community https://unity3d.com/community
  4. Social (for example, Twitter, Facebook groups, and so on)

Not only will you be able to explore a lot of the added 2D (and 3D) options that Unity offers, which aren’t covered here, you can also learn about them through their own tutorials. Lastly, I highly encourage you to become part of the Unity Community and engage with their social media. In this way, you will be able to connect with other Unity game developers while at the same time being up to date with the latest news and be immersed in a great platform for you to share your own projects and questions with other game developers.

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.

Note

More detailed information can be found here: https://unity3d.com/unity/activation/personal or by scanning the following QR code.

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):

(left) The Survival Shooter tutorial that Unity offers. (right) The tutorial as viewed within Unity itself.

 

An overview of built-in features in Unity


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. 

Creating a new 2D project in Unity

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.

A brief overview of the Unity User Interface (UI)

Unity will begin setting up the project and once it's completed, you will see a screen like this:

This is an example of the Unity UI once you open Unity. As you can see there are no project files at this stage. 

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.

The main components of the UI in Unity

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.

Hierarchy Window

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.

Scene View

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.

Game View

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:

Inspector window

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:

Console window

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:

Project Window

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:

In this image, you can see the various Sprites that have been cut from the Sprite Sheet for Angel Cakes.

Customizing the workspace

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. 

Hotkeys to keep in mind

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:

Tools

 

Keystroke

Command

Q

Pan

W

Move

E

Rotate

R

Scale

T

Rect Tool

Z

Pivot Mode toggle

X

Pivot Rotation Toggle

V

Vertex Snap

Ctrl/command + LMB

Snap

GameObject

 

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

Window

 

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

Asset Workflow

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.

Primitive and placeholder objects

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:

In the image above, you can see an example of each type of primitive/placeholder objects within Unity, along with their pivot point (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: 

Images

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.

Note

If you save your layered Photoshop (.psd) files into your Assets folder, they will be imported as flattened images. This means that you cannot access the layers directly within Unity. If you need to make changes to a layer within your .psd file, you will need to do so within Photoshop.

3D model files

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).

Meshes and animations

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:

Audio files

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.

Naming conventions for assets (and in general)

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.

Importing into Unity

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.htmlor by scanning the QR code:

Special folders

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 UnityProject window would look like if you have created all the special folders.

Image of the special folders setup

Assets

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.

Editor

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 default resources

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.

Note

You can only have one Editor Default Resources folder within a Unity Project. This folder must be placed in the root of the Project directly in the Assets folder. 

Plugins

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.

Note

These plugins are usually platform-depend (Win, Linux, Mac, Android, iOS, WP, and so on) and might be written with glue-code to allow calling specific OS level functions (APIs) that Unity doesn't provide access to through its classes. Those plugins are oftentimes also written in different programming languages like C/C++, Obj-C, C#, Java, and so on Moreover, the plugins folder allows differentiating between platforms by adding sub-folders per platform: x86, x86_64, Android, iOS, and so on.

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.

Note

Like many other types of folders, you can only have one Plugins folder and it must be placed in the Assets folder. You can refer to the screenshot at the beginning of this section to see this in action.

Gizmos

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:

Gizmo menu

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.

Note

Like many of the other special folders, you can only have one Gizmos folder and it must be directly within the Assets folder.

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):

Example of Gizmos within Unity

Standard Assets

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.

Note

It is important to remember that you can only have one Standard Assets folder. In addition, any subfolders that it contains will also need to be placed inside of the Assets folder.

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:

  1. Open your project
  2. In the Project window, right-click on Assets and then select Import Package submenu
  3. 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.

StreamingAssets folder

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.

Note

It is important to remember that you can have only one StreamingAssets folder. This folder must be located in the Asset folder, along with any additional subfolders that it contains. 

Resources

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.

Hidden Assets

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
 

Preparing for the projects in this book


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.

Project 1 - Angel Cakes

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/.

Project 2 - intergalactic shooter: Quark

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/.

Project 3 - RETROformer

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/

 

Summary


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!

About the Authors

  • Lauren S. Ferro

    Lauren S. Ferro has a Ph.D. in player profiling and modeling. She is currently an Adjunct Professor and researcher at Sapienza University, in Rome. Lauren is also the co-organizer of the Unreal Engine Meetup in Rome. In addition, she created the game design resource, Gamicards, which is a prototyping tool for game experiences. At heart, she is intrigued by how we interact with the world and those in it.

    Browse publications by this author
  • Francesco Sapio

    Francesco Sapio received his Master of Science in Engineering in Artificial Intelligence and Robotics degree from Sapienza University, Rome, Italy, a couple of semesters in advance, graduating with summa cum laude; he is currently a researcher at the same university.

    He is an Unreal and Unity 3D expert, skilled game designer, and an experienced user of major graphics programs. He helped the development of many games (both educational and commercial). He is also an active writer on the topic of game development.

    Finally, Francesco loves math, philosophy, logic, and puzzle solving, but most of all, creating video games—thanks to his passion for game designing and programming.

    Browse publications by this author

Latest Reviews

(2 reviews total)
I cannot fault your service in any way.
okokokokokokokokokokokokok

Recommended For You

Unity 2018 Cookbook - Third Edition

Develop quality game components and solve common gameplay problems with various game design patterns

By Matt Smith
Learning C# by Developing Games with Unity 2019 - Fourth Edition

Understand the fundamentals of C# programming and get started with coding from ground up in an engaging and practical manner

By Harrison Ferrone
2D Game Programming in Unity [Video]

Get in-depth knowledge of developing exciting 2D Games with Unity.

By Dr. Ashley Godbold
Hands-On Game Development Patterns with Unity 2019

Write maintainable, fault-tolerant, and cleaner game codes by understanding the standard development patterns and battle-tested practices.

By David Baron