This is part one of a series on learning to make games with Unity. I will be attempting to put this through to an intermediate level. In order to understand this guide I will expect that you understand fairly advanced operating system ideas. Like I should be able to tell you to install something somewhere and through your own knowledge / Google find out how. As well I will assume you are somewhat familiar with what a game is and why one would make one. Unity is a very powerful tool for developers and artists a like. You will not need either skills for this tutorial but again you need to know what a developer does and what an artist does. I will show you how both can use unity as well. Giving an overview of the graphic components and scripting components.
Gettin Unity Installed
First things first is we gotta get unity installed. Go to that link and grab unity. Start the download now because it is massive.
In a weeks time when you have it finished we can begin ;). Go through the install setup, putting it anywhere you want I’m not aware of it being overly picky like some programs can be.
Creating A Project
Once this is done we will need to begin. So now we need to create a project. When you first open unity it will present you with the unity Project Create Wizard. Go to the “Create New Project” tab and you will see a project location text box. This is the place for your new game and the title of the project will be based on what is put in at the end. Replace “New Unity Project” with your working title.
Next there is a big intimidating box of check boxes we can totally ignore for now.
Ok defaults, I’m gonna level with you and say I work in 2D almost exclusively. Its almost purely because 3D is more complicated. Why is it more complicated? Orders of magnitude. Any concept in a 2D environment will be limited to 2 dimensions. Which is x * y. When you add the third dimension you add an order of magnitude to the concept of the game. This is not bad but just conceptually harder. When trying to do the math on games I get frustrated easily so I stick to 2 dimensions because I can literally picture it better. So you can go either or but I’m going to stick to 2D for the tutorial. The differences are minor though and if you go with 3D it should mostly be the same.
Anyways hit create project and it should g-g-go.
You will be presented with unity. Maybe some pop up, I can’t remember but make it go away and get to the program.
What is a “Scene”. Unity first look
This is the main hub of making the game but you should not think you are looking at a pulled out view of your game. Unity breaks things up into “scenes” which are isolated areas of game play. At no point in unity are you pulled out to look at how all the scenes fit together. Instead unity is like a scene editor and when you finish one you can direct it over to the next one.
So very early on you want to start thinking about your game in this structure, because if you are going to do it in unity then that’s how its broken up.
What this allows us to do is to group things into concepts in the game. So you might have a scene for your opening credit and splash shit. Then a scene for the intro. Then a scene for the main menu, then from there branching into other scenes as the player picks them.
You may have 6-8 scenes in a game and 1 of them is just way way bigger because its most of the game.
In order to work well with a development environment you need to make your designs match the designs of the environment. This is why I am stressing scenes now, if you do not design your game with scenes in mind then it will be confusing when you need to work within that structure. Plus you may try and do concepts (switching game states) that are just so much better done with scenes. Anytime the entire gameplay method changes its probably a scene change.
Gameobjects and Prefabs
The second thing to keep in mind with unity is that it works with an Object component model. If you are familiar with object oriented programming I would like to make a mention here. If you aren’t skip to the next paragraph because this may just complicated things for you. OOP is about hierarchies and inheritance. Objects only gain functionality because they have it or their parents have it. So you design things by abstracting them out to their base classes and adding functionality as it becomes less and less abstract. Animal, to mammal, to ape, to human kinda idea. Now unity uses a slightly different model and if you go in thinking oop you are gonna be like… oops (OMFG HAHAHAHAHAHAHA). The component model means that every “object” is just a shell of a very basic function. I’ll explain more later about it but the gameobject can be viewed like a gameobject base class. Its the thing that is also everything deep down. You don’t create your structure from inheritance though. Instead you give it a component. So instead of a dog getting the ability to bark because its parent class has the function “make sound”. You would create a component (script most likely) that would play another component (an audio source). The sound is then an argument to be filled in later. So if you wanted to make an “animal” class so you could have cats, dogs, sheep, cows. All with similar attributes but different sounds you could make an “animal” component that would give them a basic set of data. It could call the “make sound” component too though so each animal would walk around the same but make their different noises. Additionally its easy to adapt for a lack of component and if we had a “rabbit” object that had an animal component and no make sound component its easy to adapt for that by doing a small check at some point. So instead of thinking of things like a tree think of it like a power bar. You can really plug things in freely and create this crazy components. Its a bit of a wild west I would think if you don’t maintain some sort of personal organization, far less structured then oop and you have to keep that in mind.
Ok so I’m going to try and explain at a fairly high level what the basic structure for unity is. Like what you are “making” to make the game. In Unity there are scenes as I have explained before. Scenes are like universes. Inside each universe is its own collection of physics and objects. The objects in unity are called gameobjects. All of the game objects for the scene show up in a menu called the “hierarchy”. This is how the objects are organized, this is done in a nested structure. Like how folders are nested. Each gameobject has something called the “transform” which is a representation of its place in space. So the position, scale and rotation. These gameobjects and space nest properly. Nesting is done with parents. So a gameobject with a parent will move with their parent, scale with their parent and rotate with their parent. Later on it becomes important for all sorts of things. However we know that game objects need to be structured like this so I will try and show you how to mentally visualize your game as gameobjects.
Gameobjects allow structure to be enforced on the objects in your universe. So if you have a spaceship with a gun but want to change the gun then you need 2 objects. The spaceship and the gun. The gun does not fly and is dependent on the spaceship for everything about where it is. So the spaceship owns the gun, otherwise when the ship moved the gun would just stay. Now we need the gun object because sometimes it might be a different type of gun, like you get an upgrade. Additionally the gun can have its own local rotation so it can move relative to the ship. So we need to know both the rotation of the ship and gun. If we only had the ship object then we would need to do a lot of complicated math to add a gun that you could aim independent of the ship. Unity allows you to set all of that up instantly by using the hierarchy like this. So if two objects move independent of each other they are likely not owned by each other. If one objects position is dependent on another then they are likely supposed to be parent/child. This of course is different than 2 objects causing each other to move because of physics as in a collision. We are trying to conceptualize our game as a hierarchy. You want objects that are independent of each other to not share immediate parents and then establish relationships for close knit objects. You may have a “world” object for instance that all enemies and players are children of. This makes sense if they all depend on the world. Try and find what order things should be owned. Body > Arm > Upper Arm > forearm > hand > finger etc etc. Each part is dependent on its position in the world by its parent and should be grouped as such.
Its also good to structure less physical things into the right gameobjects. You may need non visual concepts in your game as well. Something that keeps track of a score for instance. You need to house this code in a gameobject, it will have a position but its not really relevant. Still if things make sense to have a logical hierarchy it makes sense to structure it that way as well. When you delete a gameobject all of its children are deleted as well. So for modular design (which is generally awesome) we encourage always grouping things into nice hierarchies. It may be tempting to not but if you are strict about it then your objects have a lot of integrity which is proper and shit.
Prefabs are short hand for “prefabricated objects”. Once you have designed an object and added all of the components (discussed below). You can save it by dragging it from the hierarchy window to the project window. It will change color indicating it is no longer a scene gameobject but a prefab.
Prefabs can be based off of each other with different component variables. Maybe you have 2 enemies that look and act similar but slightly differemt. You can make them share all the same components and be identical except for the few changes they need. Since they share the same components there is still a relationship in similarity but you can also build structure by making prefabricated objects.
So that is almost all of the structure of a unity game we just have one thing left which is where the variety really comes in: Components.
You may notice that the structure of unity is pretty much just things inside things inside things inside things. Scenes are in your project and gameobjects are in your scenes and components are in your gameobjects!
Components describe what a gameobject is. You could add a camera component to it for instance and now your object is a basic object and a camera. If you wrote a script that made the position of the transform move up every frame then suddenly we would have a moving camera! Add a sprite renderer with a sprite of a ship and boom we got a ship with a camera attached. From there we could do the smart thing and make the camera another gameobject that has a script to track the ship.
The components are all of those different functions and I don’t wanna undersell how powerful this is. This makes it super easy to structure your game. Picture components like grammar for objects. The gameobject by itself is like a formless idea. You use components to express what it is. “It walks” because it has a movement component. “It looks like a bug” because it has a sprite renderer and with a bug sprite. “It gets squished” because it has a set of physical geometry that can be compared to other objects in the world, also because it has a health component that gets decreased upon the geometry being entered. Think about what your object does and figure out what components can be made to make it do that.
Its About Structure
Anytime you create anything you are going to need to work within the tools you are using. The paintbrush is not an obstacle standing between you and expressing your ideas clearer. It is only through proper understanding of tool selection that you can make the brush strokes you want. Learning how the components of your medium works and going with it instead of against it.
Unity will force you into things, it will make you structure your game in certain ways. These restrictions are the trade off for gaining the power that it has. So the very first thing anyone must do when wanting to use unity to create a game is adapt your games structure to how unity works. Try thinking about how you would implement classic games in this structure. Hell give it a shot. Try and break tetris down into unity. Even if you don’t write any code, or draw anything. Just think about how you would structure Tetris into scenes, prefabs and the components in them.
Once you know how to structure the game for unity its way less intimidating and frustrating to work with it. You understand how your tool works. If you approach painting for instance wanting to do all sorts of fancy things with one horse hair brush you will be frustrated. Sure maybe with enough work you can do it but there are different brushes for a reason, because what structure you put into the process is important. You can’t create something with a tool if you don’t understand how its supposed to accomplish what it was designed for.
Games in unity require you to turn your designs into a unity structure. Its not good or bad its just how we need to think about our designs to begin.