CAGD 495 (Aftershock Forecast)

Sprint 7 (Aftershock Simulator Sprint 20) 

  It’s the final blog post of the semester for Aftershock Simulator! I think our team did pretty well, despite our rough transition. In the beginning, we really had no idea what we were doing, and so it’s really quite a shame that we really only got started in the middle of the semester. I think this team was really good and they demonstrated their abilities well.

Our team begins at Sprint 14.

A part of the rough transition we had was essentially our team being confused as to what our goal was and how we would attain that goal. Our goal was for the game to teach the user how to use the Aftershock Forecast in order to better determine what to do in an actual earthquake. But our team has no idea how the Aftershock Forecast even works in the first place, so it’s pretty difficult to teach something you don’t understand. The previous team was only able to get to writing the code for the earthquake simulations, so they weren’t really able to get to any actual gameplay yet.

Learning Objectives

Another thing that went wrong was the fact that we kind of had to redo most if not all the in-game UI, especially the phone asset. Unfortunately the team had to really rush, so a lot of it was kind of scuffed. The phone UI was stuck in a portrait orientation, making it extremely hard to read the information that it was supposed to display. Our UI designer spent several weeks getting it right. The entire layout of the phone is completely different now. The apps now display their information in a landscape format, and the text is much bigger now. The other parts of the in-game UI (view buttons and action buttons) was moved up to the top of the screen and consolidated into the toolbar along with the objectives.

Original

Present

The settings menu was also revamped in order to fit with the style of the in-game UI. One thing that made it harder than it usually would have been is that most of their UI assets were not reusable. Many of the buttons had the text directly on the image of the button, which made editing them way more tedious than it would have been.

Original

Present

One thing that went well was the idea of mini tutorials and the objectives system. That idea basically lets us stay within a limited scope while also allowing us to be able to add on to the game when we need to. Simply put, our mini tutorials teach the user a feature of the game, and within the tutorials, we have objectives so that the user can focus on what they know in the level. Our target audience is emergency managers, and they are usually non tech savvy people. That results in our objectives being very simple so we can doubly make sure that we know that they know what each and every part of the game is. This also helps us reach our goal of making sure that the user reaches the learning objectives.

Another thing I think that went well is how the programmers were able to write and design features so that future programmers could understand them easily. Our programmers wrote easy to understand tutorials on how to add in objectives to the objectives system and the dev hack system. We also have a sample tutorial scene for the future tutorials we make, so that the new team can just duplicate the sample and add in dialogue and what not.

Lists the console commands.

Part of the tutorial on how the dev console works.

I’ll be sticking around next semester as the producer to help out the teacher, so I hope that we’ll have a much better time working on the project. Now that we have somewhat of a goal to move towards, we can potentially make some decent levels after we finish creating the tutorials. I feel like a difficult part of “restarting” in the next semester is telling the whole team to act as a designer, but at least we can kind of have a head start on what to do.

Sprint 6 (Aftershock Simulator Sprint 19) 

  For this sprint, there were many important things planned. It’s kind of a shame that this is the penultimate sprint and we’re only now getting to work on teaching the mechanics of the game to the player. This feels like it should be the third or fourth sprint of the semester. We’ve finally gotten into the groove and there’s only 4 weeks left. In any case, we were able to finish up 44 points out of 83 this sprint.

One thing we got started on was a “building debris” mechanic. To put it simply, when a building is damaged, there’s a possibility that it could spawn debris on the road tiles near it. It’s basically an easier implementation of the previously planned “landslide” mechanic, but the difference is that we don’t require input from an expert for the data on how to implement it. Planning is easy, but the hard part is implementing it. Every time a new obstacle is added into the AI’s path, it kind of has to recreate what its available paths are. Doing that is really taxing on a computer, and the amount of times the buildings will spawn debris is random. A basic version has been implemented, and in the next sprint, we’re going to add in the 3D models of the rubble so that it doesn’t just look like gray blocks everywhere.

  Some more things we got done is really getting to work on the phone UI. Now that most if not all of its assets are finished, now is the time to use them. Our UI designer had a lot planned for the phone to make it feel a lot better. The quake tracker info section looks a lot nicer than before, giving you more space to see the text. The MMI info section has a nicer looking legend so that you can easily tell the probabilities of what magnitude earthquake might happen. Also, you can maximize and minimize the phone’s space on the screen, so you can pull or close it up depending on what you prefer.

  A great addition we had to our in-game UI is the legends that explain the MMI scale and the ground conditions. The soil types are not very obvious at first glance, so having this here is really helpful. The map visualization kind of makes it look like there are more than 4 types.

  The settings menu was also redone as the previous one was really rushed and rough. It’s not currently 100% implemented, but all the design is there. Right now only the screen settings and return button should be working properly because we haven’t really focused on the sounds as of now.

  We also changed how the tagging buildings mechanic works so that it’s more accurate to the emergency manager experience. Previously, you had to tag the building yourself, but now the game handles it for you if you send a worker over there. The interactable tag menu has been moved to the debug console, in case we’d still like to use it for something. The queueing has also been moved there as technically, it’d be better if we forced the user to need to pay attention to using up their resources.

  One thing I’m really proud of is that we were able to get a new map working and looking fine! There’s still stuff that needs to be done as we needed to copy over elements from the previous scenes and we’re going to be creating a tutorial that uses the map. I was terrified that the previous team’s code was more hardcoded than expected, but seems like that wasn’t the case.

  I hope that we’ll be able to finish up everything we have in the next sprint. The programming right now is pretty complicated and it’s a bit of a shame that we’ve only been able to get to it so late. It’s the very last sprint, so the deadline is much more harsh than any of the ones we’ve experienced so far. Although technically for our group, we’ve probably been having it way too easy.

