Aftershock Simulator Sprint 4

During this fourth sprint, I was focused on adding a developer console to the game. By the end of the sprint I had it fully functional, with three different commands and an easy way for more to be added in the future.

I’m still not 100% sure that this is the best way to make a developer console, since I know that OnGUI() is very resource intensive. But this is a tool intended only for developers that shouldn’t appear in the normal game, so it should be fine. 

I didn’t actually know how to handle text input in Unity, so I did some research and followed a guide to get a base setup. This gave me the basics of taking and defining commands, and I borrowed the DebugCommandBase script. One change I made was simplifying it down to only one name for the command, since I figure if other people are adding commands in the future, it might be confusing to have to define a separate plaintext name and a command name.

The biggest original addition I added was an extra text line for feedback. I figured that as a developer, it’s important and useful to know that your command worked properly. In addition to the “Command not found” default message, the commands I implemented have success/failure messages to let the user know if the command activated successfully, or if it couldn’t.

For example, the first command I added was one that completes the current objective. To prevent errors, there’s a check to ensure there’s a current objective to complete. By making this function bool returning, I can return a different message whether or not it was successful. If it fails, the display message is instead, “All objectives already completed.”

The other command I implemented was one to skip the survey at the beginning of the program. This was pretty simple, thanks to the way commands can be given Actions to be Invoked. It’s a really elegant system.

One tricky part was setting up the help command. I’m not as used to UI elements, and it took a lot of tinkering to get the scroll field to display properly. The guide I was looking at set up the console at the top of the screen, but since our project needs it at the bottom, I had to change a lot of its orientation.

In terms of its place in the scene, I figured the script needed to be attached to the camera, since that’s the object that takes player input, and the console needs to be able to listen for certain commands (F12 to enable it and Return for processing). 

Finishing off the sprint, I wrote up documentation for the feature so that future teams will be able to use and modify it. It’s a pretty straightforward feature. This was something that needed doing, and I needed something to do while waiting on some UI art to be made. Now that it’s ready, I look forward to the next sprint where I’ll be working on the front-facing UI for my objective system.

Aftershock Simulator Sprint 3

This is the tutorial video I made for my team demonstrating how to use the objective system I designed this sprint. I’m really happy with how well it worked out and I look forward to getting some UI implemented so that it can fully appear in the game.

I went into designing this system with some idea of what to make. I knew that designers would need to be able to make customizable modular objectives and tell the game levels what order to progress through them in. 

What was a huge help was a comprehensive list one of my team members put together of all the currently planned levels and objectives. This meant I didn’t have to make a universally-flexible system, just one that fit what we needed, which gave me some valuable direction. I looked at the list and broke it down into three categories: clicking on tiles, clicking on UI elements, and taking key input.

Initially I drew up a class diagram to figure out how I wanted my system to work, but I ended up iterating through so many different approaches it mostly just ended up as a brainstorming document. Objectives started more or less as I planned them, with one major exception. I knew I wanted an abstract class so that the three objective types could inherit it, but I ran into a huge problem pretty quickly.

I started by trying to implement TileObjectives (for clicking on tiles in game) and realized the issue: all of the relevant game data is stored in completely different places. TileObjectives needed to grab their info from the SelectionBoxManager, InputObjectives needed to take input from the CameraController, and UIObjectives needed to grab their info from three different layer visibility scripts.

This is why Objectives inherit from Observer—I decided to implement the Observer design pattern to try to tie together these tangled scripts. TileObjectives can observe the SelectionBoxManager in order to make sure they

1. Only run their check when the player clicks on a tile

2. Receive the game data needed to see if the Objective was completed

And this system worked awesomely! There were a few small hitches—I had to make some enums for ease of communication—but the last big one was for the UIObjectives. Like I mentioned, each UI element connected to code in a different script, so I made a LayerUIWrapper class that “wraps” together references and shared information for the different relevant UI scripts. 

The final piece of the puzzle was the ObjectiveManager. The first part is pretty simple, it has a list of Objectives where designers can add their Objectives in a certain order, and the manager will progress through them during the level. The magic happens in the attachObjective function, where the ObjectiveManager will Attach Objectives to the appropriate Subjects based on what type of objective they are. I’m really proud of this system because, at least in my mind, it should be super efficient: the game only tracks the current objective, and the objective only looks at one script.