Hello again everyone, this is Gaian in the frigid wasteland of Edmonton reporting on yet another Month passed for Genome Studios! This month is a tangled mess of demands, and distractions, coming from all corners. We survived it, and are ready for the next!
Let’s get into it!
But actually no, not yet.
This past month it became clear to me that anyone at all actually reads these blog posts.
Yes, like human beings.
Eww… why? What a bunch of nerds.
Ahaha, joking aside, I am really happy to have all y’all along for the ride. These sorts of business updates are always good to make to just signal you’re around and still at it, but to actually know people read them is really cool.
Thanks so much for coming along for the journey. It really is something…
Okay, meta aside, on to the actual Month in Review you came here for!
We started this month real slow. Winter is finally starting to sink in and it’s a pervasive force.
I began by trying to head off this Entity Activation community work I started last month. It’s for direct GS gains, but also a pressure to do work that’s not related directly to GS’s game project experience development.
Regardless, I began doing benchmarking to identify the additional loads of checking for active state and processing the results. Created a 100, 1000, 10000 entity prefab to spawn and despawn, and track that for timing. Found additional load, but it was marginal.
One thing that was proving to be an issue was that the Transform Component, as it stood, was really problematic. Circumventing it involved a LOT of shoddy hard-coded workarounds, and really, the entire Hierarchy tracking system I’d worked on to actually handle activation and deactivation was also an entire workaround from what would be native to the transform system: Being able to request the entire parent-child hierarchy. Which is only available when active…
Meanwhile, we’ve returned to working out Graph Canvas work. A colleague from the community had made some exciting breakthroughs on getting “anything” to happen. We immediately grilled them for everything we could glean, and now our teammate Shauna is going after it once more. This has been a gruelling experience spread over months of attempts and failures. First contact was back in June, and it’s serving to still be more cryptic than usable. This has been killing us.
I also had the chance to introduce our other teammate, Alex, to the camera system. We’ve been barreling forward so much, trying to break into all the tech and systems we’ve yet to make that I haven’t actually gotten anyone on the team used to actually USING GS_Play. It worked out well, and Alex went along to chip away at some level blocking work, setting up PostProcessing, Camera shots and when they take over, setting up materials and things. It was great that the tools were simple enough to pick up right away, and I look forward to us getting him more up to speed.
I then jumped back into trying to finalize this Entity Activation System work.
It kept nagging at me that it was so close to being finished and proven out that I just couldn’t let it go. I definitely do not like things like that hovering over my head for any longer than necessary. I also just… kinda took offence at the state of the Transform component and how it was interacting with game development as a whole. There’s been long-standing issues of objects getting offset every time you activate and reactivate, and reading the code, it was because the entire thing was needlessly destroying all its hierarchy and connected state when it was falling dormant. Like all of it was just completely against the systems it was meant to provide.
So I finally decided to dig into that piece. I’ve been feeling like the amateur going through really critical and core pieces and pretending like I know what is going on. But after reading it over and over and working around it over and over, I just couldn’t shake that I was pretty clear on what it was doing and where those issues were happening. I couldn’t possibly be able to understand and implement Entity work AND Transform work, though…
But I went after it anyways. And immediately, everything I was writing was perfectly fine, and played out exactly as I had spent nights envisioning. I moved the start and stop logic to initialize and destroy, making the Transform essentially stay active all the time, despite the Activate and Deactivate state of the entity firing. This preserves the ability for Transform things to happen even while inactive, the source of a lot of the hierarchy destruction. I made the parent changing and the events around tracking the parent non-destructive, and because the Transforms are listening all the time, they could properly respond to anything and everything that was going on, regardless of being active.
Lastly, I just made the more destructive behaviour come when the parent entity is being destroyed. Usually, it means the child will destroy right away after, but in cases where it doesn’t, it safely disconnects fully, as it was doing all the time for everything deactivated. Which was no good.
Well jeez.
With this working in that improved way, I didn’t need to track any hierarchy. I didn’t need to process or evaluate active states pretty well at all in any external systems. The Transforms already know each other and their hierarchy, they’re already keeping tabs on their parents and reacting accordingly… If I just make them handle their own “my parent is inactive, so I am too”, then my ENTIRE parent activation system could be torn down and just connect a few threads to make this all concrete.
And it worked out splendidly. The hierarchy tracking was having some stability issues, the overhead was identifiable, but now? The whole thing worked exactly the same; there were absolutely no issues with the hierarchy, the overhead was gone, and when I started running new benchmarks? Absolutely indistinguishable measurements. This was the final key to the entire system. It worked, was reliable, was the least destructive I could have made the system, and affected the engine in a way that essentially had no impact.
It also brought out industry-standard expected behaviour from the activation stuff itself, but also in the “always-active” nature of the Transform component, allowing ongoing ability to access and manage the entity hierarchy, regardless of active state. Hell yeah. 100% primo.
In the following day, I got the green light from my colleague Nick from the O3DE community, and it was one of the most rewarding experiences I’ve had thus far in my Open Source making career.
Super rewarding!
With that measure of my ability I, like I was mentioning last month, felt I was breaching into being the most evolved in programming I have ever been. By like, a large measure. Never would I have anticipated that I could read through others’ code, within a very complicated and advanced software, understand it, and apply new work and changes to it. Not only understand, but thoroughly know it to the point of seeing it in its entirety and knowing where the limits were and how it was hitting certain walls. All a really incredible feeling.
This, however, got me feeling a lot like I could actually take some of the reins of the engine development into my own hands. I’m no longer a naive developer poking at the extents of the engine and trying not to rock the boat too hard, but still provoke some improvements and fixes relating to Genome work. I am now someone who can parse through this game engine, make sense of it, and actually plan out or apply, direct changes, fixes, and work all my own.
This feeling of responsibility really started to put a heavy pressure on me, though. Now I wasn’t just Genome Studios waddling along working with O3DE, I was simultaneously responsible for leading and developing this game engine to assure its future is strong and bright. Managing the community began to take on new weight and purpose, as I started to envision how each person and each issue or idea arising would be a significant impact in the engine if we can just nudge these community members to start taking initiative as well.
All this pressure began to really erode me.
Even time off was feeling this imposing panic of not working hard enough to further the engine, so I could make bubbles of time to focus on Genome Studios’ work during my working hours. This was becoming vastly unsustainable. I was getting VERY stressed out, strung out all evening, all weekend… Basically, a perpetual panic.
In truth, I needed to let go of that responsibility and pressure; just because my relationship to the technology has evolved doesn’t mean I suddenly have to be captain of the ship. Although a lot has changed, so little has changed as well, and it’s so easy to get caught up in that overwhelming feeling and think that it is the new way things are going to go from here on out.
All easier said than done; but identifying it’s an issue, and that it’s not an absolute truth, brings it to the forefront and helps you stop yourself when you’re reacting to the impositions from that new point of view unnecessarily.
Getting back to the work.
Over one of the weekends, for some random side fun, I had wanted to poke around at a “Component Creator” tool that was loosely mocked up quite a while ago.
Unbeknownst to me it was actually merged into the dev branch and already available. It was a good start, but over my time making projects, I have identified a lot of component formats that it was not able to make. Sure, a nice ground floor component is great to have, but there are some semi-complicated ones that are pretty fast to set up when you know their needs, but requires research and solving if you do not.
Part of what the community is trying to do with the engine is reduce the learning curves necessary to just get started in basic ways with the many systems. Making C++ components being a massively difficult one. The components are easy, but the initial prop-up is very complicated, and not necessarily needed, when just starting to make little features and functionality for game experiments.
I actually started to breach into some cool system and patterns with the tool to actually accommodate the more complex component types. I got the system to create a “Staging” environment, allowing you to create the files, but then edit, or remove them before actually putting them into the project directory.
I made it able to scan your project gems and let you create components to any custom gem, and even target specific build targets. All things that have to do with handling gems, but now by default, able to just happen in an automated fashion in “good enough” ways. If you know better, and are doing custom things, you can certainly shift how it processes, and then also do things manually afterwards, which you already have to do currently from scratch anyways.
You can also dynamically make custom value fields based on more complex needs for certain types. They only come up on selecting that type. Super cool.
I thought from there I could push it up as a new concept, provoke some brainstorming and feedback, and maybe let it move forward on its own. But then I got some alarmed reception and feedback. Rightly so, I was making big sweeping changes; it was in a raw state, and it was massively new across the board.
Well, there I went.
I didn’t want to be upsetting and not offer a resolution to the concerns. I was taking over and making sweeping changes. I really should back it up. That’s the responsibility of someone actually working towards furthering the engine’s accessibility. And the pressure began to ramp.
Certainly, I can say that these experiments get intriguing and fun. My mind is just racing about what changes and fixes I’d do, and how it’ll come together to be a measurable improvement, and allow anyone the ease of being able to just pump out components automatically. Truthfully, I also wanted that level of ease myself.
Well, what turned into an evening and weekend thing became a sliver in me that just had me reeling to get wrapped up and over so I could move on.
I don’t like to use LLM’s excessively and be unable to understand the output, but I was working with Python and UI elements that I am massively inexperienced in using. For a larf, after having a discussion with another colleague about better programming solutions to Chat GPT, I experimented on this class creation wizard using Claude. I piped in the file and asked it to do the big pieces that came up in the feedback; make it class-driven, make it use PySide UI system.
Boom, it pumped out this cleaned up, reorganized, and class-based version of the wizard. It was astonishingly accurate to what was there, but now far more tidy than my very messy earlier work. I open it up, chuckling to myself about how there’s no way the program would be able to run being fully processed by Gen AI. Nope. It opened up, and the ui was brilliant. Obviously from PySide, but all the entries were consistent, the window was properly sized, the log viewport was correctly sized… Wow.
It’s no silver bullet, just like any Gen AI, but it was a great leap into the tool, the work being based on things I was wholly ignorant to. Well, now I REALLY wanted to get this thing finalized and through the gates.
The remaining work, though, was all the complicated, hard-to-discern stuff. It was definitely work I had to clearly identify and curate through the rest of the project, not relying on AI. But steadily, I got every piece working far more to the level it needs to be as a baseline.
The UI remained consistent, despite some big changes that came from dynamic entry elements that come from the various component types.
The targeting and processing of projects, gems, files, etc, were very difficult to pin down. There were so many subtle factors at hand that made it fairly hard to do. I am in no way a programmer familiar with file and text parsing, which this whole job was.
But steady as she goes, I brought together something I’d be very happy to use.
A class wizard that you can open from the engine or your IDE, it has Basic, Level, System, and UI components. It can generate data assets, a feature I feel is absolutely necessary for anyone making games. The entire thing can be selectively targeted to any project and build package you want. And has steps where, if you don’t have a major infrastructure piece for the class type, it will create it and add it to the project, but if you already have it, it will simply register the new entry to the one that already exists. So, so, nice. Spares so many steps of setup each time you make a new component, and spares the headache of missing one piece of the puzzle, and having inexplicable issues crop up.
I left it off at that. Unfortunately, I opted to use the fancy new PySide 6, which is unsupported by O3DE natively. So the only way to use the wizard right now is to take the branch and install PySide 6 to your editor source code manually.
There’s work going on that will naturally require a Python upgrade that will also introduce this version of PySide, but I have to sit on my thumbs and wait for that before this wizard can go along.
All in all, those two community tasks ended up to be very reasonable efforts, but will yield incredibly large impacts in the future of the engine.
But, as you can see.. I started taking that work so seriously. It took up a large chunk of the month and had me feeling so much pressure not to mess it up or leave it incomplete. Thankfully, this one I slaked off quickly as my hands are tied on the PySide compatibility part of things. Gives a nice reason to step away from the responsibility to “get it through the gates at all costs”.
Ultimately, while I am really proud and happy with the results of this work, it’s drastically spun me out of sync with “just” Genome work. It’s added a lot of responsibility to my plate and really didn’t help me feel very accomplished, as so much GS stuff just hung there in stasis while I didn’t work on them. The guilt of being a finite person with only so much time and energy was coming from absolutely every angle; there was no winning… so I was doing a lot of losing instead…
Rolling on back to the “meanwhile at Genome Studios”.
Level edits were coming along. We were curating assets from the various asset packs I’ve gotten over the years. Been working at Terrain, but have run into an annoying detail with the heightmap, when you draw the image, you’re using full RGB black and white, but the heightmap only reads the red value, and for some reason we’re only getting 1/3 of the stranth of the drawn values.
Graph work has been chipping forward… It’s a massive system, and we have absolutely no one to ask for greater understanding of how to get a bare bones version to start working. It’s basically a “Build it in full or not at all,” which is brutal for us as we can’t solve one piece, and then move on to another piece and slowly work out details and functionality. It’s just prop up, and prop up, and prop up, while trying to find cutoff points where it can run at all in a partial way, while still not making very much sense as a whole for how we got there.
Graph and Rendering have been our absolute bane at Genome Studios. While most stuff has been able to be brute-forced, and we can get a few leads and make our way through, these pieces have been viciously contesting our every stride in trying to make sense of them. It’s a faint dream of ours to get through it in a way where we actually understand what’s going on, so that we can make tutorials about it and actually have the liberty to use the systems for our own ends. Seems to be a long march in this desert still…
So then I decided to have a crisis with my work, now that I’ve freed myself to get back into it.
Turns out, not using an activation system in the past 2 years of ever using O3DE, I hadn’t made much of any stopgaps with what happens when you activate and deactivate parts of my game systems. Well, surpriiise! I get to put out fires all throughout the GS_Play system.
Cameras can’t track a character that’s been deactivated and removed from the universe, and in order to react to that, the cameras, characters, and other things need to find out deactivation is happening and to act accordingly before running logic on a null and crashing the entire game… Joy.
Fires out. Finally, good, phew, what a relief.
But then the real crisis began. I had missed one particular test I didn’t think to do with the activation system. When I finally started stepping forward into the game systems I had finally unblocked by making active handling, Level Loading, things started to absolutely and completely collapse. Some serious, messed-up, things were happening, and I just couldn’t understand why.
My characters, and the puppets inside of them, were separating from each other and getting stuck on 0,0,0.
After a day of trying to make sense of this, the issue became clear.
In O3DE, when you make a prefab, there’s a wrapper around the prefab you made.
When you know there’s only 1 root entity, like with a unit, you usually set the wrapper to not spawn into existence. This gives you the common behaviour of: creating your prefab, and the element you get given IS the prefab itself. This setting is called “Editor Only”, basically meaning: “we understand it needs to exist to identify to the system that this is a prefab and not just some disparate entities, but when you run the game, just outright exclude it, we don’t care”.
Wellllllll…
Removing the wrapper, or really anything set to editor only, was happening as one of the first things running the game. This meant that the Transform components, now able to be used at all times, were STILL not quite ready yet. This meant that instead of just being a child of the place they were left, they would lose connection to their parent and become independent entities. This meant they were not following the positioning of their owning parent because they were ceasing to be a child of it entirely. So, in my project, my unit was being spawned, then teleported to the right spawn location, but its performer model was being taken out of it and left to be alone where it spawned.
Hoooly, this took another day of being gaslit by the engine to work out. Everything was working fine, but why was it not behaving normally? The new parent being set was actually the right parent; the Transform WAS being told the right parent for them… This was sooo difficult to make sense of. The stuff that “works right every step of the way but doesn’t end up working” is some of the roughest parts of development.
I finally found that the Transforms were getting their parent set before the Init(), but because the startup process of the Transform is to take their stored parent data and set their parent to it to begin, it was overwriting its newly set parent with the one that got removed automatically. Meaning it was parenting itself to “invalid entity,” which was making it do the destructive: “Your parent is gone, so just free yourself” logic; rightfully making it have no parent.
Ay ay ay…
So I needed to report that on the O3DE server, put it through its rounds, make sure that it’s stable again, etc, etc…
Thankfully, I got it all working and was able to fully create my StageManager’s level loading system! The game loads inactive, the level loader hooks in and decides what needs to happen to the game. In regular runtime, it will change to the main start level; in debug it’ll just load the level you’re currently editing and run the game from there.
Super rewarding to see that feature finally take shape despite being one of the first systems I’d made for the GS_Play tool set. One finally has very thorough control of the level loading; nothing will start active before you’re ready for it, and from there, you can begin making custom load stages to activate and bring in your game level in the right ways to work completely and reliably. I already started the lazy loader components for that.
A long payoff relative to a lot of my feature turnarounds, but certainly a well-earned one. While it creates doubt about immediately implementing the activation system into the public JUST yet, it’s already serving us really well, and I am fully confident that it will work 99% of the time. We just need to stay on top of it and catch anything falling through the cracks.
And now that things were cleared up, I can FINALLY branch off and do contracting work instead of GS_Play work!
Ahaha, it wasn’t actually that bad. Funny to struggle through a bunch and then have to shift focus. It was a good transition point anyways, and fixing bugs is just as valuable and productive as moving features forward. So I didn’t do nothing.
I have to say, doing this contract work in such a limited time frame and budgetary scale was really validating. I am reliably able to tackle development work and prototyping incredibly rapidly. I feel I can find realistic strides forward in how to best bring out the game experience, and my scoping to realize it has been quite accurate. In fact, for this recent round of contracting work, I hit the feature complete on the dot, like by the minute I was budgeted. It came together faster than I had anticipated; it worked exactly how I had envisioned it; and I like to believe it has really started to capture the interesting facets of the core experience we had brainstormed at the start of the project. Only took 3 days from starting the work to wrapping it up with all the new mechanics I’d proposed to build.
All that said and done, I was FINALLY very burnt out!
It was great, rapid work, tackled it well and precisely. But, with everything else I’ve done this month on top, the lack of letting myself off the hook for my community management involvement, alongside the community contribution work. Holy… Yup, I was still happy and excited for my accomplishments, but the toll had finally come due.
I haven’t been having full-blown burnouts so far this year, but definitely “no more gas in the tank” burnouts. It was nice to be at a closing point, did my commissioned work and did it well, cleared up the instability in my own work, but yeah, I did not want to think or do anything more about game dev that weekend whatsoever. Finally, it was time to recognize that I’ve been needlessly burdening myself, and this is the payment for taking responsibility where I didn’t need to. Time to correct course.
And while I was burning myself out?
Yussss….
Anything at all? Don’t mind if I do. We were finally seeing anything coming out of the Graph work. And more so, through actual, clear avenues of understanding. I’d say this was the kind of hello world we wanted. Anything at all to look at and go: “cool, let’s add to this now.”
I am very excited for us to start to suss out more reliable behaviour and make sense of it all. It’s something we really want to use ourselves, but we really want to make it something that others can also use. Graph handling is a great one for tool building across the board.
Getting there, one step at a time.
All this and we find ourselves in the last week of the month. Finally, winter has rolled in in a meaningful way. Edmonton has started to get snow, the temperatures are reliably below 0°c, and it’s getting so dark every day. Dark to rise, dark to sleep… It’s a gruelling experience. Tie that to my overexertion, and I had a very slow final week.
It wasn‘t for naught, but I also wasn’t blazing on forward by any measure.
I FINALLY got to work on feature development where I’d left off some time last month, and it was steady ahead. Took a lot to acclimatize to the work, as it’d been quite a spell since last I worked on it, but I started to make my stride by the middle of the week.
I started to deepen the dialogue system to provide the features I need to make in-world dialogue panes, and use the dialogue sequencer to target performers for dialogue and cinematic triggers.
Started with the markers to identify individual performers, then started working out the dialogue.
As a side effect, I was building out a more robust dialogue UI system in general. You can now independently register unique NPC, Player, and Dialogue Options UI’s, whether in the UI space or in the world space.
It was full speed ahead. I tackled each piece quickly, everything was rolling along until.. Using the EXACT same logic in the options select UI as the rest, it was not working at all. And like.. catastrophically not working.
Yet again, all the logic was fundamentally working. The dialogue speech bubbles were working fine, and in fact they were the ones COPYING the logic over, so the originator was failing to work?? This was maddening.
Diagnosed everything, made a million debug things, added a bunch of stopgaps… Nothing. Nothing worked. Getting everything running and working was the first half hour of the day; the entire rest of the day was this. Yet again, everything is working, but nothing is actually working…
It was my render image…
O3DE UI is its own legacy system. It handles its own rendering and management on its own. Because of that, when you want to have UI in the game world, you need to render the UI to a texture image and put it on a 3D plane in the game world.
One of the values in the image file however, is “IsUniqueName”. In my process of copying the assets of the Player Dialogue into the Selection and NPC dialogue render textures I missed setting that one thing.
Well, because of that, it was rendering the selection to the speech bubble texture, which at the point of having dialogue options, was not being updated and thus locked in place, and at a bizarre offset. Meanwhile, my selection material was never getting updated, and was then following my character perfectly fine, but as an invisible texture.
Holyyyyyy….
That was driving me crazy. Spending an entire day knowing your logic is sound, only to find you made a small mistake in a one-and-done setting is sooo aggravating.
But now I have in-world, robustly handled dialogue UI!
Now at the end of the month.
It’s nice to be back to the game-making part; awesome to start seeing game-facing visible things happening in our project; and I am excited to get back to it this coming month.
While all this work is hard, demanding, and can really impact the way you relate to it and your career, I find it to be endlessly compelling and always able to lead to more rewarding accomplishments. It’s a lifeblood for me, and while I may not get restored physically by it, I certainly feel nourished in my passion and career aspirations with every stride forward.
As always, thanks for reading along and watching the chaos and carnage unfold.
I will be excited to report on more this coming month! There’s always more to do!
Have yourself a good start to your winter, or I guess, summer on the other side of the world.
Till then!
P.S. Did you know you can keep up with our Month in Reviews by signing up for our newsletter? Just check below!
Want to keep track of all Genome Studios news?
Join our newsletter!