Yet another random map generator

[aeonios]

Hmm. I think I can sort of see where you're coming from with wanting to represent the map data as a collection of objects containing point/height/slope rather than just an array of height data. That would certainly allow you to treat map points more uniformly when performing various operations and current support for slope-based operations is very poor to say the least.

On the other hand I don't really understand how you're trying to create entire maps from scratch in a single pass using fractal/viscosity type logic. The current rmgen functions are fairly easy to understand when reasoning about geometry, although also fairly limited for doing certain other things. I'd like to see an example of a real (playable) random map made using this method and the sort of code/calls that you'd use to produce it. It's easier to understand things when you have a context to go on.

Since this may in fact offer a significant improvement over the generic rmgen method I don't really want to overlook it as a possibility, and I am working on improving random maps for a24.

[Pyrophorus]

3 hours ago, aeonios said:

On the other hand I don't really understand how you're trying to create entire maps from scratch in a single pass using fractal/viscosity type logic. The current rmgen functions are fairly easy to understand when reasoning about geometry, although also fairly limited for doing certain other things. I'd like to see an example of a real (playable) random map made using this method and the sort of code/calls that you'd use to produce it. It's easier to understand things when you have a context to go on.

Take a look at the "anEgyptianOasis" random map in the mod, and you'll make an idea. IMO, the rmgen functions are too "geometric" to create easily realistic maps, even if some random maps are rather  good at it (with a lot of work and execution time, "blurring" the map in some way to hide the geometric artifacts). My work aim only at providing some tools to get easily bases to design maps (random or not).

Friendly,

[aeonios]

40 minutes ago, Pyrophorus said:

Take a look at the "anEgyptianOasis" random map in the mod, and you'll make an idea. IMO, the rmgen functions are too "geometric" to create easily realistic maps, even if some random maps are rather  good at it (with a lot of work and execution time, "blurring" the map in some way to hide the geometric artifacts). My work aim only at providing some tools to get easily bases to design maps (random or not).

Friendly,

It doesn't work with a23. InitMap and ExportMap have been converted into methods in a23 using the RandomMap prototype so trying to call those functions fails. I have no idea what they used to do so I can't really replicate it either. 

[Stan`]

@elexis

[elexis]

I'm here

[Stan`]

6 hours ago, elexis said:

I'm here

What happened to Init map and and export map ?

[Pyrophorus]

Don't worry... I have been on trip these days and I have not yet finished to update my add-ons to A23 (A lot of files renaming and moving in the "art" folder totally ruined my personal faction ). I will update YAMG soon and notify here when done.

8 hours ago, aeonios said:

I have no idea what they used to do so I can't really replicate it either. 

InitMap creates the g_Map object to fill and ExportMap save it to the engine. They must have been replaced with something.

Friendly,

[Stan`]

2 minutes ago, Pyrophorus said:

A lot of files renaming and moving in the "art" folder totally ruined my personal faction

Sorry bout that. If you want a make amod about that I could probably make some pull requests

 

[Pyrophorus]

2 hours ago, stanislas69 said:

Sorry bout that. If you want a make amod about that I could probably make some pull requests

No... I doubt this civ could interest anyone. It's outrageously overpowered to face 500/600 foes and win, like Leonidas at Thermopyles battle. I use it to test some features too, design technologies and auras, create new units using existing props and meshes, just for fun. If no mods are impacted by your changes, there's no need to worry about.

Friendly,

[elexis]

Since the library was rewritten for 6 months every day, this won't be the last thing you may have questions about.

One can find out such things with svn blame and log or in case of good commit messages by simply searching for that name on trac:

https://trac.wildfiregames.com/search?q=exportmap&noquickjump=1&changeset=on

The easiest way to learn about changes is to look at any of the map codes in alpha 23 and see how it's structued.

Every map is sequence of some declarations (terrains, entity templates, heights), 1 map init statement, like 20 createArea and createObjectGroup calls, timed logging in between and 1 export call.

Will you remove Alpha 22 backwards compatibility code or extend it to achieve Alpha 23 compatibility?

[Pyrophorus]

4 hours ago, elexis said:

Since the library was rewritten for 6 months every day, this won't be the last thing you may have questions about.

Aeonios (relayed by Stan) had a question about old InitMap() and ExportMap(). Those should obviously replaced with:

var g_Map = new RandomMap(heightShore, tHill);
g_Map.ExportMap();

It's probably not the only change to make the random script and the library to work with A-23, but I don't know yet which are needed. Very few probably.

For myself, I have no question. Thanks...

4 hours ago, elexis said:

Will you remove Alpha 22 backwards compatibility code or extend it to achieve Alpha 23 compatibility?

I don't know. Backward compatibility is not my priority since I believe nobody uses my library yet.

Friendly,

[aeonios]

Nobody uses a22 anymore either.

I think your fractal placers and painters have the potential to produce much better looking mountains, lakes, continents, etc than the current library allows for. I think with a better interface and integration with other library functions it could/should be included for a24. The usage in anEgyptianOasis was kind of raw and lower level than what random map designers ought to be exposed to. Even the rmgen interface in a23 is a bit junky and I've been working on improving that and making it easier/more consistent to use.

[Stan`]

