Hello all,
I would like to create a procedural map/world for my turnbased game, and I am considering two possible approaches. I tried both of them and see initial strong points and drawbacks of both. I am interested in your opinion, which option would be better suited fo rhte task, or perhaps in a new option I haven’t considered yet.
Requirements:
- the map needs to allow for a cylinder shape (you can go across the dateline)
- the texture of the terrain at any point needs to be controlled through some sort of 2 dimensional array. I am aware tha tI can pass a limited number of textures via the terrain functionality, however as far as I know, this can be controlled in the shaders, while I would like to have this on a game logic level - changing terrain characteristics for instance.
- I would like to have some sort of 3d relief.
- (I wanted this to be on a sphere, but decided that the complexity of such an approach is not worthwhile at this point)
Two solutions that I considered:
-
Custom terrain mesh, based on a heightmap from perlin noise. I could have several of those, and they could wrap around the dateline. I do not see a simple way of controlling the textures however. The texture would be passed through shaders to individual vertices, and the GPU would paint them on the mesh. Perhaps I could store my data in a double array the size of my vertices array and everytime I change a value I would pass this as a new information to the GPU. It seems however quite complicated. Also, amount of possible textures is limited.
-
Tiles, where each tile is a single object (like a quad). I can assign the material of an object at will. There are no issues regarding material limits. the only problem here that I see is the performance. If I imagine a map that is 1000 x 500, and the camera moves in such a way as to render the entire terrain, I reach performance limits. In case of tiles, I would prefer to have them smaller than bigger as to have more possibilities to shape the map into continents and islands that look somewhat natural.
So option 1’s limitation that I see is controlling the textures.
And option 2’s limitation is performance.
Is there a better way of doing this? If not, how can I optimize that which I have.
I think I see what you’re asking here. Basically you’re trying to recreate Civilization to some extent (Very cool btw I’ve been chipping away at that sort of game for a while now). So it’s going to depend on how you want your terrain to look like I’d say. If you want everything to line up nicely on predefined tile spaces I don’t think you’ll be able to get away from making an asset of some sorts for every possible type of tile and loading it in in the right location.
You COULD use the noise function from option 1 to determine what tile to use and where. But using noise specifically to generate the surface and then applying some texturing based on the perlin noise at that particular location will most likely mean you’ll have features that don’t line up to tiles nicely.
For your camera movements I might suggest not moving the camera but moving the map in front of the camera instead and just loading map tiles and assets at the edge of visibility as it rotates. Just food for thought there.
As for the issue of way too many assets loaded I’d dig through the forum here for the numerous projects that deal with similar assets like the Minecraft clones kicking around in here. They have to load a cube per location and that can easily overwhelm their hardware. I don’t fully understand the “how” behind it. But I know it’s been done before.
Precisely, however I did not want to call it a civ clone as it feels a bit too overwhelming…
For option 2, what I had in mind is precisely to use a perlin noise function to determine land from water, then another perlin noise function (perhaps with some offsets) to control where I have desert, and where other types of terrain). Also, hexagos could replace square tiles. The map should look rather natural, so no, I do not want to have clear straigh lines. If tiny hexagons won’t do the trick, option 1 would be clearly superior.
For clarification, I do not intend to do any game logic on the map itself, only to update the map once a piece of game logic is applied. For the game logic itself I would have exactly a two dim array where each array object would represent all the aspects of that terrain in that location (terrain type, neighouring nodes, population, ownership, natural resources, etc,).
I like the idea of moving the map instead of the camera. Also that would fix the angle at which the camera is looking, which could eliminate cases where the entire map is visible.
I’ll check the minecraft topic for asset loading.
heh heh… Ya. I hear ya about the intimidation thing.
So one other point I’d like to bring up to make the map aspect a bit easier.
Do you need it to be on a cylinder at all?
Civilization has it as one flat surface that just happens to load the tiles on the other side of the “date line”. This’ll simplify your map building and asset placement greatly since you only need to deal with 2 dimensions instead of 3. Once your camera gets to a point where the map would wrap around it’d start loading tiles from the other end of the map. This virtually makes it a cylinder since it wraps… but it’s not a cylinder in actuality. Thus you can ignore a lot of issues like mucking with which way is “down” if you’re using any physics. Also for any path finding algorithms you won’t have to worry about plotting a course in 3D.
Interesting. When I thought about cylinders, I had a thought shortcut to exactly that; a 2D place that would render after the dateline. Before I was trying with a 3d planet/sphere, but that was quite difficult and therefore want to try with something more simple.
Yup. Like if you want to wrap your map onto a cylinder go nuts. But remember a cylinder is essentially a flat plane that is bent around to touch it’s other side… Soooooo why not cut out the middle step and just make it a flat surface?
You can work out some simple mathematics based on distance from the plane to tell your game how many tiles to load on either side of the center of your view and voila. You have your map.