Log #19: Dec/8/2024

• Gimbal Lock Thoughts
• Explaining a feeling
• What Will We Make?
• Organization Takes too Long

This week was pretty good. I realized that I didn't know exactly what "feel" I wanted our game to convey, which, as a designer, is problematic. After talking about it, I spent some time not only thinking about what I wanted, but what would interst the rest of the team, and what would be the nices thing for our player.

While I was struggling to phrase this, I tasked one of our team's artists/other designer to work on laying out what else we're going to need for this project. They quickly began listing out ideas of ways to improve the game and things to add. They are good at finding things that don't feel intuitive and pointing them out, and as I've been able to communicate the idea of the game better, they've able to better contribute design ideas as well.

As I was talking with them, they asked me to describe the gameplay that I was envisioning. It sounds simple, but until I wrote a simple document summarizing what I had been envisioning, I don't think they fully understood what I had in mind (or how our game idea would be any fun at all). This turned out to be way more helpful than I expected, and it actually helped me plan out later sections of our game. Simplying imagining what our game looks like in a greater detail is super helpful, and I think I should have been doing this so much sooner!

Articulating the "feeling" we want to convey with out game is kind of a weird thing to do. At first, I thought I would need to be a poet in order to properly explain some of the weird feelings I had in mind. But after talking with others about this, the technique of first explain what our game is not turned out to be very helpful. I think the ideas for the game's design started clicking when I was brainstorming one night, and they developed into a better state as I thought about what gameplay would be interesting a few days later.

I think I have decided that I want our game to feel awkward. We want to juxtapose social awkwardness with empty "liminal" spaces, playing primarily into the fears of disapproval and the unknown (with some fear-of-insignificance sprinkled in there as well). Rather than being directly scary, we want the player to feel intriuged to learn more, to generally be curious about why things are as they are, and to question whether or not they should really be scared.

I also spent some time doing more level design. I am getting faster, but I may need to better balance organization and neatness with efficiency. It's weird for me to design levels, becuase I can't exactly picture what things will look like before I actually do them. I think it would be beneficial if I were to brainstorm level design ideas, because it's easy for me to get locked in to making the first idea that comes to mind -but I don't want to miss out on other cool ideas!

MATH SEGMENT: Geometry

Gimbal lock. I think I finally understand it. While I think our team has decided to drop the full 6-direction 3D gravity changes in our game due to technical difficulties, thinking about these problems has been very interesting, and pretty mathy.

One of the problems with trying to rotate the camera in our game is that we can't change the camera's frame of reference. This means that if we rotate our player 90° to be "on the wall", when we look with our camera to the left or the right, we have to pass through the point of gimbal lock.

I don't fully understand how Unreal Engine works, but the problem of gimbal lock is an interesting one that took me a little while to understand. The following YouTube video helped me better understand the process of gimbal lock: https://youtu.be/zc8b2Jo7mno

Gimbal lock is when we loose the ability to rotate our gimbal along a specific axis, because our gimbal is rotated in such a way that two axes line up and are spinning on the same axis. This happens because the types of gimbals we are using do not have independantly spinning wheels. When we spin the outer wheel, the two inner wheels spin, and the middle wheel also spins the centermost wheel, which spins only itself.

There are different ways to arrange gimbals with the x, y, or z axes being on the outer, middle, or center wheels. These arrangements are labeled like XYZ or YZX, starting with the outermost wheel, and working your way in.

To envision what happens, we'll lable our x, y, and z axes with different terminology. Our x-axis will be our pitch, which if you imagine from the perspective of a person facing the y-axis, is the axis that person would use for a backflip. Our y-axis will be our roll, which is like this hypothetical person doing a side flip. Lastly our z-axis will be our yaw axis, and is like our person twirling or spinning.

If we use an XYZ gimbal, then when we rotate on the x-axis, the inner two wheels spin relative to our x-axis. To reach gimbal lock, we just need to spin 90° on the y-axis (or have our person do a quarter-side flip), and then our z-axis spins on the same axis as the x-axis, effectively removing our ability to move on the z-axis. Or in other words, because our person is sideways, twisting that person while their sideways up along the pitch axis (like a sort of barrel roll) does the same thing as making that person twirl on the wall. Because the person's z-axis movement is reliant on the orientation of the outer y-axis, their relative z-axis is the same axis as the outermost x-axis.

This is an interesting problem, becuase, going back to our video game, this set up would mean our player wouldn't be able to look up or down if they were on the wall.

One way we could try to fix this is by rearranging our gimbal so that gimabl lock only happens on an axis we don't need to use. In our video game, our player only needs to be able to look up or down 90° and to be able to spin along their z-axis. This means, a potential solution to this problem could be use a YZX gimbal.

Envision our hypothetical person again. When they are twisted 90° to be rotated onto a wall, they can still move along their z and x axes without being messed up by gimbal lock. Gimbal lock occurs when the person is twisted 90° on their z-axis, but the axis that we loose the option to alter is instead the outer y-axis, which isn't an axis we need to rotate our player on. Because our player doesn't need to be able to do a side flip, we never actually need to rotate the camera like that, so our problem is solved.

These gimbal lock problems are incredibly interesting, and fun to think about. The one difficulty is that we have to work with what Unreal Engine is capable of, and I don't think there is a way to change the rotation order (the arrangement of our axis wheels) of our camera, so we'll need to be more creative if we want to implement our gravity-chaning mechanic to its fullest potential. We'll see what happens, but at the very least, we got to learn about interesting maths!

MATH SEGMENT: Data Added Dec/9

Our team's programmers spent a lot of time organizing code. It was decided that we would switch to using Unreal Engine's data tables to store the NPC dialogue. Data tables are sort of like spreadsheets. In fact, data tables support importing CSV (comma-separated value) files.

With data tables we can access our NPC dialogue stored in these tables by row. It is essentially a matrix that contains the information holding what our characters will say. The first column in this table gets the eloquent name, "Name," and is used to label the adjacent rows.

This is also a cool way of storing data because it is user friendly. The spreadsheet compatibility allows working in other softwares like Excel to happen. A designer like me can easily plop information into a data table, and the programmers will have defined how the different rows in that table are treated.

For now, we store strings in these tables that we can access when we need to in-game. We can organize these tables however we want, letting us access NPC dialogue in flexible, but still organized ways.

-Luke Knotts