Terrain Handling in Frontiers

Engine, AI, scripting, that sort of thing.

Terrain Handling in Frontiers

PostPosted by ensiferum888 » Sat Jan 18, 2014 5:03 pm

Hey everyone, just found out about this game, I grew up playing Daggerfall and I wish I had known about this while the KS campaign was still rolling :)

You can count me in your player base that's for sure this game can't come out soon enough.

I'm currently making a city-building game in Unity and only have one terrain per map. I'm already starting to write down some ideas for my next game which would be a zombie invasion set in a fantasy world (think of a mix between S.T.A.L.K.E.R and Frontiers I guess). My biggest concern would be how to manage such a big world since I can't just have one terrain of 30km x 30km without some major performance hit.

I'd like to know if it's possible that you make a very in detail post on how you create, store, load and unload the terrain cells in run time and how you go about editing them. I'd actually be willing to pay a lot of money for that kind of information. If you want to keep your secrets under the hood I understand as well, a lot of people take their creations at heart and I can appreciate that too! I'll just have to dig Google a lot more as I haven't found anything yet.

Regardless I think you have a fantastic game and I'm really hoping we can play it soon! Good luck with the development!
ensiferum888
Novice
Novice
 
Posts: 7
Joined: Sat Jan 18, 2014 4:48 pm

Re: Terrain Handling in Frontiers

PostPosted by Railboy » Sat Jan 18, 2014 5:58 pm

I'll be releasing all of my chunk code eventually. It's mostly cobbled out of existing solutions anyway.

The gist is that I store terrain data in various maps - height map, splatmaps, color overlay - and load /unload them based on player proximity. I would start here by experimenting with setting heights and adding details & tree instances at runtime.

I'll make terrain the subject of a devlog sometime soon and get into more detail. I want to wait until a few more things get locked down before writing anything up. In the meantime you can find bits and pieces about how I store world data in the existing devlogs.

In all honesty, my suggestion is don't go open world, especially if you plan to stick with Unity. It's caused nothing but problems, and while I think it's the only valid choice for the play style I'm going for, I also think it would have been wiser to design a game around the 'level' paradigm. Resource management is simpler and many, many more off-the-shelf solutions will be available to you. Not that you'll listen. :D
Language is to the mind more than light is to the eye.
User avatar
Railboy
Developer
Developer
 
Posts: 1845
Joined: Mon Jul 15, 2013 10:46 pm
Location: Seattle, WA

Re: Terrain Handling in Frontiers

PostPosted by ensiferum888 » Sat Jan 18, 2014 6:12 pm

Thank you so much for replying :)

I'm already comfortable enough with procedural generation, creating terrains, randomly placing trees, rocks and rivers but only on one terrain. You can actually check it out here: http://dl.dropboxusercontent.com/u/2343 ... uilds.html

But I'd like to make this huge terrain by hand, it would allow for a much more detailed world, honestly I was looking forward to Elder Scrolls Online and since this morning I've been looking at all the screenshots and videos of your game and I'm a bit sad I won't be able to play when I get home tonight.

I'll be looking forward to this devblog and will hunt down your current ones for any information. By the way are you still on track for a Q2 2014 release?

You say it's caused nothing but problems, but now with the experience you have gained by making Frontiers, would you do it again knowing what you know now? If you ever decide to make another open world game would go use Unity again or another engine?
ensiferum888
Novice
Novice
 
Posts: 7
Joined: Sat Jan 18, 2014 4:48 pm

Re: Terrain Handling in Frontiers

PostPosted by Railboy » Sat Jan 18, 2014 7:37 pm

Ah, very cool thanks for the link.
But I'd like to make this huge terrain by hand

Since you seem to have a handle on manipulating terrain data, Given might be the guy you want to talk to. He created the terrain tiles in World Machine and brought them into Unity.

You say it's caused nothing but problems, but now with the experience you have gained by making Frontiers, would you do it again knowing what you know now? If you ever decide to make another open world game would go use Unity again or another engine?

