Return to “Suggestions”

Post

Time acceleration vs. super cruise / in-system jumps

#1
(re-posted because we were slipping waaaay off topic)
Hardenberg wrote:I'd rather prefer some type of "cruise mode" with all power routed to the engines to facilitate faster in-system travel (basically, the way Freelancer handled in-system travel).
While time acceleration has it's own bundle of problems, so does a super-cruise mode. =)
  • Autopilot woes.
    Instead of a 100m/s ship traveling at a virtual 1000m/s (with the usual effects on autopilot object avoidance), you have a 100m/s ship traveling at 1000m/s.
    See the problem? =)
  • When and where does it work?
    • If you can engage super cruise anytime, no one will ever win a fight.
    • You can't say that it "doesn't work with enemies around". If there is a lone fighter buzzing around my battleship, I couldn't care less if it's hostile or not.
    • Having any ships nearby is not a good fail condition, either.
      You want to allow formations of ships...
    • It would be reasonable for stationary large objects like stations or planets to kick you out of super cruise for safety reasons when you get close.
      This could simply a matter of the size of the object. A huge dreadnaught might have it's own (tiny) gravity well that disables super cruise in a small radius.
      As a result, escorting ships would either keep their distance or land on the dreadnaught to hitch a ride - both of which offers an interesting opening for a temporary vulnerability.
  • What negatives are attached to using it in order to prevent anyone just taking off anytime?
    • Huge energy drain, that sucks shield and weapon banks dry leaving the ship defenseless for x seconds before the drive engages.
      If your shield / weapon energy is dry to begin with, it takes longer to charge.
      Not recommended under fire.
    • Shields /weapons recharge while under way but on short hops, you still end up in less than stellar condition.
      It's designed for long distance travel.
    • Extremely low steering while under way. It should not be a glorified afterburner.
    • Shields must be down for the system to charge in the first place because they would prevent the "field" from being generated.
  • How do you prevent ships from getting away?
    Star Wars had ships / stations equipped with gravity well projectors, such as the Immobilizer 418 cruiser, which showed up in the X-Wing / Tie games. (no GWP equipped ships featured in movies)
    This "placed a heavy drain on the generators" but prevented ships in a large radius to just bugger off.
    This would limit the ability to considerably big ships.
    OTOH, the GWP ship would be weakened by the power drain while the system is engaged so it would be an obvious target of everything that wants to get away. Not impossible to balance.

    Another way would be technobabble anti matter gibberish mines (TAMGIM).
    You drop and detonate one of those and all ships in the vicinity are unable to engage super cruise for x minutes.
    (used in a different fashion by Weber in the Dahak series)
    While it would be good that smallish pirate ships could use the functionality, there is no real counter to this. Not so good.
There is no "I" in Tea. That would be gross.
Post

Re: Time acceleration vs. super cruise / in-system jumps

#2
Excellent suggestions, I am very much trying to weigh super cruise vs. time acceleration.

I've always disliked time acceleration in principle, because to me it's like, "we couldn't figure out how to make the game interesting in the passing time, so we'll let you accelerate it away." On the other hand, super cruise can easily break the feeling of scale, which is something that TA preserves since you see the universe changing rapidly around you.

Tough call. And yes, cruise is certainly harder on the physics engine, TA doesn't have that problem (well, implemented properly, that is, I'm not sure if X had problems with TA and physics or not..).

In the mean time, while cruise is not implemented, that time accelerator sure saves me a bundle of time when I'm trying stuff out in-game...I find myself using it more and more -_-
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Time acceleration vs. super cruise / in-system jumps

#4
JoshParnell wrote:Tough call. And yes, cruise is certainly harder on the physics engine, TA doesn't have that problem (well, implemented properly, that is, I'm not sure if X had problems with TA and physics or not..).
It all depends on the implementation.
The big issue in X3 is collision avoidance. This is only a symptom, though.
The timing in the game is effectively frame-based. One frame is the smallest time unit in the game.
If you accelerate time 10x, your FPS drop, let's be generous and say to 1/2. Collision avoidance is therefore checked less often.
Ships cover 10x the distance in "realtime" so with half the checks, collision avoidance is 1/20 as accurate.

Ships do not check far enough ahead to make this work. As a result, they evade too late. Kaboom.

TA is also an exploit in X3. Since everything is frame-based, this includes bullet collisions. If you want your missile barrage to hit unopposed, launch away and hit TA.
The bullets from the defensive turrets rarely intersect the missiles they are targeting because in one frame, they travel far enough to skip the missile entirely. The turret scripts also suffer, sometimes freezing completely.

If the timing in your game works differently, this may not apply...


On principle I like the super cruise concept better but there are a lot more bells and whistles to take care of to make it work properly.
If you can make time acceleration work properly, it's straightforward and fair to everyone.
There is no "I" in Tea. That would be gross.
Post

Re: Time acceleration vs. super cruise / in-system jumps

#5
Man, I'm really glad we have you to reveal the implementation details of X. And man, that was a lot of mistakes they made :shock:

