I used a good bit of it as a starting point(like the core folder), it just extends further to utilize the modules system to make it easier to drop in/out module packages and the like.
Well, if you are going to only read the last post please try to fully grasp that single post you do read.disclaimer: only read the last post, i'm lazy, sue me.
Due to the way this template completely revamps the initialization process, that's already been done. As an aside, though, there is a new module named 'clientServer' that handles all the initialization for Client AND Server. But it actually IS easier to make MP games with this template, because it's easy enough to go one way or the other following the initialization scripts @ JeffR has assembled here.Why not separate files in a way that makes separating client and server easier for those that want to make multiplayer games
Haha, thanks. A lot of the idea behind the structure is from @ buckmaster, but I've expanded on his original base.@JeffR: It would appear I'm raising this thread from the dead! Necromancer extraordinaire! I have been designing a new Base Template for modular development, and I found this thread. Firstly I'd like to commend you for the work and effort that went into building this. Thanks man, this has been needed for awhile. Respect, I am particularly fond of the craftiness that went into bypassing all of the duplicate initialization code.
If you mean the module script files for initialization stuffs, then you actually can set what the creation/destroy functions are called in the module definition file. I opted for the create/destroy naming convention, but start/exit could work just as well.I have some inquiries about your work. Firstly, I didn't see the onStart() and onExit() callbacks in the new main.cs files.
This is really interesting, and left me curious:
Wouldn't this be question 2?Question #1: Will the current "main loop" layout be deprecated in source? Obviously it's already been deprecated in the New Base Template, just wondering if the current functionality would still be available. (i.e. onStart() and onExit() overrides to initialize mods.)
Yeah, the modules are intialized when loaded. If you look at the module taml files, there's a entry for the create and destroy function names. In the main.cs, we find and force load any game modules at the start, which automatically executes the create function. Order is defined by dependencies, so you'll see some of the modules have dependencies to the UI module, for example.Question #2: Related to Question #1 - Would the current onStart() and onExit() callbacks just be redundant anyway because the module system is automagically initializing the modules?
This is definitely one of the squirrelier parts. Most of the common shaders are just core, attached to lighting, and main classes like terrain or water. So there's a fair case to be made of them just being in core to make sure everything initializes correctly.Unrelated to all of that, I wanted to ask about the postFX and shaders:
Question #3: Would it be safe to move the shaders\ directory into core\? It just seems out of place since it's not really a 'module' in the data\ directory. It appears shaders aren't necessary for core\ initialization, though, which leads us to Question#4:
If we had to merge 'em all, it'd probably make the most sense to bump 'em to core. The idea behind the core directiory is "This is what's needed for the engine to load/initialize". The game-specific stuff is still there for core initialization of core game classes like terrain and all that. So they kinda exist in a twilight zone area.Question #4: I noticed the core\gfxData\ directory holds game-specific stuffs. TerrainBlock, Clouds, ScatterSky, Water...are these necessary to include in core\ ?
Suggestion for #3 and #4: I would merge all of that either way. Either place shaders\ into the gfxData\ directory or gfxData into the shaders\ one.
You can just do a search for:Anyways man, yea thanks so much again for this template. I had put in a few pages worth of a changelog constructing a new template when I stumbled on your post. Would have saved me a good bit of time. lol.
Oh, I almost forgot:
Question #5: Could you point me in GitHub to relevant files that were altered in source regarding the shader file paths?
$Core::CommonShaderPathAnd that should find 'em all.
$Core::MissingTexturePath $Core::UnAvailableTexturePath $Core::WarningTexturePath
Yeah, this all ties back to what I said above, about how the game class initalization and those common shaders are kinda in a twilight position, where they ostensibly need to be there to make sure it's all initialized properly, but also pretty game-specific as they're prone to modification, where as the CORE scripts usually aren't.In my posting, if anything, I've spoken in favor of moving some stuff that doesn't belong in core\ out of it. I only suggested shaders\ joining with gfxData\ since they are closely related anyhow. Preferably, yes, I'd imagine they would belong in a client module. If you look closely at my Question #3 above, you'll see I did state that the shaders aren't necessary for core initialization. Which I immediately followed up with #4, where I question if gfxData\ belongs in core to begin with. Really all of that serves to highlight how much of a grey area those are and it's easy to see how placement of those particular directories/files can be a bit of a chore.
Breaking up the client and server sides into 2 modules wouldn't actually be a bad idea at all. It'd make it easier for people to have a 'client' and 'server' build of the game, for projects that go that route. Definitely worth a consideration!Due to the way this template completely revamps the initialization process, that's already been done. As an aside, though, there is a new module named 'clientServer' that handles all the initialization for Client AND Server. But it actually IS easier to make MP games with this template, because it's easy enough to go one way or the other following the initialization scripts @ JeffR has assembled here.Why not separate files in a way that makes separating client and server easier for those that want to make multiplayer games
Heck, as a matter of fact, the more I delve into this New Base Template, the more it's starting to stick and it's working well. I've already started building modules and having them initialize using the new system!
EDIT: The thought occurred to me that one could split the clientServer module and add shaders\ to the client module. That could be useful, but Jeff's got it all so tidy already it's kinda hard to bring one's self to mix it up. lol. The client and server scripts are separate and initialize from different functions. Good enough for me!
And yeah, if you've been keeping an eye on my work blog thread, the modifications to the asset pipeline should make this new approach way easier. I'm most likely going to retool the template some to account for those changes when they get more solid, as it'll be easy to smash out and organize modules in the editor directly. May help make clearer what to do with stuff like the terrain/water initialization stuff too.Heck, as a matter of fact, the more I delve into this New Base Template, the more it's starting to stick and it's working well. I've already started building modules and having them initialize using the new system!
Yea, it kinda is I guess. I was just wondering if onStart() and onExit() callbacks would still exist that's all. I noticed ya did still use onExit() so I'm assuming those callbacks may still be floating around. It's a trivial concern, as you've eluded to, in question 2 we've covered what really matters: the modules initialize everything with their functions!Wouldn't this be question 2?
Not quite getting your meaning here. Could you clarify some?
Toss my vote in the hat for doing that. There are a few reasons:Breaking up the client and server sides into 2 modules wouldn't actually be a bad idea at all. It'd make it easier for people to have a 'client' and 'server' build of the game, for projects that go that route. Definitely worth a consideration!
Code: Select all
if(!$Server::Dedicated) ModuleDatabase.LoadGroup( "Client" ); ModuleDatabase.LoadGroup( "Server" );