I had the pleasure of working as one of the first hires at the Kabam Austin development studio. The starting size of the studio required people to wear multiple hats, which is one of my specialties. Rapid prototyping for projects was a mix of Unreal and Unity with a small core of people. I became part of the Engineering team as a gameplay programmer during our prototyping phase. Shortly after, Kabam decided on our studio's first project, Terragaul: Rogue heroes. Terragaul was a coop multiplayer mobile title initially inspired by Archero's gameplay. My role on the project was to prototype gameplay features, finalizing gameplay systems, optimize for network performance, integrate our custom backend data into abilities, and refine designer workflow. My primary gameplay focus was on projectiles, player abilities, in-session progression, and combat. Terragaul was a crash course in Unreal's synchronous multiplayer framework and Unreal's Gameplay Ability System; challenges that I thoroughly enjoyed.
Terragaul was a game dominated by projectile combat. As such, projectiles needed to be highly flexible and performant. For flexibility, character guns were able to fire in a variety of different shot patterns achieved through a handful of settings and curves on gun barrel components. Projectiles themselves could also house and use gun components for behaviors like splitting at a set range, exploding into multiple bullets when hitting a target, or firing random lobbed projectiles while traveling. Projectiles could be homing, lobbed, use acceleration and could animate any of those properties with curves. They also could change impact behavior on the fly to switch from destroy on hit, bouncing, ricocheting, and piercing. Projectiles carried a variety of payloads which could apply things like status effects, damage, shield breaking abilities, and critical hits. All of the projectile settings were defined in backend data, so that the could be modified in live-ops without any content patches. These aspects were designed to be layerable and accessible by the Gameplay Ability System so that Designers could enable or disable these behaviors at will. The combination of all of these features gave a robust toolset for projectile combat.
For performance, object pooling was an obvious requirement for the projectile system. Not only did it reduce the spawning cost and garbage collection times, it also gave a way to ease network overhead by not constantly establishing new actor channels for the spawns. Pooling was split into two separate concepts, server and client only pools. Server pools were collision and gameplay logic only actors, while the client only pools were the visuals fx associated with each fired projectile. To reduce the number of pools, projectile classes were consolidated to small sets of basic behaviors which then had backend data templated properties applied to them as they were pulled from the pool. Client projectiles were also allowed to do some clientside prediction for impacts and post impact behaviors due to the separation of visuals from the gameplay objects. With so many properties on projectiles, size of replicated data when firing was a concern that needed to be addressed. Due to the backend data definition and application of properties, Unreal CDOs couldn't be used as an easy way to get matching properties on the client. Initial tests had an RPC call for firing in the hundreds of bytes. By accessing client cached projectile template data through replicated ID, stripping down transforms to just 2 position components and a rotation, then compressing all of the results, the average size dropped down to 12 bytes per firing.
My previous experience taught me the need to constantly maintain data integrity for a project. An immediate goal of mine was to integrate Unreal's Automated Testing with our external data solution. This was a personal initiative that included creating editor access to the backend data and writing JavaScript code generators to automatically create validators based on backend schema. I worked with the build engineers to incorporate the process into the automated build system and Slack. The end result was consolidated test results posted to Slack each hour. Content team members were able to see data errors early and resolve them before the overnight build process. This became an excellent way to make sure that gameplay data was setup correctly for the project and was expanded to other systems.
Iteration times are key in game development. Although the technology foundation needs to be solid, the game will only ever be as good as the content that forms it. I strived to find ways to speed up iteration times for the designers. This included contributing to PIE (Play In-Editor) test paths that allowed designers to jump into maps with full player loadouts or test full floor layouts. I also supported editor customizations, such as extending blueprint editor graph pins to allow assignment of backend data through dropdown menus.