Appendix

This section will include added notes and other topics that don't quite fit in our Unity project for several reasons – topics such as Virtual Reality (VR) for a side-scrolling game that could work but ideally would be better suited to a first-person view format to help with the potential issues that a developer may encounter.

Finally, in the last topic, we will cover some random general knowledge pertaining to Unity that could also help you through the exam.

Developing for Virtual Reality

As you probably know, VR has been around commercially since the '90s, but it only became more widely recognized when Oculus and Vive headsets, which can be hooked up to a PC, became accessible. A short time thereafter, mobile phones were being turned into VR headsets as a cheaper alternative, examples including Google Cardboard and Samsung's Gear VR attachment headsets.

As Unity developers, we need to not only understand the technical limitations of these VR devices but also understand how and why some people feel sick while others do not.

VR games/simulations can get rejected very quickly if, for example, the brain and the body know they are not inhabiting the world their eyes are telling them they are a part of.

Note

If you would like to know more about the health and safety aspect of using/developing a VR app, refer to the following link: https://retrophil.codes/Self-Study-App-Cognitive-Behaviour-GearVR.

So, in terms of performance and VR applications, frame rate is important. Developers are encouraged to aim for a high frame rate of 90 to avoid a jerky disconnect with the world the user is in. Latency or, to be more precise, motion to photon (MTP) is required to be no higher than 20 milliseconds (the delay in updates when the user moves their head) with a display refresh rate of 90 Hz (displays refresh every 11 milliseconds).

The following diagram shows the three aforementioned technical targets that need to be achieved when designing a VR app:

Figure A.1 – Technical targets to achieve with VR

So, if we can hit those three targets consistently, the user will feel more immersed in their world. Keeping performance high means being careful with the platform's resources. For example, if, in the user's distance, there are plenty of 3D assets with materials and various textures applied that the players are never going to reach, we may as well replace those assets with a skybox to help maintain the fluidity of the VR app. Another technique designed to help keep the VR app running smoothly is by altering the texture of the display (renderViewportScale) at unavoidable parts in the VR app.

We, of course, can still make the user feel ill by overdoing things with post-processing effects and by adding aspects such as motion blur and depth of field, which may confuse the user, while removing aspects such as jagged edges on assets would naturally make the user feel even less like they are in a game/simulation. Meanwhile, even going as far as increasing the resolution through super-sampling can be a very expensive method for a mobile device. If your VR app is basic (no textures, basic lighting, and few assets), you may be able to achieve this... as long as your performance doesn't dip!

The main takeaway from this is that VR needs to run as smoothly and convincingly as possible before filling and polishing a scene too soon.

Closing suggestions for the game/exam

There is also a possibility in the Unity programmer exam that you will come across the odd question on shaders to establish how much you know about creating shaders or what different shaders can create. Learning about shaders is another book in itself, and it's also unlikely when you sit your exam that the majority of it will be devoted to shaders. Hence, if you don't know how to write shaders, do not concern yourself with the coding and focus more on the general practice and functions used. For example, a cel-shaded toon in an environment or custom post-processing effect can be achieved by using functions such as Camera.depthTextureMode to calculate the depth of a scene.

Knowing that these functions and methodologies exist will give you a better chance of answering them, and if you need more information on shaders in general, refer to the Packt book entitled Unity 2021 Shaders and Effects Cookbook – Third Edition; otherwise, I recommend skimming through the Shader reference manual provided by Unity: https://dev.rbcafe.com/unity/unity-5.3.3/en/Manual/SL-SurfaceShaders.html.

In the next section, I'll go through the process of installing post-processing v2 on later versions of Unity.

Rendering paths

Some of the mock questions in the Unity programmer exam may refer to Forward and Deferred graphic settings, but what are these, apart from a selection that can be made in our Camera component in the Inspector window?

The following screenshot shows alternative rendering paths in the Camera component:

Figure A.2 – Render paths

As we can see in the preceding screenshot, there are a variety of different rendering paths. Each of these will render our scene's surface and light in a slightly different way. Some will work faster than others but be devoid of other benefits, such as anti-aliasing.

Note

