Announcement

Collapse
No announcement yet.

Optimal map scaling for open world racing game

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Optimal map scaling for open world racing game

    Hello,

    Me and some friends want to try to make an open world street racing simulation game, to play by ourselves and with our other friends. I work as a programmer in a R&D company, and I have some modeling and level building experience, mostly for other games. For UDK, I've only created a small map for FPS so far, so I don't know much about UDK yet. My other friends also have some modeling and coding experience, so we are not complete novices, but we're not experts either.

    For the game, we want it to be multiplayer, not exactly MMO, but it should be able to run with a single dedicated server and fit 20-30 players. It will have a huge open world map, where we will be cruising around, buying cars from car dealers, fix damage in services, modify them in tuning shops, and drive to races, just like games such as Test Drive Unlimited and Need For Speed Underground 2. 3 main differences though, the races will not take part on the main map, but on separate maps with mostly real life tracks or locations; It will have a huge amount of cars, like maybe over 1000; and the driving physics will be very realistic, we're aiming at simulator level of realism, look at rFactor 2 and Assetto Corsa to see what I mean.

    Since it's a private project and it's not gonna be released to the public, there should be no problem easing our load by converting assets from other games, for example car models from Forza 4 and tracks from iRacing and such. The open-world hub map will be done from scratch, though. And this is the main reason I'm writing this topic, as you might have guessed from the title.

    Since we want the map to be as large as UDK will allow, we will probably have to scale everything down to fit within the limits. Ideally we would like to have 256km x 256km map, though we can settle for less if we have to. We want to know how far can we keep scaling everything down before it compromizes the realistic driving physics and collisions and such. Also, I'm curious to know what would be the difference whether we use heightmap terrain or a static mesh, cut to smaller pieces for LODing purposes. Last but not least, I want to know whether UnrealScript will give us the freedom to create such a game, or we should wait for an indie version of UE4 so that we can use C++ instead?

    Thanks in advance!

    #2
    *bump*
    Come on, doesn't anyone know?

    Comment


      #3
      In short, you're looking at the wrong engine. I don't think you'll find a regular game engine with out of the box support for your requirements, as they're quite specific. You need a simulator engine with 64-bit coordinate support, including in the physics.

      For a longer explanation, I think the first thing I'd mention is that what your proposing to do as a hobby project is just ridiculous and that you haven't thought this through. The game you're describing looks like the kind of project a professional 200 man team would start to get nervous about. It's too big, and too detailed in basically every direction and will never be achievable - you are simply aiming far, far too high. Reading through the feature list it sounds more like a joke, which is why you've had no replies.

      Ignoring the stupendous amount of content you want to throw out, let's look at the most important technical issues you're facing:

      Originally posted by Takumi Fujiwara View Post
      We want to know how far can we keep scaling everything down before it compromizes the realistic driving physics and collisions and such.
      You cannot scale it down if you are doing anything that requires a semi-decent physics simulation. The physics engine behind everything works on a specific scale - scaling objects down in the world will not translate properly into the physics engine and you will have all manner of problems making it behave properly.

      Originally posted by Takumi Fujiwara View Post
      Ideally we would like to have 256km x 256km map, though we can settle for less if we have to.
      Big games worlds and accurate 'simulator like' physics do not play together nicely - this is why:
      Game coordinates are floating point values. The farther a floating point value strays from the origin coordinates of 0,0, the less accurate the value is. Frequent use of already inaccurate values within the physics engine will result in increasingly inaccurate results of the calculations using them - the further you stray from the origin, the less accurate your physics behaviour will get, to the point where it may break down completely.

      256 square kilometers is enormous. Ignoring the fact that you haven't got a hope of actually producing content to fill that space, the limit of the game's world extents is fixed at 524288 units (presumably because something like physics will start to break down past this point). The physics engine scale is 1 unit = 2cm, giving you a maximum playable area of around 10km^3.


      Some simulation engines use 64-bit floating point coordinate systems as they require more accurate physics over larger playable spaces. I don't think any such engine is free however.

      Comment


        #4
        Im curious then about rFactor, an old racing simulation game from 2005. The game is made for 32-bit windows xp, no doubt about that, and it can handle humongous tracks with ease. Well, there is reduced performance, but it's still playable, and the physics are pretty realistic at any point of the track. How did they achieve that there?

        As far as I know there are currently only 2 indie game engines that support the oculus rift, UDK is one of them, and the other one can only handle 4km x 4km as far as I'm aware. I guess it's the wrong time to start this project then. When UE 4 gets an UDK, would that be able to handle this project? If not, maybe UE 5? And, is 1unit = 2cm (10x10) the lowest I can go? What about 1unit=4cm (20x20)?

        Comment


          #5
          It's possible rFactor used 64-bit precision floats, but it's also likely that they built their engine around their requirements. Engine comparisons aren't allowed on these forums, but there are engines out there that do support that out of the box, and have been used for games. Generally speaking 64-bit floats aren't used because they are quite performance intensive compared to 32-bit floats.

          You can integrate Oculus into most engines that you have source access for without too much difficulty.

          Comment


            #6
            How large world is the Unreal Engine capable to handle?

            Comment


              #7
              The answer is three posts up?

              Originally posted by ambershee View Post
              the limit of the game's world extents is fixed at 524288 units (presumably because something like physics will start to break down past this point). The physics engine scale is 1 unit = 2cm, giving you a maximum playable area of around 10km^3.

              Comment


                #8
                I cannot afford an engine license, so I do need a free engine, one with good graphics and oculus rift support. Anyway I look at it, UDK is the only choice. I guess I'll have to cut out most of the map I had in mind and leave only whatever will fit within the limits. Though, can't it fit at least 20x20 (1unit=4cm)? Or that will already worsen the physics too much?

                Comment


                  #9
                  10k x 10k is pretty big especially if all your tracks are to be separate levels.there would be plenty of room for a few friends to drive around and find each other.even at half size the physics gets dodgy.
                  once you have built a few common assets it is surpising how quickly even a one man team can build a level.

                  Comment


                    #10
                    Generally speaking, the advice is to never scale your stuff by more than a factor of two, as the physics (and interestingly networking) can start to break down. 20 square kilometers is still an enormous space to fill though, I'd expect it to take absolutely forever.

                    Comment

                    Working...
                    X