Messages

1

Programming / Re: Slow Attack/Movement Speed

« on: June 29, 2011, 02:57:43 AM »

Can you provide a few more examples with probabilistic tick-scheduling?

I will say that there is a limitation in that your tick has to be the shortest possible action. With that in mind, let's set our system as 10 ticks per turn, with "normal" player actions taking 10 ticks each. Let's also define a speed 0.7 "Troll" and a speed 1.8 "Kobold". Time for a race!

Player: steps take 10.00 ticks. Schedule first step at tick 10/0
Kobold: steps take 5.56 ticks. Schedule first step at tick 5/56
Troll: steps take 14.29 ticks. Schedule first step at tick 14/29
The remainder indicates the percentage likelihood each action that the action is delayed one round.

tick 5: RNG 62 - Kobold steps and schedules for tick 10/56
tick 10: RNG 39 - Kobold reschedules to 11/0. Player steps and schedules for 20/0. Note that the Kobold had a 44% chance of going (again) before the player here.
tick 11: Kobold steps and schedules for 16/56
tick 14: RNG 67 - Troll steps and schedules to 28/29
tick 16: RNG 29 - Kobold reschedules for 17/0
tick 17: Kobold steps and schedules for 22/56
tick 20: Player steps and schedules for 30/0
tick 22: RNG 45 - Kobold reschedules to 23/0
tick 23: Kobold steps and schedules for 28/56
tick 28: RNG 28 - Kobold reschedules to 29/0. Troll steps and reschedules for 42/29

So, what we'll seen so far is: KPKTKPKTKP, which is pretty reasonable for the large disparity in movement rates we have.
Where this system really gets interesting is when creatures have similar speeds but one is slightly faster or slower.
I like it because it doesn't seem to have any strange artifacts like slower creatures occasionally going twice before a faster creature and because it isn't completely deterministic thanks to the RNG each tick, so you can't rely on or exploit, say, getting an extra move on every sixth attack.

2

Programming / Slightly OT on OOP

« on: June 24, 2011, 03:14:57 PM »

[quoteIn what world are the bastardised hybrids of java and C++ traditional OOP languages?][/quote]

I'll give you C++ as the poster child for "bastardised hybrid", but Java at least started out as one of the first "pure" OOP languages. I haven't kept close track to what they've done to it since then, but if you wanted to learn clean OOP semantics in the 90s Java was -it-.

Just saying...

3

Programming / Re: Slow Attack/Movement Speed

« on: June 24, 2011, 01:50:37 AM »

Oddly, I was thinking about movement/time systems on my drive home today and am working on the skeleton of a blog post.

My problems with activity point accumulators are:
1) You may need an accumulator per-creature, per-activity capability (locomotion, manipulation, sensing) which can quickly add up given sufficient NPCs.
2) They can often interact oddly with 'rest' actions, or else require complicated algorithms to determine how much surplus activity can be stored before use.

My solution is based on probabilistic tick-scheduling.

Basically, you use whatever appropriate speed applies to an action (may be calculated on a case by case basis) to schedule on which future tick the even will occur, but you keep any fractional tick stored with the event. So, for an action of length "2", a character of speed '1.0' would schedule it for NOW+2 and record "0" as the fractional tick of that activity. Another character of speed "0.9" would also schedule for NOW+2, but would record "0.22" as the fractional tick.
[Note that you can choose to scale speeds so that the player is always speed '1.00' for convenient turn-based play.]

An initial approach might just sort based on the fractional time and execute actions sequentially. I don't like that because it makes an activity of length 2.0 always take twice as long as an activity of length 1.9, while 1.9 and 1.1 occur with the same frequency. This becomes especially noticeable during chase scenes and leads to an artificial importance on doing whatever is needed to 'crack the next numerical boundary'.

A better approach will roll a random probability for each activity with non-zero fractional tick. If the probability is greater than the fractional tick, the activity happens, otherwise it is rescheduled (with 0 fractional tick) for the next round. This can fairly simulate sub-tick speeds within a tick-based framework, and works pretty well.

But wait... this can still lead to statistical weirdness when slower critters get lucky while faster ones get unlucky. Fairness is only guaranteed over a long interval, and unfairness over even a short interval can lead to perceptions of wrongness or untimely death. Fortunately, there's an even better tweak that, coincidently, makes things simpler.

Every tick, generate a -single- probability roll that is compared against every fractional action potentially occurring that tick. This both saves wear and tear on your RNG and guarantees that a faster critter never ends up acting slower than a slower critter. They may go neck and neck for a while, but the faster critter will eventually break away/catch up.

Another nice benefit of this technique is that is allows arbitrary precision in your speeds without requiring arbitrary precision in your ticks... you just need the single probability per tick to be generated with sufficient precision to discriminate between the speeds.