CAGD 470 Sprint Blog 6

11/20/2025

Sprint 6 Kickoff

For this sprint I focused on a couple of things that I needed to definitely take care of since last time. One of the main crucial ones was getting our animations to play properly with our character model of the player since I could not get them to work for our build last time. My other tasks involved fixing bugs heavily that appear to break core features and mechanics of our game that would cause our players to get frustrated and not enjoy our game. We learned all of this through our team's most recent playtest feedback we had received from our last prototype build. 

So, like I explained I first started by reimporting our model that came from our FBX files that had the animations attached so that I could now use the model that had the appropriate rig and skeleton attached to it. Once I did this I went ahead and reattached all of the important components to that model's inspector window in order to match our old player game object. After I did that, I made sure to attach my animator controller as well as my respective player scripts and I gave it a shot. As soon as I did that it worked perfectly and I marked this card as complete. 

The next thing I immediately worked on was updating all of our speed variables across the board. These included player movement, animations and ability timers. It became clear to us during our playtest feedback that players thought the movement for our game felt too slow and buggy, so I wanted to address that almost immediately. All I really did for this was go into both of my player scripts and update all the float values I had declared for speeds. Player speed went from 5 to 8, Animation speed from 1 to 1.75 and another important one was sun pillar charging that went from 5 seconds to now only 3 seconds to charge. These would all now reflect faster speeds that would make our game feel much smoother. 

The last and perhaps most challenging thing I worked on was bug fixing. There were quite a few bugs that were still lingering around in our latest electronic prototype and that were brought to our attention during the feedback. There were at least 3 big noticeable bugs but one of them was by far the most annoying and game breaking bug, which was ultimately a wall clipping bug. The problem was players were using our dash mechanic, and it would accidentally cause them to clip into walls or blocks in our levels making them stuck and having to restart the level entirely. This was very frustrating to our players, and it made their play experience very poor unfortunately. It is because of that reason that I actually spent a lot of hours finding a solution to this bug. 

At first, I tried casting a ray cast in either direction that my player was facing in order to detect when my player would nearly collide with a wall so that my dash mechanic could stop there. I was basically getting nowhere with this and I had to ultimately redesign how my player was moving completely. I used to move my player through transform.translate and apparently Unity physics does not like this, so I instead rewrote all my players movement to now rely on its rigidbody attached to it. Both my player movement and dash used to move that way so making these changes was definitely necessary. As soon as I did this I would no longer be able to clip into walls and that bug was 100 percent taken care of. This was a huge win and a massive relief because this bug was terrible and game breaking.

CAGD 470 Sprint Blog 5

11/09/2025

Sprint 5 Kickoff

For this sprint I had a couple of things to work on right off the bat. Some of them included getting our special tile effects to work directly with our players' movement mechanics, as well as getting our animations implemented to finally reflect our player idling, walking and jumping. This sprint was also important since we needed to have a new electronic prototype ready to go by the end of the sprint to showcase and get some playtesting out of it.

So, as I mentioned I began this sprint on working with the 3 different tiles that our team made for our game. The Slime tile, Dandelion tile and the Mushroom tile. All of these needed to have their own distinct effect on the player, and they basically would affect the players momentum as far as moving and jumping. I started working on the slime tile since I thought it would be the easiest to accomplish. What I did for this was create a couple of new variables inside my player collision script that would reference both new slower and weaker jump variables. Since our speed and jump variables would now be changing at certain times, I also renamed our original variables to reflect normalSpeed and normalJumpForce. This way our player could always go back to their original momentum speeds as soon as they left the specific tile. 

As soon as I had this it was easy enough to now in my same collision script write a new if statement inside OnCollisionEnter to now check when the player has collided with the slime tile. When this is true it would simply set my players original momentum speeds to the newer slower and weaker ones. I also made a separate one to check if the player has reentered a normal ground tile to reset their momentum speeds back to normal. 

I did the same process for both the Mushroom and Dandelion except that these 2 had different effects. The mushroom tile grants our player a super jump force while the dandelion grants our player super speed while they are on it and for 5 seconds after they have left the tile. Above is how I was able to get them to work similar to the Slime tile.  The only difference is that for the dandelion in order to get it to work for 5 seconds after, I needed to write an IEnumerator that could start a Coroutine as soon as I have left the Dandelion tile. This if statement would need to go on my OnCollisionExit function for it to work. 

