Regions

For what's not in 'Top Priority Game Design'. Post your ideas, visions, suggestions for the game, rules, modifications, etc.

Moderators: Oberlus, Oberlus

Message
Author
aphenine
Space Floater
Posts: 23
Joined: Tue Oct 05, 2010 10:15 pm

Regions

#1 Post by aphenine » Tue Oct 12, 2010 4:17 am

This is an idea that has been in my head a while. It's about a problem that was bothering me about space-based games, in that they all had this same flaw regarding realistic astronomical scale and modelling solar systems. So I thought about it and, in doing so, I realised that the flaw is to do with a fundamental problem in making space-based games playable and fun. I then tried to solve it. I think it's a useful exercise whether it ends up in the game or not (I've read the anti-realism policy, so I know how likely that's going to be ;) ) as one day someone will have to solve it, so I've written down my thought processes, and I'd love to see what other people have to say about it.

The Problem

Space is big. Really really big. However, everything in it is really, really small. A typical solar system is about 100 AU (about 10 to the power of 13 metres) but a light year is about 10 to the power of 16, and solar systems are many light years apart. A solar system, at scale, would occupy 1/1000th of the distance between two stars space (not very optimal for a map with tens of them being drawn). The problem gets worse as one goes into a solar system. The Earth is 10 to the power of 5 in size while its distance from the sun is 1AU which I already said is 10 to the power of 11. This means that you wouldn't even bother drawing the earth on a screen. This gets further exacerbated when you try to do moons. Even if you tried to do the solar system with the planets not to scale (so they're visible), this leads to problems as the inner planets in our solar system (Mercury, Venus, Earth, Mars) are very close to the sun compared to the ones further away, and most astronomical texts show the inner solar system separately, if they try to draw the solar system in the first place.

In practise, for game designers creating space-based games (of any kind, strategy or fighter sim), this creates a huge headache. Any attempt to make the game realistic and so create an immersive space-based experience makes the game too complex, creating headaches for the game designers. Too many objects can result in too much happening in the game map (slowing the game down especially with physics collision scaling rapidly with the number of objects). Pushing the details on to the interface can lead to too much information on the screen, all of it displayed in a way that's not optimal for gaming interferes with the player's gaming experience. In the end, game designers solve problems like these by simplifying greatly and not using proper scale. This has the advantage that the game is simple, playable and easy to use. However, this sacrifice leads to a loss of immersion. It also leads to great practical design problems in space based strategy games like Free Orion. Chief among the problems are that the game designers usually have to code in a solar system for combat segments (and then the lack of scale becomes jarring, especially when they draw a planet on) and they also have to hack in inner system dynamics (like asteroid fields, orbitals, trade, production etc) without actually considering what is happening, leading to some pretty weird and jarring effects. Game designers spend a lot of time thinking about how they'll fix the problems they created by simplifying so greatly, believing that those problems are smaller than trying to do it properly.

Current space-based strategy games face this problem, and all of them have tried different schemes of simplification, with greater or smaller degrees of success. However, all of them are seriously flawed. Any game intending to extend on and improve the current games needs to find a solution to this problem that actually works.

A Possible Solution

This is my take at solving the problem. There are two main ingredients:

Space is Clustered

Although space's size is a considerable headache for game designers, it can be turned into a considerable advantage. Firstly, objects in the galaxy tend to be clustered in a small region (with not much in-between). Things in solar systems are clustered tightly around the solar system compared to the distance between solar systems and things inside solar systems (e.g. planets) are again clustered together into a small region, as moons are clustered tightly around planets and orbitals cluster tightly around moons/planets/planetoids. This pattern, of tight clustering, occurs everywhere in the Universe in reality. Even in a binary star system (something Free Orion doesn't do), it's easy to divide the system into the orbital region around star 1, the orbital region around star 2, and the orbital region around both stars. It really can be used to model everything in space using this regional system.

If we decompose our Solar system into regions as an example, we would have something like this:

Code: Select all

The solar system
|
+ - Inner Solar System
     |
     + - Mercury
     + - Venus
     + - The Earth/Moon System
           |
           + - Earth
           + - Moon
     + - Mars/Space
     + - Asteroid Belt
