Dragon Guild Blog

      From the start of development, there have been only 2 types of room -- small and large. These rooms were always square and they looked visually the same. This is a problem for immersion and for the general feel of the game, as it leads to a very same-y environment. The player will very quickly grow bored of seeing the same room over and over again. In addition, every room flowed the same, leading to strategies that remained stagnant throughout the game. For example, if you see a sniper, retreat into a corner and pull out your own sniper rifle. To solve this, there was an imperative need for new room types.     I'm going to outline 2 rooms that I designed for this game, and how I went through designing them. Firstly, the Hallway room variant. This room was designed around a much more cramped space for the player. A long straight hallway can force the player into one route, with no room for escape. This can lead to interesting interactions, especially with the large number of h

      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 no

      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

    Author: Pedro Polanco III       The issue I had was with the enemy's death animation. Some of the enemy's would get stuck in their death animation causing the player not to be able to progress. This was a big problem as if this happened the player could not progress any further in the game causing them to have to restart.     The solution to the problem was a bit annoying to fix and took some time. What was causing the issue was the way the enemy's got deleted because in the collision library it was not deleting them do to their dead state not being set or called. The way I fixed this was by using the animation system and checking for when the dead animation was supposed to be done. When the animation was the done their dead function would be called deregistering the enemy from the animation system and removing them from Collison which then allowed the player to progress through the game.

 Author: Cameron Taylor At the current build state when the player died they were instantly teleported back to the start room and floor. This was very jarring and a couple people though it was a bug or were just confused what happened. Also when the player killed a boss it instantly teleported them without any sign that they killed the boss. As for the final boss Dr. Lugo, when he was killed the game would straight up crash... The first thing I did was update the win condition. What I did was display text saying the boss was defeating and that the simulation was teleporting them to the next floor. This would show for a couple seconds as the boss would die and then the player would be moved. For the death state I would animate the player dying and display text saying that they died. The simulation would also say "resetting" to signify that they were in a simulation of some sorts. The player would then be teleported to the start floor again and be reset. As for fixing the final

 Author: Daniel Jackson     While balancing enemies and bosses I discovered that the player had the chance to lose entire magazines of ammo when using the auto reload function that occurs when the equipped weapon's current magazine runs out of ammo. Additionally, the ammo in the current magazine could drop into negative values which was a very clear issue.     The first change I made was an executive design  decision that the player would only auto-reload when they pressed fire and had no ammo rather than immediately starting a reload when they hit zero current ammo. Then I discovered an issue inside the reload function that was miscalculating the amount of ammo needed to refill the magazine and found that reload was being called an extra time causing the extra drop in ammo. Finally, I added a check that will prevent any possibility of firing when out of ammo and prevents the current ammo count from ever dropping below zero which solved the display error and the miscalculations.