Sprint 5 (Aftershock Simulator Sprint 18) 

  It is now Sprint 18, and there are about 5 weeks left of the semester (excluding break and finals week). Seems like things are about to wind down for the other teams, but for our team, we’re really only getting started! At the beginning of the sprint, we were really running out of things to do. Now that our team has gotten relatively familiar with what’s in the project, we’re beginning to be able to teach more advanced things in the project.

We were able to finish about 45 points out of 88 this sprint. We’re going about the same rate but slightly less this time because I wasn’t able to prepare enough for people to do on kickoff day, so I ended up assigning some tasks later in the sprint. There were mainly bug fixes to be made.

The main things we did was revamping the UI and adding in the objectives dropdown. Now you’re actually able to see what you need to do in the game. One thing our team was talking about was how the information on the phone was really difficult to read. Some of the information text on there is just incredibly puny. So, we ended up having a complete rehaul of the phone’s UI. The main issue was everything being stuck within the portrait orientation of the phone, so we decided to make the information readable by rotating the phone and making the layout landscape instead.

One thing we were able to do is get in a tagging system for the player. Technically, it was always already in the game, as buildings will get tagged automatically when an earthquake happens. However, it is more accurate to the emergency manager experience if they initiate the tagging themselves. The way we have it working right now is that you, the user, sends a worker over and the building is tagged. Also, when a building is tagged red, the building will automatically be cordoned off. Previously, the cordoning mechanic blocked off both roads and buildings because the previous team needed to rush this mechanic in. Now, we’ve separated the building cordon to only be in the tagging system.

Another thing we got started on is trying to create an entirely new level. We’ve been slightly procrastinating on it, but now that we kind of have a handle on how it works, I believe that our team should actually be able to get our own custom level working. Thanks to the work of the previous team, making the level itself is actually really easy. Basically all you need to do is create your level in the custom tool and it’ll output a custom map data file. And then in a scene, you’d add in the monobehaviours and UI (this is the annoying part) and you’d just need to attach the map data file to the appropriate script.

The glaring mishap that we’re not sure is fixable is that when the game loads in the map data, it’ll fill in the extra unused space with a default dirt model. This might be because the previous team was only thinking that we’d only be doing large cities instead of mini levels. The current San Francisco uses up the entirety of the level designer tool’s area, so we were unable to notice this part.

Later in the sprint, we had a meeting about what else we would be able to add into the game. As of now, the game doesn’t necessarily feel like a game, so we had to think about how we’d actually make this fun and interactive for the player. We can now touch on our more advanced mechanics, so in the next sprint, we should be able to teach how search and rescue and the cordoning works. While we don’t necessarily have an overall game loop yet, I feel like having the self-contained levels that will eventually lead up to something bigger is definitely the best way to go for the future.

Sprint 4 (Aftershock Simulator Sprint 17) 

  In Sprint 17 of the Aftershock Simulator project, I assigned 76 points and 48 of those points were completed. The main goal for this sprint was to finish up the rest of the things we had planned: tutorials about the visualization layers, and a dev hack addition too. And of course, we continue our UI fixes too. There are still a few more things to do, but at this rate, we actually will run out of things to do after at least the next sprint.

As a producer, I feel a little bit of frustration when the velocity gets lower, but technically the chart I made doesn’t take into account the team size. The previous team had around 10 people while ours is half that. Just looking at the current team’s velocity, we average around 45 points and steadily going up little by little.

Our team's velocity, separated from the previous group.

Even though this sprint is number 4 out of 7 for the semester, our team doesn’t exactly have that hard deadline like the other teams do, so we’re not feeling as much pressure. This in turn somewhat makes it feel like we’re not doing too much, despite the fact that we are running out of things to do. It makes for a mostly stress-free environment, but also I feel like it’s slightly driving down morale due to not having that usual pressure to finish a complete product at the end of the semester. Although, as long as we finish up what we planned, it’s good enough for me.

