I have an architectural best practices question. I have figured out how to load objects at run-time.
Could anyone tell me the best architecture to build a scene all at run-time.
For instance:
Would I create a method and place it right after…
armory.system.Starter.main?
Is there a better place/structure to place the code that will allow me to report load status back to the user easier?
Would I crate an empty with trait, and put it in the init and it would never run again until game restart?
Basically I would like to recreate the playground sample at start from json.
I’m just not sure how you guys inject start up/setup code.
Without getting too specific about Armory, I’ll speak in the abstract to this question.
Most of the time a game-engine has a queue of “things to do.” When some part of the system wants a subroutine to be called “soon,” it creates a record – let’s call it an “event” or a “to-do” – and adds it to this queue, which is serviced by the main game loop on a regular basis. (But, not synchronized with “frames” and so on …)
It’s very similar to how you see things being done, say, in the also very-asynchronous world of JavaScript … which literally has an OnLoad event. Same idea exactly. (Although remember: I am speaking of abstract ideas – I’m not talking about "the JavaScript target," nor anything particular to Armory or to Haxe.)
So, “initialize the new scene” is placed onto this queue before the main loop is started, so that it’s the first thing to be done. The game’s overall state is set to something like NOT_YET_STARTED so that other parts of the game logic twiddle their thumbs until the initialization routine finishes its work and sets the game-state to something else.
This kind of design works well because “it isn’t an exception to how the game normally operates.” The first thing that we do is to start the engine and leave it running, having pre-arranged for the first thing(s) that it will do. Code to set up the first level can be more-or-less reused to set up the next ones without building-in too many special cases. So it’s very clean. Sometimes you’ll see a more-elaborate game initialization (or, level initialization) process that is broken down into many “queued events” that queue one another, that arrange for “call-back events” to be queued at the right times, and so on… (This might be done so that several threads, each of which are being driven by the same event-queue, can work simultaneously.)
This is a great response! You totally got me over the architecture block I was having. I have been a C# developer for a while so the abstract concepts you covered I understood and are spot on.
You said the magic words that got me out of the block. You said “initialize the new scene”.
You got my design thoughts back in line.