[Znr4123]

Your right. It is a scripted language. But I use the term language loosely, as each command is really just an index into a table. It is something we created. I don't believe it's similar to LPC.... but I have yet to work much with LPC. So my mind is a little shaky on that. Here is a sample from earlier on testing:

SetVic(PC)
If HasVicTarg
Remain 1 to 1
Else
Return Fail
Endif
If affected(Mob)
Ornot awake(Mob)
Orif Fighting(Mob)
Return Fail
Endif
VicLoop
If pc(Victim)
Andif lvstage(Victim) < Hero
Andif visible(Victim)
Andif lvcap(Mob,Vic) >= 5
NextVic
Else
RemoveVic
Endif
EndLoop
Kill(ListMember)

This is a type of aggressive mob routine. It is triggered by any character comming into the room. The first line obtains all PC's in the room. The first if block escapes the behavior routine (BFUNC) if there are no PC's. The second if block does some basic checking on the mob to see if it should be able to attack. The VICLOOP section loops through the list of PC's obtained from the first line of the BFUNC. The loop eliminates PC's the mob isn't interested in. The "kill(ListMember)" line selects a random PC and attacks. Assuming there is one left. Otherwise it just does nothing. The third instruction "remain". That command keeps the BFUNC in active memory. So the mobile will come back to this routine later and "execute" it again. The numbers are time ranges, low/high values. This isn't really my section of code, but I believe it can be used to randomize when the routine will be activated again. In this sample though, we want it to always come back at the same time. And we want a quick reaction.

The neat thing (we think) is that since everything is mostly table lookup, we are really not adding that much to the CPU load then we would if we put in actual code. In a stock ROM/DIKU style mud, if memory serves, each mob in the mud would execute it's special_* routine every time through the MOBACT. This approach pretty much eliminates that overhead. At the time, we were testing on a Linux box. We like to test on older systems occassionally, so it was a P120. Our mud code running with the old ROM/DIKU special_* type system was hitting about 4% CPU time. With this scripted language approach, we had trouble getting the mud code to break 3%. Most of the time it sat on 2% CPU time or less. This was a test with around 10 users, each issuing 4 psudo-random commands/second. And a full complement of 60 areas. We also tested this with similar constrants, but adding 25 mobs into one room with all 10 players. Very similar results. Honestly, it surprised us a little. We thought it would add overhead with typical use (Though in reality it does). We just weren't too worried about it since nowadays computers are so fast.