Hello everyone! New month means new Month in Review!
Continuing right off from last month…
I have been coaching a new team member through onboarding! Working with other people on the day to day has been a wildly different experience than my normal state of working: In isolation for 15 years. Of course, with it comes new kinds of work habits. Conveyance of information is a massive one. I can hold quite a lot of my plans in mind, with some light documentation to make sure I don’t forget small details. But now we find ourselves with people that aren’t my mind, and therefore have absolutely no idea what I’m doing, and what’s going on. I have the context of my many years of work in Unity, the context of all my business plans ongoing, and in the past, and the context of the work we’re going to be doing right away here. It’s quite a lot, too much to all pass on, which means I need to find my way of giving ENOUGH insight, without mega overshooting it with an abundance of excess knowledge.
Yay communication!
While a bit tangential, this stoked me to take some effort into filling in the large library of product documentation for the GS_Play toolset. I had been quite diligent at first, because it gave me breaks between wracking my mind around the programming side of things in O3DE. Of course, once I started getting more familiar with it, I started breezing by from feature to feature with little aggregation of the info around it. Well… now I’ve got to do entire days of it instead… GOOD, but holy… They remain in flux as we continue to work and flesh things out. Both in the work itself, but also in how we plan to format and communicate the features in the documentation. I have a pretty okay starting format, but I’m sure there are a thousand ways to improve it. A very cool eventual study, and something that will feed back into making better documentation in general, which is cool.
Back to it.
Finally, I broke back into some actual programming work. I returned to the Camera system, it was definitely not even close to finished where I left off.
I fixed an issue that came from blending while in the middle of blending, thanks to spamming camera changes like a maniac. Now, no matter the position of the camera, if a blend kicks in, it’ll just shift to the next target. Far more stable. I expanded some of the features already in place, like adding a “relative offset” toggle to determine if the offset should be relative to the tracked object or adhere to the static cardinal directions. The relative is largely the useful one, but you never know what a developer needs.
I then began working out an “orbit cam”, before I process inputs and move the orbit by command, I wanted to just get the basic structure in place. The “Static Orbit Camera” is the format I used for Del Lago Layover, so I definitely wanted to have it in some form. The way I created the orbit cam was pretty cool as it calculates it’s offset and orbits together, meaning one doesn’t have to make a lever out of game objects to set a pivot, and orbit, and then reference the two pieces and spin and pivot them to create the orbit functionality. Now it’s all handled under the hood. You set your angles, you set your orbit position, and you’ll have the camera where it should be, easy.
Next, I tackled a very necessary fix to the camera system, converting to Physics based tracking movement to prevent stuttering. When you’re using a physics system, it has an entire simulation space separate to the basic 3D environment. This is due to having all sorts of optimizations and underlying functionality necessary for realtime physics simulation. This has a side-effect however, where you can’t reliably position something in the 3D environment to match an object in the physics environment. The physics space updates through physics ticks, while the 3D space updates with frame by frame ticks. This makes instances where the frame tick fires before a physics step and now the character is in one place, while the camera is tracking a position it is no longer at. With the changes I made the cameras now move like butter. Primo.
Next is… eww… more people things?
Did some more onboarding, now with my other colleague. At this point I’m actively working alongside people now… It’s a bizarre feeling. Other people? I’ve never heard of them. As a nice kickstart, we tackled a bunch of small systemic needs that I’d been putting off due to tedium. Renaming repositories, propagating those changes to dependent features… it was such a fuss. But! I didn’t have to do it, yaaay!
This instigated a very deep need to start actually gathering ideas, tasks, and knowledge together in a detailed enough way for other people (there’s that term again) to actually work them out.
Right round, back to communication.
This involved a massive organization of work tasks on Jira. The removal of vague, ambiguous tasks from aeons ago. Creating Task projects for all subsets of the company’s work, migrating tons of tasks between the various projects to clear out all the scattered info about projects into their own domain. Filling in details to dozens of tasks that only had a title, assigning tasks to people, claiming tasks myself… This is all a very good reason why Producers exist. Actually making productivity software bring out productivity is an art in and of itself… along with hounding people to get quality work done, ahaha.
Finally on to new work!
With that done… well… handled as much as I could stomach without a change of focus, I stepped into the Interaction system. Creating targeting, triggers, and interact input.
This time actually focusing on working out the product documentation as I worked, instead of abandoning it for months. Tee hee.
This stage of the feature involved building out a ton of scaffolding and leaving it there to be filled in later. As I may have mentioned at another time, the GS_Play framework is meant to be made out of intuitive patterns for various features, with the ability to extend those structures into all sorts of iterations of content/features to meet your development needs.
A great example is the very simple structure of Trigger Actions and World Triggers. The Actions are like nerve endings. They read, react, and respond to various things going on in the world, like an interaction, and then fire off a trigger. The World Triggers are the other side of the system, they simply receive a trigger call and do the triggering that they are built to do. They evaluate the conditions for success and succeed or fail regardless of the action calling it. This leaves the developers to be able to create a massive library of both. Nerve endings that can react to anything the game can do, and drive changes in the world that can do anything the game is capable of doing or needing done. Love it. And I will be building plenty of them in the coming iterations of our toolset.
On to… Communication… again… but this time different!
Moving on, one of the last broad needs necessary to begin looking at actual game projects is the Dialogue System. Dialogue handles so much information dissemination, from investigating arbitrary objects and environmental things, to managing dialogue through cutscenes, and of course, using the back and forth between the player and the character they’re conversing with to unearth details and story about the world.
This one is a very hard task however, doing roughly implemented dialogue ends up VERY messy, incredibly tedious, and massively inefficient. Ideally, you should have a nice editor to just link dialogue from one to the next. Simple in use, deeply deeply complicated to implement.
We broke the ice on this matter with manually identifying the data structure that could host the proper information for the dialogue sequencer to feasibly work, including all the messy extra bits, like changing character avatars, and using conditions to determine which dialogue to play or which options are available to select. As a mock, I actually wrote out the data by hand to capture what gets stored where, what the values of the various pieces would be, and the way we would link between dialogue nodes. Holy cow, it was tedious. Like, as a last ditch pivot for building out a project I could definitely do it, but it took forever. With all that, though, it read well. As far as we could discern, it was realistic enough and gave us some confidence to try and satisfy creating that same data in a far more user friendly way, which meant… now we need the rest of everything to follow it.
Let’s just say, it’s been a mess to try and figure out. There are not many experienced developers that are knowledgeable in GUI and more deeply, node-graph based systems in the O3DE community remaining. This has rendered us needing to read the code of the currently existing node graph editors and see if we can reverse engineer the information we’re reading to figure out how to create a foundation that we can then expand with our unique needs for this dialogue system. It’s been a horror show. I tried what I could. I mentioned as much in last months Review. But, I have colleagues to foist- I mean, designate work onto now! (Reporting from the end of the month: we’re much more confident that making the GUI is possible! Excellent.)
One way or another, we gotta get something done soon. No more kicking the can down the road. Fingers crossed. Having even a rudimentary system will be great for building out simple games.
And so, back to procrastinating, I mean documentation.
A lot of this month has been heavily administrative. Super productive on the matter, I’m getting better at it as well, but definitely a different world of work. I dove back into doing more product documentation, project planning and task organization. Collecting ideas and outlining plans in our internal documentation.. It was a lot of work. I can’t say I love it, but I also love when I finish a new wave of order and clarification and I feel it all makes a lot more sense. The details actually describe the task and why I raised it in the first place. They show what I would do to satisfy the task, and include any links and resources related to it. All really good habits to reinforce.
Wrapping up this Month
Wrapping up the month, our new colleague got to break out of pure onboarding and finally got some real deal features implemented, and even pulled together the product documentation for it as well! Getting a good foundation set with him, I look forward to being able to work more with him and get some more good work in!
During all this work, I had also spent the month designing and implementing a Discord Server Rework for the O3DE community. It was slow, and incremental, but coming together and will be implemented in the community server some time next month.
Speaking of O3DE, I got my very first component added to the public source code! I’m officially an open source developer! It’s a component for the in-game UI system that recursively steps through an elements children and toggles their interactivity on and off. This enables the developer a much easier means of isolating UI windows with one action, than to manage every child element and manually enable and disable them. I use it, now others can use it!
And lastly. Some big moves!
I’m breaking out into a game project! Starting this next month, we enter a very rapid production cycle. It’s going to be quite an experience, but I hope to capture the flow that came from developing Del Lago, and put a bit more structure to it.
Lots will be needed from GS_Play, systemically, but what we develop will be driven by the actual demands of a project with targeted gameplay and experience. Something very necessary when creating a product meant to satsfy the needs of a game production.
I outlined nearly the whole game, broke down as many things into a list of their individual components, articulated every possible trajectory of progression, and how the game will play from start to finish.
I made a slew of tasks, condensed them into their target stage of development, and laid out a timeline… a very tight timeline… to work through the stages of production from conceptualization to product release.
We aim for 3 months, expect 5 months, and will struggle for 6. Who knows how that will all play out in reality, but at least it’s a digestible scale and, thanks to already outlining the majority of it, we can worry about only scaling down from where we’re at. No scope creep, only scope shaving. Lots more on the project to come, stay tuned.
In order to hit the ground running I’ve already started the concept art for the town. Interesting enough, I have already thought about the game content so much, the conceptualization wasn’t about imagining the possible scene, but rather depicting the model I had in my head into reality. It’s pretty well exact. I’m very happy to be able to have that already at hand. It will make a lot of the work moving forward very concrete instead of ambiguous. All the core buildings are placed correctly and work out in visual space, the interiors of the buildings make sense, have space to navigate a character through, and feel fleshed out enough to be “realistic” (not blank/sparse, but lived in).
LOOK AT IT!
LOOK AT IT!
In Conclusion
We’re getting a lot done, setting our targets on some fun new prospects, shoring up, and improving our workflows and knowledge, and striving to build up our GS_Play toolset to meet the demand. This month has been a great kick-off to a new era of work, and I really hope for some solid Months to come.
Thanks as always for coming along for the ride. We’ve definitely got some great stuff on the horizon to report on in the coming months.
Here’s to one more month!
Join our Discord Server!
Want the most out of Genome Studios?
