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 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 this Sprint Kickoff, my most significant task was creating the watcher enemy. Also, during kickoff, my team started discussing what would be needed for the game to be fully functional with the sprints we had left. It looked like the watcher would be one of our last enemies added, so most of the time in this sprint was dedicated to the watcher itself. Sprint Kick-off was good because I got to discuss the game’s current state and the work ahead for future sprints with the producer, designer, and another programmer. I started researching the watcher and how it had to achieve the intended behavior. So, the watcher enemy is supposed to follow you when you look at it and stop when you look at it. So I started looking at how to check if the camera was seeing an object, and luckily, various forums mentioned different ways of checking if the camera was looking at a game object. One of the bigger problems I ran into when developing this feature was that the object was being checked ...

  During the Sprint kickoff for Locked In, we had a very straightforward object: to get a build of the game done and have a playtest released. To achieve this there were various key aspects of the game that we had to work on. My job was getting more enemies done and released. We would need to implement other things, like health and other enemy features.  So, starting with the features, the first thing that I tackled was making the health component, which needed to be the most modular it could be; I wanted the same Health component to be used by the enemies and the player, which meant a lot of adjusting. Something else that I was aware of is that the player can grab an extra armor piece that acts as a shield, so I made it so the health component could also have a shield. Finally, I added some events that trigger when the health is changed and when the health is depleted; that way, there could be a modular way for the other programmer to implement it and apply it to their play...

  During this Sprint, I wanted to tackle more monster behavior and start some other mechanics related to the monster. During Sprint kick-off, we discussed that the objective for this sprint was to polish the already-made progress. So, as the developer in charge of the monsters, I aimed to finish one of them. So, the first thing I wanted to work on was to finish the mimic behavior that I started working on in the first Sprint. To start, I made a sphere collider that would act as a trigger; once the player entered this collider, then the mimic would transform into monster form and follow the player. This worked theoretically; however, once I implemented it in my prototype, I faced the first problem. The player will enter the area, and the mimic will follow it even if the player is on a different floor or behind a wall. To solve this, I implemented a Raycast that will shoot from the enemy to the player, and if the first thing that the Raycast hits is not the player, then it will not...

  In CAGD 470 (Video Game Production), I was recruited into a group that wanted to make a first-person horror game in which a player is in a laboratory and trying to escape. At the same time, some monsters roam around, making the player’s journey difficult. The game will have various rooms and puzzles that will challenge the player. In the game's vision, enemies would roam the laboratory. The player would have to gather various items that will help them on their journey to escape the lab. After getting an idea of the game, many key points and features came to my attention, including the player controller, enemy AI, Inventory System, and Crafting System. All those were going to be heavy tasks for this project. After discussing with the other members in the group, we concluded that the hardest feature to develop would be enemy AI since it needed to include multiple behaviors and enemy types, and we all had previous experience programming enemy AI. I took on the task of learning how t...