Log #32: Mar/29/2025

• The Final Stretch?
• Filling in a Flowchart
• Designing Levels

This week it was announced that the deadline for our game is nearing. Our team has known this, of course, but it's still scary to hear.

All of our groups met and discussed the upcoming deadline, and how much time we have left. Immediately afterwards me and the rest of Team ERASE privately met and laid out our own plans on what we were going to do.

Because of last week's Chaos Jam, we were not able to finish a "white-boxed" progression through all of the game's levels. This is okay, but it does worry me a little bit.

The team's programmers did work this week on trying to finish that over simplified progression through the entire game.

In our meeting, I also brought up my confusion on the main player motivations in our game. After talking it out for a second, we were able to articulate the two main motivations that we will plan for: Trying to climb the corporate ladder at ERASE, and trying to sabotage ERASE. While I think I already knew these things, talking about it helped me know it.

The rest of the week was spent reformatting the flowchart I've been using to plan our game, working on designing the final level's appearance, and experimenting with some new architectural designs for our game's levels.

MATH SEGMENT: Geometry

As I mentioned above, I have been experimenting with new architecture designs for our game's levels.

One of my biggest inspirations is M.C. Escher's Relativity, an awesome display of gravitational inconsistency. You can see the work at the below link:

www.escherinhetpaleis.nl/showpiece/relativity/?lang=en

Escher's work is a big influence, and so I decided to try to imitate the architectural style of Relativity in our game.

One key difference between our game and Relativity is that Relativity has three directions for gravity, while our game only has 2 (due to technical difficulties mentioned in earlier devlogs).

Unfortunately, I don't have pictures of my work I can show you, but I will bring up one problem I had while doing working.

Because our stair meshes were not made with the plan of being viewed form the side, I ended up not having a good way of putting a wall under some stairs. Instead of making a new wall mesh with a step shape at the top to fit under stairs, I used a ramp and scaled it to be as thin as a wall. This worked okay, but I ran into Z-fighting between the ramp-wall and the stairs that were on top of the wall.

Z-fighting is when 2 objects are at the same plane, and so the camera struggles to render one on top of the other, making the two objects appear to "fight" back and forth to be the one you see.

In the meantime, my bad workaround is to set the ramp under the stairs ever so slightly so that the stairs clearly win the Z-fight.

What I should probably do is make a new mesh that fits nicely under stairs like a puzzle piece, but my ugly solution is probably good enough, and gives the steps a somewhat stylish overhang from the walls.

This ended up creating more problems for me though, because suddenly walls under stairs were offset, meaning I had to jig things around to make sure that there were no visible seams between wall actors.

I guess the moral here is to build your meshes knowing how they will be viewed in-game, and potentially redo them to fit their functionality. Or the moral is to create a systematic way of offsetting your walls for stair-overhang, that way you can predictably fit everything together (as opposed to repeatedly adjusting assets' locations like I did).

But whatever you do, don't leave your meshes to fight over the lime light. Find some way to stop two objects from overlapping on the same plane and Z-fighting.

MATH SEGMENT: Algebra and Functions

In my own time, I have been wanting to wade into the math pool of Calculus. I have not kept up on the Kahn Academy course, but thankfully it's not too late!

I learned a little bit about how to calculate derivatives, which I found very interesting. I'll discuss what I've learned below, but I should preface it with the fact that I am currently learning this stuff, and so lack an authoritative or educated voice on these matters.

A derivative can be used to find the "slope" of a function at any given point, or how quickly the output of a function changes based on its input.

While a point can't be used to calculate any sort of "rate" or "slope," you can calculate the slope of a super close point. This is basically what the formula for calulating a derivative does.

The formula for calculating a derivative.

In the above image, "h" is how far away the "super close" point is. The "lim" part of the equation says that we want to solve the equation as h approaches zero, or in other words, we want to calculate the slope between two points that aren't really apart at all. But as you can see, if h actually was zero, we would have to divide by zero, which is super illegal.

So, we can use algebraic wizardry to avoid a division by zero. And that's okay because we are calculating a limit that approaches zero, not zero itself, so things work out.

I find this formula very interesting because it practically feels like cheating. It calculates the slope of a point, something that seems impossible to do, by using infinately close inputs. Pretty creative.

Learning about the sneakiness of derivatives is interesting, and I look forward to learning more calculus.

Thank you for taking the time to read my stuff. If there is parts you like, or parts you don't like, email me with the below email. I would appreciate the feedback.

-Luke Knotts