Unity Systems -- Continued from "Input System" thread...

Per mod request, continued from here... ( https://forum.unity.com/threads/input-system-update.508660/page-6#post-3505028 )


@Rene-Damm

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) 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]
  1. internal programming to support this may not exist
     
  2. could require some serious development time to deliver this feature
  3. 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]
  1. possible "development-hell" feature
     
  2. 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?

 

Heh you beat even my long post Seriously, though, thanks for engaging and sticking with it.

TBH I'm a little surprised by this. Though, well, given how bad we tend to be on the communication front at times, maybe not so surprised. But it is pretty different from the culture I see in Unity R&D every day. Maybe the harshest words Unity gets day in and day out is probably from the people working on it Maybe it's the expletive-laden nature that prevents it from reaching beyond the office walls.

Just to clarify this one... it's not. The current version is 0.0.1-preview. It's not even alpha.

There were concerns voiced internally about going public too soon thinking that it'd give people the impression that we're presenting a "soon to be final system" when it's really not there yet. IMO this is exactly the point. It's not a beta, it's not an alpha. It's in development. But rather than being in development behind closed walls, it's in development for everyone to look at it and curse at it And for us to find people willing to work together with us

Yup, IMO we've been guilty of that on several occasions (and man, over my own programming career I can point at quite a few things that have missed the mark the same way). IMO the only way to effectively combat it is tighter integration with users and faster feedback loops. And I see that being the direction things are veering towards.

I think here we're hitting on a core thing. From our side, the gathering really did happen. We asked around and went around far and wide. We listened to people, we assembled lists, and we condensed requirements. Everything you have on the list made it in there in one form or another. There is an entire thread here in the input forum where "what do you want?" was the question and we went through it post by post (again, only *one* source; we did ask the same question in many other places).

BUT... we did indeed never communicate back out to users publicly. So yeah, I think that's a good point and a missed opportunity. Our final list of requirements stayed internal.

Heh, here I think you're missing my position somewhat. Because that's not my philosophy

As mentioned, we extensively went around to first find out what users don't want and what users do want. And now, with what's there, the idea isn't to let users "play with it" and then "refine it".

We may disagree on this part, but personally I have very little faith in people sitting down and discussing designs and how something should be done. I have never seen anything good come out of that. What I have seen is systems becoming great by starting with "something" based on an idea and then letting real world, actual use determine what works and what doesn't.

To me, that's very different from looking for "like" or "hate" or trying to "wow". If something solves a problem satisfactorily, great. If it doesn't, then you have some real information on what needs to change and how.

TBH I'm not quite sure what you have in mind with the design approach you are outlining. From my own experience, there simply is no going from requirements beyond an initial design without writing code. You can do mockups and thought experiments and diagrams all day long. You can discuss and go back and forth. But IMO, once you implement the thing and try it out in practice, that's when all your nice diagrams and mockups go out the window. In my opinion there is no understanding a problem fully and coming up with a workable solution without, well, trying to actually create a solution.

Again, I think you're really missing my point here. I want engagement and feedback that separates what works from what doesn't, allowing us to get to an end result that works as a whole.

 

Off topic but @awesomedata do you just randomly bold, underline, quote, italicise and capitalise stuff?

I'm a fan of a bit of emphasis, but at this level it seems to be getting in the way: I think your "style" has gone too FAR.

 

@Rene-Damm : My biggest petpeve is that you rarely ever see Unity Employees, heck even the Community Manager come to the General chat and just say hello. I don't expect the CEO to come (which he did come to one of my posts couple years back).. But regular ol' folk working with Unity would be a great thing to have them at least get involved with the community. I love Unity, love the employee's, just wished some, would come chat with us and maybe teach us a thing or two for thoughs of us who think we know it all *Cough* @hippocoder *Cough* ahaah jk lol.

 

There is quite a lot of Graphics and R&D Folks active in the Graphics Related channels (SRP, Lightweight RP, Shader Graph, etc).

 

