Map Generator- Please Critique!

Love the Level Blueprint for prototyping, but I like the GameMode due to portability and every thing having direct access to it (Blueprint node “Get GameMode”; If it’s a Blueprint, you can access it). Mostly it’s just preference, and I’m not the most comfortable with event dispatchers =)

As for key stuff on the player controller, totally, also your controller is separated from the pawn so if it is destroyed, that’s cool, still got all your data on the controller.

As for Global things… well Macro Libraries + using GameMode as storage, and you kind of have them, but I get what you’re getting at. I’d like to just be able to call my map size from anywhere without worrying if I passed it in from the outside. Doesn’t solve the speed issue with the casting though. I think there are optimizations to the Spawn from Class node either in or coming that will reduce the need for them.

Rock on =) C++ is definitely not my realm.

Yeah when I thought about the actual actor spawning in the world I knew what you meant. :slight_smile:

Your bluepritn screenshot helps quite a bit! :slight_smile:

Would you keep the main menu, map preference screen, and the actual game all in the same game mode or split them up?

So, you hit New Game and it loads the map preferences screen, perhaps all from a Menu Game Mode? The options in this screen are all HUD events directly setting the variables of the World Data actor. When you hit Play, it loads the Game Mode that actually spawns the map.

So there could be 1 Main Menu game mode, 1 game mode per game type(scenario, random map, campaign, etc), a game mode for each map generator type(fractal, biome, earth map, etc), etc.

Using player controller sounds like a good idea for variables that are universal to every screen in the game. I will have to put some thought into what those variables might be for my game.

I would love such a C++ tutorial targeted at non-programmers! :slight_smile:

I also feel that there are a ton of easy, yet crucial optimizations that can be made in C++ but require going through the research to make it happen.

Here is my map with color coded collision volumes attached. The volumes carry the Tile Class and the tiles are instanced meshes.

I factored in some separation on the collision volumes. I figured all movement will occur in relation to the center point of each hex so the volumes would not need to encompass the entire hex.

I could probably make them even smaller. Would I get any performance gains from smaller collision volumes that are invisible?

Thanks for putting this thread together. Really appreciate it.

Awesome ,

The volumes can also be your method of control for mouse/touch controls as well, so you may want them to be the same size of the hex depending on the platform. Now if you’re thinking more about controller usage, then it wouldn’t really matter much as you’d have another way to highlight the hexes for movement.

Adding the material to the meshes is a pretty good idea from a debug stand point. The “SHOW COLLISION” console command will actually render the entire collision mesh, even if it is normally hidden, with material. So if you have your system make changes to the “Tile Class” and that in turn propagates up to the render mesh, then you’ll have a way to debug it easily in the future.

I’m digging it =)

No performance gains that I’m aware of, perhaps super crazy minor if you were to collapse the bottom side of the collision hex, like a 6 sided cone.

Heh yeah I had that thought regarding size as I went to sleep. I think I will make them just short of the edge, maybe 90-95% of the hex tile width.

And yeah, I was testing a few things with the Right Mouse Button to line trace, call an event on the volume hit, destroy the volume, update arrays to place an Arctic on that tile, regenerate the tile map(with the update), and then replace the volume with the Arctic volume. It works! Except my new arctic volume wasn’t generating 90% of the time, but the tile map swapped so quickly that I couldn’t even notice that anything besides the tile hit had changed. The tile just changes to an Arctic tile as if that is all I was doing. Pretty sweet. It seems the 2 map idea isn’t needed for the smallest of maps on a fairly fast computer, but I will keep it in mind when I test out the largest of maps on slow computers. :slight_smile:

Not sure what is going on with the volume yet, but for some reason my editor crashes every time I try and open the project… -_- Error: 9c26e3bf5ceff148b933522aff1de581

It might have something to do with the question I posted to answerhub: Why won't my 3 separate Blueprints compile? - Audio - Epic Developer Community Forums

Seem to have created some kind of cast-loop in my BP’s that the editor really hates: Why won't my 3 separate Blueprints compile? - Audio - Unreal Engine Forums

Aw jeeze, yea I’ve hit those crashing Blueprints on load a few times. Have you tried pulling a backup out of the Saved\Backup folder? Unless you disabled auto save, you should have a number of backups available =)

Yeah, I deleted one of the 3 offending blueprints and pasted it back into the folder after the project loaded. Then I deleted 2 of the functions referenced by the Casting and it allowed me to compile all 3 blueprints and load the project without crashing.

Edit: Silly me, I was destroying the actor before I had finished referencing it… Though, removing that by itself doesn’t resolve my compiling problems so there may be more going on.

