Senior Production Sprint 10

I made a lot of progress on the boss this week. I added rotation and vertical movement, making the fight much more dynamic and exciting. I also added some variables to set the length of the stun the boss takes when damaged in the different phases of the fight. I fixed a bunch of bugs and set up the eye image switching, so now the fight feels much more finished. It still needs some work and not everything is final, but it’s getting there.

The boss had the problem of being uninteresting and static if you knew how to fight it, because you could easily get above it and it only had a few attacks it could use while you were above it. The solution to this was to let the boss rotate to face you, so now you have to race around it to get to the capsules to damage it. I set this up, and later added variables to the boss to determine how fast it should rotate in each phase, making the boss get harder as it goes. I also added in a much quicker spin that happens after you damage the boss’s eye. It pauses for a second, then quickly rotates to face you, resetting your progress and preventing you from abusing positioning to take the boss out quickly. All this makes the fight much more frantic and difficult, without leaving any easy methods of beating the boss with little effort.

I improved a lot of other things that were either wrong or incomplete. I made it so the player can grab onto the boss, making it easier to maneuver. I fixed the boss’s mine to do damage. I added in the eye sprite switching to show the boss taking damage as the fight goes on, although that still needs some adjustments. I fixed some bugs with the boss fight, like the eye’s hitbox being wrong and some errors when the boss was killed.

The boss is feeling a lot more complete now. It is very difficult with the current settings, and the difficulty can easily be adjusted in a few different ways if needed. All of its attacks are used, and they are all intimidating and threatening in their respective danger zones. The rotation really helped the whole fight come together as a whole, and the boss now commands the respect it deserves.

19ec04bda59bbe79a757eb3fa1535026

The first pod is basically free, but the rest are anything but.

Advertisements

Senior Production Sprint 9

This week, I worked on setting up the boss to use different assets and a different system for popping the capsules. Instead of having the normal capsules from the other levels that you can pop in any order, with big shields appearing on them when you should shoot the eye, there is now only one active capsule, which glows, letting you know which one to aim for. I also added in a stun state and a sleep state for the boss, to make starting the fight easier and to make the fight more dynamic and responsive. The boss doesn’t start moving until you enter the room, and damaging it makes it stop moving and attacking for 2 seconds. I also helped implement some VFX for the boss, for when it takes damage and when it is destroyed.

The largest task for the week was adding in the new capsules. While implementing art assets isn’t usually a big deal, this meant changing the whole system from “grab any capsule” to “grab this specific capsule, and you can’t grab the others.” The assets also had to be switched in and out to provide visual feedback, giving a glow to the pipe that is currently active. I also took out the shields that used to appear covering the capsules when you are supposed to damage the eye, because you can’t grab the capsules while they are inactive anyway.

The next task was making a state for the boss where it doesn’t move or attack. I needed to add an override into the state system, allowing the boss script to change the AI controller’s current active state to the damage state whenever I want. I could then use this when the boss takes damage, cutting the current attack and preventing it from attacking until the stun ends. I also had to stop the boss’s movement, but that code was in the boss script already, so I just had add a toggle and a check before moving.

With all of these new updates to the boss, along with updates to the level, it was finally ready to be taken to QA and tested. The results were positive, with some people liking it a lot. About 40% of testers were able to beat the boss, which was a bit discouraging. We’ll have to make it harder for next time. We already have plans for some simple additions that should shake up how the fight works, and alleviate some of the problems we have found.

Senior Production Sprint 8

I didn’t do much for the game this week. We didn’t meet to discuss what would be done this sprint until Monday because of spring break, and we didn’t have the whole team because of GDC. My only tasks were adding the boss into the boss level and making documentation explaining how to edit the boss for designers. I added the boss to the level, but I still have to finish up the boss documentation.

Adding the boss into the level took a little longer than I expected. I thought I could just put it in, hook up some variables to the player, and it would just work. When I did that, the tentacles were acting weird, and I thought something was wrong with it. After tracking down the issue, it turned out to be a random collider running through the center of the boss level. This was a collider left over from the level that the boss level was copied from, and it had no place in the new level, so I removed it.

For the documentation, I ended up splitting it up into two documents. The first is a general AI document. This explains how the basic system of the enemy AI works. The boss uses the same base as all of the other enemies, so it made sense to have a single document for all of them together. It explains the state machine system, and the transitions and behaviors. I want to add explanations for the specific types of transitions and behaviors as well. This should make it possible for anyone else to make changes to the enemies if they need to.

