My Job

As a programmer, most of my work has been aimed at improving the engine and it's performance, help other coworkers with physics, develop tasks in the Stage and Puzzle scrum and lend a hand to Combat and UI scrums.

In the firsts steps of the project, i have spent my time implementing our physics system based on nvidia PhysX lib and adding new features to fulfill the needs of the team. I also have been taken part in the development of two puzzles, the barrels puzzle and the pressure plates puzzle. I have helped other scrums like the combat one adding physics to the projectiles, weapons and enemies, leting them interact and spawn particle systems with desired collisions or the UI scrum creating a system to resize UI using anchor points.

Finally, due to low engine performance, I have worked hard to improve it, mainly upgrading gameobjects culling and removing leaks.

In collaboration with Joan Pareja, we have added a new module to handle physics simulation. Starting from nvidia PhysX lib as base we have done an abstraction layer to integrate physics within the engine. Due to the low requeriments of the game, only basic functionality has been added. The initial elements has been: component collider, component rigidbody and component joint.

From that point, I have taken care of physics in the engine and I have added new features and functionality to match the needs of the project.

Features added:

• Trigger and Contact collision callbacks
• Continer for Contact point data
• FilterShader to detect collisions using gameobjects taggs

Scripting Features:

• OnTriggerEnter, OnTriggerLost, OnContact
• Lock and Unlock motion/rotation
• Apply Liniar and Angular force/impulse
• Move Kinematic and static colliders
• Enable/Disable colliders
• Physics Raycast that return the gameobject

I have refactored the component transformation to improve its performance and add some functionalities. The most relevant is the possibility to edit transformations in two diferent ways: Local or World transform. The last one, first update the global transform and then calculate the local.

Related to In-Game transformations, scripting can modify both transformations and use extra functions added like: SetForwardVector, SetUpVector or SetRightVector.

My coworkers in the UI scrum have had problems when considering how to use anchor points and then rescale the UI, so i have volunteered to face that task. To solve that task I have done the anchor poits and the option to rescale using uniform scale to keep textures proportions or adapt elements to screen scale.

The engine should be able to handle multiple scenes at the same time, for example, the level and the pause menu. The reason for this was to have two scenes, the primary and the secondary, and switch between them realy fast. Only the primary scene needs to be update and recive input events.

To load multiple scenes at the same time I have taken as reference the work done by Eliot Jimenez this system can load a scene in a secondary plane and keep the current scene until next one is loaded.

In the first half of the project, we have had a lot of bugs and random crashes due to objects deletions. Later on i have solved this problem refactoring scene clean up, gameobject deletions and reference removal from scripting system.

Since the work had to be done and the time was limited, some things have been skiped, one of them is the efficient managment of memory. In the late stage of the project we have realized that due to that we have had many memory leaks. Using deleaker as a main tool i have identified the most relevant leaks that might affect gameplay and I have removed them.

Along this task, the leaks has been reduced by 75%. The remaining 25% of leaks are due to the engine itself, this leaks are small in size and hard to solve without getting involved in a huge patch, so we have decided to let them be.

At the last milestons of the project, we have realized that the overall performance in-game was rather low, so a few coworkers from the Stage scrum, the lead Programmer and I have tried to solve it. One of the major problems has been the render of the lights and the huge amount of gameobjects in each level. Since I didn't know how the shaders and lights worked i have tried a different aproach to reduce the compsumption.

Until that moment, we were using Octree as a Camera culling tool but due to the game being a tile based game with lots of gameobjects in every tile the process to collect candidates was realy slow. We have tried to reduce this time by switching the way we iterate through the hierachy, on the other hand I also have modifyed the alorithm to check if the bounding boxes were inside the frustum, but with both improvements the result has been of about 15% less time (1 ms). The results of this improvements have not been good enough for our goals.

After that I have tried to filter the dynamic objects, which at that point of the projecte were always drawn, using a faster aproximation of camera culling, with this improvement the dynamic gameobjects drawn have been reduced about 60-80%. Even with that, the performance remained low so we kept thinking a way to improve it even further.

The best option we have found is to use a grid based collect candidates, I have implemented this grid based culling and the results has been quite amaizing since the time requered to collect candidates has been less than 5% of the previous time.

One of the best things of 2D grid culling in a tile based videogame is that we can oclude tiles in a easy way and win even more performance by reducing the amount of GameObjects drawn.

So that is what i have done, Elliot Jimenez have created a tool to edit oclusion maps, with the help of this tool I have done the frustum Oclusion culling to oclude tiles and skip the need to check and draw the gameobjects within them.

In the next photo, which is a screenshot of the smallest scene without some walls to see through, before the Oclusion Camera Culling is done, 456 GameObjects have been drawn. After the Oclusion culling only 72 of them have remained, this diference of 384 objects has helped us to reduce the render time.

This has been the first big puzzle made by our scrum. In the first iteration of barrel puzzle we have used physics to detect collision and make the barrel fall down. I have added joint component to the engine and I have used it to connect the chain and the barrel. When the player interacts with the barrel collider (shot or attack) the joint is destroyed and falls down building a floating path above the valyrian pool. I have implemented Physics mechanism and the scripts to detect collisions to make the barrels fall down.

After that, first I have fixed some issues related to the generation of paths to cross the pool, and then I have added a lever to start the puzzle and chains which are moved in a synchronized loop with the barrels.

At the end, we have had to remove the physics due to lack of sense of applying physics to our puzzle and the negative impact of the low engine performance which makes the physics behave wrong.

The pressure plates puzzle have been proposed in the last half of the project because at that moment the engine had improved enough, we could split the work in smaller teams. My task have been the development of this puzzle which consists of a follow-up of pressure plates that modify the way forward. The player must proceed through a room full of obstacles and pressure plates until reach the exit.

Being a videogame where the characters have different weapons, some of them range weapons, we had realized that the physics would have a very important role around the player. Therefore, from the beginning I have been helping the player scrum with character's attacks and interactions.

Among the needs that had been raised was to shoot projectiles and detect collisions with obstacles or enemies. I have made the script to shoot arrows and fireballs, also the one to destroy the projectile after collision, and then create a particle system in the point of impact and apply damage if the projectile clashed against an enemy. The mele combat uses a combination of raycast and dynamic collider to attack with the sword. If an attack lands on an enemy, particle systems emulating blood spatter are created at different collision points with every slash.

Levers are used almost in every level as a mechanism to open doors or start puzzles. As the lever collider triggers the player, the ui button to interact with, appears, when interaction happens the animation starts and finally the linked functionality goes into action.