Immediately after all 3 of those tile effects were working I started to implement some of the animations that our team had ready for me to add. This was perhaps the thing that took the longest to do and overall, there were some challenges I had to face in order to get it to work. I started by making sure all 3 of our animations were set as clips in our inspector and made sure that both the idle and walking were set to loop. After that I made an animator and attached it to our player and also set the 3 animations inside of it with the appropriate transitions to them.

The problem I encountered was that the player model I had set up in our scenes was not the one that had a skeleton and rig attached to it so unfortunately, the animations were not able to be seen even though they were actually running. In the animator window each one of the animations was getting triggered except you could not see them play out in the game view. My fix for this was to instead drag in one of the models that came with our FBX files of the animations instead and it seemed to work but by then our whole movement script had broken. It is because of this that we ultimately decided to not include animation into this build for now while I take some more time perfecting the animations. That will be my entire focus next sprint.

CAGD 470 Sprint Blog 4

10/26/2025

Sprint 4 Kickoff

For this sprint I had one huge focus that I needed to accomplish. Essentially it was to convert all of our old movement system to Unity’s new input system. At the start I had underestimated how much time this would actually end up taking me since I just thought it would be a simple change, but it ended up being more difficult than I thought. The problem was I was trying to quickly convert all of our old movement functions to now work through the new input system directly without first considering that the whole movement functions would need to be reworked.

For example, the old way of moving right and left was through directly telling my players transform.position to now move either left or right and the new input system does not seem to like that. Another big contributor to the problem was the fact that I did not stop and test my code every couple minutes like I should have been. Instead, I tried to rewrite and try to match everything with the new input system and then run my code. Long story short, I ended up getting all 3 of my main old movement functions (Move, Jump & Dash) to finally work in the end, but it would have been done a lot sooner and easier if I had been more patient with it.

Alongside this entire mess I was also trying to productively clean up and decouple a lot of my old code in order to get it to look much more professional and cleaner. This was important to do since my old script basically had a lot of moving parts all tied together. Essentially, I had all of the 3-movement mechanics, the collision detection as well as the glowing functions all in 1 script totaling over 400 lines of code. This was definitely an inefficient way of doing things since I would constantly need to go back to this script and alter or check the code for testing and debugging.

What I did for this was separate the players mechanics from the collision events into their own scripts that would tie directly back to my player prefab. Inside those scripts I also made headers for all the variables that could basically be considered in the same group. I set a bunch of those variables to private as well since I would not need to edit them inside the inspector window and would clear up a lot of space for the ones I did need. To summarize my player prefab would now have 2 scripts attached, one for all the player inputs/mechanics and one for all the collision tracking. This would now make it 10 times easier to go and update something in the code if I needed to in the future based on the thing I am trying to add. 

By the end of this sprint, I was also given some tasks to work on implementing a key and door system. So, what I did for this was create 2 simple prefabs in the meantime of a key and one of a door. As soon as I did that, I gave them colliders, and I was able to get them to play animations that I made inside the Editor. For the keys animation I made it so that it could be a looped animation that basically looks like the key is spinning and floating in space while the door was just a simple change in y position. Then I moved on to throwing the animation of the door into Unity’s Animator so that it could be listed as a clip. I would then play that clip through code whenever my player has collected a key and has collided with the door. This was simple enough to do after all my movement and code was polished up so I'm glad I was able to accomplish a lot this sprint.

CAGD 470 Sprint Blog 3

10/12/2025

Sprint 3 Kickoff

At the start of this sprint, I was assigned some more programming tasks and a couple other ones that involved setting up our UI to showcase our players charges.

As I mentioned one of the key things I worked on this sprint was creating our games Sun Pillar working. This required quickly creating a simple prefab that I could use to test. I made a mock-up prefab and attached a collider to it so that my player could detect collisions with it. After that I made a tag for it and attached it to itself in the inspector. The way I got it to work was by creating a function inside my player controller script that would allow for this pillar to recharge my player’s sun charges if they collided with and stood there for a total of 5 seconds. 

