Hey boys and girls!

After an... unintended hiatus from workblogs, I got off my butt and kicked things back off. Now, as you can see, with a separated forum for easier organization and allowing discussion to not over-shadow literally everything else.

So, what's been happening since the last workblog? Whole bunches of stuff, naturally.

I just took a peruse through the repo(which you may recall from the community refresharoo thread, is now over at https://github.com/TorqueGameEngines/Torque3D and counted it up and we've had 124 commits since the last workblog.

What all has that covered? Well, lets have a look, shall we?

BaseGame

The BaseGame template is cruising along quite nicely. With the help and feedback of peeps in the discord, it's got a much more legible, consistent and stable look and feel. Here's a few pictures to show how it's looking now:

As we can see, a nice, clean look with a modern, unoffensive dark theme. A great launch-off point for customizing into your project's special UI.

It has a fleshed out options menu, a litany of default preference options, as well as the keybind menus for both keyboard and mouse, as well as gamepad.

Even the level select page is module-friendly. It automatically scans for any LevelAssets and auto-populates into the listing.

Also from a usability standpoint, it not only supports button presses via the MenuInputButtons at the bottom, but they also work with gamepad inputs, detect the last input type and refresh the UI to show the input-specific images on said buttons(supports keyboard + mouse, xbox, switch and ps4 controller button prompts)

The logic for the menuInputButtons will also later be expanded to be able to be used on other UIs like the playGUI so you can show the correct input prompt during gameplay too.

Beyond the looks, overall behavior is much more stable and cleaner as a general example.

Not only does the general behavior of modules lend itself to extendability, but there's also logic with being able to better control queue and execution order of scripts, allowing modules to override script files. So if you don't want to use the BaseUI's MainMenuGUI, you can have your own module have a mainMenu file that overrides the BaseUI and creates a clean swapout replacement.

Specifically pertaining to it's looks the dark theme used was used as a general visibility/design testbed which can then be fed back into the dark theme for the editor, and the new Project Manager.

So lots of good stuff from that.

Oh, and another bit of usability that just recently went in from Tony was a slider to control the opacity of the console window. Because depending on what it's backdropped against, sometimes legibility can get pretty bad:

Plus, a lot of cleanup has been going on to de-tangle various guiProfiles so they make more sense, and there's less unused/unneeded/duplicate ones dangling around cluttering the place up.

Now, you may ask why put any effort into the BaseGame template if it's likely to see a lot of replacement of elements for any real project. Which is a good question, of course. I've mentioned it before, but I see the BaseGame template not only a launch-off point for projects, but also a general guide.

It provides a lot of common functionality, which lets people get on with actually working on their games, and it has a decent amount of comments in the code already(and will get more as we go) explaining how stuff works. This lets newer users see a working example without having to download 'ActuallyWorkingGUI' pack or the like.

Beyond that, establishing good habits for newer designers is a win for everyone. If the default options menu comes fully loaded with a bunch of performance preferences they don't have to fuss with, then that means nearly all games will have that then. Much better than most other engines' defaults which generally are nothing.

If the dev is lazy or not skilled enough to implement those kinds of things, that can lead to a bad general impression. A lack of performance options means that players have no recourse in improving how the game runs, which leads to a bad time. Inconsistent UI behavior, or gamepads support that doesn't work in the menus also leave a bad taste in the mouth.

All of which can come back and negatively impact on T3D.

So if the starting point new developers jump off from is concrete and more fleshed out, then that encourages a development direction towards that end-user experience, which ultimately reflects positively on the engine as well.

Plus, developers being able to know that if they slap 'New Project', they're getting a solid baseline project and UI they can just work on what makes their game their game, it saves a lot of time, and they can have assurance that it's solid(if needing customizing), which isn't a guarantee with a random pre-made UI pack on an asset store.

There's still some bits to polish and refine, of course. Ensuring the options menu buttons better indicate what page you're on, finishing filling out the tooltips/descriptions of options and keybinds, and documenting the crap out of the code for it all. But it's pretty solid at this point and the remaining kinks are getting hammered out quite nicely.

Tomorrow, I'll get into what's been up on the engine and tools side, and a look into the new Project Manager! Exciting!

Laters!

-JeffR