Posted December 08, 2024 by Kirijo
Hello fellow gamers and game makers,
it is I, Abby as usual.
So far in the campaign, I have gotten to the point where there is no longer just one wolf in the scene but two. The things that I have decided need to be taught before “multiple wolves” are as such: zooming in/out, doing actions, seeing the effects of doing actions, and being introduced to the “suspicion” value. Things that are taught after two wolves are in the scene: creature selection via the crucible, puzzle solving, resting, different animal stats, animal relationships with one another, clan dynamics and leadership structure.
For example, below is how the game first looks when you start and are zoomed out. The box at the top of the screen is telling you that “Mr. Chuckles is getting hungry!” The bottom of the screen is intentionally covered by fog, that will fade later as the player’s camera angle zooms out and more of the map is visible and playable.
Scrolling in results in the next image, where the player is zoomed, in the screen is progressively covered by a vignette on the sides, the creature info panel is shown on the left, currently only allowing the food creature info to be accessible outside the basic information. I have clicked on Mr. Chuckles since zooming in and encountered the action selection menu, and have opened a submenu of the action selection menu, the “needs” sub buttons that include eat, rest, and be healed. I only have the one action, “eat,” available among all menus and sub menus, because really that’s what the player needs to learn how to do first. As the game progresses, I allow more and more things to be clicked on. I’m learning that TBC's tutorial is about establishing expectations and purposefully granting different levels of control to the player so that they are, instead of overwhelmed, intrigued to continue.
(Abby again) I am excited to announce that on my desktop, TBC runs at around 70-80 fps and on my macbook, it runs at 40 fps. These maybe aren’t the best numbers in the world, but they are a galaxy of a difference in comparison to TBC’s FPS before the widget optimization pass. Briefly the widget optimization pass has been: my friend Krayno trying to figure out what is taking up so many draw calls. Then him learning more and more about UE5 and determining that it is the user interface layer of UE5, the widgets and the HUD, that are taking up most of the draw call. Why is this, you(I) may wonder? Well apparently, there should only be one widget in your game, as each widget has its own canvas layer. Each canvas layer that interacts with the HUD takes another draw call, and then the GPU gets bogged down more. I, as the intellectual I am, thought that it would be comprehensible and organized to have each user interface element as its own widget, so that I could store code that interacts with such interface element on the widget itself. I have learned that maybe this would be a fine (not good) programming pattern if I were, maybe say, outside UE5. But UE5 does not want a bajillion widgets inside one another. It wants everything on one widget, and then a class that I’ve called the UIManager to handle the logic and access the canvas externally and handle logic. So I’ve been refactoring code a bit while playing Wizard101. Kray said it would take maybe four months to fix it but after a few weeks like, I think honestly it’s looking pretty good? I think he ball-parked that number without realizing the amount of time I’ve spend dicking around in UE5 (~5 years at this point???), but maybe his assumption was based on the fact that I didn’t know about the canvas widget draw call shenanigans. I guess I do tend to go into stuff head on and worry about issues until later (and NOW is later). This is great for making prototypes, but definitely not great for anything bigger that other people are also working on. So lesson learned, and FPS gained!
Anyway, thank you all for reading, see you next month! :)