Is Unity right for me? - God/War style game

Getting Started
1

Hi all.

I’ve been playing with Unity 5 for a few weeks updating my c# skills and having some fun. I’m working on a map based god/war type game which would cover an area of 2000*2000 miles. My plan is to do this in 10ft resolution, so the map space is just over 1m units * 1m units (x, z). If I do it in 3d, the height / y axis would be about 5k (50,000ft). Terrain would cap out around the 2k mark.

There will be some 2000-3000 ground based objects (factories, airfields) of between 10u - 100u in size. These will need to scale up for distance viewing, but I will use camera clipping and blending to prevent too many from trying to draw.

There will be up to 5000 airborne objects (ok, probably alot less, but dream big, hey) with fairly low-res textures which will need to be scaled up or they’ll disappear. These may need to be 100u to maintain visual acuity. Again I’d clip these as appropriate, but the engine would need to manage these off-screen at all times.

The player would need to be able to move to any part of the map quickly, and the nature of the game would mean some of these airborne objects would converge in tight spaces. I’ve just been playing with spheres, and can happily get 1000ish into screen space without much of an issue.

I’m not sure I fully understand the issues with the floating point resolution at the edges, but I think it’s OK. As the edges will be max of 700k px away, I think that means my FP would be 999999.x. As I’m using the 10ft resolution, I’m more than happy with +/- 1 pixel granularity. Anywhere within that 10ft box is fine by me. If there’s a cumulative drift problem, then I might have an issue, so please correct me if my understanding is wrong. I won’t be using colliders, so accuracy is a minor concern from that point of view.

So, should I do it? Can Unity handle the beast? I’m at the point where if this is going to happen, I need to build a scenario editor to allow my database guy to get to work, but I don’t want to waste effort if it’s all going to go to hell in a handbasket when we stress the engine.

2

In a 3D game you can’t measure the size of things in pixels in any useful way.

The important question is, “what scale will you build your map at?” 1 unit of Unity scene space = what distance on your map? 1m, 1km, 100km? You need to find a balance that gives you the size you need without giving up too much precision.

You might need to build multiple representations of some things to work at different view scales. The LOD system might be able to handle this for you in some cases.

To answer your question, I’m pretty confident Unity can handle this. However, it’ll probably require a solid understanding of how things work, and quite possibly some custom systems. The general purpose stuff Unity includes is great for general purpose use, but it can’t cover every possible niche, so you might have to make some things for yourself or buy 3rd party solutions that suit your needs better.

3

Witcher 3 is only 136km^2, and they did crazy optimizations to get that. 2000mi^2 might be a bit of an over-reach.

http://gamingbolt.com/witcher-3-map-size-compared-to-gta5-skyrim-far-cry-4-new-screens-show-different-visual-settings

1 Like
4

That’s not the kind of game he’s talking about, though. How much space do you think the strategic map in, say, Medieval: Total War covers? (Both “the whole of Europe” and “a table” are correct answers.)

2 Likes
5

The total war series does not cover all of europe at the same time. Each map is actually rather small. If you’re talking about having an overland map where you drill down to smaller areas, then sure it will work, but it sounds like he wants to have a single large map. Whether or not he wants a game like witcher doesn’t matter, displaying that much area will be prohibitive. I’m not knocking the guy’s dreams, I have some pretty big ones myself. I’m just pointing out that the game that is currently considered the largest (not counting procedural infinite stuff) is a fraction of what he wants.

6

I did specify the strategic map, which does indeed cover the whole of Europe at once.

That’s the thing - it totally matters. It’s all about scale. In a game like The Witcher a building will be dozens or maybe hundreds of units across. It’ll be at a scale around 1unit:1meter. At that scale a world thousands of miles across is prohibitive like you say. For a game like The Witcher the scale is optimised for detail rather than size, because that’s what’s important.

In something like Total War’s strategic map, however, you can have a scale more along the lines of 1unit:10miles. Since you don’t need close up detail like The Witcher a you can optimise your scale for size rather than detail. For instance you can draw miniaturised clumps of low-detail buildings and the whole thing might be less than one unit across. Then making something 2,000 miles across isn’t that big a deal.

3 Likes
7

They also had a $32 million budget, which helped those optimisations become a reality.

1 Like
8

thanks all for your comments. I’ve removed references to pixels from the OP.

The planned scale is 10 feet per unit. This equates to 528 units per mile, 528000 units per 1000 mi. The farthest point from origin will be 746,704 units. Objects will move at around 20-50 units per second.

In scale terms - if you consider an airfield with a 1 mile runway, this will be represented on the ground as 528 units end to end. A fighter wingspan is around 40 feet, so I’d do these in 10* scale to get some resolution and make spotting easier.

I think this nails it for me. Yes, it will be a table across. Maybe even a small room. If the floating point precision at 6 digits away is within my 1 unit/10ft box I’m prepared to keep pushing on.

9

Float drift at that distance is going to be huge. I even think that placing an object past 100k units in Unity will give you a warning message.

As a general rule of thumb you want to avoid being more than a few thousand units from the origin of the scene.

At that scale you’ll still have accuracy down to the millimeter. Do you really need that?

Also, for what it’s worth, make your life simple and stick to metric measurements. 1 unit = 100m or 1 unit = 1km or something. Conversion is way easier.

First of all, you’re taking about two different scales here. Be clear about whether you’re talking about the scale of the room or the map. Since the map is what matters, I’d focus on that. The room or table will just be decorative dressings, right?

Other things to consider are how fast objects will move. If they end up moving at 0.00000000001 units per second because of the size of the map then you’re going to have problems moving them. That doesn’t mean it can’t be done, but the standard approach of “increment position by speed divided by time” won’t work.