Posting history of CTO and co-founder Joachim Ante. 6 posts last week. Not at all saying it invalidates your point or anything. Just thought it's noteworthy

 

The SRP and ECS folks have been a very positive exception to a rather... non-communicative norm.

 

@Andy-Touch and @Rene-Damm :Sorry I guess I said what I said in the wrong way. I know you guys are active on the forums. But what I meant was, to come to general discussion, and just chat when you can. Not about business, just to be friendly and be part of the community so we can all be friends, not just another UT Employee that we only talk too about bugs or adding features or why free doesn't have dark theme lol. So what I mean is, lets say we have a discussion about some new type of tech, discussion is going really cool, would be nice to see you guys come in and chip in your opinions on it... This is one big reason I love Unity, we despite at times having arguments on things, we all at the end of the day, enjoy the conversations, and it helps bring us all closer.

I mean I understand why employees don't chip in on the regular discussions going on here on a day-2-day basis. I'm just saying it would be nice to talk about things in general, not specific issues and problems that need to be addressed.

 

Honestly, general discussion is probably the least useful section of the forums. If UT devs are interacting w/ community, the other specialized subforums are probably better time spent.

I mean, it's kinda nice for us general discussion regulars, but still.

Side note: I'm actually very impressed that a Unity Co-Founder is posting detailed technical discussion on a semi regular basis. This alone gives me a lot of faith in UT's future.

 

@frosted that's why I said I understand why they don't. But would be nice if we could all just sit down and talk about anything without always just being serious about a specific topic.

But I do agree with you though.

 

Various Unity employees do interact at times on General Discussion; but perhaps not as frequent as the more specialised threads. I used to interact a lot more there but often would get bombarded by questions that I don't have the position or knowledge to answer. I now choose to stick to the more specific threads dedicated to features.

 

hahaha yeah I remember you jumping in occasionally. Didn't realize people would bother you guys that much. Guess it makes total sense now. In other words, it becomes a customer support job on a place that isn't for Customer Support lol.

 

I do. It's my thing. Don't judge.

I didn't provide a TL;DR version because I wanted a lot of people to complain about how long it would take it to read it and then make them spend the time they could have spent reading wondering what it said instead.

No, seriously though, that was a joke. To be honest, I figured you'd read it only if you were interested. If not, then only the people it was directed at would read it. That was my goal. I only started this topic because (as it says in the first line of the post) a mod requested it be a separate post. I wasn't aiming to get attention from the wider user-base. That said, the TL;DR is that I am just pointing out some issues with things in the Unity workflow that is currently bleeding over to regular users, and directing my questions on this toward people in a position to know (and possibly do) something about them.



Back on-topic now:

Please clarify then -- what I gathered from the "rip it all out and start over again" is that everything is transient and nothing has a clearly-defined plan from the outset -- only an "idea" that can be "played with" and then "refined" as it improves and becomes more solid.

Also -- what "users" do you guys seek what they do / don't want? -- Are these subscribers, or are these mainly the devs / studios that you work closely with who have a deeper or more personal relationship with you guys? At the end of the day, anyone who uses Unity should be considered a "user" -- and not just a select few -- and as such, their ideas should be at least as important (if not moreso) to consider making it into the final product.

It feels like products like the Mecanim system arose from somebody saying "hmm -- I want a system to better blend and layer my animations..." and somebody at Unity replies "yeah, that's a good idea!" and then proceeded to make a giant system that focuses solely on that one task -- while leaving every other part of the current (legacy) animation system (such as scripting flexibility, speed, and overall simplicity) to the wind.

If you guys feel like this is "the right way" to do this, then how can you improve your design process? -- I don't mean to sound rude or mean about it, but Mecanim missed the mark on so many levels, and yet it's the Input System that is being reworked?

Don't get me wrong -- it definitely needs it -- and you guys seem to be doing a great job on it now. But the truth still remains that its "redesign" missed the mark on "design" the first time -- and, as far as I gather, the process the first time is still the same the second time around -- the only change is that you have data telling you where you failed.

Here is my problem with that:

