Chapter 5. Prefabs, Collection, and HUD

In this chapter, we'll continue our work from Chapter 4. Working with a similar approach to the previous chapter, we will be expanding our knowledge of collision detection by using a third method of collision, that is, by using colliders as Triggers.

Triggers are often referred to as actual components. However, in simple terms, they are the primitive colliders you are already familiar with, but with the trigger mode set in the Inspector using the Is Trigger checkbox, as shown in the following screenshot:

As we have already set up an outpost with an opening door, we will now restrict player access by making them find objects in order to open the door. By creating onscreen instructions when the player approaches the door, we will inform him that the door requires a power source to be opened. We will then add a 2D display of an empty battery on the screen. This will prompt the player to look for more objects, that is, batteries, which are scattered nearby...

Creating the battery prefab

In this section, we will import a downloaded model of a battery and turn it into a Unity prefab — a data template that we can use to make multiple copies of the model with predetermined settings applied. If you've worked with Adobe Flash before, then you might compare this idea to the MovieClip concept, wherein you can create many identical copies, or modify individual copies post creation.

Download, import, and place

To begin creating the puzzle, you'll need the battery asset package which is available in the code bundle provided on packtpub.com (www.packtpub.com/files/code/8181_Code.zip). Locate the package called batteries.unitypackage from the extracted files. Once you have done this, switch back to Unity and go to Assets | Import Package. Browse to the location you downloaded the package to, and select it as the file to import. You will be presented with a list of the assets inside this package in the Import Assets dialog window, then click on Import to...

Scattering batteries

Now that we have our battery object stored as a prefab, when we duplicate the copy in the scene, we are creating further instances of the prefab. Ensure that you still have the battery selected in the Hierarchy and then duplicate the battery object three times so that you have four in total, this can be done either by going to Edit | Duplicate or using the keyboard shortcut Command + D (on Mac) or Ctrl + D (on PC).

Tip

When objects in the scene are duplicated, the duplicates are created at the same position — don't let this confuse you. Unity simply does this to standardize where new objects in the scene end up, and this is because when an object is duplicated, every setting is identical — including the position. Moreover, it is easier to remember that they are in the same position as the original and simply need moving from that position.

Now, select each of the four batteries in the Hierarchy panel, and use the Transform tool to reposition them around the outpost. Remember...

Displaying the battery GUI

Now that we have our battery collectables in place, we'll need to show the player a visual representation of what they have collected. The textures imported with the batteries package have been designed to clearly show that the player will need to collect four batteries to fully charge the door. By swapping an empty battery image onscreen for one with 1 unit of charge, then for an image with 2 units of charge, and so on, we can create the illusion of a dynamic interface element.

Creating the GUI Texture object

Part of the assets imported with the batteries package was the textures folder. This folder contains five image files — one of an empty battery cell and the others of the four stages of battery charge. Created in Adobe Photoshop, these images have a transparent background, and are saved in a PNG (Portable Network Graphics)format. The PNG format was selected because it is compressed but still supports high quality alpha channels. Alpha channels are what...

Battery collection with triggers

To trigger the differing states of our Battery GUI, we will use a function called OnTriggerEnter() to detect interaction with objects that have trigger mode colliders, that is, our collectable batteries.

Before we add this function to our PlayerCollisions script, we will add a public member variable at the top to hold an audio clip to be played when the player picks up a battery as a form of audio-based feedback to back up the GUI element.

Open the PlayerCollisions script by double-clicking on its icon in the Scripts folder of the Project panel. This will launch the script in the script editor, or simply switch back to it for you, if you already have the file opened. Add a public member variable for the audio clip to the top of the script by adding the line:

var batteryCollect : AudioClip;

Remember that this is not assigned in the script, but simply left with a data type (AudioClip) so that it may be assigned in the Inspector later.

Next, place your cursor...

Restricting outpost access

The main point of this exercise is to demonstrate how you can control certain situations within your game development. In this example, we wish to allow the player access to the outpost, only if they have charged the sliding door by collecting four batteries.

This puzzle presents us as developers with two main issues to be addressed:

• How does the player know they need to collect the batteries to enter the door?

• How can we code our game to open the door only if all of the batteries have been collected?

To address the first issue, we'll aim to maintain the element of mystery about our game. We will only present the player with a hint to collect batteries should they be inquisitive enough to attempt to enter the outpost. To do this, we will need to add onscreen instructions when the door is approached for the first time. We will add further instructions if the door is approached again, if the player has collected some but not all of the batteries required.

In order to...

Summary

In this chapter, we have successfully created and solved a game scenario. By assessing what your player will expect to see in the game you present to them — outside of your prior knowledge of its workings — you can best devise the approach you must take as a developer.

Try to consider each new element in your game from the player's perspective — play existing games, think about real-world scenarios, and most of all, assume no prior knowledge. The most intuitive gameplay is always found in games that strike a balance between the difficulties in achieving the tasks set and properly equipping the player for the task in terms of information and familiarity with the intended approach. Appropriate feedback for the player is crucial here, be it visual or audio based — always consider what feedback the player has at all times when designing any game.

Now that we have explored a basic game scenario and looked at how we can build and control GUI elements, in the next chapter we'll move on to...