Get things moving

[Pyrophorus]

10 hours ago, aeonios said:

The usage in anEgyptianOasis was kind of raw and lower level than what random map designers ought to be exposed to

Could you elaborate what you have in mind ? I'm interested in improvement suggestions. (BTW, this random script is more a proof of concept than a playable map).

Friendly,

[aeonios]

21 hours ago, Pyrophorus said:

Could you elaborate what you have in mind ? I'm interested in improvement suggestions. (BTW, this random script is more a proof of concept than a playable map).

Friendly,

After sifting through the library I've sort of begun to understand how your painters and placers work now.

The painters I can mostly understand although I haven't figured out what kind of values it expects for all the params. One thing that does bother me is that the fractal painter seems to expect a roughly circular area when placing. What then would happen if you fed it a non-circular area, like say a long wavy region produced by a path placer? As is it might be difficult to integrate usefully with existing rmgen library utilities. While I'm not sure if that's actually an issue or not, the interface is also nonstandard for painters. The area param should be moved to paint() and the 'nochiasm' param should be moved to the constructors. Beyond that I'd have to play around with it to see what it can do.

For 'nochiasm' I can sort of see and appreciate how that works, but it also lacks a 'modify' type functionality like the current elevation painters offer, which is useful if you don't know ahead of time what the base elevation will be (for example when using diamond-square for initial terrain randomization).

