Howdy! I only started studying this project recently, so take my comments with a grain of salt.
The only part of your data structure that can't be represented by the new protocol is multiple universes. At the moment, all objects that are displayed on the map must be in the "universe", or object 0. This restriction can be lifted if two things are changed. First, an additional argument must be added to the "Get Object IDs by Position Frame" that specifies which object is the frame of reference. Using the current protocol, universes would appear to "overlap" on the client side. Second, clients must be able to display maps of different frames of reference. Currently, they all default to displaying only objects inside of object 0. This could be presented to the user of a client by being able to click on container objects that contain their own frame of reference. The map would then change to show only objects contained inside of the that object. This extension to the protocol has much wider application than simply allowing multiple universes. Imagine clicking on a star system and zooming in to see the current locations of the planets in orbit. You could set the relative position of ships in a fleet or station fleets in different positions in the system depending on each planets defense needs. I made a back-of-the-napkin calculation a few days ago. I think I found that on a map the size of the Milky Way, 64 bit integers would offer 50 meter accuracy. That's way more than is necessary for the positions of stars, planets, and even ships. What that doesn't buy us is any kind of semantic information. The absolute coordinates of a planet relative to a star don't do any good if you have to click the zoom button 10,000 times to go from the galactic to the system level because the client doesn't have any information about frames of reference. Getting back to your data structure, it's hard to imagine a game where both the velocity of planets and the velocity of galaxies are relevant. JD Marble On Jan 15, 2008 1:42 AM, Jason Wandel <[EMAIL PROTECTED]> wrote: > G'day all, > > Firstly, please indulge me the opportunity to introduce myself to you > all. I'm a work colleague of mithro's. I have taken an interest in this > project since I've been in the process of trying to write my own 4X game > for nearly 20 years. I've had to restart a few times for a variety of > reasons, and with the latest attempt I got to starting on the universe > generator system of it. Mithro suggested that I take that task on within > the tp community instead, and use tp as the engine for my game. I think > that's a good idea! > > So, that's what this e-mail is really about. I'd like to canvass > opinions as to what to include within the universe system and how to > represent it. > > My overall idea of some required attributes and structure is something > like the following (this would look nicer if done with a UML tool > graphically, but I'll limit it to text to save some space and also to > allow you all to insert comments!) - please note that I'm trying to be > very generic here to accommodate a wide variety of game structures: > > Absolute top level is the Multiverse. > > Multiverse contains: > 1 or more Universes > > Universe contains: > 1 or more Galaxies > an identifier > an optional physics engine > an optional list of connection points to other Universes, with a > corresponding format for that connection > > Galaxy contains: > 1 or more Systems > 1 or more Nebulae > 1 or more dust clouds > a name or identifier > position/velocity information for the physics engine > > System contains: > 1 or more Orbital planes > a name or identifier > position/velocity information for the physics engine > > Orbital planes contain: > 1 or more Stars > 1 or more Planets > 0 or more starbases > position/velocity information for the physics engine > > Stars contain: > Colour > Temperature > Density > Stability > Type > Radius > identifier > > Planets contain: > Game-related data (population? industrial items? > shipyards/starbases/etc.? Occupying players?) > Identifier > 0 or more moons > Physical attributes (e.g. radius, density, atmospheric contents, > surface contents, indigenous life forms, etc) > Description string > > Moons contain: > Game-related data (population? industrial items? > shipyards/starbases/etc.? Occupying players?) > Identifier > Physical attributes (e.g. radius, density, atmospheric contents, > surface contents, indigenous life forms, etc) > Description string > > Starbases contain: > Game-related data (population? industrial items? > shipyards/starbases/etc.? Occupying players?) > Identifier > 0 or more moons > Physical attributes (e.g. radius, density, atmospheric contents, > surface contents, indigenous life forms, etc) > Description string > (in other words, starbases are like miniature artificial planets) > > My idea is that individual games be able to specify planet (and moon and > starbase) attributes via the ruleset, along with an identifier as to the > type of attribute required. So, it might be an integer, with a maximum > value. This would be stored in some kind of hash table via the attribute > identifier, along with some mechanism of the game knowing what to do > with the attribute. > > Because not all games are likely to support parallel universe kind of > structures, or even multiple galaxies (the game I've designed does, > which is why I want to go to that level), I'm proposing that the ruleset > specify the top-level that is needed. So, for the RFTS emulator, you'd > just need 1 galaxy as the top-level. > > Parallel to all this is the arrangement of maps. Is the game 2D or 3D? > If it is 2D, is the map wrapped around or is it a flat plane? For > parallel universes, we could make it so you can actually define these > things on a universe-by-universe arrangement, so you can have some 3D > universes, and others 2D on a toroid or sphere surface, or whatever. > > Of course, parts of this are going to be quite complex, while the actual > structure seems to me to be really rather straight forward. One of the > key architectural requirements may be that for the physics engine(s) we > may need to hook in a script or something, rather than defining it all > within the game - so we'd be developing an API for game writers to plug > their modules in. > > Please feel free to let me know what you think of all of this - > including the data structure outlined above. > > Thanks, > Jason > > -- > Jason Wandel [EMAIL PROTECTED] > > I'm going green: whenever I get an idea from now on, I'll have an energy > saver light come on over my head. > That'll keep Malcolm Turnbull happy! > > _______________________________________________ > tp-devel mailing list > [email protected] > http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel > _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
