Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

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

Discussion in 'Getting Started' started by harleyjd, Jun 15, 2015.

  1. harleyjd

    harleyjd

    Joined:
    May 11, 2015
    Posts:
    16
    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.
     
    Last edited: Jun 15, 2015
  2. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,617
    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. delinx32

    delinx32

    Joined:
    Apr 20, 2012
    Posts:
    417
    Meltdown likes this.
  4. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,617
    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.)
     
    Kiwasi and HemiMG like this.
  5. delinx32

    delinx32

    Joined:
    Apr 20, 2012
    Posts:
    417
    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. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,617
    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.
     
    NomadKing, Kiwasi and HemiMG like this.
  7. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    angrypenguin likes this.
  8. harleyjd

    harleyjd

    Joined:
    May 11, 2015
    Posts:
    16
    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. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,617
    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.
     
    Meltdown likes this.
  10. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    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.
     
    NomadKing likes this.
  11. harleyjd

    harleyjd

    Joined:
    May 11, 2015
    Posts:
    16
    <lots of snippage>

    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. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    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.
     
    Meltdown likes this.
  13. harleyjd

    harleyjd

    Joined:
    May 11, 2015
    Posts:
    16
    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.
     
    NomadKing likes this.
  14. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    You might need oversized Units/Buildings as Z fighting might become an issue with small objects.
     
  15. elmar1028

    elmar1028

    Joined:
    Nov 21, 2013
    Posts:
    2,355
    Wait. How are you planning to detect collision with an enemy?
     
  16. harleyjd

    harleyjd

    Joined:
    May 11, 2015
    Posts:
    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. elmar1028

    elmar1028

    Joined:
    Nov 21, 2013
    Posts:
    2,355
    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. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    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.
     
    Ryiah, Gigiwoo and Deleted User like this.
  19. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    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. :)

    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. Gigiwoo

    Gigiwoo

    Joined:
    Mar 16, 2011
    Posts:
    2,981
    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.
     
    Last edited: Jun 15, 2015
  21. harleyjd

    harleyjd

    Joined:
    May 11, 2015
    Posts:
    16
    The last few comments have missed the mark slightly, though I do welcome the insights - it's giving me a lot to think about.

    @JoeStrout Nice. Didn't know you could @...

    @hippocoder & @JoeStrout - The 'player' is a god-like object. He can flit about anywhere on the map at any time. He can choose to react to events or not. The objects are attackers and defenders, and work completely autonomously. God gives orders, the objects execute them according the their scripts. Because the objects do all the work, they need to be in the right place at the right time, whether visible to the player or not. There would be no point resetting the origin because of this.

    @hippocoder & @Gigiwoo Pretend the objects are minatures. They're not real-size, they wont have movable parts, they wont have animated props or pilots. It will be as if they're die cast toys. Mere representations of the real world. There won't be trees, there won't be dials. As I said first up, I was considering the scale at 10ft per 1u. With my derp moment past and realising I can do 1000ft per 1u, I might even be able to go smaller than that, maybe even 1000m per 1u and still achieve my required visual scale.
     
    Last edited: Jun 15, 2015
  22. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Then you have no answer. How do you think these games do it?
    You must reset world origin or change your game's scope.

    Why not make some tests? It could be everyone is over thinking it.
     
    angrypenguin likes this.
  23. harleyjd

    harleyjd

    Joined:
    May 11, 2015
    Posts:
    16
    I don't think you're following what I'm saying. If the camera is at -10000,-10000 and 2 objects are fighting at 10000,10000 it's going to happen irrespective of whether the camera sees it or not. Does that explain my design intent better?

    Those 2 objects would be at 20000,20000 if the origin was reset to the player/camera point.

    angrypenguin's comments about getting the scale right my best bet. The closer to origin, the lower the FP drift and the lower the system requirements.
     
  24. harleyjd

    harleyjd

    Joined:
    May 11, 2015
    Posts:
    16
    lol, yes. remember my first questions were based on a completely false assumption from which I have moved on. I haven't had time to play with my new ideas yet.
     
  25. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    This is incorrect.

    We're talking about display of the game objects. You must reset the origin to keep the camera (and all objects the camera can clearly see) near the origin, where 4-byte floats work. There is no avoiding this. It is inevitable: you will accept this, or abandon your game concept. :)

    But you can simulate your objects quite separate from the display of them.

    If your simulation depends on the detailed positions of things (even when they are far out of view), then you'll need to build your simulation engine around doubles rather than floats. That's not a huge job (I have a double-based Vector3d class I can send your way if you like). Think of it in MVC terms: you'll need to entirely separate the model (the simulation data) and controller (the simulation code) from the view (the Unity objects which display the parts of the simulation the player can actually see at any given moment).

    Getting the "scale right" does not help. The whole point of floating-point numbers is that the decimal point floats. To a first approximation, it really doesn't matter whether your scene is measured in meters, mm, inches, furlongs, or parsecs. All that matters is the range of scales you need to deal with. If you need to have human-sized objects in an area 2000x2000 miles, then no matter what you pick for your units, it's not going to work — unless you learn to shift the origin and apply aggressive LOD to the display, as we've been trying to explain.

    I think the basic problem is that you haven't separated simulation from display in your head. Once that clicks into place, I bet it will all become clear!

    EDIT: Or maybe I'm still misunderstanding your goal... if your area is 2000x2000 miles, but each "object" in this environment is 1 mile square, then you have no problem at all!
     
    NomadKing, Ryiah, Kiwasi and 2 others like this.
  26. Gigiwoo

    Gigiwoo

    Joined:
    Mar 16, 2011
    Posts:
    2,981
  27. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,617
    I hope that's not how people interpreted what I said... though I certainly see how it could be interpreted that way because I kind of chucked the discussion about the meaning of numbers in with the discussion of scale/detail.

    The point isn't about making things smaller. It's about considering the scale required and working to it. Going back to the Total War example, the area being considered in the strategic map is the size of an entire continent, but the detail level required is that of a map - so that's how it's treated. (And that's the direction I've interpreted this project as going in.) Whether the internal implementation has that map as being 3 units or 3 thousand units across is actually neither here nor there - you're just moving a decimal point.

    Having said that, the engine you're considering using does make assumptions about scale that will effect usability and potentially accuracy/precision. For starters, if you made your map actually 2000 miles across (at a 1 unit : 1 meter scale in the Editor), even if you don't lose any relative precision compared to making the same map far smaller you're not going to have much fun moving the camera around in the Editor.


    Separately, work to a scale that a) makes sense and b) is easy to convert and calculate distances in. That's what I was getting at with using something metric rather than a 1 unit = 10 feet system. If you use a metric system and have a 1 unit = 1 kilometer then it's trivial to calculate that something 100 kilometers wide will be 100 units wide. But if you're using 1 unit = 10 feet then you need to dive for your calculator and do a number of steps of arithmetic to figure out how many units makes something a mile wide... ick.


    That's only one approach and it's definitely the one I'd take if it fits, since it comes working out of the box with near zero effort to get started. But it's not the only approach, especially if distance checks are all that's necessary.

    That's how I was interpreting it.
     
  28. harleyjd

    harleyjd

    Joined:
    May 11, 2015
    Posts:
    16
    Hello all.

    Thank you all for your comments and suggestions.

    I realised after re-reading some of the posts that what I'm doing is a (very detailed) table-top game. The size of objects will not be to scale with the map size - they're essentially game tokens and can be any size needed for the game to 'look right'. For instance - if I draw an airfield to scale it looks right from a top down view, but if I draw an aircraft it's so small it's too small to be of any use. It was at this point I remembered - individual aircraft are not rendered, Wings/Groups/Squadrons/Flight tokens are, and they will be larger icons by necessity, both to be seen and to represent the 'strength' of the raid. On the ground, a group token might cover a quarter of the airfield to display the used capacity of the airfield. Whilst individual planes and pilots are tracked, they're never rendered. It's not the true MVC @JoeStrout referred to, but it is a start. I think i will investigate that pattern more.

    Anyway, I think I see a way forward here. Based on your comments, If my map is detailed enough for my purpose, I stick within 20,000 units of origin and the objects look right, I think I'm on a winner.

    I will also take on @angrypenguin suggestion re scale. My logic with the 10ft resolution was based on all the aircraft stats being in MPH, and some legacy (last century!) game designs. I was converting MPH to MPsecond to Feet per second to get very accurate movement using iTween, and it worked and looked lovely. But you're right - meters (and floats!) are so much easier to work with, and all I have to do is convert MPH to KPH to work with a simpler system... On the display side I can just reconvert to miles on the fly. MVC heh...
     
  29. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    Yep, what you're describing now is a much more achievable project for a beginner than the concept I originally thought you were after. You're absolutely on the right track.

    While I previously said that scale doesn't matter, this is (as others in this thread pointed out) a bit of an oversimplification. Unity works most easily with objects that are about 1 unit in size. So, I would suggest you really think of this as a tabletop game, where tokens are maybe 1 cm wide or so, and the whole table is a couple of meters. Then just define 1 Unity unit == 1 cm, and model the whole thing that way. This will make your units roughly 1 unit in size, and the whole playing field about 200 units across, which will make manipulating things in scene view very easy.

    And yeah, under the hood, I do recommend working in metric units, and simply converting to miles/feet/furlongs/whatever for on the fly for display purposes.
     
    Gigiwoo likes this.