The placer interface is terrible. In the map you do some sort of weird raw loop to create a "monts" zone and some others which I don't really understand the point of. Reimplementing constraints and things from scratch in an even less intuitive fashion is less than ideal. It'd be better to extend the RandomMap prototype with that kind of stuff. Personally I don't really like how the current tileclass system works, since each tileclass is effectively defined as a random bag of points, which is particularly inefficient for checking constraints later on and also means that a given point may belong to more than one tileclass, which is kind of bad when you're creating a map by painting layers. However constraints are very convenient, or at least the interface for them is (which I've submitted a patch to improve even further).

The current (rmgen) implementation doesn't handle slope hardly at all, which could definitely be improved as well.

I can certainly see the usage of the road creating function although I can't really tell if it auto-flattens terrain to create a path if there isn't already one, but that would be nice. It seems like something that would need a lot of tuning but it's definitely a cool feature. The existing road function sucks.

I cannot really figure out the purpose of the YPatchPlacer, or how it differs from any other sort of placer.

Cramming all that stuff in with the TOMap doesn't make much sense. The TOMap should have its own interface, and the placement/road functions should have their own, possibly moved into gaia_terrain or wherever happens to be most appropriate.

[Pyrophorus]

Thanks for this interesting reply !

4 hours ago, aeonios said:

What then would happen if you fed it a non-circular area, like say a long wavy region produced by a path placer?

It works on any region (even not connex) but maybe the result will be rather unnatural if the region is very thin and the bump parameter set to high values.

4 hours ago, aeonios said:

While I'm not sure if that's actually an issue or not, the interface is also nonstandard for painters.

I can't tell exactly because I haven't yet look at the new painters interface (I'm busy with retrieving the functions which vanished or have been renamed and figure if they work as before). In A-22, the interface  was standard with some extension: I don't like the idea to recreate a new painter each time you need one. Now, this would be really important if all this was to go into rmgen, but I don't think it will happen soon.

4 hours ago, aeonios said:

For 'nochiasm' I can sort of see and appreciate how that works, but it also lacks a 'modify' type functionality like the current elevation painters offer, which is useful if you don't know ahead of time what the base elevation will be (for example when using diamond-square for initial terrain randomization).

I have no idea of what could be this 'modify' functionality I will take a look at it.

4 hours ago, aeonios said:

The placer interface is terrible. In the map you do some sort of weird raw loop to create a "monts" zone and some others which I don't really understand the point of. Reimplementing constraints and things from scratch in an even less intuitive fashion is less than ideal. It'd be better to extend the RandomMap prototype with that kind of stuff.

There are some screen shots in the documentation showing what you can expect from it. Rmgen placers blindly select points on the map not taking into account the underlying relief, but this one does. Now it's really easy to implement constraints in the rmgen fashion from my model. I have given examples in an older version of the library. Of course, I agree with you about extending the RandomMap object, and maybe you read the discussion we had earlier in this thread about it. It would remove the need of a separate TOMap object. But dev staff is reluctant to this idea.

5 hours ago, aeonios said:

I can certainly see the usage of the road creating function although I can't really tell if it auto-flattens terrain to create a path if there isn't already one, but that would be nice

Yes it does even if this need to be seriously improved.

5 hours ago, aeonios said:

Cramming all that stuff in with the TOMap doesn't make much sense.

Yes, you're right, but you're thinking in the perspective of a rmgen integration which is still very problematic for now.

Friendly,

[aeonios]

7 hours ago, Pyrophorus said:

It works on any region (even not connex) but maybe the result will be rather unnatural if the region is very thin and the bump parameter set to high values.

Well that's good to know.

7 hours ago, Pyrophorus said:

I can't tell exactly because I haven't yet look at the new painters interface (I'm busy with retrieving the functions which vanished or have been renamed and figure if they work as before). In A-22, the interface  was standard with some extension: I don't like the idea to recreate a new painter each time you need one. Now, this would be really important if all this was to go into rmgen, but I don't think it will happen soon.

I think the only difference is that paint() should take an area as input. It's a pretty simple fix. Creating a new painter isn't really a major overhead, and usually you only create a painter once per major job. Like if you wanted to paint mountains, you'd probably create a painter for that, create all your mountains, and then discard it. You wouldn't create a new painter for each mountain. Of course if you have two different functions creating two different types of mountains, then each would create its own painter, but that's a minor detail.

I suspect that the biggest overhead for map generation is actually checking constraints, which may be O(n*m) where n is every tile being written to and m is every point owned by every tileclass that needs to be checked for the constraints. If tileclasses were reduced to a single tilemap with one allowed class per tile, then checking constraints could probably be reduced to near constant time.

7 hours ago, Pyrophorus said:

There are some screen shots in the documentation showing what you can expect from it. Rmgen placers blindly select points on the map not taking into account the underlying relief, but this one does. Now it's really easy to implement constraints in the rmgen fashion from my model. I have given examples in an older version of the library. Of course, I agree with you about extending the RandomMap object, and maybe you read the discussion we had earlier in this thread about it. It would remove the need of a separate TOMap object. But dev staff is reluctant to this idea.

There are actually two ways that can already be used to achieve that with current rmgen. The first is constraints and the second is to use placement within an area. Both methods can be combined as well. The only thing it doesn't support is using slope or height in constraints, but it would be pretty trivial to extend constraints to support that. I've also extended the library with a function that allows you to get an area from a set of constraints, making it easy to increase the success rate of operations which would otherwise fail heavily due to restrictive constraints. With all of that I'm not really sure if the TOmap is really necessary.

Getting stuff included in rmgen isn't really that difficult. The fractal painters could be added immediately with just a little bit of cleanup and updating. The other stuff would probably need to be reformulated, which would be more work but that ultimately depends on how much of it is actually needed.

[Pyrophorus]

Hi, everyone

37 minutes ago, aeonios said:

There are actually two ways that can already be used to achieve that with current rmgen. The first is constraints and the second is to use placement within an area. Both methods can be combined as well. The only thing it doesn't support is using slope or height in constraints, but it would be pretty trivial to extend constraints to support that.

No, the YPatchPlacer doesn't work with constraints even if you can add surrerogatory constraints in the parameters. It makes a region grow around a starting point, selecting on the border the best candidate to expansion. It's not the same as selecting in the whole map or in a region tiles matching a set of constraints. Try to get something like the examples I gave in this very thread and you'll see.

47 minutes ago, aeonios said:

I've also extended the library with a function that allows you to get an area from a set of constraints, making it easy to increase the success rate of operations which would otherwise fail heavily due to restrictive constraints. With all of that I'm not really sure if the TOmap is really necessary. 

The TOMap object is not technically necessary. I could have stored all it's stuff in the g_Map object itself. The reason why I didn't is devs opinion. They think there's a risk ExportMap could fail if g_Map houses some extra stuff. The major design problem is not here but in the Cell object TOMap holds. In my development, there's only one object holding all tile properties and in rmgen there are potentially many. It's exactly the same problem in databases design when one duplicates the same data in different tables, and worse, in Javascript, we have no triggers to keep the data in sync. Now it solves the constraints checking problem as well. You may say I implemented them in an obscure way and I agree but any set of constraints can be tested in two bitwise operations and I doubt you can find faster. A convenient interface can be easily designed to expose them in a more understandable way of course.

Now I'm a little uneasy with your last comments because you speak as if you were the project manager in charge of the future of rmgen and able to decide which part of my work should be integrated and which modifications should be made for that, including it in this refactoring project of yours. I have nothing against it, but maybe you could remember you're not the only one making decisions about rmgen. Personally, I have no opinion about this integration because my goal is to offer a large pallet of tools everyone can use or not at will, so they can come in a mod or in mainstream as well. To me, the fact different placers can achieve the same result is not an issue: I will not tell the RectanglePlacer should be dropped because my PatchPlacer can do the same. It's true, but if you want a plain rectangle, the Rectangle Placer is much simpler to use, and why not have both ?

Now you suggest my design changes are not necessary, but the proof is in the result. AnEgyptianOasis produces a fully featured giant map with eight players in about five seconds (with roads and all the shebang). AFAIK, many legacy scripts just hang miserably on this map size after some minutes. Maybe you can do the same or even better using the rmgen data model, but for now, it's only a promise, not a result. Don't misunderstand me: I don't intend to be rude, but I don't work for you or other programmers, because I perfectly know you don't need me to create what you want. To you, all my work is obviously unnecessary, but I work for end users who have nothing to do with these specialists discussions, and I'm sure very few of them enjoy to look at a choked idle computer.

IMO, the end user should decide what is useful and convenient, and not the specialists we are, and to me it's far more important to get the feedback from map scripters and even from those who would like to script maps and can't because... Because what ? We don't know and here is the point  to focus at. If not, we only fall into the well known trap waiting every programmer: create software for programmers and not for end users. That's why I started this thread: mainly to have end users feedbacks telling me how to make my library more accessible and convenient to their uses and unfortunately, I have very few. Yeah, I got a lot of likes and appreciations which is kind and satisfactory, but don't help me much.

Friendly,

[aeonios]

35 minutes ago, Pyrophorus said:

The TOMap object is not technically necessary. I could have stored all it's stuff in the g_Map object itself. The reason why I didn't is devs opinion. They think there's a risk ExportMap could fail if g_Map houses some extra stuff. The major design problem is not here but in the Cell object TOMap holds. In my development, there's only one object holding all tile properties and in rmgen there are potentially many. It's exactly the same problem in databases design when one duplicates the same data in different tables, and worse, in Javascript, we have no triggers to keep the data in sync. Now it solves the constraints checking problem as well. You may say I implemented them in an obscure way and I agree but any set of constraints can be tested in two bitwise operations and I doubt you can find faster. A convenient interface can be easily designed to expose them in a more understandable way of course.

Are you saying that you can determine, with only two bitwise operations, if a tile lies at least x distance from the nearest tile of a particular tileclass? Or that it lies between at least x and not more than y distance from a particular tileclass? If you can then it'd be fairly miraculous. That's also the sort of constraints that are very commonly used when generating maps. Now I don't completely understand how all your placer functions work, or what would make them better than existing placers, so maybe there is a motivation for doing things the way you've done them. I have yet to see the results they produce so it's difficult to make any judgments at this point.

On the other hand g_Map is in no danger as long as you don't mess with anything the engine needs, which isn't a whole lot. This is the engine export function:

Engine.ExportMap({
	"entities": this.exportEntityList(),
	"height": this.exportHeightData(),
	"seaLevel": SEA_LEVEL,
	"size": this.size,
	"textureNames": this.IDToName,
	"tileData": this.exportTerrainTextures(),
	"Camera": g_Camera,
	"Environment": g_Environment
});

Adding a TOmap as an extra internal structure would not affect this in the least.

If I understand correctly, your placing/road algorithms work like a sort of flood-fill pathfinding expansion. That's interesting but it still leaves a lot of questions.

 

44 minutes ago, Pyrophorus said:

Now I'm a little uneasy with your last comments because you speak as if you were the project manager in charge of the future of rmgen and able to decide which part of my work should be integrated and which modifications should be made for that, including it in this refactoring project of yours. I have nothing against it, but maybe you could remember you're not the only one making decisions about rmgen. Personally, I have no opinion about this integration because my goal is to offer a large pallet of tools everyone can use or not at will, so they can come in a mod or in mainstream as well. To me, the fact different placers can achieve the same result is not an issue: I will not tell the RectanglePlacer should be dropped because my PatchPlacer can do the same. It's true, but if you want a plain rectangle, the Rectangle Placer is much simpler to use, and why not have both ?

Now you suggest my design changes are not necessary, but the proof is in the result. AnEgyptianOasis produces a fully featured giant map with eight players in about five seconds (with roads and all the shebang). AFAIK, many legacy scripts just hang miserably on this map size after some minutes. Maybe you can do the same or even better using the rmgen data model, but for now, it's only a promise, not a result. Don't misunderstand me: I don't intend to be rude, but I don't work for you or other programmers, because I perfectly know you don't need me to create what you want. To you, all my work is obviously unnecessary, but I work for end users who have nothing to do with these specialists discussions, and I'm sure very few of them enjoy to look at a choked idle computer.

Well in order for it to be useful it either has to do something that the existing placers can't, or it needs to do the same thing much faster, or be easier to use, or offer some other advantage. Otherwise it's just duplicate code. As I don't really understand what it actually does or how it works I can't really make any judgements on it.

And of course I'm not the only person working on random maps, but I am in fact doing significant work on it. Our players want better looking, better balanced maps, and I'm doing my best to deliver on that for a24. I'm trying to understand your work to see how it fits into those goals, so that I can usefully integrate it if it is and to fight tooth and nail to have the code accepted if necessary. The interest people have shown in your work is evidence that it's at least something in the right direction.

In terms of performance, that's great on paper but if you can't produce the same or better results to the maps people are playing now, then it's a moot point. At this point I've gotten your fractal painters working and have been messing around trying to get good results with that, but it's still only a part of the whole package. It's hard to make a case for something that I haven't even got working, let alone understand the usage of.

1 hour ago, Pyrophorus said:

IMO, the end user should decide what is useful and convenient, and not the specialists we are, and to me it's far more important to get the feedback from map scripters and even from those who would like to script maps and can't because... Because what ? We don't know and here is the point  to focus at. If not, we only fall into the well known trap waiting every programmer: create software for programmers and not for end users. That's why I started this thread: mainly to have end users feedbacks telling me how to make my library more accessible and convenient to their uses and unfortunately, I have very few. Yeah, I got a lot of likes and appreciations which is kind and satisfactory, but don't help me much.

Friendly,

Eh, I'm not just hacking at the library without any understanding of how it's used. I've been actively working on making map scripts, and have done improvements for at least 3 different maps now. A lot of the work I've done on the library has been to make life easier for that. Map scripting isn't exactly something you can do without at least some degree of technical expertise, but I have been trying to make it more idiot-proof and less demanding in terms of needing to know exactly what every function expects as input.

If you want to see the sort of thing I've been working on I could either dump it into a mod (assuming that the mod's files will override the default ones, I guess) or you could pull my patches from phabricator: https://code.wildfiregames.com/D1501 and https://code.wildfiregames.com/D1497

although fair warning the map script isn't up to date since there's a feature freeze I haven't bothered. I'll probably update it later today though, and maybe add my ardenne forest remake since that's pretty well cleaned up now.

[Pyrophorus]

7 hours ago, aeonios said:

That's also the sort of constraints that are very commonly used when generating maps.

No. More accurately, it's the only way script currently have to do things like resources or players bases setting. Maybe you're not aware you're immediately formalizing the problem using geometry as if it was the only solution. But we're not designing a geometry solver but building a convincing illusion of a landscape and using geometry is not mandatory. It's only the most obvious way to go. Maybe you missed  the fact my work uses very little geometry if any. It's not coincidence. First of all, rmgen already offers a lot of geometry based features, and it would be stupid to duplicate them. Next, euclidian geometry applies on euclidian spaces not on meshes we're working on. To give an practical example, the YPatchPlacer can compute the border of a region. One can of course discuss the accuracy of the result and try to prove it is wrong using a mathematical method to compute an accurate border. But, rounding the result to fit the map mesh will ruin this accuracy, and I bet the final differences between both methods shall be unnoticeable. BTW, the feature exists not in rmgen and there's no easy way to expand a region as well. Same with slope: mathematically speaking, slope is a vector, not a scalar and is not constant on most tiles because, generally, they're not plane. Rmgen computes a slope factor in a way, I do otherwise, but nobody is right, both are wrong. And last but not least, geometric procedures generate regularity and monotony which can be avoided only adding a lot of noise.

That's why I explore other ways to create maps and I hope here to enlarge the tools choice, not replacing anything. If someone is more easy with constraints in rmgen fashion, it's OK to me, of course. But don't tell me those constraints are absolutely necessary features. One more time, the proof is in the result: I don't use constraints, only locks and regions. And  as you say:

17 hours ago, aeonios said:

The interest people have shown in your work is evidence that it's at least something in the right direction.

Thanks, you're clearly not ready yet to enter my fan club but time helping, who knows ? But I disagree: there is not a single good direction. There are many each one having it's strong points and drawbacks. I think this at least partly explain why I meet some incomprehension among developers here. They try to make me enter the Procust's bed of their geometric model and can't see why I resist.

16 hours ago, aeonios said:

In terms of performance, that's great on paper but if you can't produce the same or better results to the maps people are playing now, then it's a moot point.

What do you mean here ? It's not "on paper", this script is working and you will be able to verify it as soon as the A-23 upgrade will be out.  Now, don't expect me to reproduce exactly existing maps  to create a valid benchmark. I should reproduce even their defects which is ridiculous and impossible: can you really admit at last my placer is not a duplicate of any rmgen placer ?  It's like a knife and a corkscrew: both can be put at some limited purposes like opening a bottle but you wouldn't try to peal an apple with a corkscrew. And yes a knife can be used to open bottles, but does this means corkscrews are useless ?

16 hours ago, aeonios said:

Eh, I'm not just hacking at the library without any understanding of how it's used.

Of course not, but your user experience is not very valuable to me because many things are known or even so obvious to you that you imagine not their ignorance can be an obstacle to ordinary users (I have the same problem of course and anyone having some degree of technical expertise, as you say). An example is the "random" label we put on these maps scripts. They are fully deterministic and the only "random" thing in it is you can let the computer choose a map within the large set of maps the script can produce (2^16 I think but maybe it's 2^32 or even 2^64). To you, there is probably no mystery here, but it's against common acceptance of the word "random" and it can puzzle people knowing not how a pseudo RNG works.

The challenge here is to learn how end users figure in their mind the process of creating a fully featured map, as a cooking recipe, using their words and not ours. Believe me, this is far less obvious than it looks.

Friendly,

[aeonios]

11 hours ago, Pyrophorus said:

No. More accurately, it's the only way script currently have to do things like resources or players bases setting. Maybe you're not aware you're immediately formalizing the problem using geometry as if it was the only solution. But we're not designing a geometry solver but building a convincing illusion of a landscape and using geometry is not mandatory. It's only the most obvious way to go.

Well yes, and it's also pretty good at producing playable maps the majority of the time. Most maps never become strictly unplayable and for the few that have the potential it's still rare and easy to avoid for the most part. Judging by your screenshots that seems considerably more difficult with your method.

11 hours ago, Pyrophorus said:

Maybe you missed  the fact my work uses very little geometry if any. It's not coincidence. First of all, rmgen already offers a lot of geometry based features, and it would be stupid to duplicate them. Next, euclidian geometry applies on euclidian spaces not on meshes we're working on. To give an practical example, the YPatchPlacer can compute the border of a region. One can of course discuss the accuracy of the result and try to prove it is wrong using a mathematical method to compute an accurate border. But, rounding the result to fit the map mesh will ruin this accuracy, and I bet the final differences between both methods shall be unnoticeable. BTW, the feature exists not in rmgen and there's no easy way to expand a region as well.

Actually it is possible to expand regions, using an appropriate border constraint. ChainPlacer also expands its region by placing circles of various sizes (down to 1 tile if desired) at the borders of its region, and in some cases produces shapes very similar to YPatchPlacer. I'm not really sure how the cost compares between the two.

11 hours ago, Pyrophorus said:

Same with slope: mathematically speaking, slope is a vector, not a scalar and is not constant on most tiles because, generally, they're not plane. Rmgen computes a slope factor in a way, I do otherwise, but nobody is right, both are wrong. And last but not least, geometric procedures generate regularity and monotony which can be avoided only adding a lot of noise.

Well slope can be expressed either as a vector or as a scalar, each of which conveys different information about how the underlying mesh varies over space. One or the other might be more useful depending on what you're trying to do. Also with regards to noise, there are professional terrain programs such as terragen and world machine that create terrain maps using basically nothing but specific sorts of noise. I don't see that as being a drawback, but rather something that should be put to good use. Diamond-square makes nice maps as is, at least for base terrain, and can be more or less randomized or customized as you care for it to be. Of course it doesn't do everything, but I'm specifically looking for something new and useful.

11 hours ago, Pyrophorus said:

Thanks, you're clearly not ready yet to enter my fan club but time helping, who knows ? But I disagree: there is not a single good direction. There are many each one having it's strong points and drawbacks. I think this at least partly explain why I meet some incomprehension among developers here. They try to make me enter the Procust's bed of their geometric model and can't see why I resist.

I dunno. I've been playing around with the fractal painter and I wasn't able to get anything more than pointy lumps with a few sharp edges, a rather far cry from the nice mountains I was hoping for. I played around with the params quite a bit and they still don't make any particular sense to me. I never got anything even vaguely resembling your screen shots, although YFractalPainter was the only one I really messed with.

12 hours ago, Pyrophorus said:

What do you mean here ? It's not "on paper", this script is working and you will be able to verify it as soon as the A-23 upgrade will be out.  Now, don't expect me to reproduce exactly existing maps  to create a valid benchmark. I should reproduce even their defects which is ridiculous and impossible: can you really admit at last my placer is not a duplicate of any rmgen placer ?  It's like a knife and a corkscrew: both can be put at some limited purposes like opening a bottle but you wouldn't try to peal an apple with a corkscrew. And yes a knife can be used to open bottles, but does this means corkscrews are useless ?

Perhaps. I've at least seen the screen shots of anEgyptianOasis, but I still only barely understand how that script works (and I have no idea whatsoever how it creates mountains or anything else with terrain). I've also seen a lot of weaknesses so far, like the sharp vertical edges at the boundaries of the YFractalPlacer's hills, and various other sorts of artifacts (some of which produce unplayable maps), but I have yet to see any particular strength that could be further developed. That's not to say there aren't any, just that if they are then I don't understand them or how to use them at all. And that's coming from someone with a fair amount of technical expertise.

12 hours ago, Pyrophorus said:

Of course not, but your user experience is not very valuable to me because many things are known or even so obvious to you that you imagine not their ignorance can be an obstacle to ordinary users (I have the same problem of course and anyone having some degree of technical expertise, as you say). An example is the "random" label we put on these maps scripts. They are fully deterministic and the only "random" thing in it is you can let the computer choose a map within the large set of maps the script can produce (2^16 I think but maybe it's 2^32 or even 2^64). To you, there is probably no mystery here, but it's against common acceptance of the word "random" and it can puzzle people knowing not how a pseudo RNG works.

The challenge here is to learn how end users figure in their mind the process of creating a fully featured map, as a cooking recipe, using their words and not ours. Believe me, this is far less obvious than it looks.

Well yes, but random map scripts aren't something that a layman can or ever will create. That's just how it is. If a layman wants to create a map they use atlas. That's what it's for. If you want to create a random map script then you need some level of technical expertise and there's no way around it. We can of course make it easier to use, for people who do have some level of technical expertise, but that's it. There's no way to dumb things down any further than that without degrading the quality of the maps it can produce or the level of customization that is currently possible.

If you don't have a basic understanding of how a pseudo-RNG works, or if you can't figure out how javascript works, then you can't make a random map script. And that's fine, because it's a difficult thing to get good, playable, balanced maps that don't look like they were scraped out of a garbage can using a script. It's something that people with no technical expertise would have little to no chance at doing one way or the other. I mean even world machine, the easiest to use pro terrain making program that has a GUI interface to all of its script components, is extremely difficult and complicated to get good results with. In fact it'd probably be simpler with a js interface like we're using.

[Pyrophorus]

Hi,

On 6/3/2018 at 6:59 AM, aeonios said:

Well yes, and it's also pretty good at producing playable maps the majority of the time. Most maps never become strictly unplayable and for the few that have the potential it's still rare and easy to avoid for the most part. Judging by your screenshots that seems considerably more difficult with your method. 

So what ? Except denigrating my work, I can't see the purpose of this. It would be interesting if you could provide some measuring tool for playability and players respective advantages (balance) It would certainly be nice to have this. But I fear you have none, and all this is only an opinion. I don't work with opinions, only facts and algorithms.

On 6/3/2018 at 6:59 AM, aeonios said:

Well slope can be expressed either as a vector or as a scalar, each of which conveys different information about how the underlying mesh varies over space.

I would be glad to know how you would simulate water running downhills with a scalar definition of slope. If greater than zero, you'll know it should run, but where ? You need a direction for that, and what's the name of something having a (scalar) modulus and a direction ? A vector, isn't it ? You can split the two in different variables and call them as you want, but this don't change what they really are. I don't like long members names, but if not, I would have used 'very_inaccurate_slope_modulus_approximation' instead of 'slope' in my program. This crude approximation is sufficient for my current needs, but pretending it's slope definition would be language abuse. Sorry, but even if your sentence looks good, it is very confusing. Every variable convey information in a program, and "varying over space" is a very vague formulation. We have functions, gradients and derivatives to describe accurately 2D surfaces and the fact a mesh is not a continuous surface is a difficulty in the modeling problem. We're only making illusions  here, and even very convincing, they aren't science in any way and don't allow us to redefine at our fancy scientific notions.

On 6/3/2018 at 6:59 AM, aeonios said:

Also with regards to noise, there are professional terrain programs such as terragen and world machine that create terrain maps using basically nothing but specific sorts of noise

Maybe you noticed not, but this is exactly what the fractal algorithm does, even if in professional softwares they obviously have much more elaborated algorithms. The point is noise is used as the map production mechanism, not a way to blur too regular maps previously created with geometric procedures.

On 6/3/2018 at 6:59 AM, aeonios said:

Actually it is possible to expand regions, using an appropriate border constraint.

Yeah, creating a tile class first, applying the constraint to create a new region containing the border and finally merging it into the initial region. First two steps are fairly time consuming as you know, particularly on large regions (I remember someone writing somewhere tile classes and constraints were very inefficient in  rmgen. Was it you or not ? I wonder...) . With a YPatchPlacer, you can do that using its 'expand' method, without using expansive data structures and computations (BTW, no rmgen placer has such a method). Keep peeling apples with a corkscrew if you prefer, yes it works and I have nothing against it. The really interesting point is both methods don't give exactly the same result: rmgen will add a border equally large everywhere and the YPatchPlacer don't (and can't easily). Is this regularity desirable or not ? It's map author choice.

 

On 6/3/2018 at 6:59 AM, aeonios said:

Perhaps. I've at least seen the screen shots of anEgyptianOasis, but I still only barely understand how that script works (and I have no idea whatsoever how it creates mountains or anything else with terrain).

How can you expect to produce constructive criticisms about something you  understand not ? It's impossible to anyone, including geniuses, you know, so it results only in rather sterile bashing. Try to understand or turn to something else, it would be better to everyone.

Friendly,

[elexis]

On 6/1/2018 at 5:26 PM, aeonios said:

The only thing it doesn't support is using slope or height in constraints

A23 has SlopeConstraint and HeightConstraint

On 6/1/2018 at 11:22 PM, Pyrophorus said:

The reason why I didn't is devs opinion. They think there's a risk ExportMap could fail if g_Map houses some extra stuff

Don't recall if FeXoR other devs commented on it, but my opinion is about minimizing code complexity while maximizing effects and performance. Increased code complexity without adding new features can increase the error-proneness in the entire related code and generally gives more maintenance and consumer more reader time. If alternative data structures can make things faster, it were less maintenance and errorproneness if they would replace existing data structures where possible. (At least that was the aspect I recall when I looked at this the last time.)

On 6/1/2018 at 11:22 PM, Pyrophorus said:

You may say I implemented them in an obscure way and I agree but any set of constraints can be tested in two bitwise operations and I doubt you can find faster

I don't know if it's true, but code should only be obscured if we don't have an alternative. There are some extremely slow bottlenecks in the code (+1min time), but obscuring the code to improving the map loading time from 14 to 13 seconds seems meh. rmgen doesn't scale well, so if one wants to argue with performance, one could test if proposed alternatives to the current code could allow larger mapsizes than 512*512. (I found it a bit sad to not be able to create a larger map for the jebel barkal scene in the a23 trailer than that giant one.)

On 6/1/2018 at 11:22 PM, Pyrophorus said:

so they can come in a mod

I'm personally happy to take up new random map code into the map base, as long as we don't have too different ways to create maps. First time readers are mostly familiar with Spahbods mapping style, but FeXoRs maps (Caledonian Meadows, Deep Forest iirc) used entirely different code for mapgen, same as wraitiis maps (Belgian Uplands, Pyrennean Siera, for instance) or _kalis maps (rmgen2/, Ambush, Red Sea). To some degree it has been reinvention of the wheel three times, so I'm just cautious to add more redundancy.

Diversity of approach in the random map scripts is good, but in the library only where it is really needed. In Alpha 23 a lot of things were made more conform and the Placer/Painter/Constraint interfaces were used where possible (some of the new Painters and Placers were converted from global heightmap library functions or abstracted from code of individual maps). Since these are interfaces, It allows people to understand what a new prototype does even before they read its contents.

What I wanted to say is that we have this ingame mod downloader in alpha 23 and you could spread your maps there too (after one of WFG signed it).

On 6/1/2018 at 11:22 PM, Pyrophorus said:

I will not tell the RectanglePlacer should be dropped because my PatchPlacer can do the same. It's true, but if you want a plain rectangle, the Rectangle Placer is much simpler to use, and why not have both ? 

Yes, different noise placers should be fine too if they are different enough.

On 6/1/2018 at 11:22 PM, Pyrophorus said:

Now you suggest my design changes are not necessary, but the proof is in the result. AnEgyptianOasis produces a fully featured giant map with eight players in about five seconds (with roads and all the shebang). AFAIK, many legacy scripts just hang miserably on this map size after some minutes

Yes, that is the performance we should try to achieve. But ideally it should be achieved by all maps. If a new library can do the same faster, all the maps should switch over too to faster equivalent code where possible. Also code readability improvements (less lines of codes) that make things slower but not measurably slower should be prefered IMO (to improve map author performance).

5 seconds is really promising for a large map, I will have to test (once I am free of bug fixing and maintenance of previous code crimes).

On 6/2/2018 at 12:42 AM, aeonios said:

my ardenne forest remake

I really prefer new maps over deleting old maps and replacing them with ones that have an entirely different character. I would miss the old Alpine Valleys map generation and I don't know if the original author would agree to have his work replaced by something new. All of our maps are favored by players, even the most dumb mainland is played heavily. New maps that provide something unique that no other map provides is something that keeps 0AD interesting to people who played all 65+ random maps already up and down. Also we should have maps that are specific to one scenario, historically and geographically accurate site , rather than remaining generic and featureless (like Continent for instance).

2 hours ago, Pyrophorus said:

I remember someone writing somewhere tile classes and constraints were very inefficient in  rmgen. Was it you or not ? I wonder...

That's not a secret that some constraints are very slow. Mostly the avoidClasses and stayClasses ones when passing larger numbers, the area to test increases by the square of the radius. It's one of the reasons why the StaticConstraint cache thing was implemented. There will surely be better ways to refactor that class.

Anyway, I didn't say anything actually specific to the code which is likely what you were looking for... I think it should be possible to add new stuff to the library, it should just be like Lego bricks. One should be able to opt-in easily and combine with all the other bricks. So if we need to cache vector slopes or whatever, it could be stored in a new prototype that could be instantiated optionally and passed around to the things that need it. But I will have to take a close look once I can get to it (Stuck with stupid bugs since months). I wish the best luck to the map development until then.

[Stan`]

Maybe @FeXoR could have a look too. I hope he is still around.

[aeonios]

1 hour ago, elexis said:

A23 has SlopeConstraint and HeightConstraint

Yes I noticed that when I was digging around in constraints. I also incorporated it into the constructor function.

1 hour ago, elexis said:

I'm personally happy to take up new random map code into the map base, as long as we don't have too different ways to create maps. First time readers are mostly familiar with Spahbods mapping style, but FeXoRs maps (Caledonian Meadows, Deep Forest iirc) used entirely different code for mapgen, same as wraitiis maps (Belgian Uplands, Pyrennean Siera, for instance) or _kalis maps (rmgen2/, Ambush, Red Sea). To some degree it has been reinvention of the wheel three times, so I'm just cautious to add more redundancy.

Diversity of approach in the random map scripts is good, but in the library only where it is really needed. In Alpha 23 a lot of things were made more conform and the Placer/Painter/Constraint interfaces were used where possible (some of the new Painters and Placers were converted from global heightmap library functions or abstracted from code of individual maps). Since these are interfaces, It allows people to understand what a new prototype does even before they read its contents.

This.

1 hour ago, elexis said:

I really prefer new maps over deleting old maps and replacing them with ones that have an entirely different character. I would miss the old Alpine Valleys map generation and I don't know if the original author would agree to have his work replaced by something new. All of our maps are favored by players, even the most dumb mainland is played heavily. New maps that provide something unique that no other map provides is something that keeps 0AD interesting to people who played all 65+ random maps already up and down.

I dunno. A lot of the maps aren't exactly popular and some basically never get played at all. Ardenne forest does get played occasionally but I've never seen anyone play alpine valley. The disadvantage of having too many map scripts that nobody plays is that nobody will be willing to use random map selection since they don't want to roll a bad map. One of my biggest goals in improving random maps is to get rid of the bad ones so that it's no longer an issue. For ardenne at least I think it'd be fair to let the users decide if they still want to play the old one after seeing the new one. For the time being I could change the name to Ardenne Mountains or something.

1 hour ago, elexis said:

Also we should have maps that are specific to one scenario, historically and geographically accurate site , rather than remaining generic and featureless (like Continent for instance).

That's neither here nor there. It's only the generic maps that actually use the default biomes from rmbiome. Maps representing specific regions can't really do that. Also a lot of the newer maps representing specific regions aren't particularly random and often aren't even very playable, even if they do look pretty good. I think that's something that should be avoided rather than encouraged. I'm all for adding region-specific scripts though. I've considered trying to make a greek acropolis type script, maybe one for bactria and probably a better indian jungle type map.