haskell-libs-rtstrategy — discussion of a realtime strategy game in Haskell

Re: [H-rts] project summary, RFC

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

Derek Elkins <dd...@ho...> writes:

> Another one you may want to look at is "Functional Reactive Programming,
> Continued"
> (http://www.haskell.org/yale/papers/haskellworkshop02/index.html).
>
> We should be able to steal parts of the implementation with little or
> no effort, but the more primitive parts will almost certainly need to be
> rewritten.

"It should be easy"

I'm not sure where to start though. Any suggestions?
-- 
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"++)

Re: [H-rts] project summary, RFC

[Derek E. <dd...@ho...>]

On Tue, 29 Apr 2003 22:25:22 +0100
Ian Lynagh <ig...@ea...> wrote:

> On Tue, Apr 29, 2003 at 09:12:08AM -0400, Derek Elkins wrote:
> > On Tue, 29 Apr 2003 14:00:17 +0100
> > Ian Lynagh <ig...@ea...> wrote:
> > 
> > > > http://www.haskell.org/arrows/
> > > > http://www.haskell.org/yampa/
> > > > 
> > > > Specifically, it allows functions to transform their behavior
> > > > with triggers.
> > > 
> > > I've just scanned through AFPLectureNotes.pdf but it wasn't
> > > obvious to me exactly how they worked, i.e. whether they
> > > calculated how long till the first trigger or just stepped in
> > > discrete timesteps.
> > > 
> > > We also want consistent game speed on different computer speeds
> > > don't forget.
> > > 
> > > Can yampa give us what we want?
> > 
> > I wasn't really expecting to be able to steal the implementation,
> > just the interface, semantics, and ideas.  Though, if the
> > implementation can be stolen too that would be nice.
> 
> Oh, right. Do you have a suggestion as to what the best thing to read
> is? Or is AFPLectureNotes.pdf as good as any?
> 
> 
> Ian

Another one you may want to look at is "Functional Reactive Programming,
Continued"
(http://www.haskell.org/yale/papers/haskellworkshop02/index.html).

We should be able to steal parts of the implementation with little or
no effort, but the more primitive parts will almost certainly need to be
rewritten.

Re: [H-rts] project summary, RFC

[Ian L. <ig...@ea...>]

On Tue, Apr 29, 2003 at 09:12:08AM -0400, Derek Elkins wrote:
> On Tue, 29 Apr 2003 14:00:17 +0100
> Ian Lynagh <ig...@ea...> wrote:
> 
> > > http://www.haskell.org/arrows/
> > > http://www.haskell.org/yampa/
> > > 
> > > Specifically, it allows functions to transform their behavior with
> > > triggers.
> > 
> > I've just scanned through AFPLectureNotes.pdf but it wasn't obvious to
> > me exactly how they worked, i.e. whether they calculated how long till
> > the first trigger or just stepped in discrete timesteps.
> > 
> > We also want consistent game speed on different computer speeds don't
> > forget.
> > 
> > Can yampa give us what we want?
> 
> I wasn't really expecting to be able to steal the implementation, just
> the interface, semantics, and ideas.  Though, if the implementation can
> be stolen too that would be nice.

Oh, right. Do you have a suggestion as to what the best thing to read
is? Or is AFPLectureNotes.pdf as good as any?


Ian

Re: [H-rts] project summary, RFC

[Derek E. <dd...@ho...>]

On Tue, 29 Apr 2003 14:00:17 +0100
Ian Lynagh <ig...@ea...> wrote:

> On Mon, Apr 28, 2003 at 11:17:53AM +0200, Shae Matijs Erisson wrote:
> > Ian Lynagh <ig...@ea...> writes:
> > 
> > > 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.
> 
> I've just scanned through AFPLectureNotes.pdf but it wasn't obvious to
> me exactly how they worked, i.e. whether they calculated how long till
> the first trigger or just stepped in discrete timesteps.
> 
> We also want consistent game speed on different computer speeds don't
> forget.
> 
> Can yampa give us what we want?

I wasn't really expecting to be able to steal the implementation, just
the interface, semantics, and ideas.  Though, if the implementation can
be stolen too that would be nice.

Re: [H-rts] project summary, RFC

[Ian L. <ig...@ea...>]

On Mon, Apr 28, 2003 at 11:17:53AM +0200, Shae Matijs Erisson wrote:
> Ian Lynagh <ig...@ea...> writes:
> 
> > 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.

I've just scanned through AFPLectureNotes.pdf but it wasn't obvious to
me exactly how they worked, i.e. whether they calculated how long till
the first trigger or just stepped in discrete timesteps.

We also want consistent game speed on different computer speeds don't
forget.

Can yampa give us what we want?


Ian

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"++)

Re: [H-rts] project summary, RFC

[Ian L. <ig...@ea...>]

On Sat, Apr 26, 2003 at 05:55:45PM +0200, Shae Matijs Erisson wrote:
> 
> Please respond with any comments, thoughts, or ideas.
> 
> Basic Idea:
> real-time strategy, similar to warcraft, starcraft, command&conquer, etc
> different in that the player writes the AI for his units ahead of time,  and then uses high level less-detailed controls/commands in battle (or more detailed if you want to write it that way)

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.

> Open questions:
> 
> Is communication jamming a good idea?

This can be ignored for now, of course.


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.


Ian

[H-rts] project summary, RFC

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

Please respond with any comments, thoughts, or ideas.

Basic Idea:
real-time strategy, similar to warcraft, starcraft, command&conquer, etc
different in that the player writes the AI for his units ahead of time,  and then uses high level less-detailed controls/commands in battle (or more detailed if you want to write it that way)


Problems seen in other games:

In starcraft, single units or groups of units will attack enemies effectively committing suicide by running into situations that are obviously deadly

In most RTS games, each of your units in a group will shoot at the enemy unit or building nearest to them, rather than all of them focussing on killing off the most threatening opposing unit at the time. 
Example, a group of units shooting at a building while they're picked off one by one by a single strong enemy unit


Solution:
write a game that has elements of both detailed interactive real-time strategy games such as warcraft and non-interactive programming games like corewars


Planned Features:
'fog of war'

Human player has line of sight and direct control close to hir command center and nearby buildings

Orders can propagate from one unit to another across the battlefield.

Information about the map, dead units, etc can propagate back to the player from units returning from the field


Events:

All events and orders should be timestamped, otherwise insanity will result


Orders:

UI should be a pictorial finite state machine
states should be modes such as
"attack enemy base"
"defend myself"

FSMs can be composed of other FSMs

order replacement should be allowed without needing to restart at the beginning of the new orders
that would require mapping the old to the new, how to do that?

order primitives:
"Stay where you are and do nothing"
"Stay where you are and shoot at any enemy that comes within range"

"Go to waypoint X"

"Build a tank" (buildings need orders too!)
"Build a tank and put it in group 'Attack force' and group 'Team 2'"
"Build a tank
 and put it in group 'Attack force'
           and group 'Attack Team 2'
 with orders 'Attack team 2'"


Units:

spotter aircraft to quickly update the shaded portions of your map, and to see friendly forces, losses, and enemy troops; should these aircraft be able to relay orders? probably not

fast courier units will be important, and obvious targets for the enemy


Waypoints:

there will be global waypoints to use in order construction


Open questions:

Is communication jamming a good idea?


Current plan:

Igloo says "write a command and conquer clone, then we can extend from there"

Darius found an SDL sprite engine written in C++

multi-player is one of the necessary early features, for fun, motivational purposes, effective testing, etc

basic features:
map grid
units

one piece (square? hexagon?) of the grid should have some way to approximate slopes

Unit types have max hit points, max speed, sight/comms radius,
weapon(s?) and special abilities.

Individual units have hit points, velocity, time(s?) till can next fire,
orders.

Buildings are units too.

UnitType should be records so we can get e.g. the hit points of any unit
type with the same function easily. We'll probably need hasFoo functions
for some of the ones that not all types have.

So should everything else so we can add bits without breaking all the
code.
-- 
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"++)

[H-rts] test

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

ping
-- 
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"++)

[H-rts] test

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

ping
-- 
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"++)