Tweaking Multiple Levels
Shady91 last edited by
I've been working on my Krab project trying to add levels. I start by duplicating the scene and modifying it, but I find myself constantly going back and tweaking or fixing things with the gameplay on the original scene. So, I end up having scenes that don't match. Editing each scene doesn't seem very practical, neither does starting over. How do I solve this?
It depends on how your logic and game play is set up.
But we have a function called "Mirror Object", where you can duplicate an object to another scene, but all of it's behaviours and logic are shared across all scenes.
So if you modify one of these mirrored objects in Scene A, the mirrored object in Scene B will also have the changes.
Press and hold an object, then select Mirror instead of copy. Then it will let you select a scene to paste it to.
Deeeds last edited by
@Murtaza Does it also hold true that editing the object in Scene B propagates changes back to the original (source) object in Scene A?
Yes. The mirrored object is the same across all scenes.
Deeeds last edited by Deeeds
@Murtaza That's not an answer to the question I'm asking.
If I mirror Object_XYZ from Scene_A to Scene_B and Scene_C, when editing Object_XYZ in Scene_C, do those changes propagate to the instance of Object_XYZ back in Scene_A and Scene_B?
Yes. Like I said the mirrored object is the same across all levels.
It's not 3 different objects. It's one object that exists in 3 places. So when you add a behaviour to object_xyz in Scene_B, that behaviour will also exist in object_xyz in Scene_A and Scene_C
Deeeds last edited by
@Murtaza Ok, let me help you.
Saying "The mirrored object is the same across all levels" doesn't provide an absolute description of the relationship, it only says that they are the same at the moment of mirroring, not that they're the same object.
Let me try to make this clear by example that might help you understand why "mirror", in this context, is not nearly as communicative as you imagine it to be, by exchanging it for one of the words within its context of usage, in that same sentence:
"The copied object is the same across all levels" does not mean that it is the SAME object, it means that the objects are the same, at the moment of copying. There is no implication of a relationship, only of a process that creates in a manner that means they're the same at the moment of the action of copying.
When mirroring, I'd imagine a reflection, i.e. that it's opposite in left and right, but otherwise the same, in the moment of performing the action. There is no clarification that the mirror is real, or permanent, as it is in other environments.
The word you're avoiding is "REFERENCE", which defines the relationship between each location using the object and the object. Each scene holds a REFERENCE to the one object. In this way each mirrored object is not the same, there is ONLY one object and it's being referenced in multiple Scenes.
Which is where your use of the word "prefab" is weird, and belays your exposure to Unity and not much else. Prefabs in Unity are a shocking workflow. Make in a scene, shape as you like, save as a prefab, and then instantiate back into the scene as an instance.
Just about every other environment of creativity has done this better than Unity, including Photoshop, which has really struggled with its "Smart Objects" metaphor for generations.
Due to the nature of programming, there is not the need for a "library" in the manner in which Flash and Unity require, these are only contrivances to overcome the need to hold entities somewhere universal to the project within a world before the cloud.
I'm suggesting a process of universal classing, for lack of a better term, whereby ANY entity created anywhere can instantly be referenced (and instanced) by any other Scene, Project or User. At the project level this is handled by the user within the project. It doesn't matter where they first create the entity, all uses of it are a reference to it so are all equally capable of editing its states and abilities.
Once shared with other projects, it becomes unique to each of those projects, as it's imported from the shared space, the cloud storage. That cloud stored version can change without changing the states or abilities of the referenced entity within other projects. The user has the choice to "upgrade" to later versions of the cloud-shared entity (this is a classification file, blueprint or "class", by any other name).
We actually used the term reference very early on. But in testing, it just didn't work. Our focus groups would result in users just coming back and saying "Ohh, like a mirror then?". And thats when we started looking into other words.
Also reference is to much like programmer speak. Which is something we try to avoid in hyperPad. Our goal is to make the concepts and paradigms easily accessible to non programmers. So we often need to avoid making thins overly complicated.
As for Prefabs, Unity is not the only engine to use Prefabs. It's also not the only engine I've used. I've been using Game authoring tools since about 1997 so I've experienced a few different prefab systems. Unity is actually pretty nice in the grand scheme of things, but not perfect I agree.
But what you're suggesting with your "classing" system is sort of where we're headed with the prefab system :).