You probably recall that Unity lets you build your product for a wide variety of platforms. We'll take a look at building for different platforms in a moment, but before you build the project, you should pay attention to relative project settings that determine a lot of the core settings that impact how the game looks and plays once it's built. The first thing you want to do is look at the Project Settings in Edit, Project Settings. First thing we will look at is quality settings. Here you can adjust the quality settings. If you don't want your game stripped of certain quality elements, you can disable the lower settings. In most cases it doesn't matter, in our project it doesn't. It would be more important for things like textures. In some cases, it might actually have an impact, but not in ours. We have also have vsync.
Vsync and the quality settings really has to do with the framerate that your game is running on, and how it adapts and runs at lower settings or lower framerates. In the player settings, here the most important thing is setting the resolutions, aspect ratios and so on. You can handle that all here in the resolutions dialog. This would be the actual platform you are going to be building to. Obviously, the considerations for resolution settings and all that kind of stuff should be relative to the platform you're building on. That probably should be determined before you are actually ready to build the project. That should be one of the first considerations, actually, as it would really impact how the game looks on the device that you end up building to. Here we also have whether or not, for the PC settings, whether or not you can run it windowed or full-screen. For our build, what I'm going to do is make sure it runs at 1280x720. 720p of course. Supported Aspect Ratio 720p is 16:9.
We'll only allow it to be supported on that aspect ratio. That's all we will worry about here. You can add icons for your executable that ends up getting built as well as a splash image. There is a few other settings if you have more complex stuff to worry about in your game, which we don't. For Project Settings, we'll also look at script execution order. Script execution is something you will want to keep in mind. We talked about this a bit in the lesson to do with LateUpdate() and camera movement. To resolve when one script depends on the values of another script and that other script hasn't yet run, you just determine this in the script execution order. Chances are, you already have looked at this before you are ready to build the project. Audio, this is a section you might be interested in. Here we can solve audio issues at the project level. One issue we might see is in our project is too many voices, as they are called here, which basically is those sound clips playing at once. When the CrowdCheer audio clip is played. This voice gets multiplied with every Enemy that comes close to our Cube.
That can result in audio dropouts, unless we have enough voices to handle the clips. There are all sorts of ways to fix that in code. If you can spare audio processing, you can probably resolve it by increasing the max available virtual and real voices here. I'm not really going to worry about that in our project. You should just be aware of that as an option. A lot of these other settings are not relevant to our project either. If you have network settings or certain shaders here if you have all sorts of shaders in your game. There is physics stuff if you have physics employed in your game. We don't, again. These are also settings you are going to want to pay attention to before you build your final project. Finally, to build a project, what you want to do is go to build settings. Here you have the different platforms that you can build to. For our case, it will just be the PC, Mac, Linux standalone. There used to be some decent support for the web player, but I think recently it has been more or less dropped.
I think few browsers don't really support it anymore. I don't think Unity is likely to likely to want to support it going forward. Unfortunately, that's not really much of an option going forward, but you can try that out. In most cases, you're just going to want to build an executable, an .exe file in other words. For here, all you do is just put those player settings that we determined previously. You can look them over once again, and basically just build the project. When you build a project, it will just build to a folder created in the .exe file and a folder that holds all the data. You can launch it and play the game, you can send it off to other people for them to play on their end. It's a little bit more complicated to run the game at fullscreen for a variety of issues. I think the best thing to do is run the game windowed. Take a look at the graphic settings and set the resolution according to your monitor to make sure it's set properly.
Hopefully on your end, you have a monitor with the right form factor, and it stretches according. Here you see that you also have the input manager popup. It allows you to reassign the inputs for your game controller or what have you. Probably the most important consideration when building your game is the way it adapts to different resolutions. The choices that you make in this regard should probably precede development of the entire project itself. In other words, you should be creating your game with the different platforms that you think it will be published on in mind. Not only that, but you have to consider the style of game, the intended platforms, their resolutions, whether you want the game running windowed mode or full screen, whether things should scale, and so on. These are all kinds of things that you should be thinking about. Our game was made at a fixed 1280x720p resolution. Fixed resolutions are good for old-school 2D games because unlike 3D games, it's probably not a good idea to let the user see more of the world if they had larger monitors or, indeed, see less if the are smaller devices.
In most cases, the idea is that these kind of 2D games should have a fixed resolution that compresses and stretches, sort of like resizing an image in a photo editing app, in order to adapt to the resolution of the device they are running on. The native resolution should always be whatever the game was made in. Again, our game is in 720p, which the has the appearance of a lower resolution, just because of the pixelated graphics we chose. If we run this game in windowed mode, it will do just this. It will stretch and compress the window size and fill to the window size. Another option is to scale all the objects in the game relative to the screen size. You will have different sized objects at high resolutions that uses those assets rather than the smaller ones. That option might be better if you are publishing to mobile devices which have all sorts of screen sizes which aren't always uniform. Unfortunately, there are just too many possibilities to do this particular topic, resolution, screen sizes, adaptation, and so on, justice and not go off on a wild tangent. Just so you know, you should be aware of this when you endeavoring on your own project and keep that in mind. Look up the solutions to whatever might best fit your game that you are developing. That's it for this project. The entire project is pretty much behind us. Onto a new project, a scrolling platformer which uses the Unity physics engine, and I will see you there.
Lesson 52 - Final Build and Project Settings