Aftershock Simulator Sprint 6

During Sprint 6, one of my points of focus was making a miniature level for the game’s tutorials. The start of this task meant diving into our level editor developer tool. While previously I had been able to use the tool just fine, what we needed was to be able to change the level size; a feature which the editor didn’t had. So, my first accomplishment was coding in a new setting for the level editor to set its size.

I found the section in the code that defined the level size, set it to a variable, and added an input field into the level editor. This way, any future designers will be able to make levels of varying sizes for different purposes.

I then used one of our level designer’s designs to build a simple level using the editor, and set up all the necessary infrastructure to get it functional in the game, which can be seen in the picture. One major change I had to make was how the camera worked; since it was designed around a 100-unit wide level. I modified the camera attributes to also take variable input in the designer, and set it to center around wherever it is first placed in the level. This way, I could constrain it to the much smaller level bounds.

Next, I did some more work with objectives. Since our team implemented a building tagging feature, I made a new type of objective for tagging buildings. 

The TagObjective was pretty straightforward, just copying my methods for the UIObjective. The main addition was adding a customizable variable for the number of buildings that need to be tagged.

My main challenge was that each building tag is its own unique object, each with their own script that activates when clicked. In the main scene, there were 800. So in order to manage this preexisting system, I made a new script called the TagManager. Since all the tags were instantiated as children of the same object, I gave them a small addition that grabs reference to their parent on creation, which finds the TagManager. On click, they’ll reference back to the TagManager, which will keep track of how many tags have been added. This way, the TagManager can be the subject for the Object Observers, and tie back into the Objectives system. Following my patterns from before, I wanted to link together as few scripts as possible, so I think tying hundreds together into one was a successful way to integrate the two systems.

Following with objectives, I also began work on some integrations with the rescue system. The ScoreManager already keeps track of the number of people rescued, but I added a prototype UI element to display this to the player during testing and play. Lastly, I began setting up a bunch of the infrastructure for RescueObjectives that check how many people have been rescued, which will be expanded upon in the next sprint.

Aftershock Simulator Sprint 5

Now that the UI elements were created, during this Sprint I set to implement all the Objective UI so that the information gets dynamically communicated to the Player. For example, I started by making a dropdown menu that displays the current Objective.

It’s pretty straightforward. Since I made the ObjectiveManager a Singleton, it’s super easy to add scripts that can reference it. In this case, it let me make a simple script that displays the current objective. I did however have to learn how to make a Mask for the UI element, to make sure it doesn’t display over the top of the toolbar.

Next I worked on the actual Objectives menu, which is accessed from a button on the first dropdown.

It’s a pretty straightforward menu. There’s one tab for the current objectives, and one tab for the completed objectives. The script works just like the dropdown, except it runs through the whole list of objectives and adds them to a string to display. I haven’t used this much text in a 3D game before, but I got used to utilizing text displays during my other classes in c++, and this task helped me learn to do it in Unity.
Since I already made the Objective system, it was pretty simple to get them all to display here. The trickiest part was definitely the checkmarks on the completed screen. Rather than trying to place them on the screen separately from the text, I created a sprite sheet asset using the checkmark asset provided. Then, I could use TextMeshPro to place it as a symbol in text.

Lastly, I was assigned to make a sample level based on some tutorial designs to learn to use the Data Model Editor. I followed along with the existing video created by our predecessors, and also had to read some documentation to find information the video didn’t cover. Overall though I didn’t find the editor tool too difficult to use, and demonstrated by making this little sample scene. In the future, we may make some small, simple levels like this for the tutorial levels.

One limitation I did run into is that I couldn’t find a way to change the size of the ground itself. I limited the area I worked in to 4 chunks, so that we can carve it down in the future, but I’m not even sure if the tool has a feature to make the landscape smaller–I couldn’t find anything about it in the tool or documentation.