+ - Outer Solar System
     + - Jupiter System
          |
          + - Jupiter
          + - (The moons of Jupiter, inc Io, Callisto etc)
     + - Saturn System
          |
          + - Saturn
          + - Rings of Saturn
          + - (Moons inc. Europa etc)
And so on.

Why is this useful? Well, from both a physics and game design perspective, things in one region don't interact with things in another region, except by moving between a parent or child. This means that the map has been effectively split into several smaller maps, each of which are (by and large) independent from each other. From a physics perspective, E.g. the moons around Jupiter don't feel the physics influence of the Earth's moon, they will never collide, they will never interact and we don't have to worry about them. From a game design perspective, the individual components are effectively self-contained (e.g. production on Earth is probably going to only be used on Earth unless transported by the game). The structure outlined above is also well known in programming, It's called a tree. It's easy to code and it's easy to write simple algorithms that will span the tree, and FreeOrion already uses a subclassed system, so it's not incompatible with this idea (i.e. making the change would not totally require rewriting the code). It's easy to take the Earth/Moon system, for example, and issue orders to it, and have them transferred via tree-spanning algorithms. The tree system has the advantage also that it's natural for interfaces. You double click on a solar system to zoom in on it. You see the stats for your system. You double-click on a planet/moons system and zoom in and see its stats and then finally the planet itself (or the moon, or the orbitals). When you're done you zoom out. This system can never, never overload the interfaces with information and will automatically display it in a logical manner. Rather, any problems will come from trying to move around the tree and compare stats or issue orders that require one place to take another as an argument.

The size of a system is really its gravity well

The above tree system solves an awful lot of problems. One problem it only partially solves, however, is scale. Anything that interacts with an object A gravitationally tends to be at the same distance from it as other objects that are interacting with A. However, you'll notice that it doesn't work with the inner and outer solar system have wildly different scales. However, it does work if you split them manually. It's a hack, but a small one, and hopefully an acceptable one that can be done anywhere there's a dislocation in scale. It's also something you only need to do for systems with lots of orbiting stuff, and thanks to gravity's 1/r^2 law, you tend to only have to divide things into near and far for most cases to cope

The tree solution also doesn't solve the problem of planet and moon scale. Although the inner system is only some 3AU in size, that's still bigger than the Earth. Venus etc. Far too large to display them. However, if you consider the Earth Moon system, you realise that the Moon is 10 to the power of 8 away from the Earth, which is only 1/1000th of an AU. Also, you realise that, if the Earth influences the Moon at the power of 8, then it's influence will touch fleets about at the power of 9ish, and if we want to model orbitals, they'll be at a power of 7. This means that, in reality, we'd be forced to use a region of 10 to the power of 9, which is only 1/100th of an AU and eminently doable on the inner solar system map. So it's possible to see that gravity well sizes work well in most cases, both in reality and in game design, meaning that there's not too much hacking one has to do.

In those cases where it doesn't work, we can extend the region to a distance that displays nicely on its parent screen with no real problem that I can see.

Issues

The only immensely important and horrible programming issue I can see is that, although the maps are independent, because things can move from the child to the parent (and vice versa), you need to do the movement in all of the maps at once (or in incremental steps) to make sure things collide where they should.

Closing Argument

The region system allows you to model any space system on a real scale without sacrificing gameplay. The complexity of this solution is the minimum that I believe can be realistically achieved by modelling space realistically. This solution doesn't make the game needlessly complex and it does add to the immersion of the game. It adds and removes complexity to the game (although it adds more than it takes), it obeys KISS and, well, no one's tried it yet, which is never good, although I'm sure they will one day, as it's an obvious solution once you think it through, and obvious is awesome. I also think that modern computing hardware is up to the challenge of handling these trees for the first time ever and the reason this has not been tried before is that programmers couldn't.

Pros:

Complete freedom to build/move/attack/defend/explore anywhere in space, even in a system or in orbit.
The ability to model most space environments ever imagined in any science fiction book, including but not limited to: binary stars, Lagrange orbital points, different orbital bands (Low, high and geosynchronous orbit), O'Neil Halos, Iain M. Banks Culture-style orbitals and asteroid bases.
No separate tactical displays for combat, can reuse main map with no problem for any type of combat (except ground).

