After some consideration I’ve decided to make my three test worlds as .xml files. I haven’t had much with .xml editors, so for now I’ll use FlashDevelop. It has some code completion that makes end tags and things, so that’s nice.
Anyways, to make something in XML I basically have to do the same as making it in code, I have to make each of the properties as an XML node. Of course, this requires vastly more XML than it does for code, because that’s how XML works. Isn’t that fun? XD
As I go along I’ll be able to expand the parameters as I realize I need them. Unfortunately, FlashDevelop’s XML editor is pretty basic so I can’t add a new child node to all nodes of a type simultaneously. I don’t use XML enough to know how to do that with proper XML editors, and I don’t feel like learning to use a proper XML editor right now. Cut and paste will just have to do me!
At any rate I figured out a lot of the properties over the last couple days, so I’ll list them here for future reference, and make basic ones I can cut and paste in another XML file.
Thing
// Dimensions
length
width
height
volume
deformable
maxLength
maxWidth
maxHeight
minLength
minWidth
minHeight
// Position
inside
x
y
z
// Orientation
xa
ya
za
// Physical Properties
mass
durability
material
properties
behavior
name
shortDesc
longDesc
contextMenu
Space inherits from Thing, and adds these properties of its own
// Dimensions
interiorX
interiorY
interiorZ
interiorVolume
// Boundaries
boundaryNorth
boundaryEast
boundarySouth
boundaryWest
boundaryUp
boundaryDown
// Contents
contents
Mobile inherits from Thing, and adds these properties of its own
// Inventory
inventory
held
worn
attached
// Attributes
strength
agility
endurance
// Skills
skills
// Properties
mobileProperties
Exit inherits from Thing, and adds these properties of its own
// Connection
connection
// Status
blocked
Most of the things that Exit, Mobile and Space will add are methods, rather than properties, but properties are what I need to define the world, so that I can figure out just what methods I’ll need.
Now I’ve gone ahead and made xml formats for those properties. Next I’ll copy them over to another xml file and start filling it with the data for the areas for my thought experiments.
To begin with, I’ll make the Roaring Turkey Inn’s Pub again.
Making references in xml is a little funny since there’s no built in way to do it. I decided to do it by giving each of the objects an id property, and when they reference another object they use the id number. #id1 is the World space. For some of them, I’ll have to go back and fill in the numbers after I do their child objects. This’ll definately be easier when I make a dedicated editor. ^.^
It’s also interesting that when I made the example for the Roaring Turkey Inn, there wasn’t really much of a description for the room. Mostly it’s generated out of the objects in the room. I could probably just do it like that, too. I was thinking of making each of the six boundaries into a Thing, so that if the boundary changes it doesn’t have to change the description of the space. In that case there would be a thing floor and the floor’s description would be used instead. Of course, if I did that, then the boundaries would have to change their dimensions when a deformable space changed its dimensions. I suppose I could do that. I could even make it so that a space automatically changes the dimensions of its boundary Things when its own dimensions are changed, so that they’re always accurate. Of course, not all spaces are deformable, also.
Given that, I’m not sure if a space would even have a description of its own. It’s just a nothingness inhabited by things. Hmm… The more I think about it, the more sense that makes. Interesting!
Alright I’m going to go with that and see how it works out… Oh, here’s a situation where a Space needs a description. When you’re in an area and you’re looking at an enclosure, that enclosure should have it’s own external description which is different from the internal description, because an enclosure typically contains many spaces and you never go into an enclosure directly, all exits from outside an enclosure go to one of its enclosed rooms. If you look through an exit you’ll see a generated description of the room with all the entities you can see inside from your perspective. Hmm… Likewise, a sack isn’t a box with six cloth walls, it’s a sack. I’ll have to make it so that, it’ll generate a room description if there isn’t a description set. Mostly I want to have the ability to change the boundaries of a room without changing the description of the room.
Hmm… This is all really interesting stuff. ^.^
Let’s give this a shot…
From the name property: You are in the Roaring Turkey Inn’s Pub.
From the boundaryDown property’s material enumeration, Wood and Sawdust: The floor is made of wood and covered with sawdust.
The boundaries on the nesw directions have the same material, so: The walls are made of wood.
The boundaryUp Thing is higher up than the player’s character by more than an arbitrary amount, let’s say more than four feet up, so: The high ceiling is made of wood.
Within the same paragraph it lists the contents. It occurs to me that the order might be significant. Perhaps based on location? I could have it list them by location, in a clockwise circle starting from the player’s left, but then the description of the same room would be different if you came in from a different exit. I could do it by a standard position, like clockwise around the middle, but that could get weird. The more I think, I think it would be best to let the room’s creator decide the order. So, they’ll be listed in the order they’re placed in the space. That way, immovable permenant objects will always be in the same order, and movable objects will be in the order they were put there, if the player or annother Mobile moves them.
Hmm, I wonder if I should be using length, width, and height as parameters, when they’re really all length along the x, y, and z directions.
Anyways I’ll continue the example I was working on.
From the contents it begins listing the names of the contained Things, in name/location format. The location is vague, and determined by the relation to the boundaries of the space. A Thing which intersects one of the boundaries is “in” the boundary. A Thing which is within 1cm of the boundaries is “against” the boundary. Things on the floor are given special consideration since that’s logically where they are if they aren’t someplace else, so if something is on the floor and against a wall, it’ll say against the wall. If something is in the middle of the room, it won’t say on the floor. If it’s flying, then it’ll say it’s flying, but otherwise it’ll just be assumed to be on the floor. If you take up most of the space, it’ll just say ‘within’. Also it occurs to me that a space might have a smaller interior than it’s exterior, like a chest or an oven, so I should include that in the properties.
Depending on where you are relative to the middle of the room, the ceiling, and the four walls, it’ll use different but vague language. Objects within another space are either near or on the space, depending on if they’re close to grade in the perspective space. A table, for example, is a flat surface at around 1m in height, so something in a table would be ‘on’ a table. The fireplace is embedded in the floor, so the burning log is in the fireplace.
There is a fireplace in the south wall. Within the fireplace, a log is burning. Near the fireplace is a stack of logs. There is a bar against the east wall. Near the bar are five stools. There are three booths against the west wall. Within each booth is a table. There are hunting trophies against the south wall. There is a door in the south wall. There is a door in the north wall. There is a window in the north wall.
Eheh, the cafe is closing up rather quickly, so I think I’ll take this moment to pack up and head out. I still have to do the mobiles in this little experimental description, but I think it’s coming along well enough.