After I made that I also wanted it to only grant me 4 charges and once I had the max amount of charges it would no longer keep charging our player. This was simple enough since I already had the recharge function working properly. The last thing I needed for this to fulfill my assigned card was to showcase some sort of visual for our character model charging.

This was perhaps the hardest thing to tackle since I had never altered any material in unity before but after a couple of searches, I was able to figure it out. I had to grab a reference of my players assigned material through code and I did that by assigning it in my start function.  Once I did that, I created 2 new functions, one that would play a pulse glow mechanic to show the physical glow when charging and the other to fade out the glow in a smooth way when my player reached full charge. I was able to make them work by creating a new color variable that would essentially be my new glowing color and setting my players material to this new color for a short period of time. Along with that I made some other variables that would handle the glow intensity.

Once I had these 2 functions working properly, I made sure to call them whenever my recharge function also gets called in my update. Getting this to work was so awesome since it is a huge feature we wanted to implement this time around. 

After all that I moved on to making sure our 2D sprites were properly hooked up to our UI so that we can now effectively display charges on screen. Since the 2D sprites were made last sprint, it was easy enough to have them hooked up. What I did for this was to go back into my player controller script and make 4 new variables for game objects. This 4 would be specific for each one of my groups of UI images I made inside of unity.

Each group consisted of 2 images, one to showcase when the charge is active and the other show it empty. Once I had those ready, I simply wrote 1 if statement followed by 4 else ifs in order to set those game object variables to off. It was easy enough to go down the line for each scenario where in the first statement they are all active and in the last one they are not. They all essentially just check to see how much sun charges my player has. 

That was pretty much my main focus this sprint with the exception of a few other things and ultimately, I think my team really stepped up this sprint and I believe we are beginning to head in the right direction.

CAGD 470 Sprint Blog 2

 09/28/2025

Sprint 2 Kickoff

Welcome back to my blog guys today I will be covering how my team and I’s progress went for our Sprint 2 for our Sundance game project. I will also be going over the work I was able to accomplish and some of the issues we encountered. Let's dive into our games working Progress.  

As for this sprint, I was assigned some more programming cards to accomplish, and they all had to do with expanding upon the work I had completed last sprint. Which was essentially our player prototypes basic movement mechanics. Having all that setup I started working on 2 key things. Our players dash mechanic as well as the double jump mechanic. Since I knew one was going to be harder to do than the other, I started with the one that would take me longer, which was the dash. My card for this entailed me to set up a dash mechanic for players to use whenever they would double click either A or D at a certain moment. So, I started to experiment a bit with my already made player script. First thing I needed to do was to alter my movement function to now also check if I have clicked either the A or D key within a single time frame in order to activate the dash mechanic. I did this by writing a couple new variables and making a Boolean as well to check when I am dashing. 

After creating these it took me a while to figure out how to implement them correctly but after a couple tries, I was able to do so. I basically had to tell unity to remember the last time I had pressed one of the keys and if I hit that key within a certain timer, I would suffice the criteria I needed to dash. 

Working on the Jump was a lot simpler and easier to do. For this mechanic I did not have to check If I had double pressed the space bar within a certain time. Instead, I would only need to check if I have jumped once then I can only jump once more. I was able to accomplish this by using my existing Boolean that checks if I am grounded and a couple new int variables that would count how many jumps I have used and setting my max jumps to 2. This would allow my player to jump if I am grounded and once, I have jumped I could only jump one more time. Additionally, both of these mechanics needed to work without messing up any of my old movement code. On top of that as well I would need to further implement a counter that only allows me to use those abilities if I have picked up a sun charge. In game my player could simply collide to one of the sun nodes and the count would go up. Following that I would then have to simply implement that count check into my if statements.

Overall, as a whole team this sprint we had a little bit of a rocky start. We ended up having to change our team's meeting time to a whole new time and date in order for everyone's schedule to align better and ultimately it did not work fully to our advantage, costing us quite a bit of confusion and time spent on the project. We were able to discuss this issue as a team and going forward we are all going to start dedicating more time and meeting at our appropriate times in order to prioritize what needs to be done on time.