Nebulous: Fleet Command

[potatojohn]

https://store.steampowered.com/app/887570/NEBULOUS_Fleet_Command/





Looks pretty cool

 

[Beowulf]

Is this the Nexus 2 we deserve?

 

[Parsimonious cook]

Looks great, will watch with interest.

 

[Burning Bridges]

too nebulous for me

 

[Alpharius]

Looks intreresting, but from steam description it seems like there won't be a single player camapign?
And also from steam description no economy so multiplayer potential looks nebulous as well. It'll take significant effort to make it fun and balanced and will the number of players justify it? Uncertain.

 

[Lone Wolf]

This looks like Children of a Dead Earth with a +1 to technological level.

 

[ShaggyMoose]

Love the blow-through of projectiles with what looks like gas escaping from both sides in some cases.

 

[Beowulf]

Love the blow-through of projectiles with what looks like gas escaping from both sides in some cases.

That is a nice touch indeed. But at the same time it seems like when your self defense lasers blow the warhead of the enemy missile it just disappears. What happens with the rest of the mass going towards the ship?

 

[ShaggyMoose]

I assumed without the warhead its just a bunch of minor shrapnel without enough kinetic energy to breach the armour.

 

[Norfleet]

That is a nice touch indeed. But at the same time it seems like when your self defense lasers blow the warhead of the enemy missile it just disappears. What happens with the rest of the mass going towards the ship?

The vaporizing debris plume coming from one side pushed the now dead missile off course so it won't hit your ship anymore. It is therefore no longer of relevance to the simulation.

 

[Beowulf]

That is a nice touch indeed. But at the same time it seems like when your self defense lasers blow the warhead of the enemy missile it just disappears. What happens with the rest of the mass going towards the ship?

The vaporizing debris plume coming from one side pushed the now dead missile off course so it won't hit your ship anymore. It is therefore no longer of relevance to the simulation.

That's a sound explanation, but on the other hand, what happens to the debris flying towards the target - it is propelled with even greater speed. And knowing about how ciws work wouldn't you just deign the missile to be more akin to a mass projectile, like a solid metal rod with small engine?
Anyway, that's besides the point - the game looks good, I'm hyped.
If it is indeed MP only I hope the devs can at least balance it somehow to prevent overpowered meta to be discovered too soon.

 

[Lone Wolf]

I watched a Dev Log and - apparently - they just spent some time solving a bullshit meta issue wherein the player would buy four battleship hulls, basically empty, and sit on capture points to win matches. The opposing player usually wasn't able to damage those battleships sufficiently in time to recapture the victory locations.

So, yes, it looks like they're trying to keep the meta under control.

 

[Yaar Podshipnik]

Looks like COADE to some degree, minus some simulation stuff, with a decline spaceship design. All those ships look to have a layout like ocean ships, instead of towers. Still, will wait for full release to see.

 

[DraQ]

This looks like Children of a Dead Earth with a +1 to technological level.

Don't think so. Velocities seem to be pretty molasses and it seems they're capped at ship-specific, ludicrously low values (something like double digits m/s for ships, 200m/s for missiles? Homeworld was fast in comparison).
Plus there is no waste heat management (read: radiators) and ships are laid-out like ocean-going vessels.

So basically this game seems like (admittedly in-depth) simulation of sea battles, except in space and with aesthetics somewhere between bastardized Homeworld and Nexus.

Completely soft SF, with very thin veneer of Hard-Sf stylization.

 

[DraQ]

For the record, while any sort of (reasonably achievable) speed cap automatically pegs the game as NOT hard SF and speed cap that is different for different objects doubly so, just to appreciate how glacially slow those limits are in Nebulous:

• missiles travel at 200m/s max
• corvettes can briefly achieve 50m/s at the cost of burning out engine, normally 35m/s
• battleships likewise can briefly reach 20m/s and are normally capped at 16m/s

For comparison, in Homeworld:

• The only ships travelling slower than Nebulous' missiles are the big banana Mothership (at 50m/s in MP, so as fast as the fastest ship in Nebulous, except sustained), and heavy cruiser (at 190m/s it's just barely slower than N's missiles)
• Most Homeworld capships and non-combat vessels are at least 1.5x faster than Nebulous' missiles.
  
