Variant Elements - an idea to reduce combinatorial explosion of scenes
Suppose I'm creating an RPG. Let's say that there are 16 types of enemy for the player to battle, and having all of them in a single scene would exceed a thermometer limit. But that shouldn't be a problem provided that there won't be any battles where the player must fight every type of enemy - I can create one battle scene for each combination of enemy types that the player might need to fight. In this case, let's say that the maximum number of types of enemy in a battle is 4. Unfortunately that means that I'll need 16!/(16 - 4)!4! battle scenes which is 1820 and that also exceeds a limit.
What feature could fix this?
A Variant Element would be a logic gadget similar to an Emitter, but its tweak menu would also have the name of a dream persistent variable and a list of connections associating values of that variable with Dreamiverse elements. When a scene containing a Variant Element loads, the value of the Variant Element's variable is read, and the corresponding Dreamiverse element is loaded. For the remainder of the scene, the Variant Element is an Emitter for that one Dreamiverse element only, and cannot emit any of the other Dreamiverse elements associated with other values of its variable. The thermometer usage of a Variant Element would be the thermometer usage of its most expensive associated element plus a small overhead for the gadget itself, as opposed to the sum of the thermometer usage of its associated elements.
For the scenario of creating a battle scene for an RPG that I described earlier, Variant Elements would reduce the combinatorial explosion from 1820 scenes to 1 scene.
I think it doesn't necessarily *need* to work like a variable. It could be more like a selector, where you have one gadget that holds a list of elements. Send a signal into one of those items and that'll be the one loaded in, if a gadget of the same name is in the next scene. Something like that. So the implementation is fairly flexible; main thing is the "persistence" of which element is requested to be loaded between scenes.
As I understand it, the next scene (or what it guesses to be the next scene) is downloaded--either on disc or in memory--while playing the previous scene, but no processing is done on it. (If it hasn't been downloaded fully, that's the little percentage you see in the corner.) Turns out the scene it preloads is the one targetted by the doorway gadget closest to the camera? Or the player maybe? So you can actually get Dreams to preload the scene you actually want to preload.
Then when you actually go to the next scene, it processes that data. If a sculpt wasn't used in the previous scene, it's rebuilt from the downloaded instructions (list of edits). If it was used, and so already in memory, it'll just keep that in memory.
So yes, it does do a load of processing between scenes--depending on what's required.
Yeah maybe. I think that is how audio works, is streamed off the hard drive.
And yes that is right with the double memory. If you didn't need the reference object that could save a little gameplay. On LittleBigPlanet an emitter wouldn't take any thermometer (well a tiny fraction) if nothing was emitted. They worked a little differently to Dreams, you didn't need a reference in the scene.
I think the variable element idea is definitely the more 'bulletproof' method as I like to say. It would be perfectly stable so would the safer bet.
I don't think either idea would be technically too difficult to implement. In my opinion (non expert) I think that what I suggested could potentially be more straight forward as the game essentially does it already when you stamp a new element in edit mode.
When I said wouldn't that cause a paradox before what I meant was that when a scene is loading what actually is happening? Is it just downloading data and putting into ram? Is it running code in the background also? If it is running code then it needs the downloaded data first to know what element data to then download. I'm sure that could easily be done in multiple passes but is that how the game works? I have no idea. The way I thought about it was like a variable, only a number is stored between the scenes and the individual scenes interoperate that number in how ever you set it up.
But yeah TheBeardyMans idea is great, I gave it a vote before I commented. Only thing I didn't like was possibly having a fiddly variable style system. Isn't intuitive or user friendly, which is the spirit of Dreams. other then that is a solid idea/method.
Ah cool. :D
I think with your solution they could at least download all the elements ahead of time to the cache; downloads are fast and small anyhow. If so it wouldn't need the internet while playing to load it in. But reading from disc and getting stuff into memory is what takes more time, so could cause stutter during play. If that's an acceptable trade-off, then that's fine I guess.
Another thing I just thought of which may be relevant is that when the emitter loads up that element to emit it, it's actually using double the memory--once for the reference and once for the actual emitted object. Not that big a deal as that is how emitters work anyhow, but thought I'd mention it.
I think technically either could work. I think the variable-element would be an easier sell, as it can fold into the existing loading step and not cause any runtime issues. And I would personally prefer it because I would prefer to avoid the potential runtime stutter.
That's the reason I like it so much really. I've always wanted to be able to just emit soemthing I actually need and not have it in memory if I don't need it, but couldn't think of a way of doing it without adding complexity and accepting lag as it loads. So this sort of "compromise" where we tell the loader what we will need in the next scene is pretty ingenious, to me :D
No need to be sorry. I didn't see it as an argument, we are just both very opinionated. As long as everyone is respectful it is good to have discussions, even disagreements.
Although I don't always agree with you I've not once thought that you haven't been respectful. Hopefully I haven't come across as disrespectful either, even though I am very opinionated.
I think the confusion stems from the fact that we were discussing the drawbacks/functioning of my idea with the functioning of the original idea interchangeably. They would be very different solutions in the end so aren't necessarily comparable. All you can do is look at the negatives and positives.
TheBeardyMans main issue with my suggestion was an increased risk of hitting a limit. I think he understood that everything wouldn't be in memory as he said "...provided that an Emitter that emits a Dreamiverse element doesn't consume the thermo until it gets emitted...".
My response to that was emitters already have a risk of hitting a limit, gameplay usage goes up. If graphics could work similarly being able to going up and down, I don't think that is necessarily a bad thing. It would be something the creator would have to manage like gameplay.
Your first reply to me about everything would need to be in memory is where my "I assumed the elements wouldn't need to all be in memory as otherwise that would make this idea pointless..." was referring to. I was talking about my idea, as that is what you were talking about. You also mentioned that it would be slower, which is correct. I had no issue with that as it was relevant.
Your explanation in your second reply was more helpful as my questions to TheBeardyMan and later you were genuine. I was interested how the two ideas would differ in hitting a limit.
I understand now that what you were saying is it would be impossible to try and load more elements then the game could handle, so it would always be stable in that sense. I had considered that as I compared my idea to an emitter. I was thinking more that if used correctly in an identical scenario there wouldn't be an increased risk of hitting a limit.
So yeah I was addressing the issues raised with my suggestion, which I thought were either not an issue or a justifiable compromise. But anyway as I said, relying on a constant connection to the server is more of a problem. I never really considered that as I probably take it for granted I have super fast and reliable internet, cant guarantee that for all players.
Sorry, I wasn't trying to start an argument honestly. I was trying to explain the difference between allowing us to choose an external element to emit if we wish to during runtime, and being able to say which element we want to emit before runtime. I guess I didn't do a good job.
Maybe you understand all the below, but when you said "I assumed the elements wouldn't need to all be in memory as otherwise that would make this idea pointless" it sounded like you were saying OP's idea was pointless because it would need to be loaded into memory. Or that things that you want to emit don't use thermo by default (as you didn't mention those external elements would be loaded in at runtime).
To summarise, OP's solution means you never have to wait for something to load during play and (seemingly) requires minimal changes to the loading part of Dreams. Whereas selecting an external element for an emitter would mean waiting to load stuff during play and (seemingly) requires a new loading mechanism to be put into place that doesn't disrupt gameplay to get stuff into memory.
If you *don't* disrupt gameplay and introduce waiting for stuff to load in, that means you'd have to load all those external elements when the scene loads. And so it would have the same costs as a regular emitter and be able to pop the thermo. Vs OP's solution which is far less likely to pop the thermo as it doesn't have to load all the elements in from the start.
When reading your original comment it wasn't clear that you didn't want to avoid delays and gameplay disruption (avoiding those is pretty great in Dreams right now and by far preferable), so I (and it seems OP) assumed you wanted to load it all in from the start. Maybe not, but it wasn't explicit in your original comment to me.
Here's my full explanation in case the above didn't cover it...
OP's problem, as I understand it, is that they have many possible things that need to exist in the next scene. They could have all of them in the next scene and then destroy the ones they don't need, but that means they'd all require thermo to exist in the first place. They are proposing a way that *none* of them using thermo unless a certain flag is set in the previous scene.
Something that could be emitted at some point *must be in memory* for it to be emitted so that it can be emitted instantly. The object an emitter references and will make a copy of is in the scene as well, using memory/thermo. When it emits a copy, it makes a copy of that reference object. So the object-to-emit isn't free; it has to be loaded into memory and use thermo. That's why using an emitter wouldn't work for OP's case.
So however you do this, if you want to emit something at any time during play, that object will have to be loaded in with everything else that is loaded in. If we had the ability to select an *external element* to emit later, Dreams would *still* have to load in that external element at the start of the scene so it could emit immediately when requested. If that's the case, then that external element would still use memory and thermo no matter what.
This would use the same memory as just importing that element and linking it to an emitter. So it would make no difference thermo-wise. So it would not help with OP's problem. This is what I was trying to explain; thermo-wise, using the existing emitter mechanism will not help.
OP proposed that Dreams loads *none* of possible elements into memory (using zero thermo) apart from the ones flagged in the previous scene. So in the scene they could emit the object as they would with a regular emitter, but instead of all the linked objects (whether external elements or objects stored in the scene) having to be loaded and use thermo... only the ones that the creator specifically requests are loaded into memory.
There is no way of loading stuff during the scene, as that will introduce delays at runtime when you want to emit something. So Dreams needs to know *before* it gets to the next scene what things it will need to load. With your solution it seemed like it would still need to load all of those external elements in, because it doesn't know which ones will ever be emitted during the scene. With OP's solution it would be explicitly told by the creator which ones will be emitted during the scene--and by the same token, explicitly told which ones will *never* be emitted and so do not need to be loaded at all.
Yes I am aware of the point of this. I just gave an alternative suggestion that if possible (which I have no idea) would achieve the same result but be more flexible and simpler to understand and use I think. Is only food for thought.
TheBeardyMans issues with that idea were that it could have an increased risk of hitting a limit and you'd need an emitter for each element increasing gameplay usage. I addressed those points saying it would function similarly to an emitter which already has an increased risk of hitting a limit and that you can already optimise your scenes different ways.
You are the one that mentioned loading things into memory. I thought it was self explanatory that if the element wasn't in the scene then it wouldn't be in memory. Maybe it wasn't clear though so I explained that to you. The process of emitting something (or other methods) would load it into memory then emit it. That would be slower as you pointed out (not me), it would be a compromise for being able to load external things.
Thinking about it the main problem with what I suggested is relying on a constant network connection. That wouldn't stable for some players so probably isn't the best idea.
Something like this (dynamically loading things you need, not things you don't) in some way shape or form would definitely be useful.
The whole point of this idea is that the engine knows *when loading the next scene* what it needs to load in. The engine can read the variable data any time it wants, even while loading a scene. So if they made a gadget that can store what needs to be loaded on next scene-load, then it can do that before the player gets to the next scene. So there would be no actual varaible gadget involved. There would be a "variable element" instead, which could be read by the loading part of the engine.
This idea is not about loading and unloading things during a scene. It's about loading things between scenes that you can use in the next scene. And it's not about how long it takes to load, but how much stuff has to be in memory. With such a gadget you can say in one scene "the next scene requires such-and-such an element" then it can load that element in while loading the next scene, and you can use it in the next scene.
So this a much more focussed problem we're discussing with a much more focussed solution (and may be easier and safer to implement).
I assumed the elements wouldn't need to all be in memory as otherwise that would make this idea pointless, thermometer usage would not be reduced.
Doesn't the scene need to be loaded so the variable can be read and the logic can run? That sounds like a paradox, how would the scene know what to load without the scene running?
If the scene does need to be running then why limit loading things into memory just on initiation, wouldn't be as powerful or useful.
Yeah having to load stuff into memory would take longer then it already being there but I thought that was the idea of this, to load things into memory you need and don't load things you don't need.
Dreams loads things incredibly quickly, yes it would be slower but that would be the compromise of loading new things into a scene.
Something to bear in mind is that emitting something needs to be instant (or as close to instant as possible), which means it has to be in memory already, which means to be safe it should be loaded when the scene is loaded.
So the difference between the two ideas is:
Being able to emit anything from the dreamiverse means that that object would have to be loaded at load-time anyway, and be in memory. So if you have 20 emitters for 20 characters, you'd need to have 20 characters in memory because you don't know which will actually be used so you have to assume they will all be used at any moment. So it has to load them all in anyway--which is the same as a regular emitter that has the thing it *could* emit loaded into memory from the start.
Whereas a "variable element" could be loaded when the scene is loaded, Which object that gadget can emit has been decided before loading begins, so it knows for sure you won't need any of the others, and so does *not* need to load them all in.
How would your idea not have an increased risk of hitting a limit compared to what I suggested? I don't understand that. The purpose of this is being able to more dynamically manage the thermometers right?
An emitter in it's current state already has an increased risk of hitting a limit. I think your idea as well as what I suggested would function identically to an emitter (except for being able to increase graphics as well as gameplay) so I don't think it would be an issue.
Yeah your idea would reduce the amount of emitters by allowing one emitter to emit many different things but it sounds a bit cumbersome and convoluted so wouldn't be that intuitive or user friendly I don't think.
You can already optimise by dynamically emitting and destroying things as and when you need them. For example emitting an element that contains the 16 emitters then destroying it, then you still only have a single emitter in the scene. So I don't really think that justifies a complicated variable system.
Your idea is great, I'd like to see something like this. It basically allows you to stream data into a scene. It is just I think the execution could be refined and streamlined compared to what you described.
@oLMCo Yes, that would achieve the same result provided that an Emitter that emits a Dreamiverse element doesn't consume the thermo of that element until it gets emitted for the first time, but there would be an increased risk of exceeding a thermo limit at runtime. Adapting your idea to the scenario of creating a battle scene for an RPG that I described would require 16 emitters in 1 scene, and the elements wouldn't necessarily be optimized to allow more than 4 of those emitters to be triggered before the graphics thermo is exceeded.
How about just being able to select an element from the Dreamiverse to be emitted? A bit like with the trigger zone where you can select something from the Dreamiverse to be detected (which I don't see the point of currently, why be able to detect something that is not necessarily there?).
Would achieve the same result of being able to load things into a scene but be more user friendly and simplified in my opinion.
Oh I get it, like a "variable element" sort of thing. That could be a pretty elegant solution for this type of case 👍
Works for fighting games where you want like 100 character to choose from or whatever :D