Whaaaat? It’s already been a month?! Hoboy. Let’s see what we got into this month. This is Gaian, and let me spin you a yarn I don’t yet even know. We can discover what has been going on at Genome Studios together!
Thankfully it was a nice medly of things. What’s sweetness without a touch of bitter, amiright?
We started the month off fairly standard. After I write out all the progress stuff into a month in review, the next day is an onslaught of everything else we haven’t done or fixed yet. As it goes.
I wanted to continue tackling details for the “We Don’t Go Into The Forest” project. Little fussy things were cropping up and just really needed to be nailed down. My track camera was not snapping like the base cameras were already made to. Turns out I just didn’t apply the same logic to the override.
Additionally, a bunch of collider things were just not working as desired. When you try to teleport a character, or anything with physics attached, you have to remove that thing from the simulation by doing a bunch of disabling, then at your new teleport destination, you re-enable all that stuff back. However, this was causing issues with collision fields, where if you left and returned while always in a collider (the global ones spanning the entire level), you’d not get the global setting re-applied to the character. Something that happens because if you’re swapping between levels, you don’t want previous settings stuck to your character, so you dump it all, knowing you’ll teleport into a bunch of new fields and regain all the settings. Well, not always.
As a “decent enough” fix, I created “global” component versions of the fields so that there’s at least one blanket setting available, and you’ll never lose track of it because it’s just there to be read from. Problems ‘mostly’ solved.
Then we entered into some of the hard stuff…
To preface all of this: I am neither a graphics programmer, nor a tech-artist. I celebrate and am grateful for what those skillsets contribute to excellent games… and being able to make games at all. But I have no idea. Like close to none. I know shaders and render passes are part of it… and that there are two kinds of shaders “original” and “compute”. And I’m probably mostly wrong in all of that.
I digress!
So we decided to start looking into building our own O3DE Render Pass to create some post-processing effects that are not currently present in the engine by default. Spearheading this goal is our poor, poor colleague Alex. Who will be forced to suffer this decision all month.
What a choice…
To start, we were trying to lay out the bare bones to just gather what we need to even begin making anything from the render passes. How naive we were. There is definitely a distinct stage of realization even a blank set of classes and shaders need to be, to even be picked up by the engine, ideally without also crashing every time.
We did not meet that need. Thankfully, the crashing part had not yet begun. Everything else, though. None of it worked, none of it was succeeding in getting processed by the asset processor… none of it was able to make proper reference to other pieces, or the rendering systems at all.
So, we began to try and make sense of any of this.
For now. Moving on!
Throughout this month, I’ve been responsible for some contracting work. Whaat? Making money from your professional career and skillset? Nooo… that’s not how this works…
And yet, I found myself actually being compensated for work, and relied on for my skillset and how it contributes to a project. Unheard of..
Steadily, bit by bit, it has been all going by well. Very, very agile and adaptive, we didn’t have much time to work on these projects. Both for the budget, and in lead up to some pitching opportunities coming in hot.
Next on the making games for Genome Studios docket, I just wanted to start dotting the project with environments and the level transitions between. It’s nice to have a feel for a “whole world” while you’re brainstorming details for any given space. This, of course, shook loose ever more mistakes and issues. Truly, at this stage in my career it doesn’t even phase me; it’s actually exciting because you know that when you knock those down, you’ll have an even more finely tuned and capable system. It’s a really cool feeling.
This month has been a Launch month for a new version of O3DE. So we’ve been busy supporting the community and the launch of that as well. Shauna is managing the docs team for O3DE and has been working diligently to match the documentation release to all the engine release needs and scheduling. Many many thanks to her, as there are far fewer documentation managers than any other field… cuz most people don’t care about documentation as much as doing the game making, and engine programming stuff.
Thankfully for me, I got to just breeze on by and observe the hive as all the work in delivering a properly stabilized and complete engine was being orchestrated and handled by the many people responsible. Many thanks to them as well for tirelessly working out the details of everything involved. It’s not the prettiest job, but it’s one we absolutely need and, like always, was done masterfully.
Then came a demanding but fantastic shakeup to the regular routine.
Alberta Game Series!
An annual conference that hops between Edmonton and Calgary, Alberta’s two metropolitan cities, and offers two days of intimate learning and connection. There are speakers from all over the world covering all sorts of topics involved in their field of expertise. All about video games and the video game industry. You’re there all day, getting catered to for breakfast, lunch, and dinner. There’s a networking after party between the two conference days. It’s a very cool experience. Talking to people top in their fields and careers over a beer, right there in person. Asking questions, getting really cool insights… It’s a very, very cool experience.
There was also a pitch contest with 5 attendees, one of whom was my contracting colleague. It was really cool to see him really play the presentation with charm, and a lot of adaptation to not having the right version of the presentation loaded at the time. Yeesh. The gameplay clips and hype material in the pitch was the game work I had done, so cool! And then it was also really stunning to see my face in the “This is my competent and capable team” slide… Me? Competent? AND Capable? No, you must mean someone else… that has my exact photo for a face… Really rewarding to see, and to have experienced collaborating, leading up to the pitch presentation.
One of the major topics that set the tone of the conference was: The State of the Industry. A grim topic that has been very hard to navigate for all of us. As in, ALLL of everyone in the entire global games industry. Everyone.
Resilience, adaptation, and optimism were regularly spoken about as, really, that’s all we’ve got in such a new and uncertain environment.
There are things to know and trust. Despite the massacre of jobs, despite the very difficult terms by which you can access a large market success with your titles, the industry is still the highest-grossing entertainment industry over all other media combined. This is proof that the demand for games has not waned at all; really, it’s the means by which you access those funds and make contact with the markets that provide that income.
How to move forward and generate revenue from game projects, right now, is the difficult one. The climate of the commercial side of game development has drastically changed. The ways of delivering a product to an audience has grown far more complex than in the past, as well.
What the magic recipe is for success is the part that nobody knows anymore. It used to be “Get it all the way to market.” was enough of a filter to assure you actually had a place at the table. Now it’s a bare necessity. “Just get a publisher” was another angle that would often be the make-or-break of your project or company. However, now, any investor, be it Publisher or Venture, essentially wants a sure thing before they’ll even consider you. Ironically, the risk of investment is now not on the investors to shoulder. Instead, you need to create a massive success with no money in order to get the funding to make a massive success. It’s madness.
But. It does set the stage for something. If you’re supposed to make a massive success out of nothing before anyone will give you any credence. There’s the opportunity to simply not accept anyone after the fact. You needed them then, but now you’ve got your champion. They are now the ones begging you for a piece of the pie.
That’s not to say, “never get investment”, but rather, when you’re the one making a success, you’re no longer the one desperate for investment, you’re the one with the golden goose, and so you can posture yourself VERY differently during negotiations. Something I highly advise, as the reason investors can treat us so poorly is because we let them. It’s hardly a thing we can do alone, but the more people realize we’re the keepers of the keys and they would have nothing to invest in if we didn’t let them, the more we can reclaim the positioning to be risked on earlier in our stages of project realization.
It’s an uphill battle, but one I seek to pursue myself. Maybe then, we game studios can inter-invest, loft more developers and studios, and stimulate far better project and studio outcomes than alone.
Totally double, triple, depleted, but back at the regular grind again
I had made some very cool discoveries on how the O3DE system creates its game entities. (Really, all entities, but I digress) It loads a base of data relative to the entities; this is ephemeral but serves as the templates for the eventually created elements. After the data has been loaded, you then instantiate a new, unique, entity by cloning the data that this entity is supposed to become. It does some finessing to hook up all the, now unique, pieces, then gets ready to load it into the engine environment. At this point, it initializes them, then activates them.
I used this to make the first mock of a loading screen, complete with progress bar!
In doing this, however, I realized I kinda had the final pieces of understanding to return to a topic I just haven’t been able to let go of. “Start Active” and its Inactive counterpart. This is a feature that is not fully implemented in the O3DE engine (really not at all), and something I have wanted to solve for nearly my entire time working with O3DE.
So I was stirred now to see if I could outline a total plan to introduce the entire feature to the engine source code. There were some less-than-ideal workaround ways to do it, but the clean and clear version was to actually build it into the engine. And quite surprisingly, the plan came together, and, to my cursory review, all made sense. Those kinds of moments are staggering, where you think it’s going to be this vexing thing with insurmountable issues that you’re ignorant to, and are glossing over, only to see that, overall, it makes pretty straightforward sense.
This led to, and made obvious sense to continue into, plotting out a plan for improving the other side of loading: Asynchronous Spawning. This would break up the data loading, cloning, and initialization steps that happen BEFORE the Start Inactive takes place, and would break it out over time to both soften the framerate hike that happens from a massive spawn request, and allow for incremental progress reporting: An absolute necessity for loading bars!
It was a lot of planning and trying to frame the features, but I feel it was my best attempt yet to outline it in a way that’s actually feasible.
So about that Rendering Pass…
Just.. augh.. More struggling, more blind attempts to make things work. We found out that you needed to “require” a rendering “service” in order to properly connect to the system at all. Something that was coming up null endlessly, despite copying other render pass systems word-for-word.
So it turns out that: When you declare a required component in your custom component, the engine actually assures that that component is activated before yours. This assures that the component is there for your use when you begin to run your dependent component. This is particularly necessary for System Components (global components that govern from above). Originally, I had understood it as: Just make sure that an entity with this component also has the required component added, too. Which it is! But isn’t the entire picture. That was deeply revealing.
BUT RENDERIIIING -shakes fist-
We were finally getting things to connect, and register, and exist correctly, but never all together, and never in a way that wouldn’t crash the editor every time. Or, just cause massive errors every frame in an alarming, screaming messaging spam. So, physically and mentally crashing out, basically. Sorry Editor…
Let’s get back to happy things!
I had some space to get back to the game-making part. Something that has been growing increasingly difficult this month.
This time? Starting to introduce Jorje, our protagonist and first mock of the GS_Play Paper Performer system. It’s a system I was developing quite deeply for “Some People’s Kids” based games in Unity, and something I definitely didn’t want to drop, moving away from that engine. Things aren’t quite as easy in O3DE to support the various needs of this system. One of which, that utterly kills me, is that you can’t flip an entity by making its x-axis “-1”. While it’s a common staple for a very simplified form of rotating a character left and right, it doesn’t exist. So I spent quite a bit of time trying to get the paper performer to spin 180, and correct all its layering to not show, an effectively “inside out” version of Jorje when looking left.
After some fussing, it’s worked out well! I have Jorje built out of body parts assembled into a core performer, something that allows swapping things in and out; I have the bones offsetting very gently to order themselves properly in both directions; and I’ve done it in a controlled fashion! In some cases, I actually improved how I’m handling things compared to the original, which is always very rewarding.
This gives me the very base foundation of the Paper Performer, and now, simply means I need to slowly expand the features as the needs arise.
Fun things aside. Render Passes… RENDER PASSES
No, no more. We are going to shelve that and do ‘anything’ else. Wanna make things pretty? There’s plenty of post-processing that already exists; shut up and do that.
Awesome, but I wasted all of Alex’s time on the rendering stuff.
Argh. Renderiiiiing! -shakes fist-
But, Alex managed to do some poking around, and it should be pretty fun to actually get into working with it when he’s back on. There’s one thing O3DE doesn’t lack, and it’s render system potency, so as long as we play with the training wheels on, I think it’ll turn out pretty solid anyways.
Here was where all the annoying frustrating time consuming stuff that culminated in the working Paper Puppet mentioned above happened.
… So… then I moved on and started tackling some more client work!
This particular one was really cool, because I had laid the foundations for plans of a game, but it was pretty bland and empty. This time, with some “let’s try and make what we have fun” targets, I could try to flesh out more of an experience, rather than the base things necessary to make anything happen the way we had hoped for.
This rapid prototyping is a very interesting process. It’s a rapid exercise in targeting meaningful additions, reducing them to as small an addition as possible, and trying to flow with only doing so much, while capturing more in the sum of the parts. Working so rapidly and tightly, and then actually delivering what I’d say as an experience where you can see some fun and strategy to it, including things like ui and other forms of feedback necessary to ground you in the mechanics, was incredibly rewarding. It’s validating to see that my capacity for larger projects and larger systems has not locked me into only being able to do slow, gradual, large-scale work. I can be very agile, see the valuable points, and build it within tight constraints, and actually touch on the only thing that matters to me, which is the foundation of Genome Studios: The actual experience. The ephemeral, hard-to-define, feeling that the game gives you with its systems and content. Super cool.
Afterwards, I was up all night thinking…
With my newfound freedom to return to my work, I was caught on something. I was tossing and turning, spinning on the same thing for hours. That “Start Active” stuff can’t possibly work like you thought… There must be some totally missing chunk that means I’m totally naive and incapable of doing it, right?
I couldn’t find it. It all seemed doable.
So I was finally stoked to do something about it. One of the major contributors to the Engine, Nick, has been expressing that he literally has more work than he could ever realistically do. It’s both a clarion call for contributors but also a warning. Although I’ve ideated the needs of the feature with him many times in the past, I can not sit and wait for him to do it for me. So I have to do it myself if I truly believe it’s something that needs to be added to the engine.
So I started at it. I had poked around the source code in previous attempts to prove that it’s possible at all. Mostly hacking the things and utterly destroying the vast majority of the engine’s functionality.. But still proving things!
This time, I was taking this very seriously. I would take the smallest increments of features necessary to prove out a single action of the required features and ensure that it works. That way, I can assure things are stable, and that, with every addition of features, the stability would remain, yet prove out the combination of features together.
And it started happening.
I first got hierarchical activation and deactivation. A need when you want to disable a complex entity made out of many pieces, instead of a single piece with everything running on it. (Before, the piece would deactivate but the children would remain, untouched.)
It worked!
So then, I would then introduce doing that exact same functionality, but at start, assuring that the thing never activates before you make it start inactive.
And it worked!
One last thing, and I’d say ‘this’ was the unexpected and unknown detail I did not plan for, was to make sure that when you set a new parent to an entity, that that gets recorded and handled correctly by changing its activation by whatever the parent is, preserving the hierarchy even when things are shuffled around.
It wasn’t pretty, but it worked! It all worked.
No way, am I a game engine programmer? An actual Engineer? This has been a detail that has bewildered me. Never in a thousand years would I have thought that I’d be able to research the details of some of the most fundamental pieces of a game engine, and not only understand it, but be able to alter it in a way that can actually work?!
This marks a momentous stride in my capacity as a game developer.
It’s a level of expertise that I want to have as well, because the O3DE community needs more people who are as intimately familiar with the engine as the vets who made it. Nick needs to not have a list so big on his plate that he’ll never be able to finish it.
And hopefully with this effort, it’ll be one thing on his list that can be removed without him doing everything about it, start to finish… And it is on his list… and needs to be marked off… desperately.
But as I had said, I’m messing with the most foundational piece of the engine: The Entities.
And that is no casual initiative. Something that I have taken very seriously, but also has appeared a bit blasé with my prototyping, and rapidly messing with everything in that system. This has finally stoked a lot of attention from the many vets who have been responsible for the engine thus far. It’s serious, serious business.
But this has initiated the most significant part of this effort, which is to have outside input from intimately experienced devs, who not only know a lot about the engine but have been involved in its creation and use in production for many years.
This broke out into some really valuable discussion and ideation on how to FAR BETTER handle what I’m doing, in order to make it something good enough to work in harmony with the engine as it already stands.
And I’ve already got the first stage implemented and working!
I’m very, very excited for the next little while as we eke out definitive and precise strides towards making what I’ve prototyped into a cohesive and complementary system that will be available to every O3DE developer forevermore.
While it may be closer related to O3DE directly, it’s a feature that has been majorly needed for some of my most fundamental systems in the GS_Play framework. Even though I ‘just’ haven’t been able to work on the game project directly, which is getting annoying, I am directly improving GS_Play and enabling those very features for We Don’t, to realize a far more performant game by release!
In Conclusion
The immediate forecast will be to chip away at this engine stuff while also chipping away at the game project. I think they are both valuable trajectories. I hope, with far fewer demands of me next month, that I’ll be able to really get into the guts of it all and start putting out some cool progress pics of the game taking form.
While chaotic, I think this month has been a very gainful one and will mark a very interesting stride in Genome work, as well as the future of the O3DE Engine.
As always, thanks so much for your attention throughout this review. I hope you can be as excited as I am about how all this work is developing for Genome Studios.
Here’s to one more month!
Have a good one.
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!