Martin Vilches

  We have reached the end of the Project, and with it, we have our last version of the game Slippin Away . This project was my first ever project for mobile development, which also came with various challenges that I was unaware of at the beginning of the project. I was thrilled to have an amazing, flexible team that would adapt to all the production hurdles. At the beginning of Slippin Away, there wasn’t an exact idea for the project, so it took some time to develop the base design idea for the game and determine how we wanted to target it. With the prototype, we figured out what the game mechanics would look like. The prototype was to test the basic mechanics and make sure that the game concept was fun; this mechanic testing was done in Sprint #1, and it needed for the player to be able to drag the screen, making the character launch and also stick to any surface it lands on. We were ready to begin the production process after having this prototype and getting excellent data on t...

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

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

  For the Sprint, there were various things that I wanted to tackle, mostly fixing bugs and adding some basic animations. During Sprint Kickoff, I was tasked with polishing some of the previously implemented mechanics. My first approach to handling the problem was to set a priority for every bug and start working from there. After having the feedback from our playtesters, I had a general idea of how to fix some of the core bugs.  First off, It was polishing the character controller so that the player wouldn’t get stuck as easily; previously, if the player were in a corner, they would get soft-blocked. After looking at the code, it was a problem in the main logic of the character controller, so I had to change various aspects of the character controller; first, I had to make it so that the controller is stuck and independent and not depending on the box collider attached. Using my previously implemented custom collision detection system, I could check when the player hit a corn...

During Sprint 4 of Stumblebumps, I wanted to accomplish various tasks, including fixing some of the bugs found in previous sprints and reworking some backend systems. During Sprint Kickoff, I was assigned to work on more systems and fix bugs. One of the main concerns or focus for this sprint was making better developer tools that the designer and the level designers needed to test the levels more efficiently. Right after the Sprint kickoff, I first tackled Player Animations. Since both of our animators were being shared among all the teams, I knew the earlier we had that animation feedback, the better for them. This was my first big approach to handling character animations in Unity, and I wanted to make them look good so they fit our character controller and display the animations themselves. Because I wanted the animation handling to be outside of the main third-person movement, I had to implement a wrapper that would extract some values from the main third-person controller and send...