Game Distance Units
Moderator: Oberlus
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Game Distance Units
Presently FO object positions are represented in the code in arbitrary units, such that an average universe is about 1000 units across. This works out so that stars are about 80 or so units from their neighbours.
This is too long to sensibly call the inter-star distance "light years", or "parsecs" without some creative explanation why the stars are so far apart.
I'd also like, if possible, to avoid having to convert distances from internal game representation to player-readable / UI representation in units of ly, parsecs, or whatever. Similarly, unless there's a good reason to, I don't think we should change the scale of the code internal distance units just so they can be displayed the the player in sensible number ranges without the above conversions.
So, can anyone come up with a good unit of distance name / symbol / etc. for stars being 80 such units apart typically?
Keep in mind that this unit will probably also be the measure based on which some effects conditions will include or exclude possible targets, and also the unit per turn (or some other less-gamey time unit) that ships' speed is measured in.
Now, granted, we'll have grossly unrealistic scales somewhere regardless, since a galaxy of 500 stars isn't going to be big enough across compare to its inter-star distance to compare to any real 100000+ lightyear diameter galaxies. But in practice, the players will be mostly dealing with inter-star distances, while playing, so I figure this should be the focus of any distance-unit naming attention.
Thoughts?
This is too long to sensibly call the inter-star distance "light years", or "parsecs" without some creative explanation why the stars are so far apart.
I'd also like, if possible, to avoid having to convert distances from internal game representation to player-readable / UI representation in units of ly, parsecs, or whatever. Similarly, unless there's a good reason to, I don't think we should change the scale of the code internal distance units just so they can be displayed the the player in sensible number ranges without the above conversions.
So, can anyone come up with a good unit of distance name / symbol / etc. for stars being 80 such units apart typically?
Keep in mind that this unit will probably also be the measure based on which some effects conditions will include or exclude possible targets, and also the unit per turn (or some other less-gamey time unit) that ships' speed is measured in.
Now, granted, we'll have grossly unrealistic scales somewhere regardless, since a galaxy of 500 stars isn't going to be big enough across compare to its inter-star distance to compare to any real 100000+ lightyear diameter galaxies. But in practice, the players will be mostly dealing with inter-star distances, while playing, so I figure this should be the focus of any distance-unit naming attention.
Thoughts?
-
- Space Floater
- Posts: 28
- Joined: Thu Apr 13, 2006 8:22 pm
If I understand correctly 1 parsec = 3.26 light years
So, if we made 1u = 1/100 parsecs and the average star separation is 80u that would make .8 parsecs between stars or 2.6 light years between stars...
Our sun is pretty remote and it's closest star is something like 4 light years away, so 2.6 light years sounds pretty reasonable to me.
With a simple conversion like 1 = .01 I think things would work out well.
So, if we made 1u = 1/100 parsecs and the average star separation is 80u that would make .8 parsecs between stars or 2.6 light years between stars...
Our sun is pretty remote and it's closest star is something like 4 light years away, so 2.6 light years sounds pretty reasonable to me.
With a simple conversion like 1 = .01 I think things would work out well.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Hmm... so "centiparsecs" ? Abbreviation "cpc"... At least it's... uhm... original sounding? and looking...?maelstrom512 wrote:So, if we made 1u = 1/100 parsecs...
*ANY* conversion would be a pain, as someone, probably me, would have to go through and put a / 100 next to every instance where positions or distances are calculated. If the unaltered internal game units are used, then it's much simpler...With a simple conversion like 1 = .01 I think things would work out well.
*ANY* conversion would be a pain, as someone, probably me, would have to go through and put a / 100 next to every instance where positions or distances are calculated. If the unaltered internal game units are used, then it's much simpler...[/quote]
Shouldn't there be a constant somewhere in the code
eg
constant float fUnits = 0.1f
Then you can go:
Move(10) //calculation 10*fUnits =1
Shouldn't there be a constant somewhere in the code
eg
constant float fUnits = 0.1f
Then you can go:
Move(10) //calculation 10*fUnits =1
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
More likely it would be defined externally for easier modding...utilae wrote:Shouldn't there be a constant somewhere in the code
??? Referring to the constant in the comment doesn't change what the Move(...) function does. I'm not sure what you're trying to suggest here...Move(10) //calculation 10*fUnits =1
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
-
- Space Floater
- Posts: 28
- Joined: Thu Apr 13, 2006 8:22 pm
Maybe this is too obvious, but shouldn't someone be going through the code and add the label every place the distance is displayed? There isn't much difference from changing sprintf(s, "distance: %d", dist) to sprintf(s "distance: %d abcde", dist * conversion)
If we don't go through and make this change what exactly is the point?
If we don't go through and make this change what exactly is the point?
-
- Large Juggernaut
- Posts: 938
- Joined: Fri Jan 20, 2006 9:34 pm
- Location: GA
I'm just saying how it should work, so if the distance unit changed, you can change it in one place.Geoff the Medio wrote:OK... can you explain how it does it without someone going through the code and adding scaling factors every time a distance is one of either a) compared or used, or b) displayed to the user?
Because (as you said) is hard coded, someone will have to go through each and every bit of the code and change it.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
(Half of) the point was that I didn't want to have to go through the code and change every reference to spatial position or distance to be multiplied by some constant. This is a pain, and it's also asking for trouble if there's every any math done using the relevant numbers. For example, if you had some effect that worked on objects within distance of "Source.EffectRange + 5", you've probably got to convert one of those values to another set of units (user-visible or game-internal) in order to add them meaningfully. It's not just text IO...maelstrom512 wrote:If we don't go through and make this change what exactly is the point?
-
- Space Floater
- Posts: 28
- Joined: Thu Apr 13, 2006 8:22 pm
As far as math being done with the conversions, I agree this could lead to trouble. If we go with a conversion scheme we will need to be very clear that the conversion only happens when going from internal to end-user (and vice versa) and no internal representations are stored converted. (Scripts would be included as internal because a script developer is still a developer and not an end user)
As far as you (Geoff) ending up doing it, isn't what us programming types that are new to the project are good for? Semi-tedious tasks that require looking at a lot of different code?
All in all, I agree that it is not a perfect solution and it has some definite pitfalls that we will have to address in order to make it usable. The alternative to have a simple description that is a made-up unit is still there, but the only problem I see with that is it runs the risk of making the game seem silly... The really nice thing about using a unit like parsecs is that it is something users have heard other places and sounds hard core. (Even if they have no idea what it means ) This might be able to be bypassed by a very clever term, but I'm nowhere near that clever.
On a rather humorous note, I find it very amusing that the term parsecs would actually have no real meaning in our created galaxy because it depends on the size of the Earth's orbit...
As far as you (Geoff) ending up doing it, isn't what us programming types that are new to the project are good for? Semi-tedious tasks that require looking at a lot of different code?
All in all, I agree that it is not a perfect solution and it has some definite pitfalls that we will have to address in order to make it usable. The alternative to have a simple description that is a made-up unit is still there, but the only problem I see with that is it runs the risk of making the game seem silly... The really nice thing about using a unit like parsecs is that it is something users have heard other places and sounds hard core. (Even if they have no idea what it means ) This might be able to be bypassed by a very clever term, but I'm nowhere near that clever.
On a rather humorous note, I find it very amusing that the term parsecs would actually have no real meaning in our created galaxy because it depends on the size of the Earth's orbit...
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Content also need stringtable entries as well though... which need to use correct units, which will be different from those in the scripts...maelstrom512 wrote:As far as math being done with the conversions, I agree this could lead to trouble. If we go with a conversion scheme we will need to be very clear that the conversion only happens when going from internal to end-user (and vice versa) and no internal representations are stored converted. (Scripts would be included as internal because a script developer is still a developer and not an end user)
Bah. I'm going to try to avoid this whole issue by changing the size of the universe... I'm not sure how many other coding assumptions were based around its current size, so this may be a simple fix or may be totally nonworkable...
Edit: That didn't go as well as I'd hoped...
IMO it's best to start by finding a somewhat self-contained issue you can chew away at until you've started learning the code and its structure. My first code contribution was the starlane generation code, which was pretty much independent of anything else. The IO stuff is strewn all about in files that are likely changing due to other coding...As far as you (Geoff) ending up doing it, isn't what us programming types that are new to the project are good for? Semi-tedious tasks that require looking at a lot of different code?
If you want something to do, and can't find an appealing-looking feature request or bug report, do please ask and I'll see what I can find for you to work on. There's plenty to go around...
And also the definition of an arc second...On a rather humorous note, I find it very amusing that the term parsecs would actually have no real meaning in our created galaxy because it depends on the size of the Earth's orbit...