The tutorials we created this time were about the visualization layers. We need to teach the user what the different colors in each visualization means. To double make sure they get it, there is a level for just viewing them while the city is normal and another level for them to specifically click on a tile of a certain color in the visualizations. In the second visualization level, an earthquake happens so you can see the effects of the earthquake through the layers.

Another thing we did this sprint was add in a dev hack. The only pressing dev hack we really needed was to skip the survey in the first tutorial, but since we talked about having an option to make all objectives completed, we added that in too.

For our UI rehaul, we had talks about changing up the in-game UI, so now it’s a fancy toolbar on the top of the screen. At first, it was just going to be the action buttons and the visualization layer buttons, but then we decided that it would also be a good idea to make the objectives also accessible from there as well.

One thing I noticed when the scenes load is that it looks like it kind of freezes for a second before the level actually loads in. So, we added in a loading screen so that it doesn’t look like it freezes! But, the weird thing is that the loading usually goes from 0 to 100 almost immediately, so it then looks like it’s lagging at 100%... Hopefully that’s fixable.

And yet again, we are almost out of things to do. There are some things that we still need to do and a few new things that we were able to think up. We still need to implement the objectives UI so that the user can actually see them in the game. One thing that we thought up last sprint was for the player to be able to save their progress in the game, and we were able to get that knocked out really easily! We also need to rehaul the phone UI so that it’s more legible and then we also need to create a tutorial explaining it so that the user can understand each part. But overall, I think our team is doing a great job.

Sprint 3 (Aftershock Simulator Sprint 16) 

  On sprint 16 in Aftershock Simulator, I assigned the team 87 points and 51 points were finished. We’re beginning to pick up now that we have a plan on what to do. In this sprint, our team started on the tutorial levels and the objectives system. And of course, there was some extra work to do for the UI in the game as well.

  As a producer, I still find it difficult to gauge the difficulty of a task, especially when it comes to programming. I still end up needing to change the point values of some cards because they end up more difficult than expected. For example, I had figured that creating the basis for the objectives system wouldn’t have been too difficult, but not necessarily. A few of the objectives require you to click certain UI elements on the screen, and the things that would “listen” to those UI elements are all each in their own separate scripts, so now there’s the added work of finding them and knowing where to put the code. I always end up asking people if they think their cards are 3-pointers rather than 1-pointers, but usually they just find that their cards need to be broken down.

Objective System Parts

  A cool thing our team was able to do was to be able to add in two new and simple levels. We’ve got an intro level which teaches the user about what earthquakes are, and how to access the USGS info required to assess the situation. There’s nothing too special about it, as all it really is is just a bunch of dialogue. Although, it might be better for the dialogue to be split up more as it does look somewhat hard to read. Instead of a built level, we just have a nice looking background as there’s no map that we really need to pay attention to right now.

  Our second level is our camera controls level. All it does is show the player how to zoom, pan, and rotate the camera. Our users are most likely not going to understand these controls naturally, so it’s important that we have this type of tutorial for them. The person who worked on this level basically finished it up in a weekend, which I was pleasantly surprised by. The dialogue flows naturally, too, so there’s not much we need to change. Although, one of the teammates was planning to create a small level, so we’re going to need to swap out the current San Francisco level eventually.

  For this sprint, I decided to work on refashioning the simulation access screen so players can access the tutorials. One thing I noticed that was really odd was how most if not all of the UI elements were hard placed into their positions. So the scrollbars don’t actually do any scrolling and if you look at the sprites of the UI elements, they’re kind of just the element itself placed into a bunch of transparent space. I think people used to use sprites like that, but in the modern day, we don’t really need to do that. Plus it makes designing for other aspect ratios more difficult. I was able to fix those issues easily by repurposing a few of the sprites and fixing the placement of all the elements so that they used Unity’s UI system.

  I made it a little easier for future programmers to make levels by making it so that they can type in the title and descriptions for their levels a lot easier. If you type [TextArea] above some strings you want to edit in the inspector, you can make the text box a lot bigger so that you don’t have to write paragraphs in the default singular line Unity gives you.

Sprint 2 (Aftershock Simulator Sprint 15) 

  Hello! It’s sprint 15 of the Aftershock Simulator project. In this sprint, we had 97 points assigned and 48 completed. More than last time, but to say it’s been a bit of a rough transition is kind of putting it lightly. Later in the sprint, our team had a discussion with our teacher, who is the head of the project. Unlike the previous semester in which there was a student as a designer, our teacher would now take their place in order to avoid this rough transition that we had with future development teams.

  One thing I had a bit of difficulty with is that for most of the sprint, I didn’t have access to Github which hampered my ability to understand how the code in the project worked and even how programmers would cre