Nope. I would have gone with a different engine, OR tried to redesign the game to use levels in a quasi open world. (Of course at this point I'm committed to this approach so I intend to see it through as-is.)

By the way are you still on track for a Q2 2014 release?

So far we're looking good.

Best of luck.
Language is to the mind more than light is to the eye.
User avatar
Railboy
Developer
Developer
 
Posts: 1845
Joined: Mon Jul 15, 2013 10:46 pm
Location: Seattle, WA

Re: Terrain Handling in Frontiers

PostPosted by ensiferum888 » Sun Jan 19, 2014 1:34 pm

Given might be the guy you want to talk to.

When the time comes I'll keep that in mind, you'll probably be releasing a dev blog before that. I want to finish my current game before moving on to the next.

I'm very glad you decided to go the full open world route, I watched the path editing video this morning I'm probably more excited for this that The Witcher 3. Anyways good luck with everything I hope the rest of the way will be smoother than that "dead zone" :P

I'd offer my help but I think you're a much better coder than I am!

Thank you for taking the time to answer my request.
ensiferum888
Novice
Novice
 
Posts: 7
Joined: Sat Jan 18, 2014 4:48 pm

Re: Terrain Handling in Frontiers

PostPosted by yarnevk » Sun Jan 19, 2014 3:24 pm

Railboy wrote: I would have gone with a different engine, OR tried to redesign the game to use levels in a quasi open world.


Unity levels is what Portalarium did for SOTA. While people complained it was not open world, it is the way Ultima (and D&D) always was, the world map was a seperated world from dungeons and towns. But I do not care for that because that presumes the adventure is in the dungeons and towns, when more adventure can be had in open worlds. It caters to those that fast travel, why even bother with the world if everyone skips over the world?

Skyrim uses walled cities in a fake world, it is much more immersive with Open Cities mod running even though it means you cannot mod the cities anymore. I really notice it as they did not open the fort in Dawnguard which means my horse has to stay outside the canyon (yet vampires hounds can get in!) Adding more content with closed cities is less immersive than less content in an open city.

Unity Pro supports more occlusion and lighting than Skyrim had so glad you are sticking with the open world.
Last edited by yarnevk on Sun Jan 19, 2014 3:41 pm, edited 2 times in total.
yarnevk
Pathmaker
 
Posts: 178
Joined: Tue Sep 17, 2013 2:48 pm

Re: Terrain Handling in Frontiers

PostPosted by Railboy » Sun Jan 19, 2014 3:27 pm

I can offer you this in the meantime, it's the function I use to pull heightmap data (16 bit, mac encoded, exported from Unity terrain.) It's adapted from a Unity Answers post, can't seem to find the original now. But it took me a while to get it importing without artifacts so maybe it'll spare you some trouble.

Code: Select all
public static bool LoadTerrainHeights (ref float [,] heights, int resolution, string chunkName, string rawFileName)
{
   string directory             = System.IO.Path.Combine (gBaseWorldModsPath, System.IO.Path.Combine ("Chunk", chunkName));
   string fullPath               = System.IO.Path.Combine (directory, (rawFileName + gHeightMapExtension));
   FileMode mode               = FileMode.Open;
   FileShare share               = FileShare.ReadWrite;
   FileAccess access            = FileAccess.ReadWrite;

   if (!File.Exists (fullPath))
   {
      return false;
   }

   byte [ ] bytes = System.IO.File.ReadAllBytes (fullPath);
   int byteNumber = 0;
   for (int x = 0; x < resolution; x++)
   {
      for (int z = 0; z < resolution; z++)
      {
         heights [x, z] = ((float)((bytes [byteNumber] << 0x08) | bytes [byteNumber + 1])) / 65536f;
         byteNumber += 2;
      }
   }
   return true;
}
Language is to the mind more than light is to the eye.
User avatar
Railboy
Developer
Developer
 
Posts: 1845
Joined: Mon Jul 15, 2013 10:46 pm
Location: Seattle, WA

Re: Terrain Handling in Frontiers

PostPosted by yarnevk » Sun Jan 19, 2014 3:37 pm

This blogger does Unity terrain project tutorials as he fools around with different algorithms

http://scrawkblog.com/page/2/

He has examples of how to slice bigger terrains so you can keep Unity performance for modifying the terrain. I have found tiles of 257u to be optimal tradeoff of too many small or too few large. You can fit 64 of those in one 2049u tile so you need a method of slicing a larger terrain.

The biggest thing that will trip you up about tiling is that the border mesh overlaps with neighbors, it needs to be the same height on all the neighbors.
yarnevk
Pathmaker
 
Posts: 178
Joined: Tue Sep 17, 2013 2:48 pm

Re: Terrain Handling in Frontiers

PostPosted by Railboy » Sun Jan 19, 2014 4:10 pm

[edit] (You posted as I was typing so I missed the bulk of your response.) I don't think Unity is at fault for not supporting open-world-style games by default. I think their level-based setup is really robust and totally appropriate for the vast majority of games. I blame myself for trying to shoehorn a game style into an engine where it doesn't fit. If I ever make an open world game again I'll just choose an engine that's built around that concept, and if I ever make a level or region based game I'll use Unity and take full advantage of all their built-in tools.

yarnevk wrote:Unity Pro supports more occlusion and lighting than Skyrim had so glad you are sticking with the open world.


This is only true if you are sticking to Unity's level system. If you go open world you lose occlusion culling altogether and baked lighting becomes a lot trickier. You also lose their built-in navmesh support and lots of other features. Huge bummer.
Language is to the mind more than light is to the eye.
User avatar
Railboy
Developer
Developer
 
Posts: 1845
Joined: Mon Jul 15, 2013 10:46 pm
Location: Seattle, WA

Re: Terrain Handling in Frontiers

PostPosted by yarnevk » Sun Jan 19, 2014 4:51 pm

I mean camera occlusion for rendering purposes. In Indy it takes out everything out of camera, in Pro it also takes out that which is occluded, like houses behind a mountain that you cannot see, or furniture in the house you cannot see. Very important for someone wanting to play open worlds with Indy, that Pro feature makes a fps diff; in Indy you would have to do close cities like Skyrim. Open changeable worlds also would use dynamic lighting/shadows which you need Pro for. And any 'baked' features do not work if you can change the world.

http://docs.unity3d.com/Documentation/M ... lling.html

You are talking about loading and unloading of assets for memory management, which indeed if the world is one 'level' you have to manage this yourself, though maybe 64b Unity will make it so the solution is just add more memory!
yarnevk
Pathmaker
 
Posts: 178
Joined: Tue Sep 17, 2013 2:48 pm

Re: Terrain Handling in Frontiers

PostPosted by ensiferum888 » Sun Jan 19, 2014 5:32 pm

Thank you very much for the piece of code!

I suppose you also move the entire world back to the origin when going above a certain distance from the center of the scene?

I'll start tinkering with world machine eventually it looks extremely powerful.
ensiferum888
Novice
Novice
 
Posts: 7
Joined: Sat Jan 18, 2014 4:48 pm

Re: Terrain Handling in Frontiers

PostPosted by Railboy » Sun Jan 19, 2014 5:36 pm

yarnevk wrote:I mean camera occlusion for rendering purposes. In Indy it takes out everything out of camera, in Pro it also takes out that which is occluded, like houses behind a mountain that you cannot see, or furniture in the house you cannot see.


Occlusion culling is baked in at the scene level, not calculated dynamically. If you're loading all your elements at runtime - terrain, prefabs, whatever - and dumping them into an otherwise empty scene then this feature isn't available even in pro.
Language is to the mind more than light is to the eye.
User avatar
Railboy
Developer
Developer
 
Posts: 1845
Joined: Mon Jul 15, 2013 10:46 pm
Location: Seattle, WA

Re: Terrain Handling in Frontiers

PostPosted by Railboy » Sun Jan 19, 2014 5:43 pm

ensiferum888 wrote:Thank you very much for the piece of code!

I suppose you also move the entire world back to the origin when going above a certain distance from the center of the scene?

I'll start tinkering with world machine eventually it looks extremely powerful.


Believe it or not I don't - I tried this approach early on and it resulted in too many problems. Chunks are loaded and unloaded in world space. If the world ever got large enough you'd start getting floating point errors but the FRONTIERS world is small enough so that it isn't a problem.
Language is to the mind more than light is to the eye.
User avatar
Railboy
Developer
Developer
 
Posts: 1845
Joined: Mon Jul 15, 2013 10:46 pm
Location: Seattle, WA

Re: Terrain Handling in Frontiers

PostPosted by yarnevk » Mon Jan 20, 2014 3:50 pm

Are you sure about the camera occlusion do not see how that could be baked since it depends on camera view. Skyrim uses occlusion boxes for large dungeons so the game would fit on consoles, Unity also supports baking that in. Does not matter to me since my Pro trial expired and did not want to fiddle with Indy missing features so I am fooling with Skyrim modding now.

Kirby Space Program uses the Unity origin reset trick so they can model solar systems, assuming default meter unit you can go +/-100km before having issues. Just means slicing a larger world up and using slice coordinates on top of the floating point. For further distance views you can do scaled down mountains placed closer on a slower tracking camera (AKA 3D skybox), though these tricks fail in VR.
yarnevk
Pathmaker
 
Posts: 178
Joined: Tue Sep 17, 2013 2:48 pm

Re: Terrain Handling in Frontiers

PostPosted by Railboy » Mon Jan 20, 2014 4:51 pm

yarnevk wrote:Are you sure about the camera occlusion do not see how that could be baked since it depends on camera view. Skyrim uses occlusion boxes for large dungeons so the game would fit on consoles, Unity also supports baking that in. Does not matter to me since my Pro trial expired and did not want to fiddle with Indy missing features so I am fooling with Skyrim modding now.


Unity handles it by pre-calculating which renderers are visible / occluded from any given point. It's a long, slow process that can take hours depending how granular you make the search. At runtime as you enter/exit occlusion regions it flips those renderers on and off. This occlusion data is stored in the scene and can't be loaded additively.

I figured it would be dynamic as well, or at least configurable at runtime - maybe do a really broad search with huge occlusion boxes and add/remove renderers at runtime, something like that - but unfortunately it's just not an option.
Language is to the mind more than light is to the eye.
User avatar
Railboy
Developer
Developer
 
Posts: 1845
Joined: Mon Jul 15, 2013 10:46 pm
Location: Seattle, WA


Return to Technical Stuff

Who is online

Users browsing this forum: No registered users and 0 guests