The second document is the specific boss document. This explains the transitions and behaviors unique to the boss, as well as a few other scripts that only the boss uses. I put in the general explanation for how the boss specific scripts work, but I didn’t finish all of the behavior explanations. I did hit some of the most important parts, and a designer has already started making changes to some of the boss’s attacks.

Senior Production Sprint 7

I made a lot of progress on the boss this week. I implemented some new art assets, added in a tentacle attack, and added in two new types of attacks. The new attack types are lasers and bombs. The laser is mostly a copy of the player’s laser, with some adjustments. The bomb attack is currently just a sand dollar that is launched slowly at the player. This should be easy to improve upon later, once we have the correct bomb set up. With all of the new attacks, the boss is close to being a functional, playable fight, now that it has ways of hitting the player from all angles. There are still some aspects that need to be implemented, but it could enter testing during the next sprint.

The new tentacle attack I added is fairly simple. It reaches out with all of the tentacles, then swoops in, hopefully catching the player and pulling them in close. I might make this into the bite attack we have planned, so the boss pulls the player in for the bite. This was an attack we had planned for if the player got too close to the bottom of the boss, but that seemed like an unlikely scenario without a little assistance from the boss. With the pull in, it might be more likely.53af69163e5b50049c00abb28225e939

The next addition was the boss laser. The majority of the code controlling the mechanics of the laser is borrowed from the player’s laser, with a few changes to support new systems. Instead of being run by input checked from within the script, the boss’s laser is told to fire from a separate script. The other script can change things like damage, speed, and size of the laser, and can even change the amount of prediction the lasers use. This last piece lets the boss have attack patterns such as one where it fires a burst of three lasers, one where it thinks the player will be, the next where the player will be if it speeds up, and one where the player will be if it stops.b3d934c8776016fcd0bc5dc4cbb19d16

The last couple attacks were mostly made using old systems. One is a giant laser that does more damage and moves faster, that only shoots when the player is far away. This is to deter players from staying far away for too long. This uses the same scripts that the burst laser uses, with different variables. The last attack added was the bomb launch. This sends a bomb towards the player, blowing up when the player enters within range. This is launched in the direction of the player with no prediction, meaning the player can easily avoid it by moving. It moves very slowly, so it occupies space for a while, preventing the player from moving freely. This same system will be used for a cluster bomb, which does more or less the same thing, with extra explosions for more fun.

ca5337944157346a699678e6cbc7fb7b

At the moment, the lasers and mines don’t have a lot of visual feedback, only being noticeable by the projectiles sent flying towards the player. These attacks will likely have sound and visual effects to give the player a better understanding of what the boss is doing at a given time. An example of where this would happen is the big laser. It is delayed by a second from when the attack starts, but that delay is unnoticeable because there is no feedback during it. There will probably be some sort of charging effects, before the blast is released at the end. Each attack will likely have something like this to make sure the boss is readable at all times.

Senior Production Sprint 6

This week was spent working on the boss again. I was tasked with setting up the boss tentacles and attacks. The tentacles can now move in patterns set up in the editor with a script, and the whole tentacle will follow that pattern. They look pretty good, and make for decent attacks on players below the boss. They can’t do much to players to the side or above, but that is what other attacks will be for. The only things left to do for the boss are add in the last few types of attacks and add movement. Then it will be ready to be tested, and improvements can be made.

The way I planned on moving the tentacles was by connecting segments together with joints, then moving the tip of the tentacle through code. The other pieces would follow, connecting all way back to the source, giving it the look of the boss swiping its tentacles at you. I ran into some problems with the range and the way the pieces moved, so I tried out two types of joints. Neither looked great, so I tried moving the pieces with code too. After I added that, I tried each combination to see which looked the best, and it ended up looking best with both joints and the extra code. That’s what it uses now.

More specifically, each segment of the tentacles has a hinge joint and a fixed joint connecting itself to the next piece in the chain. The extra code pushes each piece towards the point it would be in if each link in the chain was evenly spaced between the two end points. Before adding in this last piece, the movement had trouble with pieces moving unevenly, with the pieces near the tip doing all of the moving, and the rest mostly just staying still. This code makes all of the pieces move at least a bit, making it look much better. There was also a problem when the tip would move towards previous parts of the chain, and the movement would get ugly. The code helps keep the other pieces out of the way, and keeps them in order.