Cons:

Completely new system of moving around which has extra clicks and is therefore, on the whole, more complicated, and particularly hard if you do lots of up/down tree operations.
Forces games designers to consider inner system dynamics in all cases.
Forces a tree structure over the entire game, each level based on the scale of space based system.
Transitions between regions can give collision headaches to programming.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12529
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Regions

#2 Post by Geoff the Medio » Tue Oct 12, 2010 6:19 am

There's a lot of extraneous text in your post, so I'm not sure if I've really understood what you're suggesting. As far as I can tell, you're suggesting a multi-level hierarchical interface, with double-clicking of items to see the items inside them, for several levels.

FreeOrion already has a similar organization of objects in the game universe: systems contain planets and fleets (unless they are moving between systems). Fleets contain ships, and planets contain buidlings.

This does not require any more than two levels of interface, however. From the galaxy map, the player can directly access fleets, which shows all the ships in them, and systems, which show all the planets in them, which in turn have icons for all the buildings. No more than two clicks is needed to see all these items.

What you're proposing sounds similar to the MOO3 "layers of an onion" UI design, with multiple successive levels of detail being revealed.

FreeOrion, conversely, has been somewhat planned without the need for multiple such levels. All the information about fleets or planets or buildings that is needed should be accessible for the system-level sidepanel of planets or the system-level fleets window. This makes it easy for players to get to necessary information or UI widgets, and somewhat helps limit complexity by limiting how much the UI can show at once.

That said, FreeOrion does have a bit of this layers type interface to it, with systems containing fleets that contain ships, with separate lists within the fleets window for each fleet's ships, and systems that contain planets that contain buildings, with a separate collapsable list of buildings for each planet. The main feature is that it's not necessary to open an whole separate subscreen or lose access to the other type of information to use the more detailed information about a planet or fleet.

aphenine
Space Floater
Posts: 23
Joined: Tue Oct 05, 2010 10:15 pm

Re: Regions

#3 Post by aphenine » Tue Oct 12, 2010 1:04 pm

Um, actually the interface part was a completely secondary point to the main point of the post, which means you didn't understand it. Can you tell me why, so I can get better at explaining things? I honestly thought I'd explained it as simply as possible and I'm normally good at explaining technical things to other people, but I haven't done it in a while, so maybe I'm rusty.

I know that FreeOrion stores things in a hierarchical way. In some ways, what I'm suggesting is rather similar. However, the chief difference in what I'm trying to convey is that, once anything gets to a system, FreeOrion stops considering its location, unless it draws a tactical map at the time of combat. As a result, the solar system is a black box where there's no way to see inside or control the fleet inside before a tactical situation arises. The whole point about regions is that they're hierarchical regions of space, in which things can exist and collide and whatnot. In the current system, if you move a fleet to another system, it gets placed on the main map, moved and added to the other system when it gets there. However FreeOrion will never track the path it took to get out of the system. In a region system, the fleet exists in some point in space for it's whole journey, from the spaceport orbital at one planet, to the spaceport orbital at the other end, and you can see it and click on it and tell it to do things at any point on that journey. In the current system, you can only intercept a fleet if its moving on the main map, but in a regional system, you can intercept a fleet anywhere on it's journey, even inside a solar system. In a regional system, you could draw a map of the system and it's real distances (like the top level Universe map shows the real distances between stars systems), in the current system you'd be screwed unless you put really unrealistic numbers in for the planet sizes/orbital distances, which must screw something else up later on if you come to rely on those numbers for physical calculations.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12529
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Regions

#4 Post by Geoff the Medio » Tue Oct 12, 2010 9:16 pm

