CAGD ePortfolio

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

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

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

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

  Sprint 6 was mostly a sprint with not a lot to do. I basically had everyone finish up everything they needed to do on the project. Programmers always have stuff to do, but it was a little bit difficult thinking of things for the others to do, since there’s no time to fully implement a new level design and there’s not much of a point in adding new models. It was also time to start working on the marketing images, so I had a person on the team start on those. Since I’m the person who works on the UI, I thought it would be a good idea to begin working on making the menus look a little prettier. I bet players don’t want the default Unity UI in their game. Figuring out things to do for the modeler and the texturer were somewhat difficult. We were able to find some textures that needed to be done that happened to have slipped through the cracks previously, which was good. But in the next sprint, there’s basically nothing to do. For the modeler, I had him mostly focus on getting the...

     For this sprint, I mainly focused on getting the build to work and did some more work on the UI. To be honest, I feel like the team’s output in this sprint was not too great. Although, that was probably only because the last sprint’s output was really great. I usually remind the team to get at least one thing completed on the board so it doesn’t look like they spent 5 days doing nothing. Because there was a class that was canceled, people aren’t going to use that time to focus on the project, so I was unable to approve any work for nearly a week. I don’t really like to bug people on that since I know everyone’s extremely busy, but it was really concerning to me. We were able to make it up in the second week of the sprint, but consistency is important.      In the last sprint blog, I talked about how the build was incredibly laggy, which would definitely have an impact on how a player would play the game. I looked at the Unity profiler, which told me th...

  For this sprint, the goal was to get a new level in. We have it in there, and you can play through it, but obviously it’s still unfinished. I spent the entire night before sprint review thinking that we needed to get it done right now, so I ended up rushing the programmer to fix a bug with the mazekeeper transitioning to the next level (which he did but he ended up forgetting to do some of his own homework that was due that day). I feel really bad about rushing him, but the act of putting together a new build actually turned out to be a good idea. When I tested the build out on the high performance computers in the library, the frame rate was absolutely terrible. It’s a good thing I saw this problem now and not later when we actually do need the build out. Footage of the current build.      At the moment, I’m not exactly sure what is causing the bad frame rate. In our game, we’re putting all the levels in one main scene so that we don’t have to mess with scene tran...