Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
When we're getting close to completing our game, we can actually make a build of that game, and a build then, is a calculation of everything in the game to produce a standalone executable. This may be a standalone app for a phone or a standalone for Web or PC. You should know your platform going in. It shouldn't come as a surprise that suddenly you're offering for iOS, for example. But you can always go and change if you need, and Unity has a lot of great things along the way to facilitate developing for multiple platforms. I'll produce a development build to start and this'll let me pull up a debugger and a profiler to watch out for any other warnings or show stopping errors.
I'll choose File and Build & Run. In Build & Run then, I can choose a platform building towards iOS, Android, Blackberry and so on. I'm going to build mine for PC, Mac, and Linux as that's where I've directed all my textures to go to and I haven't used any overrides for anything in here. I'll check Development Build, and then I'll check Auto Connect Profiler and Script Debugging. Now when I go to build this, it'll pull up a profiler which is a pro version only, and show me where my resources are going.
It'll also help me debug any scripts along the way, flagging any errors in my code, so I can run the game correctly. In our architecture then, we can specify a target platform. In this case because I'm working on a PC, I can't develop for Mac OS. If you're working on a Mac, you can develop for Mac OS and the same with iPhone. I'm going to build for the x86 architecture. But we do have an option in here to do x86 64, if we'd like. I'll press Build and Run, and what it's going to do is take the current player settings, build the game, and then open it up, running in the Unity player.
When I click Build and Run, it wants to make an EXE, an executable for Windows. I'll name this for a testing build, so in case I see it in my directory later, I can delete it, because it's just a working build of the game. I'll name it Modernistatest, and I'll make a new folder that this is built into. It'll go into a folder I've called Debug Builds. And this way, I can be careful about version I'm actually putting out there for consumption. I'll click Save, and Unity will take a minute, compile the scripts, and build the game. The build came up and opened up the Profiler. What I can see in here is that I haven't specified a splash screen yet, and it's at the default quality of Good.
My screen resolution came across and it's going to play windowed. I can also see in the Input tab that it's just the standard WASD inputs, that is, the standard keys for jumping around, firing, moving, and so on. We can always get in and change if we need, and we can lock these if we'd like. Back here in the Graphics, I'll try the Graphics Quality at Fantastic, the most it can go, and see how it looks. I'll press Play, and I'll watch that debugger as well. With my build open, it looks really good. I can see in here that the anti aliasing I've specked looked fantastic.
I've got a development build going, and it looks really nice. All the work I put into the lighting and the shading is really coming across well. I'll move forward, knock over my sculpture, and go out the doors. Finally bumbling around like a player, I found the right door to get out.
I can hear the water, and see the water in front of me. The shallow depth helps me focus on the railing, and that background is blurred. Looking down, I can see the detail on the railing, and a little bit of that Q map moving in the middle. I knocked over the painting. I can see some areas I'd like to fix, like the clipping plane and the collision on that player collider. I went into the painting a little bit. That's an easy fix, though. I can go back in and fix the size of that so that as I go forward, I can't quite pass through objects.
The ambient occlusion looks good. There's some minor issues with the bottom of the wall texture, but I can take care of that quickly in some mapping. The screens are holding up well, not too much of a Moire pattern, and the lighting looks really good in the space. I'll close that build and what I can see here in the Profiler is my usage and my frame rate. I'm hitting a frame rate roughly of 30 frames per second, and getting reasonably close occasionally and a little bit under. This definitely tells me I've got places where I can optimize, where I really need to streamline what it is we're seeing. It's neat, though, because I can see where my rendering and draw calls are, depending on how much I've seen, that is, how far away I'm looking.
I can also see in here that I'm probably taking a big hit in the draw calls from those image effects. And so if there's any way to optimize them down, maybe going through and color balancing out all of the different colors, I should, and see if there's any of those I can take off. I should also see if there's any optimization I can do along the way, in terms of either geometry or textures. And this provides a really nice graph of where are we using that processing power. So far, it looks like my scripts are working. There weren't any errors popping up, although this is not terrible intensive on the scripting.
As you get farther and farther into your scripting, you'll find more and more places where that debugger is really helpful. Flagging areas where scripts are in conflict, either in their ordering running, or in the syntax, and you can go in and find and fix those before you publish your game. So you make a development build, look at the Profiler, look at the script, and really read what those consoles and debuggers and graphs are showing you. Because it will help you streamline your game, so you can play as smoothly as possible.
Get unlimited access to all courses for just $25/month.Become a member
107 Video lessons · 31755 Viewers
90 Video lessons · 21991 Viewers
78 Video lessons · 8098 Viewers
83 Video lessons · 7765 Viewers