WorkBlog - July 2020, Part 1

This is for workblog posts from DEVGRU, though would mainly be from JeffR.
Update threads would cover what development and news is going on with the active development of the engine.
4 posts Page 1 of 1
JeffR
DEVGRU
Posts: 956
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Jul 30, 2020 6:43 am
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 dicussion 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:

Image
Image
Image
Image
Image

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:

Image
Image

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
Duion
Posts: 1622
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Thu Jul 30, 2020 12:46 pm
Finally the broken options menu gets fixed, now I understand all the redesign of it, to make it gamepad friendly, like it is common in modern games now, I never considered this.
The problem now is, that Torque is not really made to release on consoles, so you will have a console ready GUI, but cannot release on console. Console ready GUI are often worse than PC friendly ones, so you are optimizing for a customer group that does not exist and cannot exist currently.

No idea what to make of that, but overall you should not bother with making GUIs, rather get the engine released. Making GUIs is simple, it just takes a few days to make them and many people already made GUIs, so if you want a better one you can just ask them if you can use their version or if someone wants to contribute their options menu etc.

Nils for example already has a working options menu like he showed here: viewtopic.php?f=8&t=1860&sid=4c3e25ffc1 ... 000#p13513 and I also have one, but not that console friendly.
So instead of bothering for months with making GUIs, just take someone elses work and slap it in, spend a few hours changing colors and scale, add a few console friendly buttons and call it done and move to the next task.

This mentality of reinventing the wheel every time leads us to nothing getting done for years now. At least it looks nice now, the previous designs were quite bad.

Let me tell you things from my perspective, the only feature I really will use and will benefit from in the next release is the physically based rendering, which may improve my graphics, however it comes with a huge cost of upgrading everything already. Almost all the other features are kind of useless to me and probably also to many others, yes they are supposed to make development easier, but they have not even been field tested if they make it easier for real. Even after a final release it will take a lot of people using it for real and testing it for months and years until those features finally make things easier. Most people that use Torque now are experienced people and they will not bother with the UI of the engine much, I for example do most things directly in notepad instead of using the engines UI features.

So I for example for now would only benefits from the PBR, everything else I will use only because I'm forced to use it, because you intentionally broke all backwards compatibility, so much that I don't really know if I will ever manage to port my game to the new version, because I would have to rewrite most of the game code again from scratch. All those new features probably only benefit people in the long run, in the short run, they just break everything.

This is just my perspective, but for further development I would suggest to get together with all people that have released or develop a game and ask them what they think about it or what they need, so you get a direct feedback, since those people are what you/we are developing the engine for, not for imaginary new customers or people that do not develop anything.

I can tell you from experience, do not listen to average people, rather ask an expert on things, otherwise you end up just building golden handlebars, which may look good, but take a long time to build and do not help anyone for real.
Nils
Posts: 211
Joined: Thu Feb 05, 2015 3:32 am
by Nils » Thu Jul 30, 2020 1:21 pm
Thank you for the update @ JeffR, and all who keep on working on this very hard to get it all up and running. Understand it takes much of your precious time but still keep on providing for the T3D community. Looking forward to see the 4.0 final release anytime soon. Again, thanks!
Steve_Yorkshire
Posts: 342
Joined: Tue Feb 03, 2015 10:30 pm
 
by Steve_Yorkshire » Thu Jul 30, 2020 3:24 pm
it has a decent amount of comments in the code already(and will get more as we go) explaining how stuff works
Hurray for code comments! Can't have enough code comments! :mrgreen:
4 posts Page 1 of 1

Who is online

Users browsing this forum: No registered users and 0 guests