Making the difficult decision of what to cut -- Owen Meyers

    Near the end of every project, the question of what to finish and what to cut becomes more and more important. There is simply not enough time to finish everything that was in the original creative vision without extending the timelines. Other times, an idea may actually make the game worse if it were included, and must be cut. Near the end of Project [REDACTED]'s development, there were several features and concepts that had to be cut, despite the difficulty in doing so.

    The first feature to go was animation blending. As the one who would be doing development on that feature, I simply didn't have enough time to build it. Blending between animation states certainly would've helped with the smooth feel of the game, but not having it didn't detract from the gameplay, only the visuals. The time invested in building animation blending would've been far better spent on fixing the bugs and issues with current systems, rather than building and testing a new system. It is for this reason that it ended up being rather easy to cut.

    Another feature to be cut, this one near the end of development, was a room variant known internally as "tiny room." This room was incredibly cramped and hard to maneuver in. Within it were 2 enemy spawners with a high chance of spawning either an assault enemy or a shotgunner. The player would enter the room and be greeted by a large amount of gunfire to the face that was near unavoidable. This was cut during balancing, as it ended up being a dice roll to see if it was time for the player to restart or not. The unfairness of this was deemed too imbalanced, and it was cut.

The tiny room variant in the level editor. Notice the incredibly cramped design with 2 enemy spawners right where the player has to walk.


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