Now that I’ve got that scroll bar, I can start working on the world some more. There are other interface elements I need but they’ll only make sense once I have something for them to represent.
Previously I attempted to define a thing class and began thinking about the structure of my little text world. I’m going to continue that now.
Thing is the base class of the TextWorld universe. Everything is a Thing. A Thing has physical properties including a text description, links to related Things, a Context Menu, and a link to a behavior script. It doesn’t have to have a behavior script. Some things only do something when you interact via the Context Menu; non-player Things may be able to interact like that as well. A rock doesn’t have a behavior, but a fire does.
Everything in TextWorld is either a Thing or a child class of Thing. The most important child class of Thing is Space. Space defines a region of bounded space. Every Thing is contained by a Space, including every Space, except for the final absolute Space which contains everything. Every Space is roughly rectangular in shape. A Thing can only be contained by a Space if it’s physical dimensions will fit inside of the Space along with the contents of the Space. A Space can be Deformable or Nondeformable. A Deformable space has a defined space in cubic meters and will change it’s dimensions to fit Things inside of it.
Spaces come in many different scales. The first Space contains all other spaces, and is as big as it needs to be. After that, there are Spaces at the region level, that can be used as a sort of ‘fast travel’ or ‘world map’. Then there are spaces for individual outdoor areas, specific locations within those regions, like a particular forest trail or the south beach of a lake. There may be sub-areas that are part of those areas as well. One consideration I’ve had is perspective; to a giant or a fairy, a particular location would be tiny or huge, and they might have their own reference for an area. Especially if I want to include small animals it might be good to have smaller areas within larger ones. In that case you’d likely be able to see everything happening in those smaller areas from the larger area. Of course, from the player’s perspective we can measure a region of observation in the case that they’re in a space that extends farther than they can see. Using that we can determine if they should see the whole beach, or just the area around a particular pile of rocks.
Indoor areas consist of their own spaces. There’d be a space for a house, which takes up a portion of the space in the area it’s in, and inside of the house is a collection of linked rooms. Likewise for a cave complex, or even for an animal’s burrow if you’re the right scale to interact with it.
There’s also smaller Spaces. A container like a chest, bag, or even a table would also be a Space. The dimensions are defined and bounded and they can contain other objects. Any container can contain any container that can fit through its entrance and is smaller than it’s bounds. A bag is a small deformable space, while a chest is a non-deformable space. Both are primarily used for holding small Things. A table is a Space with only a floor, and you put things on it instead of in it, but logically speaking it does contain them, rather than the room the table is in.
It occurs to me as I talk about the Deformable Bag and the Table that any Thing should be able to be Deformable, to some extent. In my original example I had some booths with tables, but in order to sit at a booth you have to deform your body. So, I think every Thing should have the Deformable or Nondeformable tag and properties defining their minimum and maximum extents. It’s mostly for determining how small of a space you can fit through/in. A Table and Chair can contain a Thing of any size, but obviously not larger than the Space that contains the Table and Chair. That sounds good. I was trying to figure out how to get players to squeeze into booths but I think I’ve figured it out.
That gives us a nice clean heirarchy of Spaces. World>Region>Area>Enclosure>Room>Container
Hah, I just had a funny thought. Every living Mobile should have a Stomach space, and when they eat a Thing it goes into their stomach and is digested. I might use that, depending on how much overhead Spaces have.
Spaces are also bounded in six directions. Even if they’re unbounded in a direction, the open space is a quantified boundary, since it must be connected to another space. A room will usually have four walls, a floor and a ceiling. Even a forest trail might be bounded by impenetrable forest walls; or they could be penetratable if I go really deep with the simulation.
After Spaces we have Locations. A Location is a specific point within a Space, but it’s also a Thing. Effectively, Locations are significant permenant or semi-permenant features of a Space. In the Example I used before, the Roaring Turkey Inn’s Pub, the Pub itself was a Location, as well as being a Space, since every Space is effectively a Location in another Space.
Hmm… That was the design I was using, but now that I think of it, there’s little difference between a Location and a Space, since a Location is a defined region of space in a Space. The Pub is a Location and a Space. The Booths are a container for Mobiles, and each one has a Table. The Bar is a physical object but also a space. I was going to use a child object of Location called Exit in order to bridge spaces. A door would be an Exit leading in from the outside and out from the inside. I guess part of the issue is visibility. When you’re in a room in an enclosure you get the description of the room rather than the area the enclosure is in, even if the room is smaller than your sight range. But if a room is containing further spaces as locations, well, you would see all the locations and their contents from the room, just like how you can see all of the locations and enclosures in an area, within your range of sight. I suppose if I include the exits as properties of a Space, and used the Boundaries properly, a Location wouldn’t need its own object type, it’d just be a Space beneath your perspective, becoming a part of the description of the Space you’re primarily in. Of course, if you were in a Location space, you would still see the greater Space around you, it would just say that’s where you were in relation to the overall space.
So I guess I don’t need Locations and Exits as unique classes after all. Though, I might make Exits anyways, since they’re defined things located in a Space. A door is a physical thing, it has dimensions, and you can’t fit a car through the front door of your house. It also has a description of its own, seperate from the room’s description.
Finally there’s the Mobiles. A Mobile is a type of Thing which moves or operates under its own direction. In particular this is the Player, NPCs and Monsters, but also things like a Car, which doesn’t have a will of its own but will keep going on its own if you don’t put it in park.
A Mobile isn’t a Space but instead has an Inventory, which can include Spaces. The Inventory defines things that are attached to or being held by a Mobile. So it could be clothes, a tool, a bag, or in a more exotic example, your stomach, or the interior of our car Mobile. Things specifically being held or ‘equipped’ are given special handling.
A Mobile also has stats that define it’s capabilities. Strength, Agility, and Endurance are pretty standard. Strength measures your capability for exherting force. Agility measures your speed and balance. Endurance measures how much work you can perform before you’re exhausted; what you can endure. In a fantasy setting you might also quantify Magical abilities. I think those three are enough to start with though. A Mobile also has quantified skills. Which skills depend on what’s implemented for the setting, but that could be anything from Swordfighting to Map Reading to Belching. Skills define how good you are at doing something, or if you even know how to do a particular task.
All Mobiles can move, which is why they’re called Mobiles. I suppose there might be some that CAN’T move, but they’d be able to if they weren’t restrained. So, every Mobile has a move speed and a sprint speed, and how long they can sprint depends on their endurance and skills. Some might also have special moves like flight that allow them to access mid-air areas or just go out of reach of other Mobiles.
Mobiles might also have special properties, so they’d have a list of them. Things like Water Breathing, Air Breathing, Fire Breathing, Poisoned, Cold, Flu, that sort of thing. They’d be important for the Behavior scripts to determine what they’ll do in reaction.
I’d like to include a complex body structure tracking individual parts, their properties and capabilities and statuses, but I’ll work on that after I get the basic world set up and working. I’m less worried about punching a midget’s arm off than I am about having a universe in which to do such a thing, at this point.
So, that’s the world I’m going to be building, in brief. Each Thing will also have a Context Menu that you can access by clicking on the Thing’s name in the text. The Context Menu will be populated by both Standard Actions and Context Actions. You can always look at something, but you can only drink from a container of liquid.
Each option on the Context Menu will be connected to a function. Sometimes you’ll just do the thing you clicked on, and other times another Context Menu will pop up from the option, and give you further options. You might click on Gun in your inventory and you’ll get options Examine, Unwield, Put, Fire and if you click on Fire it’ll give you a list of targets in range, as well as the option to fire at nothing. Standard Options will probably be included as methods of the Thing class. Other classes will have their own additional Standard Options. Special Options will be a list of function links, for special objects and items.
Ultimately I want to divorce level creation from the code, so that A) It’s Easier To Make Content and B) I can let YOU THE VIEWER make content. So, I want to make sure I can define objects in something like XML, and include all of the possible options. Ultimately I’d like to be able to make new actions without going into code. There’s always going to be something coming up, I’m sure. That’s long range stuff though, maybe even after I start tracking individual fingers. XD
Anyways I think I’ve figured out the basic structure of Thing and its Children now, so next time hopefully I’ll start coding them, along with the TextWorld visualization, which turns the objects into hopefully elegantly structured text.