Re: Game Logic

[Chris Purnell <cjp@oit.net>]

On Thu, Aug 03, 2000 at 06:35:58PM +0000, Pierre Phaneuf wrote:

> Chris Purnell wrote:

> > It's the number of node executions needed to get the job done that's
> > important for speed.  How you've arranged them, tree or list, is much
> > less important.  A virtual machine executing from an array of high
> > level instructions is going to be faster than something walking a
> > directed graph of low level instructions.

> Yes, of course! I was mixing things together when I shouldn't have.

> Higher level instructions is good for execution speed, period.

> A directed graph is good for runtime optimization. The same thing can be
> done with an array of instructions, just slower (moving blocks of
> instructions around instead of just changing pointers).

What run time optimization are you talking about?

I know about pruning constant expressions form parse trees.

If I were writing it I would parse the source script into a tree
structure, then do the optimization.  If I wanted to execute it then
and there I do a tree walk executing using recursion.   If I wanted
to save some sort of byte code for execution later I would save the
nodes in reverse polish order.  Later they would be executed using
iteration and some sort of evaluation stack.

Others may do things differently.

But the point is that the discussion will be based upon the following:

1. Do I want to include the parsing of the script source into my game
or do I want to have external "byte code" compiler.

2. Will the easier to implement iterative solution cause problems later.
Such as stack usage or trying to break out from the execution (eg on an
error).

> Also, higher level instructions generally have a greater chance of
> having complex parameters (Pentium instruction is high level enough for
> that!), so this is longer to decode, and when optimizing you have to
> find out the length of all the instructions before doing the (expensive
> by itself) move.

No, those a low level instructions.  The high level instructions
appropriate for the execution of a scripting language would get
their parameters in a simple and constant way.  Such as from
the child nodes of your directed graph or from the top of an
evaluation stack.

> A directed graph executor benefits a lot from having
> same-sized nodes, but it can shove a pointer to additionnal parameter
> information without copying stuff around or being variable-sized itself.

The same is not only true of virtual machines but of many real RISC
processors.


Anyway this all implementation.  This is something I know about.
What I don't know is what language I should use.  I have ruled
out using an existing script interpreter.  Not only because
their languages don't have the one feature I know I need
(A native vector type) but also because I want to execute
the script in a controlled and secure environment.

What features have people found useful when writing scripts
for 3D games?

How should the scripting language relate to the actual objects
in the game?  I'm of the opinion that any OO aspects of the
language should relate directly to the objects in the game
but how should this be done?

What have people found lacking in the language they've been using
when writing scripts for 3D games?

-- 
Christopher John Purnell  | A friend in need's a friend in deed
http://www.lost.org.uk/   | A friend with weed is better
--------------------------| A friend with breasts and all the rest
What gods do you pray to? | A friend who's dressed in leather

---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: linuxgames-help@sunsite.auc.dk