Cameron Taylor When I was trying to integrate new code for the project I needed to include different OOP classes so that all the information can be shared correctly. The first issue is that three of us were putting the includes in the header file when we needed those files and this worked fine for the time. The second issue is that we weren't completely communicating with what was being included. This combined together was a mess I needed to solve by moving tons of includes into the cpp files and moving some functions around so that everything could work smoothly (although build time is still slow). This issue mainly came to light when I needed to merge with other branches too. Like I said above the way to solve these issues was to move the includes into the cpp file. I also made sure that nothing was including intermediary that intermediary was also including since this was instantly making so many things crash. Then when merging I just brute force fingered through the code and f...
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...
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 integ...
Comments
Post a Comment