Dragon Guild Blog

    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.

      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.

 Author: Pedro Polanco III     This problem that I had was with the jump animation for the shotgun enemy. The issue was that the enemy would not jump with his animation, he would jump before or after it was done playing, and the enemy would get locked in the jump animation not being able to do anything else. This would be a problem for the gameplay experience the player is having as the main ability for one of the enemies is broken and would break the immersiveness of the game.      I discovered there were many factors for the enemies broken state. The main issue was that the update loop for the jump would not get called if the player was within a certain range because the enemy was supposed to shoot the player. The other big issue was that if the enemy did not finish the jump, then he would be stuck in the jump start animation. To fix the first issue I had to make sure that the jump of the enemy could not be interrupted by anything so that the full jump action would happen which also

 Author: Cameron Taylor The skill tree had been in the game for a while but it didn't have connected lines until now! For the longest time I thought I would need to have the engine to dynamically draw the lines through some voodoo magic. This is the main reason I was putting it off, but the real issue was I had no idea how to attempt this. I ended up using assets but they were weird in the beginning since they looked fuzzy and I needed to hardcode the direction and figure out how to attach them to the scene. The first thing I did was open mspaint and draw two diagonal lines: one going up, one going down. Then I imported those into the project and took the middle points of each skill and gave it the appropriate texture before it so that the line would look like it's connecting the two skills. I also needed the system to know the line was connected to that skill so it could highlight and change colors for when the player had enough money to buy the upgrade.

 Author: Daniel Jackson     The boss' laser much like the minigun is already a formidable weapon so instead of making a major update to the gun directly, I create an additional entity in the room which when hit with the boss' laser creates an additional one 'refracting' the laser in a different direction. The problem was pointing the new laser in the proper direction and having it correctly turn on and off when hit by the boss.     I spent several days attempting to correctly get the angle of collision between the hit entity and the boss dynamically so that it would update as the boss moved. I was generating the correct angle after a while but was having an issue rotating the new laser by the correct amount. Unfortunately, I needed to move on to work on and complete other aspects of the game so instead of calculating the correct angle as I would have liked, I had to settle for flipping the correct axis (x or z) to produce a similar but not quite as accurate effect. Then

 Author: Cameron Taylor How I originally made the system I made every key press hardcoded with a certain outcome. For example, when pressing WASD the player would move in coordinal directions throughout the game. The problem with this is people like to rekeybind and therefore I needed to make a menu for them. The biggest hurdle I needed to overcome is making a map to comprehend an input key with the correct action. I also needed to display what key they had selected/bound so they know for gameplay. The way I accomplished the rekeybinding is is by making two maps (translators) to tell the system what key was going in, and what that key needs to be interpreted as. This took a lot of work since I initially needed to hardcode every key input to their respective output in our system. Then it was all up to the player to reassign each one through the settings and that would then automatically update in the code since I was using translators instead of hardcoded values.

 Author: Daniel Jackson   The final boss can use any weapon currently in the game and improve them while in use. For the minigun, because it is already a very powerful weapon, rather than do some major improvement to it the final boss can spawn turrets that will track the player while firing and will add to the chaos during the fight. Correctly creating the turrets, making them behave as intended, and allowing the boss to spawn them at will is what made this take the longest.   The first thing I did was spawn a basic enemy which I would convert to a turret. I gave it a lesser version of the minigun and set it so it would constantly fire. I removed its ability to walk and made it rotate to face the player exclusively which already effectively made it a turret. Then I put up a safety net, typically when a basic enemy dies they are removed from the game. With the turrets, so that we would not have to spawn them during the fight, all the turrets are created outside of the level as it is ge

 Author: Cameron Taylor I was tasked to make a settings menu to allow the player to change their settings as easily as possible. The biggest issue I had was not with the buttons, but rather renderer not wanting to cooperate and show the correct assets on the screen. Those said assets also didn't like centering correctly since the entire pipeline was made on a custom engine. There was no support to allow auto-aligning or special effects for certain objects/text. To fix this I needed to make different game states so that the renderer knew which textures to draw on the screen and update accordingly. I also needed to do a lot more math than I would've liked to in order to fix the centering on each object. I added checks to make sure that I centered objects correctly with different offsets rather than having an engine do all the math for me.

 Author: Daniel Jackson   An issue we experienced this week was one with our projectile collisions. Projectile collisions were indeed being registered however, the same projectile and enemy (or player) were registering a collision every frame while in contact. The good news is that we are registering collision properly, the bad news is because we register it properly damage is being applied to the same entity every frame as the projectile is in contact which could make our weakest weapon end up doing thousands of damage possibly one-shotting a boss.   Luckily, because projectile collisions are only handled in one specific area of our codebase, debugging didn't take very long. To fix the issue I implemented two fixes. The first is a small safety net that doubles as an implementation of an upgrade to the weapons 'piercing'. Most of our weapon's projectiles will hit a wall or entity and disappear, however, some upgrades allow bullets to hit an entity and pass-through allow

      Like all games, Project [REDACTED] needs a HUD in order to display information to the player. The original system for displaying text in our game was functional, but not particularly good. It was thrown together in haste, and it clearly shows. In order to rectify this, I scrapped it and rebuilt it from scratch. It's still an active work in progress, however, I can very easily give a brief description of the problems. First, it was unreliable in placing the text. Text that was placed in one position on one screen resolution would be in a different position if the screen resized. That text would also have to be placed mathematically OUTSIDE the screen in order to be shown properly. Clearly, if we wanted to resize the screen, we'd need a better system. Secondly, the font itself was rather fuzzy and had a strange reverse scaling issue, where smaller scaling values resulted in a larger font. Both of these needed to be addressed to make the font a bit better on the viewer.    

      One of the main tricks in a level designer's toolbag is the idea of light leading the way. Shortly after rooms were created and functioning within our game, the next problem to tackle was rooms. We needed a way to easily telegraph to the player which doors were duds and which could actually open. We also needed to show that a door was locked or unlocked, as all of a room's doors are locked until every enemy within is killed. This required a lighting system that could be easily accessed from multiple places, and which would also upload its data quickly and easily to the GPU. The lights also needed to be as lightweight as possible to not affect framerate too terribly.     The first problem to tackle was the lighting manager. This needed to simply be a black box to access the underlying lights that are in the scene. Doing something as simple as changing the spotlights above a door from red to green up to something as complex as making a light flicker, could be done through t

      Our game is a rogue-lite that assembles levels dynamically in order to afford maximum replayability for the player. In order to do that in as simple a system as possible, it was decided to have a registry of prebuilt rooms and to string them together randomly in order to build the floor. The result would be a balanced gameplay experience that is random every time, as the game would be built from pre-designed and balanced rooms that are strung together in a unique manner. Building this system would be relatively straightforward, as all that is needed is a list of the following -- Meshes (including transforms), lights, enemy spawn points, and colliders for doors, walls, the floor, etc.     The first hurdle to jump over is actually building the level. I opted to utilize Blender for this, as I have a script that outputs objects and their transforms from a Blender scene. Included in this is the name of the object, allowing for mesh names to be parsed from the room as well. Thus, our l

      In the previous blogpost, I discussed the Instancing manager that needed to be put together in order to properly display static meshes. The system was essentially a pool for the instances on the CPU side, which would then be organized and sent over to the GPU. There were some problems with building this system, which led to a bit of a longer development cycle on this feature than I would've wanted, however it was still completed on time.     The first problem that I encountered when building this system was integration. The way I approached this problem was simply by removing all instancing from the Central Processing system, and instead place it within its own manager. This helped to simplify a lot of the update code, as a message would be received in Central Processing to update a model or add/remove an instance. That message would simply be passed along to the Instancing Manager, which allowed for a "black box" approach to utilization. Anybody from anywhere withi