Lua, and More
I couldn’t be happier with Lua. The more I read, the more it looks like a very flexible, fun language with a whole lot of thought behind it. I haven’t gotten deep into the C API, but it also looks like it will be decently easy to extend. Everything is handled by what they refer to as a table object, which from my VB background sounds more like a dictionary (matched key-value list structure). Keys are variants, so you can string- or numerically-index them. I suppose you could even index tables with function pointers, given how functions and tables are “first class objects”...I think, don’t grade me on this because I’m not familiar with the term.
The C API is based upon a stack structure. You push stuff like variables onto the stack then gobble them with any number of operations.
For example, to call a function you might do what I’ve written below. Working distantly from memory:
Goal: Call f(x, y) and return the result to z.
Queue x
Queue y
Call f
Pop z
Calling f would gobble (okay, pop, I’m sounding like J-Lo in Gigli) x and y off the stack and queue up the value that I pop into z. This is a bit cumbersome to understand (I recall a duh look on my face for an hour or two when I first read about this six months ago), but once you get used to it things get clearer. I’m sure all languages are really like this, but I’m a youngling (ha ha, Lucas) when it comes to this stack jazz.
As far as getting names and functions to register, there’s a table that is called the environment table. It’s like a root table, where all the system names and types are registered. You just tap into that and add a “sigma” sub-table, or something to that effect.
Almost everything in Lua that’s useful beyond the basic language constructs is provided by a pluggable API, so the actual core language is small. This also means that simple stuff like trig functions are not part of the language core and that the plug-in architecture must be very tight to make all this convenient.
This also means that if they started shipping a sockets layer as a “core library” an extending/embedding programmer (i.e., me) could disable the loading of this library at run-time, customizing even the integral parts of the language for my application and security standards. Very impressive.
Today is a slow day at the refinery, so I’m tasking myself with thinking about containers and getting a solution solid in my mind. I also have the drive home for this. Options, options, options:
- Build containing ability straight into the Object class (base class of all game entities, including rooms)
- Build a separate base class and have everybody co-inherit it or whatever you call it when you have two base classes [everybody will inherit, though. Why not use a base class?]
- Build a separate class Container and allow each class to carry a pointer to a container [bloat, bloat, bloat]
- Forget classes. Code an inventory for Character’s, code a contents for Items, code a floor for rooms
My bloaty option has one core advantage, and this advantage actually highlights why this relatively simple problem is causing me hair loss: If an Item is not a Container, how is it made to not be a Container. Reworded: If an Item has a 0 kg total capacity, is it still a Container?
What bugs me about this is this is this [sic, :P]: in “real life”, meaning life simplified down to Sigma precision, I see things that are containers and things that are not containers. A letter is not a container, an envelope is a container.
Now let me make a fool of myself and throw in a contradiction: a letter folded correctly becomes an envelope. A letter held on both ends is a poor container, but it still is a container. Of course, Sigma precision doesn’t worry about these things. A letter has a 0 kg capacity. An envelope has a 500 g capacity.
Did I just answer my question?
So, it looks like we’re building container functionality into the Object base class. This means we’re giving the Item class a weight property. Character’s and Room’s cannot be contained, but they are all containers. This, my friends, is why we have the Object class below Room, Character [Player, Denizen], and Item. Rooms are really large objects. They have a description like a Character and Item, and they can contain objects just like a bag. Only they have an incredibly high (or infinite, we’ll leave that thinkin’ for later, I’m thinkin’ infinite) capacity.
Dang, that didn’t take long enough.