a09d3d950483fef292c8716994982c3e

Senior Production Sprint 5

This week, I worked on implementing the boss. The goals were implementing the systems to kill the boss, setting up tentacle attacks, and setting up the dynamic tentacles. I worked on the first two, and the last one will be pushed to next week. They weren’t all necessarily goals for this week, just what I knew needed to be done soon. We have a plan for setting up the tentacles, and it may require assets I am waiting on for now. Regardless, there was plenty for me to do this week with just those two tasks. I also fixed some bugs with previously implemented systems.

The first thing I did was set up the flow for the boss fight. You can now follow the intended steps to kill the boss, including opening cylinders and freeing starfish, shooting the eye with the laser, and shooting the tentacles with the laser. They are all in the intended order, and the fight plays out as planned, just without the boss moving or attacking. When you deliver the final hit, it explodes. It still has a ways to go before it can be QA tested because the steps aren’t communicated very clearly, but it can be played, and that’s something.

I also got started on the boss attacks system. I already set up a system for deciding states to transition between, based on the angle to the player, distance, and RNG. Now that we have decided how we want the tentacle attacks to work, I could get started on the system that controls them. The tentacles will be composed of segments connected by joints. The way I plan on controlling them is by controlling the tip of the tentacles with code, and the rest will be simulated with the physics joints. This will allow for controlled attacks that target specific areas, without the need for complex animations for each attack. What I worked on was the code to set up the control of that tip.

I set up a behavior script to make a target object move through a set of nodes. These nodes can be added and moved in the editor, using an editor script I set up. You can set the total time it takes to move between the points with a variable on the script. The path between the points is interpolated using a Catmull-Rom spline. This gives it a fluid path to follow, without the need for a complicated steering script. It is a giant robot squid, so it will pretty much completely ignore everything in its way. A static curve works fine for this, because it doesn’t need to interact with anything anyway. This all works, but until the tentacles are set up, it just moves a sprite around.

The other thing I did this week was fix the sand dollar explosions. They are supposed to destroy walls, which I set up to work in a test scene. The problem was that the walls in the levels use a different script to break apart, so the sand dollars didn’t break walls in the game. I added some code to check for that script and use it, and that works now. As a fun bonus, setting the explosion range to a large enough number can completely strip a level down to just the indestructible materials.

Senior Production Sprint 3

This week went well. I finished what I needed to get done, and even went on to other areas that I wanted to work on. I made some adjustments to some of the enemies I worked on earlier, and got those more in line with how they are intended to function. The piranhas are now visually implemented for the most part, and don’t look out of place anymore. I also worked on making their pathfinding grid update when walls are destroyed, without needing to rebuild the entire graph. The last thing I worked on was starting the boss AI. I started working on the system it will use to decide which attacks it should use.

The first thing I did was finish implementing some systems that the enemies were supposed to use, but that I hadn’t gotten around to doing yet. I made the piranhas take damage and get destroyed by the player’s laser, instead of simply being destroyed on contact. I also made the sand dollar enemies destroy walls with their explosions. Additionally, I implemented the piranha’s sprite and the bite VFX for when they attack the player. All of these were simple additions that didn’t take much work, but were delayed either because they involved a system I needed to get more information about, or they required work from other team members before I could implement them.

After I finished all of those and was waiting on another system to be implemented, I decided to work on making the pathfinding grid update. I didn’t plan on working on it this week, but it needed to be done eventually and it was something I could start working on right away. The system used a graph of nodes with connections built between them in the editor. If there was a wall where a node or a connection would go, no node or connection would be built. This meant that updating the graph would require adding in new nodes and connections, which would be needlessly complicated and expensive. I changed it to make the nodes and connections, and simply avoid using them. Whenever a wall is damaged, the nodes around that area are checked for new available connections, and those connection are set to walkable if they are now clear. This can be done quickly during runtime, and makes the piranhas look much smarter, because now they won’t get stuck when they have an obvious path to their target.

The last thing I did was start the boss AI. This system depends heavily on design and art that still needs to be done, but some of the underlying systems could be started with the information I had. I made a system that can transition to a random state from a list, in order to get the random attacks we want the boss to make. I also made a script that picks one of these sets of transitions to try, based on the relative position of the player to the boss. This means that the boss will check where the player is, and then pick the set of attacks that correspond, then pick one of the attacks from that list randomly. This is how the designers described it, so I set it up that way.

e2e601109532fd53bfe38be96aa5d08c