At last, we’ve reached the end of our first project. Let’s go over the final steps you might take when finished with a project: “building” it so that others can play it. I’ll leave you with some further ideas for features to add to the game as well.
Building the Project
Although our project is anything but a polished and pretty gem waiting to be distributed to the masses, we can still get some hands-on experience with the building of a Unity project.
We discussed this topic briefly already. Building a project converts it to a format acceptable for an end user who wants to play your game. It copies our Unity project into a set of files that can be run without the Unity editor. This is necessary if you ever want to make a game available to a base of players – you very well can’t ask them all to download the Unity editor and play your game through it, and you certainly don’t want to give out all of your code and assets to the players.
The Build Settings menu for our project, set to build for Windows
We previously learned about the top section, titled Scenes In Build. The section beneath it is where you pick the target platform to deploy to (left) and related settings (right). By default, it’s PC, Mac & Linux Standalone. The project will be deployed to a particular operating system (Windows, Mac, or Linux). This can be changed with the Target Platform field, but support for building to each operating system comes from a different Build Support module installed through the Unity Hub. If you want to build to a target platform that isn’t listed, you probably don’t have the module installed. All you have to do is go through the Unity Hub program and install the Build Support module for the operating system you want to target, which we talked about back in Chapter 1.
The remaining fields aren’t particularly relevant to the everyday user. All you should need to do is just click one of the two buttons in the bottom-right corner: Build or Build And Run, the only difference being whether or not the built project will be automatically executed when it finishes. Before building can begin, you’ll have to select a folder to store the built project in. Unity will generate the necessary files within that chosen folder.
Player Settings
The Player Settings can be accessed with the button in the bottom-left corner of the Build Settings window (shown in Figure 25-1). They can also be reached through Edit ➤ Project Settings and then by clicking the Player tab on the left.
The Resolution and Presentation section of the Player Settings
Fullscreen Mode
Defines the default display for the window. Is it fullscreen or windowed by default? If it’s windowed, it will be a movable window that is not fullscreened (not a “windowed fullscreen”).
Default Is Native Resolution
If this box is checked, the game window will use the resolution of the user’s computer by default. If you uncheck the box, two extra fields will appear, allowing you to set the default height and width of the game window yourself.
If you’ve set Fullscreen Mode to Windowed, this field won’t show.
Run In Background
Check this box if the game logic (your scripts, physics, etc.) should continue to operate even when the user minimizes the window or loses focus on it. Alternatively, if the box is unchecked, the game will pause (freeze in place) whenever the user minimizes it.
Display Resolution Dialog
This setting defines whether or not Unity shows the resolution dialog when the game starts. This is a popup box which lets the user make their own decision for the resolution when they start the game.
By default, it is Disabled. It’s recommended that you don’t rely on this feature, since Unity has deprecated it – meaning they don’t plan on supporting it in the future.
Resizable Window
If this box is checked, the window can be resized by the user clicking and dragging on the corners or edges. If it’s not checked, the window will be stuck in the default size you’ve specified.
Allow Fullscreen Switch
If checked, the user can use the default hotkey for their operating system to toggle fullscreen on or off (in Windows, this is done with Alt+Enter).
Force Single Instance
If checked, only one instance (window) of the game can be run at any time. Attempting to run a second one will simply bring focus to the already-running instance instead.
Aside from these features, there’s also the option of defining a custom splash screen. The splash screen is a sequence of graphics that pop up when the game first runs, usually showing the logo of involved companies. You’ve probably seen this in games you’ve played before. By default, your game will have a splash screen of the Unity logo, lasting a couple of seconds. If you’re using the free license of Unity, you cannot disable this – you don’t get a state-of-the-art game engine for free without giving a little credit! You can, however, add your own logos to the splash screen, customize the background color, and add a background image. Of course, this is probably not of much concern to you at this stage – but do remember that, if you want to lose the official Unity splash screen when your game runs, you have to have a paid version of Unity.
Recap
Moving with a CharacterController component.
Turning a number value from “per frame” to “per second.” If you want to move X units per second, move by “X ∗ Time.deltaTime” per frame.
Slerping and Lerping positions, rotations, and float values. This is pretty much just moving value A toward value B by a fraction of the distance between the two.
Calculating the time since an event happened. When the event first occurs, set a variable X to the current value of Time.time. Later, use “Time.time – X” to get the seconds that have passed since.
Invoking methods to run code after a specific duration has passed.
Calling the GameObject.SetActive method to activate and deactivate GameObjects through code.
Using a basic enum to depict the state of an object and changing the way they behave based on this state.
Calling the Random.Range method to generate a random value between two given numbers.
How a pivot point can affect the scaling of a Transform.
Additional Features
Now that you’ve got all this newfound experience, you can always add features to the project yourself. Thinking your way around a problem on your own is a great way to develop yourself as a programmer. Even if you bite off more than you can chew and attempt something too difficult, you’re probably going to pick up at least a few tidbits of information that make you more knowledgeable – and who knows, they might help you solve a different problem in the future.
Striking out on your own to implement a feature in a game project doesn’t mean you have to do it independently. A few Internet searches can make all the difference when it comes to solving problems or coding up new mechanics.
Getting an error message that doesn’t make sense to you? Use your favorite search engine, like Google, and type the error message out (you can even select an error in the Unity Console window and press Ctrl+C to copy the whole message). Chances are you’ll find other people making a similar mistake to the one you’ve made, asking others for help figuring it out, and there you may find your answer.
Unsure how to go about implementing something? Search for it, and so long as it’s not a particularly niche mechanic, you’ll likely be able to find a guide or tutorial for it.
Dealing with a component type you’re not used to? Search for it, and Unity’s documentation page will likely be one of your first results. You can see all of the members of any built-in class and read the descriptions for individual variables or methods. Knowing what sort of relevant data and methods are at your disposal is often one of the first steps when it comes to planning your code.
In this day and age, the information you need is probably just a couple well-chosen search terms away.
If you ever run into trouble that you can’t seem to think your way around and you can’t find a solution online, you can either set it down and come back to it when you’ve gotten better (there’s no shame in this!) or head to some online community and ask for help with your particular problem. Unity’s official question-and-answer site, located at answers.unity3d.com, is a great place for beginners to present their questions or problems so more experienced Unity users and coders can help illuminate the correct path. If you’re going to do this, be thorough. You don’t want your question to generate more questions! Describe what you’re trying to accomplish, what’s in your scene, and what’s happening that you’re trying to fix. If code is involved, copy-paste any of it that relates so others can check it for errors – particularly the subtle ones you may not have noticed.
Sometimes, the act of trying to describe your problem with enough detail that someone else may be able to solve it for you is enough to help you realize what’s going wrong. One day, you’ll realize you’ve gotten so good that you don’t need other people’s help. You’re good enough at finding the answer yourself that you solve the hurdles before you ever hit the point of asking for help. Or perhaps the problems you face will be deep enough that properly explaining them so others can help is more trouble than figuring it out yourself.
Teleportation
Two teleporter pads are placed on the ground at different locations. Touch either one, and you’ll get warped to the location of the other one. Use an Inspector reference to the Transform of the other teleporter pad to link them together. That way you can move them around – even in-game – and it’ll still work.
Fancy shooters
Make Shooters with multiple barrels sticking out in different directions, all of them firing at the same rate. Create shooters that are constantly spinning. Mix the two for much more daunting obstacles.
Checkpoints
Larger levels can have checkpoints spread throughout them. When the player touches the checkpoint, they unlock it, making it the current checkpoint. Whenever they die, they respawn at the current checkpoint (if they have one unlocked). Just make sure the player can’t go back and unlock a worse checkpoint by touching it again!
Lives
Give the player a limited number of lives. Whenever they die, take a life away. If they run out of lives, kick them back to the main menu and make them feel bad by telling them they’re a loser. This way, they can lose their progress earned by reaching new checkpoints. Consider also rewarding them with more lives when they reach a new checkpoint.
If you’re tired of doing what I say, don’t be afraid to try to implement something that you think would be fun or interesting. You might fail and never get it done. It happens sometimes. But you’ll learn in the process.
Or just keep following the book and save that for after!
Summary
In this chapter, we’ve handled some loose ends, leaving us ready to set aside our first example project and move on to the next. We learned how to use the Build Settings window to build our project, and we learned about the Player Settings window, which contains properties relating to the appearance and behavior of our project once it is built.
Next, we’ll move on to a project that will give you plenty of practice working with object-oriented programming concepts like inheritance.