Grapple Gliders - Sprint 3

  For this sprint, I worked on creating two enemies (homing and shooting enemies) and a goal watchtower. The enemies were leftovers from the last sprint, but the homing enemy was much more developed than the shooting one. Most of the mechanics of the enemy were simple to implement, but making sure everything was attached correctly in the Unity scene was a little harder. In this sprint the player and the camera were split into different objects (they were children of an empty object before) and that resulted in my enemies either messing up when detecting the player or not being able to deal damage to the player. I made an “attacked” function that would trigger whenever an enemy or a bullet hit the player, and getting the enemies to access that was a little more annoying than it needed to be.

The homing enemy was not too difficult as most of how you get it to home in on the player is just a line of code that makes the enemy look at the player and another that makes it move towards the player.

Getting the enemy to move between a range of values seemed to be much harder. I had a problem where it would get stuck when it hit the end of the range. It seems like it still gets stuck sometimes after the homing action is triggered, but it goes away if you trigger the homing action again. This enemy was easily able to trigger the “attacked” function, but at this point it was still a little too aggressive. And because of that, the enemy would keep ramming the player and the “attacked” function would actually trigger after the player moved away from it. To remedy this, the enemy would make the player bounce off it.

The shooting enemy felt way harder for me than it needed to be. At first, I wanted to get the cannon looking at the player and shoot, but then the rotation of the cannon during gameplay was really weird as it looked at the player, so I decided to do away with it. I mentioned last sprint that the bullet shot out wobbly for some reason but after that one time it didn’t happen again so not sure why that was a thing. I had trouble getting the “attacked” function to activate when the bullet hit the player cause I wasn’t able to attach the script that function was on through the inspector. Luckily, my lead was easily able to help me remedy that with a singular line of code. I had a problem where the coroutine for the bullet shooting wouldn't stop when the player was out of range, so I had to use StopAllCoroutines() to make it stop. I suppose it's fine for now, but I feel like this isn't the right way to do it.

The goal watchtower should have been incredibly easy to get up and working but for some odd reason that turned out to not be the case. Before playtest day, I quickly popped in a goal screen that said “You did it!” when the player landed on the platform, and I specifically remember that working fine. On playtest day the goal screen did not show up at all but then while I was working on it in class, it was fine! And then right before the end of the sprint, this was the one thing preventing me from finishing it off. I’m not really sure what the problem was either because neither collision functions or trigger functions worked. The problem might have been that I was using the platform detecting the player to make the goal screen show up, so to fix it I made it so that the player detects the platform. I’m not really sure why the change made it work, but at least it works.

    Going forward, since our group is without one person, me and the lead will have to take on some more tasks. Although, looking at the burndown chart, it seemed like we were doing ok. It's slightly easier to communicate because we can split the tasks into coding or level design. I'll be doing more level design instead of coding since I'm not as good at it compared to the lead. We could probably get more tasks done since the lead can get the difficult coding parts out of the way much faster.

Comments

Post a Comment

Popular posts from this blog

Aftershock Simulator - Sprint 16

Image
  On sprint 16 in Aftershock Simulator, I assigned the team 87 points and 51 points were finished. We’re beginning to pick up now that we have a plan on what to do. In this sprint, our team started on the tutorial levels and the objectives system. And of course, there was some extra work to do for the UI in the game as well.   As a producer, I still find it difficult to gauge the difficulty of a task, especially when it comes to programming. I still end up needing to change the point values of some cards because they end up more difficult than expected. For example, I had figured that creating the basis for the objectives system wouldn’t have been too difficult, but not necessarily. A few of the objectives require you to click certain UI elements on the screen, and the things that would “listen” to those UI elements are all each in their own separate scripts, so now there’s the added work of finding them and knowing where to put the code. I always end up asking people if t...
Read more

2D MegaMan Level 2 Feedback (10/27/21)

     Making a late-game type level is incredibly difficult. I had my idea of making the player climb up, but I wasn’t really able to implement that. I couldn’t really think of a layout for a room that wasn’t having the player zigzag up the room. Although, according to my playtesters, what was in the level was pretty good. At least I was able to avoid the “no clear way to the exit” problem I had with my tutorial level. It was a simple “gather the keys to unlock the exit” type level, and unlike my tutorial level, there was actually a point to it.      Players generally praised the way I set up my keys, as you need two keys to unlock the exit, but there are 3 in total. You can get the first key through an easy or hard route, and then you have to get the second key by passing through some enemies. When getting the second key, I put in a weapon deleter that takes out the Nado so you have to jump through a bunch of enemies to get to the top of the room. There’s a...
Read more

Chicken Scramble - Sprint 1

Image
  To start off, this first sprint was kind of disorderly. Since we’re using a completely new project management tool with no prior experience, it took some time to get used to (and still getting used to it). I suppose for my other teammates it wasn’t a big deal but it was an added pound of stress to my shoulders as the producer. To add to that, there was some confusion between me and the designer as to what the whole game idea and aesthetic was. My original idea for the game was a multiplayer maze in which the goal was for two players to compete to get to the other side of the maze. We could have ways for the players to mess around with each other, like using door switches to open and close doors. To clear up the confusion on what we were building, we set up a meeting to talk about it. To prepare, I made a design map of what I thought it should look like. (In the picture, the blue dots are door switches, yellow dots are checkpoints, and the red dot is where the enemy spawns. Bl...
Read more