Skill Tree being a Skill Tree

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 to each other in the correct order. Once they are connected I would then finally push them into the array so that the copy constructor would copy them over with their children and parents still set. I then made a switch case of all 87 skills each to call their appropriate functions like raising health or increasing damage. I was told I could make a function pointer for them but in the end it would still be setting every single one of them and I would have to make the functions to in the classes in the end. Switch case allows for more debugging in the end right now.
Location: 178 Ward Dr, Winter Park, FL 32789, USA

Comments

Post a Comment

Popular posts from this blog

Adding assets to every enemy -- Owen Meyers

Image
      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
Read more

Sphere to AABB collision

       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.
Read more