As it all starts, I've got an idea for a game-cum-simulator. I have virtually zero compilable programming language experience, instead getting into VRML, &#106avascript, and PHP because I'm basically an impatient sod who likes to write something, refresh browser, critique, re-write, refresh browser, etc. The basic idea is simple, but even a simple set of rules can lead to a complex system. :) It's a persistent universe, explorable and interactable. That's the basic idea. There are (in order of size, from biggest to smallest) galaxies, solar systems, stars, planets, moons, cities, towns, buildings, trains, cars, people, pets, and appliances - and I think I should stop at appliances before it gets ridiculous. The scope of this idea could be huge, but I don't want to start working on the Big Idea because I know that's impossible for me at this time. What I want to start working on is the basic framework that all this is glued together with, and the biggest obstacle I've seen in other games was the co-ordinate system. In nearly every game and 3D modelling environment I've touched and played with you have the Point of Origin, a 0,0,0 xyz place where everything is placed relatively to, and you're limited by the number system used, e.g. 16bit, 32, 64, etc. I think I may have come up with a solution to keeping the numerals small while still allowing for a huge scope of field, and I'd like the opinion of any programmers out there. Instead of having a single point of origin and relating everything to the universe to that, I've been thinking it might be better to have a Parent-Child Relational system, and I'll try to explain what I mean. In our own solar system (to keep the example small) the Sun is the parent, and Earth is the child - distance, 1 au, revolving at a certain speed I'm not going to look up right now. The point of origin is Sol, and Earth is constantly moving on a path that is pretty much set in a circle 1 au from that point. The Earth has many children, so it becomes a Parent and to us it becomes the point of origin for where we are (I am at a longitude and a latitude, as is my house, and where I work). So when travelling through a solar system, the central star is the PoO. Moving to a planet, moon, or space station makes that the PoO. Now, to express that relational system, I might say "Earth is +1 AU (1x,0y,0z) from Sol-PoO, Mars is 2.5 AU (just for instance), Jupiter is..." and they're relevant while I'm in space in my ship (at 54 AU, heading to the moon - PoO Sol -> Earth 1 AU, PoO Earth -> 600,000 km Moon. So I'm heading into our Solar System and my ship is at a set of co-ordinates related to Sol. As I approach the Moon, my ship's point of origin shifts from Sol to Earth, then as I land on the Moon, Luna becomes the point of origin. "But how does the engine know what to load so you can see where you're going?" I hear you ask. I think that would best be modelled by the relationships between orbits and size. Luna orbits Terra, which in turn orbits Sol. If my point of origin, i.e. my orbital parent, is Sol, then it's child, Terra, is rendered using a low Level of Detail, and Terra's child, Luna, is also rendered at a low LOD because it is a large spacial body. As my point of origin shifts from Sol to Luna - briefly passing through that of Terra but not at a close enough distance to increase the LOD - details on Luna are rendered at gradually higher levels of detail (perhaps based on this thing I read today about using noise and fractals to render in real-time spherical terrain, with the occasional modelled landmark thrown in). When I land on Luna, my suited pilot steps out of his craft and on to Luna's surface, and his point of origin shifts from the ship to Luna itself. Pilot (at Bridge of Ship) is on Ship (at 54 AU from Sol), heading towards Luna (at 600,000 km from Terra, 1 AU from Sol). Engine renders Pilot, Bridge of Ship and whatever of the ship is visible through the windows, the distant grey dot of Luna and Terra, and the bright dot of Sol - all dictated by LOD. As the ship co-ordinates approach Sol and come close to that of Terra, the LOD of Terra and Luna are rendered at a slightly higher level, as is, of course, Sol. But what about the actual co-ordinate system? On Terra we work with compass points, longitude and latitude, altitude, distances measured in metres, and velocity when we're travelling comparatively large distances, but as far as I can tell the best way to translate this into a scalable system, or at least scalable outside the realms of a house or starship, would be to use just Altitude, Longitude, and Latitude. Sol, being Point of Origin, would have a child of Terra, altitude 1 AU, longitude, and latitude. Those three co-ordinates would exactly describe where Terra is at any given point in Time - with time being expressed as a constant, and motion being described as changes to altitude, longitude and latitude over time. While we too are in orbit of Sol, or at least floating through space outside of the influence of Terra or Luna, we also have co-ordinates based on altitude, longitude, and latitude as they relate to Sol, and the engine need not bother itself with rendering Terra or Luna as anything more than either a dot, or cluster of blue-green or light grey and dark grey respectively. It is only when our starship enters the orbit of Terra or Luna, i.e. their gravitational influence, that the engine bothers to look at our altitude, longitude, and latitude based on either Terra or Luna as a point of origin and therefore renders what might be visible based on our co-ordinates and the size of objects on the planet or moon. I think this Altitude, Longitude, Latitude system could be used for any activity that takes place between objects like starships and space-walking astronauts, starships and starships, starships and planets, and so on. It describes in only three vectors exactly where something is in relationship to another object, and only requires the addition of changes in any of the three vectors over time to describe acceleration, constant movement, or decceleration (sp?). I just had a thought. What about working out North and South? They are crucial to Long-Lat systems because North and South are what they're based on. Perhaps it could be described into the model upon creation, starships taking their cue from the designer, planetary vehicles taking a cue from the planet they're on, auto-generated planets and so on taking their cue from stars, in turn taking their cues from galaxies, with a there being a certain randomising factor thrown in - after all, our own N-S on Terra are not straight up and down. Is my explanation of my idea too screwed up to understand? If not, does this seem like a viable way to model, say for example, a small galaxy and allow travel through that galaxy without the game/simulation have to stop to load different maps but simply load and unload relevant and irrelevant objects and scenery on the fly? I'd really like to get this idea out my head and into my computer. I've been thinking about this idea for several years and I'm starting to have dreams - not nightmares yet - about what could be made with this. I have many questions, and more will form as I delve into the actual programming side of things, but I think that once I get this down first I'll have a good starting point for mapping out the rest of my idea (only partly a pun).