• Homeworld fighters are typically 4-5x faster than N's missiles.

For reference:

• Speed of sound in Earth atmosphere around STP is somewhere around 340m/s, Nebulous' missiles would actually be subsonic.
  
• You could outrun N's missiles with WWII era early jetfighters.
  
• You could outrun any of Nebulous' alleged spaceships with a fucking car, given good road.

So basically, the

is:
The game is navy guy's attempt at translating his autistic wank over modern naval warfare into a space tactical game, with a lot of good work put into the former, but only cursory amount of effort into translating it into the latter.
Which is a fucking shame because a military guy genuinely trying to understand how to apply his experience to starkly different realities of space combat (rather than copying it over verbatim, whether it makes sense or not) could result in some quality shit.

 

[Yaar Podshipnik]

I also think there is another reason why most games keep velocities slow: programming difficulty. If you use floats for position/velocity (and most likely you are), you lose accuracy as numbers move away from 0. So clamping the velocities is a way of not having to solve that challenge. I think there were some KSP blogs about this long time ago, and how you need to apply some tricks to avoid objects jumping around space.
However, as DraQ said, it would still be nice if the guy made little bit more effort researching space combat, even if that was playing CoaDE or spending time on Atomic Rockets (which has a very, very, big section on space combat).

EDIT:
Now that I'm fully awake, here's some relevant info on technical challenges of simulating small objects (spaceships) in large environments (solar system)


Quick explanation of floating points:

(from Julia Evans, an awesome person)

Way more detailed explanation from the fantastic Fabien Sanglard (srsly, 10 minute read that explains this shit better than all my university books)

And if you are a programmer, and just need info on the fuckery that are floating points, I highly recommend the following series (C++ centric really, but useful for anyone using floats):
Bruce Dawson's Random ASCII posts on floats

You may all now go back to discuss space stuff.

 

[Yaar Podshipnik]

Realistic space warfare, or at least what we predict that would look like, would not make for good gameplay.

Good sir, have you heard of Children of a Dead Earth? It did make a rather strong impression of being good and incline among the codex cultured space and science enthusiasts (i.e. me, DraQ, and other posters from that thread)

 

[DraQ]

darkpatriot
I second COADE recommendation.

It's a bit janky, being a hyperambitious (see below) one man project, but it shows earnest jab at realistic space combat can be done and made fun even restricted to existing technology and trying to simulate everything from first principles (it's basically the kind of autism that can forge planes with its power).

 

[Joggerino]

Well, I guess Aurora 4x kind of tried a fairly realistic model for their space combat, but it causes all kinds of problems that make the game largely unplayable for most people. I haven't tried the new version though, maybe their have fixed their issue with turn lengths/frequency and combat.

They didn't...
And I also recommend COADE, it is hard incline of realistic space combat. The developer made an insanely detailed module editor that takes a shit ton of real life knowledge to manage.

 

[Alpharius]

I also think there is another reason why most games keep velocities slow: programming difficulty. If you use floats for position/velocity (and most likely you are), you lose accuracy as numbers move away from 0. So clamping the velocities is a way of not having to solve that challenge. I think there were some KSP blogs about this long time ago, and how you need to apply some tricks to avoid objects jumping around space.
However, as DraQ said, it would still be nice if the guy made little bit more effort researching space combat, even if that was playing CoaDE or spending time on Atomic Rockets (which has a very, very, big section on space combat).

Why not use something like BigDecimal in java? (i'm sure other languages also have similar data type, or if not it wouldn't be hard to make one).

A BigDecimal consists of an arbitrary precision integer unscaled value and a 32-bit integer scale
https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html

Should barely increase memory consumption, unless the devs treat each particle like an independent object or something.

 

[Yaar Podshipnik]

Good questions Alpharius!

Why not use something like BigDecimal in java?

• all the physics libraries I know of work on floats, double (or vectors thereof).
• BigInt is neither a cpu-native nor gpu-native type (though with some implementation, and to some large value you can benefit from AVX instructions in cpu) making it waaaay slower
• you usually don't need possibly infinite precision in a game.

(i'm sure other languages also have similar data type, or if not it wouldn't be hard to make one).