ate new features. Now that I do have access, I am again worried because I’m a sprint behind everyone in understanding the code better and also it’s kind of a mess. Our main UI designer wanted to rehaul the in-game UI, and that’s going to end up being more of a challenge than expected since code is a part of every single

aspect of the game. We definitely don’t want to touch the code without breaking anything.

  Since we were kind of directionless for part of the sprint, we had a meeting in the middle of the sprint to better understand what our direction was going forward for our team. What the previous team was doing was essentially pre-production and creating the foundation and tools for future teams. What we’re doing now is building the path that the users of the Aftershock Simulator are going to take so that they truly understand the learning objectives.

  The learning objectives are: to be able to define what an Aftershock Forecast is; to be able to describe when the Forecasts are updated; to be able to interpret how the Aftershock Forecasts work; and to be able to find where the Aftershock Forecast webpage is. What we’ve decided to do is to create a really simple level-based tutorial system. The San Francisco level that’s currently in the game right now is way too complicated for a normal user to understand, so we really need to roll all the way back and reteach them. Unlike what us students are used to, our target audience is explicitly NOT gamers, so it’ll sound like we have to “baby” them throughout our tutorial levels.

  Since the San Francisco level attempted to teach everything through dialogue on the phone our levels will be broken down into very small parts. The first level will show the user what an earthquake is, and then the next one will show the player how to move the camera. To go along with this, we’re going to implement an objective system so that the user can keep track of what they have already figured out what to do.

  Another thing we also discussed adding in was a dev hack for us. There is a pre-survey that users must take so that we know what they’re thinking beforehand, but us developers don’t want that. So next sprint, we’re going to add in a system which will let us use certain commands to bypass certain things in order to make testing things easier. Although, other than the pre-survey, I’m not exactly sure what else we need to bypass.

Sprint 1 (Aftershock Simulator Sprint 14) 

Hello! I’m the new producer on the Aftershock Simulator project for the USGS program. The Aftershock Simulator is created with the intention of teaching potential rescue workers how to best save as many lives as possible in the event of an earthquake. As this is a project that’s being continued rather than starting from scratch, I needed to read through the notes that the previous team left over while devising new tasks for the new team. I was a bit worried about not being ready for kickoff, but now that this sprint is over, I think I and the team have almost gotten ourselves familiar with the project and are mostly ready to go. In this sprint, our team was mostly reading through the learning objectives for the game and understanding what was already created. I assigned people new features that might have helped to introduce them into the project, but most of those were not completed just yet.

For this sprint, I assigned the team 81 points and 34 of those were completed.

That doesn’t seem good at all, but that’s because the new team needed to get familiar with what was already in the project. In order for the programmers to start coding anything, they of course need to read through the code and understand what’s going on. In order to make sure they understood the code, I asked the previous designer of the project to devise a little quiz for the programmers to do so they could have a bit of a guide on what to pay attention to when reading through the code.

Excerpt of the code understanding quiz for programmers!

This turned out to be WAY more daunting than expected. For example, it was difficult to find certain scripts as they were mixed in with commented out scripts that didn’t do anything or placed in folders that you wouldn’t think to look in. One new thing I learned was that the commented out scripts are industry standard so other programmers can reference them, but unfortunately it’s frustrating to sift through. Currently, the programmers are still in the process of doing that little understanding quiz, but now they can at least somewhat understand how to code for what they were assigned. I was really scared that I needed to cut down on their load, but they assured me that it was alright.

The way that the class is formatted is a little bit odd in that the animators and the audio creators in the class aren’t assigned to a specific team. Since our project already has work done on it, they were directed to us first. I wasn’t able to give anything to the animators because there doesn’t seem to be anything that requires special animation (yet). I struggled with thinking of stuff for the audio people to do, but I was able to settle on a few soundtracks and some sound effects. Feel free to listen to the main menu music. Although, since there were already sound effects in the project, it’s only going to get harder for me to assign them work!

For the future, there are a few things that I need to pay attention to. One thing that is of utmost importance is that the AI needs to be nearly redone. In the notes, it says that the AI needs to be remade without the literals it currently has. This is going to take a large amount of time and is clearly more difficult than it seems. Unfortunately, I am not a great coder, so I’m going to have to rely on the programmers to tell me their process on how they’re going to recreate the AI so that I can write their cards more effectively. Another thing I noticed was that there seemed to be no feedback as to whether the player was actually saving anyone, so that has to be paid attention to in the next sprint. There also seemed to be a small bug in which the building repair time didn’t display properly. Also, there is no actual end programmed in the game, so we’re definitely going to have to get that done soon as well. I would have assigned these at the beginning of this sprint, but I was incredibly terrified of overloading the team with things they didn’t understand yet. Here’s to a productive development period!