Message system discussion

[Gleeok]

Gleeok, can we do something like this:

There is a list of game objects (which I will cause Objects, for lack of any creativity) that can have scripts attached to them. An initial list of Objects are
1. the game itself;
2. the screen;
3. Link;
4. npcs;
5. items;
6. weapons;
7. combos (freeform or otherwise).

Each Object maintains
- any number of scripts, each of which can contain any number of callbacks;
- local variables associated to that Object

The game engine, and scripts, can send a message to either a specific Object (via a pointer to that Object) or broadcast a message to all active Objects.
If multiple Objects would receive a message, they receive them in a well-defined order (for example, in the order listed above, with scripts associated to the game getting first dibs, then screen scripts, etc). Each callback returns whether to continue processing the message, or to stop. Each callback runs in its own execution context as described in my first post.

You suggestion to start with just CB_ON_UPDATE and CB_ON_DRAW sounds fine to me. We can work out the details of WaitFrame() and WaitDraw() within callbacks, Object pointers and variables, execution contexts, etc. for just these two basic messages, and build up from there.

As a good jumping off point I was planning on Screen and Global scripts, or "Objects," first then going from there. The first script system I wrote was over-engineered and as a result was crap to work with and use; the second time I learned my lesson and it was much simpler. Forcing scripters to use objects (read: classes, member ptrs, virtual, inheritance, etc.) for everything is not a good start I don't think. Tell me if you think I'm wrong here, but whenever we can do a simple procedural style interop I'd go with that.

The simplest things to add (and immediately support) right now are global callbacks--Link is just a namespace so he falls into that category as well--everything else object related needs a bit of integration into ZC, and npcs need a slight refactoring first. Also doing the bindings and all that junk for them so I'll call that phase 2.

The way I'm doing it right now is this: If a script object defines an instance callback then it gets called, if not then the engine will ignore it. For example:

class MyGlobalScript
{
  int myTime = 420;

  void OnDestroy() { //this callback is defined, so it gets called by the engine.
    //last call for alcohol
  }
}

In this example maybe the scripter doesn't care about it being updated, or drawn, or anything else besides what happens when it is destroyed, so that is fine. It still exists and other scripts can access it the same, or whatever else. Did you have something better in mind?

I don't like the idea that any object can have any number of scripts though, that sounds very complicated and bad. Can you give an example?

Also Waitframes(), contexts, and callbacks are already working. I do need to implement an intermediate pass over preprocessed script code (hopefully without any major lexing) as a next thing I do though. Modifying angelscript is not so easy for certain things, and I wasted a bunch of time in that when I should of just done it separate... :/