CAGD ePortfolio

  In this second sprint, I think I can say our team was able to get some work done. The marketing team meetings really eat into class time, which is kind of annoying, but at least we are mostly out of the pre-production phase. The other people on the team still need some time to familiarize themselves with the project.   Meanwhile, our programmer went to work on creating an “earthquake scheduler” scriptable object that could be used to plan out the earthquakes so that users could potentially create their own scenario and see how the earthquakes affect the map at certain times. I really like that the programmer made documentation even someone like me, a less than middling programmer, can understand. At the moment, we’re waiting for the earthquake data from the USGS scientists to come in so we can make sure that the scriptable object is accurate.   Our team had to meet up with the marketing team to talk about creating a new name for the game, as “Aftershock Forecaster...

  This semester, I am still the producer on the USGS Aftershock Forecast project. Despite being experienced on the project since I was on it last semester, it’s still no less nerve wracking than it was when I first started. Unlike last semester, we were actually able to have first-person talks and playtests with people from USGS.   One thing I considered unexpected was the type of people that would be brought into the project. I thought we would get another all-programmer team like last semester and continue what we were doing. But instead, we get a definite designer (although technically all of us can design) and just one main programmer. We are potentially able to have more programmers working on the project if the other teams have them free to do things. Although, we can never have enough programmers.   This sprint ended up being a pre-production phase, and our in class time was taken up by meetings with a marketing team. I remember the team being vaguely mention...

  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 O...

  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 ...

  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....

  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...