By: James Keats | 11 October 2017
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.
Still, all of us have been working hard. I won’t go in-depth about these items here, but Tyler, our artist, has been working hard on character animations which you’ll see in the videos below, while our designer, Charlie, has been working on SFX and a new level for the game. You can out Tyler’s blog here and Charlie’s blog here. Here’s what I was primarily working on:
One of the most significant and repeated pieces of feedback we’ve gotten from QA so far has been that players have a difficult time telling when they’re taking damage, and when they’re damaging enemies. Part of this will come a little further down the line with improved sound design, but the easiest thing we could do in the moment was to create a classic FPS screen-space damage indicator, as well as a particle system on enemies when they’re hit.
The most difficult part of this was determining how to rotate the 2D image of the damage indicator arc depending on where the damage source was located. The final solution for this can be found below:
In addition to the above radial indicator, we also flash a full-screen red vignette to tell the player that they’ve been damaged. Feedback so far indicates that this is an improvement, but we still need to do more. We may explore options like screen shake next, but ultimately our goal is to convey most of this information through the sound design.
One of Charlie's next requests for Modulate was the ability to design damage falloff over distance for the different weapon combinations. This value can make gameplay more interesting as it requires players to get close to each other to do enough damage to get a kill. The system is designed such that each projectile (bullet, grenade, and rocket currently) has a falloff curve, and then the weapon parts are able to modify the distance that that curve applies over.
We discussed the possibility of allowing different parts (such as the barrel) to modify the curve directly, but decided that the math for that would become too complicated to properly visualize the result of different combinations, the gameplay benefit would be minimal, and it would be more complicated to explain to players what was happening.
A few other, smaller items went in this week, one of which we've been eyeing for some time: different fire modes for the weapons. In the past, the player could just hold down the fire button to shoot regardless of what type of gun they had. Now, Charlie is able to define a maximum "shots per click" for each barrel, resulting in more varied gameplay; for example, pistols must be clicked anew for every shot, the minigun can still be held down as before, and we have a new "burst fire" rifle barrel that gets three shots per click.
We also brought part durability back into the mix, networked now. This will have to be reworked during the refactor of all the network code, but it was at least testable (and got positive feedback). We also did a first pass on post-processing (as visible in the damage indication video above) and I helped support Tyler with the animation implementing and Charlie with the new audio implementing.
Overall, while this week was a little slower due to our well-deserved break, we’ve still made some great progress and I in particular am looking forward to the major refactor and rewrite of our network code to bring it up to where it should be next week.