aphenine wrote:Um, actually the interface part was a completely secondary point to the main point of the post, which means you didn't understand it. Can you tell me why, so I can get better at explaining things? I honestly thought I'd explained it as simply as possible and I'm normally good at explaining technical things to other people, but I haven't done it in a while, so maybe I'm rusty.
I think the main problem was the length of the post... It's approaching 2000 words. It's also got several very long unbroken paragraphs, several of which contain mostly unnecessary information or discussion. You also don't get to the point until the end of the 3rd paragraph (in vague terms), and then there's another paragraph or two of tangential discussion... And then at the end, I'm still not really sure what you're proposing in practical terms for the UI or game mechanics.
...once anything gets to a system, FreeOrion stops considering its location, unless it draws a tactical map at the time of combat.
[...]
In a region system, the fleet exists in some point in space for it's whole journey, from the spaceport orbital at one planet, to the spaceport orbital at the other end, and you can see it and click on it and tell it to do things at any point on that journey.
[...]
In a regional system, you could draw a map of the system and it's real distances (like the top level Universe map shows the real distances between stars systems), in the current system you'd be screwed unless you put really unrealistic numbers in for the planet sizes/orbital distances, which must screw something else up later on if you come to rely on those numbers for physical calculations.
Your essential complaint seems to be that FreeOrion is too simplified and not enough of a physical / AI simulation.

This is not really a design flaw; it's intentional and by design. FreeOrion is a galaxy-spanning strategy game with (planned) system-scale combat, and is not intended to be a realistic space empire simulator.

This can lead to some inconsistencies when setting up combats (eg. where are the planets this year?), but these issues aren't really very important... or at least aren't important to warrant reworking the whole design to simulate everything down to minute detail.

Also, you're proposing some major redesign and rewrites of the existing / implemented game mechanics, which really isn't practical at this stage of development.

That all said, if there is a specific issue with an overly simplified system in the game or design now, please feel free to point it out and discuss...

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: Regions

#5 Post by Bigjoe5 » Tue Oct 12, 2010 9:18 pm

What you're suggesting would most likely require different time scales for ship movements on different scales. Currently, there are only two scales - the galactic scale, and the tactical scale. Ships on the galaxy map move on the galactic scale at speeds measured in universe units per strategic turn, and ships on the tactical map move on the tactical scale at speeds measured in (I think) 1000ths of a radius of a system per combat turn. This allows turns to be split up into two distinct types of phases - those in which ships move on the galaxy map, and those in which ships do stuff on the tactical map.

I think part of Geoff's confusion stems from the fact that you explained in great detail the theoretical aspect of your idea, without any discussion of the practical game-altering effects except with reference to the user interface. It would be helpful if you could explain in greater detail how tactical combat and ship movement are integrated on each level of this hierarchical structure, since that's essentially the main difficulty in simulating a to-scale universe.
Warning: Antarans in dimensional portal are closer than they appear.

aphenine
Space Floater
Posts: 23
Joined: Tue Oct 05, 2010 10:15 pm

Re: Regions

#6 Post by aphenine » Thu Oct 14, 2010 2:06 pm

I think the main problem was the length of the post... It's approaching 2000 words. It's also got several very long unbroken paragraphs, several of which contain mostly unnecessary information or discussion. You also don't get to the point until the end of the 3rd paragraph (in vague terms), and then there's another paragraph or two of tangential discussion... And then at the end, I'm still not really sure what you're proposing in practical terms for the UI or game mechanics.
Well, I aimed the post not as a suggestion, but rather as a technical document saying "this is a problem that all space-based games face and this is how you might go about solving it". I then beefed it up to be understandable and flow with extra words, so that it could be posted for general consumption. That's why it is the way it is. If I'd done it any shorter, it would be a terse programming document a la the boost programming guides (which are informative but so... dense). I also didn't want to lead anyone to my idea without showing them how I got there so that they could go somewhere else, if they wanted. This is because what's important in the post isn't the suggestion I would like implemented and getting someone else to implement it, but the idea I worked out.
Your essential complaint seems to be that FreeOrion is too simplified and not enough of a physical / AI simulation.
Um, no. Firstly, I'm not complaining and secondly I'm not saying that FreeOrion should be more of a physical simulation. Rather, I was saying that, if you want to make FreeOrion into a physical simulation, this is how you do it, this is what you gain and this is what you lose. If I have any view, it's that simulating things physically, using the method I have described, needn't be massively complicated.
This is not really a design flaw; it's intentional and by design. FreeOrion is a galaxy-spanning strategy game with (planned) system-scale combat, and is not intended to be a realistic space empire simulator.
Yes, I get that. I've read some of the design documents to understand why you've picked to do things this way and what the rationale is and I've found it fairly sensible (to be fair, the documentation tells me to read this stuff before posting, yet I'm feeling like you think I haven't, and this is annoying me - why tell people to do something if you then expect them not to have done it anyway?). However, when I read them, I got the impression that FreeOrion is so focused on making a fun and simply playable game that you simplify where you might not need to, and that, in a zealous desire to keep it simple, you actually break KISS in designing the program. If modelling reality is the simplest way to do something, why should it be wrong?
Also, you're proposing some major redesign and rewrites of the existing / implemented game mechanics, which really isn't practical at this stage of development.
To repeat what I said earlier, I'm not proposing anything. I phrased this post like a technical document which basically says if you want a physical simulation element to the game, then this is how you do it. I thought about it hard for a few weeks, crunched a lot of astrophysical numbers and worked out, yes, it could be done without making things too complex. That's what I'm giving to you, that thinking, and if you don't want it, fine.

