ED as a game engine

Imagine ED stripped down to the bare bones flight sim. Take away the economy, background simulation, power play, missions, ranks and rules. Fix the p2p network instancing model to allow for true mmo. Now imagine releasing this marvelous flight sim and universe as an engine for gamedesigners to build games upon! Think what great gamedesigners could come up with. Oh what amazing worlds and games could be build upon this engine.

Master of Orion(1993) in an ED universe? Sid Meyers ultimate space game? Raph 'Designer Dragon' Koster creating content and building worlds? I agree with Lee Hutchinson when he says: 'David Braben and his team at Frontier Developments have built the best, most immersive, most gripping "you are flying a spaceship" experience I have ever played...'. However when it comes to game content... meh

tl;dr old grumpy mans wet dream.
 
Fix the p2p network instancing model to allow for true mmo
It wouldn't need "fixing", it would need a complete game rewrite, and a lot of infrastructure investment. I'm not paying for that. Anyway, if I wanted to
anything, it would be a single-player space game with a procgen focus like that exemplified by No Man's Sky - planetside gameplay, huge space battles, AI crewmates, in-depth exploration and mining, an infinite variety of ships and gear... DBOBE has talked a good game with respect to the possibilities of procedural generation methods for years, but it doesn't appear that his PG chops or that of his company have improved a whole lot since FE2/FFE. I'd love for that to be inaccurate, so I hope that upcoming expos or newsletters show that some progress on those ideas has been made, even if there's no end product any time soon. Concept art and prototypes of volumetric clouds were fine a couple of years ago, but time waits for no man.
 
Last edited:
Problem is that the "flight sim" part of E:D is really arcady - to ridiculous extents, from the speed limit to the blue zone. We can get over that because the rest of the game is immersive enough.
However, when you want to have a game designer incorporate that engine, he always has to work up hill.

Plus, from a technological standpoint, it's really outdated. Still 32bit (we have 64bit in end user computing for a decade now), in many aspects single threaded and doesn't support multiple screens/MFDs. There isn't even a Linux port.
 
Plus, from a technological standpoint, it's really outdated. Still 32bit (we have 64bit in end user computing for a decade now)

The engine is 64 bit. The Mac build is for example 64 bit because you have no choice in the matter on OSX anymore.

The PC build is (currently) 32bit simply because there is very little benefit in doing a 64 bit build at the moment. There have been plenty of discussions about this on the forum with FD programmers giving their views on the subject.

...in many aspects single threaded...

"in many cases"? What about the other cases?

So multi threaded in other words... ;)

Seems to be utilizing my cores pretty effectively anyway.

...and doesn't support multiple screens/MFDs...

Source?

Or do you mean that the ED game client specifically hasn't full support for this? ;)

There isn't even a Linux port.

How has this anything to do with how "dated" it is or isn't?

However the Mac port has brought it closer to Linux so maybe if they find it financially viable to do so Linux might eventually come.
 
The engine is 64 bit. The Mac build is for example 64 bit because you have no choice in the matter on OSX anymore.

Have a look at the task manager - 32bit. Have a look at OSX - of course it supports 32bit binaries running in compatibility mode on the x64 plattform. What are you trying to sell me?

The PC build is (currently) 32bit simply because there is very little benefit in doing a 64 bit build at the moment. There have been plenty of discussions about this on the forum with FD programmers giving their views on the subject.

There is no benefit in maintaining a 32bit port that needs compatibility libraries etc. The amount of gaming PCs with a 32bit CPU is limited. That was the Athlon XP / (early) P4 era.
Trust me, if they would be able to compile in 64bit without problems, they would do it. Plus, it's usually rather simple to do that (I've ported many applications myself), which implies they have major code issues.

"in many cases"? What about the other cases?

So multi threaded in other words... ;)


Seems to be utilizing my cores pretty effectively anyway.

Hahaha, you really make me laugh ;-).
That is, while I see 1 core at 100% and the rest idle while the route planner is calculating for minutes and minutes while the UI thread, in which it is tied in (!) is ridiculously unresponsive.

Source?

Or do you mean that the ED game client specifically hasn't full support for this? ;)

Please play the game. You will find out that you cannot make use of a second monitor or connect other devices to the game - like we have seen in X-Plane for example. Seriously, why are we talking about this?

