June Month in Review coming in hot! This month was a blur, I am honestly surprised that it’s already time to do another one of these. Good work all around though, I’m excited to report on it!
So what did I get up to?
Coming in right from the last Month in Review, I was able to start working on, and verifying, my character controlling systems. I had a regular free “mover”, a “slide mover”, and a regular “grounder”. These are components that can work together, and transition between, to facilitate all sorts of movement behaviour. I was only able to lay the scaffolding by the end of last month, but this month it was the first thing to get going.
And guess what? I got it all working!
Some interesting details to share. This is a new revamped version of a character controller I hadn’t yet implemented in my Unity systems. The special detail of this is that the characters “capsule”, the thing that represents the characters body collider, doesn’t go all the way to the ground. Instead, it stops a little bit before, allowing a clearance for steps to slide underneath. That way as you go over the step, your character will realign with the ground up the step without striking the side face of the step and behave like there’s a brick wall infront of them. This is really nice for steps and angular levels, but has an incredibly valuable side effect: When you’re roughly putting a level together, and you place a ramp up against a second floor of a building to be able to go up. If your ramp has a tiny lip, or doesn’t quite make it exactly up to the level of the next floor, you can actually clear that sliver of collider. The unbelievable frustration of trying to make a test space and have your player character, and even worse your AI characters, completely halt at the top of your ramp is immeasurable.
Another really awesome detail of this feature is how I’ve been handling the “blending” of the momentum and turning. I was able to implement “Critically Dampened Springs”! I’ve known about these calculations for years because of the discovery of this VERY cool blog, “The Orange Duck”, written by one of the creators of Ubisoft’s Assassins Creed animation system. The walking through crowds, responding to walls and objects around as you freely move around the game animation system. He’s done so much cool work. It’s so incredible, but very heavily math oriented.
Bonus: Ubisoft Publications.
Using these springs, you can move from a starting point to a target destination with a really pleasing momentum that hangs for a bit as it starts, then increasingly speeding up before snapping smoothly into alignment with that final destination. This applies both to the position of the movement, and also the rotation to the heading direction. And they behave FAR better than the more commonly understood LERP and SLERP’s that are often taught to do similar things like this.
I ended up bringing together the various types of springs into a little utility library and can now utilize it all over my game systems. It’s so nice.
Moving forward, I thought I’d tackle the hardest feature I planned to work on in the near term.
The Dialogue System.
One of the philosophies I’ve taken unto myself has been that: “If you are hiding a characters hands in your illustrations because you’re bad at them, you should be drawing EVERY illustration with hands clearly visible, and infact used dynamically and in all sorts of poses.” That’s because it’s the most immediate void in your skillset and will hinder you until you overcome it.
This philosophy drove me to very seriously diagnose and stabilize the Awaken Guardian gameplay features last winter. It drove the quality of my work far higher, it brought me confidence in how I implemented the gameplay, and has given me a far deeper clarity on what I can do for this gameplay framework on O3DE. Those sorts of gains are incredibly valuable, and drive you quickly forward in a far more rounded way than avoidance.
I utterly failed.
Yeah. I spent a good while trying to make sense of example tools already present in the O3DE engine to get a window opening, add nodes to a graph… and well. Just do that first and we’ll see about making more complicated things.
It started working.
And then I was not able to get any further. Nothing I did after this made anything else appear or become available.
It was killing my morale, oversaturating me with unclear information, and was losing me a LOT of time. So I kicked the can down the road. I have a lot of features I need to be bringing around in tandem with this dialogue system, and it’d be better served to just get through those things while I remain so unsure of how to proceed with this editor window. It’s incredibly advanced, and has very little documentation to accomplish because so few people are actually that integrated into the game engine to be able to do that kind of work, let alone make tutorials on it to get a layperson able to accomplish the same things.
So on I went! Next feature, next feature!
I moved into a much needed feature. A Camera system! Phantom Cam is what I’m calling it. It’s a system that uses camera “phantoms”, entities that represent a camera, and through a priority filtering system designates a phantom that the real game camera will snap to a mimic it’s settings.
It’s very powerful to be able to create hundreds of various cameras, and have a system that’s constantly shifting and changing, blending, and updating targets and focus points to acommplish complex dyanmic and cinematic visual experiences. In some ways I’d say the camera is more the character than the character is.
So I’m off to work. Many of these features I’ve been slowly bringing aorund have actually had script based prototypes made the last time I was tackling O3DE work. However, due to the restrictions of the scripting, there were certain thigns I wasn’t ever able to do.
One of which was being able to set a far more complex blending index. Formerly I could only set blending to the destination, and set the linear time. Now I can set the blends between a start and destination camera, allowing more precise blends between clusters of cameras. Like a 1 second blend to the target cam from one camera, but a 4 second blend to the same target camera from a different camera. And along with that I was able to also add a list of blend types! Along with my springs utility I made a curves utility to collect a big juicy list of easing curves to make all sorts of blending effects between my cameras. Of course, like with my springs, I can now use these curves anywhere I want! So nice.
In the middle of this camera system work I decided I should waste my time.
So I ended up returning to a painful topic for me. Starting entities disabled, including their children, so that I can precisely control when certain gameplay elements become active in the game. This can be selection systems, like randomizers that activate 1 of 5 possible elements, or more systemic. Like being able to load in a level mostly disabled, and then through tiered activation, activate pieces before activating later pieces, onward and onward. This is used to assure certain things are already active before proceeding to doing other things, or to make sure that you’ve done certain stages of processing before other things, or to make sure you’re doing the processing WITHOUT certain things. It’s a control thing.
I ended up buggering around, drawing a lot of attention through my vocal struggling on Discord, and eventually was given a fork of O3DE with a legacy “Start Enabled” feature that was left dormant in the engine due to being incompatible with the entity-prefab system. I ended up making a massively contrived and sloppy prototype of being able to start inactive, along with all the children, and then reactivate things at a later time. It was so much effort and really proved out how this really needed an actual solution.
Thanks to my incessant failing, I drew more attention to it by a power user in the community and after some discussion on what exactly it is, they have a feature to accomplish this exact need on their docket. Infinitely thankful of them, definitely sorry for being such a pain, and frustrated that when it comes down to the boilerplate “in the guts of it” work around the engine I am completely outclassed… by a large margin. Surviving none the less!
So I returned to my comfort zone. Gameplay. Cameras. Phew.
I bring around all the various features I had mentioned above. Follow targets, look-at targets, powerful blending profiles, and smooth as sugar blending between cameras. It’s pretty good!
I have some fixups still to do, like the visual stutter you’ll see happening during the camera movement. Along with expanding to some of the most commonly used camera types, like an orbit camera that will swing around your character based on input.
But I decided to branch out to something I’ve had nagging at me for months.
C++ Tutorials.
If you’ve been following along for a while now you know that I occasionally contribute to the O3DE community by creating “Intensives”, long winded sloppy tutorials about doing things in the engine. As I’ve been entering the C++ world of the engine, and breaking through on logistical hurdles, I’ve been slowly stewing on how I can present those concepts to a new adopter. Lots of users like myself prefer written programming over visual programming, and want to do that when deciding to use O3DE for their projects. However there is a very steep difficulty for entry as there are specific things you need to do to get to the part of simply making components and programming random gameplay things. Like any C based language, once you get there you are likely to feel fine even if you’re unfamiliar with this particular form of C, but the logistics around starting can be prohibitive.
However. I am totally tooootally unqualified to talk about these things. It’s been a quandary for me as the information is good to get out there, but I also only have understanding enough about it to break through and focus on my gameplay feature development.
So I ended up finally breaking. O3DE recently released their next version 25.05, and got a new influx of users, drawn in by the endorsement of GameFromScratch.com on Youtube. This of course also brings a huge surge of users only loosely familiar with the engine, wanting all sorts of things, and to immediately do their desired thing in the engine. So, as you may understand, we started getting SO much demand for information on getting started with C++. Rightly so, and totally valid to want. But there is no “You know nothing, now by following my motions you can now program in O3DE like you’d expect to.”
Well I guess I can just bs my way through and show people how I managed to break through. So long as they end up on the other end, the service will have worked.
So I start on the tutorials. No wait.
Part of the need for tutorials is to not have to completely reinvent the wheel. So rather than use my exact setup, I spend an entire day trying to set up a working environment close to the expected defaults. Except I’m struggling so hard to get Visual Studio Community 2022 to make sense to me about what’s going on. So I fall back on my vscode set up I’ve been using since loosely thinking about starting so I poked around on some files in it, and now I’ve been developing on O3DE exclusively with vscode…
So I go with vscode… and it’s still complete madness to me. All the same things I have no idea about as VS2022. But in for a penny, in for a pound, so I keep on working out vscode things.
A really nice side effect is that now I’ve MASSIVELY improved my workflows, made things more automatic, created nice little utilities for myself, and got closer to the command of the engine that one needs from advanced IDE’s. I can build, run, debug, and get code hints with my projects, gems, and the engine. It’s a very nice improvement for myself… but WOW it was an information dump crammed over one day to get my understanding JUST clear enough to now regurgitate it to the masses. We’ll see how this goes…
The next day? 7 hours to make 4 hours and 45 minutes of tutorials.
This was so exceptionally intense for me. I don’t really preplan my tutorials in a “this is your script” kind of fashion. I have beats, but that’s about it. So I spent well.. like 5 hours improvising and working through incredibly complex topics trying to work out the full process from “you don’t know how to do C++ programming with O3DE”, to “now you can basically do anything from here!”.
I somehow did it. And only with SOME mistakes/unclear topics.
Based on my foray into setting up vscode, I put together a 2 hour long setup video. Wowee.
Then, following that, I started actually making sense of O3DE in a C++ context, including the logistical things.
First Gems. The things that hold everything the engine has.
Then Components. The things you use for almost everything, in order to impart specific functionality onto an entity. A very common pattern for game dev engines. Entity-Component systems.
Then lastly, I focused on Events. A very large part of how the engine runs. Using EBusses to communicate between entities and components without needing to make an explicit connection between the two. This is meant to decouple features and allow them, with the Gems system, to easily be toggled on and off as desired.
Okay I paid my dues. Right?
Sorta… I did make some mistakes I want to correct, power users gave feedback on incomplete information about things.. and before I posted the tutorials I had to watch all 5 hours of tutorials to add chapters to the vids. A pretty neccessary job that I’d put off in all my former tutorials. But with the complexity of the topics I thought it necessary to put forth the effort.
But wow, after all this I am VERY done with doing presentations.
I really should do those final corrections in a followup… I’ll see where I can fit it in.
So onto the final development of the month!
Exciting news! I have JUST begun working with a recent graduate student from NAIT, a local Technical College with a range of game development programs, and a highly engaged game development club. We just started on-boarding this week, and I look forward to the work we’ll be able to do!
It’s a wholly new process for me to onboard someone to such a complex project, with so many variables you could never expect anyone to alreay know ahead of time… like using O3DE engine, but I am happy to be patient, and get them up to speed and tackling tasks in no time.
I’ll also be on-boarding a colleague that’s been working on adjacent projects into the Framework development too! I am excited to see all the work we’ll be able to do in tandem, building towards us making small use-case game projects using the toolset we’re developing!
Wish us luck!
In Conclusion
Lots has been going on, lots of progress, features and learning is happening all the time steadily. I have no intentions to stop here and will be happy to continue to knock down the foundational systems for the many features that will be included in the framework.
All of the work is being pointed towards making the minimum viable features to go after a small project I am targeting for the near term. It’ll be a powerful use-case test, help steer the most critical functionalities we need to satisfy the projects development, gives us a creative outlet in the face of such continuously technical work, and lastly, gives us a first project to point towards as proof of the frameworks capacity to produce quality games.
A little longer to go, but stay tuned for that!
Thanks for reading! Here’s to another month!
Join our Discord Server!
Want the most out of Genome Studios?
