CAGD 470 Group 1, Sprint 4
- Els Fouche
- Mar 27
- 6 min read
Kill Everything As Fast As Possible
Kill Everything As Fast As Possible is a 3D first-person boomer-shooter where you take control of a killer AI hell-bent on destroying every human in sight.
Project Credits:
Daniel Bocanegra-Ramos: Lead Designer
Jack Bradford: Producer
Dylan Brown: 3D Artist
Els S. Fouché: Lead Programmer, Level Designer
Sean Gibson: Programmer
Sophia Villenueve: 2D Artist
Rayen Yousfi: 3D Artist
GDC
During this sprint I was away at the GDC Festival of Gaming (formerly known as the Game Developer's Conference). I was grateful for the opportunity to work as Festival Crew (formerly known as Conference Associates) during the event as it enabled me to meet so many other passionate game developers. The professional development workshops I attended strongly influenced me; I feel strongly that they will prove useful in my career.
As preface to talking about the work I accomplished this sprint for KEAFAP, indulge me in discussing some numbers. This sprint totaled 10 regular work days and, because as students we're expected to work on weekends, four irregular work days. As I was working at GDC instead of just attending I was required to be there early and to leave late - this meant I was unable to work on this project for nine out of the 14 days available. Of the remaining five days, all other projects and trip preparations needed to be squared away. All told and much to my chagrin, I had precisely one day to work on this project. Considering the importance of a certain upcoming playtest, I'm unfortunately going to need to deprioritize other areas in order to make up for the lost time.
Movement Mechanics - Momentum & BHopping
Let's move on to the elements that I was able to complete. Our producer Jack and I definitely learned some lessons regarding how best to hand off a project in situations like this. The biggest pain point from these lessons was figuring out how to handle kick-off and the subsequent secondary kick-off after I returned. Specifically, we had an issue where card prioritization slipped and I spent the little time I had available on adding to the existing movement mechanics rather than polishing the core loop of the game.
First up was adding a more gradual acceleration curve to the player's movement. This is a difficult element to capture in video but can be felt clearly when interfacing with the controls. Further testing will be necessary to dial in the values. Upon request I've included code snippets for this feature.
When the player initializes a movement input a timer is started (seen below). This timer gradually ramps the player's maximum walk speed. This approach was utilized to place more control in the hands of the designer than would normally be provided by the built in Character Movement component's acceleration settings.
When the player releases their movement input the timer and associated variables are reset. The haste with which I created this feature is apparent even in the variable naming conventions - "Speed Ramp Alpha Delta" does not accurately self-document its purpose and is far from being a designer-friendly name. Additionally, I'm performing a clamp after a set which is bad practice.
I remind myself often that we're in a prototyping mindset here - doing things fast is more important than doing them 100% clean. The functionality of this feature didn't quite feel right, however, so I took a second look at it.
The reworked timer event showcases the updated variable name "Time to Full Speed" which makes it clear what it does to both other programmers and to the designer that may need to modify it. The logic was also reworked such that the variable name wasn't lying about its function. I wrote v1 of this timer while co-working with my teammates and it's a reminder that I'm not the sort of person that can operate at full effectiveness in such an environment.
As shown in the video there is also a component to this feature that allows the player to gain more speed by hopping repeatedly within a short time window of landing. In the code snippet above this is handled by the retriggerable delay that's set to two seconds - this value will be designer-configurable once the feature is fully approved for addition to the game. As I mentioned, there was some confusion with regards to task assignment this sprint which resulted in this piece of the feature's creation. As an aside, 'bhop' refers to bunnyhopping which is a movement exploit in Source engine that allows players to gain speed by repeatedly jumping alongside other inputs. The additional input requirements have been removed to simplify this mechanic.
Movement Mechanics - Chain Hook
The 'Chain Hook' feature received some updates during this sprint.
The 'Chain Hook' ability allows players to attach to an enemy, pulling themselves closer and dealing a small amount of damage. This feature received a lot of updates in a short period of time:
It no longer attaches to walls; the player must target an enemy.
The ability deals damage when colliding with an enemy during the movement, including the targeted enemy.
The ability can now be canceled by jumping during it.
The movement speed of the player while attached to an enemy was significantly increased.
Affected enemies are frozen in place for the duration of the ability.
Penetration checking was removed. More on this below.
Previously the player was able to use the 'Chain Hook' to grapple to walls. This required that a series of penetration checks be performed to ensure that the hit location was a valid end-point. Now, the player can only move to the location of a target and so it is assumed to be a valid destination. The player does use their own height rather than the targets to determine the end point, however, to prevent falling through the ground when targeting small enemies. I've included the deprecated code below; the code was not designed for maximum robustness of end-point validation due to the high likelihood that the feature would be changed later, as turned out to be the case.
The ability freezes enemies in place when used - this might seem odd but I argued in favor of this for a couple of reasons. One, it's player-centric to have the destination remain fixed after selection; there's no chance that the enemy may walk off a cliff bringing the player with them, for example. Two, it avoids having to do continuous end-point and move speed recalculations which would have increased the complexity of the feature. Allowing for enemy movement while the player was 'reeling themselves in' would have required depenetration checking during the movement to avoid hitting intervening obstacles, or a full refactor to use non-deterministic movement methods.
Here are two additional videos of the 'Chain Hook' feature. The jump-to-cancel element has been updated to guarantee a jump regardless of the player's current double-jump state. In other words, the player always gains height when cancelling the ability even if they've already double-jumped. Previously, if they did not have a double-jump available they would simply fall out of the 'Chain Hook's movement.
The 'bump' feature of the 'Chain Hook' is shown in more detail in the second video. This feature does not perform as consistently as I would like - further refinements are likely to be necessary, time permitting.
The 'bump' code is shown above. By taking the location of the target B and subtracting the player's location A we create a vector C with origin 0,0,0 and a magnitude proportional to the distance between B and A at the time of vector C's creation. We normalize this vector to the 0-1 space to use alongside the 'Chain Hook's impact force to determine the directionality and force to launch the impacted actor. We then overwrite the Cz with some arbitrary small value to prevent launching enemies downwards into the ground. The value 100 was selected to provide just enough upwards force to overcome ground friction. I've included the full code for the 'Chain Hook' feature below.
Feature: Chain Hook
Pixel & Color Limiter Shader
Prior to leaving for GDC I also created a very simple post-processing shader that applies a pixelated effect to the rendered scene. The shader also includes a basic color limiter that reduces the total number of colors on screen to some specified amount. This creates a sort of video compression effect that's most noticeable in smooth gradients, which instead become visibly banded. Both the level of pixelization and the color reduction are designer-adjustable using a material instance. Further updates are likely to be made to this shader to allow for any object in the scene to adjust how much this effect applies to it.
Summary
The key takeaways from this sprint were that first, GDC was an amazing and exhausting experience. Second, the combination of GDC and Spring Break made it especially challenging to allot time for this project. Third, getting back into the project was unexpectedly joyful - I've found myself looking forward to the time I spend working on this game. Unreal wants to make experiences like this and it shows; every feature emerges with a minimum of friction. Now it's time to pull it all together.
Comments