Re: Pingus Scripting Language

[Ingo Ruhnke]

Jonas Bähr <address@hidden> writes:

> It might be useful to give the codeblocks names (and omit in opposition the 
> <function>-tag) and to enclose all this in <script version="..">...</script> 
> as a child of <pingus-level>. 

Could you elaborate on how you want to replace the function tag? If
you just do:

<my-function>
...
</my-function>

It would be impossible to differ a function definition from a function
call.

> The user could call his own function-blocks with
> <call name="nameOfBlock" arg1=".." arg2=".." .... return="var" />
> and if there is a return it is stored in  "var". I know that this is a bit 
> more complex then your currend approach but I think that a seperate namespace 
> for each function-block is nessesary to write a bit more complex scripts.

Seperate namespaces for function are planed and will come the
implementation currently in SVN was just a quick experimental hack if
it would work out at all.

> If global variables are needed, I propose not to declare them outside the 
> blocks (like you do in C) but to import them in the particular block (like 
> php does). Therefore you need a new tag but you can be sure that <script> 
> only got <block>'s as childs:
> <global local-name="localVar" global-name="externalVar" />

Shouldn't be hard to implement, but it sounds however like overkill.
After all this whole thing is meant for very little scripts and
triggers and a few global variables don't hurt there. If somebody
wants to implement something complex he should do that in a WorldObj
and possibly export some triggers to the scripting, but not implement
complicated stuff in the scripting itself.

> You could also add some predefined externals like "MaxPingusToSave"
> etc...

Functions will be easily add-able, so whatever is needed should be
implementable without to much problem.

> In the editor you could place some signal-spots which call named 
> function-blocks (with the pingu-id as argument) whenever a pingu walks over 
> it...

Yep, will come. Triggers are the main reason for the scripting so that
switches and do more flexible things than just opening doors.

> It is also nessesary that you could manipulate the level-geometry
> with the script but I've no idea how to do this best (but as I
> haven't thought too much about that).

Functions exported from C++ can take a whole xml-tree as argument, so
you could do stuff like:

<insert-objects>
 <hotspot>
  <surface><resource type="datafile">
    <resource-datafile>entrances</resource-datafile>
  <resource-ident>entrances/snow_front</resource-ident>
    <modifier>ROT0</modifier>
  </resource></surface>
  <position>
    <x-pos>143.688</x-pos>
    <y-pos>157.332</y-pos>
    <z-pos>100</z-pos>
  </position>
  <speed>-1</speed>
  <parallax>1</parallax>
 </hotspot>
</insert-objects>

To insert an hotspot.

> This becomes even more interesting for a worms-mode. It could be
> possible to generate whole levels with the script's "_init". You
> could have a directory with some of these random-levels like "small
> islands" or "cave" which get only a parameter for the theme and a
> random number (the player can but haven't to set these)

Stuff like random levels are better done on the C++ site, after all
one could need some non-trivial there to check that the geometry is
more or less useable, from an xml-script that would be pretty much
impossible.

> As I've understand you, your script-approach is only a first draft
> and nothing too concrete and you may find some of my ideas usefull
> :)

Exactly, its currently just a little toy to see if this aproach is
useable at all. Real implemantation would have different name-scopes
for functions and block, a lot more basic functions and all other
stuff that is needed and reasonably easy to implement. For everything
that gets to complex to do in scripting, one can also write it in C++
and export it to the scripting language.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: address@hidden 
ICQ:      59461927