Secondly, and importantly, keep in mind that float drift is an accumulating error. That’s why it’s called float “drift”. Any time you operate on floating point numbers they potentially get further away from their ideal value, and the further from 0 the number is the bigger the drift will get.

It depends on the type of game, perhaps none of this matters. (Turn based tabletop wargame with no animations? You might be fine.) But it sounds to me like you’re at least going to have to learn the gritty details about how floating point numbers and scene hierarchies work.

1 Like
10

Just build a stress test already. Will only take a couple of hours to set up a map of the size you want and test it in engine.

1 Like
11

Thank you for your detailed response. It sounds to me like I’m working from incorrect assumptions about the engine/scale and would be better served getting that down right before making ill informed decisions. Like…

“what can you fit in one Unity unit” will be something I’ll go read up on now.

12

The simple answer No Unity out of the box would not be able to provide you with a simulation on this scale.

The complex answer…

You get serious floating point errors outside of a 10km radius from the world origin, this will effect the alignment of world objects, physics issues and major camera judder.

You can work around this by using a higher resolution vector3 based on doubles, and by rendering a near and far scene elements separately check out the Kerbal Space Sims Unity presentation. As they used a three camera system 1 camera for the cockpit view, the next for things within a 10km radius, and the third for things in the wider world.

You could scale your world to under 20,000 world units to maintain accurate floating point vectors. But this would introduce serious problem with collision detection as everything in the world would be so small that you would have to turn on advanced collision physics which would slow your game down massively.

To do this effectively you might want to consider writing a double Vector3 simulation of your world that can be viewed within Unity in 20km patches at a time. With further out patches as scenery.

Yes Unity could provide you with a way to view your higher precision game but you would need to write/buy a double precision 3D simulation for your game.

1 Like
13

I’ve had my blinding flash of the obvious, thanks angrypenguin!

having spent entirely too long working with integers and never with floats, it never occurred to me that everything can be parts of a unit from another unit, I was still working with whole numbers. Now that I’ve got that in my head I can scale the map back by at least 100 and still get my desired scale.

This will also bring me under Arrowx’s recommendation of 20,000 units (it will be 14,140ish at max!). I won’t be using colliders or physics as the combat is abstracted.

1 Like
14

You might need oversized Units/Buildings as Z fighting might become an issue with small objects.

15

Wait. How are you planning to detect collision with an enemy?

16

you know elmar, you got me thinking about that. I’m not using physics per se, but I will need to do some collision detection, albeit at long ranges - 1 mile or so. Once the unit is ‘in combat’ it will then need to go to the abstract system

so yeah, I wont be ‘colliding’ but I will need that combat routine to come in to play. Effectively I’ll put a big collider bubble on the objects way beyond its physical size.

17

Colliders and rigidbodies are required to detect the collision and do specific action (e.g sword touches enemy → enemy takes damage). You can make some objects static if you know they will never move throughout the game, which will save some performance.

18

Uh guys.

You can’t say “make things smaller and you get more world” because it really doesn’t work like that. For a start, floating point error is always there - it’s always present, and is magnified gradually over distance as you drop each decimal. So even if you made everything small, they would just pop and jerk in a much more magnified way.

The only solution for this stuff is to reset world origin.

You should also test Unity’s skinned meshes at various distances. I’d expect them to start screwing up around the 20,000 mark.

3 Likes
19

This is the correct answer. I’m a little surprised it took so long to come out!

@harleyjd , you can totally do this in Unity. Consider Kerbal Space Program, which is written in Unity and models an entire solar system, and you can go anywhere within that and see bumps and lumps in the terrain smaller than 10 feet in scale.

How do they do that? They reset the origin. As soon as the camera gets more than a certain distance (probably 10 or 100 km) away from the origin, they put the camera back at the origin, and shift everything else so the player has no way to know anything happened. No glitch in the matrix. :slight_smile:

Another way to do it is to have a continually shifting origin… you keep the camera at 0,0,0 always, and just move the world around instead of moving the camera. This can be expensive though.

The other way they do it is through aggressive use of level of detail. A moon or planet that’s hundreds or millons of km away is just a couple of polygons. As you get closer, they refine it more and more, until there are hundreds of polygons right under your feet. You will need to do something similar. Hundreds of miles away, you can’t possibly see goats, people, or small houses, so they shouldn’t even be there; and at that distance even the mountains can be sketched out with a few polygons. Up close, the mountains should be far more detailed and all the little objects need to be there.

So you will be continually moving things around to keep them close to the origin, and swapping out models (or adding/removing them wholesale) to get the appropriate level of detail.

But yeah, if you’re sufficiently clever and have enough time to put into it, this is totally doable in Unity.

(And if you want professional help with it, feel free to send me a PM!)

20

2000x2000 miles? You’re going to have to write a MASSIVE amount of engine to get this to work. Large, outdoor terrains is a big part of my day-job, so I’ll simply say that Unity is not built to support that. Truth be told, NO engine is built to support that, not even engines like Delta3D, which though crappy looking by today’s standards, was designed from the ground up to support large simulations. At that size, curvature of the earth is more than just a concern, it’s a massive problem. At 2000x2000, you’ll likely need a full geocentric coordinate system, which includes your terrain. Plus, the accumulation of floating point errors will cause massive jerking, warping, and bouncing.

TL;DR - Be prepared to write your own render management system, terrain LoDs, and curved earth coordinate representation. Plus custom systems for ground clamping, physics/AI, and dead reckoning (see my article in Game Programming Gems 2). Plus, a distance-prioritized game management system (for balancing CPU), since you won’t be able to tick that many units, every frame. And, lord help you if you are networking all this.

Gigi

PS - I’m assuming standard human sized objects, like walking avatars, driving vehicles, and flying planes.