Changing the rate of collision checking is just bad news no matter how you slice it. In my implementation, TA switches the physics step to a constant step size (60 Hz), then loops the game logic (without any rendering). I am using 10x acceleration right now, and the framerate is roughly halved. Which is good, it means the game logic is very fast compared to the rendering, as one would expect (as we discussed earlier, X probably has difficulty in that area due to script interpreters hogging CPU). But the collision frequency remains constant. Well, everything remains constant, from the perspective of all game logic, there is absolutely no way that it can tell that you've sped up time, it looks exactly the same as 10 frames at 60FPS would have look without TA. So automatically, everything "just works."

As for the bullets/missiles problem...I can't believe they are using discrete collision for this, as it should absolutely be continuous, no questions asked, especially when the bullet is small and easily approximated by a ray. In LT, you will never see a weapon go through a hard object, because I use continuous raymarching rather than some discrete approximation. It's very cheap with the right acceleration structures, thankfully.

Still, even with this "correct" implementation, I feel that it's a hack. Will definitely need to play with cruise soon.
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Time acceleration vs. super cruise / in-system jumps

#7
On the Oolite BB, the debate about torus drive (Elite's/Oolite's implementation of a cruise mode) vs. time acceleration is a lively one, and it tends to turn up again and again, with some people very emphatically defending the traditional torus drive (which is a de-facto acceleration of player ship speed, but only works as long as nothing is within scanner range), while others equally emphatically prefer time acceleration (which speeds up—or slows down—everything in factors of 2 between 1/16 of and 16 times the normal speed; acceleration is achieved by skipping more and more AI cycles, which leads to weird AI behaviour with higher TAFs, for instance sending escorts astray).

While there is no general consensus, most of the recurring points that are being made point in the direction of preferring general time acceleration over cruise mode:
  • The torus drive (cruise mode) feels like a cheat, being a player-only device. In a universe that emphatically is not centered around the player, it feels out of place.
  • A variation of the first point is the observation that many new players/players who are not familiar with the code-base automatically assume that NPCs have a torus drive as well, and are disappointed when they find out that that's not the case.
  • In a pursuit situation, the torus drive gives an unfair advantage to the player: if he's the pursuer, he can always close in to the pursued ship at no cost, as long as there are no other ships nearby; if he's being pursued, he can always run away at an unbeatable speed at no cost, as soon as he gets out of the immediate vicinity.
  • There are repeated requests for replacing the torus drive with TAF, although the development team has made it clear that the current TAF (also because of its quirks) is meant mainly as a debugging feature, and won't be part of the next deployment (= made for playing) release.
  • Torus drive is part of the Elite heritage, and therefore shouldn't be changed/disabled.
All points but the last one are in favour of time acceleration.
Post

Re: Time acceleration vs. super cruise / in-system jumps

#8
JoshParnell wrote:Man, I'm really glad we have you to reveal the implementation details of X. And man, that was a lot of mistakes they made :shock:
I don't think these are the result of bad planning or genuine mistakes but rather of adding stuff to a 10+ year old engine.
The concept worked in the original X because the scope was so much smaller. You didn't have a huge number of assets, complexes, sectors, AI actors, or scripts. It's easy to blame them with the benefit of hindsight. =)
Now we got fixes to hacks to workarounds for a truly byzantine game engine.

X is still a good yardstick for features because it has ginormous scope. Just about every crazy thing you can think of has been tried already.

I even scripted a tech demo for a different control interface for capital ships.
You press a hotkey to engage course setting. You are dropped into an "empty space view" where you can mouselook freely. If you rest the mouse for 1-2 seconds or press the hotkey again, you are back in your ship which is now lumbering towards the new heading.
I don't always want to go through a lot of menus and tinker with a waypoint systems in 3 dimensions. Just fly THIS way! KISS.
The capital ships in X3 turn too quickly to make this very useful. I just wanted to demonstrate something I was suggesting for Rebirth. =)


Commander McLane wrote:The torus drive (cruise mode) feels like a cheat, being a player-only device.
I implied that AI ships would use super cruise as well. It's the whole point of a fast-travel system!
There is no "I" in Tea. That would be gross.
Post

Re: Time acceleration vs. super cruise / in-system jumps

#9
Gazz wrote:I don't think these are the result of bad planning or genuine mistakes but rather of adding stuff to a 10+ year old engine.
The concept worked in the original X because the scope was so much smaller. You didn't have a huge number of assets, complexes, sectors, AI actors, or scripts. It's easy to blame them with the benefit of hindsight. =)
Now we got fixes to hacks to workarounds for a truly byzantine game engine.
Makes sense :?
Commander McLane wrote:On the Oolite BB, the debate about torus drive (Elite's/Oolite's implementation of a cruise mode) vs. time acceleration is a lively one, and it tends to turn up again and again, with some people very emphatically defending the traditional torus drive (which is a de-facto acceleration of player ship speed, but only works as long as nothing is within scanner range), while others equally emphatically prefer time acceleration (which speeds up—or slows down—everything in factors of 2 between 1/16 of and 16 times the normal speed; acceleration is achieved by skipping more and more AI cycles, which leads to weird AI behaviour with higher TAFs, for instance sending escorts astray).