Yep, plenty of arbitrary precision libs out there. As to "it wouldn't be hard to make one" - naïve implementations, sure. Something that can actually perform decently is a different story.

If having to use this in C++, I would go with Boost.Multiprecision. You can see some performance comparisons as part of their docs. They don't look bad if you forget that you can't offload that shit to GPU easily. And I would do my own tests on the exact type of math you need.

Should barely increase memory consumption, unless the devs treat each particle like an independent object or something.

You need 6 numbers orbital parameters to describe a Keplerian orbit. Milimeter resolution in a solar system number gives you (roughly, napkin math), 54bits required to represent just one orbital parameters. So you could just use double for that and don't pay the penalty of arbitrary precision. You would still need more data for things like orientation of your object in space, etc. So this is not hopeless, BUT as your objects get bigger, the less of them fit in cache. Which means more fetches. Which means slower.

Not sure if that was covered in the video I linked, or I read it somewhere else, but KSP does the actual physics simulation (at least rails one) using doubles. It does need to drop the precision for the rendering part to float though, due to how the engine and gpu works.

 

[DraQ]

I also think there is another reason why most games keep velocities slow: programming difficulty. If you use floats for position/velocity (and most likely you are), you lose accuracy as numbers move away from 0. So clamping the velocities is a way of not having to solve that challenge. I think there were some KSP blogs about this long time ago, and how you need to apply some tricks to avoid objects jumping around space.
However, as DraQ said, it would still be nice if the guy made little bit more effort researching space combat, even if that was playing CoaDE or spending time on Atomic Rockets (which has a very, very, big section on space combat).

Why not use something like BigDecimal in java? (i'm sure other languages also have similar data type, or if not it wouldn't be hard to make one).

A BigDecimal consists of an arbitrary precision integer unscaled value and a 32-bit integer scale
https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html

Should barely increase memory consumption, unless the devs treat each particle like an independent object or something.

And this is your brain on Java.

On a more serious note, though, computers are finite machines grinding finitely represented numbers. Any arbitrary precision computation may necessarily need arbitrary number of cycles to complete.
If you're running an engine that ticks 30 times a second this is very much a Bad Thing(TM).

 

[Alpharius]

I also think there is another reason why most games keep velocities slow: programming difficulty. If you use floats for position/velocity (and most likely you are), you lose accuracy as numbers move away from 0. So clamping the velocities is a way of not having to solve that challenge. I think there were some KSP blogs about this long time ago, and how you need to apply some tricks to avoid objects jumping around space.
However, as DraQ said, it would still be nice if the guy made little bit more effort researching space combat, even if that was playing CoaDE or spending time on Atomic Rockets (which has a very, very, big section on space combat).

Why not use something like BigDecimal in java? (i'm sure other languages also have similar data type, or if not it wouldn't be hard to make one).

A BigDecimal consists of an arbitrary precision integer unscaled value and a 32-bit integer scale
https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html

Should barely increase memory consumption, unless the devs treat each particle like an independent object or something.

And this is your brain on Java.

On a more serious note, though, computers are finite machines grinding finitely represented numbers. Any arbitrary precision computation may necessarily need arbitrary number of cycles to complete.
If you're running an engine that ticks 30 times a second this is very much a Bad Thing(TM).

Yeah, just spin up one more instance in aws if the code is slow. :D

Well the precision is arbitrary if you don't define it, all operations may be performed using the same precision as double has (64-bit IEEE 754), though it takes more lines of code. So i may be talking out of my ass here but i think it could be said that big decimal is a generalization of double. So if not for hardware optimizations and all the libraries using double it may have been not a terrible idea to use something like big decimal instead of double. (With quadruple precision or something.)

 

[Norfleet]

There's also other practical reasons for relatively low velocities, and by relatively low velocities, I mostly mean acceleration: It makes it much easier to have a reasonable idea of where the object is when you're lagging by 100ms to the server. If objects can change their velocities very wildly, resulting in very unpredictable positions, there's just no way this will make for satisfactory network play. If objects can also have extremely high relative velocities to each other, it greatly complicated collision-checking because objects can simply plow entirely through each other during a single simulation tick.

 

[Retardo]

So, has anyone tried it already?