This probably won't make any sense. It's 4 AM, the day after graduation, I'm dehydrated, and I'm a bit out of it. Still, here it goes.
Okay, this was something I was doing back in January. Wanted to devise a simple scripting language of my own because A) I was bored. B) I'm too autistic for LUA. C) I'm allergic to good ideas. Anyway, I worked on it for a bit and I got something that was sort of workable, although I didn't really have the interpretor set up to handle if statements sanely (or at all). Likewise, the only data types I had were strings and classless objects, so actually dealing with stuff is bizarre. Still, mostly a proof-of-concept thing, and at that I believe I succeeded admirably.
OKay, so I figure that, as is, I can simply re-use a lot of the data manipulation stuff I wrote for the express purpose of reusing when I inevitably rewrote the thing (the functions I'm reusing are mostly tokenization functions and search functions. Nothing big), and then rewrite the interpretor itself (which is rather simple -- it's basically just external function calls. I'm not doing anything really elaborate or cool here). The only problem with this is that all of the object-oriented stuff still has to be handled in the C++ code. I want to at least design the scripting language to have some degree of its own object-oriented... stuff (primarily, because it's completely happy with completely maleable, classless objects. C++ obviously isn't. This sort of ... well, amorphousness seems useful for writing text adventure parsers and language bots). Anyway, while I guess an ultimate goal would be able to write a complete game in this system, that'd be incredibly dumb and I wouldn't do it.
One of the test games people use to show-off their system's capabilities is this short text adventure called The Cloak of Darkness. when trying to write that in my scripting language, I noticed something I needed -- a better way of handling state control for objects (well, also some sort of set math, but that's not really hard to do). Specifically, in the game, you have a cloak. It can either be worn, in the players inventory, or on the coat hook. Worn is the initial state. Inventory is the state it needs to be in to either wear it or hang it up. Being hung up is the state it needs to be in to make this room not be dark (hence the name). One way to handle this, of course, is just with a lot of if statements. if cloak is in the inventory, and if player selects "wear,"etc etc. This, of course, is rather clunky. A more desirable method would be to have some sort of "reaction" code in certain objects that would, at some interval, check object A's 'state,' and update/alter some value, variable, or piece of code in object B.
For example, if the cloak's state became 'worn,' if there's a function member in the cloack object that handles what happens when you try to wear it, normally I'd just have three or so if statements to figure out what state the cloak was in and then what do. I'd rather have it automatically... somehow, like, "switch" which member gets called whenever the state changes. I'd also rather have something inside the object so I have less loopy procedural coding stuff to deal with. If I have it automated and within the object, I can write THAT bit in C++. Just wondering if you guys had any thoughts on existing implementations or other ways to handle this.
One thing I noticed is that, given how I'm setting the language up to work, I can very easily make it so object members can be accessed by, er...well, you can store the name of whatever member you want to access in a variable, and then just pass in the variable for the member-access-code. Same thing works with function calls. In this case, if there were, say, three member which were basically just function calls, I could potentially just have a state-change-reaction thing change some variable, and simply call that variable instead of an actual member.
It's also worth mentioning that I've only written C++ stuff to interpret the scripts. Beyond this, I've yet to do any more direct interaction, which, if I'm going to be embedding these instead of just writing a discrete interpretor, would probably be a good idea.
