Log #15: Nov/2/2024
- Grey Characters
- An Underdetermined Plot
- This Isn't Minecraft...
- Like a Lost Child
This development log coveres the week, spanning from October 28th to today, November 2nd. I honestly feel like I dropped the ball as a designer this week, failing to provide clear plans for the game's characters, story and feel. But I suppose failing is how one learns.
Designing characters for our game was difficult. I originally wanted a diverse cast of NPCs, but that proved to be an enourmous workload, so we ended up pivoting. We decided that the characters should be simple variations on a grey humanoid, that way we can create lots of unique characters without doing a truckload of work.
If I'm being honest, I think I was trying to make myself look "commendable" and "cultured" by pushing for more diverse characters, but in reality some of our efforts were just a drag on the project because the idea wasn't very feasible. Making a large number of completely customized NPCs turns out to be a lot of work. Just goes to show how trying to impress others can get in the way... However, I think we also learned a good deal about character deisgn, so at least it wasn't all for nothing.
But part of the problem remains, because I still sit on the fence on how exactly the NPCs in our game should be. I originally wanted everyone to be different, but now I feel conflicted because I don't want our game to feel too much like the TV show Fired on Mars (2023), one of our game's influences.
And I never really got to actually finalizing the direction for the characteres of our game, because I felt preoccupied with designing the layout of an area in our game. I pretty quickly found out that laying out a level in Unreal Engine is slightly more involved than I had previously thought.
Despite the difficulties, I learned a lot, and feel much more confident about designing this new area in our game. I'll tell you more about these level design challenges in one of the below MATH SEGMENTS.
All of these things got me thinking about what our game should be. Despite the lack of direction I've been feeling, there is one thing I feel pretty confident about. Our game's feel. And after some thought, I think I have finally found a way to communicate what "feel" I want our game to give players, -at least partially. I imagine our game as something similar to experiences I've had wandering empty rooms in large unfamiliar buildings. The sense of exploring somewhere without explicit permission is appealing to me, and I like being able to wonder about what goes on in said buildings.
MATH SEGMENT: Numbers, Coordinate Space Transforms
I promised above that I would elaborate on my level designing endeavors. I learned that a good way to do this was by simply typing in the locations of my game's actors. Punching in the coordinates of everything worried me, however, because I thought I'd have to perform lots of calculations to correctly lay out things.
It turned out that I was correct. One challenge, for example, was when an object was rotated. I ended up having to swap which local axis I altered in order to move something in the same global direction. This felt tedious, but I learned other, significant tips.
Firstly, when laying out levels, one arranges everything in the level roughly at first, and then, knowing where things go, you can do all of the math once, instead of having to redo things each time you make a small change to the level layout.
Secondly, I learned that I needed to ask our team's 3D modelers to make sure the origins of the game's models were in a bottom corner. The origin of an asset is the point that represents the asset's location. For a lot of our assets, this was in the center of our models. The reason I want to switch to putting our assets' origins in the bottom corners is to make the necessary calculations much simpler. For example, I'll explain what I was doing if I wanted to place two assets next to eachother whose origins were in those object's centers:
First, I had to find the first asset's location, and then add half of that asset's width to the appropriate coordinate in order to get the location directly next to that asset. Then I would have to add half of the second asset's width to the coordinate to find the appropriate location to move the second asset to in order for both assets to be direclty next to each other. This was annoying, and by simply making an asset's listed location be from the corner means I only need to add the first asset's width to the coordinate to find the right location for the adjacent second asset.
This whole process was pretty annoying to me, but it taught me a good bit, and now I feel much more equipped to design a level using cartesian coordinates.
MATH SEGMENT: Functions (Logic) added Nov/3/2024
A somewhat tedious thing that I have described in the past is how I've layed out flowcharts that show off the logic for different parts of our game. I did this again this week, and found that creating the chain of events to give our players an in-game "job promotion" turned out to be more complicated than I initially expected. It seems like a lot of things turn out to be more nuanced than I think.
For this part of our game, I wanted the player to have the option to take the promotion when they chose, but I also didn't want it to seem like the in-game employers were desperate for the player's attention. I decided to write some NPC dialogue to make the job sound unwanted by anyone else, that way the player wouldn't feel too valueable, and allow the player the option to refuse the promotion, and come back to the NPC later to accept it when they want. I'm not sure how good this is, so perhaps I should rewrite it. I think it puts an unnecessary amount of attention around the promotion, but it might be okay. We'll have a better idea of what makes the most sense once we start implementing some of these ideas.
Allowing our player to refuse the promotion and accept it at their own leisure makes sense for a video game, but the consequences of this logic could end up creating something that gives off a completely unintended message to the player. Designing this part of the game should probably be dealt with with care.
I also came across another odd situiation while writing this promotion. I wanted a boss character to move to another area, but I thought that the NPC movements would be too complicated. So, I opted for the NPC to essentially teleport between levels when the player moved between in-game locations. However, I think the way I explained this in my design flowchart was not clear, and would do good to be revised. Instead of simply writing, "the boss NPC is removed form this location, and added to another location" on the flowchart, I left a vague note describing this, which was disconnected from the actual flowchart.
Leaving little notes convolutes the flowchart, and disguises the underlying logic. Intead, the flowchart could be improved by including a section that describes the NPC movement when it should happen. For example, it would be more clear to write something like "when the player reaches location X, the boss NPC is removed from level 1, and added to location Y in level 2." That way, our team's programmers actually know what to make of the design.
So there you have it, continually dealing with how the logic of our game affects the story as well as communication within our team.
Thanks for reading this post, and have a good one.
-Luke Knotts