Dragon Guild Blog

 Author: Pedro Polanco     This issue happened when I was trying to implement Dr.Lugos second phase. During this phase he is supposed to teleport out of the room and then spawn clones into the room. The problem I had at first was that the new clones that were being created where not put into the Collison libraries entity list correctly and it caused a problem with the indexes in the list that would crash the game. This is very bad for the user because if this were to happen it would be a game breaking bug.     The Way I fixed this essentially is by pre-generating the clones before the player fights the boss. So when the player transitions to the boss room the clones are created and set to be outside of the players view that way when the boss needs to summon them in he can summon any number of them by just teleporting them in and the indexing in the list would stay correct because we know where the clones are in the list so we don't delete them improperly. This fix allows the player

 Author: Cameron Taylor The weapon wheel needed to be in the game since month two but it was constantly pushed because we ended up adding debug keys to switch weapons. The first issue I ran into was that the assets that use transparency would cut off other assets when covering them. Then I needed to use the greyscale value from before to either have them with a blue outline or a grey outline dependent on highlighting a certain weapon. There was also trouble with dot products for determining which slice the mouse is closest to so that you could select a slice from anywhere on the screen for quick weapon swapping.  To fix the assets covering each other I had to space them out and give them a big gap so that you could read all the assets. I then told every slice to be a greyscale value unless I specifically told it otherwise. This allowed be to highlight a green slice whenever I wanted to. For using the dot product to figure out which slice the mouse was closest to I needed to convert all

    Author: Pedro Polanco     The issue was that for every gun they did the same thing and that the pattern was then the same for every gun he used. Seeing as how the final boss is supposed to steal your weapon and use it better than you can so having the same pattern for every gun would be a letdown for the player as there won't be anything new to do in the boss fight.     To fix this I made gave the boss a spin factor so he would spin around and fire differently by modifying his gun fire delay and what the guns actually do which created a variety of patterns for the different weapons. I also randomized his abilities and weapons when he enters his third phase so that way, he can switch up his entire build to combat the player. This will provide a more rounded experience and overall, more fun experience.

 Author: Pedro Polanco          The issue was that at times the rocket would jump out of the playable area sometimes due to his jump target position being outside of the map. This would be a really bad thing to see for the player because the enemy would jump outside of the bounds and come back in which would be really weird and look awful.     The way I fixed it was by making the enemy predict where his target is going to be and if it outside of the bounds, he will instead flip directions and jump away from the bounds. This in the players eyes will look like the rocket just jumping over the player or away from him which will look much better than crashing into the wall.