Quote:

Original post by celotil ...cum-simulator... ...Parent-Child Relation... ...PoO... ...large spacial body... ...my suited pilot steps out of his craft and on to Luna's surface...

This is possibly the dirtiest thread ever...

That being said, this sounds like a really complicated way to subdivide your universe. It certainly "could" work, but I'm not sure how it's more useful than just subdividing your universe into a large 3D grid (each with it's own local coordinate system, if you're somehow worried about the numbers getting too big) and only loading/drawing nearby cells.

You just have a dirty mind. :)

I thought about the grid idea but the problem is that a grid must be big enough to hold everything upon the grid, and if I don't make the grid big enough to start with then I have to go back and see if the simulation supports simply increasing the size of the grid or if I have to recreate the whole environment, whereas simply picking an object and placing another object at a certain distance, vertical angle, and horizontal angle seems so much simpler, and simpler to add other objects at a later time.

Why does this feel strangely like inheritance and polymorphism?

Quote:

Original post by Chrono1081 Why does this feel strangely like inheritance and polymorphism?

What are they when it comes to game development? I can sort of guess what inheritance is, but I'm not sure about polymorphism.

Quote:

In nearly every game and 3D modelling environment I've touched and played with you have the Point of Origin, a 0,0,0 xyz place where everything is placed relatively to, and you're limited by the number system used, e.g. 16bit, 32, 64, etc. I think I may have come up with a solution to keeping the numerals small while still allowing for a huge scope of field, and I'd like the opinion of any programmers out there. Instead of having a single point of origin and relating everything to the universe to that, I've been thinking it might be better to have a Parent-Child Relational system, and I'll try to explain what I mean.

I can't see why you would need to do this. The coordinate system is definitely not your "biggest obstacle". Actually constructing an interesting persistent universe on that scale is. You can use your relational system as long as you never care about relationships further than child-parent (if you have to work out how far a particular car is from Alpha Centauri, then you will have the same problem with precision that an absolute coordinate system would have).

My advice to you is to detail your requirements, and ask a programmer to think about how to model it before trying to solve these kinds of issues. At least get one level of detail working first, then think about extending it.

You might find Ysaneya's journal a useful read.