While there is no general consensus, most of the recurring points that are being made point in the direction of preferring general time acceleration over cruise mode:
  • The torus drive (cruise mode) feels like a cheat, being a player-only device. In a universe that emphatically is not centered around the player, it feels out of place.
  • A variation of the first point is the observation that many new players/players who are not familiar with the code-base automatically assume that NPCs have a torus drive as well, and are disappointed when they find out that that's not the case.
  • In a pursuit situation, the torus drive gives an unfair advantage to the player: if he's the pursuer, he can always close in to the pursued ship at no cost, as long as there are no other ships nearby; if he's being pursued, he can always run away at an unbeatable speed at no cost, as soon as he gets out of the immediate vicinity.
  • There are repeated requests for replacing the torus drive with TAF, although the development team has made it clear that the current TAF (also because of its quirks) is meant mainly as a debugging feature, and won't be part of the next deployment (= made for playing) release.
  • Torus drive is part of the Elite heritage, and therefore shouldn't be changed/disabled.
All points but the last one are in favour of time acceleration.
Absurd..why would only the player get this device? Makes no sense! Cruise will, of course, be available to everyone in LT, not just the player...in fact, as I've said before, the player will be no different in capability from any of the NPCs!
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Time acceleration vs. super cruise / in-system jumps

#10
Absurd..why would only the player get this device?
Tradition, I presume, as the system is ported straight from the classic Elite. Being a straight single player game, the player had access to a couple of things that no one else in the universe had, like ECM, smartbombs, an escape capsule and said Torus drive. Back then, they were only available to the player since the universe wasn't persistent in any way or form.

I agree what with what you have in mind, the concept of a player-only time high-speed drive is mindbogglingly stupid. But keep in mind that the original idea was from 1984, and the machines this was supposed to run on had between 16 and 128 KB RAM. You had to cut corners everywhere to make things fit.


On a related side-note, has anybody considered in-system jumps a'la Star Wars? Where you basically can move around freely and FTL, as long as there is no gravity well nearby? (IIRC, the interdictors in Star Wars worked by projecting an artificial gravity well (and no one bothered to weaponize that system...my, SciFi doesn't get much softer than that). You could basically skip only empty space, but as a side effect, the void between the stars would be pretty much void of anything, including passing ships. Also, you need a more portable (i.E., smaller than a pretty large Star Destroyer type craft) way of assuring that a targeted ship can't simply jump away, since players don't usually follow screenwriter's script and have no sense of drama ;).
Hardenberg was my name
And Terra was my nation
Deep space is my dwelling place
The stars my destination
Post

Re: Time acceleration vs. super cruise / in-system jumps

#12
I would like to throw in my $0.02 and say that time acceleration should be put in regardless of whether or not it is favored against super cruise/jumps.

When I say Time Acceleration, I'm talking about pressing a button and everything goes 2x, 4x, or 8x faster. Freespace had this, and I think LT should as well. By Time Acceleration, I mean that when it is set to 2x, everything is CALCULATED twice before showing a frame to the screen when normally it would only be calculated twice. Not just double the length of vectors, or double the amount that is added to variables, but the actual process game loop be processed twice, four times, eight, etc.

I know this is INCREDIBLY CPU expensive, however the reason for this, is that when Josh finally comes out with LT, we might be on the next generation of video cards, CPUs, etc. When most of you come back to this game 5, 10 years later like many of you do with freelancer, your computer will be that much more powerful, and what is considered CPU expensive now will be incredibly cheap in not even a year's time. Not only that, but time acceleration done this way would be INCREDIBLY easy to code, and may not need more than 2-3 more lines.

Any fakery or trickery that would normally be done to make a different sort of time acceleration reasonable and processor cheap could still be discussed, but the actual capability of time acceleration how I described seems like a no-brainer. It also means that when Josh does testing in smaller universes/systems, it allows him to simulate universe age really fast.

E.G. Josh is simulating a single system with a handful of ships, and wants to test out how the economy flows, setting it to 100x speed and watching how the ships interact to see if there is any problems in what would normally be days of gameplay over the course of seconds would help troubleshoot. But if you try to add 100 * variable to other variables, or however other method is chosen, you may end up seeing things that would be impossible.

I also choose Sim City as an analog to this. In Sim City, if you can build a relatively small city that's able to generate a mediocre income, you just set it to 'auto budget' and turn off disasters, then crank the speed up to highest and leave it overnight, you have yourself millions to build however you want. I know some people who would want to play this way not only to gain money easily, but to see how the universe evolves and how other factions evolve too.
Image
Early Spring - 1055: Well, I made it to Boatmurdered, and my initial impressions can be set forth in three words: What. The. F*ck.

Online Now

Users browsing this forum: No registered users and 0 guests

cron