Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Addressing overall problems vs specific solutions

Discussion in 'World Building' started by awesomedata, Nov 27, 2019.

  1. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    Seems like you'd be better to post this than me. You've got that nice little "Unity Technologies" tag under your name, so people are likely to give more feedback than something I would post.


    Does performance lag from too many visible elements somehow not "get in the way of editing other things?"

    It may be just me, but I think your "design mantra" should really be updated to be more broad than Unity has traditionally favored in the past.
    Here's my own design mantra:

    "In cases where it specifically relates to the general overall problem you're trying to solve, a specific solution should be considered to be (in some form) a part of the overall solution, no matter what form the overall solution ultimately takes, as 'flow' determines the overall shape of a solution as it grows organically."

    What this means is this: If you have an overall general problem (i.e. "Problems with editing in the editor due to visibility issues"), a specific solution to this problem set should be considered in full as a part of the general solution to the overall problem (i.e. "The specific problems I am having with editing in the editor are x,y,z, and the solution I'm attempting to solve only covers problems x and y, but not z, so I need another leg of my solution to account for problem z, since problem z is still a problem with editing in the editor due to visibility, despite it requiring a different codebase or API to solve for.") This is despite the form it should take. The problem arises when the team for visibility and the team for editor tooling must cross paths (and swords) to decide on who should take on the problem. In the end, it doesn't matter whether the solution for "z" (from the example above) looks more like an editor tool, or a visibility API toggle -- What matters is how does one maintain the flow between solutions most easily? Since this is a visibility API, the "flow" of the solution I pose flows more readily (with less intuitive resistance) into the waters of SceneVis tooling than it would flow into those of editor tooling to me (since those are generally used for scene design purposes, not visibility ones). As a user, I was sure this would be where you guys were headed -- but I guess I think differently than most.

    Following this mantra, if the visibility of anything (in any form!) generally "gets in the way of editing other things" (in any sense of the word or phrasing), be that for performance reasons or any other reason, then a solution (in some form!) should be provided to solve for this problem too, letting only flow dictate both the shape and the scope of that form.

    Beyond this, if you guys are solving for "editing problems arising due to scene visibility" -- what other even more general problems would inevitably arise when following the "flow" channelled from hiding an entire scene back up the chain of workflow to the more general problem of performance (due to visibility) and scene management (also due to visibility) when it comes down to making the editing of both things in a scene and the editing of other scenes more manageable with the powers of visibility at our fingertips? While, yes, there are many possible forms for solutions to these problems, the solutions all have very clear origins. Thinking about designing a solution without thinking about the true origin of the problems and their flow beyond the solution itself is the same as shooting yourself in the foot over and over again each time you take a step. In other words -- you might want to reconsider your aim. :/

    I digress.

    I shared my process because this ultimately leads to solutions that not only are more general and flexible, but also ones that evolve organically while still serving the original purpose of seeking a more general solution to begin with, plus it leaves me with room to respond to new problems that arise that I was originally unprepared for during the designing phase of a more rigid "solution" that fails to be scalable to more general (but still hierarchical) problems by its own design (as you are implying is true about SceneVis). To me, because of this, I consider SceneVis to be a bit half-hearted. I really like the ideas you guys have going forward, but it really bothers me that things appear to still be missing the mark simply because of self-imposed design restrictions. :(

    As an added note:

    This way of thinking, inherently, requires a more flexible programmer (and API) -- but it will make designing your overall solutions loads easier in the end since your entire API will not become dependent upon misguided or uninformed designs (as was the case with the infamous Mecanim and its unwieldy and inflexible state-based API -- it assumed all animation in Unity was state-based, and ignored logic in animation almost entirely, treating it as a "special case", which is just utterly insane). Mecanim thoroughly missed the mark in its API design. It basically ignores everything in a user's mind that is important to game animation in favor of a play button and a state graph (which quickly becomes tedious state-based spaghetti in practice) all because it ignored the general problem of game animation (i.e. animation in an ever-changing logic-based environment) in favor of the specific problem of "we need an intuitive visual interface!", in essence losing its identity and purpose while inundated with its overwhelming ocean of problems to solve. It would've made much more sense if this "ocean" of problems was a hierarchy instead.

    I'm curious to hear what you guys think about this. I might be waaay off the mark here.
     
    Lars-Steenhoff likes this.