Isaac Carman's Work&Math Blog.

Math Blog

This week, within Game Development, we were back to our normal, yearlong projects. In my case, this meant adding brand-new secondary weapons into the game.
Since I have not refactored the blocking code just yet, I haven’t been able to add the shield, but I was able to add the tomahawks and throwing knives to the game. To do so, I had to have a deep understanding of vector mathematics (Standard: Number and Quantity). When implementing them, I had to have a different approach to coding their movement and physics, as the tomahawks and throwing knives have a much slower velocity compared to the previous projectile weapons; therefore, I focused on making the initial impulse as well timed as possible, along with at just the right angle and velocity to look consistent, and “good”. Along with using vector mathematics, I had to use a deep understanding of 3D Geometry (Standard: Geometric relationships), especially for the tomahawk, as the tomahawk is intended to spin within the air after thrown. To add this intended spinning effect, I had to understand the direction to rotate the tomahawk scene, after thrown, at what intervals to rotate it, and make sure that the animation was mostly faithful to the hitbox of the tomahawk.

Math Blog

This week, within game development, the game jam was extended. Due to this, this week I pivoted back to coding to be able to make as much progress on the code for the project as possible.
My main goal for the week was to get the UI and code for each stage working and finished. This involved using Boolean algebra (Standard: Algebra and Functions) to make the logic that determines how to spawn the tetrominos that the player places down in order to increase their score. I used Boolean algebra in this way by creating multiple If-Else statements that determined which marker to set the tetrominos placement to, which tetrominos to deactivate in order to place new ones down, and how the placed and deactivated tetrominos may affect the player’s score.

(A Line, T, Z, and Square tetromino, respectively)

Along with this, I had used an understanding of 2D space (Standard: Geometry) to be able to create the game’s UI, and have it function correctly. I used Geometry in this way to be able to signal within the code where players are clicking, and if the code should spawn new items, tetrominos, or power-ups if the player clicked on the respective UI or button area.

(The game’s UI within the Godot editor)

Math Blog

This week in game development, it was another game jam, and as such, I had to design a new game. To do so, I had to use algebraic functions to determine the minimum required score that the player needs to reach in order to progress within the game. The function that determines the minimum score being: $f(x)= ((2^x/10)+x^2+10)$
with $f$ being the score, and $x$ being the player’s current stage.
Along with using functions, I also had to use numbers and statistics to determine parts of the player economy. Namely, how the player gains money and how certain “modifiers” within the game give the player extra money. The player gains money by having more unplaced tetrominos by the end of the stage, and the modifiers that can be used during stages give the player a flat amount of money each time they are used.

Math Blog

This week in game design, I had to rely heavily on Boolean algebra and have a deep understanding of Boolean algebra to refactor code that allows the player to attack with their main-hand weapon from 4400 characters of code, down to 2200 while still keeping full functionality. The code snippet below shows two boolean statements used within the new code, along with comments explaining what each part does.

Along with boolean algebra, I needed to have a deep understanding of probability and random numbers to add code that determines when a bleed effect is added to an enemy with a random chance, along with the damage and duration that the bleed effect will last.

Math blog

This week, in order to fix bugs related to the stake gun secondary weapon, flintlock secondary animation, along with certain animations, I had to use vector mathematics, along with boolean algebra. When fixing the stake gun and flintlock, I had to change the impulse applied to the projectiles to prevent them from colliding and getting stuck on the player when traveling too slow, along with creating a boolean statement to determine when to apply this impulse to make sure its after the projectile’s position was set to the correct marker. when fixing the animations, I had to edit a faulty expression that determined when to play the animations that correlate to player movement and locomotion.

Math Blog

This week, it was essential to use both boolean algebra, algebraic functions, along with geometry to improve and polish the animation system. This involved creating complex algebraic equations/functions and boolean expressions to allow animations to flow together more smoothly than before, along with more accurate detection of when to actually trigger each animation. Along with the boolean algebra and algebraic functions, it also involved using an understanding of geometry to add some minor tweaks and changes to animations to once again make the animations flow together more smoothly and add better transitions between animations.

Math Blog

This week I had finally got the animation system to start to work, which required an in-depth understanding of boolean algebra and logic. I had gotten the system to work by intertwining different variables within a script (Variables such as whether a player is running, the velocity of the player, which swing within a combo the player is on, whether the player has the block button held down, etc) with boolean expressions in a tree, that periodically updates to transition between different animations.

Along with the animation system, I had been working on fixing multiple bugs involving object collision, and a bug involving the projectile from the flintlock freezing in place when spawning, which required an understanding of vector mathematics to be able to redirect objects out of the ground, along with fix the projectile.

Math Blog

This week I had created quite a few temporary animations during the timecrunch for when we thought open house would be for the dagger weapon, which required an understanding of basic geometry principals.

(image of the animations soon i promise)

Along with this, I have continued to work on the final animation system for the main hand weapons, which as detailed in the past blog, requires an in-depth understanding of boolean algebra.

Work Blog

Math Blog

This week I had used boolean algebra to (attempt to) create a complex and in-depth animation system for the main weapons the player will use. This involves creating a boolean expression for each and every possible transition between each animation (as shown in the image below).

Using vector quantities was also essential to creating this system, as I had to determine whether to play different animations depending on the velocity of the player, along with blending multiple animations together depending on the players velocity (such as swinging the players weapon while running/walking/standing still, etc.)

Work Blog

This animation system is going to be the death of me. I started to work on it this week and have worked on little else during most of the week, and it still doesn’t work. Even after simplifying it and refactoring the code multiple times. I’m sure that I’m close though and if I keep working on it next week I can get past the silly bugs that keep haunting me. (that might also just be the sunk cost fallacy in me having some fun too but I hope not)

Math blog

This week I worked on updating the way that the secondary weapons switch between animations, which required an understanding of boolean algebra to determine when and what animation to play.

Along with the transitions and logic for the animations, I also had to create some temporary animations for the stake launcher that I made last week, and had to use a understanding of geometry to create animations from scratch using the Godot animation system.

Work Blog

This week I was really focused on getting the secondary weapon animations working, but I had finally been able to fix a bug I had been dealing with for quite some time. Said bug being an issue where when switching secondary weapons, it wasn’t assigning the weapons script to a variable, therefore whenever a function of that script was called, it would not work. I had also spent a small amount of time working on getting the foundation for two other main weapons (that being the dagger and the longsword) into the game, but not giving them animations/functionality just yet.