Martin Vilches

  During the sprint kickoff, the main objective was to polish enemies further and start making them work with the other features implemented in the game. So, a couple of points were the jumpscare, a watcher vision fix because it had some inconsistencies with the player looking at it, and finally, adding an enemy item drop when killed. I started by tackling what I considered one of the most challenging features to fix. I started by identifying the problem. At first, I thought it would be a problem with the vision detection; however, the problem was in the state machine, and there was an error in the prioritization of each state. After tweaking the code, I realized that the problem was more in-depth in Rage mode, which was taking priority over all roles even when it lost the player in sight. With this taken into account, I could fix the issue, and it was now working as intended. After working with the watcher, it was time to address another missing feature: nothing was dropped when t...

     During kickoff, two main objectives were assigned for this sprint. The first was to finalize the final feature required for the final puzzle to work, and the other was to improve the game's performance. A problem presented in the level design from the last sprint was that many of the levels needed to be optimized, with multiple extra colliders and game objects. I started tackling the most significant problem, the unoptimized levels. After reviewing them, I needed to identify the core problems with them, which were the following: Unstandardized measurements Too many game objects Unnecessary colliders. So, there were many inconsistencies in the measurements of the level, which meant some overlapping, which made the level inconsistent. I also noticed that we were using about 1800 game objects for a single level, which is not the most optimized for a single short level. Finally, most of the 1800 objects had colliders in them, and this caused a little lag spike in the gam...

  During the Sprint Kickoff, some bugs accumulated in my bug board that were crucial to fix to gather good playtest data. So, fixing those was the first priority before developing new features to add to the game. The objective of the Sprint was to solidify the core game loop into a playable and loopable state and tackle the game's UI. So, one of the major problems with bugs was the inconsistency that the slap mechanic had; sometimes, it would work, and other times, it would execute differently than intended. To fix this, I had to understand how to use a SphereCast, which detects all Colliders within a sphere radius that is not a game object in Unity. This allowed us to detect all the players within the sphere radius and push them if they were in the radius. After implementing this, the slap became consistent, and players could push each other with no problem. Another bug was a prototyped mechanic that was not meant to be in the game; when the player dived, it would cancel the reset...

  During Kickoff, we had a clear objective of what we needed to do during this sprint. Since a couple of Sprints, we planned to add a new puzzle consisting of rotating pipes and water flowing. Out of all the puzzles, we decided this would be the best to develop since our game takes place in the sewers. After that, the rest of the objectives did more minor fixes, and we also had a build scheduled for this sprint. I’d never done a puzzle like this before and thought it would be more straightforward. However, I soon found out that it was an illusion. There were various complications when developing this system, starting with the logic. At first, I knew I needed to lay down the bare necessities: an origin, a rotating piece, and an end. I knew beforehand that the rotating piece would be the most challenging part. Despite having multiple pipe pieces, I aimed to make the rotating pipes a single script. I started by making the pipe interpolate its rotation to a target degree; the pipe ...

  During Sprint Kick, we found some exciting things we wanted to research. Since I’ve been in charge of the enemies since the beginning of the project, it was my job to do this research. The designer aimed to research a mimic behavior, which meant I had to do research into procedural generation. With that plan in place, the other things that we needed to get done were polishing some mechanics further and adding details to the game. I started by researching some procedural animation examples in Unity and how they are handled. After looking at some of those examples, I had a basic knowledge of procedural animation. So, after understanding the basics, I started looking at tutorials on how this is approached in Unity from a development side; what we were looking to make was some kind of alien octopus that would walk on any surface that would be in front of it. However, because of the time left for the project, I soon informed the designer and producer of some of my concerns when develo...

  During Sprint Kickoff, some significant changes were made to the game core loop, including a change in how it was going to be handled. The game would now be handled by points, and it would be divided into modules. The modules can be of two types: last man standing and race. This meant I would have to change the main backend of how the system was being handled. The backed rework for the new game structure was the highest priority for this sprint, so I tackled it first. Thankfully, everything was broken down from the previous rework, and now it was easier to change the system and the order of events needed to happen for the game to start. I started by removing the order of events and dependencies and reorganizing them on a UML diagram to understand what needed to be done.  For this new re-work, I decided to make the systems even more modular and have some required soft dependencies. The game needs the dependencies necessary to start, and then the soft dependencies that are not...