compilation fixes

[intricacy.git] / notes / game

Wrench *
Hook @ -
Sprung block S S S S # # #
Wound sping  $ $ # # #
Block with gap  # # _ # #
Pivot  o -
Ball  O

Ratchet:
   S S # _ # _ #           

   $ # \ # _ #
        o -
       /                

   S S # / # _ #
      - o  
         \

                        \ /
                       - @ -
     /      \           / \
  - o        o -
   \ \      / /
    o -    - o
   /          \
#    
 _    
# # # #
   #  



Physics:

Forces try to push entities in hexdirs. Forces can necessitate other forces.
Resolution involves moving each entity one hex in the given hexdir. These
forces can be inconsistent, resulting in nullification or transferral of the
forces. Note that inconsistency is a complicated business, pairwise
consistency not being enough.

Furthermore, we need some notion of equilibrium: a block with springs on both
ends should settle with equal numbers wound on each end. The wrench,
meanwhile, should be forceful enough to wind arbitrarily many springs.

Importantly, forces are always about something moving into a particular hex.
This means that multiple forces acting in different directions must be
inconsistent and will all fail. So we only need to add when there are forces
acting in diametrically opposite directions.

Adjacent tiles can be connected together into 'entities'. This can be
represented graphically drawing a connected entity in one colour, and ensuring
adjacent distinct entities are always drawn in different colours (cf 4-colour
theorem; or maybe 5-colour theorem - see linear time algorithm here:
https://en.wikipedia.org/wiki/Five_color_theorem ). The physics could also
allow non-connected entities, we can't really draw them (requires
arbitrarily many colours) so let's disallow that for now (except for the
uncoloured fixed frame).

Entities which are connected to no spring are fixed in place, and needn't be
coloured; they are considered to form a single "lock body" entity.

One of the tile types which can form part of an entity is the pivot. Pivots
have one-hex arms emanating from them (with colours indicating the
connection). Forces on arms translate to torque on the pivot.

The hook pick acts as a pivot with one arm and user-applied torque. It can
move laterally, but can't apply lateral force.

The wrench is always pushing in some direction. You can reset the direction
only when it's stopped.

Balls are special one-hex pieces which don't experience friction so can
transfer momentum - once pushed, they continue moving in the direction until
they hit something, then push that.

Springs connect two entities in a principal direction. One entity is the root.
The spring never given rise to a force on the root, except when it's fully
wound and is pushed on rootwards. To avoid unpleasantness, a sprung entity
must be rooted by a single spring - although it can act as the root for
arbitrarily many other sprung entities.

Graphical representation of springs: '|' for the root in the root's colour,
'=' for the connection to the sprung entity in its colour, '$' for wound
spring, 'S' for unwound (each '$' unwinds to two 'S's).

   #                     
    = # | $ $ = #      #               
     S         #        = # | S S S S = #
      S                  $             #
       |                  |          

We can also have unsprung yet moveable entities, by having them rooted to
points on linear tracks (which can be part of other entities), represented by
'| - = - |' etc.
                                     
Origins of forces:
    wrench
    turning hook
    wound springs
    ball collisions

Force resolution:
    A force is always actually just of the form "entity E wants to move in
    hexdir D", and a torque is of the form "pivot P wants to turn +/-". If
    there's something in the way, the force is transferred to the blocking
    entity in the same direction. Forces on an arm are converted to torques on
    the pivot.

    We could use something more confusingly ornate, but I suggest the
    following very simple resolution: as soon as two forces act in different
    directions on the same entity, even if the directions are diametrically
    opposed, the piece gets 'stuck' and no motion results.

    So for each top-level force, we cascade down to determine resulting
    forces, watching out that we don't get lost in a loop. The force is
    self-consistent if no entity gets two different forces, and no entity gets
    a force in a direction in which it is fixed. Two forces are mutually
    consistent if the union has this property. With these rules, pairwise
    consistency is enough - so after throwing away first the self-inconsistent
    top-level forces which are inconsistent with themselves and then those
    which are inconsistent with some other remaining top-level force, we're
    left with a consistent set of forces.

    (note we do need to throw away self-inconsistent forces first, or we have
    situations where a silly force can block a non-silly one)

    Problem: this doesn't handle the case of winding springs, where we really
    do want opposing forces not to lead to stuckness.

    Solution: there are two levels of force - player-instigated, and
    environmental. The former overrules the latter.

    So force resolution works as follows: first remove self-inconsistent
    forces; then look for pairwise inconsistencies, and remove any force which
    is inconsistent with a force of equal or greater strength.

    Problem: we haven't handled moving roots.
    Solution: have the strength of a spring decrease with depth in the
    tree of rootedness - which we do require to be a tree.

    Winding springs: during force propagation, a spring of equal or greater
    strength will always pass the force through, while one of lesser strength
    will pass the force through iff it is already fully wound.

    Ball collisions can be the weakest level of force, so they will never wind
    springs but can push other balls and tracked entities.

    A spring-force which is inconsistent should be replaced with a reaction
    force on the root entity, with the same strength, with this then being
    checked for self- and (from the top) pairwise-consistency.

    Hmm. Would be much neater to not have different strengths for different
    springs. Can we avoid it?

    Yes:
        A spring will resist a force on the sprung entity which tends to
        extend/compress the spring, unless the force is player-strength.

        For remaining forces: a push/pull is transferred through a spring iff
        the spring is at minimal/maximal extension or the spring is at an
        angle to the force.

        A spring not at its rest-length will generate a force on the sprung
        entity. This never yields a force on the root.

    Problem: pairwise consistency *isn't* enough.
        e.g. consider a line of interlocked sprung entities with compressed
        springs, such that the springs must decompress together.       

        Consider this as a SAT problem, where we favour certain answers?
        No.

    Another problem: colliding entities.
        If two entities are forced to move into the same hex by forces of the
        same strength, we need to decide what to do. Currently I think it
        would be better to block them both, rather than to introduce some
        arbitrary rule to decide which gets precedence. The idea would be that
        the gridded nature of the lock isn't just an artifact of our discrete
        physics simulation, it's part of the underlying architecture of the
        lock itself.

        However, this does mean that checking for consistency is *not* simply
        a matter of inducing forces and checking for multiple different forces
        induced on the same entity. Actually it wasn't anyway; pivots can
        break that too.

