Log #18: Dec/2/2024

(Log for the week of November 18th)

• Still Messing with Gravity
• Designing the Ceiling
• Gameplay Flowcharts
• Shall there be Light?

Hello. This entry is for the week of November 18th, during which progress was made in a variety of areas. It seems like the level design has been eating up most of my thinking this week, but the complications of the gravity mechanic have turned out to require heavy brain-power as well.

One of the team's programmers spent a looong time trying to work out the gravity mechanic. We've been able to flip our player's camera 180° to make them upside down, but getting the player to stand on the walls seems like it's not going to work out. The complications for this involve how Unreal Engine handles its camera.

I am not qualitifed to properly explain gimbal lock, but it basically is a problem created when our camera tries to look further than 90° up or down. Even when we "free" our camera and allow the player to look further than 90° up behind them, Unreal Engine freaks out and causes our camera to shake around crazily.

To add to the problems, Unreal Engine's camera doesn't use relative coordinates. Instead it works with global coordinates. This means that while we can avoid needed to move past the lock points when the player is flipped the simple 180° to the ceiling, we can't avoid gimbal lock when the player is sideways. In order for a sideways player to spin, that have to regularly move past these "gimbal lock points", which for the reason mentioned above seems difficult.

And while we could experiment with spinning the world around the player, that will probably create big problems with the game's other mechanics.

All in all, this week one of the team's programmers spent a lot of time trying to figure out this perilous situation, and I tried brainstorming potential solutions with them.

Because of the gravity difficulties, I strayed away from designing levels that made use of walking on walls, instead using only getting some "ceiling areas" set up in one of our levels. I put in a lot ot time planning out the second section of our game, and it still needs plenty of work.

I enjoy the "architectural" aspect of level design, but I constantly feel like I need more time to work on our levels. It's hard for me to plan out ideas because I can't really visualize 3D spaces, -but that's also part of why I love it!

Work was also put in to further plan out game interactions, particularly the details of our "rebel" storyline. Much more of the game needs to be fleshed out. Working on the design flowcharts I use to communicate to the team feels tedious and time consuming, but I think it'll be cool once we can actually implemenet everything into the game.

Lastly, I spent time figuring out what additional 3D models we need for our game. Incredibly, our artists have been finishing all that I've been assigning, so I was able to spend extra time figuring out what assets we would need. Like lights.

MATH SEGMENT: Geometry Added Dec-3

I've mentioned in previous MATH SEGMENTS how I've still been measuring my levels to keep the sizes of rooms and hallways consistent, and I have been scaling models (especially cubes) to decorate and to build neat walls.

This segment will be about the kinds of things I consider when designing a ceiling that the player will walk on.

Obviously, when things are walking on the ceiling, they should be rotated 180° to appear as if gravity is pulling them up instead of down. This is different form scaling things by -1 on their Z-axis though, because scaling something by negative one may result in a mirror image. Instead we want to rotate our assets and player, as if they were doing a handstand.

Windows looking into an "upside down" floor of our game

We also need to keep in mind how tall rooms should be. With a player standing at about 2 meters tall, we need to ensure that if their is a ceiling above the player that they can walk on, then that room will need to be 4 meters tall, otherwise we could bonk our head on NPCs standing on the ceiling.

We also want to create a seamless way to swtich from being on the ground to being on the ceiling. One idea we've experimented with is a semicircle ramp that pulls the player up onto the ceiling.

A semicircle ramp curving up and out of sight (to the ceiling!)

The purple arrows in the image above represent the direction that are player is pulled in against normal gravity when they step onto the ramp. Because we want to smoothly spin the player 180°, having them walk along a semicircle does just that.

We could theortically extend this system to spin the player any amount we want. For example, to get our player to rotate 90°, the necessary ramp would be a quarter-circle, or a 90° arc.

This gravity mechanic turns out to be very fun, and offers a lot of new persepctives that the player can view the world from. This is a fun part of the design of this level. Since the player can walk on the ceiling, we need to make the ceilings look good!

Looking out an upside down window over the void that the dark sky has become

Rotating an entire floor 180° kind of makes a symmetrical level, leaving floor-like features on both the floor and ceiling. I'm excited to come up with new ways to make use of this cool design opportunity!

MATH SEGMENT: Functions Added Dec-4

As mentioned above, I did more work on flowcharts to communicate my gameplay design to the team's coders.

In one part of the game, I plan for players to be asked to copy a "file" item, and then give an NPC the original item and the copy of the item. For this task to be complete, the player needs to have at least 2 of this "file" item, getting them to utilize our "copy machine" game mechanic.

Defining the logic that our game should check for to make the sure the task can be completed is more complicated in previous tasks.

There is multiple ways we can have the game check if the player has the right items. I wrote on our flowchart that the game should check if the player has at least 2 of the necessary item. The reason we can't have the game check if the player has exactly 2 files is because if the player copies their "file" item multiple times, we don't want the task's requirement to be considered "not met."

While the above method would work, that's not the only way we could make the game check for the file and its copy. For example, we could make a special "marker" for the copy of the file item. Then the game could check that the player has an item with that marker, and that the player has the original file.

A flowchart detailing the interactions of our "copy file" task

However our team's coders decide to implement this part of our game, we need to be mindful of how different logical definitions affect the resulting gameplay.

Wether or not we force the player to have exactly 2 of our "file" item, or if we measure how many times our player copies any item, we need to be aware of how these definition restrict the player's actions.

As you can see in the above flowchart, there are two dotted blue lines heading back to the initial red box, the first event. This is because we want to catch the "edge cases" where the player does not meet the given requirements, and allow them to try the task again. We to give the player the freedom to fail, but also to try again.

Planning what logic is required for parts of our game is interesting, and helps our team's programmers better understand what I'm asking them to do.

I hope you didn't hate reading this post. Cheers.

-Luke Knotts