I'm new to this game. I've not contributed anything yet. It would be pretty arrogant of me to tell you what you should or should not do. I have no idea of the balance of decisions that have gone into this game. That's why I phrased it the way I did. If you like the idea and it makes sense to you and is awesome to you. you'll rewrite the game anyway, whether it's late or not. That is, if you could actually understand what I'm saying.

(Also: I wouldn't have suggested something I wouldn't be prepared to do myself. If I didn't think that FreeOrion couldn't be easily adapted to do this in a short space of time (one or two months), I wouldn't have said so.)
That all said, if there is a specific issue with an overly simplified system in the game or design now, please feel free to point it out and discuss...
As I said already, in reading some of the design discussions in the archives, there's been a huge discussion in how to model various systems and arguments over how one simplification of reality is better or worse than another. All games need to simplify somewhat to work and be fun. The way you've phrased this, I'd have to (unfairly) point out the whole game. I'd much rather join in the discussions as they're happening and contribute something useful.

aphenine
Space Floater
Posts: 23
Joined: Tue Oct 05, 2010 10:15 pm

Re: Regions

#7 Post by aphenine » Thu Oct 14, 2010 3:36 pm

I think part of Geoff's confusion stems from the fact that you explained in great detail the theoretical aspect of your idea, without any discussion of the practical game-altering effects except with reference to the user interface. It would be helpful if you could explain in greater detail how tactical combat and ship movement are integrated on each level of this hierarchical structure, since that's essentially the main difficulty in simulating a to-scale universe.
Yeah, I suppose that's fair enough. I didn't really want to talk about the practical in-game details as I really don't know enough to comment. I was really hoping that those who did know enough would be able to understand and adapt the idea, coming to a clear conclusion about whether it's worth it.

As for the issue you pointed out, I thought that would be obvious enough :) One speed for the FTL drive (light-years/second) and another for the normal space drive, and make up some sci-fi bumf about how gravity wells stop hyperdrives at the system boundary (sci-fi authors do it often enough). It would give you a reason to mount lots of normal-space thrusters on ships, or a benefit to making system-only ships for in-system patrol.
What you're suggesting would most likely require different time scales for ship movements on different scales. Currently, there are only two scales - the galactic scale, and the tactical scale. Ships on the galaxy map move on the galactic scale at speeds measured in universe units per strategic turn, and ships on the tactical map move on the tactical scale at speeds measured in (I think) 1000ths of a radius of a system per combat turn. This allows turns to be split up into two distinct types of phases - those in which ships move on the galaxy map, and those in which ships do stuff on the tactical map.
Hmm, I have great difficulty seeing how any of this is a problem. Whatever you do, there are two scales of movement: interstellar and system speeds, exactly like universe and tactical combat speeds, so there's a one to one transference. In deep space (interstellar or interplanetary), fleets occupy their own little region given by the size of their sensors anyway (they are not point sources, so there's no sense treating them as such), which will be much smaller than the distance between the objects they're travelling between, so at any point if you have two fleets intersecting, you can just dump them in the same region and push that combat phase later on. This is exactly the same as what happens now. The only issue is if they're in a small region (like orbit), then they're already in the smallest region possible, so they can't be in their own. But that would be easy to detect and solve.

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: Regions

