Command Args Parser Update

Made a small update to the GitHub repository for the console command variables and functions library I've been working on.  Now both functions and variables can use functions with pre-computed hash values.

Variables Before:
CommandArgVariable g_testInteger("g_testInteger", CommandArgVariableType::Integer, 0);

Variables After:
CommandArgVariable g_testInteger(HASH_COMMAND_VARIABLE("g_testInteger", 0xf681f79d), CommandArgVariableType::Integer, 0);

Functions Before:
CONSOLE_COMMAND_FUNCTION_HASH(SetPlayerPosition)(CommandArgsParser & args) {

Functions After:
CONSOLE_COMMAND_FUNCTION_HASH(SetPlayerPosition, 0x13748f32)(CommandArgsParser & args) {

This has numerous benefits related to code size, initialization time, and perhaps most importantly security.  Unfortunately the trade off is that programmers need to calculate the hash value themselves.  To ease with this I've added 2 defines that allow you to compile an executable that makes this pretty easy.  By defining _HASH_COMMAND_VARIABLE and compiling you can create a simple command line utility that formats the HASH_COMMAND_VARIABLE macro for you.  By adding the folder this executable lives in to your system variables you can open up the command prompt and copy paste the values fairly easily.  Another _HASH_COMMAND_FUNCTION define has also been added to do the equivalent for the CONSOLE_COMMAND_FUNCTION_HASH macro.

Browse Commands Arg Parser On GitHub

Doom: Eternal Recap

I started working on Doom: Eternal in January of 2019 until it shipped in March 2020 and I am still actively supporting it post launch today.  The commercial and critical feedback for Doom: Eternal has been very positive despite a pandemic forcing the closure of many retail outlets (yes people still buy games that way).  Some reviews have called it "one of the most intense shooters ever" and others have even given the game perfect 10 out 10 scores!

My personal experience differed with the one I had with Red Dead Redemption 2 for numerous reasons.  The team was much smaller, the genre was a first person shooter rather than an open world game, and rather than being on the project from the very start I joined relatively late into the development cycle of the project.  This meant I had to carry existing features across the finish line more often than architect them from the ground up and I had to become acquainted with these systems very quickly.  The project was originally scheduled to ship in November of the same year so this "whatever needs fixing fix it" attitude was more or less my experience working on the game.

Rather than linking to other videos I captured and edited some footage myself this time.  The compilation below does a good job of quickly demonstrating features I contributed to on the project.

You will likely want to  watch on YouTube and manually set the quality to 720p to get an acceptable resolution compared to the embedded video.  I captured the footage on an old 1680x1050 display and apologize for the inconvenience.

 

Weapons

I spent a lot of time working on the player’s Ballista weapon.  This included work on all 3 fire modes, the AI gore wounds used when hit by it, damage related issues, and the impact VFX.  This resulted in adding a few collision filtering features to our physics system, special shapetests for the primary fire, adding support for ‘sliced’ full body gore wounds, and splitting up the VFX into multiple instances for different positions and normal.

I did a lot of work on various weapons in the game aside from the Ballista.  This ranged from various damage issues, queueing up the equipment launcher, hit scan logic, smoke bombs for the playable mancubus, and many issues related to the upgrades for each weapon.

Gore

I fixed numerous features for gore systems and added a pattern for the destroyer blade gore cut behavior that could be re-used to replace demons with custom rigs, split ragdoll constraints, and shoot the pieces off with a random range of speed and direction.  I also worked on other gore behaviors like the blood punch, syncing wounds for multiplayer, and the deferred blood pools left behind by a corpse.

Multiplayer

My previous industry experience at Rockstar Games always used a peer to peer networking system which would migrate ownership of entities to different player machines during active gameplay.  Doom: Eternal was a fun learning and growth experience for me because it instead used a server authoritative method.  This meant I needed to learn new methods to deal with things that needed to be client authoritative such as hitscan weapon hits and how to validate it on the server.  Animation issues also could be much more difficult.  Previously during something like a ledge grab with a peer to peer setup we could simply disable all network blending but with a server authoritative setup this got much murkier and complicated than that.

I supported many gameplay features specific to our PVP gametype known as Battlemode.  This included demon character work (e.g. the revenant jetpack or the marauder shotgun), summon wheel abilities, 3^rd person ledge grab animations, 1^st person spectating, and a considerable amount of work adding features to our visual scripting system for the Battlemode tutorials.

Misc

• Soft body repulsors that prevented characters from visually clipping into each other
• Contributions to a heat map performance tool to find bottlenecks in a level
• Contributions to player customization from getting skins to appear in cutscenes, animated deaths, and on remotely controlled clones in multiplayer
• Gore nest secret encounter systems support
• Boss voice over audio for the doom hunter boss fight
• Numerous bug fixes for VFX, damage, stats and milestones not working as intended
• Rune prototyping
• Various UI and menu support