[Ohrrpgce] snapping an NPC or hero to grid

[Ralph Versteegen]

Automatic realignment would likely break the emulated 'puthero' used
in Siv: Journey of an Egg, but I doubt there are many other games
doing that.

I don't remember anyone opposing the idea, instead, I don't remember
anyone proposing it in the first place!
Oh, actually I just searched my emails, and it turns out that you did
propose switching to pixel-based collision/activation and adding a
back-compat bitset for it way way back in 2006! Really, back then we
did move fast and break things (I notice there's a big dropoff in our
compatibility with games before 2006/2007), and it's over the
intervening years that we've become overly reluctant to make changes.

Changing walkabout alignment would also be necessary to support other
walking speeds (and hence other framerates), so it would be nice to do
that soon.

Incidentally, I've been quite busy with a deadline lately, but want to
get back to OHR dev after this week.


On 12 July 2016 at 04:10, James Paige <Bob at hamsterrepublic.com> wrote:
> Yeah, you are totally right. We should fix it so that misalignment doesn't
> get you stuck. The chances of that change actually breaking a game are so
> tiny, I regret any past opposition to the idea
>
>
> On Monday, July 11, 2016, Ralph Versteegen <teeemcee at gmail.com> wrote:
>>
>> I think it's far better to implement this as a command instead of a
>> script, because we might want to change how it's done in case we add
>> features like pixel based movement. It seems a bit strange to add an
>> argument putNPC, because that's for pixel based positioning, maybe it
>> makes sense to add it to setnpcposition.
>>
>> Also, the fact that everything breaks horribly when things are
>> misaligned is definitely an engine bug. Can't we fix it? I'm sick of
>> treating ancient bugs as features. We can keep the current
>> code/behaviour around (activated by a backcompat bitset), and try to
>> fix things so that if an NPC/hero is misaligned collision detection
>> still works, and it's automatically realigns when moving.
>>
>> On 9 July 2016 at 05:59, Adam Perry <arperry at gmail.com> wrote:
>> > It might even be the kind of thing you want at the engine level. The
>> > original Legend of Zelda allowed semi-freeform movement, but you snapped
>> > to
>> > the half-tile when you switched between moving horizontally and
>> > vertically.
>> > The same thing could work here.
>>
>> We could follow something like that approach (realign both X and Y
>> when doing a movement), but snapping to the nearest tile when you move
>> would probably look quite bad especially if you're not using half
>> tiles. But there's no need; just realign only in the direction of
>> current movement.
>>
>> Aside from that, and thinking about implementing pixel-based movement,
>> I guess the Legend of Zelda system (with full tiles instead of half
>> tiles) has several benefits compared to fully free movement. It makes
>> collisions and obstructions simple: each walkabout occupies/obstructs
>> either 1 or 2 tiles (in the OHR only one tile at a time is obstructed,
>> except for NPC activation which checks both tiles). And everything is
>> basically just as aligned with the tile grid as tile-based movement,
>> avoiding alignment problems when fitting through gaps. You can pack
>> more moving NPCs into a given area (although fewer than the current "1
>> tile obstruction" system). It could be done without snap-aligning,
>> such as making a diagonal step when switching from horizontal to
>> vertical movement.
>>
>>
>> > On Fri, Jul 8, 2016 at 12:56 PM, James Paige <Bob at hamsterrepublic.com>
>> > wrote:
>> >>
>> >> I was talking to RMZ about how to unstick NPCs that get stuck when
>> >> their
>> >> speed
>> >> changes while moving. I know Pepsi has had to do a ton if this sort of
>> >> thing too.
>> >>
>> >> I came up with:
>> >>
>> >> script, snap npc, arg, begin
>> >>   # Kill current movement
>> >>   walk NPC(arg, west, 0) # x axis
>> >>   walk NPC(arg, north, 0) # y axis
>> >>   # reset NPC to current tile
>> >>   put NPC(arg, NPC x(arg), NPC y(arg))
>> >> end
>> >>
>> >> And I was thinking this is probably common enough that it should be
>> >> done
>> >> with standard commands.
>> >>
>> >> Maybe a built-in "snap NPC" command? Or maybe an optional argument to
>> >> "put
>> >> NPC" that can kill current momentum?
>> >>
>> >> Thoughts?
>> >>
>> >> ---
>> >> James
>> >>
>> >> _______________________________________________
>> >> Ohrrpgce mailing list
>> >> ohrrpgce at lists.motherhamster.org
>> >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>> >>
>> >
>> >
>> > _______________________________________________
>> > Ohrrpgce mailing list
>> > ohrrpgce at lists.motherhamster.org
>> > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>> >
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>