FeXoR

Well, give it a try. As long as it works well and not to much hacks are needed to make it work. Would look more natural for sure. I feel the empty space on grassy terrain is to big on some seeds. Any good idea what to place there? Some eye candies perhaps? Does razed buildings give resources? If so perhaps some buildings for Gaia?

Ah, that is good! Did get that wrong then (Thought they'd need to "drive" to turn). Added a ticket to add this map: http://trac.wildfiregames.com/ticket/1688

Yes, that's a bad thing. An citizen soldier, even if a bit weaker than others, can still be useful to gather stone/metal because it might costs the resources easiest to get on a specific map. For elite units this argument won't work of cause. In general I agree with you.

AFAIK RMGEN was split from load/save map (simulations?) because it was to complicated already. AFAIK AIs where split to make a later change to thread them will be easier. I don't know where I got this information. I searched the forum for about an hour but couldn't find it. I'm pretty sure someone (Philip/feneur/bruno?) I consider trustworthy (Not that I distrust anyone here but some just have more information of cause ^^) said that somewhere. Would be nice if anyone would remember but IMO that's not really a point. If we see fit we still could change it. I ATM agree with feneur to leave it as is to make the game "final" faster. True. Though I'm quite sure I would want triggers to be more widely usable (not necessarily used) than you would consider OK. I remember the "security issue" you talked about: http://www.wildfireg...24 Guess you would consider triggers able to change "everything" be such a security issue. But IMO the "Trigger level" connecting the Javascript part with the engine closer can handle this quite well. EDIT: Wild guesses only! I don't gave up ^^. I'm extremely sure powerful triggers make things better to modify and are essential for a vital community after the game is considered finished. I just agree that having a feature complete game - considering the gameplay - is vital, too, for an open source game. I'm pretty determined to talk loud to make triggers as powerful as possible - when they are added. We just seam to have to wait a few more years ^^ (until 0A.D. 1.0). Since sometimes I can't shut my mouth (keep my fingers away from the keyboard) it might happen that it comes up again before triggers are added, though x). That's my fault and I try to keep myself from doing it to often because it's not helpful, sry. I have not much time ATM so I haven't finished a cleaned version of the map, yet. Guess it will take a few more weeks. Further suggestions very welcome tough. Off topic: I found a very good reason to avoid "turning" of units like planned (already implemented?) for siege weapons: If units can't turn on a point they can wind up in gaps not getting out again...

The balancing reason is not entirely true. You could just balance the "needed" units (to have all roles filled) and make the others a bit less powerful. That way things will be balanced and still a great variety of units will be available. Only one strong unit can break the balance, not a variety of weak ones as long as for each role about equally strong units are available for each faction. That (one overpowered unit) might be a problem with e.g. war elephants and Iberian ranged elite cavalry. They can only fill the role (siege like) when dealing enough damage to structures but will then be overpowered against units if units have no high armor against crush damage (as it is now). Similar thing with other siege weapons. Guess buildings should have less crush armor while units should get more crush armor (compared to as it is now).

I have not much time right now but I think about writing this map in trigger function (without writing the functions explicitly) just to show how it would look like (or how I think it should). Thats another thing. It would enhance gameplay. That's only true in part. To add trigger events to the engine those functions has only be added e.g. the damage calculation is done anyway. It just doesn't send the event to the triggers. But if the engine has to be rewritten to make parts of it threadable it would have to be rewritten on a larger scale. However. The code to be rewritten will be the code to write for triggers (that's fixed and mainly of an unknown amount) and the part we have to implement before they are added. The amount of the second depends on when they are added and how complete the game was before. So first finishing the game means RMGEN/AIs working quite well. So: The code will be more then if triggers where implemented earlier and everything was trigger based. And at first glance the need to change them to be trigger based vanishes. That hurts me! I fear you are right with this. It's important to have something finisched at some point and while implementing triggers might "only" take about 1 year making everything trigger based might take about the same amount of time or longer. I couldn't hold it (again) x) For one part I still fear that implementing triggers as widely as I think would make the difference between "another modifiable" and a "awesome easy to do mindblowing stuff with" game when not starting ASAP since RMS and AIs seam that well working that nothing seams to be gained by using triggers for them so they will only be used for story driven maps (And no triggers that for terrain manipulation or handling a player (AI) will be added). That's nothing really new. Some might argue similarly as you did: "Why should some part of the game have access to stuff they don't need?". Yes, in the common case it might seam to just be overhead. But in the end (when more and more users wright maps/scenarios/mods for it) the gain will be enormous. Especially if the changes are easy to do and all concepts can be implemented using only one part (Triggers/simulation). But that's to hard to do even for team members ATM so an AI-API and an RMGEN part was added. I fear feneur is right about the amount of time needed to do this. I'll try to shut up for a few (hopefully many) month about this.

Thx. I'll follow the tickets and am thinking about how to implement it for RMGEN. True. So it might be a good idea to use fixed prefixes for the general function in triggers and the more specific functions for RMS/AI e.g. te_blaBlub could be used for trigger events, tc_blaBlub for trigger conditions, ta_blaBlub for trigger actions, ai_blaBlub for more specific AI functions and rm_blaBlub for more specific functions for random map generation. I don't want to make the engine accessible directly BTW. The engine just calls the event checks when they happen and give more specific information about the event by setting the variables like "damagedUnit" to a copy of that unit and the trigger actions pass the changes to be done to the engine when they are valid. I don't think that will work properly because stuff is made explicitly for that one part of the program e.g. in the RMGEN functions a "closed" wall can be build (which would be useful for the AI) but the placement is instantly (not the construction foundation is placed but the finished wall). Additionally rmgen uses an abstract "map" without the engine running. It is not designed to work during engine runtime and so will not work for AIs. The other way around: AIs have functionality for terrain analysis. This would help to restrict entity placement in RMGEN, too, but doesn't work with RMGENs abstract g_map. As the functions are now makes perfectly sense when not considering fusing those parts (which is quite hard anyway without triggers) and so we'll write more and more code to carve in stone that RMGEN/AI will never get trigger based and disable the vast possibilities arising with it. So adding triggers ASAP will lead to more usable, less redundant and extremely variable code while not doing it leading to vast amounts of duplicated later obsolete code OR (if not fusing AI/RMGEN/simulations trigger based) a much less spectacular/modifiable/usable end product.

It is not the advantage of AIs having RMGEN stuff but the advantage is there is no RMGEN stuff and AI stuff any more. There are just general functions to manipulate "everything" (with triggers, that take care of things are done same and pass it to the engine if needed/valid). So terrain can be manipulated in the "first turn" to generate random maps and everything has access to all information (so it would be much simpler to avoid many problems in RMGEN we have to fight with e.g. no access to entity templates). In general the advantages are far beyond anything that can be predicted. The vast amount of possibilities arising by it is just mind blowing. AIs would extremely profit from it as well, since they, too, would have all information and so can more sensible take actions. Another example that would help both - RMGEN and AI - is a terrain analysis for areas passable/reachable/buildable. There are many more but I already talked about that until I got blue in my face: http://www.wildfireg...showtopic=16096 A thread about this... http://trac.wildfire...1449#comment:20 Scip untill "The perfect world:"... And we need it anyway to build a story based campaign (yes I know it is planned for part II). In the first place: Why shouldn't they??? Or more calm: Information about if a part of the maps can be passed/build upon/reached is needed for both. Yes... if you like implementing redundant stuff over and over again for every part of the game not connected. (ATM there's an in-game method and a tool for RMGEN only AFAIK).

"Triggers" are functions that can manipulate something during runtime of the engine. A trigger usually is made of: - An event: when it is triggered. Example: aUnitTookDamage (while that event is triggered once for every damage calculation and with it sets some "global variables" like e.g. "damagedUnit" (and/or "triggeringUnit"), "damagingUnit", "dealedDamage" and "lostHealth" in this case) - Conditions: in which case the actions should be called to minimize overhead. Example: damagedUnit.type == "athen_infantry_spearman" damagedUnit.level >= 2 damagedUnit.health < damagingUnit.health - Actions: Mainly code that calls several functions that does something with the engine. Example: playSound("allert_01", positionOf(damagedUnit)) pingMinimap(positionOf(damagingUnit))) messageToPlayer("An advanced spearman is about to loose", ownerOf(damagedUnit)) If you implement all actions possible you can do everything with triggers. Because it's possible to use them during game time you can do awesome stuff. But for now a (very rough) concept of how to do a random map with it: Event: new game started, Condition: true (no condition), action: [all the random map code]. For that mainly all the functions in RMGEN libs has to be reimplemented as triggers. But that way not only RMGEN can use them, but e.g. the AIs too (to build walls for example). AIs ATM are "loosely" connected to the engine to ensure threading the AIs will indeed make sense. So many of the trigger actions should be thread save and can be used on the actual map the engine works with or on a threaded representation of it. That way AIs could have full access to all map data and still run on another CPU. ATM simulation is mainly the part that comes closest to triggers so this would be the place to start implementing triggers.

I totally agree. But ist the same old problem that makes it hard to realize in RMGEN: No access to the templates... Otherwise I'd done it already... Another thing: It will not work well on a "huge ramp". Whatever you do when flattening the ground under/around the building it will make the total ground on the ramp more uneven. This does not work for RMGEN... Just to go on your nerves again: I'd really like to make everything (especially simulations, RMGEN and AI) trigger based and generate RMS while the engine runs. Don't wait until part II. It will really be more work in the end NOT to add trigger due to tons of duplicated code. Not to mention all the time spend to think about workarounds for things not well doable without full access.

Oh, true. BTW I like the tiling style of the Greek Civil Centre. I still think buildings in general should reach a bit further into the ground. I'm quite sure it can work well and agree that it would improve things, yes. Late EDIT: I changed my mind : http://trac.wildfiregames.com/ticket/21#comment:10

I could do this and place the terrain after the players and restrict placement of other entities in the areas around the players but:this is mainly a test of concept map for heightmaps generated by erosion to look more natural. To derivate players like I do now feels more natural to me as well. Additionally there's no way to tell if the predefined start locations will be placed where water shows up on the random terrain (Or after everything is build and a player is detected in water the heightmap would have to be rebuild... even more time consuming OR the heightmap would have to be changed "artificially" afterwards to ensure the players are placed valid which somehow defeats the purpose of this map). Most other maps (or all) are done like you suggest but I think variety in the random maps is a good thing, not only in design but also in the general approach. In some rare cases it can indeed happen that there are not even 8 valid start locations but only on a tiny map. I'm pretty sure that no one would like to play with 8 players on a tiny map and many other RMS will wind up in chaos as well with this settings EDIT: The players start locations are chosen "randomly" because lets say there are 100 valid tiles found to place the start positions and there are 8 players present leading to a number of 100^8 = 10^16 = 10000000000000000 possible player derivations. Looping over them will result in an out of memory error. So I randomly pick 10000 possible derivations and finaly take the one with the maximum player distance (more precise the derivation with the maximum distance between the 2 players closest to each other). That would help, yes. Keep in mind though that flattening the terrain in one area will make it more step on the edges of that area so it might be good not to flatten it totally but only make it more flat. The changes to the terrain will be seen after the building is destroyed as well and might look a bit strange but it's quite realistic that terrain build by mankind looks a bit "unnatural". another question is: Will it be applied to buildings placed in random maps at all? I guess it will have to be implemented for RMGEN separately...

Here's another version. Changes: - Players will not be placed in the corners (only inside a circle fitting into the rectangular map) - Players will now be close to "bog" (low ground) and "woods" (high ground) so they will more likely have access to all resource types (due to the very random nature of this map an equal amount can still not be ensured). - Again added more bushes to the "bog". - Reduced the number of deer entities. - Very Large and Giant maps does not seam to raise an out of memory error any more (not sure why, guess the extreme reduction of possible start positions is the reason). The map takes longer to generate now because of the "ensure players are close to low and high ground" check. In some cases the added start location restrictions result in less "equal" start location derivations over the map. I still think it's an improvement. Here's a screen shot that shows that: Since no high ground is top left no player is placed there. So one player is more in the mid of the map so more likely to be attacked. That does not happen often with 3-5 players. With more then 5 players it's natural (when maximizing distance between players) and intended. And the map: belgian_uplands2012-9-18.zip If no further bugs/objections show up I will add a ticket soon to add this map after I cleaned up the code. Afterwards I will refocus on a general erosion lib for rmgen and mess around with the existing maps

This is really cool

This happens because some wall parts are outside the map while the territory border can't expand over the map border. I could add restrictions not to place wall entities outside the map. The better way to deal with that would IMO be a check in each random map for the size of the map and dependent on that and how close the player start locations can be to the border the map designer should disable Iberian walls (e.g. by placing them with "placeCivDefaultEntities(x, y, playerID, BUILDING_ANGlE, {'iberWall' : false});"). I just can't know well what the map designer wants/ how much space each map grants. I could change the default to: Map size = tiny -> no Iberian walls, map size = small -> Iberians get towers only, map size medium or greater -> Iberians get full walls. Feedback welcome...

Ah, yes, I remember. In random maps the coordinate for the hight cannot be set so I don't think they can be used easily. The waterfall in addition needs the terrain to be shaped as the fall to look well, so it's even harder to use. Here's a new version, changes: - Added a darker more fitting terrain between the light grass and the water surroundings like Wraitii suggested. - Added bushes to the water surroundings so players without high ground near (forests) will still have access to wood though less. - Added berry bushes and cypresses as start resources next to the players (not sure if I should have used grapes/apple trees/other (wood) trees instead/additionally). Players now all have access to wood but not equally high. It should by far be enough to reach town state. After that players with less access to wood will have more stone/metal so it will be about balanced I think. A bit off topic: - Some buildings (like e.g. civil centres) in part "fly" above the earth when placed on uneven ground. I thought/think they should have they foundation reach wide below their placement height coordinate. - I noticed that not all civilizations have infantry units that cost food and metal (only). I feel that should be the case (foot fir the living and metal for the arms). The RMS: belgian_uplands2012-9-16.zip ...and a screen-shot:

Indeed ^^. Though I will follow wraitii's advice to add a terrain between the lakes surroundings (plants and bog mainly) and the light grass to make it more smooth.

Just want to say that still not all attributes are shown - neither on the build/produce button nor in the entities tooltips: - Range - Attack rate or time - Number of attacks (like ships, (siege)towers, fortresses and Cevil centres) - Maximum garrison space (only missing for build buttons AFAIK) Additionally I would really like a description of what "armor" is. It's not at all clear. At least something like: "For each attack type the armor is subtracted from successful attacks but at least 1 damage is dealt ?per type?".

I fear that would mainly raise the number of polygons... if at all possible. I read somewhere (http://www.golem.de/...1209-94503.html) that polygones are not needed any more, though, so it might be possible but I'm not the one to answer this question. I should have explained a bit further x) E.g. that I start with a random heightmap and rescale it at the end because in the process the heightmap gets extreme flat of cause. More explained here: http://www.wildfireg...=40#entry250216 Erosion, as I mean it here, is a change to the heightmap calculated by a function that simulates a real erosion process. The one I use here could be called "decay erosion" because it just depends on the height difference between all pairs of fields connected to each other and a portion of the difference is added to the height of the lower field and removed from the higher field - like material falling downhill. More mathematic: newHeight = oldHeight + erosionStrength * laplaceOperator(oldHeightMap, actualCoordinates)². The square in this case only means that not only appending fields in X and Y direction are compared to each field but the diagonal shifted fields are as well (German Wikipedia: http://de.wikipedia....ildverarbeitung ...can't find this in the English version). I use a map of x/y shifts to determine the fields compared to a given field: [[1, 0], [1, 1], [0, 1], [-1, 1], [-1, 0], [-1, -1], [0, -1], [1, -1]]. This enables me to do directed erosion, too, like sun would do (or wind when further checking if the change is down or uphill). But all those are to simple for lets say water gathering in streams and forming rivers. The Laplace operator is in general just div( grad( scalarField ) ) and the grad( scalarField ) gets you the direction and speed water would flow at each point of the scalar field (the height map) - generating a vector field (the water floating field). There you have to apply non-linear scaling before processing the div(). For that I wrote a javascript lib for discrete n-dimensional vector analysis inside a finite n-hypercube (with the "beginning" and "end" of each dimension wrapped together to ensure the same size of scalar and vector fields): http://www.wildfireg...=40#entry250606 . The problem is... it is MUCH to slow - I wish someone could help me with that though I fear it will always be slow with the needed self-recursive functions. So I'll implement 2D and 3D versions. I think in general that would be the main types of erosion to define: General decay, directed decay by the sun (so only at one side), additive/removing only directed erosion to simulate wind and the non linear streaming water erosion. I don't have taken into account the texture at all. That would make things more realistic by having different materials that resist more or less to different types of erosion. So in short: Erosion for me are changes to the heightmap and the terrain applied in a similar way like natural erosion would do. Of cause you could generalize "heightmap" to "surface" and "terrain" to "material" so it could be applied to entities as well. Those functions will be easy to use (ATM I use getBla() functions and set the heightmap to it later): - applyDecayErosion(strength) ...with strength between 0 and 1 determining how extreme each apply changes the heightmap - applySunErosion(strength, northVector) ...with north vector defining the direction the sun is coming from and it's length the average angle towards plain ground (the longer the lower over the horizon) - applyWindErrosion(strength, direction, type) ...with direction similar to the northVector (in this case where the wind is blowing towards) and type can be "additive", "subtractive" and "both" - applyWaterErosion(strength, nonLinearExponent) ...with the non linear exponent determining a scale factor strength is scaled with got by the normalized vector-fields vectors length with the exponent given by nonLinearExponent - rescaleHeightmap(minHeight, maxHeight) ...to "stretch" the heightmap after multiple erosions are applied. It's stretched in the height, ofc, not in the plain. An additional argument determining how often the erosion should be applied would help. Don't confuse this with strength! Strength can't be set to high values because the heightmap will wind up in self interference (with the frequency determined by the "compare field map" used) while the number of applies can be infinite (if you want to wait that long ^^) and blurs structures each time so the average size of structures will grow (and blur ofc.). To avoid the extreme blur after many erosion processes it might be a good idea to add a rescale function in X/Y direction as well. Additionally it might be a good idea to make erosion possible to only parts of the map... Me too! I like balanced as well but I hope that's not to contradicting. To smother blend two textures at the edges? At least I noticed that textures look quite unnatural in some cases showing the edges of the tiles.

I'm honored Indeed this map contains less code then most others ^^ Thx, I'll do my best! Yes, and there are still some unresolved problems... (see below) That would need non-linear scaling or it will become a water map ^^ I'm working on general functions to deal with such things. May I know why it's so important for you? Rocks/gold: I haven't play-tested yet. I will see to that. Transition terrain: Yep, it's quite a rough change. Easy to do. Different grass patches: There are two "grass types": low (a bit lighter) and high (a bit darker). Both contain at least 4 types of terrain. That seams enough to me. If you mean patches of other type on the same height: Not ATM. I try to keep things simple until the general functions are tested well. Not fair: Yes, that's a problem that may be not so easy to resolve. However, the map description warns you. This aproach is more to look natural then to be balanced. But I like balanced maps and I'm thinking about how to fix that but not at highest priority right now. Could someone please tell me what's so darn important about water depth? Or do you mean the general change of heightmap and SEA_LEVEL in rmgen??? Well... Here's a new version with the players placed valid. That in no way means something like "balanced". Indeed there are many problems left: (1) Very unequal derivation of resources across the map. Possible solutions: Adding a tilting function may change the hight derivation to be more equal across the map. In this map it would be the wood to be balanced. (2) Player start positions are not always close to wood. Possible solution would be to add a check if wood is inside a current distance of each start position. The amount, however, could still differ much. A simpler method would just be to add some "civilizes" wood with the starting entities (like some cypresses). Another solution would be to add more wood to the lakes surroundings. That leads to the next problem... (3) Stone and metal entities are bigger than a tile. If wood and stone is put in the same "random terrain" the wood might wind up unreachable inside the stone/metal entity. Possible solution: Don't place different resource types in the same random terrain... but that is a bad restriction IMO. (4) To ensure valid player starting positions much space is left on the map. Guess I have to do some finer decoration at the end. Here's the map: belgian_uplands2012-9-12.zip And a screen shot of a more balanced seed (9) of a medium map with 4 players: Keep burning!

A "playable" map (though not the random map itself) based on very simple erosion is just some steps away from being ready: http://www.wildfiregames.com/forum/index.php?showtopic=16535

This map is based on the simplest way to do erosion. It is more experimental but I thought it might be worth an announcement. The random map script itself is not playable, yet, but some seeds might be (e.g. 2110). EDIT: Short description of the heightmap generation: Set each tile to a random height -> apply decay erosion several times (about 50 + mapSize / 4) -> rescale the heightmaps height because the erosion process flattens it. Further explanations: http://www.wildfireg...=40#entry250216 http://www.wildfireg...35 Random map: belgian_uplands2012-9-10.zip Map of the "playable" seed 2110: belgian_uplands_seed2110.zip A sceenshot of seed 2110: EDIT: A new more playable version can be found later in this post (I might sometimes be to lazy to link to the newest version ): Ticket with the newest files attached: http://trac.wildfiregames.com/ticket/1688

I wrote a rmgen lib to support n-dimensional discrete vector analysis e.g. for simulating floating water erosion. I'm not quite sure that's the best way to do it and I am sure it's not the fastest/best readable code. I hope for someone more into programming/javascript to give me tips how to do better (but please without removing the generalized approach). Indeed it might be possible to do all this with vector algebra as well and for that fully documented javascript libs might be out there so if anyone has information about that, plz let me know. Here's the code (indentation missing due to erased tabs): ...and the ziped rmgen lib: discreteVectorAnalysis2012-9-10.zip And some test code: EDIT: One problem is that defining divergence and gradient would shift the field by 1/2 of the maximum cell diameter of the grid and reduce the size of the hypercube the field is defined in by 1. The size reduction can be avoided by "wrapping" the cube's side in each dimension e.g. wrapping the left to the right. The shift comes from taking the difference of the cell itself to an appending field in each dimensions direction. So the "point" where the calculation "takes place" is between the cells. The shift can be avoided by ignoring the field the operation is applied to and use the previous and next field instead. That however leads to two decoupled grids like black and white fields on a chess board. Using such a decoupled approach for erosion leads to two smooth fields stacked in each other and together are extremely rough (so nothing is gained). The decoupling could be avoided by also taking into account the diagonal differences (like the last example here: http://en.wikipedia.org/wiki/Discrete_Laplace_operator#Implementation_in_Image_Processing )

Thanks too Started a new approach to generate more realistic terrain reliefs: http://www.wildfiregames.com/forum/index.php?showtopic=16233&st=40#entry250216

Now that I got my 3D support back today I had to try something Here's the result of a first approach to generate a more realistic/random looking reliefmap/heightmap/terrain shape. It's only generated by a total scratchy random heightmap with a (very simple) erosion function flattening it several times (and sanely rescaling it at the end). The type of erosion is more like cracked rocky earth after an earthquake is decaying from sun erosion and a bit of random wind/quakes that make the material fall down. So it looks more like sandy ground without much wind and without water that gathers in streams. I'm going to add other erosion types later. In addition, to make cliffs possible, I think about filling in some geological activity like plates shifting or lava bubbles hovering ground. But here's what this very early state with only a few lines of code throw out: ...and the random map: fexor_hightmap.zip Of cause it is very hard to predict how such random terrains look like and it will take some effort to make it well playable but I think that will be possible. EDIT: More interesting structures can be got with directed erosion (similar to wind would do): The screenshot shows the map generated by fexor_hightmap2012-9-7.zip with seed 5201. EDIT: An additional screenshot of a relief map generated with only subtracting directed erosion with terrain painted by height.: ... the scale does not fit the unit/building sizes, yet. EDIT: A simple "playable" map done with erosion can be found here: http://www.wildfiregames.com/forum/index.php?showtopic=16535