Does Unity make game dev too difficult?

I did a Doom Level 1 (original) remake in Unity (unity package file included for free) ...

https://arowx.itch.io/doom-retro-remake-level-1


The title Screen shows the 3d level made in blender.



And in game screenshot with UI and selfie camera shot.

It only took about a week, a lot of the time was spent learning how the original Doom level worked and building it up to look similar.

And realising that Unity Navmesh does not do elevators or moving platforms...!

However if you consider Wolfenstein 3D and Doom they both had lots of levels and used the same level editor to make their level files or WADS.

I think that's the gap in the Unity way, it's open sandbox nature does not really set you up to make a great level editor.

The component/sandbox model of Unity may be at odds with a data driven/level editor approach to making games?

Or take the modern version of Doom the dev team includes a level editor which lets users quickly build up their own levels from elements.

Unity has Scenes, Prefabs and ScriptableObjects but it could be argued they are not ideal for making quick, easy and compact data driven levels in Unity.

Then if you consider the static elements in Unity, lighting, GI, colliders, navmeshes, it literally forces you to build each level one scene at a time.

If you have any experience with Prefabs, they are great to start with but only really work with one level of hierarchy as any form of nesting and they don't work. Imagine you give guns to your soldiers, then you decide to change the gun prefab so it has a different scope and a bayonet, in theory you just change the prefab and voila. No, you have to change the soldiers unique gun prefab.

And both Prefabs and UI don't have any kind of styling system e.g. changing the colour of the chairs in one room only or the font in all text in a menu.

I really do think Unity could have a much smaller lighter faster better level loading system, think about it for small levels a 16 bit float Vector3 or if snapping is used a 8bit Vector3 could be used to locate the elements with a similar precision rotation vector and an ID value for the object and you have the start of a tight level loading format. Add in some additional options for repeating things with offsets and you could be churning out levels a lot faster and keeping a very tight memory space.

The next problem is Unity really doesn't give developers much control on how things are packed into memory...

Apologies got off on a bit of a rant there... Unity could make level editing/prefabs and the data driven/memory storage aspect of games a lot easier IMHO.

 

You tried to do a remake.

If you recall feedback on your thread - it feels and looks nothing like the original.

 

No apology needed. This is all great stuff man and I think the only replythat actually addressed some of the bottlenecks in building such a game in Unity.

Thank for that. If there is anything else you want to share about challenges you ran into while making your Doom clone in Unity feel free too. It's not about bashing Unity so people shouldn't take it that way. It's about using the best approach in Unity to make the development as easy and fast as possible with basic (but complete) graphics and animation and whatever time needed to iterate on graphics and audio left for the end. That can be done whenever.

 

From my own experience I think the gap (between where it is and where I think it should be) in development productivity comes down to two things:

1. It used to be the first thing I would do for a game is build tools that were needed to make it as easy as possible. Or enhance and earlier tool. If all tools were already in place and fine that is the ideal. I don't do that in Unity simply because I find it odd to approach building tools in it. I think I keep expecting any such tools should already be in place. lol

2. As someone mentioned I think a great increase in productivity would be found in a more specialized game building approach. For Unity that would be in some kind of asset store kit that allows a person to rapidly design the levels and work with that data later. Of course this should all be done in as open of a way as possible so the game can be enhanced easily.

 

It's called artistic interpretation, anyway if I got too close to the original they could just DRM block it!

In hindsight a lot of what a game does is event/reaction management...

if X hits Y do damage and particle effects and if dead run death animation on character.

Which is fine when you only have a small event/reaction matrix but as a game grows even adding a single new event or reaction is multiplied in workload by all the things it reacts with. E.g. if you have a 10x10 event matrix adding one new thing means dealing with potentially 11 new interactions.

So you go to the 10 pre-existing things and their OnCollision/OnTrigger events and hard code to detect the 11th interaction and it's effects. Then do the same for the 11th element for all pre-existing things it interacts with?

The closest thing to this is the physics collision matrix. Maybe an interaction matrix UI could work.

So maybe Unity needs to look at ways like level editing, prefabs and event/reaction aspects of game development as ways they can reduce the complexity of game development in most projects.

Side note would OnTrigger/Collision events work better if they could take generic types as opposed to game or collision objects?

So an OnCollision(Ork orkHit) method where you don't have to work out what was hit could massively reduce the interaction code complexity?

 

-_-

As long as you haven't ripped any assets and recreated them by hand, they wouldn't. There's already a remake called FreeDoom.
------

Either way seeing this "remake" makes me want to drop everything and redo it properly.

Does anyone think if a retro shooter clone would be worth anything on asset store?

 

Unless it was going up as a free training project, I kinda doubt it. It seems like it'd be a little too niche as anything else.

 

If you wanna make a retro shooter, make it for gamers not for gamedevs.
"Strafe" just recently released and its reception didn't seem too positive. If you think you can do better, go for it!

 

You have a point, but I already have two "stuck" projects and return prospects for the time invested don't look good. Then again, maybe I should just say "screw it" and just go for it.

 

If it is something you'd enjoy and you can do a good job on it then do it. At the very least it means you then have one solid asset on the store with the potential to make money. As long as it stays in your mind only it definitely won't and can't make money.

Also potential to help many people with such a thing I think. Heck I'd probably be willing to partially subsidize development via Paypal $100 to you. A tiny amount but the asset be yours and yours alone. I'd just be providing motivation in the form of a guaranteed one sale of $100. I don't think you should price it quite that high just high enough there is not a flood of people making such games. lol

 

Is this just aspects of complexity management in game development, maybe a Data Driven approach to:

• level development.
• a 'prefab' system.
• a style system.
• event/reaction iterations.

Maybe if Unity or the community made a multi-level game like Wolfenstein 3D (60 Levels) or Doom (40 Levels(?)), and focused on setting up tools/systems that make it easy to build a game.

What other aspect of game development give rise to complexity e.g. Adding More Game Mechanics, Character Interations e.g Dialogue.

 

I think the things you listed would help decrease dev time. Ideally creating the levels should be incredibly fast at least fundamentally speaking. Of course level design to create interesting levels goes into the realm of art and any additional time spent on that is solely up to the developer. But technically speaking it should be a very rapid process.

As far as what else adds complexity (or at least time).... everything. Interactions, relationships between in game objects, etc. Much of this is still up to the developer as far as how much time to spend on each thing.

If just the basics... and this is what W3D represents to me... a very solid example of the most basic FPS that serves as a fantastic foundation on which to build. If it could be knocked out in say 5 to 10 hours... well that is where I'd like to see game dev be. Because then even the most part time hobbyist developer can tackle games with a decent scope without getting bored and burnt out.

Some ways to get there would be to greatly optimize the level creation. Perhaps even to have an automated system in place choose 10 rooms and it is just created instantly and randomly. Sure it might take either 20 clicks to get something a dev personally likes OR more descriptor params fed in to begin with but this is the kind of thing that would save a lot of time.

Level population would be the next thing to focus on I think. Again maybe make it so the levels are populated in a controlled random way based on a set of criteria... perhaps ability to mark rooms and sections of corridors with an importance value 1 to 5. Then the rooms and areas with 5s I'd expect to see populated with tougher enemies or at least more enemies. This kind of thing.

It just seems like for all of the years of effort in game dev little focus has been placed on these very basic yet so very important things. We've seen a ton of focus on visuals but hardly anything on the guts. Although World Machine does some of it for terrain we need more of this kind of thing in general and also covering inside areas such as room and corridor levels as well as covering more than just the "looks".

Or actually I should say a huge amount of duplicate effort has been poured into these fundamentals but very little in the way of reusable processes and tools have come out of all of that effort (probably hundreds of thousands of man hours by this point). It's like each person has to do it all over again. And that seems like a bad thing to me.

Just my 2 cents.

 

Because it's different for every game. If you try to make general-purpose tools, then you just end up with GameMaker, where the very first thing you do after learning it is bump up against the hard-coded limitations. Come on, it's really, seriously not that hard just to write some scripts. It's plenty easy enough.

--Eric

 

I think this is basically the canned response to such things which is part of why the process doesn't improve as much as it could. Everything is "not that hard" but that doesn't mean there is no value in improving upon it and making it incredibly fast.

I could define all of my levels for a game in code using either arrays or strings. Have done it many times. It is not hard. But it is faster to use a tile map editor especially as the data needed increases in complexity needing layers for enemy spawning, collectible placement etc.

Very few things are so hard they cannot be done. It is more the amount that has to be done just all adds up to more work and time required than it should be IMO.

 