Refer to the following link to see the chart comparisons of the various rendering paths: https://docs.unity3d.com/Manual/RenderingPaths.html.

Adding to/optimizing Killer Wave

So, we really have come to the end of the book, and the whole process of designing a game/prototype was a way of trying to cover as many objectives from the Unity programmer exam as possible in a variety of scenarios. There are parts in this tutorial series where obviously things could have been quicker or done better with regard to creating a project, but this book was never about making a game. It was about covering as much as possible while seeing your project develop.

Also, if you bought this book simply with a view to making a game and you haven't made one before, you've covered a range of tools and components that you can now use, and for sure, you could find employment as a Unity developer. The majority of the 30+ Unity projects I have worked on have all emanated from the skills I have demonstrated in this book. Hence, if you want to carry on with Killer Wave or rename it and change the concept to personalize the game, go for it. You have an adequate foundation to continue, but where should you go next with the game?

Here is a list of things that you could work on in order to continue with Killer Wave:

Optimize the code:

• Use the Unity Profiler as often as possible and take the first and most expensive resource used off the top of its list, as discussed back in Chapter 13, Effects, Testing, Performance, and Alt Controls.
• As your game will likely get bigger and more complex, using functions such as GameObject.Find and Transform.Find is going to slow your game down even more. Reference these variables by other means, such as in the Inspector.
• Avoid any kind of if statement within a for loop.
• Any multiplications made with Vector3s and floats need to be done separately (keep all floats within parentheses to prevent code from going back and forth between variables).
• The following code block shows an example of keeping Vector3s and floats separate:

  transform.position = lastPos + wantedVelocity * (speed * speedFactor * Mathf.Sin(someOtherFactor) * drag * fricition * Time.deltaTime);

• Cache transforms; Unity performs checks to establish whether a game object has been deleted with its own standalone transform. The following code block shows an example of caching a transform:

  Transform _transform;void Start(){_transform = this.transform;}

• Use transform.localPosition instead of transform.position (if you can). Unity automatically stores all data as local positions internally.
• Reduce engine calls by caching variables.
• Remove the get and set accessors, and keep variables as public to avoid accessing.
• Try to avoid Vector math and replace it with cache multiplied floats. This saves the creation of Vector and having to store values inside it.
• Store Time.deltaTime as a static float to avoid multiple engine calls.
• Use for loops instead of foreach, since foreach creates garbage.
• Use array instead of List.
• Try and keep the GC Alloc list at zero in the Profiler. Basically, don't generate garbage if possible in order to avoid performance spikes.
• Instantiate game objects in the first frame.
• Make an object pool of bullets instead of instantiating and destroying.
• Don't use string concatenations; in worst-case scenarios, use StringBuilder.
• Create your own Update / FixedUpdate managers instead of using those offered by Unity. This aids performance, and you can create your own custom features to add to it.
• Use animated sprites instead of 3D assets.
• Try not to use GetComponent / GetComponentInChildren / GetComponentsInChildren / GetComponentInParent / GetComponentsInParent. If you do, make sure you use them on startup (Awake, Enable, Start).
• Avoid animating game objects with a large hierarchy.
• Create a loading screen if the scenes take too long to load.
• Make all final Profiler tests on the platform (Development Mode and/or Logcat for Android) on which you intend to build your game/app.

Other game ideas:

• Create alternative scriptable assets for the current enemy.
• Make more items available in the shop.
• Add different enemy spawners.
• Make the cluster bomb do something!
• Fight the boss.
• Create level 4.

I hope these ideas/suggestions help and that the book, in general, helps you on your journey. The very best of luck!

Mock answers

The answers to the mock questions located at the end of some chapters can be found in the following sections:

Chapter 3, Managing Scripts and Taking a Mock Test

Chapter 7, Creating a Game Loop and Mock Test

Chapter 10, Pausing the Game, Altering Sound, and a Mock Test

, NavMesh, Timeline, and a Mock Test

Chapter 14, Full Unity Programmer Mock Exam

More questions and answers can be found at the Packt repository at the following link: https://github.com/PacktPublishing/Unity-Certified-Programmer-Exam-Guide-Second-Edition /tree/main/Extra.