Re: [H-rts] project summary, RFC

[Shae M. E. <sh...@Sc...>]

Ian Lynagh <ig...@ea...> writes:

> I don't think the pre-game order writing is any different to the in-game
> ordering. It may turn out that players tend to start the game with a
> portfolio of complex orders that they anticipate being all they need for
> the game, and spend the game just assigning them as appropriate.

Yah, I agree.

> As for orders, we could have something like this:
>
> Trigger datatype, essentially a function of type WorldState -> Bool
>
> onTrigger :: Trigger -> State -> State -> State
>
> With the orders
>
>   --------------------      See enemy unit       ------------------
>   |Go to waypoint foo|==========================(Destroy enemy unit)   
>   --------------------                           ------------------   
>             |
>             | Got to waypoint foo
>             |
>             *
>
> we could have
>
> state1 = onTrigger see_enemy_unit (destroy_enemy_unit state1)
>        $ onTrigger (got_to_waypoint "foo") nostate
>        $ go_to_waypoint "foo"
>
> I don't think this gets us any closer to order updating.
>
> I guess the engine probably wants to work by working out how long it is
> until the next trigger happens rather than stepping time and testing
> them; this will have to be updated every time the user does anything
> that might change it, of course.

I've been reading the Yampa and Yampa continued papers, the arrows over signal
functions looks like a good solution for this kind of problem.

http://www.haskell.org/arrows/
http://www.haskell.org/yampa/

Specifically, it allows functions to transform their behavior with triggers.
-- 
Shae Matijs Erisson - 2 days older than RFC0226
#haskell on irc.freenode.net - We Put the Funk in Funktion
10 PRINT "HELLO" 20 GOTO 10 ; putStr $ fix ("HELLO\n"++)