Hard to believe we’re just about halfway there! It’s easy to see that the game is starting to shapeup. Here’s what I did this past sprint:

Another week, another re[Mod] technical update!

WeaponView Refactor

One of the issues we were running into as re[Mod] has expanded more and more is that the BaseWeapon class had grown a little out of control. BaseWeapon handled combining all of the stats from its component WeaponParts, handling the logic for things like shooting, reloading, aiming down sights, serializing all of the necessary data across the network, and presenting the player with a visual response to their actions (such as switching the model pieces when changing weapon parts, activating particle effects while shooting, etc). The result was a file that was over 1,000 lines long. It was split up into #regions, but I still always dreaded it a bit when going into that file. 

This week on re[Mod], we saw a lot of improved player feedback, some new features, and more refactoring of the network code!

Improved Feedback

This was something primarily handled by our other programmer, Justin. We’ve included screenshake when the player is injured, improved reticle response when dealing damage, and an improved hitmarker when being hit. I also worked with Charlie, our Lead Designer, on implementing better audio feedback for all of these events as well. This tied well into the “bullet refactor” performed last week.

This week saw some new progression in re[Mod], but it also saw me come down with the flu, so my contributions this past week haven’t been quite as large as I would have hoped.

Redoing the Sniper Scope

There were some important improvements made, the first of which being that the sniper scope “aim-down-sights” effect was rewritten to use a screen overlay instead of the mediocre “move the gun to the center of the screen” that we were doing before. Initially, my plan was to essentially use a switch inside the WeaponPartScope script which would cover the different effect types, but I quickly found that that was not flexible enough, as different effect types would require different types of data and exposed variables.

Weekly State of the Repo

This past week, we successfully passed into Proof of Concept, and are planning to challenge yet again to get into the Vertical Slice stage. At this point, we can all feel the pressure fully on–there are less than 4 weeks until the mid-year show presentation, which leaves about 3 weeks to actually work on the project if we want as much time as possible to prepare for the presentation itself.

Weekly State of the Repo

It’s hard to believe, but we’re currently about halfway between the start of the semester and Thanksgiving, which means the mid-year show is coming up quick. Modulate is still on route to be a strong candidate to go forward next semester. Visible progress this past week was slower than usual due to a couple factors. Firstly, next sprint I need to refactor all of our code that touches networking–something that made the entire team weary of adding new features this sprint; secondly, this past weekend was Fall break, giving us a four-day weekend that the team has definitely earned.

Weekly State of the Repo

During our last class, we successfully challenged Initial Concepts and are thus now in the Deep Dive stage! Of our three prototypes, we decided to move forward with the Arena game, with one important change: QA feedback was nearly unanimous that the splitscreen controller-based version was not cutting it for players. Thus, the first thing we did this sprint was one of the biggest challenges we’ve faced as a team yet: networking the game.

We’ve also finally decided on a placeholder project/code name: Modulate.

Weekly State of the Repo

Work on Capstone has continued at a steady pace. This week was mostly spent putting “polishy” touches on our prototypes to make sure that we could take them to QA and get feedback on the items we actually wanted more information on, which sometimes requires a more complete experience than you really want to build this early on.

All tasks last sprint were completed successfully, rounding out to a whopping 28 hours logged including team meetings. At this point, most of our major mechanics are implemented in the prototype in some form or another, although most have a lot of room for iteration. This week was spent on the items that follow, as well as writing our technical risk document. A summary of all our mechanics listed in the doc can be found at the bottom.

Weekly State of the Repo - v0.02.02

Last week’s sprint was successful, and essentially all of the core mechanics shared between the different concepts have been implemented. We were finally able to complete some informal and formal QA testing and received good feedback about the direction we should be heading.

None of the tasks last week were so challenging that they stand out in retrospect as being too difficult. One important thing that we tried was a pre-sprint planning session on Wednesdays. Because our class is 8:00am on Thursday and all of us have full schedules for the rest of the day, we struggled the previous weeks to ensure we had a properly planned sprint by the end of the day when our task list was due. This week, we learned that it is significantly easier if we meet on Wednesday afternoons and plan out our tasks for the coming sprint with some room for flexibility based on feedback in-class.