Reworking:
    Forget "strengths". Instead, we split into two phases: player-generated
    movement, then environment-generated movement.

    Player-generated:
        Hook and wrench forces are considered equal, and can block each other;
        the hook never gets pushed around by the wrench.
        Springs can be stretched and compressed freely within their limits.

    Environment-generated:
        A force on a sprung block is blocked if the spring's length isn't such
        as to be generating the same force.

        Allowing moveable pivots other than the hook results in unpleasantness
        when forces and torques combine. So only fixed pivots are allowed.

        (alternative would be to allow pivots on entities, but consider them
        'locked' when there's a force on the entity, so any torque is blocked)
    
    Blocking:
        note we still need to have forces propogating beyond a blockage to
        block other forces - otherwise we easily get strange loops of the
        "blocked iff not blocked" sort, leading to unintuitive complexity.

Detailed force resolution algorithm:
    (to be run first for player forces, then for environmental forces)

    Unoptimised version:
        For each source force, propagate:
            neighbouring entities get pushed,
            neighbouring pushed arms induce torque on the pivot,
            springs transmit forces where they can't absorb them.
        
        Record with the propagated force the sources which gave rise to it.

        Look for blockages:
            forces on fixed objects
                (player objects are fixed during environmental stage),
            environmental forces on sprung entities not according with the
                spring length,
            multiple forces in different directions on the same entity,
            collisions;
        in each case, mark the source forces involved as blocked.
        Blockedness of a force is irrelevant when determining blockages.

        Enact all forces with at least one unblocked source.

        A ball which pushed something loses its momentum; a ball with a
        resulting force gets momentum as well as moving.

        A wrench whose force is blocked loses its momentum.

    Optimising:
        Just check for blockages while propagating.
            
        Could try to avoid propagating the same force twice from different
        sources, but it would be more complicated than it's worth.

Problem:
    This algorithm doesn't allow for gearing of the kind I'd envisioned.

    Idea: split the concept of blocking into two: blocks and locks. A blocked
        force is one which is "immediately self-inconsistent", e.g. which
        pushes an entity against a fixed object or in a direction in which it
        is fixed. A lock involves another object or another force or spring
        tension. The idea then is that when a pivot turns, its arms try to
        push against things in the obvious direction, but if that's blocked
        (as opposed to locked) they try in the next-to-obvious direction
        instead.

        Quite intuitive, and shouldn't be hard to implement.

        DONE

    

Architecture:
    Board state consists of:
        list of entities:
            type (hook, wrench, pivot, block, ball, frame)
            shape
            position
            springs:
                root entity and position
                direction and natural length of spring
                position on current entity of connection
                    (redundant, but included for debugging)
            momentum
    
    The force resolution algorithm above simply maps states to states.

Remarks on unintuitive results of our algorithm:
    Forces which seem like they should just "cancel out" can nonetheless block
    third forces due to collisions. e.g. all three forces are blocked in:
      # $ # /
           o   # $ #
      # $ # \
    . One could imagine trying to delay or renege on the blocking of the
    rightmost force. But this isn't straightforward; e.g. consider a setup like
    the above whereby the pivot turning clockwise propagates to another
    mismatch which should cancel out the bottom force, while similarly
    anticlockwise should cancel the top force.

    Generally, having forces block forces from blocking other forces opens a
    can of knotted ouroboroses.

    Concrete example: consider three pivots and a force on each producing
    anticlockwise torque, and set things up such that an anticlockwise torque
    on a pivot propagates to clockwise torque on the next. Then if we want the
    rule to be that balanced forces don't propagate, we find that the forces
    are balanced iff they're not.

    So balanced forces must propagate - which means we're bound to get the
    kinds of unintuitive nastiness exemplified in the diagram above.

    So I should switch to trying to make it seem intuitive.

    Actually, there may be another way, which is to take a hint from CD
    as to how to cook those ouroboroses: when we get cycles as in the above
    example, consider something balanced if it's *ever* balanced as we go
    through the cycle. Would this lead us to surprising consequences with
    pulses and latches?

    Yes, it really would, just like in CD, only more surprising and harder to
    think through. This can't be a good idea, can it?

    Alternatively: work monotonically - once something is balanced, it remains
    balanced.

    So in other words: we use the current rules, but mismatches don't block.
    once complete, we look for mismatches - multiple forces on a piece. If
    there are any, we mark those pieces as 'balanced' (better term?), and run
    the algorithm again; balanced pieces just resist any force. Iterate, only
    adding to the list of balanced pieces, until we settle.

    One thing to consider: what should happen when a force on a piece
    propagates to some forces, one of which balances out the first force?
    Wouldn't it be perverse to have that propagation nullified? So we should
    say that it takes two differently sourced forces to cause a balance, and
    one-source mismatches just lead to blocking as currently.

    Simple enough to implement, and fairly intuitive in conception. Does it
    lead to any pathological results? How unintuitive is a force which is
    balanced out nonetheless having its propagands balance other forces?
    Answer: at least as unintuitive as the behaviour which motivated all this.
    Hrm.

    So a CD-style "iterate until we loop" algorithm is the only one I
    can see which would lead to reasonable behaviour - the problem being that
    it also leads to a kind of complexity I was hoping to avoid. Hrm.

    Not only that: at least in any way I can see it working, it would *still*
    involve forces propagating beyond a balance having an effect, due to the
    latch effect.

    Note that the results of actual physics in these sorts of situations would
    involve the finite speed of force transferal - which is something I
    *really* don't want to be part of the game physics.

    OK, so the current "quantum" physics stays.

Thoughts on representing blocks in the SDL client:
    Draw every blocked (as opposed to instantly resisted) force. For
    pivots/hooks: draw dimly arms in partially-rotated positions. For
    blocks/wrenches: draw dimly shifted to the edge of their hex (when not
    already drawing to the edge).

Tool resistance:
                                                 /
    Currently, the wrench can't move east in: - o
                                               * \
    This is kind of counterintuitive. Similarly with a pushing hook.
    But if we allowed wrenches to turn cogs like this, while keeping with our
    simple 'momentum' setup for wrenches and our current resistance mechanics,
    it seems we would have to have a wrench resist all pushes not in its
    current direction of motion, which means we lose the neat current mechanic
    of being able to stop a wrench by pushing it to one side.

    But on consideration, this is the lesser evil.

Spring oddity:
    Following are stable:
        # $ $ # s s %
             #   % %

        # $ $ # s s %
               # % %

    and so on. Complicated solution: bring back spring strengths.

    Simpler solution desired!

    Maybe not simpler, but neater: work directly with the porder of the DAG of
    connections. A spring source-force dominates any source-force on an
    ancestor of its root. Say "latter force *> former force" in this case (not
    that it's transitive) we should see that we can't have x*>y*>x.

    Indeed: if F:r->e and F':r'->e' are spring forces and F*>F' and F'*>F, then 
    e' >= r > e >= r' > e' (porder of connectivity), which is a contradiction.

    A sforce with source F can't block any sforce whose source dominates F.

    Note we're left with some arguably surprising cases, e.g.
         # $ $ $ #   #
        #           #
               % # # 
        # $ $ % s s #

    But that makes a kind of sense if we think of the right piece wobbling
    leftwards... I think it's fine.

    Implemented.


Rethinking the physics:
    I think we took a wrong turning in trying to work one force at a time.

    Rather, we should fully propagate each source force, and then look for
    conflicts between the forcegroups. This seems to simplify many things,
    and make multispring less problematic.

    Propagation: sources and propagands are allowed to be ordered lists of
    forces; if one fails, the next is tried; if all fail, the source/propagand
    fails. Recursively propagate out; a force fails if it is resisted or if
    one of its propagands fails. No need for special 'mediated resistance',
    nor for partially compressed springs to convey forces.

    Then check for pairwise conflicts between forcegroups:
        mismatches (different forces on the same piece)
        pairwise collisions (applying each forcegroup to the initial state)
    using domination rules to determine resulting blocks.

    Implemented.