Post-jam next steps


What's next?

  • EntityKiller needs to remove joints.
    Posted my first question to the giant Unity.Physics discussion thread on this.
  • Some final 'fun' / gameplay? (see below)
  • Aesthetics:
    • Visuals for sticky gunk?
      I investigated how "screen space fluids" work a bit.  Interesting but more than I want to write now?
      Investigated a couple of assets that could short-cut.  Realised I own one that maybe could.  Tried to hack it in but ended up taking longer than I'd hope.  Maybe later.
      Perhaps use a line renderer for 'string' effect for now? (it's an ECS one)
    • Spider legs!
      Given the "sticky web" theme I seem to be hitting, I feel some spider legs are kind'a required.  (also I love the "playing tiny thing in nature/large creature's space" feel.)
      Maybe animation-based?  Perhaps can use animation jobs to get the legs to place properly?
      I believe I came across an ECS 2-bone IK solution (can't find now).  I'm kind'a tempted to plug that in along with a bit of "move each leg in turn" logic and see if I get procedural animation out ]:-)
  • More Unity.Physics learning?
    • I kludged contact point for my jam approach.  Let's fix that.  (see below)
  • More ECS learning?
    • Don't fully understand the "Chunk" business yet.
    • More knowledge about what results in allocations (some things talking about Dynamic-something saying it might not?)
    • My jam code feels rather 'tightly coupled' atm.  I have a `ICollisionJob` that processes all contacts and filters on certain bases.  My (probably OO design instinct) says I'd rather have a single System that does this and dispatches to other jobs to do their work -- perhaps on basis of which components are present.  The open-source "EntityEventSystem" seems like forum user "tertle" had a similar feeling.  Maybe I can integrate that?

Fun?

What sort of fun was I hoping for here?  The "Connect" theme inspired a vision of webbing so maybe holding the fire button shouldn't "fire individual balls that connect to whatever they hit" but "fire out a strand that is pulled in as you hold fire"?   Maybe when you release fire, it stops drawing in?  A button to fire the other end (to connect things) or a button to release?  What about wishing to draw in some more?   These all seem like valid fun ideas.  Technically (learningly) I guess let's get that "fire and pull" part working first.  Probably fire a single line-rendered strand which, on collision, we swap to N parts to make a rope (using a set "parts per unit length" divisor).

The 'right' contacts (or "it's not who you know, it's where you touch them" !?)

The 'right' way to get contact points probably relates to using a simulation callback -- probably in the `PostCreateContacts` phase.  If I wish to combine this with my `ICollisionJob` do I need to stash it between jobs?

Oh, Unity 2019.1.5f1 (up from .4).  Update time.  Aaaaand a new error:

InvalidOperationException: The NativeContainer JointCreationJob.entitiesWithJointCreationQueued has not been assigned or constructed. All containers must be valid when scheduling a job.

Odd.  Was fine before.  It's merely a job-local `NativeList<Entity>` that I assign in my `Execute()` with a `Allocator.Temp` and dispose at the end to save passing to every call to `entityHasJoint()`.  Is this a bug in the safety system?  Should I bypass it?  Feel there's something in here I ought to be able to do but think I'll report and go with passing it as an argument for now.

Tidied my code and posted as a Gist for now in case it's helpful and to garner feedback.  (pause for family afternoon)

<-PREV | NEXT->

Leave a comment

Log in with itch.io to leave a comment.