How has this anything to do with how "dated" it is or isn't?

Everything.

However the Mac port has brought it closer to Linux so maybe if they find it financially viable to do so Linux might eventually come.

If you code right, porting is straight forward. End users can do that (except for software depending on kernel, like drivers) No big issue. But if you lock yourself out by making poor design decisions, then everything becomes complicated.

So with all these issues - why should a game developer choose the cobra engine over something else?
 
Have a look at the task manager - 32bit. Have a look at OSX - of course it supports 32bit binaries running in compatibility mode on the x64 plattform. What are you trying to sell me?

There is no benefit in maintaining a 32bit port that needs compatibility libraries etc. The amount of gaming PCs with a 32bit CPU is limited. That was the Athlon XP / (early) P4 era.
Trust me, if they would be able to compile in 64bit without problems, they would do it. Plus, it's usually rather simple to do that (I've ported many applications myself), which implies they have major code issues.

Here you go:

Ben. Can you confirm the 32 or 64 bit build for us please?
You know I wouldn't be allowed to do any such thing. ;)
I guess I can tell you that we do both kinds of build. If the question is "will the released version be 32 or 64 bit?" I wouldn't even know the answer - whether we need enough CPU-side memory for it to matter, whether the cache-usage cost of 64-bit pointers is a visible performance hit, none of it really affects me. The shaders will be running in 32-bit precision either way, and it doesn't affect the addressable texture space.

That was way back in December 2013...


Hahaha, you really make me laugh ;-).
That is, while I see 1 core at 100% and the rest idle while the route planner is calculating for minutes and minutes while the UI thread, in which it is tied in (!) is ridiculously unresponsive.

"Minutes and minutes"? Calculating routes takes seconds for me...if even that...

And this example still doesn't indicate that the engine is single threaded...some specific calculation tasks might be, but that's not the same thing.

Please play the game. You will find out that you cannot make use of a second monitor or connect other devices to the game - like we have seen in X-Plane for example. Seriously, why are we talking about this?

I do play the game...quite a bit actually. It's a game where one of the core design pillars revolves around it taking place from the eyes of the commander. As in you sitting in the pilots seat looking out into the ship. That is why you look around your ship to see the different sidepanels. This to easier tie everything together when first person gameplay comes along. Having multiple screens doesn't really fit this design since that would move elements "outside" of the game into secondary monitors instead of keeping these elements within the gameworld.

That is the main reason why secondary screen support is such a low priority.

So with all these issues - why should a game developer choose the cobra engine over something else?

I don't know (or care really)...that wasn't what I was responding too earlier.
 
why should a game developer choose the cobra engine over something else?

Because they created it? It's good to see the confusion over the differenced between 32 and 64 bit yet again, let me quote Mark Allen here as only Alpha backers can see the archived post:

Internally we have full support for 64 bit client builds (several of us develop on them by choice). Whether we'll ship that for the client in Alpha 4.0 I don't know - there are reasons for and against, but for now that's a discussion I'll leave well alone .

What I wanted to say: Being on a 32-bit OS doesn't stop us using the benefits of 64 bit where they matter (for now). Specifically I'm talking about 64 bit floating point maths, which you need the precision of to represent the sheer scale of things in space. Seriously, it's nuts.

Doubles (64-bit floats) are perfectly fine on 32 bit machines - they've been used for years. The processor will handle each 32-double vs 64-native slightly differently, but the precision & results we achieve are the same. There's performance trade-offs, but contrary to popular belief 64-bit is not strictly faster - for example doubling the size of your data types has serious impacts on memory bandwidth!

Where 64-bit flat out wins is memory - that 2GB (sort of) memory limit for 32 bit processes is much harder to get around :p, though it's not a problem we're running into atm so there's no drive to switch there. I suspect there will be in future though .
 
Because they created it? It's good to see the confusion over the differenced between 32 and 64 bit yet again, let me quote Mark Allen here as only Alpha backers can see the archived post:

Ahh...there it is! The post I was looking for...had to settle for that other one. :D
 
Well to be fair it was a post from Yaffle that I nicked it from, not that this misunderstanding of 32/64 bit happens very often... ;) The Google site: option won't pick up my own Alpha forum access so I had to fiddle it a bit.
 
Last edited:
Back
Top Bottom