Making enemy spawners function correctly -- Owen Meyers

     In order to properly give the player a new challenge throughout the different levels of the game, as well as giving the sense of a "reshuffled simulation," it is very important to have random enemy spawners throughout the levels. A simple object in the level that has a position and rotation, as well as spawn chances is all that is needed. The solution is simple, and I will outline how the system functions here.

    The first thing needed is a spawn position and rotation. This is easily done in blender through an object called "Spawner." Note that this is actually just a cube that is only visible in blender. Its matrix is output from the map by a blender script, along with its name. Included in the name is an alphanumeric sequence corresponding to a spawn chance for a specific enemy. When the level begins, every spawner that could be generated is iterated through. A number is rolled, and an enemy is spawned according to its spawn chances, which could include nothing.

    The next thing needed is balance. It wouldn't be fair to have a room with 5 spawners spawn 5 enemies when the player has no ammo and no upgrades. Thus, the max number of enemies spawned in any given room is capped at the floor number. This way, only 1 enemy can spawn per room in floor 1, while on the final floor, a max of 5 enemies can spawn in to swarm the player. This helps to give a constant escalation, as more and more enemies must be juggled the closer the player gets to the final part of the game.


An example of a spawner in a level file. The code denotes that this spawner has a 30% of spawning a pistol enemy, a 50% chance of spawning a shotgunner enemy, and a 20% of spawning nothing.


Comments

Post a Comment

Popular posts from this blog

Adding assets to every enemy -- Owen Meyers

Image
      As with every game, it is very important to have assets to denote which enemy is which. Being able to tell at a glance what enemy you are encountering before receiving a face full of buckshot is incredibly important. The issue for Project [REDACTED] is that we didn't have any artists working full time to deliver assets for the enemies. Thus, it fell upon me, the designer of the asset pipeline, to acquire assets for every enemy. This led to having to fix models and integrate animations, with each problem being subtly different.     Take, for example, the shotgunner model. His original model was designed for an OpenGL renderer, and was flipped 180 degrees for that very reason. In addition to this, he was also placed halfway in the ground, likely due to something required for that game's collision to function. Fixing this model to function for our renderer required that it be re-rigged and most of the animations acquired from Mixamo. With the help of Kris, and several hours
Read more

Sphere to AABB collision

       I had a problem today when trying to detect sphere to AABB collision. For some reason the collision check that I made was never turning true even though I could clearly see the sphere hitting the AABB. This was a big problem as we needed this collision to detect whether any entities are hitting walls.     I discovered that the problem with this bug was that I was improperly getting the closest point in the AABB to the sphere. The way I fixed this problem this problem was by getting the max vertex that the circle center could be and using that to get the closest point on the AABB to then determine the minimum vertex between the sphere's max vertex and the max of the AABB.  Once I found this point, I could properly compare the distance of that point to the center of the sphere. This solution will allow detection between walls and any sphere collider such as the player collider, and enemy collider. This is very important to make sure they both stay within the level bounds.
Read more