"Data" alone, gleaned from trial-and-error does not help one to see the mistakes before they happen. Yeah, if you already know where you might fail, it can definitely help -- but if you are blind to the dangers of failure, you just keep failing for no reason. Some failures in life are irreversible. It is in this kind of irreversible failure that I plead to you guys to reconsider how you approach your "design" process. As it stands now -- I don't really see how "design" (you know, the kind with intent behind it and not just mindless guessing at what "works" or not) plays any role in the current Unity development process.

Am I wrong for thinking this? -- If so, how do you guys combat this issue?

This is fair, and I can see why you'd prefer this approach. However, my issues with "design" being considered "irrelevant" still stand. There is no intent behind this process, and if stuff goes into the "non-design" (for lack of a better term), it's just what is there -- until a boatload of people complain to the point of abandoning Unity until it gets "fixed" at some point. Maybe. Eventually. This is exactly what happened with the first Input System "non-design" -- it was simply not up to par because of one reason only: The "design" was not actually sufficient for solving all of the problems it intended to "fix" simultaneously.

Now that may not deter you from this way of having "something" first and then doing things based off of that -- BUT that is not actually my goal here. There is nothing at all wrong with wanting to have "something" first, and then working the "design" off of that. The problem comes from that "something" becoming the "design" itself -- and this is exactly what I fear happened with Mecanim. It is absolutely wonderful at "blending animations" -- but absolutely terrible at doing much of anything else animation-related -- at least in the context of video games -- and this is supposed to somehow be "the replacement" system?

Would you please tell me why this sort of thing is not "well-designed" the first time around -- especially when it seems you guys have a seemingly unlimited amount of input and "design" resources at your disposal?

If this "non-design" process (of letting "use" determine design instead of a "functionality" determining design) is a better process for the "design" of software, then I want to know exactly why the "design" still cannot be managed this way?

(Beware, @JohnnyA ! -- EMPHASIS!)

If the "use" determines functionality, and functionality is secondary, then what "use" does anyone have for the functionality aside for the original "use" that the functionality was intended?​

This means that if there is no other "use" for the product you make other than the "use" that was engraved into it from the outset, you have a very limited product in the end -- and that's terrible for game-development and game-design.

That does not sound very "Unity-like" to me...

Now, on the contrary, if one provides a "function" instead, then it can be used in multiple ways than its original "use" was intended.

A flat-head screwdriver was created to be "used" to turn flat-head screws. However, it's "function" is that of its unique form -- a form which enables a thin/hard tip of metal to be used for anything a thin/hard tip of metal can be used for. For example, it can be used as an ice-pick to chip off ice, a way to scrape wood when carving engravings, an easy replacement for a chisel when you don't have a chisel -- or even to turn flat-head screws!

I really hope someone at Unity hears me.

This kind of design is considered "hard" to some, and "easy" to others, but it is a mainstay of great design composition and it is also the kind of thing that is useful in game-development (and even code!) when you start thinking in this way. Yeah, form follows function, but form is also what enables function. And a d*mn good design of "form" will enable a multitude of functions and uses that you never would have achieved (or even imagined!) by simply doing your design based on "use" alone.

Mecanim could have been formed to match the previous animation system's form better, while also being shaped to allow for even better support for animation-blending (which the previous system already had, but Mecanim wanted to do "better"). This would have given it the speed and flexibility of the original Legacy system, while also bringing "states" and nicer (and better "layered") "blending" into the new system design.

Hopefully that above answers your question a bit better. -- TL;DR? -- Many functions/uses with a great design to cover everything as a whole (is greater than) a few functions/uses with a great design for a single function/use.

And considering that the Input System's final "non-design" you're working on seems to match this multi-functionality quite well now, please don't take this as an attack or anything negative toward the current work. I am only emphasizing this to show that there's a better way to approach thinking about "uses" and "functionality" next time -- and despite arriving at the same result with the Input System as what I suggest, the process of getting there could have been better/faster/easier (had this philosophy I proposed been followed first).

Just my two cents.