And now I begin to actually make the base classes I described in the last post.
TextWorld
textArea
contextMenu
thing
space
location
exit
mobile
behavior
Hmm, it’s an interesting point that, being objects composed of text rather than images, it doesn’t make sense to make room and thing as inheritors of sprite. Rather, I suppose I’ll make them inheritors of object. I suppose I could make them inheritors of string, though. I wonder what the string class looks like inside. I’ll look that up now…
Hmm, no, the objects will contain strings, but they aren’t strings or some kind of super-string with new features. They’ll probably have many strings, too, so it’s not sensible to make them inheritors of String. I’ll just make them inheritors of Object. String is an inheritor of object…
Of course, thing is an inheritor of object. Honestly I wonder if I shouldn’t make room an inheritor of thing. Thing is the base class of my little universe. A room contains things, but it could itself be a thing, with a location inside a greater thing. Though, I had intended to have exits be locations that bridge rooms. Of course, I already intended things to be able to contain things. In my little screen test, I had a fire mobile in a fireplace location.
Hmm… Speaking from the perspective of practicality, an exit from the interior of a room and an exit into a room will have different descriptions, and there may be more than one exit from an exterior space into a smaller interior space, like a building with a front door and a back door.
But the idea of a room as a thing has caught me. In this way, the great outdoors room can contain rooms that represent individual regions of the world which contain rooms that represent tiny portions of the world which represent buildings which contain individual rooms which contain containers like boxes and tables which contain containers like jars and sacks which contain things!
A maybe instead of room I should call it space. XD
So there’ll be the thing object, which represents static objects in the world, and is also the base class of everything in the world. It’ll have a link to the space it’s inside, it’s dimensions, position, orientation, material, and mass. I won’t be doing real time physics so I can leave out velocity and acceleration.
So what does every object need, at the very least? Well, it’ll need a quick description for when it’s listed in the description of a room, and a detailed description for when you look at it closely. It’ll need a context menu, since everything is going to have a context menu. Which reminds me, I’ll have to make a context menu class. Add that to the list above.
I don’t think a thing will need a list of its contents; I’ll make it so that only a space can contain other things. A container like a bag will be a very small space, and you can’t enter it because you’re too big.
I do think a thing will need a behavior object. Or a link to one anyways, there doesn’t have to actually be one. The behavior will determine how you can interact with it. That kind of makes a lot of fuzziness between a Thing and a Mobile though. Mobiles can move on their own, but that’s just their behavior. Anyways the idea is that each turn, all the objects (or at least, all of the significant and local objects) will run their behavior script, and act as it requires. This allows me to divorce behavior from the physical definition of the object. A thing could be a tool, and when you use the tool it does things. That kind of interaction is sent from the contextMenu to the behavior object. Well, the behavior object will probably be a function object. I’ll probably have a whole mess of functions inside of one big behavior class, and when I assign a behavior I’ll link to one of the functions of the behavior class.
I guess the biggest difference between a thing and a mobile will be the intent, and the colour of the name as it appears on your screen. A thing will be blue, and a mobile either red or yellow, depending on if it’s dangerous or not. Hmm, traps could be dangerous, but they’re definately not mobile. Shoot. This is getting difficult. Maybe I should just make all the things mobiles. Oh! I know. Mobiles have an inventory, which is somewhat different than containing objects, since you’re merely carrying/wearing them. Also mobiles have stats, which aren’t covered by behaviors. Like strength, and agility. A tool or weapon wouldn’t have stats, it has physical properties. I can use a weapon’s mass and a character’s strength to determine the damage. But, they will need additional physical properties. Durability to quantify how intact something is. As well as flags like Sharp and Pointy. I’ll have to come up with the flags as I do development. For now it’ll just have to suffice that there will be flags.
So far:
inside – A link to the space it’s inside
location – a link to the location it’s nearest to
dimensions – l,w,h
position – x,y,z
orientation – xa,ya,za
material – refernce to material enumeration, like wood, stone, plastic
mass – the mass in grams
durability – intactness/health
properties – reference to property enumeration, like sharp, pointy, dull, rusty
shortdesc – short description of the thing for use in the basic space description
longdesc – detailed description including properties of the object
behavior – a link to a behavior function run every turn
Alright! I think that will sufficiently define a thing for my text world. I’ll have to encode that later, it’s getting late and I’m a bit worn out. I should probably set up the interface first anyways, I still need to make the textArea class with its scroll bar. Once I get the thing done, I’ll have to figure out what the subclasses will need in addition to those properties.
Things are starting to get interesting. <3