Auto-Generated Battle Maps(A forgotten gamplay part)

[Akka]

The next patch may alleviate this issue somewhat through the introduction of additional battle terrains. Auto-generated terrains are not something we are currently exploring, but we intend to continue adding a range of custom battle terrains.

First, thanks for the information ! Any news is a good thing ^^

But on the subject at hand, I simply don't understand how you can consider that hand-made battle maps are a good fit for the game when it comes to random battles. It's very anti-immersive (seeing the same battleground when you are at different places in the world just wreck the immersion), and even in term of practicality, we have literally hundred of battles in a game and we play several games.
You'd need hundred or thousands of maps to not have a feeling of repetitiveness or disjointed connection between world map and local map. Considering each map is probably several tens of man-hours, I think we can lowball the labor cost at 30 to 50 000 man-hours to have enough maps. That's basically the equivalent of years worth of work for a handful of dev to develop procedural generation. And that's without the benefit of procedural generation (which is not "enough maps to not get sick of their repetition for a few games", but "literally infinite number of maps, and which have the added benefit of mapping the entirety of the world map").

Procedural generation is just objectively and strictly superior.

 

[Bloc]

@Bloc (second mod of Bannerlord and couple of others made by him) in Turkish forum, he said it is [near] impossible for a modder to that. His post is too much technical for me to translate. By any chance, releasing of modding tools changed this(I know you said modding tools would not help this situation)?

Uh, that was not quite what I said. I can translate that to English to be clear.

You asked me if we will be able to see a mod that generates this.
Tl;dr: in theory, maybe, in practice not possible.
Long answer: Gameplay code calls Engine methods which is embedded inside the C++ engine. Reverse engineering C++ is not possible. It is possible to tweak HEX code but it's not possible to read it's content directly like we do for C# .dll files. You can still get the main logic, but it's hard. You can perhaps modify it. At best, someone can look into terrain.bin files and understand/decode it's content for readable language. Then that person would have full charge on changing the content of the file and create them on the fly. So logic would be, having a one static file where you can always change it's content and a mod where changes the battle map logic to always open that particular terrain. And terrain itself will be auto generated by other code piece and written into .bin file. What's the bad side of this? Longer battle load times. Possible HDD/SSD usage due to fact that you need to rewrite contents of several .bin files. But currently no one knows how that .bin files are generated and how to read them. So currently its not possible.

will require expertise regarding C#