#8 Post by Bigjoe5 » Sun Oct 17, 2010 1:57 am

aphenine wrote:As for the issue you pointed out, I thought that would be obvious enough :) One speed for the FTL drive (light-years/second) and another for the normal space drive, and make up some sci-fi bumf about how gravity wells stop hyperdrives at the system boundary (sci-fi authors do it often enough). It would give you a reason to mount lots of normal-space thrusters on ships, or a benefit to making system-only ships for in-system patrol.
The problem isn't splitting it between in-system and extra-solar. The problem is splitting it between extra-solar, solar, planetary, lunar, etc, which is what such a system would require.
aphenine wrote:Hmm, I have great difficulty seeing how any of this is a problem. Whatever you do, there are two scales of movement: interstellar and system speeds, exactly like universe and tactical combat speeds, so there's a one to one transference.
There needs to be as many scales of movement as there are scales of locality - otherwise, the multi-layered hierarchical scale has no purpose, since it has no real effect but to decrease the scale of combat - at least with FreeOrion's current game mechanics. There are currently no features planned that would be able to make use of this feature (though if you'd like to suggest some, you're free to do so - such suggestions may be useful regardless of whether or not such a system is implemented).

As it is, all combat is system-wide, and involves all military forces present in a system, which I think promotes richer strategy and tactics, as well as an (IMO) appropriate sense of scale for a game of this, well, scale. There are also potentially more interesting tactics that can occur on a system-wide scale, making use of the "geography" of the star system, such as planets, asteroids and nebulae (not to mention the star itself), which I feel are strong advantages to having system-wide not-to-realistic-scale combat.
Warning: Antarans in dimensional portal are closer than they appear.

aphenine
Space Floater
Posts: 23
Joined: Tue Oct 05, 2010 10:15 pm

Re: Regions

#9 Post by aphenine » Fri Oct 22, 2010 5:44 pm

