Just so I know, what's the situation with physics components? Anything been done in that direction yet?
Work Blog - JeffR
-
chriscalef
- Posts: 326
- Joined: Mon Feb 09, 2015 7:48 pm
@ JeffR: Wow. THANK YOU. Your hard work is very much appreciated down here in the trenches!
Just so I know, what's the situation with physics components? Anything been done in that direction yet?
Just so I know, what's the situation with physics components? Anything been done in that direction yet?
I haven't gotten super deep into it yet, but there's the Player physics component(that replicates the behavior of the current player object) and a beginning foray into a rigid body physics component.
From there, the plan is to expand and hit on the major checkboxes, including spring forces and the like for vehicle usage, maybe cloth, and i want a component for ragdolls as well you can flip on to make an animated mesh go all captain flopsy.
From there, the plan is to expand and hit on the major checkboxes, including spring forces and the like for vehicle usage, maybe cloth, and i want a component for ragdolls as well you can flip on to make an animated mesh go all captain flopsy.
Game Objects
What are Game Objects?
I'm sure most of you are familiar with prefabs. You take a selection of objects, convert to a prefab object, and you can quickly spawn copies of that selection of objects, move 'em around, and all that good stuff. This is good, but there are some limitations to this approach. For one, you can't do any modification to a prefab. You have to explode it out and edit it. If you want to retain that modified version, you have to save over the original prefab, or make a new one. You're not really supposed to 'do' things with prefabbed objects. You can, but it tends to lead to weird stuff if you start going around manipulating the child objects directly, etc. They're largely designed for mapping/level building, not gameplay stuffs.
That's where Game Objects come in.
Game objects broadly are similar to prefabs. You take an entity you've dolled up with components, maybe child objects mounted to it, etc, and go 'this is a setup I'd like to use multiple times'. Examples would be your player object, weapons, light switches with an associated light, etc, etc.
So how do we use it?
So what you do is take that entity, and convert it into a Game Object. This generates a GameObjectAsset, making it readily appear in the Asset Browser, but also makes it so you can very quickly spawn copies of that entity.
Another thing that happens when creating a GameObject is it has an associated script file. When the entity is made a game object, it is assigned the GameObject's namespace for it's class name, allowing the GameObject entity to have scripted behavior associated to it directly.
So lets use one of the example cases we listed off above - a player object.
We already created our entity, it's various components, and have them all configured the way we want it so it behaves like a player object. So we save it out as a Game Object: MyPlayer.
While we did up our various components, such as the mesh, collision, player physics, inventory, etc. There may be times where we want specific behavior/functionality for JUST this game object, and not a more broad general behavior that we'd put into a component. Or we have a bunch of systems that touch a lot of things and components, and feels too broad in scope for a component. Or you just prefer to code in a localized fashion rather than spreading everything out in a script component.
Any of those cases are a good reason to utilize the script file for the Game Object.
So lets say we want special behavior for our MyPlayer object, that would be distinct from other similar player objects, like AI. We can copy the game object asset, name that one MyAI so there's the distinction. The object is generally similar, still has the same components and configuration, but we can make the MyPlayer game object do stuff the MyAI GO can't, such as have inventory, or special concessions for players like a sneak system the AI don't need.
All this can, of course, be done in other ways, such as components, but the point is the system enables you to go about it in such a way that's the most flexible/comfortable to you. Personally I do a mix-n-match of scripted components and GameObject scripts.
You can also readily edit the GameObject entity, and any child objects it has right in the editor without needing to un-make the Game Object like you would a prefab. Spawn a Game Object that acts as a static shape, and change it's mesh and collision setting, and it'll only change for that instance. Spawn a light + switch combo and move the light child object into the position in the room you want, and so on.
It's not fully implemented yet, but I also plan to implement a system that compares an active Game Object to it's originating TAML file, so it'll track if a GO is 'dirty'. If you do one of the above cases, where you modify a Game Object in some way that makes it distinct from the original TAML file, it's considered 'dirty'. The editor will then have buttons in which you can either:
Save the current form as the Game Object, which is how you can quickly modify the GO.
Save the current form as a entirely new Game Object
Or Reset the game object back to how the TAML file describes it.
This should make editing fast and flexible. When saving, it'll also only save fields that are different from the TAML file, to keep data compact.
Another fun thing is that nothing stops you from having GameObjects in GameObjects. So you can quickly get some pretty fancy setups rolling while keeping things data-compact, and templated for easy modification across the board.
Example
Below is a video that goes over some examples of Game Objects and shows off how they can be pretty convenient to work with.
What are Game Objects?
I'm sure most of you are familiar with prefabs. You take a selection of objects, convert to a prefab object, and you can quickly spawn copies of that selection of objects, move 'em around, and all that good stuff. This is good, but there are some limitations to this approach. For one, you can't do any modification to a prefab. You have to explode it out and edit it. If you want to retain that modified version, you have to save over the original prefab, or make a new one. You're not really supposed to 'do' things with prefabbed objects. You can, but it tends to lead to weird stuff if you start going around manipulating the child objects directly, etc. They're largely designed for mapping/level building, not gameplay stuffs.
That's where Game Objects come in.
Game objects broadly are similar to prefabs. You take an entity you've dolled up with components, maybe child objects mounted to it, etc, and go 'this is a setup I'd like to use multiple times'. Examples would be your player object, weapons, light switches with an associated light, etc, etc.
So how do we use it?
So what you do is take that entity, and convert it into a Game Object. This generates a GameObjectAsset, making it readily appear in the Asset Browser, but also makes it so you can very quickly spawn copies of that entity.
Another thing that happens when creating a GameObject is it has an associated script file. When the entity is made a game object, it is assigned the GameObject's namespace for it's class name, allowing the GameObject entity to have scripted behavior associated to it directly.
So lets use one of the example cases we listed off above - a player object.
We already created our entity, it's various components, and have them all configured the way we want it so it behaves like a player object. So we save it out as a Game Object: MyPlayer.
While we did up our various components, such as the mesh, collision, player physics, inventory, etc. There may be times where we want specific behavior/functionality for JUST this game object, and not a more broad general behavior that we'd put into a component. Or we have a bunch of systems that touch a lot of things and components, and feels too broad in scope for a component. Or you just prefer to code in a localized fashion rather than spreading everything out in a script component.
Any of those cases are a good reason to utilize the script file for the Game Object.
So lets say we want special behavior for our MyPlayer object, that would be distinct from other similar player objects, like AI. We can copy the game object asset, name that one MyAI so there's the distinction. The object is generally similar, still has the same components and configuration, but we can make the MyPlayer game object do stuff the MyAI GO can't, such as have inventory, or special concessions for players like a sneak system the AI don't need.
All this can, of course, be done in other ways, such as components, but the point is the system enables you to go about it in such a way that's the most flexible/comfortable to you. Personally I do a mix-n-match of scripted components and GameObject scripts.
You can also readily edit the GameObject entity, and any child objects it has right in the editor without needing to un-make the Game Object like you would a prefab. Spawn a Game Object that acts as a static shape, and change it's mesh and collision setting, and it'll only change for that instance. Spawn a light + switch combo and move the light child object into the position in the room you want, and so on.
It's not fully implemented yet, but I also plan to implement a system that compares an active Game Object to it's originating TAML file, so it'll track if a GO is 'dirty'. If you do one of the above cases, where you modify a Game Object in some way that makes it distinct from the original TAML file, it's considered 'dirty'. The editor will then have buttons in which you can either:
Save the current form as the Game Object, which is how you can quickly modify the GO.
Save the current form as a entirely new Game Object
Or Reset the game object back to how the TAML file describes it.
This should make editing fast and flexible. When saving, it'll also only save fields that are different from the TAML file, to keep data compact.
Another fun thing is that nothing stops you from having GameObjects in GameObjects. So you can quickly get some pretty fancy setups rolling while keeping things data-compact, and templated for easy modification across the board.
Example
Below is a video that goes over some examples of Game Objects and shows off how they can be pretty convenient to work with.
Minor update.
Took a chunk of the weekend to cool off and play around with some fun bits. The end result was this:
Got my example dude working with some look animation action. It's subtle, but you can see him always turning to look in the direction the camera's facing, even as the rest of his body orients in the direction of movement.
This is a lot more natural compared to the normal third person fare of either the player always looking in the direction of movement, leaving other players wondering how you saw behind you, or locked to a rigid over the shoulder, forward/back/strafing view, which isn't really how people move about.
Also got the vertical look thrown in, because why wouldn't we, and a quick test that i did because I couldn't remember if I'd rigged in the prone keybind or not at the time, haha.
Incidentally, outside of one new math function i added that gets the signed angle between two vectors, which'll be PR'd in the near future, all that business was implemented with art and scripts.
It suffers a bit when it does a full 360 turnaround, because it's jumping from one extreme end of the animation to the other, so I need to correct that, but once it gets dialed in, I'll probably do a quickie tutorial and doing that sort of thing. Natural animations are a big deal, and I'm all for encouraging it
Took a chunk of the weekend to cool off and play around with some fun bits. The end result was this:
Got my example dude working with some look animation action. It's subtle, but you can see him always turning to look in the direction the camera's facing, even as the rest of his body orients in the direction of movement.
This is a lot more natural compared to the normal third person fare of either the player always looking in the direction of movement, leaving other players wondering how you saw behind you, or locked to a rigid over the shoulder, forward/back/strafing view, which isn't really how people move about.
Also got the vertical look thrown in, because why wouldn't we, and a quick test that i did because I couldn't remember if I'd rigged in the prone keybind or not at the time, haha.
Incidentally, outside of one new math function i added that gets the signed angle between two vectors, which'll be PR'd in the near future, all that business was implemented with art and scripts.
It suffers a bit when it does a full 360 turnaround, because it's jumping from one extreme end of the animation to the other, so I need to correct that, but once it gets dialed in, I'll probably do a quickie tutorial and doing that sort of thing. Natural animations are a big deal, and I'm all for encouraging it
-
Steve_Yorkshire
- Posts: 191
- Joined: Tue Feb 03, 2015 10:30 pm
-
That feel when you've become an avatar for an open source game engine ...
badumtsss!
badumtsss!
Alright everyone!
With 3.10 done, we've started moving towards all the big and great things for 4.0, and the first biggie on the list is finalizing and rolling in the new template arrangement.
The current, near-final branch is here: https://github.com/areloch/Torque3d/tree/NewBaseGameTemplateFinal
Some changes since the last time I had everyone eyeballing this: obviously it's been updated to comply with 3.10, but the shaders and postFX stuff has been moved to /core/, and the visualizer shaders were moved to the tools directory.
I also fixed up the editor launch, so that if no levels are found because no modules have any that hook back to the default choose level dialog, you'll get a pop-up prompt to load the default editor blank level. If you're not already in a running game, launching the editor from the keybind(F11) or the main menu option will do the same, just open the default blank level. It'll also create a camera object and push an editor-specific movemap, so even if you have nothing other than a window spawning, you should be able the launch the editor and get making stuff.
Also moved the grid materials and a blank skybox material into the tools dir so the editor always has at least a few materials to work with.
So, I know there's been some inquiries in how the general behavior will work with modules and all that in relation to the new template, so I'll do a breakdown post and explain the flow of the new template here, and how it'll be expanded on in the future.
So, for the moment, the new BaseGame template will exist alongside the current Empty and Full templates, and the Full template will stay the default picked template by cmake, just so we can be sure no big problems were missed before we make the sucker the mainstay and fully deprecate the old templates.
So the first thing to do is select it as your targeted template in cmake:
Then build and install as per the norm.
If you fire it up, you'll get the default-as-included ui, all snazzy and modern-like:
Options menu behaves as you'd expect, as does the Join Server and exit buttons, and the launch world/gui editor buttons likewise behave how you'd expect.
If you click Singleplayer or Create Server buttons, however, you'll be met with a mostly blank screen, and a pop-up prompt informing there are no found levels.
If we take a look at our game's directory, we can figure out why there'd be no levels. Here's our root directory:
Core obviously has all our 'stuff needed for the engine to actually initialize and run' and tools is the editor, so we'll ignore those for now. So if we open the data folder we see this:
Here, we have the only two default modules included with the template currently - the clientServer guts, which enables you to play singleplayer or host multiplayer servers, and all the level-loading code associated with letting clients join said server. This is basically the default functionality of the Empty/Full templates in regards to launching a game.
There's also the UI folder, which has the default modern-dark UI we were looking at a minute ago.
These are MODULES, which I'd talked about in my workblog a fair bit. But we have no gameplay modules currently. The plan is for the new Project Manager to track and allow easy un/installation of modules, but until that's ready, we'll just stick with copying the ones we care about for now. If we go back to our <engine directory>/Templates folder, we'll find a Modules folder inside:
Opening that up will reveal 3 module folders: BlankGame, FPSGameplay, and spectatorGameplay.
Blank game is designed as the ultimate bare-bones project starter. It hard-loads a level created via script, and shortcuts the client/server connection stuff, so it's basically 'real' single player in that there's no true hosted server and distinct client(at least as far as T3D is concerned. Obviously it has those aspects in the backend of the engine, but you don't truely 'connect' in the same way the clientServer module sets it up as. You basically bypass all that for a local-only connection)
Then it dumps you in that map with a camera and that's it. It's up to you to go from there and work on everything, UI, gameplay, etc. Most people probably won't want to start with this one. Pretty much bypasses the clientServer and UI modules.
FPSGameplay basically replicates the Full template's aspects. It has the art assets, gameplay/weapon scripts and the levels. So the empty room, empty terrain and outpost missions, the various guns and mines, the vehicles, all that jazz. If you're working on an FPS, this is a decent starting place.
spectatorGameplay is basically the Empty Template. Empty room mission and a controllable spectator camera and not much else. A good middleground template, where you don't need all the stuff in the FPSGameplay template, but want it to hook into the UI and clientServer module functionality like the FPSGameplay module
Hook into the UI and clientServer module functionality, you say?
Indeed I did, we'll get to that momentarily. So once you have your gameplay module of choice, copy the entire module's folder and drop it into your project's data folder, alongside the ui and clientServer module folders. In our case, that means we'd now have a data/FPSGameplay folder alongside the clientServer folder and ui folder.
If you fire the game back up, and click Singleplayer or Create Server, you'll see that we now have some levels listed!
That's using the FPSGameplay module, of course.
And, picking a level and launching the game(letting the models cache, of course), you'll find you have the working guts of an FPS(or ghost simulator, in the case of the spectatorGameplay module)!
Gee willikers, is that what you were saying about hooking into the other modules?
Curiously dated proclamations of excitement aside, yes that's what was being referred to!
So lets crack open the FPSGameplay module folder and have an eyeball at what's going on with it to make it all work.
Looks pretty run of the mill other than the auspiciously named FPSGameplay.cs and FPSGameplay.module
If we open them up, here's what we'll see:
for the script file,
and
for the module file.
With 3.10 done, we've started moving towards all the big and great things for 4.0, and the first biggie on the list is finalizing and rolling in the new template arrangement.
The current, near-final branch is here: https://github.com/areloch/Torque3d/tree/NewBaseGameTemplateFinal
Some changes since the last time I had everyone eyeballing this: obviously it's been updated to comply with 3.10, but the shaders and postFX stuff has been moved to /core/, and the visualizer shaders were moved to the tools directory.
I also fixed up the editor launch, so that if no levels are found because no modules have any that hook back to the default choose level dialog, you'll get a pop-up prompt to load the default editor blank level. If you're not already in a running game, launching the editor from the keybind(F11) or the main menu option will do the same, just open the default blank level. It'll also create a camera object and push an editor-specific movemap, so even if you have nothing other than a window spawning, you should be able the launch the editor and get making stuff.
Also moved the grid materials and a blank skybox material into the tools dir so the editor always has at least a few materials to work with.
So, I know there's been some inquiries in how the general behavior will work with modules and all that in relation to the new template, so I'll do a breakdown post and explain the flow of the new template here, and how it'll be expanded on in the future.
So, for the moment, the new BaseGame template will exist alongside the current Empty and Full templates, and the Full template will stay the default picked template by cmake, just so we can be sure no big problems were missed before we make the sucker the mainstay and fully deprecate the old templates.
So the first thing to do is select it as your targeted template in cmake:
Then build and install as per the norm.
If you fire it up, you'll get the default-as-included ui, all snazzy and modern-like:
Options menu behaves as you'd expect, as does the Join Server and exit buttons, and the launch world/gui editor buttons likewise behave how you'd expect.
If you click Singleplayer or Create Server buttons, however, you'll be met with a mostly blank screen, and a pop-up prompt informing there are no found levels.
If we take a look at our game's directory, we can figure out why there'd be no levels. Here's our root directory:
Core obviously has all our 'stuff needed for the engine to actually initialize and run' and tools is the editor, so we'll ignore those for now. So if we open the data folder we see this:
Here, we have the only two default modules included with the template currently - the clientServer guts, which enables you to play singleplayer or host multiplayer servers, and all the level-loading code associated with letting clients join said server. This is basically the default functionality of the Empty/Full templates in regards to launching a game.
There's also the UI folder, which has the default modern-dark UI we were looking at a minute ago.
These are MODULES, which I'd talked about in my workblog a fair bit. But we have no gameplay modules currently. The plan is for the new Project Manager to track and allow easy un/installation of modules, but until that's ready, we'll just stick with copying the ones we care about for now. If we go back to our <engine directory>/Templates folder, we'll find a Modules folder inside:
Opening that up will reveal 3 module folders: BlankGame, FPSGameplay, and spectatorGameplay.
Blank game is designed as the ultimate bare-bones project starter. It hard-loads a level created via script, and shortcuts the client/server connection stuff, so it's basically 'real' single player in that there's no true hosted server and distinct client(at least as far as T3D is concerned. Obviously it has those aspects in the backend of the engine, but you don't truely 'connect' in the same way the clientServer module sets it up as. You basically bypass all that for a local-only connection)
Then it dumps you in that map with a camera and that's it. It's up to you to go from there and work on everything, UI, gameplay, etc. Most people probably won't want to start with this one. Pretty much bypasses the clientServer and UI modules.
FPSGameplay basically replicates the Full template's aspects. It has the art assets, gameplay/weapon scripts and the levels. So the empty room, empty terrain and outpost missions, the various guns and mines, the vehicles, all that jazz. If you're working on an FPS, this is a decent starting place.
spectatorGameplay is basically the Empty Template. Empty room mission and a controllable spectator camera and not much else. A good middleground template, where you don't need all the stuff in the FPSGameplay template, but want it to hook into the UI and clientServer module functionality like the FPSGameplay module
Hook into the UI and clientServer module functionality, you say?
Indeed I did, we'll get to that momentarily. So once you have your gameplay module of choice, copy the entire module's folder and drop it into your project's data folder, alongside the ui and clientServer module folders. In our case, that means we'd now have a data/FPSGameplay folder alongside the clientServer folder and ui folder.
If you fire the game back up, and click Singleplayer or Create Server, you'll see that we now have some levels listed!
That's using the FPSGameplay module, of course.
And, picking a level and launching the game(letting the models cache, of course), you'll find you have the working guts of an FPS(or ghost simulator, in the case of the spectatorGameplay module)!
Gee willikers, is that what you were saying about hooking into the other modules?
Curiously dated proclamations of excitement aside, yes that's what was being referred to!
So lets crack open the FPSGameplay module folder and have an eyeball at what's going on with it to make it all work.
Looks pretty run of the mill other than the auspiciously named FPSGameplay.cs and FPSGameplay.module
If we open them up, here's what we'll see:
// The general flow of a gane - server's creation, loading and hosting clients, and then destruction is as follows:
// First, a client will always create a server in the event that they want to host a single player
// game. Torque3D treats even single player connections as a soft multiplayer game, with some stuff
// in the networking short-circuited to sidestep around lag and packet transmission times.
// initServer() is called, loading the default server scripts.
// After that, if this is a dedicated server session, initDedicated() is called, otherwise initClient is called
// to prep a playable client session.
// When a local game is started - a listen server - via calling StartGame() a server is created and then the client is
// connected to it via createAndConnectToLocalServer().
function FPSGameplay::create( %this )
{
//server scripts
exec("./scripts/server/aiPlayer.cs");
exec("./scripts/server/camera.cs");
exec("./scripts/server/chat.cs");
exec("./scripts/server/cheetah.cs");
exec("./scripts/server/commands.cs");
exec("./scripts/server/deathMatchGame.cs");
exec("./scripts/server/health.cs");
exec("./scripts/server/inventory.cs");
exec("./scripts/server/item.cs");
exec("./scripts/server/player.cs");
exec("./scripts/server/projectile.cs");
exec("./scripts/server/proximityMine.cs");
exec("./scripts/server/radiusDamage.cs");
exec("./scripts/server/shapeBase.cs");
exec("./scripts/server/spawn.cs");
exec("./scripts/server/teleporter.cs");
exec("./scripts/server/triggers.cs");
exec("./scripts/server/turret.cs");
exec("./scripts/server/vehicle.cs");
exec("./scripts/server/vehicleWheeled.cs");
exec("./scripts/server/VolumetricFog.cs");
exec("./scripts/server/weapon.cs");
//add DBs
if(isObject(DatablockFilesList))
{
for( %file = findFirstFile( "data/FPSGameplay/scripts/datablocks/*.cs.dso" );
%file !$= "";
%file = findNextFile( "data/FPSGameplay/scripts/datablocks/*.cs.dso" ))
{
// Only execute, if we don't have the source file.
%csFileName = getSubStr( %file, 0, strlen( %file ) - 4 );
if( !isFile( %csFileName ) )
DatablockFilesList.add(%csFileName);
}
// Load all source material files.
for( %file = findFirstFile( "data/FPSGameplay/scripts/datablocks/*.cs" );
%file !$= "";
%file = findNextFile( "data/FPSGameplay/scripts/datablocks/*.cs" ))
{
DatablockFilesList.add(%file);
}
}
if(isObject(LevelFilesList))
{
for( %file = findFirstFile( "data/FPSGameplay/levels/*.mis" );
%file !$= "";
%file = findNextFile( "data/FPSGameplay/levels/*.mis" ))
{
LevelFilesList.add(%file);
}
}
if (!$Server::Dedicated)
{
exec("data/FPSGameplay/scripts/client/gameProfiles.cs");
//client scripts
$KeybindPath = "data/FPSGameplay/scripts/client/default.keybinds.cs";
exec($KeybindPath);
%prefPath = getPrefpath();
if(isFile(%prefPath @ "/keybinds.cs"))
exec(%prefPath @ "/keybinds.cs");
exec("data/FPSGameplay/scripts/client/inputCommands.cs");
//guis
exec("./scripts/gui/chatHud.gui");
exec("./scripts/gui/playerList.gui");
exec("./scripts/gui/playGui.gui");
exec("./scripts/gui/playGui.cs");
exec("data/FPSGameplay/scripts/client/message.cs");
exec("data/FPSGameplay/scripts/client/chatHud.cs");
exec("data/FPSGameplay/scripts/client/clientCommands.cs");
exec("data/FPSGameplay/scripts/client/messageHud.cs");
exec("data/FPSGameplay/scripts/client/playerList.cs");
}
}
function FPSGameplay::destroy( %this )
{
}
for the script file,
and
<ModuleDefinition
ModuleId="FPSGameplay"
VersionId="1"
Description="Starter module for FPS gameplay."
ScriptFile="FPSGameplay.cs"
CreateFunction="create"
DestroyFunction="destroy"
Group="Game"
Dependencies="clientServer=1,UI=1">
</ModuleDefinition>
for the module file.
So, looking at them, you can surmise that they are related to how the modules operate.
The *.module file is a taml file that defines the properties of the module itself - it's name, version number, description, the script file it uses(in our case, the FPSGameplay.cs) and the CreateFunction/DestroyFunction, as well as any dependencies the module requires to work. In the FPSGameplay module's case, it requires the clientServer and UI modules, at least version 1 to operate.
For the script file itself, you can see we do exec'ing of scripts, loading of DBs, levels and handling for if it's a client instance.
The main bits of 'hook in' pertain to the DatablockFilesList and LevelFilesList.
The DatablockFilesList basically is the list of all DBs being used that need to be transmitted to the client - which is something the clientServer module utilizes, and the LevelFilesList is basically a listing of all found level files that can be presented/selected in our chooseLevel dialog in the UI module.
There's a few bits that share common hooks with the modules, such as the clientServer module expecting a gui named playGUI somewhere it can display when the client connects, as well as some sort of description of gameplay mode in the levelInfo object in the mission so it can pick gameplay behavior or it'll spawn the player as a spectator.
Everything else is more standard; exec'ing scripts in order to ensure everything is set up and loaded for use. It just happens in a semi-automagic way now rather than needing to fuss with init.cs files and the like. When a module is loaded(which happens during the game launch - or if you add mod support, can have a separate module load phase for mod-type modules), the create function is called in the module's script file, which in our case does our init'ing.
It's important to note the common structure here. A module doesn't technically NEED to go in it's own folder, but for the sake of easy of drop in/out(you know, a big point for the entire system) and the separation/ease of maintenance that that entails, it really should go in it's own folder. Beyond that, you need the *.module file, and the script file for any stuff you need to do for the create/destroy on activation/deactivation of the modules. Beyond that, as long as it's contained inside the module's folder and has those 2 files, the rest of the module's structure can generally be whatever it is you want. Just please use some logic when organizing your modules. No one likes to open a folder and see a single directory with 1000 different files of varying types
What about all the asset stuff you were talking about before?
Excellent question, I was just getting to that. Obviously, the FPSGameplay and spectatorGameplay modules currently merely replicate the current template's behavior, as a means of acting as a bridge to older behavior people are more familiar with.
Going forward, however, most of the explicit exec'ing will be dropped in favor of the asset system. Your modules will have all your various assets, and when the module is loaded, the assets will be as well as part of the course, without needing to fuss as much about exec'ing everything yourself, streamlining the process considerably.
Sounds neat, so you're going to port the existing templates to the new asset system?
Kinda-Sorta but not exactly.
See, the advantage of the modules setup, and the assets system beneath that, is it's very easy to drop in blocks of functionality, do light integration, and be on your way with working on the actual meat of your game.
Our being able to drop in the FPSGameplay module, and because it had the hook-in behavior to the clientServer and UI modules already in there, it was able to be utilized and we spawned in a map with FPS-style gameplay just by relaunching the game.
Similarly, if you did up a custom UI module for your game and didn't need the default UI module anymore, you can just drop your UI module in and remove the default one and bam, you're done. Unlike the current templates which requires a lot of time clearing out the various exec's, and making sure you don't have erroneous references/files lying around.
The longer-term plan is to have a series of modules that provide some starting art of various styles(cartoony, near photoreal, etc), and various vertical-slices of gameplay functionality, such as FPS gameplay, Third Person Shooter gameplay, 3d platforming, racing, flying, etc, and have all these readily available on-tap so you can drop them into your project, do some light integration work, and mix-and-match assets, components and objects to rapidly prototype out your gameplay.
Not only will having the Rapid Prototype Kits on hand help, but the ease in which you can drop in, pull out, or reference/integrate modules(and the Asset Manager I talked on before will help manage dependencies, so as you make changes, it's easier to keep tabs on what's actually needed/used and what isn't) so you can spend less time trying to integrate an art pack, or AI kit, and more time working on what that means for your gameplay.
The *.module file is a taml file that defines the properties of the module itself - it's name, version number, description, the script file it uses(in our case, the FPSGameplay.cs) and the CreateFunction/DestroyFunction, as well as any dependencies the module requires to work. In the FPSGameplay module's case, it requires the clientServer and UI modules, at least version 1 to operate.
For the script file itself, you can see we do exec'ing of scripts, loading of DBs, levels and handling for if it's a client instance.
The main bits of 'hook in' pertain to the DatablockFilesList and LevelFilesList.
The DatablockFilesList basically is the list of all DBs being used that need to be transmitted to the client - which is something the clientServer module utilizes, and the LevelFilesList is basically a listing of all found level files that can be presented/selected in our chooseLevel dialog in the UI module.
There's a few bits that share common hooks with the modules, such as the clientServer module expecting a gui named playGUI somewhere it can display when the client connects, as well as some sort of description of gameplay mode in the levelInfo object in the mission so it can pick gameplay behavior or it'll spawn the player as a spectator.
Everything else is more standard; exec'ing scripts in order to ensure everything is set up and loaded for use. It just happens in a semi-automagic way now rather than needing to fuss with init.cs files and the like. When a module is loaded(which happens during the game launch - or if you add mod support, can have a separate module load phase for mod-type modules), the create function is called in the module's script file, which in our case does our init'ing.
It's important to note the common structure here. A module doesn't technically NEED to go in it's own folder, but for the sake of easy of drop in/out(you know, a big point for the entire system) and the separation/ease of maintenance that that entails, it really should go in it's own folder. Beyond that, you need the *.module file, and the script file for any stuff you need to do for the create/destroy on activation/deactivation of the modules. Beyond that, as long as it's contained inside the module's folder and has those 2 files, the rest of the module's structure can generally be whatever it is you want. Just please use some logic when organizing your modules. No one likes to open a folder and see a single directory with 1000 different files of varying types
What about all the asset stuff you were talking about before?
Excellent question, I was just getting to that. Obviously, the FPSGameplay and spectatorGameplay modules currently merely replicate the current template's behavior, as a means of acting as a bridge to older behavior people are more familiar with.
Going forward, however, most of the explicit exec'ing will be dropped in favor of the asset system. Your modules will have all your various assets, and when the module is loaded, the assets will be as well as part of the course, without needing to fuss as much about exec'ing everything yourself, streamlining the process considerably.
Sounds neat, so you're going to port the existing templates to the new asset system?
Kinda-Sorta but not exactly.
See, the advantage of the modules setup, and the assets system beneath that, is it's very easy to drop in blocks of functionality, do light integration, and be on your way with working on the actual meat of your game.
Our being able to drop in the FPSGameplay module, and because it had the hook-in behavior to the clientServer and UI modules already in there, it was able to be utilized and we spawned in a map with FPS-style gameplay just by relaunching the game.
Similarly, if you did up a custom UI module for your game and didn't need the default UI module anymore, you can just drop your UI module in and remove the default one and bam, you're done. Unlike the current templates which requires a lot of time clearing out the various exec's, and making sure you don't have erroneous references/files lying around.
The longer-term plan is to have a series of modules that provide some starting art of various styles(cartoony, near photoreal, etc), and various vertical-slices of gameplay functionality, such as FPS gameplay, Third Person Shooter gameplay, 3d platforming, racing, flying, etc, and have all these readily available on-tap so you can drop them into your project, do some light integration work, and mix-and-match assets, components and objects to rapidly prototype out your gameplay.
Not only will having the Rapid Prototype Kits on hand help, but the ease in which you can drop in, pull out, or reference/integrate modules(and the Asset Manager I talked on before will help manage dependencies, so as you make changes, it's easier to keep tabs on what's actually needed/used and what isn't) so you can spend less time trying to integrate an art pack, or AI kit, and more time working on what that means for your gameplay.
Doing some testing on a feature need that came up when I was working with Az last night.
Az wanted to try making a module that implements the twillex code to make nice fancy animated GUIs, and have it override the main menu gui control for the new template.
I remembered there's actually a setting in the console for how to handle the event when redefines happen(ie, creating a new MainMenuGUI control when one object named that already exists)
So, I implemented the overrideExistingObjects flag into module definitions, so that if that's set to true, any objects created during that module's create function call will be replaced, allowing clean overrides.
This allows some pretty cool drop-in-and-go behavior, such as the animated main menu controls, or a 3D scene background to the main menu, both of which are demonstrated in this video:
Az wanted to try making a module that implements the twillex code to make nice fancy animated GUIs, and have it override the main menu gui control for the new template.
I remembered there's actually a setting in the console for how to handle the event when redefines happen(ie, creating a new MainMenuGUI control when one object named that already exists)
So, I implemented the overrideExistingObjects flag into module definitions, so that if that's set to true, any objects created during that module's create function call will be replaced, allowing clean overrides.
This allows some pretty cool drop-in-and-go behavior, such as the animated main menu controls, or a 3D scene background to the main menu, both of which are demonstrated in this video:
Having fun module-izing old resources in between working on other more important bits.
Another fruitful endevour on this end:
Modulized the old Improved Guard AI resource by Twisted Genius, and the RPG Dialog resource recently reuploaded by @
SqHd. They've got some bits that need doing before they go up, like making the guards properly utilize the navmesh, or friendly AI helping in combat, etc, but as per the video, the broad strokes on this stuff is pretty solid and easy to work with.
Meantime, for the meat-and-potatoes work now that the new BaseGame template got merged in, I shifted back to trying to finish the update to the mesh export to support collision mesh exporting and LODs. Once that's done, I'll role on with the strip-out of Dx9.
Also had an epiphany in regards to the dark theme for the editor, where rather than hardcoding it to just simply be the dark theme. Some clever EditorSettings values and some tweaking to allow reloading of the GUIProfiles the editor controls use, and we'll have the ability to customize the theme right in the editor settings themselves, with a few fields and the regular old color swatch, rather than having to edit everything manually.
I figure from there, the logical step would be to have a few preset color themes and people just pick the one they like.
Another fruitful endevour on this end:
Modulized the old Improved Guard AI resource by Twisted Genius, and the RPG Dialog resource recently reuploaded by @
Meantime, for the meat-and-potatoes work now that the new BaseGame template got merged in, I shifted back to trying to finish the update to the mesh export to support collision mesh exporting and LODs. Once that's done, I'll role on with the strip-out of Dx9.
Also had an epiphany in regards to the dark theme for the editor, where rather than hardcoding it to just simply be the dark theme. Some clever EditorSettings values and some tweaking to allow reloading of the GUIProfiles the editor controls use, and we'll have the ability to customize the theme right in the editor settings themselves, with a few fields and the regular old color swatch, rather than having to edit everything manually.
I figure from there, the logical step would be to have a few preset color themes and people just pick the one they like.
Who is online
Users browsing this forum: Google [Bot] and 4 guests
