Dragon Guild Blog

 Author: Pedro Polanco III     I had an issue this week with doors disappearing which caused the player to be stuck in the room. This was seriously hindering on the gameplay because after killing the enemies the door would disappear sometimes.      I discovered that the doors were disappearing do to them getting deleted in our entity list which is the list that comprises of all the entities. To resolve the problem, I decided to put the doors into their own list which doesn't get deleted or updated until the next room is loaded. This allowed for the player to correctly progress through the level and not get stuck in any rooms.

      At the present moment, through playtests, it may be painfully obvious that even though we can support skinned meshes and animation (arguably the hardest type of model to support for the requirements of our game), there are zero static meshes, despite them being simpler and easier to process. There is a reason for this, and that reason is incredibly dumb when stated aloud. The system as it works right now has to reshuffle matrices whenever an enemy dies. This is to be expected, as the matrices are all in a singular buffer that every enemy refers to in order to keep rendering fast. The problem with that is when static meshes are introduced in order to add visual variety to the world, they are placed behind the skinned mesh matrices in that buffer. This leads to an issue where the buffer and a set of structs that index it desync from each other, and lead to rogue mesh instances placed out of bounds (this is rarely, but occasionally visible in the current build of the game, which has

      Through the course of working on the asset pipeline and animation manager, I've had to deal with a fair few broken models and assets that need to be updated for the system built. This has lead to a few headaches, as with the current system for the engine, everything is done through code and cannot be tested without significant time investment. As a result, I've had to get better at looking at a model's attributes and discerning if it will work or not in our engine. This has included (but is not limited to) checking the scale of the model, and a particular example of this is pretty egregious. A teddy bear model used by the team as a placeholder for the enemy model had a scale that was in meters, while the engine we built utilizes centimeters. As a result, the teddy bear, when translated into our engine, was incredibly massive. Now, if it was a static mesh, this wouldn't be much of an issue -- just manually scale all of the verts in the mesh and move on as though no

      The required system for this week (shortly after the completion of a bug fix that took almost the whole week to implement) was the animation management system. Simply put, there are 2 major problems to overcome for the integration and completion of this system. 1) Ensure that an entity that needs to instantiate an animation state machine can do so quickly and easily and 2) Ensure that the machines are all updated accordingly, with the data for joints loaded into the GPU-side storage buffer in the correct order. This required a shift in thinking for me, as I needed to figure out how to order the data in the buffers such that it would line up properly with the instanced draw call as well as figure out how to ensure that the CPU-side state machines were managed properly with no memory leaks. This proved to be an interesting design problem that took a large amount of problem solving to overcome.     The solution was relatively simple. To solve the first problem, I essentially started

 Author: Daniel Jackson     Our game requires the player character look towards the mouse in order to shoot in the game world correctly. This is done by using a raycast from the mouse position down into the world and rotating the player to face that position in the world. This appeared to work fine on startup but if the window was resized at any time in any way the raycast was skewed and would constantly be separated from the mouse position.      This has been a recurring issue unrelated to the actual raycast code. The code itself is set to base the raycast's position relative to the size of the window. The raycast itself works fine however, when it grabs the size of the window, its only saving one size. To fix the issue I changed a separate function to get the current size of the window when the function is called instead of getting the size of the window on startup. I've done this fix before however at some point during integration the fix had been lost in the mix again.

Author: Cameron Taylor As part of the final build the game needed replayability without restarting the program. I solely chose to solve this and the first thing was to allow the player to go back to main menu and restart the game from the main menu. The challenges I ran into was the gamestate that the main system "thought" it was on. I used the gamestate and sent messaged to intermediary to know when they could use the exit button and what to do. The other issue was level constructor was never setup to handle going back to the main menu or reloading the start floor. So when attempting to throw them back and forth I ran into plenty of issues with doors going invisible or just completely breaking. The enemies also started cloning themselves which is obviously not great for gameplay. To fix the button issue I needed to add new states to the build so that I could further figure out where we are in the program and started storing the previous state. For the next issue I needed to

 Author: Cameron Taylor I wanted to get interactables working so I made a child off of Entity and gave them special attributes that I could use to figure out what each interactable did. I then used health from entity as how much health is used to heal the player. A problem I ran into was update was called too fast! This is weird because usually the code works, but since update is called about 900 times a second then interacting with interactables started breaking. A prime example was with the starting doors. When pressing 'E' to start there was a chance that it would start twice and fill buffers twice and this took a painful amount of time to track down. To solve this I had to put breakpoints everywhere and see why the function was being called twice. Took more time than I would like to admit, but the final solution was putting a boolean check inside start to make sure the start code only happens once. Before this it was starting 2 sometimes 3 times. 

 Author: Pedro Polanco III     I was implementing the assault enemy and wanted to give him a shield but when applying the shield, I had issues determining whether a bullet is hitting the enemy from the front or the back. This would be a problem because the player would always be hitting the shield even if they are not supposed to be.     The Way I went about fixing this was by using dot product math. I grabbed a vector between the enemy and bullet and then used the dot product with that vector and the enemy forward vector which allowed me to setup a "cone of vision" for the enemy. I then check to see if the dot product is positive or negative. Positive means I am in front of the enemy, negative means I am behind them and using this it allowed me to properly decrement from the shields or health. This will make it so that way the player has to destroy the shields if they attack from the front.     

 Author: Pedro Polanco III     When I was creating the sniper class for our game, I was trying to make him teleport between the corners of the map and he would instead be teleporting outside of the map. This would obviously cause issues if it's not fixed because the player would not be able to kill the enemy due to him being outside of the map making it so they cannot progress.     When I was debugging the code, I realized that I was using improper points to teleport the enemy. When I was calculating the size of the floor, he would grab a point just outside of the room corners because I calculated the corners incorrectly. The way I fixed this is by using the bottom corners of the walls to determine what spots where valid and then I subtracted by a small amount to further push the position further into the map, that way the sniper should never be spawned outside. Fixing this allows for the player to properly interact with the enemy and clear the room

 Author: Daniel Jackson The laser is the final weapon we needed to be finished with all of the base weapon systems. However, because it behaves completely differently from all of our other weapons it needed its own system to function properly. The player firing it, its construction, and its collision checks all had to be built from scratch using different functions for each.  For this, I created a new class for the laser itself to handle its construction. I limited the player only being allowed access to one laser at a time and constructed one if the player had no laser assigned to them. If they did the laser would grow in size (assuming it's maximum radius hadn't already been reached). The collision acts as a raycast from the one firing it, forward until it hits a wall. After which, it constructs a capsule stretching from the start point to wherever on a wall the collision was registered with the current radius of the laser. If an enemy is within the bounds of the capsule dama

 Author: Daniel Jackson Because I am working on the weapons systems, I also have to create their effects such as a bleeding effect or doing explosions for the explosive weaponry. I finished the bleeding effect fairly quickly, but the explosion took slightly longer. Because the explosion persists after making contact with an enemy multiple collisions can occur. These collisions happen every frame doing the full damage over a thousand times a second (at the moment). To fix this problem I created a map inside the explosion. Whenever an enemy came within the radius it was added to the map which associated a timer with that particular enemy. Now the timer is decremented by the time between frames and the enemy is only damaged when the allotted time is exceeded after which the timer is reset.

