Aftershock Response Manager - Sprint 26 Review
This sprint involved a lot of 2D and UI design for both the screens that played at the beginning and the end of the Sandbox mode. The custom scenario screen was re-done and re-stylized so that the assets felt like they fit with the color palette and overall design of the game, while also providing the player with a wide range of tools that they will have access to in the sandbox mode.
After that, we also wanted the evaluation screen to provide relevant information to the player about how well they did in the scenario, how long it took them, and the number of earthquakes that occurred, along with the corresponding magnitude of each. We want this screen to reiterate that looking at this information will help EMs make more informed decisions because they can see the results of the scenario that they might be able to predict (have control over in the game) and then translate that into a real scenario using the system we've build
Finally, I also saw that we were getting feedback from our USGS clients who gave us feedback on the systems we have implemented thus far. I corresponded with them about what changes we can make for the last few weeks, and I think we can fix the MMI tutorial to add relevant information & get some of our systems working in time before our date. We have a lot to cover in that time frame, but I think if we can do it the game will be in a much better place.
Aftershock Response Manager - Sprint 25 Review
This sprint was a hefty one and one that took a lot of willpower to get through because I was sick, but was still trying to make sure that every level we had was up to par with where we wanted it to be, as I was making an attempt to rewrite our tutorials to make them more focused on what emergency managers actually get out of the game, along with giving them more resources and more information.
After the usability playtest from the last sprint I began to focus on refining, reorganizing, and spell/fact-checking our tutorial to make sure that the game is not only scientifically accurate with the information that we give to players but also relevant to emergency managers and the situations that they might be placed in.
I spent hours combing through each and every instance of dialogue that we had to make sure that every piece of information was concise but not overbearing. I also wanted the gameplay tutorials to have more of an impact. Before, most of the tutorials were
Before my restricting of the tutorials, there was simply information about the tutorial telling you how to click things and where to find certain pieces of information. While that was still something we wanted to have in there, I wanted to make sure that it felt more streamlined and also included explanations about WHY this information is important and what they can do with it.
Not only that, but I also made sure that the tutorials we did have had more links to USGS resources regarding what was presented. For example, something else I worked on was the implementation & refinement of a new level for teaching the MMI scale, a scale that measures the intensity of an earthquake as felt on the surface, not like Magnitude which is the actual force generated.
My process for updating the dialogue was putting each instance into Grammarly, checking USGS to make sure that it was accurate, and then making sure that the flow of information within the game made sense. Once it did, I reorganized the dialogue boxes to make sure that it was in the same order as the game.
I was debating if I should have asked for more points on the card or for it to have been split up, but ultimately I think it's fine because I don't feel like I did as much as I could've in previous sprints. Next sprint I will be refining the sandbox UI and listening in for anything else we might need. I'm hopeful now that the project will be more well-defined and have a solid gameplay structure.
Aftershock Response Manager - Sprint 24 Review
This sprint was an important sprint for us because we finally had a big usability playtest that gave us useful feedback that allowed for us to dial in on what needed attention for the remainder of the project. Originally the scope of the project was supposed to contain another year of development with overlapping people, but because that got cut out we've been somewhat scrambling to get the project in a place that is close to what the original vision of the project was going to be.
However, now that we've gotten great usability testing, the feedback was that the tutorials need to do more than just explain how to use the controls and click things, but actually explain WHY what they're interacting with is important and why that data they get to see in our game matters. I had already started working on a few tasks before this test, but after the test my focus will very much be on the feedback.
Another piece of feedback we got was about the camera's functionality. While we could see the issue and would like to fix it, we didn't think that fixing the camera, even if it is a small task, is worth putting our time into considering the requirements and learning outcomes we'd like to hit.
I did work on a dust particle scaler that would adjust the visual effect of dust based on its magnitude, and our awesome programmer Bryan collaborated with me on that. Unfortunately, I am not as experienced as him, but it wasn't too bad to try and figure it out together. 
I also started working on the Scenario Creator that we are going to add to the Sandbox mode for the game, so I started by setting up a basic UI for how we would like it to work. We want the player to either be able to add their own earthquakes or for them to see the sequences that happened during the Turkey 2023 earthquakes.
The most important piece of work this sprint was something that I wasn't able to get to till the end, and will continue on with it to the next sprint. This would be me going through all the dialogue and the tutorials we have currently, and then explaining the scientific information that is conveyed through the tutorials more efficiently and with more prominence. While we want the game to be accessible to people who aren't tech-savvy, I think that the ultimate goal of the game is to educate on the science, and I will be doing some restructuring of the game to make sure that's the outcome. So I might be adding more things like linking to USGS resources, deeper scientific explanation, why this matters to EM's, and more.
Overall though, I do feel that this sprint was harder because I didn't have a clear direction to go in this sprint alongside the fact that other classes and breaks got in the way of me being as productive on this project as I would've liked, but I am looking forward to pushing through next sprint and seeing what more we can do, as I want this game to be as best as it can be before we show it off in San Francisco.
Aftershock Response Manager - Sprint 23 Review
This week was spent primarily on reformation and continuing the implementation of the ideas presented in our big playtest. We also coordinated with the project's marketing team to discuss how we want to present the story of the development of this game for their stories and for the conference we'll be attending in May to show off and test the software.
We eventually renamed the game Aftershock Response Manager, as this fits its serious nature while concisely explaining its content. I also researched Emergency Managers to build a User Profile for the developers and marketing team to work with. This helped me verify that the information we provided in the game would not only be accurate but also helpful to them in understanding that aftershocks are an integral part of the experience of managing earthquake disasters. Myself and a couple people from the marketing team shared the information we had gathered on our users as a way to 
I worked on a couple UI indicators to signify that objectives had been completed and to rename the game to the correct name. I then started programming a system that would allow for the dust that the earthquake emits to scale with the shaking intensity such that the dust appears larger when the shaking is more intense.
Messing with the Unity graph editor and figuring out how to program the system to make the dust scale with shaking is a challenge, one that I hope to solve soon. I am still in the process of figuring out which way would be easier to implement. Although I am not a programmer for this project, I do feel that it is important for me to learn how to implement something from a technical perspective, even if it is a minor feature especially because of the scientific accuracy that we must abide by.
Aftershock Forecast - Sprint 22 Review
After an informative and productive playtest with the USGS, we came to a conclusion about what we needed to implement into the game and how we wanted to rebrand. Our first order of business this sprint was to collaborate with MADT students to rename the project as there is another product being developed by USGS with this same name. We had landed on a couple of names, and one that the development team liked a lot, but will have to go back and have another discussion as the names we'd chosen didn't fit our target audience.
One of the primary goals I focused on in this sprint was figuring out how we wanted to explain the differences between magnitude and MMI. MMI represents how destructive an earthquake is to the surface, like ground and building damage. I designed an accessible piece of UI so that the player could always see how intense the magnitude of sequential earthquakes can be while working on another level that goes over the distinction between the two. Since EMs are likely to be worried about the damage that's caused to people and buildings, the MMI needs to be front and center and become a primary learning objective for them.
I made some adjustments to the camera shake for the dramatic and visual effect of feeling the earthquake when it happens so that the camera's shake intensity is directly lined up with the Magnitude (or more accurately the MMI) of the earthquake, so the values can reflect the intensity that is shown after the earthquake finishes.
Lastly, I read a research paper on how the aftershock forecast was used in the Canterbury earthquake and what kind of information was desired from EM's for a tool like this. Overall, this sprint was heavy on the research and the refining of current systems, so next sprint I'm looking forward to seeing what else we'll be working toward.
Aftershock Forecast - Sprint 21 Review
This was my first sprint for the production of aftershock forecast and it's been the most unique game development situation I've been in so far. As I had been pulled into the project at sprint 20, there have been several teams before me trying to implement this system and make it fit the needs of our client, the USGS.
I am part of a smaller team compared to the other teams in this class, so we were getting up to speed with the project alongside talking to the USGS and figuring out what they wanted out of the game.
During the first week of development, I playtested old builds that we had to see if any key issues could be addressed alongside trying to brainstorm some ideas for a gameplay loop, but since I wasn't sure of what the client would want and didn't know about the learning objectives, these became obsolete fast.
The second week began and we eventually were able to find out the needs of our client. We had dinner and a playtest where we had them try the game and ask them what we needed to change. I was writing down those notes so that we could keep a clear idea of their needs and what kinds of changes we could make to our system, and luckily I think we've come to a point where there is a solid direction for the game. Now it's up to us to figure out what kind of system we want to implement and what we need to change. Next sprint will probably be full of actual production to be done.
No comments:
Post a Comment