We continued to learn about adding different aspects to our game in Unity.
The idea that our bank of desks came up with last week was picked up to work on today, which was nice since it’s something that I want to implement in my room game as I go: the beginnings of an inventory system.
First, however, we worked on another idea that is quite good for a mystery/suspense/Alan Wake game, which is giving the player control over turning on/off a flashlight they’re holding.
We added a spotlight to our game and made it a child of the First Person Controller. I then had to turn off the other lighting in the scene, to get the full effect of the flashlight. We could change the colour (maybe to a softer yellow) and changed the shadow type so it would cast soft shadows as the player moved around. It also took a little maneuvering to get the flashlight in the right position, so it looked like the player was holding it. I thought this could be quite good to keep in mind if (at a later date) the player was wearing a headlight or something, as the light source would come from above the camera rather than below.
After that, we needed to make a script for the flashlight to work:
In the above, we created a new data type called Light and added a new variable to it called flashlight. We then implemented a conditional statement (if, then) to say “If the player pushes the F key, the light intensity will change to make it look like it’s on or off.” In this instance, it works with mathematics:
If the flashlight intensity is already at its highest, so set to 1, then:
new flashlight intensity = 1 – 1 = 0 (so the light will appear off)
If the light is already off, so set to 0, then:
new flashlight intensity = 1 – 0 = 1 (so the light intensity will be set to 1 and appear on)
You could change the higher intensity number from 1 to 2 or 3 if you want the flashlight beam to be brighter.
I think the theme I have in mind for the walking/room game I want to make could make use of this mechanic, so I’m please to have something relatively simple to use and I’ll see if I can build on it – maybe need to pick up batteries to keep the light going (again, like Alan Wake) or have pitch black rooms and only the light to guide you through the puzzles.
Next, we covered how to take items we pick up and store them in an inventory script, which could lead to having an on-screen or called-up inventory mechanic implemented. I realised once the items were stored in the component, it should be quite easy to call them up to display in the GUI.
The above script was the first one we wrote, where we had to define what the Inventory was (a list that would store each item on its own line).
The next script was for the items themselves – we needed to define which items could be picked up to store in the inventory (by attaching the InventoryItem script as a new component) and what it would be stored as.
Here, we’re saying that we need a new space in the component to define the item’s name as it should be in the inventory (itemName). We then say that, when the player clicks on the item to pick it up, it will saved in the inventory but the object will be removed in game so it won’t appear anymore.
Attaching this script to the key will be most useful. I made a couple of alterations to the code we were shown for the door controller.
I decided that I didn’t want the door to automatically open for the player when the key was added to the inventory. Instead, I changed it so that the player had to click on the door (OnMouseDown) and it would open, but only if the key was in their inventory. It wouldn’t do anything until the key was in their inventory and it was interacted with.
We also were told of a way to add a distance restriction to picking up items like the key; this way, a player couldn’t be half-way across the room and still be able to click on it to pick it up if they could see it. I actually really like this idea and I’ll likely add it to the door OnMouseDown code so they can’t open the door until they’re in front of it.
In the last 20 minutes of the class, we were asked to implement an activity diagram to show an idea we would like to see developed in the game. There are some important things to remember when making an activity diagram:
- A solid circle is the starting point of the diagram. It’s where the flow of the the program starts and where the initial arrows come from.
- The arrows themselves show the flow of the activity and have to be uni-directional, unless in specific situations using specific kinds of arrows.
- You use rounded rectangles to denote actions that take place through the activity.
- The end point is designated by a solid circle surrounded by a circle. You can have multiple exit points if your activity diagram requires it.
- If (or conditional) statements are designated by a diamond; these decisions should have (at least) 2 arrows directing away from them as descriptors.
This was my activity diagram:
I’m not entirely positive if the diagram is correct, so I’ll just have to wait for feedback.
Essentially, I wanted to continue on with the idea that there is an on-screen GUI inventory system, so you can actually see what’s been stored and what can be used, perhaps with descriptions.
I’d like to use this with what we’ve already learned and go a few steps further for a potential mystery/puzzle walking sim I would like to make.
It’s going to be a while until we have class next, so I’d like to see if I can figure out at least one way I may be able to implement this plan on my own in the room project we’ve already started.