It would be super awesome if something like that didn’t crash the editor but instead gave you some kind of stern warning. :stuck_out_tongue:

So I fixed my compile/crash problem and also fixed the spawn of the new volumes after I destroy them. So basically I can click on the map and change tiles at will. I will expand upon that more in the future, but the basic functionality lets me see how it all works out.

, the node that Spawns your Tile Generator into the map. It was modified in C++ to give the basic spawn actor node the variable inputs, or can that be done in BP?

Passing the variables via an interface or a cast doesn’t seem to really fit with the way you have implemented it, but I am not sure I could emulate your system without coding it in.

Edit: Here is my current map with widened collision volumes and my Right Mouse Button map interaction.

Heya ,
I only work in Blueprints and I’m setting variables on my Blueprints to “Expose on Spawn”:

onSpawn.png&stc=1

Which will make the Spawn node have a bunch of input pins and the variable is set before the construction script is fired.

Wow op great work.

I have not fully read this thread but from what I have read, great info is presented. I cant wait to read this completely

Thanks

Ah of course! :slight_smile: I think I thought that did something else before. I may have to see if I can use that when spawning the tiles as well, nice.

Thanks! Hopefully sometime in the next couple weeks I can update the first post with the improvements I have made to the process.

Good news, progress!

Bad news, my material editing skills are currently limited to “Tint”. lol

Key:
Ice = White
Tundra = Turquoise Blue
Boreal Forest = Blue-green
Deciduous Forest = Green
Coniferous Rain Forest = Dark Green
Jungle = Darker Green
Grassland = Lighter Green
Steppe = Brownish
Desert = Sand

Also, Mountains have the deep shadow and hills have a very light shadow.

So I revamped the generator and added in most of the terrain types that I intend to have available. Right now that is 9 land and 1 water. The new generation is still pretty crude, but I based it on what I hope to be the foundation going forward. What I have done is taken the old system and removed the actual tiles from the generation consideration. Instead of growing biomes based on deserts, they are grown based on 4 criteria:

Sea Level. The Vector Field is seeded with Land and Ocean seeds, they grow in the Vector Field, and the Sea Level Array is updated. Land and Ocean arrays are also created and only contain vectors relevant to their type.

Elevation. The Land Array is then seeded with Plains, Hills, and Mountains which grow throughout the Vector Field and the Elevation Array is updated.

Precipitation. The Land Array is finally seeded with Arid, Semi-Arid, Moderate, and Wet seeds which again grow in the Vector Field, and the Precipitation Array is updated.

Temperature. Temperature isn’t seeded as much as it just exists for each latitude on the map. The Temperature Array is updated though(Arctic, Tundra, Temperate, Sub-Tropical, and Tropical), to assign temperature values to each index.

Once everything has been seeded and all 4 arrays are filled, the generator proceeds to generate the map by referencing the Current Vector being generated to each array’s index and pulls it’s Byte. That Byte is run through a vast field of Enums and the tile is generated.

I will try to go into more detail sometime in the near future by updating the first post. Let me know what you think! :slight_smile:

Here is my first run at coastal waters:

Still a fair bit of math to do though. I didn’t account for the offset so I have to figure something out. Then I need to factor out the wrapping at the top of the map and factor in the wrapping on the sides. Hopefully when I work that out it is a short process to complete the world wrap mechanic.

Coasts now account for the poles and the East/West wrapping.

Here is a pic with the Precipitation zones outlined.

Blue = Wet (Jungle & Coniferous Rain Forest)
Green = Moderate (Deciduous Forest & Boreal Forest)
Yellow = Semi-Arid (Steppe, and Grassland)
Orange = Arid (Desert, Steppe, Tundra)

So depending on the latitude, different precipitation levels result in different vegetation.

Now I will see if I can wrap the world visually in the game. Anyone have any ideas on how that is done?

What do you mean by wrapping?

The east edge should wrap to the west edge as if it were a globe.

Thinking about it, just on a map level, foregoing units and the like, you could just duplicate the map east and west, then create a camera system that wraps once it hits the border of the map.

I don’t know if there’s some fancy way to handle it… maybe the world browser can load the same map just offset (assuming you use “random streams” for all your random generation). If it does, you’d have automatic re-centering of the world once you cross the border. You’d still have to tell it to move the levels around once you cross that border (not even sure it can do this).

Making the map repeat really isn’t that big of an issue, in fact you could just re-use the data you already have and add to the instanced static mesh components you have. The real trouble comes when you add in units and need to duplicate movement and the like…

Thanks a lot , , MonsOlympus and all others who contributed this thread. It helps me a lot doing my own labyrinth generator. ( If i succeed doing it (at least) fair, i’ll show you.)