Dragon Guild Blog

author: Swapnil Narola Date:  2/24/2022 I had to display UI on the screen and didn't know what to do and how to do, didn't found any example online because it was so easy to have a tutorial. i made billboard to make it as a display but not success to attach it to camera. i found Sascha will ems blog post on post process and he uses a huge triangle to cover the screen without buffers and  vertex input, but its just one image i can put on at the end of day, so i learn from that triangle to make a quad on a screen and finally able to display pause menu on screen. which i only had to pass a quad to vertex shader and multiply with world matrix and change rasterizer pipeline cull mode to front, there you have a ui display.

      The problem I faced during this week was the integration of the audio library through Wwise. This problem arose because I had never worked in the Wwise SDK before, and had to integrate it within both the CMake lists and the code itself. This would cause a litany of issues related to linker errors if the library and dlls are not imported properly. In addition, the system would then need to initialize the audio library, which requires me to go through the setup code for Wwise's sound engine. This and more required research more than anything, and as a result was time consuming.     The solution was simply more research. Having time on my side (at least during this time of development) along with documentation that Audiokinetic provided with the Wwise SDK made the integration of that library relatively smooth. The library itself has many features that make it relatively simple to work with the sounds. Loading the banks properly is a relatively simple operation, provided they are

       I had a problem today when trying to detect sphere to AABB collision. For some reason the collision check that I made was never turning true even though I could clearly see the sphere hitting the AABB. This was a big problem as we needed this collision to detect whether any entities are hitting walls.     I discovered that the problem with this bug was that I was improperly getting the closest point in the AABB to the sphere. The way I fixed this problem this problem was by getting the max vertex that the circle center could be and using that to get the closest point on the AABB to then determine the minimum vertex between the sphere's max vertex and the max of the AABB.  Once I found this point, I could properly compare the distance of that point to the center of the sphere. This solution will allow detection between walls and any sphere collider such as the player collider, and enemy collider. This is very important to make sure they both stay within the level bounds.

 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 The idea behind this is simple enough, we make the player look towards the mouse. However, when you realize the mouse is always right with the camera and not actually in the world things get a bit more complicated. Knowing that our biggest problem was trying to do a ray cast from the position of the mouse on screen, to a position in world space. From there we could take those coordinates and rotate the player to face them. When we tried to do this, everything was wrong, the start point of the ray wasn't connected to the mouse correctly, it was moving in a strange way, and the "end" or what we could see from the camera was in an incorrect position. In the end I got the mouse position and converted them to ndc space so the math could be done correctly and saved them into a vector that represented them on the near plane. Then, I had to un-project the matrices to get a position that would act as a start and end point to a line. Finally, I saved the sta

 author: Swapnil Narola i was making particle system for the engine. i had a success in having particles show up, now to the next step having texture on it. this was my first time having texture on the particle, but for some reasone the system was not making local UV for one particle, rather have one uv for all the particle. it was my first time having texture on a point and making UV for it, So i took guides form the vulkan official example code on how he did the particle system, i took the shader code and implemented it, there was one thing i missed was i forgot that vulkan NDC has its y flipped. it took me a week to figure out the problem. when the code use to run you can see there is a partition between screen as i was doing sceenspace UV where half was red and half was yellow, as i move my camera the color change based on position, whcih was basically having UV for the entire particle. it suppose to have UV each individual particle. eventually i got in connect with Rockstar games

      The problem that was plaguing my development was with the integration and use of Gateware. The problem is not a singular issue, as Gateware has caused numerous issues throughout development despite being made specifically for working in game projects. It seems to enjoy fighting with other third party software brought in for support. A fantastic example is FBX, which seems to be a mortal enemy of Gateware, and cannot exist in the same project as Gateware without there being many issues and conflicts between the two. Gateware's math library, while useful, does have its fair share of faults, as it ends up having missing safety checks. During the creation of the animation code, this posed a problem, as the Quaternion SLERP function was missing the safety check for when the inputted quaternions were facing the same direction. This caused a problem where verts in the skinned mesh were all multiplying by a matrix of NaN, and led to a portion of the mesh being totally missing despite

 Pedro Polanco III  2/17/2022         I had an issue with creating my branch correctly and making sure it was based off of the staging branch instead of the main branch. This problem really only affected me as it was my branch that was not made correctly.          I discovered the issue was that tortoisegit was not showing the staging branch. So, in order to fix this, I had to push my current branch to main then redownload the repository. This finally allowed me to rebase my navmesh branch on to the staging branch instead of the main branch so that way there would be proper source control and that when I pushed it would get pushed to the staging branch instead of the main branch. This will prevent me from breaking the repo by making it so I cannot directly push to main.

 author: Daniel Jackson                     Since we are only at the beginning of the project most of our issues have been engine related, and as I am not working directly on the engine personally there hasn't been very many issues for me as of yet. However, with what I have done so far, GitHub has been a real nuisance. There was an issue where entire branches were not showing up or being available for us to switch to or view.                          After multiple pulling attempts and switching between our main branches nothing had worked. We found that for some reason after a new branch was created and pushed, sometimes the new branch just wasn't appearing like they should. We ended up having to save whatever we had and re-clone our repo which solved the issue and allowed us to keep working.

 Author: Cameron Taylor Posted on 2/17/2022 I started working on the random level generation and my biggest issue that the time was that I wasn't able to tell if the generation was correct or not. In order to fix this I opened up my END lab and transferred over my files to start drawing the levels out onto the screen. I then had an issue where none of the rooms were connected and I had no way of detecting if two rooms were next to each other to connect in the first place. This is a big issue because if not all the rooms are connected correctly or in a manner that is solvable; then the player can't finish a floor. The main issue that was holding me back is that I had no way to know where one room was relative to another. To fix this I used a map to store the location of a room and the output was the index inside the vector of rooms. Once I was able to store that I could generate a whole bunch of rooms all stretching out like a snake and showing proper connection points. I had a

 https://drive.google.com/file/d/1xuvfOxT_lo4AYzoxAMOlnkVBBvsMr3vB/view?usp=sharing

     In Project [REDACTED], you play as an unnamed cyborg  experiment trying to escape a secret government laboratory. You progress through various floors of the facility acquiring new skills, weapons, and abilities as you take down hordes of enemies, ending with a distinct boss at the end of each floor.