Author: Daniel Jackson                The final boss dubbed 'Dr. Lugo' has the ability to use any of the weapons in the game and use them to a better degree than the player is able to. The additional functionality changes based on the weapon and in phase one he will take and use the weapon the player had equipped. I was charged with adapting the original weapon code with the new boss variation.     To start with the boss uses the base weapon values just like the player, from there I broke out into each weapon to modify them individually. First was the pistol, in addition to firing normally it fired explosive rounds, the bullets themselves were larger than normal, and the boss can fire the weapon in a cone pattern. Second was the shotgun, I created a second shotgun in addition to the first one and offset them so he can fire two shotguns at once. Then the rocket launcher, when the rocket launcher is fired an additional one is fire straight backwards, instead of normal explosions

 Author: Pedro Polanco          I ran into a problem when trying to implement a fuzzy logic controller. at the time I was having a hard time grasping the concept of fuzzification and putting the fuzzified input into an inference system to modify effectiveness. The controller not working would not cause a real issue for the player but without it the overall game experience and combat with a boss would be severely lacking the bosses would be very linear and feal stupid.      After some researching, I realized that I should be taking the inputs and putting them within a 0-1 range and taking the minimum of those input values to determine the truest value. I then used that value and a set of ranges to determine if the current boss's strategy is effective or not and based on how effective it was applied it to his current effectiveness stat. This allowed for the boss to make better decisions on when to switch strategies so when the player goes through multiple runs of the game the boss va

 Author: Cameron Taylor The old pause menu was hardcoded locations for the buttons and all it had was resume and exit. The exit button brought the player back to the main menu and didn't actually close the game. The first issue I needed to overcome was adding 2 new buttons and have the buttons the side of the image. I also needed to add a bunch of new states to the pipeline to know which window I was on. This is important because the state of the game determines what we display on the screen. For the shield I ended up copying the health bar and decrement it the same way the health is done. This is an issue though because the code was never fully tested so the bar never went down all the way and displayed the incorrect amount of health and shield. I also had trouble keeping the slidebar inside the bounds since I needed to constantly update the mouse position and compare to make sure it's inside. I ended up splitting more of the pipeline into different parts so that only certain

 Author: Daniel Jackson Our collision library was massive. Part of the reason for that is that it handles more than it's supposed to. A section of that was handling bullets and their special cases such as explosions. Extra checks such as this were bloating the collision library, making it more difficult to work with and read. To minimize collision as much as I could, I disconnected my systems from it as much as possible. Collision itself no longer creates any bullets or explosions, instead all special effects are now handled inside the bullets update or destructor according to the shooter and the weapon type. (New bullet.cpp handling explosions) (Example of cut section from collision)

 Author: Cameron Taylor Although a single tab in the skill tree worked, I needed to make every tab work. An issue I ran into right away was that every asset was layered on top of each other. I also had to split up the buttons into their own chunks of code so that overlapping buttons that were in the same space wouldn't be clicked unless they were enabled through code. I also had an issue with displaying the correct currently displayed weapon and ammo count since the current pipeline would display any text given at it. To fix the layering assets I needed to attach and ID to each asset so that the render pipeline would only display them if I told that renderer that we want to display that ID. I then added switch and if checks into the update code that runs every frame so that only specific text will be added to the pipeline if a certain weapon was equipped. This is a sneaky way to fix it instead of keeping all code on the GPU at all times, but it works fine and runs very fast still.

 Author: Daniel Jackson The players fire function was exceeding 1,000 lines and causing a drop in frames anytime the player was firing any weapon. Each time any weapon was fired the weapon checked its current type against every weapon type and its current magazine to see if it could be fired. These repeated checks were causing frames drops and made the function more difficult to read. To fix this I shifted our player's current weapon to be a pointer to a particular weapon in its arsenal so we could skip going through the entire arsenal every fire. Then I shifted our fire into a switch case using its weapon type and was able to remove most of the code checking each weapon's magazine and instead only check our current weapon and then go through the appropriate checks. This drastically shortened the fire function and decreased the average amount of checks per fire, and I plan to shorten it even further using this new system. (Lines from fire commented out just prior to deletion) (

    Author: Daniel Jackson    The weapon system as it was functioned perfectly well however anytime anything weapon related was needed, a series of functions needed to be called. In the short term (and to get things off the ground) this was fine however doing these function hundreds of times a second adds up and gets expensive quickly. Because of this when the weapons are fired, even the least expensive weapon, there is a significant drop in frame-rate and while at the moment it's not noticeable it could hurt the final project later on.     To alleviate the strain of the multiple function calls, I've been working on refactoring the weapon so that each weapon is it's own struct containing the appropriate values for the weapon. Removing the need for function calls entirely, now we simply access the struct and grab the values directly saving us at least roughly 40 frames while the weapon is in use. Additionally, using this new system we can add any extra effect to any weapon w

 Author: Cameron Taylor I needed to make the skill tree so that the player didn't have the same weapons throughout the entire game. This also functioned as a store for unlocking new weapons. I constantly ran into an issue where resizing the window broke everything. This is because the assets would be drawn with premade values on the screen from -1 (left side) to 1 (right side) of the screen. That means when you resized the screen to make it wider then the width of the texture is now more pixels. There was also an issue where no texture could change color. They were all green and there was no easy way to tell if one was purchased or not. To fix the resizing issue I needed to constantly check the width and height of the screen and compare it with the previous width and height of the screen just a frame before. Although this happens every frame the comparison doesn't hurt. If they were different values then I knew that the screen size has changed and that triggered remaking all th