On Tue, 26 Jun 2001, Robert Masten wrote: > Has anyone implemented this or have constructive thought before I hurt > myself coding it.... You need to address: a) Coordinates and geometry. b) A scale, either uniform or dynamic. c) Memory concerns. d) Visibility. The first is easy to address -- you need only add the coordinates and know some simple Geometric formulae (distance formula, for instance). The second requires some thought. Do you want the scale to be uniform? That is, does every "square" in your world have the same dimensions, width, length, and height wise? Or can rooms have differing scales? Can one room be wider than another? Is this necessary to represent any part of your system? You might decide that some attribute is uniform, such as the Z scale (every room has the same height), or that no attributes are uniform. How does the system layer to accomplish non-uniform scales? Consider: +---+---+---+---+---+---+---+---+---+---+ | | | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+ | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+---+---+---+---+ | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+---------------+ The final row is the one of interest. We have several rooms smaller than usual and several larger than usual. It ends up being 13 rooms in the last row, while the remainder have 10. Socratically: How do you handle cases where one row, column, or height-index has a different number of rooms because of differing scales? If you make every room the same scale, how do you represent rooms that are smaller or larger than others? If you have an ant's nest and a human house, aren't the interiors both rooms? But the scale is different. How do you accomplish this? Is everything on the exterior in one scale, while interiors act like portals into their own space? (This is a good system, I think. Maybe I should expand on my thoughts about it?) Consideration (c) is one of resources. Consider if it were possible to describe every room by a single byte (it's not, of course, but let's pretend for a second) -- all of the data of a room fit into a single byte. Now you decide you want your world to be small -- 100x100x10. 100 rooms north and east, 10 rooms vertically. Thus you have typedef byte roomType; roomType world_3d[100][100][10]; and we find sizeof(world_3d) ==> 100000 or roughly 100kB. Now consider how sizeof(struct room_data). This might be around 888 bytes for just the members. Our memory usage becomes 888 times greater: sizeof(world_3d) ==> 88800000 or roughly 88MB. How do you propose to address memory consumption? How much efficiency can you trade-off for space? One way might be to add these rooms to 'neighborhoods' and rather than store containment information per room (e.g., which characters are in what rooms), store it in the neighborhoods. This is an efficiency trade-off: you'd need to deal with longer lists of objects and characters, but you'd save in per-room storage. Consideration (d) assumes you desire a player to be able to see in the distance. How do you see if anything's blocking his line of sight? Is there an efficient way to do this if we can't store containment lists on a per-room basis? There are ways to address all of these problems. They're too numerous and long to go into each, here. Anyway, rather than posting solutions I've cooked up, I'd prefer discussion of the issues. Even if such discussion eventually leads to the same conclusions I've come to, it'd be helpful for everyone, I think, to participate in some design discussion. -dak -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST