Massive World or Space Challenge

OK I'm concerned that Unity with it's 32 bit floating point precision and Physics, is limited to small worlds.

I have argued the addition of 64 bit precision to the engine on a separate thread. But this has bogged down to different binary camps 32/64 bit.

So how about we have a Massive World or Space Challenge.

Can you create a Massive World or Space using Unity, that a player can traverse quickly, ideally using a vehicle and have working game physics.

So what scale would be massive, well solar system spanning, planet spanning or just 100km² or greater.

If you don't think it can be done in Unity check out Kerbal Space Program and Homeworld: Deserts of Kharahk.

There are basically two ways to make a massive world, you can tile it and shift the players origin or adopt a higher precision system to simulate your world.

Ideal game themes for the challenge, Racing, Flight, Vehicular Combat, Space.

Think of those massive theme setting scenes in films that show an entire world that you want to explore.

The idea is to stretch what we can do with Unity and better understand it's limitations and share our experinces, what works and what does not.

And if you have an asset store system that can do Massive worlds, please show it off by taking on the challenge.

The Title of Unity Massive World champion 2016 can be voted on by the community.

Have Fun.

 

PS If you would like Unity to adopt big world 64 bit Vote Here

 

Is there cash/reward/prize/whatever involved?

It is doable, but as pure technical challenge it is not entertaining enough to bother.

 

All you need to do is get origin shifting in order and you're golden. From there it's just about managing LoD and not killing performance. There's nothing all that radical about it, it's just that there aren't many who would take on the actual challenge of filling that space.

 

Last time I tried to make planet-wise RTS, I got fed with units position in spherical coordinates (planets are round, you know) and trying to create a proper projection realtime so that fighting is actually interesting to look at(I don't like how planetary annihilation looks, honestly - it feels like planet is very small). Not to mention creating a map with runtime consistent terrain for whole earth(I didn't find a noise I like). So unless I have some huge incentive to continue that project, or at least someone provides me with lib for sphere-to-plane projections and nice noise to create a planet, I don't see reason to bring that monstrosity out and rebuild it. Besides it couldn't use any physics engine I found: what physics engine supports spheric coordinates, huh?

Otherwise propose a game design I'll like. If it's better and simpler than what I'm doing right now(won't tell you what before I make playable demo), I'll consider changing my hobby project to that.

 

Come on if it's that easy do a quick large world demo, nothing fancy programmer art is fine.

You could write an simple endless runner, it might not win but it would be fun to write and play.

I'm working on my entry as much as a learning exercise as anything else.

 

What's fun in writing game that I won't have fun playing? Where's fun in infinite runner?
I just don't have a game design I like that requires such huge world right now.

 

OK so what kind of Massive world game would you like to make or play?

 

Simple origin swapping isn't too hard, but usually projects that need it have other special requirements. Just look at some of the insane things needed to get the KSP world up and running.

 

Um... The problem is I don't know. For me it's what player can choose and what consequences that will have is what matters, not size of world. And biggest scale ideas I have are close to what Mount&Blade did: a world map and local(battle) maps where you don't need origin shifting anyway. Without that division they'll be non-playable as it'll take too long to get where player wants.

 

@Arowx great idea for a challenge, participation could churn out a few viable open world samples. I really wish I had time for it.

Make a platformer

 

Easy doesn't mean "quick". It is boring and tedious without any fun part about it, as far as I can tell.

I can see rough idea how this could be done (solar-system sized world with plantery landing), but there will be few obstacles along the way and those will take a bit of time to work around them.

So, why bother?

How the heck is endless runner related to 64bit floats and origin shifting?
It is a completely different thing.

Win what, exactly?

Suure. Planet-sized procedural worlds with cities where you can enter every room and floor.
This kind of project means at least half a year wasted on r&d minimum.

 

Maybe the infinite runner loops back around on the world after some point and saves the procedurally generated chunks?

 

Still doesn't require 64bit precision.

 

Optimist.

 

That's "at least". Also that meant working full-time. And nobody said anything about result being photorealistic, for example.

There are some papers floating around on the subject of city generation, so it is not like you'd need to invent everything from scratch.

---

@Arowx : I advise to take a look at last game jam. You see, as of now your challenge pretty much sounds like "prove that you can implement feature X!!!". That doesn't sound like a fun thing to do to me

 

Like Mercenary (8 bit game) https://en.wikipedia.org/wiki/Mercenary_(video_game)

or Elite II: Frontier https://en.wikipedia.org/wiki/Frontier:_Elite_II

 

Um... I think it suits "Massive world or space" epically good. Like it was an epical proportions world for its time. </sarcasm>

 

You know it just occurred to me you could use Daggerfall Tools for Unity as your starting point. It's MIT licensed.

https://www.reddit.com/r/dftfu
https://github.com/Interkarma/daggerfall-unity

 

I was actually wondering if there weren't solutions on the asset story already.

 

Only solution I am aware of is the one on the old Unify Wiki.

http://wiki.unity3d.com/index.php?title=Floating_Origin

 

Q: Any good C# double precision Vector maths libraries (SIMD/GPU?)?

 

If your endless runner requires a 64 bit transform you've got a lot more to worry about than floating point precision.

 

System.Numerics that is not shipped with Unity. And because it exists outside of Unity, finding vector math library will be quite hard.

 

Infinite (or very large) space is easy. Two cameras, a couple of particle fx and creative use of scale and fov and you're golden. Much like film and theater, it's just an illusion, you don't actually have to build everything for real, just the parts the viewer (player) sees.

 

For anyone else interested here is an article about double precision Vector3's http://www.codeproject.com/Articles/17425/A-Vector-Type-for-C

There is also OpenTK an Open Toolkit that has lots of 3D graphics features and double precision Vector3's it is also apparently very fast (something about hand optimised IL code!?).

 

Oh, if you need Vector2d and Vector3d they're here: http://forum.unity3d.com/threads/double-precision-vector3.190713/

 

Haha, of course not. I didn't see that part of the challenge. I think right now you can wander 10,000 or so units before things start to fall apart. I think you can only see what, 300-500 units away? A proper infinite world setup doesn't need much.

 

WIP 02

 

The challenge started already? How long is it? I can't even start until friday at 7

 

The screenshot doesn't really show the need for increased precision.

Take a look at Celestia and try to create something similar.

 

If you want to build a massive scale game, the correct answer is origin shifting. You don't need to overhaul the Unity engine to use all 64bit math in order to build a massive scale game.

 

Yeah can we use origin shifting and have an endless world? .

 

Only if the time-space procedural generator doesn't explode.

 

Hitting quite a few problems, Unity with 32 bit can only really work in a 10,000 unit cube.

So the Kerbal Space Program multi-camera approach is probably the best way to do it from this side of the source code.

The idea is to have multiple cameras e.g.

Camera A: Scale 1:1 / 1m-10km (Local)
Camera B: Scale 1:1,000 / 1km - 10,000 km (Planet)
Camera C: Scale 1:1,000,000,000 / 1,000,000 km - 10,000,000,0000 km (Solar System)

Can you see the problem we need a system that can transition smoothly from C to B to A as the player flies about the solar system.

So a 64 bit vector representation is needed.

Also consider Jupiter, it is about 70,000km so even in scale B it would just appear as a patch.

But the current terrain system which does update it's mesh LOD based on distance, does not allow for easy mapping to a sphere or torus.

So I can see why not many people have tried this and hat off to Kerbal Space Program as they have done a good job.

But even with this simple example you can see that I need to keep 3 separate camera/scaled/scenes updated with relevant models being mapped and presented into the next scene down as the player approaches them. And the hardest part is the terrain to orbit or orbit to terrain phase.

I'm not sure that my scaling system is good enough, everything in the 10km range would look good then it would drop to 1km 1 unit resolution which would not look very good. So maybe we need a camera between A and B so we can have a better 10km+ resolution e.g. 1:10 gives us 10km to 100km range at 10m scale.

So in 32 bit Unity we probably need 4 camera scales or scenes to present a good 64 bit prepresentation of the Solar System as well as a planetary terrain LOD tessilation system.

It was fun playing but in 32 bit there is a lot of overhead introduced, that could be simplified out if the engine provided the option of 64 bit transforms and cameras.

 

And it begins anew...

You didn't think that if you just cast double Vector3d position into float Vector3 of transform with origin shifting for cameras A and B, you won't see problems in any of them visually?

Yes, you can't use PhysX/box2D there, but let's estimate what you actually need and can do.

Forces calculation requires F=ma and vector summing - made manually in 10 minutes. Rotation force calculation is harder, so you could create physics objects without position change and just rotate them and apply rotational forces and then copy rotation result.
For collisions you could make bounding box collisions manually and if they succeed you could create small subworld outside of floating point errors(allocate 100x100x100 units of space for that physics simulation, scale physics models and let PhysX do the work - just make sure when object is exiting that 'scene' you remove it before it affects other 'scenes') and simulate actual collision there then reflect result onto your double precision - it would require several hours of work writing manager that will allocate subworlds in physics space, watch when actual objects could collide in theory(bounding box collision), watch object not leave that virtual subworld and clear them.

What else does physics engine do? I don't think I know anything else.

Total workaround time: about 4 hours +50% would be 6 hours - that's my estimation.

P.S. Also that's exactly why I want PhysX scenes. That manager's writing will be "just create PhysX scene and it works on 32 bit processors in all cases" instead of several hours of work.

And no, I'm not going to do it as I don't see any reason to.

 

Arowx: Multiple cameras and multiple scales is definitely the way to go, regardless of the underlying precision. Remember that a game is smoke and mirrors that functions well enough to deliver the intended user experience. A game is not an ultra realistic simulation that burdens itself with heavy internal calculations just for the sake of pure accuracy.

64bit vectors are not needed in the engine. You can use your own 64bit vector system for storing your own data models, and then you can convert that into the 32bit vectors for rendering nearby things in the engine. If you want to build a massive (nearly infinite) universe, then you will need to develop your own custom data model for delivering the correct smoke and mirrors solution for your specific game.

You cannot expect the engine to be completely rewritten to use 64bit vectors. That change would currently cause the engine to use more memory and CPU cycles, and very few games would immediately benefit from that change.

For a nearly infinite universe space game, design a layered coordinate system. Have a data set that stores the positions of all of the solar systems. Then within each solar system, store all of the positions of planets relative to the star. Then for each planet, store all of the positions of the moon, local asteroids, and any other debris relative to the planet. If you want to land on the planets, keep building layered data solutions for those things as you move in. For example, storing the locations of continents, cities, mountains, and oceans. Then within each city, store the building locations. Within each building, store all of the internal structure data (rooms, doors, floors, stairs) relative to the building's origin.

And of course, you will need to be able to stream content into position as you zoom in and out. You won't be able to load all of the detailed city data for every city on every planet in your universe at the same time, because you will not have infinite RAM in any gamer's system. So you will need to take that into account when developing the solution.

 

I think that Unity could add 64 bit in a modular manner as a feature that developers could use, e.g. you toggle a scene as 64 bit. Like you say not everyone needs > 10km for their game. At the moment developers have to write their own bespoke solutions. A built into the engine 64bit/32bit option would open up Unity to much larger game worlds at a fraction of the development cost.

And that is really what Unity provides, a toolchain and engine that speeds up the development of and improves the games that people can create.

 

You can complete your game using existing solutions listed in this thread long before Unity would add that feature.

 

You could make that statement with a lot of things they're working on lately.

 

With large worlds, be it 32 or 64 bit precision, you have to cheat anyways or you will run into problems later on, on so many levels.

Seems like you just don't wanna do the work required for a game like this.

 

My understanding of those problems was broken on one of these threads. I didn't realize 'origin shifting' was moving things to zero. I've done that before. I think it's a great solution, maybe the only solution, to having a huge or infinite world.

Next problem: An infinite size harddrive to store your persistent infinite world! Or do like I do, and don't save anything. Save 1 "home" space that you can modify, and have the rest be gone forever when it unloads Walk back and forth or in 1 direction forever and continually discover new content!

 

Engine won't provide them, or will provide them when hell freezes over.

You don't need multiple scenes.

You can stick everything into the same scene and use different layers.

Infinite procedural world can be represented by ONE number. The number can be 32bit.
The number will be a seed for random generator used to generate the world.

The problem is saving changes to the procedural world, but there you can just limit number of changed blocks/sectors and discard the oldest ones.

 

That's what I was saying, saving the changes. to the blocks. Could tale up a lot of space in a voxel world.

 

Clearly you need to design a procedural algorithm where you can simply calculate a new seed to store the latest state.

 

Nah. Nigh impossible.

Might be a better idea to store changes to original world in the save file instead of dumping entire block into it. Then again, that'll most likely slow down world loading compared "store the whole block" approach...

 

Doesn't git do this?

 

Are you planning to save chunks of infinite worlds as a text file? Git is unsuitable as a save file system.

 

I'd save it as a tree of folders. A sector folder would contain several chunk files. Or maybe a sector folder would contain several chunk folders that each contained different text files that stored different kinds of information about a chunk. A few extra folders and files to greatly increase access speed

I probably wouldn't use a git-like approach for that. I could just save the states of things instead of an aggregation of changes.

 

I believe that in microsoft guidelines for optimizing games it was said that opening a file is an expensive operation. SOmething worth keeping in mind.