Work Blog - JeffR
Mid-Holidays Workblog Update
Hey guys, hope your Christmas was good, and you're all ramping up for the new year!
The original hopeful projection for 4.0's release was the new year(ish) but real life being real life, some delays on stuff crept in, so we're a bit behind schedule. That said, hopefully we can have a lock on things for January. To show were we're at, I wanted to do this mid-holidays update!
PBR
For PBR, we're basically down to a few Quality of Life improvements, and fixing a blending issue when probes overlap. Once those are in, we can slice 'er up and PR the whole kaboodle, so that's pretty exciting!
Custom Shader Features
I have one bug I'm aware of that needs squashing with this, then a cleanup pass and it should be ready to PR in.
BaseGame Template
Ahead of rolling this guy in as the main(and in the near future, only) template there was some cleanup and bugfixing to do. I've been doing a polish-up pass on it to correct some UI design flaws, fix up some problems with the default UI module, and correct a few bugs with the editors that crept in, namely it not always properly toggling between them properly. This is coming along pretty smoothly and should be ready to be PR'd soon and then we can make BaseGame the primary template. Removing the Full template will come a bit later, once we have the new Project Manager's initial implementation rolling so people don't have to puzzle out how to work with setup/modules unless they really want to get into the nitty-gritty.
For a view at the more refined BaseGame's main menu I'm angling for, here's a screencap:
Could potentially bring it back to a flat color, but I'm not positive. Lemme know what you guys think!
Component-ification of Game Classes
This is getting there. A few of them are already done and working, like Static shapes, and I've been grinding at the Player class, as that's kinda the "big" one. Once that's done, the other big one is vehicles and the remainder are fairly simple after that.
Project Manager
So, I've yapped about a new Project Manager in some past posts, but we didn't have a concrete plan for how to go about it. We've been having a good bit of discussions in the discord(feel free to drop in and get in on that) about how to approach some aspects, like grabbing modules or Rapid Prototype Kits, which has led to some ideas.
So I sat down(well, stood) in front of a big ol' whiteboard I have and drafted out some UI design notions for layout and function/structure for the new PM. It'll run off a cut down version of T3D for simplicity(instead of needing to juggle a completely separate app structure).
Here's the whiteboard, for reference:
(There's some other bits in there, mainly relating to Scene object logic, which is coming along well too but I'll get to that)
So I figure that it will by default have 2 tabs: Community and Torque3D. More tabs could be added for purposes of integration of T2D or whatever else, but that's the main starting point.
Community(for the first release) will mainly just be a link hub to quickly be able to launch to a number of webpages and the like, but in the future I'm figuring it'll pull feed/updates for various showcase/blogs, updates and the like and display it directly in the PM so people can keep an eye on things and connect back to the community much more easily.
Torque3D is where the Project Management actually happens. Main starter column would have the Projects, Engine Builds, Modules and RPK options.
Projects would open up another column with the various Projects you have created so you can launch the game, the editors, shows the file path, etc or you can spool up a new project.
Engine Builds is where the different builds go. It'll let you pull down builds(and eventually, just be able to manage different repo/branches in a clean way) and keep the different projects and binaries organized through that. Being able to keep tabs on what version of the engine is what lets us grab copies of the vanilla binaries so you don't always need to compile the engine just to start a project up(leaving source access for when you need it, as opposed to a mandatory step to getting on with prototyping or testing something) as well as offering options like us being able to draft Update scripts to update projects to new builds of the engine.
Modules would basically be various standalone Modules and asset packages pulled down from repos or eventually the Store in an easily managed way, which makes it easier to share them among projects
RPK(Rapid Prototype Kits) are similar to modules, but are more 'meta modules' in concept. I've talked about RPKs before, but the idea is a sort of package that implements a gameplay idea or starter kit so you can easily kitbash out the prototype phase of your project to get onto the meat of the development. I want a bunch of RPKs to let people quickly prototype stuff out(which ties back to wanting to shift away from compiling being a mandatory first step for most people using the engine as well with the engine builds having binaries) so I want RPK's to get a lot of attention. This one would let you see what RPKs you have and able to grab new ones, etc similar to modules.
I also want the process to spool up a new project to be more streamlined as well. With having the vanilla binaries on-hand when you grab an engine build, when you create a project it'll have the option of being a source or binary build at create time(and it can be turned into a source build later, of course). If you go with binary, it just sets up the project structure, copies the template files and binaries and you can get cracking on prototyping stuff.
If you do source build, it'll do commandline execution to run cmake for you in the background(with options to activate different things like AFX or whatnot, same as building with cmake gui now) and generate the source project so you can build it and start implementing source-side changes.
I figure if you have modules or RPKs that have C++ assets, it can just inform you 'hey to use these, this project needs to be a source project' so keep the flow simple as well.
For existing projects, there'll be the Legacy Project Importer which you can see bits of at the top. I've been prototyping the general behavior of this for a while now and I've finally got an idea of how to approach it from the UI side. It's pretty simple, honestly.
You set up your project, like normal in the PM, then run the legacy importer. From there, you add modules, and for each module, you go through the different asset type tabs: shapes, animations, datablocks, scripts, etc and add files to the list for each.
You can do a single module or break them up in different ones to organize it more.
I figure that you can save the import configuration and come back to/modify it whenever.
Once you're happy with it, you run it and it runs the asset import logic + any additional script behavior to convert old assets. Update hardcoded path references to use asset references where appropriate, etc.
The end result is a module or several modules already deposited into your project's data/ directory with all the selected and categorized old content from the old build of the project converted to assets and good to go.
Figure we could even have an option to store the modules into the main Project Manager module list for reuse in other projects if you want just to make things as smooth as possible
So yeah, the PM should turn into quite a powerhouse for managing your projects, modules and assets. And when we can more better integrate it into online repos, github and eventually the store, no one should be lacking for easily accessable resources to make their development experience as smooth as butter.
Scene object
The most basic behavior on this is good to go, just have to ensure it integrates into the editor(s) cleanly.
I thiiiiiink that was all the major stuff. I plan on crunching a good bit more on all this over the new year weekend and then on into January so we can pull all this together and get 4.0 a release candidate and start on the bug chasing phase and plotting the next versions
Have a great New Years guys!
-Jeff
Hey guys, hope your Christmas was good, and you're all ramping up for the new year!
The original hopeful projection for 4.0's release was the new year(ish) but real life being real life, some delays on stuff crept in, so we're a bit behind schedule. That said, hopefully we can have a lock on things for January. To show were we're at, I wanted to do this mid-holidays update!
PBR
For PBR, we're basically down to a few Quality of Life improvements, and fixing a blending issue when probes overlap. Once those are in, we can slice 'er up and PR the whole kaboodle, so that's pretty exciting!
Custom Shader Features
I have one bug I'm aware of that needs squashing with this, then a cleanup pass and it should be ready to PR in.
BaseGame Template
Ahead of rolling this guy in as the main(and in the near future, only) template there was some cleanup and bugfixing to do. I've been doing a polish-up pass on it to correct some UI design flaws, fix up some problems with the default UI module, and correct a few bugs with the editors that crept in, namely it not always properly toggling between them properly. This is coming along pretty smoothly and should be ready to be PR'd soon and then we can make BaseGame the primary template. Removing the Full template will come a bit later, once we have the new Project Manager's initial implementation rolling so people don't have to puzzle out how to work with setup/modules unless they really want to get into the nitty-gritty.
For a view at the more refined BaseGame's main menu I'm angling for, here's a screencap:
Could potentially bring it back to a flat color, but I'm not positive. Lemme know what you guys think!
Component-ification of Game Classes
This is getting there. A few of them are already done and working, like Static shapes, and I've been grinding at the Player class, as that's kinda the "big" one. Once that's done, the other big one is vehicles and the remainder are fairly simple after that.
Project Manager
So, I've yapped about a new Project Manager in some past posts, but we didn't have a concrete plan for how to go about it. We've been having a good bit of discussions in the discord(feel free to drop in and get in on that) about how to approach some aspects, like grabbing modules or Rapid Prototype Kits, which has led to some ideas.
So I sat down(well, stood) in front of a big ol' whiteboard I have and drafted out some UI design notions for layout and function/structure for the new PM. It'll run off a cut down version of T3D for simplicity(instead of needing to juggle a completely separate app structure).
Here's the whiteboard, for reference:
(There's some other bits in there, mainly relating to Scene object logic, which is coming along well too but I'll get to that)
So I figure that it will by default have 2 tabs: Community and Torque3D. More tabs could be added for purposes of integration of T2D or whatever else, but that's the main starting point.
Community(for the first release) will mainly just be a link hub to quickly be able to launch to a number of webpages and the like, but in the future I'm figuring it'll pull feed/updates for various showcase/blogs, updates and the like and display it directly in the PM so people can keep an eye on things and connect back to the community much more easily.
Torque3D is where the Project Management actually happens. Main starter column would have the Projects, Engine Builds, Modules and RPK options.
Projects would open up another column with the various Projects you have created so you can launch the game, the editors, shows the file path, etc or you can spool up a new project.
Engine Builds is where the different builds go. It'll let you pull down builds(and eventually, just be able to manage different repo/branches in a clean way) and keep the different projects and binaries organized through that. Being able to keep tabs on what version of the engine is what lets us grab copies of the vanilla binaries so you don't always need to compile the engine just to start a project up(leaving source access for when you need it, as opposed to a mandatory step to getting on with prototyping or testing something) as well as offering options like us being able to draft Update scripts to update projects to new builds of the engine.
Modules would basically be various standalone Modules and asset packages pulled down from repos or eventually the Store in an easily managed way, which makes it easier to share them among projects
RPK(Rapid Prototype Kits) are similar to modules, but are more 'meta modules' in concept. I've talked about RPKs before, but the idea is a sort of package that implements a gameplay idea or starter kit so you can easily kitbash out the prototype phase of your project to get onto the meat of the development. I want a bunch of RPKs to let people quickly prototype stuff out(which ties back to wanting to shift away from compiling being a mandatory first step for most people using the engine as well with the engine builds having binaries) so I want RPK's to get a lot of attention. This one would let you see what RPKs you have and able to grab new ones, etc similar to modules.
I also want the process to spool up a new project to be more streamlined as well. With having the vanilla binaries on-hand when you grab an engine build, when you create a project it'll have the option of being a source or binary build at create time(and it can be turned into a source build later, of course). If you go with binary, it just sets up the project structure, copies the template files and binaries and you can get cracking on prototyping stuff.
If you do source build, it'll do commandline execution to run cmake for you in the background(with options to activate different things like AFX or whatnot, same as building with cmake gui now) and generate the source project so you can build it and start implementing source-side changes.
I figure if you have modules or RPKs that have C++ assets, it can just inform you 'hey to use these, this project needs to be a source project' so keep the flow simple as well.
For existing projects, there'll be the Legacy Project Importer which you can see bits of at the top. I've been prototyping the general behavior of this for a while now and I've finally got an idea of how to approach it from the UI side. It's pretty simple, honestly.
You set up your project, like normal in the PM, then run the legacy importer. From there, you add modules, and for each module, you go through the different asset type tabs: shapes, animations, datablocks, scripts, etc and add files to the list for each.
You can do a single module or break them up in different ones to organize it more.
I figure that you can save the import configuration and come back to/modify it whenever.
Once you're happy with it, you run it and it runs the asset import logic + any additional script behavior to convert old assets. Update hardcoded path references to use asset references where appropriate, etc.
The end result is a module or several modules already deposited into your project's data/ directory with all the selected and categorized old content from the old build of the project converted to assets and good to go.
Figure we could even have an option to store the modules into the main Project Manager module list for reuse in other projects if you want just to make things as smooth as possible
So yeah, the PM should turn into quite a powerhouse for managing your projects, modules and assets. And when we can more better integrate it into online repos, github and eventually the store, no one should be lacking for easily accessable resources to make their development experience as smooth as butter.
Scene object
The most basic behavior on this is good to go, just have to ensure it integrates into the editor(s) cleanly.
I thiiiiiink that was all the major stuff. I plan on crunching a good bit more on all this over the new year weekend and then on into January so we can pull all this together and get 4.0 a release candidate and start on the bug chasing phase and plotting the next versions
Have a great New Years guys!
-Jeff
About the player Class, users could script their own characters, but a ready to use multi purpose character class is a good idea.
I see the project manager to create, open delete projects, while rapid prototype kits would be existing projects template the project manager copies to create a new project.
Is modules some sort of plugins ? they should not be managed from the project manager but inside an open project, for example import some zip containing modules, or do you mean editor modules like new additions to the editor ?
About old version projects sometimes it's better to break compatibility when changes are big like V4.0.
That's progressing well for 4.0.
I see the project manager to create, open delete projects, while rapid prototype kits would be existing projects template the project manager copies to create a new project.
Is modules some sort of plugins ? they should not be managed from the project manager but inside an open project, for example import some zip containing modules, or do you mean editor modules like new additions to the editor ?
About old version projects sometimes it's better to break compatibility when changes are big like V4.0.
That's progressing well for 4.0.
Rapid Prototype Kits would be heavier examples of modules, which are indeed plugins. May or may not include source files for additional classes expanding the codebase, but for now all modules have been prototyped as additional scripts and assets run in addition to the core rendering/loading loop that would be the main project. Hence the PM so folks can tick a few boxes for what all they would want to include. as an example from above: it'd probably be best to have the scene-as-main-menu done as a module and a bog standard flat gui alternative, so folks can pick a starting sample to use there. (or default to flat and override via module with the heftier scene-based one.)I see the project manager to create, open delete projects, while rapid prototype kits would be existing projects template the project manager copies to create a new project.
Is modules some sort of plugins ? they should not be managed from the project manager but inside an open project, for example import some zip containing modules, or do you mean editor modules like new additions to the editor ?
Basically rather than having a very genre-specific 'full template', you'd have a core+FPS RPK+Vehicle RPK.
Yep, this is absolutely the plan. End goal is to completely component-ify the existing game classes(Player, WheeledVehicle, Item, etc) to act as a jump off point people can really easily permute to be it's own thing, but still be a already existing and already working example case.About the player Class, users could script their own characters, but a ready to use multi purpose character class is a good idea.
Will Torque 4 have a new launcher ? let us create, import or remove projects.
Like this
https://www.youtube.com/watch?v=oPCGyvihTsE
The old interface with play , replay, join or gui editor does not make sense a lot about projects.
Like this
https://www.youtube.com/watch?v=oPCGyvihTsE
The old interface with play , replay, join or gui editor does not make sense a lot about projects.
@ Razer
That's the entire idea behind the talk about the new Project Manager, yes. Give a nice centralized launcher for project management and the like.
For the second bit, the default UI stuff is intended as a solid launch-off point. Obviously if there are any interface elements that don't work for your project, you'd just edit those
That's the entire idea behind the talk about the new Project Manager, yes. Give a nice centralized launcher for project management and the like.
For the second bit, the default UI stuff is intended as a solid launch-off point. Obviously if there are any interface elements that don't work for your project, you'd just edit those
Who is online
Users browsing this forum: Bing [Bot] and 4 guests
