Per mod request, continued from [here… ( https://discussions.unity.com/t/685526 page-6#post-3505028 )]( https://discussions.unity.com/t/685526 page-6#post-3505028)
I apologize in advance for the length of this, but please understand that everything I say here is necessary for you guys to hear. This may not all apply to you personally (the majority of it does apply to one of your views though, which are clearly shared by many of your colleagues, and also why I felt the need to write this all out instead of just PMing you). but I would appreciate it if someone further up the chain (who has access to the other teams developing big features for Unity) to put their eyes on this post too.
That makes sense, and it is to be expected. I am glad there is more “behind-the-scenes” going on than meets the eye. However, some of the effects from “behind the scenes” even we can see, and because of those effects, not knowing the “why” is very difficult to stomach when it comes down to business. That lack of “why” we see those effects makes some of us very concerned about trusting our time to Unity. (I’ll get into some of the “effects” seen later in this post.)
I am incredibly glad to see this.
You’re probably the first Unity Team member I’ve seen (outside of the “tech” videos offering up another new “feature” or “system” in Unity that required /having/ to admit the older system it replaced was poor-enough to require a rewrite) to fully put the hubris aside and admit that there is a weakness within the walls of Unity. I’ve seen Unity-Team devs come and go, but I really hope you stick around. Although there is one major point I disagree with you on (I’ll get to that in a moment, since it takes up the length of this post), but I want you to know that I highly-appreciate that you took the time to address the issues I brought up in my previous post without you “stone-walling” me (which seems like it’s the go-to “response” from UT these days). Doing what you’ve done here is the only way progress can ever truly be made so that everyone can start seeing Unity as “cool” again. 
So this leads me to my major sticking-point with Unity’s development these days.
In regards to the input system being in a “beta 2.0” now, I completely respect and appreciate you and your team for incorporating our feedback into your 2.0 design – it really does show in the more elegant design! Because of that, I’ve got nothing negative to say about the input system’s progress (despite it being very early!) since its (current) design really does sound like you guys are back on the right track!
This leads me to my next point – “What is the ‘right’ track?” – IMO, it’s not the issue of whether or not the feature is great in the end that bothers people about poor systems in Unity – it is generally the overall “uncertainty” of the minimum standard of “what exactly IS going to be delivered in the end” that causes me ([and MANY other devs]( https://discussions.unity.com/t/668904 page-3#post-3504423)) to fear the worst about “new features”. This is because the “design” of said features rarely seems to have a solid list of bullet-points for the value to be offered (or a list of possible sticking-points) to us end-users. We tend to be forced to rely on faith that the resulting “great feature-set” will cover our many (also-unpredictable) use-cases for said “new” features. However, because there are NO expecations set – we all have great expecations.
This is a classic case of the problems arising from not setting clear and realistic expectations to those you offer a service to. Now they can say “You didn’t deliver what you promised!” simply because you were never clear (in writing, of course!) about what exactly it was you had promised. They now have a blank-check they can cash at your expense – and get away with it! – all because it was you who gave it to them and told them “write what you think is fair.” lol
Of course most people aren’t this terrible – unless you make them angry.
Here is a good example of how that might occur:
I decide to make a game “with Timeline integration” (to use a real-world example). I want to know that anything I want (or try) to do with Timeline is going to be supported. If there are potential ways to use Timeline that aren’t supported upon its official release, then I want to know before I design my entire game concept around the use of the “Timeline” tech that any important features (such as the “Events” feature shown in various videos) will not be included upon release, and that Unity still needs a serious overhaul under the hood for it to be properly supported. If there is some other internal workflow “issue” that puts the “feature” at risk (such as the internal pipeline being unable to support arbitrary code-execution on multiple platforms at the time of release), then I need to know that it is risky to expect that feature in a timely manner and how long it could take to receive it (and then be pleasantly-surprised if it arrives sooner).
However, in the case of the “Timeline Events” feature that was held back from us for so long – it was actually NOT some deeply-internal, highly-technical, heavily-integrated engineering problems that prevented the release of the “Timeline Events” feature. – No – it was a “design” issue – currently holding it back until 2018.3 now.
This is the kind of thing that happens on a regular basis. Since Mecanim, since the “new” 4.6 UI system, since pretty much everything in the recent years of our beloved Unity to some extent.
That being said:
While I have no issue with “design” being heavily malleable – it is the fact that there is no “technical feasibility study” put out to the general public before you guys “have something to show” – And therefore, many man-hours are wasted all because of the “concept” itself was flawed in some way. And to clarify – the “concept” is not simply a “new input system” but is instead a list of bullet points (considered as a whole) that defines what the “new input system” actually IS – This would look something like the following (which allows for heavy malleability while also being firm as to what it offers (without being specific at to HOW it offers it – allowing a lot of technical creativity under the hood by you guys):
-
Works for both Editor and realtime in-game input detection
-
Should be easily modifiable for new types of input (i.e. VR motion detection as well as gamepads)
-
[RISKS] Has a system for “creating” a custom device type and mapping input for it
[RISKS] -
internal programming to support this may not exist
-
could require some serious development time to deliver this feature
-
might require multi-team collaboration
-
Supports all major platforms’ currently-supported input devices
-
Adds support for a list of device descriptions that can be patched into a runtime game executable to add new types of input support (i.e. adding head-tracking to an FPS game that is currently awaiting a specific device to support it to start being manufactured)
-
Offers the ability to check detailed input chains at once (such as street-fighter’s "press down, down-diag forward, and hold forward for 10ms, then press “button 1” quickly 2 times)
-
[RISKS] Input chains can have “replaceable shortcut labels” that reference buttons/directional-inputs/etc. substituted for other buttons/etc using the shortcut labels (labels are either strings that represent hashes or direct hashes representing a reference to the input slots and controls)
[RISKS] -
possible “development-hell” feature
-
long-term or lengthy “design” processes might risk in it being cut or released prematurely.
-
(etc. etc. continued here, until it stops being technically-feasible in the timeframe alotted to you guys)
Then, once an overall list of “value” and “risks” like the above are assessed and agreed upon by your team, release THAT list of bullet points to the community (via forum post, etc.) rather than as a buggy half-finished “beta” with “features” that were pointless to begin with. What?? The community didn’t want you to waste effort on making it have “replaceable shortcut labels” over larger amount of device support out of the box?? That could have been fixed before you guys wasted the effort in the initial phases and then delivered sub-par device support that the devs themselves would have to supplement on their own (and it could have been “fixed” had we just known about it in advance so that we could speak up about it)!
In the case of Mecanim (which is an even better example of why there should have been a detailed bullet-point list like this first), what about the flexibility of the Legacy system? – Some, even today, would argue that it is better in almost every way. And had a list of bullet-points like this been released prior to Mecanim’s “beta 1.0”, people would have asked “Where is the bullet-point that says “flexible scripting API to allow skipping the internal state machine system so user can implement a custom one?” or “parameters are added via Mecanim visual interface and cannot be added via scripting” etc. etc.?” A mockup showing the visual workflow would have been even better. – The lack of a list of bullet-points and mockups showing workflow like that just means that an expensive, slow, (and, sorry for being harsh, but to many, a somewhat “useless”) system was developed instead of a more robust, lightweight, and flexible system that could even piggy-back a bit off of the Legacy code. The way it was written, it was completely detached and did all sorts of bells and whistles – but very little of what regular users like myself wanted to do with it (i.e. a simple way of playing animations, that could have more advanced features such as blending/state-machines added/removed when I needed them.)
I know this is not your fault, but it does follow your philosophy of “make something first, let users play with it, then refine it if they hate it” – and I hope the above example with Mecanim shows how that is not particularly a great idea sometimes – especially for larger systems (like animation) with many potential use-cases (such as simply posing a character or doing IK/FK or retargeting automatically on non-humaniods, etc. etc. etc.).
The philosophy of “just make /something/ and show it to people” in an attempt to “wow” us while also gathering our feedback on what didn’t “wow” us so much has backfired on so many occasions for Unity these days.
The reason why is that people want something that will fit their needs and not their fantasies – and imagination/fantasy is always prettier than reality – at first. The reality is – Mecanim is a system that is inflexible and obtuse/bloated/slow, and Timeline was incomplete and released too early with its main feature to most (Timeline Events) completely MIA – and it even took away existing features (our Animation Events) with its inception – all without warning! Had the developers in charge listed a bullet-point list with the “RISKS” (written in a candid and considerate way to the game-developers who might use it eventually, with a note about Animation Events being a possibility of removal) that let us know exactly what they wanted to deliver, and where their stumbling blocks are that might eventually make US stumble too, we would be so much more appreciative of their efforts on this feature.
So perhaps you can understand why I am against the “just make something and show it to people” idea and why I feel it is worse than simply a “shot in the dark” approach. After all, it may not matter to YOU that you must rip it all out and start over again, but it matters to US as to how long that “ripping and re-writing” takes because WE have to wait on you (and if Unreal has what we need already, for example, maybe we might choose to instead go learn about that in the meantime, instead of dealing with all the uncertainty of a “new” feature we’re not sure will fill our needs). Sorry to sound so harsh, but it is a fact – The faster you guys can develop a solid design for us, the faster WE can use a solid technology design to speed-up our development efforts. If you are slow to make this technology – then we are slow to use it. None of this stuff is really “future-tech” anymore, and there are people making their own game-engines that are beating us to the punch these days. Maybe you can see now why this “bullet list” I mentioned above to describe the concept to us is a total necessity for many of us! Before you guys even write your first lines of code – I ask that you would pleace make that list, and show THAT to us – with pictures, if you really want to “wow” us – and use THAT to see if it fits our needs, instead making us wait for you guys to finish coding for months just to trash it and try again after a few more months (potentially making us wait YEARS for your revisions to finally make it into Unity properly).
No game developer worth his salt (or your time) will ever ignore a detailed bullet-list of promised functionality (especially when the mockups are solid, and the suggested API workflows are solid and easy-to-understand too). The true reason we beta-test is to check that solidity for ourselves! – we want to see whether it fits our needs! – If you can provide this via a list (instead of after months of wasted work!), we will begin to notice that Unity is progressing fast again and trying to keep up pace with its developers on the bleeding-edge. No offense, but when we “beta-test” we don’t usually care much about squashing bugs for you – We really just want to see (for ourselves) whether your system does what we want (or are expecting) it to do. If you guys have a great idea for an interface feature (i.e. jaw-dropping dragging-dropping of states/button-inputs/input-events/shortcut-labels/timeline-events) that you feel might “wow” us, then draw us a thumbnail or three – and we’ll figure out how well that will work for us in production – and we will tell you if there’s a problem (or if we want something else instead)!
Sure, you might argue that your current approach is a “more-concrete” way of getting UX feedback, and (to an extent!) you’d be correct – However, on a system with a highly-mutable codebase (that could be ripped out at any moment) that users can touch/use but might not be near representative of the same experience in the end (and also has a very-high development-time cost overhead), trading /that/ version of “more-concrete” for a “more-concrete” bullet-list of features that, although they don’t yet have a physical form users can test, the development time-cost is next-to-ZERO at this point, which means, if all of the major points of the design are nailed-down here in “pre-development”, actual development time would be mostly straightforward, and a highly-mutable API/codebase would be mostly unnecessary as long as “concrete” API examples of doing things described in the “bullet-list” are provided beforehand.
Unity’s strength is that we can program our own interfaces for Unity’s API, and as long as the API is good enough to cover any use-cases in the bullet-list (and remains flexible in areas where it could be used for other things), you guys have nothing to fear! API is mostly theoretical, and can be implemented without being literally “implemented” quite easily! After the API is solidified ( “more-concrete” ), then the interface should be fast to make. You want something more visually-fancy, either you guys can add in some visual / functional flair during the “polish” phase, or provide an easy way so that others can implement that “fancy” themselves (via editor-scripting “overrides” or whatever). This is the kind of “more-concrete” I feel people would much-prefer (even if they can’t get their hands on the system until later) – especially since the current version of “concrete” is actually not very “concrete” at all, since even the “hands-on” early-access “beta” experience typically lies about the UX (due to its inherent malleability) – and that’s why the bullet-point list above should never change after it is solidified (and thus it will /never/ “lie”). The desciptions should be as candid and forthcoming about the “risks” and “rewards” each “feature” listed is capable of bringing – and then let users decide on a “final” version of that bullet-list, with all concerns out of the way (and any workflow-mockups necessary to convey the concept more clearly where more heady or abstract stuff is involved. )
Let “beta” really be about bug-testing a semi-user-ready module that runs a much smaller-risk of introducing even more bugs (due to a feature or programming concept having to be ripped-out or change somewhere entirely (especially when this is under the hood!) to fit the “new” version of the maleable UI/UX design rather than the other way around) – Again, Mecanim suffered from this “buggy” state for a long time after its release – and I’d put money on it that this “malleable” process was behind that (when stuff was added under the hood to support user-requested features). Had Mecanim had a list of things that users wanted from the outset, a proper mockup of workflow thumbnails and implementation details (such as showing that parameters were not able to be added programmatically or that using the API to check states was such a hassle, or that adding states via script would be an issue, etc. etc.), users would have been able to “fix” Mecanim before it was ever so hopelessly broken. 
As hinted at above with the bullet-list of features – I feel like this should change.
“Democratizing” game development is only possible where there is enough transparency for “the people” (the heart of the “Democracy” itself) to have a say. After all – if the Unity engineers are the “Electoral College” of the video game development “democracy”, don’t let yourselves be the ones to prevent “the people” from having their final say in how their games are going to be developed.
I feel like we should be the first to know, and the last to have a word on the subject of any major new features.
Who else is with me on this?
I now choose to stick to the more specific threads dedicated to features.