stratagus-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Stratagus-devel] AI in stratagus


From: ludo
Subject: Re: [Stratagus-devel] AI in stratagus
Date: Thu, 28 Aug 2003 21:59:44 +0000
User-agent: KMail/1.4.3

Well... it may not be a good idea for unit AI... 
But I think that things are different for global Computer AI. 

It is clear that the current implementation has limitations :  Even with a 
good hook system, AI will still be totally deterministic : computer will 
always react the same way. 

Not much exciting.

To prevent this, we'll have to use shorter AI scripts, chained up together. 
Sequences should be played by the computer in a somewhat clever order... Here, 
we could use hook and a little bit of random to make it take decision...

To give a wide range of computer behavior ( and interresting gaming ), there 
should be enough kinds of action sequence . 

Here we can imagine lot of thing :

        * attack on ground
        * attack on air
        * attack on sea
        * mixed attacks
        * attack via transporters
        * attack with specifics goals ( kill peon, take a ressource, ... )
        * play wired attack scenario ( atomic bomb, ... )
        * build a "wall"
        * build a new camp
        * increase incomes
        * plant some trees :-) 
        ...

These are basic strategy items, for which details will really be different 
from one game to another....
To cover a wide range of situation, some of them should also be tunable 
(number of units to send to attack, ...) 

So these scenarii will need to be more complex than what is achievable today. 
They need ways to ask for units, identify them, give them simple order, 
coordinate all this in a flexible way, recognize failure conditions ( to 
avoid being stuck ...).

What I propose is a way to make these short scenarii configurable and to 
manage their correct execution...
This is what is basically present in NEW_AI, but with the addition of :
        * flow control ( while, if, ... )
        * variables, to identify units, groups, ...
        * acces to C functions
        * subprograms
        * parallelism ( a single task can run many sub-tasks )
        ...
And obviously, all these could use scheme for the syntax...

Le Jeudi 28 Août 2003 18:13, Crestez Leonard a écrit :
> On Thu, 2003-08-28 at 22:35, ludo wrote:
> > NEW_AI only play an immutable sequence of attack/defend schema... It
> > always send units in the same order. It can't actually handle complexes
> > actions (like the transporter exemple ).
> > Writting much more complexe AI scripts would lead to a somewhat smarter
> > computer...
>
> Indeed, perhaps we could add some sort of hooks (what do when attacked
> or, when we can't reach the target).
>
> > For unit AI, the same problem applies when it comes to handling new
> > resources types...
> > I agree that existing actions work fine. But if you need something that
> > is not already existing, you have no way to do it without hacking the
> > source for the engine. ( and if you are not a great coder, that may be a
> > challenge ... )
>
> I think it's better the way it is. we can add all sorts of flags to the
> UnitType struct and change the way units act. Yes, you need to change
> the source code when you add something new, but it's a lot faster this
> way. There is hardly anything scriptable executing per-frame, and it's a
> good thing. Even resources can be configured(currently only wood is
> hard-coded)
>
> > Moreover, if you keep the hardcoded model, the engine will need to
> > provide each actions required by any of the games based on it, or each
> > game will require a patch to the engine...
>
> I don't see any problem with it.
>
> > It really depends on how it is implemented. Simple action can be kept
> > hardcoded ( as move, ... ). In this case, the script will only be used
> > from times to times. Moreover, since the script is kept simple, its
> > memory cost is kept low... Let say 512 bytes per unit... You get no more
> > than 200Ko for a whole game.
>
> I am more concerned about CPU usage. And think that you are talking
> about almost doubling the unit structure.
>
> > I already have such a script engine working. (
> > http://sscript.tuxfamily.org )
>
> We already use scheme for scripting, sorry.
>
> please respond to the list too

-- 
IOT trap -- core dumped





reply via email to

[Prev in Thread] Current Thread [Next in Thread]