The problem is that every out of the box solution to gamedesign-problems does so many things more than your specific usecase needs, that it's hard to get a grasp on- or adapt them. Also they are all designed to be so generic and encapsulated, that you can't use them any other way than intended. And if you want to do anything massive with thousands of enemies in a level, you'll quickly find that basically none of the assetstore solutions for common problems perform well enough on that scale.

 

For the most part, it's as easy as it should be. Attempts to make it "easier" from here just end up in GameMaker territory, which is counter-productive. I think you've lost sight of the goal, which is to make good games for players, not necessarily to make it "easy" for developers. Obviously anything that actively helps developers make good games is welcome, but making things "easy" merely for the sake of being "easy" is not. Again, GameMaker. (I'm not actually knocking it, it has its place, but Unity isn't GameMaker nor should it be, and I'll always push back against attempts to make it so.)

--Eric

 

Its easy to make terrible games, hard to make good ones. Hard as in that it takes time.

 

Okay I am the only one with this view. I definitely don't understand that because generally I like taking a code oriented approach to things that is seen as doing things the hard way around here. But I do that for fun and because not taking that approach has very little benefits I can see as far as productivity are concerned.

However I can also see other ways of doing things that would make a non code oriented only development approach appeal to me. But there has to be a reason for it. And I gave examples above of things that would provide compelling reasons.

Truly I guess I just don't understand why anyone would be concerned about making game dev faster. With that mindset there should be no Unity asset store at all. No products available to remove various parts of the overall workload. Just really makes no sense to me. But everyone of course is entitled to their own views.

 

Unity is easy and deep. It's easy to make something decent quickly when you are clueless, but when you get some skills you realize that you can make basically anything you want.

 

The reason it doesn't make sense is because you don't seem to be reading or understanding what I wrote. Nobody said anything about not making game dev faster, that's just a straw man. The issue is that you seem to want to make it faster just for the sake of making it faster, at the expense of flexibility. As far as I can tell your goal is "make game dev faster", not "make better games". I'm all for streamlining stuff, but it has to make sense and provide actual benefits. Ending up with a GameMaker clone is not a benefit.

Also, no matter what you do, it will always be somewhat time-consuming to make games: When you raise the bar, then you have to subsequently put more effort in to get noticed...what used to be "good enough" is no longer good enough. It used to take months and months to make a game like Pac-Man, and now you can do it in a matter of days or possibly hours, but nobody will buy it.

--Eric

 

To recreate the whole of Wolfenstein properly it would take months, maybe two minimum I reckon.

 

I thought the idea was to improve Unity to better handle the areas of game development that increase complexity and compound the work needed to make a good game?

This should be the main focus of any good game engine IMHO.

Unity does quite a good job of it but to claim that there are no areas where Unity could be improved seems naïve, especially from such a long standing member of the community.

 

I could not recreate Wolfenstein 3D in any amount of time.

The reason is because I suffer from a condition many of us hobbyists are all too familiar with: uncontrollable scope creep (USC). Every time I start a "simple" project, I plan and start thinking of features that will make it fun and cool. Next thing you know, the game is more ambitious than most AAA games I play. So I prune it way back to make it manageable, but then I can't get excited about it because it seems lame and uninteresting. So I try thinking of a way to integrate just one cool idea that will make it engaging, and next thing I know, I've got a huge list of things that I'd have to add to support that feature...

I can't clone a game. Even as a technical challenge to myself. It just doesn't interest me. I want to create something new and unique, and as such there's a real possibility I'll never finish anything again as long as I live.

This is my curse.

 

how to faile faster maybe? i am sure there are room for improvements there.Want something better? Go slower..

 

This is exactly what I think. And I don't understand anyone not viewing it this way. Nobody is talking about making Wolf3D to sell or making game dev faster just to make it faster. Well ok yeah I think it would be fantastic to just have it faster period.

The point is the faster a game like Wolf3D can be completed the faster you have a solid base on which to build. If you're wanting to make a game much more involved than Wolf3D how can it be anything but helpful to have the engine and tools be improved to the point where Wolf3D can be knocked out in a week or two by anyone and everyone?

This is a starting point on which to build and do other stuff. And people can take it in many different directions. But how no value can be seen in such a thing I don't get that. It should be common sense. If creating a certain scope of game on average takes 2 weeks instead of 2 months of course the former is better. It means we gain 6 more weeks to add more stuff, polish or whatever. Basically we gain 6 additional weeks to make the game unique and customized to our own design ideas.

 

Again, straw man, and a blatantly false statement. Nobody ever claimed that.

Also, though this point has been made before, there's some disconnect with what actually takes time to make. It's not really the initial coding, it's the polishing/iterating. Therefore it makes sense to have features such as variables in the inspector that can be tweaked, so instead of "change code, wait for compile, test" you just do "change value, test immediately". This is the sort of workflow improvement that actually makes sense, because you're not sacrificing any flexibility. Wanting prefab systems for the purpose of making things faster/easier does sacrifice flexibility, and the end result is not better games.

--Eric

 

Unity is simultaneously amazing and terrible, but mostly amazing. We've seen a huge boon in the "indie" gaming world and much of that can be attributed to the ease of which tools like Unity have made making games. But Unity is a general purpose tool, and will always loose to a game engine & tool set explicitly built to make the game you want to make, assuming it's already written and you know exactly the game that's being made, and that's never really the case apart from "remake game X" or maybe "make expansion to game X".

The real problem is finishing a game is really hard, regardless of the tools you use to make it. Much harder than most people realize, especially with how "easy" games seem to be to make now. This element is greatly underestimated, on top of how much work there actually is in fleshing out a game fully. There's always those handful of features that "if I just have a little more time" you could get in the game, but you'll just come up with more once you do. And after working on one thing for as long as it takes to actually make a full game it's hard to keep the enthusiasm in continuing to work on it. At some point you just have to start cutting off parts of the game and polishing what you have, and no tool makes that easy.

There's been a joke in the games industry for a long time now that goes something like this: "we've finished 90% of the game, we only have the last 90% left!"

 

The joke I heard in the industry, and that was before the indie boom:

- 90% of project that get pitch don't get greenlight
- 90% of greenlighted don't pass design phases
- 90% of designed game don't get to prototype
- 90% of prototype don't get into production
- 90% of production don't get finished
- 90% of finished product don't get promoted
- 90% of promoted product don't met ROI
- 90% of profitable project don't meet enough success for a sequel or even sustaining the company.

I feel less bad for failing with that in mind lol.

 

I don't think this is a joke. Sounds pretty realistic.

 

I found one very nice looking Wolfenstein 3D inspired game created in Unity.

Be interesting to get their input but I can't get a match on the combos of user name guesses I made here.

Something like this is a great example. Already looks fantastic and seems like an extremely strong foundation to build on.

 

I probably have less experience than any "forum regular" here. I downloaded Unity only a few years ago to make the open-world Oblivion-esque surivival sim with real AI and ecology. I had no programming experience beforehand, at all. No real art experience (though I'd tried to use Blender once or twice). Stumbling around with that project and one other (my smaller walking sim/puzzle game) is where I've begun.

I've gotten to where I know a bit of coding/scripting (with help, I've made a CA program in Unity that works great). Still have almost no skill in creating art. But I don't work on anything (outside of my CA program) for months at a time--it's been months since I added a single thing to either of my main projects. When I do actually work, and come across a problem, typically I find an answer and implement it rather quickly.

I actually did make a small little 2D platformer demo type thing (Forerunner Pique). It was fairly simple, where you just run (run/jump/glide) across a mesh made of words and collect these orbs to progress. When I made it I didn't work on it every day, but I finished it in about two weeks--and that includes other game stuff like a special "audio player" gallery page (for my own music) for example. That seems like kind of a long time to me, but I imagine tracking the hours working it would be shorter than it seems.

Could I make Wolfenstein in a month? I honestly don't know. I would say maybe not, because I don't have any experience making shooters, or enemy AI/pathfinding. I imagine both of those would be the bulk of my learning experience. But I might be selling myself short there, simply because I don't know what all it would take.

How many hours a day is "one month" anyway? It might be better to work with hours like Not_Sure uses for his open-world RPG thread. I would like a way in Unity to log your "active" time in the editor/script editor to see something like this.

 

I think it is partly Unity fault that a lot of skilled dev nowaday never complete a game.

Before Unity, it takes a lot of knowledge for someone to make a simple game. So you receive a lot more positive reaction from people and feel pretty good about yourself just by making a crappy game.

Since Unity - and the Asset Store for that matter - common game genres become way too easy to make, a lot of people can do it, so there no point for me to make another FPS or whatever: there no reason for people to check out my game, they don't want to play a game that feels exactly like 100s others before. I also don't feel good about myself from making something everyone can make. So just stop making them altogether. At least until I figure out something new, something can give me that great feeling every time I complete a feature.

 

There is another aspect to game development that is not covered well at Unity...

It's all smoke and mirrors and Unity's sandbox tricks you into thinking it's not.

Think of a old school scrolling game, the game holds the larger than screen level in memory and only displays a small area on the screen the off screen information is just data.

The 3d equivalent would be occlusion culling where only objects in sight are drawn.

And just like the screen is the limits of the 2d game all 3d games have to fit within a precision box of about 10,000 units radius from origin.

All those huge world and space games use smoke and mirrors to give you the experience of moving within a larger world when just like the 2d scrolling game they are streaming in assets and scenery and ensuring the player stays within this precision sphere.

I have attempted to get Unity to push for larger worlds in the engine and especially for me in the learning section, they could make this less of a dark art and just another aspect of complex game development made easier by Unity.

Although this leans again toward dynamic level data and away from static fixed scenes.

 

ArrowX, rather than "trying to make unity do something" a much better idea would be to concentrate on making games. Games are always made using tricks and workarounds and there's nothing wrong with that. Trying to "get a company do something" sounds like an extremely unproductive affair, similar to trying to convince mountain everest move to london using diplomacy.

At the very least if you want something done, implement it as an asset, publish it to the store, and if the stars are right, it'll get incorporated into the engine. "They should implement X" is pretty much attitude similar to being an idea guy.

IMO.

I'm planning to start working on the doom-styled retro-shooter next week. Will probably make a WIP when I have something to show.

 

Me outside of Unity, no access to core engine code. Getting Unity to handle large dynamic worlds or even streamed static worlds would need under the hood work for it to go smooth. All of Unity's lighting, navigation, batching technology rely on things being static. Unity is probably heavily optimised to do small static levels (<10km from origin).

For instance one way to do a larger world is to keep the player static and scroll the world under them, think of the cost of moving all those transforms and rigidbodies every frame. Some things need to be built in from the ground up to work well.

If I were in charge the next Unity demo would be a space/flight sim that allows players to fly from the Moon to the Earth in a spaceship. It's doable but it would really push the engine in a new direction and I think it would also push the Unity engineers to think out of the box.

 

Laughably small on modern hardware. There are multi-teraflop gpus, you know?

It can already be done and wouldn't push unity anywhere.

You don't need source code access for most of the things you ask for. You have native plugin interface, and you have scripting tools, and rendering pipeline. That's all you ever going to need. The rest - for example, looking for a way to make your spacesim happen - is up to you. It is your job to use provided construction kit in a way that that makes your project happen. Saying "but unity doesn't do X" to me sounds like an excuse to do nothing.

You appear to be asking for a ready-made solution for everything. That's not how frameworks work, in general. You're always given a kit, and it is your job to put the blocks together to make what you need.

Speaking of which, there are engines that already provide source code access. You could try implementing in them and see if having access to source code helps at all.

 

No transforms and physics in Unity are done on the CPU. Also Nvidia's PhysX sdk that Unity uses does have an origin shifting mechanism only it does not surface in the Unity API.

Probably because of the inherently static nature of Unity and it's lack of multi-threaded transform operations, which Unity is working on and recently demonstrated, the shoal of fish demo.

I have my fingers crossed for a large world update to Unity some time in the 2017 roadmap.

 

It is still laughably small number for a modern system. How many objects do you have in the scene, ten billion?

ArowX, at this rate you'll be sitting with fingers crossed for the rest of your life, waiting for some new magical feature to get implemented.

Conditions will never be perfect, all the cool technologies will never be available, because program development is never finished. The idea is to make things happen despite that, by utilizing what you already have right now.

I see "But unity does not have multi-threaded transforms", "but unity does not have this" and "but unity does not have that" as excuses made in order to do nothing. I.e. procrastination. Instead of convincing yourself, that your project can never be done because of lack of some minor feature (you probably don't even need), the idea is to try to make it happen, see what limitations you hit, and see how you can work around them. "No feature X, so I give up" is a bit premature.

 

@Arowx, I know that TerrainComposer2 uses multiple terrains for large maps--which can be streamed in and out. Would something like this be what you're looking for?

It's not exactly the same thing as the floating point precision issue, but it is definitely related to the open-world/large map thing in general.

 

You cannot blame Unity for that. All games are based on tricks to push the limits. The best games have always been the ones that pushed the limits way past what anybody thought was possible. For example, the original Doom (1993) delivered a 3D environment on desktop PCs that were not designed to handle games. Simple 386 computers with standard VGA graphics.

Stop blaming Unity for not holding your hand and guiding you through all of the tricks. Stop assuming Unity should deliver some ultimate sandbox environment. If you want to build a massively scalable game, you need to figure out what tricks you need to build to deliver your vision of your game.

 

In my defence...



A space to ground flight sim, the difference is the entire game fits in the 10k precision sphere. Hopefully people who shoot off into space will think the camera shake is because they are pushing too far.

If you try and build a large world in Unity even just getting the cameras viewing distance large enough to cover the world without near objects losing precision is an issue. Even here I ended up using a two camera rig, one over cockpit range and the other covering long range.

Don't just slag me off try a 10km map, start low poly and you too will see that Unity could do with a large world setup and features.

That's the kind of thing but it needs to be a built in feature set. 2D anyone can do an endless runner or procedural universe as they are naturally limited to the screen space. 3D there is a lot more work needed and you hit a lot more issues with all aspects of Unity that start to work against you.

Don't take my word for it try it, the first one to get a lowpoly to scale Earth to Moon simulator working is the winner go. We can argue all day and it's boring, if it's so easy show me how to do it? *

* Posting the Kerbal Space Game Dev video does not count they built a whole new 64 bit gravitational physics engine on top of Unity as well as a planet rendering system.

 

You can already do what you described using various tricks. Kerbal was developed in Unity, and it allows for Earth to Moon travel using a space ship.

The bottom line is that games have always been based on very creative smoke and mirrors. Games are not simulations, and the engine is not responsible for making massive scale games possible. This concept has repeatedly been explained to you in a bunch of forum threads already.

If Unity gutted their engine engine and rebuilt everything using 64bit vectors, then you would complain that 64bit is too limited and Unity should have used 128bit vectors. Again, this is because you have not yet accepted your own role as chief architect of tricks, smoke, and mirrors for your own games.

 

What is the max range from origin in disputed space, or what is the max size of your battle space in Unity Units?

 

Yet other engines have 64 bit floating point added to cope with the demands of a space game or implement large world systems.
Valkerie an open world space VR game originally appeared using Unity then took of and moved over to another engine that just happens to have source code access, ideal for implementing larger world spaces under the hood.

IMHO these features need to be built into the game engine. Without them Unity is limiting what it can do.

 

In Disputed Space, I designed each subsystem to encourage the player to stay near the origin. Even the hyperdriving between different star systems occurs at the origin. Everything is handled dynamically. There are no static scenes. I developed systems for managing everything instead of relying on Unity's static scenes.

 

So 10,000 Units is 10km if you use meters as a Unit, how big are your ships and what speeds can the ships, missiles or bullets go at before there are problems?

 

Even in Valkerie, I bet they used a bunch of tricks, smoke, and mirrors to deliver that experience. The issue is not about 64bit, since even 64bit has a limit. If you want vast space to explore, you need to decide what tricks you want to use to deliver the experience to the user using what ever engine limits exist.

 

You are still asking the wrong questions. You can build an infinite universe with tricks. You can resize things and play around with field of view. You can run multiple cameras. You can even bake the distant objects into the skybox to improve performance.

In terms of hard limits, I try to keep everything within about 5000 units of the origin, and the center of every battle is always intentionally located at the origin. The speeds of objects is not a problem, because I developed custom classes for handling movements and collisions instead of relying on the stock physics system.

 

So you must be building to a reduced scale, as a dreadnaught or carrier class battleship e.g. Star Wars Star Destroyer's are about 1.4 kilometres long or 1,400 unity units?



How big are your fighters assuming they are launched from a carrier?

 

It is your fault. Use origin shifting, space grids, and high precision coordinates.

Elite and Elite frontier had galactic-sized maps. Elite ran on hardware without floating point support.

They don't. Unreal 4 is still single precision.

You need to differentiate between game world and rendering. If you have unusual requirements, then it is your job to feed the data correctly into rendering part so the gpu can handle it.

Also, IIRC most modern GPUs have poor double precision support. So, you can't blame the engine for it.

It is your job to set up multiple cameras that render scene in turns, displaying progressively bigger objects.

P.S. You do realize that at least some modeling packages do not support double precision calculations, right? 3dsmax, for example.