The problem isn't splitting it between in-system and extra-solar. The problem is splitting it between extra-solar, solar, planetary, lunar, etc, which is what such a system would require.
You're confusing scale speed with speed. Yes, things would move at different speeds in the region across your screen, but they wouldn't move at different speeds in the game engine. So in a small region like a planet/lunar region, you'd see a fleet move faster across your screen than in the inner system view, but that would purely be an effect of your view of the game.
As it is, all combat is system-wide, and involves all military forces present in a system, which I think promotes richer strategy and tactics, as well as an (IMO) appropriate sense of scale for a game of this, well, scale. There are also potentially more interesting tactics that can occur on a system-wide scale, making use of the "geography" of the star system, such as planets, asteroids and nebulae (not to mention the star itself), which I feel are strong advantages to having system-wide not-to-realistic-scale combat.
Well, the problem is with using the game geography in a non-proportionate view is that you'd never actually be using the geography in a way that was actually realistic or fun. If you look at the scale of ships, weapons and average accelerations that are likely and sensible (and given as numbers in various sci-fi series), they're never particularly suited to system-wide combat. Even is a David Weber style combat (he uses lots of numbers and large scale combat, which is why I'm using him as an example) which involves fleets duelling with missile at extreme long ranges, the max acceleration of the misiles (around 500g ~= 5km/s^2) with a sensible live time (minutes) means that, even then, combat never really occurs on the grand scale of a system but only in the million-km range, and as a result ships on the outer system and ships on the inner system still have to manouver strategically in order to come to a tactical combat situation. That means an awful lot of options which are never given to the gamer and so there are lots of strategies for in-system combat which will never get used.

You won't have ambushes from asteroid fields, or from behind planets. The lack of sensible scale means that scanners won't work on sensible ranges, as you won't be able to pick up detail on the system until you are well into the system and committed to action (as a result, your intelligence had better be right). If you are defending a planet, do you leave the planet to intercept, or do you stay in orbit? If you're attacking, do you want to make a high-fractional-c velocity strike against the orbiting fleet before closing with them? What about your system infrastructure? If you are defending your system, you may have the planet well defended, but do you have the asteroid bases well covered, and what about your gas giant hydrogen scoop? Can you be raided? Is the military best position on an inner system habitable planet or is it better to put an outpost on a distant outer-system planet, and if so, what are the civilian consequences in doing so? If you are attacking a system, can you sneak past the outer scanners? Do you have to go for a full on assault on the main fleet? Maybe it's better to cut the orbital supply lines and starve the enemy of ammunition and fuel by isolating them from their points of resupply? What about wrecking orbital shipyards without ever firing a shot at the enemy fleet?

It's pretty much all these things that made me think that, space is big, and system space is massive too, and full of potential fun and options.

User avatar
Krikkitone
Creative Contributor
Posts: 1509
Joined: Sat Sep 13, 2003 6:52 pm

Re: Regions

#10 Post by Krikkitone » Mon Oct 25, 2010 2:43 am

aphenine wrote:
If you look at the scale of ships, weapons and average accelerations that are likely and sensible (and given as numbers in various sci-fi series), .
That's your problem, your assuming "likely and sensible speeds"
Given that the very fundamental assumption of the game engine-regular FTL travel, would require a rewriting of the physics books, we are doing that.

Ships in the FO universe have not FTL but Instantaneous sensors+communications. Their Beam weapons travel at multiple orders of magnitude faster than the speed of light. Even in systems, the ships themselves are travelling FTL. Apparently the strange physics that allows these massive apparent velocities is not capable of smashing omething into a planet and supermassive energies. (I'd suggest it is because one of the fundamental physical discoveries of the FO universe is probably a means of breaking of the conservation of momentum, and/or allowing movement without kinetic energy being involved. ie both Einstein and Newton are as wrong as Aristotle.)

aphenine
Space Floater
Posts: 23
Joined: Tue Oct 05, 2010 10:15 pm

Re: Regions

#11 Post by aphenine » Tue Oct 26, 2010 6:38 pm

That's your problem, your assuming "likely and sensible speeds"
Given that the very fundamental assumption of the game engine-regular FTL travel, would require a rewriting of the physics books, we are doing that.

Ships in the FO universe have not FTL but Instantaneous sensors+communications. Their Beam weapons travel at multiple orders of magnitude faster than the speed of light. Even in systems, the ships themselves are travelling FTL. Apparently the strange physics that allows these massive apparent velocities is not capable of smashing omething into a planet and supermassive energies. (I'd suggest it is because one of the fundamental physical discoveries of the FO universe is probably a means of breaking of the conservation of momentum, and/or allowing movement without kinetic energy being involved. ie both Einstein and Newton are as wrong as Aristotle.)
I... don't quite understand what you're saying. What I think you're saying is something like "the FO physics already assumed is so utterly outside of the physics we know now that we should therefore throw the entire physics book out of the window when designing the game", I don't agree with that. I do agree that there shouldn't be anything against assuming all kinds of crazy stuff in FO in the far future, or tweaking it to make sure the game works fine. On the other hand, there really ought to be a progression from physics we know now and the physics we have in the future, otherwise there's no sense of science fiction, just science fantasy (which is all right, if that's what's wanted, but it isn't that hard to make a sensible progression, even GalCiv 2 managed it). Also, I'd like to point out that doing something like 500g really requires you to break the laws of momentum and inertia anyway, so I'm really confused why you'd even point that out. If a ship does 500g, all the people inside go jam sandwich without some kind of compensation, and you have to scrape them up off the bulkheads. If you think 500g is reasonable (in the sense of realistic given current technology), then you're very mistaken. I go back to my general theme of, I don't really care if the game is realistic or not, but I feel not making the attempt to make it as realistic as possible and then hacking it to make it fun isn't quite the way to go. I don't even care if the ships moving in the Regions have gravity, acceleration or ballistic courses. It would be nice and awesome, but harder to do. I'd just love to see some attempt made to simulate the strategic landscape of an solar system properly, so that the decisions taken inside a solar system matter, so that the solar system landscape matters.

Getting back to the topic, I remember now the biggest reason why I want to see something like Regions happen. In MoO3, if you and someone else had a planet in the same system, because MoO3 didn't bother to simulate the internal dynamics of the system, there were issues with what happened when war broke out. Basically, being in the same system meant insta-war, and that always struck me as a little wrong. Surely if you had two empires in the same system, that would be a massive source of friction, so you'd negotiate treaties or fight limited wars to work out sensible details like who controls the star-lane termini, who controls the inner/outer systems and what the appropriate levels of access in the system are to be. Imagine how important control of the star-lane termini would be. You have a small area of the system where ALL the inter-system traffic HAS to go through. Think of the chaos you could have putting a few orbital fortresses there.

User avatar
Krikkitone
Creative Contributor
Posts: 1509
Joined: Sat Sep 13, 2003 6:52 pm

Re: Regions

#12 Post by Krikkitone » Wed Nov 03, 2010 2:28 am

aphenine wrote: I'd just love to see some attempt made to simulate the strategic landscape of an solar system properly, so that the decisions taken inside a solar system matter, so that the solar system landscape matters.
That makes sense. Planets (and other solar system features) will have distinct locations on the 'solar system battlefield' (not sure if it varies or remains fixed from one game turn to another)

Battles could still end with multiple empires having ships in the same system. (I believe)

Planets, (and probably starlane entrances) would be the only "things held".

It might be nice if "Inner System" worlds were close to each other and "outer system" worlds were farther away.
so that
orbit 1=10 from star
orbit 2=30 from star
orbit 3=60 from star
orbit 4=100 from star
orbit 5=150 from star
orbit 6=210 from star
orbit 7=280 from star
orbit 8=360 from star
orbit 9=450 from star
orbit 10=550 from star

Well that's too far away from the star, but that type of scale.... So weapons that can fire from orbit 1 to orbit 3 can't neccessarily fire from orbit 8 to orbit 10.

Sensor shadows may still be possible... planets could provide a cloaking effect to ships nearby.

The "insta-war" should be solvable by having special diplomatic rules for mixed systems... ie Your ships trigger war if they enter a system that has my planets and none of yours.

aphenine
Space Floater
Posts: 23
Joined: Tue Oct 05, 2010 10:15 pm

Re: Regions

#13 Post by aphenine » Mon Nov 29, 2010 3:12 pm

*sigh* You see, those are all perfectly reasonable and good suggestions, but they still give me the feeling that once you start down the road of adding all these tweaks, you still would have been better off doing it once and doing it right. If you had the system in detail, you'd have all the distances so you could use those in stead of imposing arbitrary rules, and ships wouldn't automatically fight if they ended turns inside planetary systems, not in the solar system. You do more complicated programming, to save more complicated programming.

User avatar
Krikkitone
Creative Contributor
Posts: 1509
Joined: Sat Sep 13, 2003 6:52 pm

Re: Regions

#14 Post by Krikkitone » Mon Nov 29, 2010 7:55 pm

aphenine wrote:*sigh* You see, those are all perfectly reasonable and good suggestions, but they still give me the feeling that once you start down the road of adding all these tweaks, you still would have been better off doing it once and doing it right. If you had the system in detail, you'd have all the distances so you could use those in stead of imposing arbitrary rules, and ships wouldn't automatically fight if they ended turns inside planetary systems, not in the solar system. You do more complicated programming, to save more complicated programming.

The rules aren't arbitrary, ships in the same system would trigger war because it is possible for them to attack each other, AND the ships can be moved out. (ie Allowing your ships in MY systems is a diplomatic agreement)

The only reason planets do not trigger war is because those planets can't be moved Out of the system.... ie if Pluto is at war with Mercury, they can fire on each other (withthe right techs).... but when peace is declared Pluto doesn't expect Mercury to move out of the system.... But Mercury's Ships should move out of Pluto's colony in Alpha Centauri.
(Unless they have an agreement of some type... perhaps Mercury won the war so it gets to put its ships wherever it wants)

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: Regions

#15 Post by Bigjoe5 » Wed Dec 01, 2010 2:14 pm

aphenine wrote:Getting back to the topic, I remember now the biggest reason why I want to see something like Regions happen. In MoO3, if you and someone else had a planet in the same system, because MoO3 didn't bother to simulate the internal dynamics of the system, there were issues with what happened when war broke out. Basically, being in the same system meant insta-war, and that always struck me as a little wrong.
This definitely doesn't need to be the case, even without regions (see this page - note that most of it is just my own personal suggestion, and not official FO design).
Warning: Antarans in dimensional portal are closer than they appear.

Post Reply