"Loader" Gadget: optional loading of elements
The Problem
There is currently no way of loading new assets into memory. Everything that could be used in the scene is loaded in at the start, before the player gets to the scene itself. This keeps things snappy, and there's no need to handle loading/failed-loads style situations in our logic.
However, this makes certain things pretty much impossible to do. I'll dive into the most common example, as taken from many questions about this I see on the internet: fighting games.
Fighting games tend to have many characters to choose from, each with many animations and effects and complex logic for combos and all sorts of things built in. Which makes them pretty heavy... some of the more polished characters getting as high as 20% of thermo.
Which is fine if you choose 2 characters to be in the scene ahead of time... but the whole point of having all those characters is so that the *player* can choose which they want to play with. So with the current capabilities of Dreams, you'd need all the possible characters sitting in memory when the scene loads (even if you destroy the ones you don't need, after).
But at 20% per character, this means at most you can have 5 characters in the scene... and likely have very little space for the rest of the scene objects and logic. *And* not have the variety of character choice that is common in such games. In Dreams, such games cannot have the 10 or 20 characters the creator hoped to use (or in some cases actually *built* only to find later that their amazing complex wonderful game with all those characters isn't feasible).
The only way of having more characters available is to have multiple scenes. At worst, a copy of the scene per character the player could choose. At best, scenes with different combinations of characters so the same scene can be used if the player chooses Char A-E, another scene for Char F-J, etc.
Of course, fighting games tend to be player vs player, or have a mode for that at least. Which means even more scenes with more combinations to allow Char B vs Char G, etc. And then make a change to a character or scene... and you've got to update *all those scenes*. It gets *very* unwieldy, *very* fast.
For these reasons, people talk about simply being able to emit an element from outside the scene the player is in. This would be ideal, but potentially complex--and also hang Dreams if it needs to load new stuff in, build sculpts, etc. So I was thinking of a (potentially) simpler solution which would have minimal disruption for how loading currently works, but give creators the ability to create games with lots of characters (and other things).
A Possible Solution? Maybe?
So going back a bit... everything that could be used in a scene is loaded at the start of the scene. My idea is to *optionally* load things at that same time. That's pretty much how fighting games work in traditional game engines: Need Char B? Load Char B while the level loads. Don't need Char B? Don't load Char B while the level loads--and it uses no memory (which we see as "thermo" in Dreams).
That part at least is already there. Dreams can load elements. All good.
Now, how do we tell Dreams to load or not to load an element into the next scene? We could use a similar mechanism to one we know and love: persistent variables. We use these to store numbers beyond the scene we're currently in, to use later.
Dreams itself doesn't use this data for anything at the moment. But what if it did? Or at least, what if it used a similar storing mechanism for the creator to tell Dreams what to load into the next scene?
Let's imagine a new gadget I'll call the Loader. It has the following features:
-
Dreamiverse Element: similar to the setting of the same name in trigger zones, where you can select any element. This could be different in different scenes, making it more flexible (I guess?). It could also be left blank--for the character select scene itself, for example, so it would never actually load anything itself.
-
Load Into Next Scene: if this is on when leaving the scene, the scene that is loaded next will be searched for a Loader gadgets of the same name. The element those have linked in their tweak menu will be loaded in, and be placed at the position of their Loader gadget (perhaps using the grab point of the element).
This setting will have the same state it had from the previous scene--letting the creator easily read whether this was loaded or not. And this setting would persist between playthroughs so that if the player starts playing a long game as Char B, leaves, and comes back, they'll continue playing as Char B.
So for the example given before... you'd have your 20-character menu scene. Players would choose the characters they want, which would turn on only the "Load Into Next Scene" setting of the relevant character gadgets. When they load the next scene, *just those characters* will additionally be loaded and will pop into existence. Any combination, any of the levels, it all just works--and allows much more complex games as a result.
Potential Issues...
- The creator wanted to emit the object. They could make the element have an emitter ready to go though, so not a big deal.
- The creator wants it to load in at a different place. There could be a gizmo to the Loader for this. Or the creator can just use a teleporter as part of their element.
- The creator requested too much to be loaded to fit within thermo. If these are processed and loaded in gadget-creation order (as most things are processed), the last things won't load in. This problem already happens with emitters, and that's how it works there too, so as it's consistent this is probably okay. There could be an edit-mode warning of some kind for the creator that this has happened (which there isn't for failed emits) to help them understand what happened. But it would be on the creator to fix.
I feel like this is a pretty solid solution to the problem, with versatility to use it in innovative ways, that makes use of the existing functionality Dreams already has, and has limited impact on the workings of Dreams.
-
I remember suggesting something similar to this in the previous incarnation of the forums - the "Variant Element".
Similar to an Emitter, but with a few extra tweaks - a text field to name a persistent variable, and an expandable table mapping values to Dreamiverse elements. At scene load time, the value of the persistent variable would be used to look up a Dreamiverse element in the Variant Element's table, and for the remainder of the scene it would function as an Emitter for that element.
-
Yeah I think we talked about this idea on there. This is just a variation I guess. But one of them well actually get through to Mm... in theory. XD
-
Definitely agree with this. Its not just for player choice stuff either. You might have some very heavy logic chips that calculate the level at start. If you could load and free these from the thermo then it would leave more space for the actual game runtime elements.
I don't see why it would be such an issue to have stuff loading in on the fly. If you try and load a new element and there isn't enough thermo then it will just not happen. Much like the way the emitter will just stop emitting if you overload it! As long as the gadgets give outputs for "is loading", "has loaded (pulse)", "failed to load (pulse)" then leave it upto the user to work it out.
-
The other thing to think about though, for live-loading... is when a sculpt is loaded that's not already built into memory, it would have to build that. Which most likely will freeze the entire game while that is building. Perhaps that's a reason they didn't want to do this kind of thing.
Please sign in to leave a comment.