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.

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

Advertisement

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.

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.

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.

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.

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.

Senior Production Sprint 2

I made a lot of progress this week. I was tasked to work on the AI for three enemies. One was the enemy I worked on last week, and the other two were new. All three were simple to make, with the hardest part being the path finding for the piranhas that I did last week. All three are now implemented to the point that they should be testable in QA, at least with most of their planned functions. The piranhas have been at QA all week.

The first enemy I worked on was the piranhas. I worked on their path finding last week, and set up the whole system for how they move. This week, I added wandering, fixed up the movement in general to the specification, and added an attack. I also added an optimization that reduces the time spent on path smoothing, simply by only running it every number of frames. The piranhas are now almost fully functional, with most of the remaining work being visual implementation. I also need to fix the way you kill the piranhas, because it’s still using inflexible temporary code.

The second enemy was the sand dollars. These enemies are mines that sit and wait for the player, then explode once the player is in range. The explosion damages the player and pushes them back. It also damages other enemies and pushes them back. It will destroy walls within a radius, but that isn’t implemented yet. This enemy’s AI is much simpler and doesn’t require any movement, but it still uses all of the same architecture. This made it very easy to set up, with only some of the functions requiring new code. This also means that anything else that uses the same system can use any of the new features I added for it. I used this to make up some exploding piranhas, that simply explode once within range of the player. This only took a few minutes, and didn’t require any new code.

The last enemy was the jellyfish. This enemy also has a simple system, only gently moving between two points. It ignores the player, and damages them if its tentacles touch the player. Once again, I only added a few new scripts, and mostly reused the same systems. The damage is just dealt to a hitbox where the tentacles are for now, because they aren’t using the movement system yet. It is just a sprite for now. Once we get that working, it should be simple to put hitboxes on the tentacles as they move.

We now have three enemies mostly functional, ready to be implemented and tested. As I add more functions to the AI system, it becomes easier to create new enemies with different behaviors. Most of the time, most of the enemy will already be programmed, and I will only need to add in a couple new behaviors or state transitions. The whole system makes it easy to create new state machines, like in the case of the exploding piranhas.

Demo of the new enemies, from a test scene with a starfish standing in for the squid. The sand dollar explodes, killing the homing piranhas and launching the player. All enemy art is placeholder, repurposing other assets.

AI Tool Plan

My idea for this project is to make an AI tool for the game engine Unity. What this would be is a set of scripts and editor scripts that help to make the process of creating a functional game AI much easier. It would help with low level processes like path finding, and higher level processes, like editable state machines and decision trees. Even higher level processes like strategies might be left to the user to work out, with the help of the easy to use tools that I provide. I might add support for things like this or learning and prediction if I have enough time and everything goes well.

I have done work with dynamically changing decision trees and state machines before, and it always felt like the limit of how deep the system goes was how much time I had to work on it. I could always make the system more robust and easier to use, and all the time I spent on it would have easily noticeable results on future usage. It could go as far as building a flowchart in the editor to control states and decisions, adding connections and transitions with conditions to control the logic in a visual way. I could add in basic functions like combat AI, using the framework I set up as a base. There are many different ways I can think of to take it, and I want to try to do as many as I can.

One of the reasons that I want to do something like this is that AI is my favorite type of programming. Trying to make complicated decisions in a purely logic-based and algorithmic way is something I have always enjoyed doing, so AI programming is something I enjoyed from the start. I also like how you can make something come to life with a few simple scripts. It is something I enjoy doing, and have a lot of fun watching it when it is finished.

Another reason I want to do this is that I like the idea of using editor scripts in Unity, but I hardly ever do. It is something that I always feel would be incredibly useful, but I never have the time or motivation to just make more work for myself. Having an entire project based on it would likely make it easier to see how it could be helpful and how I could be using them in the future. Even if I don’t end up using Unity much in the future, all of the concepts and ideas for making tools for other people to use would likely carry over into similar tasks in different engines.

AI is something I have always enjoyed programming. I want to try making a tool because that is an important thing to be able to do and I haven’t done it as much as I would have liked. I think I can put these two together to make something useful for people, and get it done in a reasonable amount of time. I also think it is flexible enough in the amount of detail I could add that I could really make something substantial if I end up having the time.

Senior Production Sprint 1

This was the first sprint on the new team for me. I had an idea what I would be working on for this game, so once the sprint started, I got to work on the new AI system for enemies. I was planning to add path finding and path following, and after I completed these I started on a state system and a system that holds common AI data. I got a lot done, and some of it could make its way into the game soon.

 

Path Finding

There was already a grid system for path finding in the game before I joined. There was even a path finding script, leftover from a system that was no longer in the game. I used the grid for my new path finding system, but I didn’t use the old path finding script, because I wanted to use flow fields. The old system used A*, which is more efficient in open spaces, but less effective in mazes or maze-like levels, like the ships in the game. Flow fields are also more effective when multiple enemies will be targeting a single point. As enemies will mostly need to target the player, it makes sense to make a single flow field that every enemy can use to track down the player.

 

Path Following

Again, there was already a system in place for following paths. It didn’t use physics, and instead just traced a curve it made between the points. I replaced it with a physics based system, using steering functions to allow for more flexibility in the future. This means that I can add additional steerings to be used at the same time, so I could have enemies that track down the player and also flock to avoid crashing into each other or avoid obstacles.

 

State Machine

This system is something entirely new that I added. You can add states to an enemy, set it up with conditional transitions, and give each state its own steering functions (such as path finding), all within the editor. It is currently a messy system to work with, but I was able to make an enemy that path finds to the player, switches to charging directly at the player on sight, then path finds back to its home when its battery charge is low, which is a system that we are planning on using for an enemy.

 

The Hivemind

Another new system, this script holds the data for where the player was last seen, a flow field to that point, and in the future will hold other data that enemies can use to organize among themselves. This is helpful for enemies that can communicate with each other, so that when one of them sees the player, all of the enemies now know where the player is and can hunt them down. It also saves time and memory to have this data evaluated and held in one common place, instead of duplicated between the enemies. This system might not be used for every enemy, because some will probably intentionally be left out of the loop, but it will almost certainly be used for some enemy types, because it’s too cool not to use. It also makes sense, because the enemies are supposed to be robots used to defend the ship. Some of them should have the ability to communicate and organize.