[Hajo]

Lex/Yacc (or Flex/Bison) really are incredible tools for helping in compiler and interpreter creation. You can focus on the syntax, and the code production/interpretation, and all the tokenizing and parsing is done by these for you.

A physicist once said "We stood on the shoulders of giants", when asked about a recent success. Don't start at the bottom. Use what the people already created, and then build something more on top of that.

[tcaudilllg]

OK I've definitely come to the conclusion that this system is WAY non-portable to any language which does not permit variable length arrays of arrays. The reason for this is that it does not place an arbitrary limit on the size of an NPC's script, therefore using 2D arrays of determinant length is stands to be wasteful. As such, either variable-length arrays or member arrays of object arrays are necessary features for languages which host this system. Although workarounds are possible, they are WAY mind bending and NOT recommended.

Variable length arrays are very important to the creation of a flexible GCS. In a GCS, you have a collection of NPCs, each of which has its own script. To process these scripts, they must first be parsed. It is preferable to parse scripts before the game loads, or else the game may bog down under the burden of processing the script. Instead you want to have all these scripts tokenized, even compiled, before the NPCs are loaded. (or, in the case of a real-time script, before the updated NPC is loaded). Actually, there is no real issue with loading NPCs that have a limited number, because then you can just loop through a set of predefined arrays, one for each NPC pre-provided for. ZZT did this, I think, as has most every other NPC scripting system ever made. But as this GCS places no explicit limits on its NPC counts, we don't have the luxury of predetermination. So you might want to think twice before trying to implement this system in a procedural language.

In the interest of portability to procedural languages, I had been doing workarounds. For example, I had been stocking all the tokens for all the NPCs in one array, and the line beginning/end points in another array, and was using tracking variables to keep track of both. I was a serious cerebral exercise about on par with BrainFuck programming, if maybe a little more productive. But I don't recommend it. I have determined this level of portability to be unnecessary, and am redoing the scripting system using variable length arrays.

[toturi]

[Hajo]

[tcaudilllg]

Using Javascript-specific features, I turned this:

[tcaudilllg]

OK I've got the inventory system done... now for the actual integration of the script... (this is gonna be a bitch... always is).

[tcaudilllg]

The script system is proving quite a complicated beast. The main complication is the event system. The approach I'm taking involves processing the declaration of an event and immediately after the declaration, looking up its subroutine for later reference. It's just too slow to search for the subroutine every time the event is called. (though for completeness' sake I'll probably do a slow version as well).

Events use the BASIC "ON" keyword:

[Hajo]

[tcaudilllg]

Yeah a linked list is what I'm going to have to use.

[tcaudilllg]

OK here's what I've got so far:

• at runtime, all the events that an actor is capable of are read into the actor's data structure.
  
• as events occur which involve an actor, they are loaded into its queues. The actor has a queue for each type of event.
  
• At the beginning of every cycle, the queue for an actor is read. The queue contains a reference to a pointer table which contains the index of the involved actor and the index of the event as it lies in the table.
  

The disadvantages of this method are the overhead of managing the actors. I'm thinking of just getting rid of labels and doing it the VB way. That way it would just be a matter of queuing actors and running through the list every time, jumping to the subroutines registered to each actor in the queue. But I still need the indirection table regardless, otherwise it becomes impossible to delete actors without collapsing the system. Although, you could argue that actor deletion in unnecessary as well, that the designer should have a plan for the entire scene.

Maybe what's needed are actor identity libraries, which load actors into pre-declared slots.

Change vs permanence... which to use...?

[tcaudilllg]

After contemplating the situation for a week, it would seem that either approach has definite downsides. The "slot" system has the downside of being very unwieldy: no matter what, you need an array index for every actor on the board PER actor. So if I've got a thousand actors on the board, that a million array indices just for the actors. Talk about a memory hog.

The other route spares memory, but is very CPU intensive: it requires looking for a match in the event tables for each actor in the queue. Actually, this is probably the best technique to use all things considered, because it allows the user to more easily manage the complexity of the interaction system: to support more actors, use fewer events; to use more events, use fewer actors.

I'm kinda surprised though: despite our advances the potential for a truly vibrant world with thousands of independent actors remains out of the reach of consumers. (not counting MMORPGs, of course) It would seem that the PS3 generation has mostly obscured this fact by putting emphasis on graphics and realistic physics involving only a few elements, which combined with focuses for the player's attention distracts from the essential simplicity of the situation in-game.

[tcaudilllg]

I've wrote a parser for BASIC code (in Javascript). I'd like you to check it out and tell me if there is anything wrong with it. Right now it does commas, string quotes, line extension characters, and whitespace trimming.

[tcaudilllg]

Did a little more polishing...

[Verious]

I would recommend using Regular Expressions to trim/normalize whitespace. It will greatly simplify your code and improve performance.

[tcaudilllg]

I implemented the parser (it's not the fastest thing ever (if you use lots of whitespace), but for now functional is enough) and tested it. It works fine.

The actor system provided a unique challenge: I had to first parse the code, then rearrange it. First I used the parser to sort the code into lines, which were defined by pre-parsed tokens. I then divided the actor scripting language into two parts with distinct semantics. The first part modularized the code by looking for commands that indicated the beginning and ending of modules. There are two kinds of modules, actor modules and event modules. Event modules are always contained within actor modules and define the relations between actors. At the moment, there are two events defined, "talk" and "contact". However, I intend to implement a "line of sight" event eventually.

When events occur, the 2nd part of the language is invoked to actually perform the tasks which carry out the effect of the event. I was very surprised that I needed to create two semantic processor functions; however, I needed different command sets for completely different purposes: it was necessary to modularize the code before working with it, which required the use of two completely independent systems. In essence, the language I have defined is two languages, not one.