Mirror, Mirror on the wall, who's the reference of them all?
Deeeds last edited by Deeeds
Rename this "mirroring" functionality.
I know... you probably thought this made it simpler to understand. It doesn't.
Firstly because it's simply the wrong word to use in a graphical environment. Secondly because it has zero correlation with any other manner in which this functionality is described in any other programming environment.
Thirdly, because this is the single most powerful feature I've found in your little engine-that-could, and the basis for how anyone would then consider designing and iterating through their development process within it.
So, to finding a way to both name this functionality and provide easy access to it, I suggest the following:
Make it possible to share an object to multiple scenes at once. The fact that it would take 10 passes through this process to push an object to 10 scenes is ridiculous. Just add checkboxes to the list of Scenes so the user can select a number of Scenes to share this object into.
If at all possible, consider making it possible to share such an object with the cloud so that it's not limited to only the Scenes in one project, but can be shared amongst an infinite number of projects... and users! In this way users can share code with one another that demonstrates ideas and techniques, easily, super rapidly.
Consider this one step further and changes can be only possible by the originator, or a list of approved, or everyone, along with a shared history (versioning) of the object's changes. Kind of like a single git repo for a single shareable object. Far simpler than whole projects and scenes. And users can pack in all the code they want to make it helpful for porting code around.
Consider how appropriate the word "share" is in the above sentences and discussion of referencing a single, shared instance. It's not perfect, but it's a good deal more accurate and meaningful than "mirror" can ever be.
Make the astute choice, do things my way: rename this functionality "Share..." complete with those three dots, so users get the full sense that choosing this item from the choices::: ||| Copy || Cut || Share... |||| are fully aware they're going to get the chance to make other choices, and cancel the process. i.e. make it OBVIOUSLY DISCOVERABLE!!!
We've tested a few different names early on (I don't remember them now, will have to pull up our documents and videos). And this is the one that made most sense to users who we tested (ranging from students, to artists).
The reason why we went with mirror is because It's not really sharing it to another scene. It's not a copy or duplicate. It's the same object that exists in both scenes. It's behaviours, changes, and settings are are mirrored across all the scenes. It's one object that is existing everywhere.
The way you're describing it almost mixes it up with a "prefab" style object. Where you would have an original object, then a copy based on that in each scene.
We're open to suggestions, but I don't think "Share" is the right wording either. When I hear share, I think I'm sending it to someone else outside of the project. Which isn't true. And when we actually add sharing objects (as prefabs) to other users, this could get confusing.
Once we have prefabbing in place it will handle most of the confusion since we can use the standard "prefab" term.
As for your other suggestion, mirroring to multiple scenes at once. This introduces a new problem. Where do you place the object in each scene? With the current workflow, the idea is that you'd mirror the object, then place it where you would want.
Also, it's rare for most users to work on multiple scenes simultaneously, so this extra functionality could confuse the majority of users even though it is a bit less tedious for a few.
Kamdroid last edited by Kamdroid
Having a prefab style rather than the “mirror” would be awesome, and a lot of developers are used to it this way.
e.g. You make a coin object, press on the object and press “Make prefab”, which would add the prefab object to your project assets, so you can drag them into scenes, rather than going to a scene with it already existing and needing to mirror it to the scene you want.
@Kamdroid My suggestion is this: The concept of a prefab and library are redundant. You simply need a sortable, searchable list of everything in a project. Everything is, by it's very nature, ready to be replicated by instancing, copying or referencing. Should be a user choice.
The UX is something like this:
Choose Spawn Behaviour -> Pick type of spawn (Instance, Copy or Reference) -> Pick from list of Objects -> Set Spacing, volume etc...
Kamdroid last edited by
@Deeeds I still believe prefabs, being easily accessible through your project asset file viewer, would be simpler.
@Kamdroid Have no fear. There's zero chance they're going to do anything other than copy the ways of unity.
iTap Development last edited by
@Kamdroid Have no fear. There's zero chance they're going to do anything other than copy the ways of unity.
You mean the way the game development industry has been doing since the existence of authoring tools? (wayyy before Unity).
There's a reason why it's done that way. It works pretty well! There's definitely room for improvement though.
@Murtaza Unity doesn't follow the conventions you think it does, and isn't what you think it is relative to other engines and ways of doing things. You're letting Unity marketing and promotion tell you things that aren't true.
Oh ok. I didn't know I was so naive.
I could say the same to you :).
We got the feature request, and we're working on a prefab system that handles a lot fo the functionality you describe (including spawning an instance of an object that doesn't exist in the scene already).
You're welcome to beta test it and give your feedback on it once we're further along in the prefab system development
There is no reason to complain about how it doesn't work the way you want it to before it even exists yet. ;).
@Murtaza I'm not complaining about a feature, or lack thereof.
I'm pointing out a simple truth: imagining the success and ubiquity of Flash was because it was well designed and articulated great concepts of programming and interactivity is wrongheaded, in the extreme. There are other far more significant reasons contributing to its later stages of success. None of which had anything to do with following good, useful, right or helpful conventions.
The same is true of Unity, for different reasons.
There is an example of superior utilisation of the reference, instance and copy paradigms, and it's one that you don't know about... 3ds Max and its Modifier Stack.
It's also, in various guises, in every design product on the planet, some good, some bad. Adobe does it worst, despite being the most commonly used design software. They were late to incorporating this sort of feature and were hobbled by legacy code in how they "designed" these "features".
@Murtaza There is an Adobe exception to the rule, After Effects has an intriguing way of doing instancing and referencing that's quite similar to how I'm describing it being something that's always available, everywhere, all the time, without the need to think in terms of a library of symbols/prefabs.
You need to free your mind from the convention of a library of prefabs/symbols and realise a project is ALREADY a library of objects, all of which are prefabs and symbols if you so choose, before this will make sense.
Flash was the worst. I'm sorry. But it's regarded as one of the worst platform when it comes to development. Actionscript, was shoehorned into it. It became bloated, and everything was a bandaid. People continued to use it because it was what they were familiar with. So no one is saying it was good because of it's conventions (it went against them)
Unity, you're complaining about. But it sounds like you don't have much experience with it. The prefab system is regarded as one of it's greatest features. And this isn't from a marketing perspective. Their prefab system was around when they were a small 5 person team and it's what drew developers from other platforms (way before they had a marketing budget ;) ). BUT it still worked the way everyone was accustomed to. Plus you can do exactly as you describe with a single line of code "Object.instastiate(prefabname)".
I've used 3DS Max since 3ds max R3 (and briefly used the Dos version before that). I'm quite familiar with the modifier stack. And it stinks. I think Modo does a much better job at it :). (Again, you don't know what you don't know)
I'm also aware of how after effects handles their library (sort of similar how Apples Final cut and motion work). I'm not a huge fan of it, but I can see the benefits.
But I'm just going to iterate what you said to me. You don't know what you don't know. We have a thorough document that describes how this is planned to work. And a lot of what you want is in place. You just don't know yet, because we're not ready to publicly say anything.
I'll give a quick run down of what I'm comfortable sharing:
- You can turn any object into a reusable prefab
- You can spawn prefabs that are not in your scene
- You can modify the original prefab and it will a) overwrite, b) create a new prefab
- You can modify the prefab instance. It will a) Create a unique object, b) Create a new prefab
- You can share prefabs to other users
- You can create a prefab as "public" (bad terminology I know) and other projects will be able use it/view it in the asset library.
You don't know what you don't know.
We got your suggestion, it's in the works. Until you have more information on how it will function it's best to just safe your thoughts. This is information overload for us, and it's a waste of your time. Just wait until it's something you can get your hands on (or actually see in a video or screenshots) then give the extra suggestions.
Deeeds last edited by Deeeds
@Murtaza I do know Modo, so you can stop your snark, again.
I was using Flash for the example for exactly the reasons you mention.
The prefab and the way it works in Unity is a DIRECT copy of how libraries and symbols work in Flash. So you're making my point, for me, again.
Compositions in AE you don't get, you're talking about the library, I'm discussing compositions, which are far more like what we're discussing, which is references, instances and copies... and it's the way THESE three things engage with the Modifier Stack that's pertinent to this discussion.
NOT THE MODIFIER STACK in its entirety, but how it's engaged with the things we're talking about, the virtualising of entities.
The problem you're having is an addiction to the concepts of libraries and prefabs. NEITHER are necessary and that's the beauty and elegance of the frank way that 3ds Max deals with Instances, References and Copies and then empowers their alternations and alterations in the Modifier Stack.
But it doesn't matter, you've made up your mind that the conventions of prefabs are best.
@Murtaza btw, Modo is to 3ds Max as Instagram is to Photoshop
Or thereabouts ;)
For what it's worth (and I know that's not much)...
Prefabbing is to Referencing, Instancing and Copying in a Modifier Stack environment as a cookie cutter is to Foxconn.
I'm not suggesting you use the word "reference", I'm suggesting you recognise the significance of referencing to the power, promise and potential of computing endeavours.
And then find the right words for communicating the processes and paradigms of instantiation, which happens in three distinct ways: referencing, instancing and copying, non of which have real world (physical) parallels.
Since copy has become the universal word for the actions and processes of copying in computing paradigms, that problem has been solved in such a manner it would be pointless to attempt swaying against.
Instantiate is an ugly word, but it's the best word we have for us to discuss what's going on here, until we can find a better, easier, kinder, gently and more practical way to communicate this concept.
Instantiation is done through one of three ways: copied, instanced or referenced. In all cases one thing remains true, an original must have been created. In all cases any later versions of that original can be further copied, instanced or referenced. These are the three means of production in a computer coding environment that are part and parcel of how we’re best able to conceive, articulate and create within computing environments. And all stem from the way memory works and programming languages and operating systems manage it.
Mirror doesn’t sufficiently (or accurately) reflect this process of instantiating references, if you'll excuse the pun, because it's not conveying the fact that there is a NEW thing, only that there is a reflection of a thing. So this is a fundamentally flawed metaphor.
Mirroring, as a metaphor, isn't part of any of these processes, paradigms or principles of programming, nor is mirror a sufficiently capable, accurate or unambiguous conveyance of the capacity being communicated. And it's an impractical metaphor under any circumstances, made far worse by its usage as metaphor in a visual environment. Just because it worked for that moment, in that moment when you were bamboozled for other choices or ways to express these ideas doesn't make it the right choice, or even a good choice.
I'm sure you can see this, if you'll please excuse another pun, because a reflected object has reversed left and right, and is directly, positionally and in every other way only able to be what its master is and does. The reflection can’t control and doesn’t have any influence over the original. So this fails every sniff test of being the right metaphor for instances of a referenced object.
Mirror, however, is good for describing the processes and power of reflecting what's done on one side of a visual creative process and another, or many others. And that's exactly where it is commonly used in computing and creative endeavours. Along with the word symmetry, another useful term for the this kind of digital assistive tooling for creative endeavour.
Mirroring, reflecting and symmetry are words that mean things already, in computing environments.
So regardless of how you came to this choice, it's a WRONG choice.
And changing it doesn't change your program, require anything much of you (there's hardly any documentation needing to be changed) and simply a Find & Replace operation in your code base, for a string that's only used as a label.
For a very small cost you can be far more accurately communicative AND permit obvious discoverability.
But you do need to find a better word that conveys what’s going on and is able to be used later when you have a full instantiation feature set.
Prefabbing isn’t right either because it’s a failed attempt to find an alternative to the word “Blueprint” as it was used prior to Unreal Engine’s scripting, as an assistive to understanding classes.
But the biggest problem with prefabs is their origin in symbols, which are vastly inferior to the way 3ds Max considers all objects capable of being instanced, referenced and copied, to any degree, in any way the user imagines.
Now, for the record, I don’t think “reference” is a good word, either. Reference requires that you understand pointers, because without this knowledge what the word is conveying doesn’t make any sense and isn’t related to the instantiated objects that result from the operation of creating multiple, referenced “copies” of an “original”. So you need to know how computer memory works, how and why C works with pointers and what it means to utilise what’s stored at a pointer in more than one way… which is referencing.
If you don’t know that what’s being referenced is the pointer to the location of the “original” and that (in this way) every “copy” is actually not a copy but just another manufactured and presented reference to the contents of the location the pointer is referring to in memory, then the word “reference” doesn’t make sense.
Similarly, if you don’t think of a “class” as a classification file identifying the properties and capabilities of an object then the word doesn’t make any sense. Here’s a tip, if anyone you ever know struggles with the meaning of class, tell them it’s an abbreviation for “classification file” that clarifies the capabilities and properties of something to be produced, like a blueprint, then they’ll get why “class” is used in the way it is, and have a mental model they can always use to destroy the other potential meanings of “class” that confuse its intent and usage in coding.
I use this as an example to demonstrate that there’s ways to quickly overcome the ambiguity and ridiculousness of programming’s common lexicon.
All joking aside. I appreciate your input. Just want and see what we come up with. The majority of things you brought up we've already discussed months ago. The new ideas I've added as notes. We'll go from there.