Author: Cameron Taylor I ended up rewriting the skill tree multiple for the following reasons: first was having two different classes. One of which would be the Skill and hold the price, parents/children, and unlocked state. This was too slow for compile time so I pulled it out to put it inside a struct. Second was having all the structs be pointers pointing to each other so that every skill could be linked easily to their parent and child. This was also bad since every skill needed to be dereferenced. Not only did I need to hand write 87 skills for every since option. But I also needed to make sure that the branches were made correctly and they were connected which proved way more difficult in the end. I was passing by reference in multiple places which I thought would work but wouldn't because of a couple copy constructors in arrays. To solve all of this I made a fixed array of 87 skill structs (since that is how many we have). Then when making every I would connect all of them t

      When testing out multiple enemies at the same time I discovered their colliders would overlap and they would get stuck inside of each other when moving. Clearly this was a big problem because the enemies could not properly navigate and oppose the player. This would be a massive issue for an end user as seeing enemies overlap each other and getting stuck on  each other would completely shatter the immersive Ness as because that's not supposed to happen.     The way I went about fixing this was by implementing separation, which is a flocking algorithm I learned about in our AI class, between the enemies. Essentially separation occurs on impact with any other enemy entity and the way it works is by creating a sphere around each entity its checking with, determining if the distance between the entities is less than the safe distance which is determined by both adding the sphere's radius, and handling collision if any by applied a scaled vector to their position determined by

      The problem I faced when working on refactoring the Renderer and Central processing is a really bad race condition that causes random crashing. This is obviously an issue as it prevents the functionality of the game. The race condition is caused by multiple segments of the engine, likely within Gateware or within the audio library. The random crashing is never within the same part of the engine, although the most common sections are within the Renderer itself, which was recently switched over to a singleton system.     This problem hasn't been fixed yet, but is currently being experimented with. Possible solutions that have been tested include ensuring that all data related to Gateware is initialized at the same time, sharing pointers, etc. So far, none of it has worked, although there is a chance it could be resolved within a couple of days. I am going to discuss this with professors and other programmers to see if they can see where the problem is, but it isn't obvious

 Author: Daniel Jackson I took the lead on creating the weapon systems for our game, that includes all the weapons the player and enemies could ever possibly use. When I took on the task we only had a very simple click and spawn bullet system and it was my job to take that and turn it into each of our guns and make them feel distinct from each other. The major issue with this was that for one no weapons existed yet so everything had to be done from scratch, the bullet class that was in use didn't have enough information to perform any gun specific tasks (such as an explosion), and even if bullets did have the correct gun information attached to them, we weren't handling the bullets at all until a collision with something. First thing I had to do was create a weapons class. This held an enum that had the gun types, and every possible weapon with its associated stats as well as a way to retrieve and set said stats. Then using that information I how the bullets were spawned when t

Author: Cameron Taylor  My beginning issue with the level randomizer is I needed a way to view it in the world so that I know what is happening instead of just looking at raw code. To achieve this I set up the entire header and cpp in another engine so I can easily render everything I need into the world. The problem came when moving both files over to the project because I had to convert from float4 to gateware vector. This isn't too difficult but gateware needs proxies for things and has way less math operations than normal END typedefs. I then also had to integrate this more with Pedro's collision code to bring collision into my handle/update and figure out when the player collides with the door. As I said above I spent a good amount of time transferring all the data types over to gateware. I then spent easily 3 hours working with Pedro figuring out how to sent signals back and forth without including each others headers in our own headers. We did this by using the instance