Well, we've filed and buffed our game to shape it into a masterpiece, it's now time to add some shine. To make our gem shine, we need to polish it up with a few things to make it work better, as well as ensure that it will work as we want it to. By now, you should have already tested it (more than once), so you will have a few ideas about what needs to be improved, such as lag. In the following sections, we will explore ways to optimize various parts of the game so that by the time you publish it, you will have something that runs smoothly and effectively.
One thing that you will want to make sure to do before you really get stuck into the development of your game is to determine whether or not it is optimized for the device(s) that you are targeting it towards. Often optimization is seen as the last step in game development, but it is not true. The sooner you consider optimization in your development workflow, the less the effort required later on to optimize your game.
Note
Unity provides great resources for optimizing for mobile platforms such as specific optimizations such as script and graphics. You can find them here: https://docs.unity3d.com/Manual/MobileOptimizationPracticalGuide.html.
Different devices come with their own issues that you need to overcome. Just like our own brains, mobile devices (and computers in general) can process so much at any one time. As a result, this will ultimately impact the overall performance of your game. For example, certain parts such as graphics (both 2D and 3D), or just inefficient code can be extremely draining. Ultimately, this will impact the running of your game, causing it to lag. In addition to the device, depending on what dimension that you designed in (2D or 3D) will require different considerations, of which we are going to explore in the following sections.
One of the many things you you need to take into account, is the dimension of your game, especially since it will impact how it will be distributed and/or released. Thus, checking how the size of your build is key in understanding the dimensions of your game. You can just build the game (how to do it, it's explained later in the chapter), and check its size. However, this doesn't give us much information on what we could reduce.
After you have built the game, you can right-click on the Console window and then select Open Editor Log, as shown in the following screenshot:
Your operating system will open the Editor.txt file with your default text editor; near the end, you can find some statistics about your last build, and in particular the size divided by the different elements of your game. You should have something similar to this:
There are details related to individual files (only a fragment is shown) as follows:
As you can see, most of our game size is taken by Textures, which is common in 2D games. Let's explore how we can reduce the size of the textures in the following section.
Some image formats can be problematic, such as file size. Thankfully, in Unity you can reduce the file size in a number of ways:
- Change the image resolution.
- Change how Unity will handle that specific image.
In Unity, you can change these in the importing settings. To do this, just select an Asset from your Project folder, and the following screen will appear:
In the past chapters, we explained some of these settings, mainly the ones related to the game. But as you can see from the preceding screenshot, there are many other options to set the texture in perfect conditions for your game.
Tip
As you can see from the previous screenshot, there is a warning about POT textures. What are those? Power Of Two (POT) textures are squared images in which the length of the side is a power of 2 (such as 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4092, and so on). Since the hardware we have, runs with a binary system, the power of 2 is really important, because some techniques allow it to be processed in a certain way. As a result, performance can improve. In the specific case of the warning, to be compressed into DXT5 format. Therefore, although it's hard to have all the textures of your game as POT textures, you should consider having as many as you can.
As you can read from the previous screenshot, our Panda sprite sheet is an NPOT (Non-Power-Of-Two) texture, because this sprite sheet was designed for clarity to learn animations back in Chapter 4, No Longer Alone – Sweet-Toothed Pandas Strike, and not to be optimized.
To improve the performance of your game, the most important parameters are: Generate Mip Maps, Filter Mode, Max Size, Compression, and Format. To make it easier to understand, they have been highlighted in the previous screenshot:
- Generate Mip Maps: It is an option that, if checked, creates smaller versions of the texture/sprite. Therefore, when the sprite is far or small with respect to the camera, the smaller version is rendered. As a result, there is a gain performance at runtime, but it could increase the size of your build.
- Filter Mode: It allows you to apply a filter to the image, in particular to make the borders a little blurry. It might be useful, when working with pixel art, to have some filters can be handy. This is because filter makes your asset less pixelated. Filter Mode selects how the texture is filtered when it gets stretched by transformations:
- Point: The texture becomes blocky up close
- Bilinear: The texture becomes blurry up close
- Trilinear: This is like Bilinear, but the texture also blurs between the different mip levels
- Max Size: As the name suggests, places a limit on the maximum size that the image can have within that specific platform. In fact, while it may be ideal to have hi-res pictures or graphics to enhance the experience, it is not not the best for an application in terms of performance. This option allows you to drastically reduce your build size, in case you have problems with it, at the cost of quality.
- Compression and Format: Specify whether or not the image will be compressed when the game will be compiled/built. It is important to remember, that if your target device is a particular platform, or really old, it is possible that it might not be able to support some compression formats. Again, there is a trade-off between quality and performance.
When creating your games, optimization will become a difficult process, especially if you have waited until the last minute to worry about it. One of the main issues (at least in 3D games) is polycounts, which are the number of faces that your 3D assets have. For instance, if you think of a cube, each face is a polygon, and therefore a cube would have a total of six polygons (some graphic cards don't support quads, and so the six faces of the cube should be split into two triangles each, resulting in a total of 12 polygons). In saying this, it is the cumulative total that needs to be kept into consideration. Get it too low and you are going to have a game that looks relatively blocky; too much and it's likely (especially for mobile devices) to lag. To check the polycount inside your Unity scene, head to the top-right hand corner of the Game view, and check the Stats option, as highlighted in this image:
To get a better idea of how you should model, in the User Manual for Unity, there is a page that explains how to model assets and characters in order for them to be optimized. You can read it here: http://polycount.com/discussion/130371/polygon-count-for-smartphone-applications.
Once you have done this, a popup as shown in the next screenshot should appear. The statistics in this popup shows you information related to the performance of different things, such as draw calls. In addition, it also indicates how many polygons are present in your current view of the scene. In fact, one of the great advantages of this Stats screen is that you can use it in real time when you press play so that you can observe which parts of your games are more resource heavy than others (we mentioned this back in Chapter 2, Baking Cupcake Towers):
The most important parameters to check (highlighted in the screenshot) are:
- FPS (Frames-Per-Seconds): As the name suggests, this shows how many frames your game can produce per second. Of course, this value could change drastically between different devices and/or computers depending on their hardware. You should ensure that your game is able to run at least at 50/60 FPS on each one of your target platforms.
- Tris (Triangles) and Verts (Vertices): They indicate how many triangles and vertices are rendered in the current frame from the active cameras (more than one camera might be active). Especially in 3D games, this is crucial. The more the Tris and Verts, the more details you can include, but it's at the cost of performance.
- SetPass calls: This indicates how many iterations Unity needs to go through to render that specific frame. You should do everything you can to try to reduce this number. The smaller the number of iterations, the faster Unity will render that specific frame, and hence increasing your FPS.
If you need more sophisticated statistics about the use of resources in your game, you can access the Profiler by navigating through Window | Profiler from the top menu bar. You should have a screen like the following:
The window has been stretched vertically in order to show you as many categories as possible. However, since the empty spaces will be filled up with graphs and the different parts of your game, the profiling window should be enlarged as much as possible. If you have a dual monitor setup, consider placing the profiling window in your second monitor.
This powerful tool allows you to monitor in detail how the different components of your game use resources. The Profiler helps you to optimize your game by analyzing the performance of the GPU, CPU, memory, rendering, and audio. Therefore, you can have an idea of how much computational power is spent in the different areas of your game. For example, you might want to know the percentage of time spent rendering, animating, or even in your game logic.
Note
You can find more about the Profiler in the official documentation (https://docs.unity3d.com/Manual/Profiler.html) or in a video tutorial from the official website at https://unity3d.com/learn/tutorials/topics/interface-essentials/introduction-profiler.
In addition, you can do remote profiling as well; on https://docs.unity3d.com/Manual/ProfilerWindow.html, towards the end, you will find a section named Remote profiling. It explains how to do it based on the platform you want to remote profile.
Another option to optimize your game is to limit the amount of materials (which is the way that Unity can apply a shader on a game object) on 3D assets. For example, sometimes you can apply many different materials (and maps) to an object to give it a range of cool effects; however, less is more. For games that are played on computer or console, this is not a big issue, but one that needs to be considered. For games on mobile devices, it is important to keep in mind that they are capable of handling some cool effects, but everything has a limit. Keeping this in mind in the early stages of your game's development will help to reduce the stress and amount of work in the later stages if you need to adjust some components of your game. Some materials could be really expensive from a computational point of view. There are shaders which replicate (with a good approximation) cool effects but are optimized for mobile (such as the bloom effect we discussed earlier).
The ideas explored in this small paragraph is just scratching the surface in optimizing your application from a graphical point of you. However, you can continue your reading here: https://docs.unity3d.com/Manual/OptimizingGraphicsPerformance.html.
Another way in which you can optimize your game is to pay attention to your code.
In previous versions of Unity (before version 5), there was the need to cache the Transform component. As you can read at the end of this article at https://blogs.unity3d.com/2014/06/23/unity5-api-changes-automatic-script-updating , there is no more need for this. However, there are still developers that use it; now it should be avoided since it reduces the code readability a lot, and therefore the development process as well. In any case, you should still cache other components into variables, as we did for the UI back in Chapter 3, Communicating with the Player – the User Interface.
Note
In case you are using an old version of Unity, or you just want to understand what was the caching of the Transform component, look at this line of code:
transform.position = Vector3.zero;
When it was compiled (in past versions of Unity), it was equivalent to:
GetComponent<Transform>().position = Vector3.zero;
And, as we already mentioned in various chapters, the GetComponent() function is slow and it should be avoided when possible. So, you should have considered to cache the Transform component into a variable (as we did back in Chapter 3, Communicating with the Player – the User Interface, where we stored the reference to the UI component into a variable). Thus, in the case of the Transform, you could have done it within a Start() or Awake() function with the following line of code (of course, after have declared the thisTransform variable of type Transform):thisTransform = GetComponent<Transform>();
Other tips deal with strings, which are extensively used everywhere in Unity. However, unless you are doing particular intense string manipulation, you should avoid doing the optimizations presented here for strings, since the performance gain may not be worth the time spent and the reduction of readability of the code. Here are these tips:
- Remember that if you are concatenating different strings together in a single call (which means, for example, doing in a while loop, which is not placed within a Coroutine so that it will be computed all in one frame), the memory could fill up quickly with unused string objects without giving the time to the garbage collector to clean it up. Therefore, you can use the
StringBuilderclass, which is also slightly faster. - There are many different ways to compare different strings. However, the fastest one is the following:
firstString.Equals(secondString, StringComparison.Ordinal);
- The reason is that the algorithm just needs to walk (go through character by character) the two strings (which the single characters are seen as numbers, thus this method is case sensitive) to see whether any difference is found.
Test, test, test! Not only test with your target device and audience, but test, test, and test again with them! This may seem like an obvious part of the game development process, but at this stage, even when you do it by yourself and with other members of your team, it is absolutely crucial. Make sure that the game works on high-end AND low-end devices that are within the range of your specifications. A great video to watch that will give you an overview on the process is extra credits video on playtesting, which can be found here: http://tinyurl.com/PlaytestingExtraCredits.
Don't assume that if it works on your or your friends' devices that it will work on everyones'. There have been cases where games don't run on specific model of phone. Given this, test on as many as possible. However, thankfully, if you can't get a hold of a range of different devices, you are able to use an emulator to simulate it running on a particular device (or devices). Genymotion (www.genymotion.com) is a product that offers a great way to emulate different devices.
The is the most fundamental question of the whole playtesting: why are you playtesting your application? Sure, the answer is obvious: to get feedback. But why? For example, do you want to see if the additional feature is necessary? Perhaps you want to find out whether the sound effects are too frequent and irritating; or perhaps they're not enough.
Call a team meeting, sit down and go through the features that your application has, what have been difficult to get working, which ones are novel/experimental, or even which ones should be removed. Has there been any informal testing that has offered an another perspective about the game? Do you need to redefine the project, and does everyone have the same concept of the game in their head? It is likely that you have already done this, even a few times, but if you haven't it is good practice to have constant reviews of your game and its development.
Whom do you want and need to playtest your game? Is it a multiplayer, single player or cooperative game? Ideally, when you are conducting a playtest, you want people who are from your target group. While they are playtesting, you'd want to encourage them to take notes, before the playtest (what are their expectations?), during the playtest (what are they thinking/feeling?), and after the playtest (what could be improved, what is good/bad about the game, what is missing, and so on).
It is better to test your game before you ask anyone outside of your group to test it. While this might seem like an obvious thing, but even if you think that your game is infallible, it is more than likely something doesn't work the way that it should. This is why it is important to playtest with yourself and/or your team because if you get bugs and glitches out of the way, then players spend less time trying to play your game and more time playing it to give you valuable feedback. In saying this, it is even worthwhile to playtest with a small group of others before conducting an actual playtesting session. Ideally, this could be easily done within your team itself. While you are doing this, it is useful to not only get a better idea how you want to test the application with others, but it will also help you to shape your questions about their experience for the real thing.
The more the merrier, and it's the same with playtesting; but at the same time, make sure it is manageable with the resources that you have available to you. When you are organizing a group test, it is important to have a mix of people from both your target demographic and outside of it. This is because you can get feedback different perspective, which could offer insight into how the game works or doesn't work.
This is the same as asking whether your playtest will be public or private. At this stage, you need to ask yourself whether the game contains sensitive components that could effect the release. As a result, you may require players to sign a non-disclosure agreement (NDA), which prevents them from discussing the game publically, sharing screenshots, and legal consequences for doing so. In contrast, it may be fine for them to freely and openly talk about the game to anyone after they have played.
It is very important that this is made clear to playtesters in the beginning, even before they sign up. You don't want to be logging onto Facebook or Twitter with people publishing screenshots about your app when it's still being developed. Other considerations can be asking playtesters not to take any video or pictures during the actual testing, including selfies, check-ins, and social media posts. In some cases, the print screen option is disabled for this very purpose. Of course, people are smart and they find many workarounds to this. But if you have certain measures and consequences in place, ensuring that participants adhere to a set of rules prior to playtesting and acknowledge them (for example, signing an agreement), you can avoid any unwanted publicity later.
Now, playtesting can always start with your friends, family, and other close associates. This limits the amount of time that is required to get superficial issues out of the way, such as navigation functionality, certain aspects not working properly, and so on. Make sure that they don't tell you want you want to hear either. Family and friends know you on a more personal level and will know what you are looking for, so make sure that they are honest with their feedback and constructive with their critiques.
In saying all of that, it's great to get comments from those that we know because there really isn't anything unknown and you're comfortable to communicate with them. But like we mentioned before, you need an objective opinion from someone you don't know and who doesn't know anything about your game other than the synopsis that you gave them prior to testing.
Given all this talk about people, it is important to keep in mind who you are intending your game for. For this group of users, you really need to define your target audience (age, location, and experience level). By developing a user profile early on, then you are able to define the kind of attributes that they may have and that you need to cater for. Not only will this will help you to improve the design of your game but also to define how you will need to conduct your playtest. By doing this, you are able to focus the questions that are related to the application, and to them, and find out (if it's not), what could make it more relevant.
Some simple steps that can get you refining this group of people are the following:
- Look at who is already using your products (if you have more than one). If you don't already have a user-base, then create a list of what would be your most ideal one. Start broad and then work your way to refining it to becoming a bit more specific. This will help to improve how you also market your game later. Look at things like age group, gender, location to help develop a better picture.
- See what others, who are similar to you, are doing. This will help you to also refine (or redefine) your target audience. Make a list of games that are similar to yours and see how their audiences are being targeted.
- Analyze the products and/or services that you already have available. Have they done well, if so why, if not why not?
- Choose specific characteristics of your audience to focus on. For example, while all of them may be gamers, maybe some are more casual than others. Perhaps your game is more targeted towards adults than children, and so on. While we aim to please everyone, we can't, so it's better to a more directed focus.
- Take a step back and evaluate your target audience. Are there things that could be added to help improve or specify them?
These are only some of the things that you will need to consider when defining your target audience, so I encourage you to also check out other, and more relevant text (on the web, books) that are more relevant to your game.
The time that you decide to run your play-set is also an important consideration. Especially if you require people to be physically present. When deciding on a time think about what your group would most likely to be doing at that time. For example, if your target group students, it is more than likely that during the day they will be at school, therefore, weekend testing sessions are probably going to be more suited for them. On the other hand, if your group are people who run, early mornings or after work are probably more ideal times to have sessions. Of course, these are dependent on the type of game that you have as well. If your game requires more time commitment, then having a longer period of time for them to play your game is going to be better suited both for you and their lifestyle. Remember, they are helping you, so flexibility is key.
If playtesting is all done virtually, either by downloading and executable or by logging in to a website, then feel free to skip this section. However, if you require participants to come to a physical location, you want to make it as accessible as possible. Ideally you want it to be somewhere that is close public transport and in an area that is likely to be a central point for people to come to. For example, a city center is generally close to public transport, and it is likely to be close to people's places of work, or even school.
What are you expecting from the playtest and what are your playtesters expecting to do are two questions that you need to consider. For example, are you wanting them to play the tutorial and then provide feedback to you, either written or verbal? Perhaps they are thinking that they will need to play the entire game. The what of your playtest is essential to define and to make clear to the playtesters, that way you're not wasting their time and they aren't wasting you by giving feedback to irrelevant parts of the application.
What will you provide your playtesters during playtest, and/or for their time? If you are unable to compensate them, make sure to provide food and beverages. This is not to say you need to get a caterer to provide you with cakes and sandwiches, but having tea and coffee with some snacks (cut up some fruit, chips, candy, biscuits, even make your own sandwiches) will help to keep them sharp, especially if they are there for a long time. Scheduling breaks during long playtest sessions is also important, because you don't want them to be sitting there for hours. Having breaks every 45 minutes is a great way to also check-in with them and see how things are going.
How are the playtesters going to, well play and how will you manage this? How are you going to get their feedback? What kind of equipment (recording devices or computers) and software (questionnaire) will you need? Prior to the test, make sure that they work, batteries are charged and you have all the necessary equipment (cables and adapters) available. In addition, make sure you have a backup plan if for some reason sometime goes wrong on the day (which it does happen).
There are different ways to approach a playtest. You can let the players figure it all out on their own (after you've provided a bit of context), or guide them through the rules. With each approach, the way that you gain feedback during the playtest will differ. The following are some ways that you can playtest your game.
Observe how your testers are playing. For example, do they do things in a particular way or that is not expected? Perhaps this is because of a glitch or from other experiences that they have with games, and as a result they use certain features (or try to) in the same way. The same concept can happen in reverse, for example if players are supposed to obtain or do something but they don't, or the game won't allow them to then this needs to be fixed. At these points, future players are likely to find the game difficult to use because of a technical issue and head towards the Uninstall button.
There is no better way to check your understanding of something than to explain it to someone else. Therefore, one way to get feedback from your playtesters is to ask them to explain the game to you. Do they explain something different, that has you asking if you gave them the right game? Or do they explain the game in the same way that you intended it to be like? While they are explaining the game to you, make sure that you keep the conversation on what the game is, and not what it could be. Of course, any improvements are great suggestions, but for the purpose of the explanation, you will want them to tell you what they just experienced.
By now, you're left with an empty testing space and a whole bunch of notes, ideas, and different thoughts whizzing around your mind. Now is the time to get them out and documented. Have a group meeting. Write it up on a whiteboard, paper, document, or somewhere that is easily accessible later. This is an important process because what happens here can greatly impact your game upon release.
Now that the playtest is over, you will want to follow up with them. It's just like being in a meeting, you think of something useful afterwards, the same goes for testing. In a week from the playtest, it might be a nice way to drop them an e-mail, thank them again for their participation and if they have thought of anything else since the playtest. The important thing here is not to spam them with e-mails and questions, but to provide them with an opportunity to suggest it. You can provide them with an online (and anonymous) questionnaire.