Martin Vilches

  During this sprint, I wanted to tackle various things. Finishing a Puzzle was my main target, and I also wanted to polish some of the work done during the first Sprint. During Sprint Kickoff, the producer and I discussed laying a more stable base for the project. With that said, various other mechanics would be essential to have for the project, so those were the ones I started developing. First, I wanted to take a very game-essential mechanic: the camera following the player while navigating the level. At first, I started prototyping my own camera, which constantly interpolated the camera position to the player position. However, after doing a bit of research, I came to the conclusion that it would be more efficient to use Unity’s Cinemachine. I’ve never used Cinemachine for a 3D game simulating a 2D game, however, and found a way to freeze the z-axis component on the camera, giving it a smooth follow to the player. After having the camera following the player as intended, i...

  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...

Starting Sprint 2 for Stumble, I wanted to do many things this sprint, including getting the bumpers that will push the player and getting the transferring of the Connected Players from the Lobby to the Game scene working. During the sprint kickoff, I negotiated this with my designer and producer, and they agreed that it should be the focus of this sprint. They also added some fixes that they wanted in the player controller to give a smoother gameplay experience. More in detail, some changes on inputs for the player and also timers that will prevent the Player from performing actions quickly. The first thing I started working on was the bumpers, and using the GDD, I had a general idea of how they needed to interact with the player. After researching how to achieve this, I needed the bounce direction to be perpendicular to the bounce surface. Finally, I came to a function inherited from Raycasts, in which you can get the direction normal from the surface the Raycast hit. Knowing this, I...

  In CAGD 377 (Mobile Game Development), we were tasked with researching and pitching multiple mobile games from the most popular genres. I joined a group that was going to develop Slippin Away. This game was about a slime trying to escape the sewers by solving puzzles, jumping, and sticking to the walls. I was tasked to be the programmer for this game, and so after getting the general vision for the game, I wanted to develop some basic mechanics like launching and sticking to the walls. I started creating GitHub and giving every team member access to it. After getting everyone’s contact information, I added a new Unity project to GitHub and started prototyping the necessary things for the slime.   I began prototyping the launching system, which would be one of the hardest things to do. After talking to the designer, we ended up with a version of the launch, which is like the player will drag from the slime’s origin, take the direction, invert it, and make it relative to the p...

  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...

For CAGD 495 (Advanced Production), I was assigned to work on a group working on the game Stumble. Stumble is a competitive Obstacle Course game in which you race up to 4 players to reach the finish line. This concept stood out to me, and once I was assigned to my group, we quickly started the project. Fortunately, I was assigned to do the programming for this project, which was my first pick role. My first task was to set up a GitHub for the project and invite every team member to it. I started by creating the repository and adding a Unity Project to it. Next, I added everyone to the repository. This was easy since the designer and producer had a spreadsheet where everyone put their contact information. They also managed to ask everyone for their GitHub-connected email, which facilitated my work. After the first programming meeting with the designer and producer for Stumble, it was clear that Sprint #1's target was getting the player movement working and implementing some of the b...