Log #30: Mar/7/2025

• Important Team Meetings
• Backrooms?
• Flowchart (now with GIFF's!)

Good morning and welcome to Luke's blog! confetti noises. Perhaps one of the best things we did this week was have two solid team meetings. In the first, I initially agreed with one of our coders, and suggested polisihing a game jam project for our portofolios. But one of our artists brought up the amazing point that it would probably be best to finish any portfolio stuff after we can get our game finished. This simple suggestion set our course for the week, and I think it was the right call. Obviously our game is the priority because it has the soonest deadline, so it's smart to save some of our other tasks for later.

The second good meeting we had was very short. One of our coders brought up that due to our upcoming game jam (more on that later), as well as spring break, our time to work would be limited. So I cut the plan down from finishing a playable version of the game by the end of this month, to instead pushing for a playable version of our game without all of the task minigames by the end of the month.

The rest of my time mainly consisted of trying to plot out the rest of our game. For some reason, I found myself hitting writer's block while doing this. I've been focusing my energy on trying to hit a certain 'liminal' feeling with our game. Instead, I was able to continue moving once I "loosened up" and started being a little sillier. I added a GIFF to our game plan flowchart. For whatever reason, that simple action helped get me moving again.

I think going forward, instead of trying to pursure a weird 'liminal' feeling (one that slightly embarrases me, if I'm being honest), I want to focus on the strange sillyness that initially brought people onto this project. And, if I'm able, maybe I can still leave a few moments of viceral/surreal/wimsy/desire-for-peace in the game too.

MATH SEGMENT: Geometry

While most of my work this week was focused on planning, I did do a little bit of level design. Inspired by the original image of the Backrooms, I set out to experiment with more Backrooms-esq room design. For those of you who don't know, the Backrooms is an internet mythos and urban legend consisting of infinately winding hallways, and other strange places.

Kane Pixels, a YouTube content creator, has made multiple videos on the "Backrooms", and is probably the biggest name behind the Backrooms. Based on a model from one of Pixels' videos, I wanted to see how an tesselation of repeated rooms broken up by doorways looked.

The top of my "Backrooms" experiment.

As you can see in the above image, I just made a simple room that could be copied and placed alongside itself. As you can see below, the door frames obscure your field of view helping you lose your sense of scale, and the repetition makes it feel like a maze.

How far does it go?

To build rooms that can be arranged in this way forces me to make my structures vertically and horizontally symmetrical. The symmetry ensures that the room can attach to itself neatly. I also made each room a square with identitcal (or nearly identical) walls, that way you can lose your senes of direction. The shape did not have to be square, but the square is symmetrical so it doesn't give you much information about direction, and it tiles so it can repeat on and on and look the same from multiple directions. I can also lay out square rooms in a neat grid.

If I choose to actually implement something like this, I would want to scatter a few decorations about to keep things interesting (and so you don't just get completely lost).

Building symmetrical, tileable and reuseable rooms is not only commercially practical, but it can also be used to convey a strange feeling.

MATH SEGMENT: Algebra & Functions

Planning parts of our game backwards has been helpful. While I don't necessarily know how all of our tasks will end up (that depends partially on how well our mechanics can work), I do know where I want the game to end.

As it turns out, our game's ending is sort of complicated. We want the different possible endings (one of which makes the player the CEO of the in-game company) to be encountered based both on how well the player supported the in-game company, and how the player got to our game's final location.

The work-in-progress flowchart detailing the progression of our game.

As you can see in the above image, two red lines connect to the blue box labeled "CEO's Chambers." That's the final area of our game. The red lines represent the two ways in which the player can reach the CEO's Chambers. But inside the blue box there is more branching. From the CEO's Chambers we can then use the "company health" metric (which I've mentioned in previous posts) to give the player the ending we want them to recieve.

This means that the code that determines the game's ending needs to acknowledge how the player came to the CEO's Chambers, and the player's support for the in-game company (the "company health"). The way the player enters the final location can be recorded with a boolean value, since there's only two possiblities, and the "company health" metric will only be a simple integer that we can check the value of.

Breaking down everything that needs measuring into simple steps helps orchestrate our game's end. It doesn't always seem deep and life-changing, but clearly laying out in a flowchart of what needs to happen can be suprisingly surprising.

Building a simple logic tree like what I've done below ensures that you really understand what you're trying to do.

             How will it end?
                    |
                   / \
           Door 1 /   \ Door 2
                 /     \
                /       \
        +5 points?      +2 points?
          /     \        /     \
     No  /       \ Yes  /       \  No
        /         \    /         \
Tragic Ending   Good Ending    Average Ending

The above shows an example of the somthing similar to the logic our game's ending may use.

That's all I have for todays blog. Thank you for taking the time to read this!

-Luke Knotts