User:Yosh/Musings

this page is mostly comprised of musings and reflections on resonite's current design, both technically and from the perspective of an end-user, as well as various things that I (and some of my friends) personally think can be reworked in a (potentially) better way than they currently are. this isn't meant to be an "I know better than the dev team" page. it's meant to be a relaxed environment to thoughtfully analyze and experiment with how resonite can potentially be improved for the greater good, and to get all these ideas I (and my friends) have had in one written-down place rather than ephemeral conversations with each other. some of these might make sense to make github issues, some might not

resonite as an IDE

inspectors

right now, inspectors feel like a barebones window into the state of the world. you can update the state by adding, changing, or removing things, and there's a few niceties for copying values, driving fields, and showing the slot that a component is attached to. however, that's about where their extensibility and feature set end

I (and my friend who originally brought this to me) feel like they could be a lot more than they are right now--rather than mirroring unity's style of "inspecting", they can become an "ide" in their own right to work on the complex, interconnected system that is the world.

when thinking about components as a language in their own right, and resonite as the ide that encompasses said components, a lot of ideas come to mind:

• being able to find where elements are referenced
• being able to "search" for a particular element on a slot--whether it be a field or component name or type
• auto-suggestion of potential relevant components when dragging fields
  • said friend, bree, is making a mod for this kinda thing, but it's pretty in-progress
• finding where things like dynamic variables are used and whatnot

and probably more that I'm not thinking of

protoflux

as for the side of protoflux, some inspiration might be able to be drawn from other node-based interfaces (dreams, lbp, blender). when it comes to ux, protoflux is severely lacking in a lot of areas. some of these are known about and done to death:

• searching for nodes (solved by many mods)
• the general inefficiency & opaqueness of the current node browser (known by froox & co. and wanting to improve)
• the separation between values/objects/references and how it relates to frooxengine's data model (more on this later)

but there's some areas that haven't been talked about in the public sphere as much:

• contextual/searchable suggestions during creation of nodes
  • if you pull out a float3, automatic suggestions of things like "dot", "unpack", etc. operations. or perhaps a little searchable pane line what blender does
  • bree has made a mod for this too

debugging

everything should be debuggable. like, everything that has some possible effect on the world should be debuggable. there's some low-hanging fruit for this right now:

• everything that has some player interactability to it should have debug visuals, including but not limited to:
  • joints
  • snappers
  • sliders
  • buttons, i.e. everything that might trigger the button at once
  • receiver surfaces
• spatial variables

interestingly, the tutorial has visuals for snappers and sliders, but there's nothing like that in-game for debugging purposes.