Not quite. Terrain generation is hard regardless of the language of your choosing. Its up to how you decode their bin files. Then you need knowledge about terrain generation in general. You can create basic perlin noise, distort it and then use that as your heightmap and perhaps apply a hydraulic erosion on the fly before writing onto the file. But again, at the end, you need to decode the bin files. Here is a reverse-engineered snipped from RGL to see how terrain nodes are generated( obviously this is not 100% legal so I won't post entire functional code - although I cant since it's 2,198,608 lines )

    *reinterpret_cast<void***>(&rsi10) = reinterpret_cast<void**>(static_cast<uint32_t>(dl));
    *reinterpret_cast<int32_t*>(reinterpret_cast<int64_t>(&rsi10) + 4) = 0;
    rdi11 = rcx;
    _0rglVarString_QEAA_AEBV0_Z(reinterpret_cast<int64_t>(rbp4) - 8);
    _0rglBuffer_QEAA_XZ(reinterpret_cast<int64_t>(rbp4) - 64);
    _0rglVarString_QEAA_AEBV0_Z(reinterpret_cast<int64_t>(rbp4) + 32, reinterpret_cast<int64_t>(rbp4) - 8);
    append_rglVarString_QEAAXPEBD_Z(reinterpret_cast<int64_t>(rbp4) + 32, "/terrain.bin");
    rsp12 = reinterpret_cast<void*>(reinterpret_cast<uint64_t>(rsp5) - 8 + 8 - 8 + 8 - 8 + 8 - 8 + 8);
    _0rglNative_file_QEAA_XZ(reinterpret_cast<uint64_t>(rsp12) + 80, "/terrain.bin");
    rax13 = reinterpret_cast<void**>(char_p_rglString_base_QEBAPEBDXZ(reinterpret_cast<int64_t>(rbp4) + 32, "/terrain.bin"));
    rsp14 = reinterpret_cast<void*>(reinterpret_cast<uint64_t>(rsp12) - 8 + 8 - 8 + 8);
    rdx15 = rax13;
    *reinterpret_cast<int32_t*>(&r9_16) = 0x104;
    *reinterpret_cast<int32_t*>(&r9_16 + 4) = 0;
    r8_17 = reinterpret_cast<void**>(5);
    *reinterpret_cast<int32_t*>(&r8_17 + 4) = 0;
    open_rglNative_file_QEAA_NPEBDHH_Z(reinterpret_cast<uint64_t>(rsp14) + 80, rdx15, 5, 0x104);
    rsp18 = reinterpret_cast<void*>(reinterpret_cast<uint64_t>(rsp14) - 8 + 8);
    if (!*reinterpret_cast<signed char*>(&rsi10) && (al19 = reinterpret_cast<signed char>(is_valid_rglNative_file_QEAA_NXZ(reinterpret_cast<uint64_t>(rsp18) + 80, rdx15, 5, 0x104)), rsp18 = reinterpret_cast<void*>(reinterpret_cast<uint64_t>(rsp18) - 8 + 8), !!al19)) {
        r8_17 = reinterpret_cast<void**>(4);
        *reinterpret_cast<int32_t*>(&r8_17 + 4) = 0;
        rdx15 = reinterpret_cast<void**>(reinterpret_cast<uint64_t>(rsp18) + 88);
        read_rglNative_file_QEAA_KPEAX_K_Z(reinterpret_cast<uint64_t>(rsp18) + 80, rdx15, 4, 0x104);
        rsp18 = reinterpret_cast<void*>(reinterpret_cast<uint64_t>(rsp18) - 8 + 8);
....

So yeah you get the idea, it's basically unreadable. It's also copyrighted etc, so don't reverse engineer stuff. It's bad. If TW decides to give us a chance about how to decode that stuff, we could have a chance.

For your case, other solution I can offer is the following:
Create huge maps in editor, randomize the position and rotation. So that even though some features of map will be same, it will be hard to recognize because of the randomized positions as well as the randomized maps. This big maps increases the loading time, but eh, that's a trade off.

The next patch may alleviate this issue somewhat through the introduction of additional battle terrains. Auto-generated terrains are not something we are currently exploring, but we intend to continue adding a range of custom battle terrains.

Any plan to have something where we can `read` the contents of the .bin files to create our own tools for scene creation? Since it's out of discussion for TW to have autogenerated maps, perhaps community create something like I mentioned above. But we need to decode those .bin files first.

 

[Piconi]

I would personally preffer a huge set of custom made battle maps, only not having a terrain/climate tag assigned to it (where you get the same map on different locations), but it having a specific place, a tile, on the main map (a square or a hexagon) where only that specific map spawns, and it reflects the main map surroundings and terrain.

It breaks more immersion for me to have different map every time on the exact same spot on the map.

Would need many maps/much time, but if a goal is also a special scene per settlement, i don't see why this can't be as well.

 

[Bloc]

I would personally preffer a huge set of custom made battle maps, only not having a terrain/climate assigned to it, but having a specific place on the main map where only that slecific map spawns, and it reflects the main map surroundings and terrain.

This doubles the game size since all the battle maps are taking quite a big chunk of your storage. However its pseudo generation but more doable at this moment.

Basically,
- Split moveable area into tiles ( imaginary tiles ) based on coordinate.
- Assign a terrain for each chunk. This requires hardcoded way of doing this or at least written into an XML file or such.
- Override terrain start functionality and inject your own battle scene that is assigned.
- You have that terrain now.

You need.. well.. roughly a hundred different scenes all customized for battles and such. Would that work? Yeah. But could be too much effort. Requires a huge collaboration but if someone is up to this, we can make it happen.

 

[Piconi]

Split moveable area into tiles ( imaginary tiles ) based on coordinate.

I think it works hand in hand with the artificial and overly bottlenecked map, as it actually has very little walkable space (thus very fewer tiles and maps than tought by a glance on the whole map)

Spoiler: Walkable area

Additionally, as we see by the current Bannerlord Creative Competition, one of the next contest's theme for scening modders might be battlefields.
When that contest finishes, we will get HUGE number of free, hand made battlefields in an OSP pack (same as for villages after this current contest ends), so for any mod to do that afterward, it will be 80% job already done.

 

[Bjorn The Dead]

Uh, that was not quite what I said. I can translate that to English to be clear.

Thanks for correcting misunderstanding made by me.

Any plan to have something where we can `read` the contents of the .bin files to create our own tools for scene creation? Since it's out of discussion for TW to have autogenerated maps, perhaps community create something like I mentioned above. But we need to decode those .bin files first.

So this is our best hope.

 

[Akka]

I would personally preffer a huge set of custom made battle maps, only not having a terrain/climate tag assigned to it (where you get the same map on different locations), but it having a specific place, a tile, on the main map (a square or a hexagon) where only that specific map spawns, and it reflects the main map surroundings and terrain.

It breaks more immersion for me to have different map every time on the exact same spot on the map.

Would need many maps/much time, but if a goal is also a special scene per settlement, i don't see why this can't be as well.

=>

The best method would be procedural maps taking coordinates as seed (so if you fight on the exact same localisation on the world map, you get the exact same map).

What you ask is simply completely unfeasable with hand-made maps, but is very easy with procedural.

I think it works hand in hand with the artificial and overly bottlenecked map, as it actually has very little walkable space (thus very fewer tiles and maps than tought by a glance on the whole map)

Gawd... Honestly, this map just makes me want to puke. It's atrocious, and probably the single most disgusting part of Bannerlord. I really, really, REALLY despise it. It's just... so artificial, so unimmersive and so WORSE than the previous one...

 

[black_bulldog]

I'm in two minds about procedurally generated maps first I hated how the game would spawn some ridiculous maps in WB like sheer cliffs on half the map. On the other hand what we have now with the lack of maps is aggravating because seeing the same maps over and over is beyond dull. I think the biggest problem with the hand drawn maps we have now are that if your army is too large there are maps that will literally kill your troops because of how they spawn. If this is an indication of how poorly the rest of the hand drawn maps are going to be then I would prefer that we have procedurally generated maps. But there needs to be some kind of restriction on how terrain variation we can see because I don't want to feel like I need mountain climbing gear just to do a portion of my battles.

 

[Bloc]

Additionally, as we see by the current Bannerlord Creative Contest, one of the next contest's theme for scening modders might be battlefields.
When that contest finishes, we will get HUGE number of free, hand made battlefields (same as villages after this current one ends), so for any mod to do that it will be 80% job done

I'm really not sure if TW would ever do such a thing and then open all those maps for users to download. I'm not sure but will village scenes be downloadable? I guess not.

At best, community itself can gather talented artists and create such a mod. Still, size will be an issue probably.

The best method would be procedural maps taking coordinates as seed (so if you fight on the exact same localisation on the world map, you get the exact same map).

Agreed. Same logic with Total War games. Which we discussed with someone in another thread I guess. But this comes down to possibility of having procedural maps. Which we wont.

 

[Piconi]

I'm really not sure if TW would ever do such a thing and then open all those maps for users to download. I'm not sure but will village scenes be downloadable? I guess not.

Actually YES, and that's the thing i like most about it

By submitting your work to the contest, you agree that it will be shared with the community at the end of the contest, to be used in various M&B II: Bannerlord modifications, according to the license provided here. None of the submissions will be integrated into the base game.

link^
Only one of the reasons i'm sure hand made maps with pinned locations are doable, and not an impossible number of them is needed in order to achieve that, on the contrary.

 

[scarface52]

Also i still think hand made maps are doable, and not an impossible number of them is needed in order to achieve that, on the contrary.

That's what TaleWorlds (cuce actually) said.

 

[Bloc]

link^

Nice, I missed that point I guess. Then yes, it's possible. I think its way better than having `village` scenes anyway. But TW needs to do this first then they have to put a prize or something and then we have to wait like 3 months for randomly made maps and then pick them for the area coordinates. I still think having a plan for walkable areas and several mappers is more doable.

That's what TaleWorlds said.

Not quite. Piconi is suggesting maps based on campaign map features. TW is considering only the terrain type you are standing on ( biomes ). Having more maps will decrease of the change of you are getting a dejavu for sure, but there is still a chance.

 

[Piconi]

That's what TaleWorlds said.

That's just tagged climate (biomes) with a limited number of maps in its rotation. It means you can still have the exact same map all the way anywhere from, for example , Sturgian border with Battania, and close to Sturgian border with Khuzait, as long as it's in the same biome.

Oh while i was typing, basically what Bloc said ^

 

[Lord Irontoe]

I would personally preffer a huge set of custom made battle maps, only not having a terrain/climate tag assigned to it (where you get the same map on different locations), but it having a specific place, a tile, on the main map (a square or a hexagon) where only that specific map spawns, and it reflects the main map surroundings and terrain.

It breaks more immersion for me to have different map every time on the exact same spot on the map.

Would need many maps/much time, but if a goal is also a special scene per settlement, i don't see why this can't be as well.

A problem with this approach is that, unless you're adding hundreds upon hundreds of unique battlemaps, the "tiles" that hold each map would be pretty big, so if you're hanging around the same area, like say, defending the area around your castle, you'll be fighting on the same one battlefield over and over again, which would also get very repetitive. Though I guess that could be minimized a bit by making each scene really big with random spawn points.

 

[Piconi]

As said above, if/when the modding contest comes to the battlefield theme, the community will get not hundreds, but thousands of battlefields of all sorts.
Out of which probably hundreds will be of excellent quality.

so if you're hanging around the same area, like say, defending the area around your castle, you'll be fighting on the same one battlefield over and over again

So you're saying you will have the advantage of learning the home terrain, and defending it much better than invading a foreign land in terrain you dont recognize?
Joking, i know you had a different point, but what i mentioned is one of the things why i preffer this, if done right.

 

[scarface52]

Doesn't map creators tag strategic positions on their maps for AI to use? How would that even work with auto-generated battlefields? Because without them battles would be even more dumb.

 

[Lord Irontoe]

As said above, if/when the modding contest comes to the battlefield theme, the community will get not hundreds, but thousands of battlefields of all sorts.
Out of which probably hundreds will be of excellent quality.

So you're saying you will have the advantage of learning the home terrain, and defending it much better than invading a foreign land in terrain you dont recognize?
Joking, i know you had a different point, but what i mentioned is one of the things why i preffer this, if done right.

If there are enough to make it interesting, then it would be cool. The best part is that you could potentially have world map landmarks in the scene. It would be like some of the battlefields in The Last Days mod from Warband, where if you fought in the vicinity of Gondor, you'd see the city in the background of the scene.

 

[Suspicious_Man]

It is possible to tweak HEX code but it's not possible to read it's content directly like we do for C# .dll files. You can still get the main logic, but it's hard. You can perhaps modify it. At best, someone can look into terrain.bin files and understand/decode it's content for readable language.

Yep, that's the plan. Starting with the terrain_ed files, starting small, just a 1x1, 4x4, and make small perturbations. Raise the height 1m, see what happens. Look at the hex of the bin, note the changes, see if you can find patterns, figure out where the header is, etc.

That's the way I'm going about it anyway. I don't have that much experience working with binary files though. Would be MUCH easier with some input from TW, or with the help of someone who works with assembly/binary stuff more regularly than I do.

Terrain generation is hard regardless of the language of your choosing. Its up to how you decode their bin files. Then you need knowledge about terrain generation in general. You can create basic perlin noise, distort it and then use that as your heightmap and perhaps apply a hydraulic erosion on the fly before writing onto the file.

I've actually got a project started in C# already, I'm just generating voronoi polygons, using some simplex noise for the heightmap, and then I got stuck trying to implement planchon darboux because I'm garbage at C# so I put it down for a while. I think a quick hydraulic erosion and then some more finessing to generate splat maps based on elevation/slope/hydrology/etc and I'll have most of what I need to at least make some basic terrains for battle scenes. It's also all probably terribly optimized because, again, I don't know C# lol. But there is progress on that front at least and I sort of know what I'm doing there (just not in C#).

 

[Bloc]

Doesn't map creators tag strategic positions on their maps for AI to use? How would that even work with auto-generated battlefields? Because without them battles would be even more dumber.

With Auto Generated Strategic Positions. Current positions are not super fancy anyway. Tagging high grounds, retreat positions and such. Finding a hill on a coordinate data is an intern hiring question, so TW engineers are more than capable of doing that.

Would be MUCH easier with some input from TW, or with the help of someone who works with assembly/binary stuff more regularly than I do.

I doubt they will provide something in near feature. If they would, it would be cool. I'm waiting for @Dejan 's answer on that one if possible. But your way might uncover some differences for sure. At least you can perhaps decypher the height values and such and we might not need to override the entire file but only tweak a little.

I've actually got a project started in C# already, I'm just generating voronoi polygons, using some simplex noise for the heightmap, and then I got stuck trying to implement planchon darboux because I'm garbage at C# so I put it down for a while.

I'm guessing you are not generating this on Bannerlord, right? Also, I wouldn't advise generating map from scratch polygon and adding into game.
Since game do have some form of "map" generation based on heightmap ( in game editor ), all we need is that particular code to generate the date and extract it. Then you can basically create an image with whatever the coding language you like ( you can bind your C++ dlls for heightmap generation, or even add some Python OpenCV to ease your pain ) and use that image data to generate a battlefield within the game engine and extract it's data. Still, too abstract since TW didn't share anything and I'm guessing that entire Modding Tools is embedded inside the engine so it's not written in C#, or at least that core functionality

 

[Suspicious_Man]

With Auto Generated Strategic Positions. Current positions are not super fancy anyway. Tagging high grounds, retreat positions and such. Finding a hill on a coordinate data is an intern hiring question, so TW engineers are more than capable of doing that.

Yes, that was my thought as well. Just procedurally look for spots with certain slope/elevation for tactical positions or splat map coverage I guess (for forests/open positions). I wasn't worried as much about that part of it. Same thinking for the nav mesh, I have an almost automated process for it now based on slopes when I make battle scenes, just need to figure out how to code what I do in the editor and convert it into the navmesh binary.