Random Map Script: Belgian Uplands

[Mythos_Ruler]

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.

Terrain flattening works just fine in AOE3 or AOM.

[FeXoR]

I don't think anything but completely flat will work, because some buildings (like the Greek civil center) have floors (or tiles in the case of the Greek civil center) that wouldn't look good if the ground underneath isn't completely flat.

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.

Terrain flattening works just fine in AOE3 or AOM.

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

Edited November 1, 2012 by FeXoR

[feneur]

I think the thing is that terrain flattening should be smooth and affect the area around it and not just below the building. I think there are three parts to good building placement: restrictions (if the ground is too uneven it won't work well even if the ground is flattened underneath the building - the difference to the surrounding area would be too large and cause "pits" etc where the building is), foundations for the buildings to make them possible to place even on slightly uneven terrain, and smooth terrain flattening to make it work on slightly uneven terrain

[Zaggy1024]

I think the thing is that terrain flattening should be smooth and affect the area around it and not just below the building. I think there are three parts to good building placement: restrictions (if the ground is too uneven it won't work well even if the ground is flattened underneath the building - the difference to the surrounding area would be too large and cause "pits" etc where the building is), foundations for the buildings to make them possible to place even on slightly uneven terrain, and smooth terrain flattening to make it work on slightly uneven terrain

Some buildings have foundations that would work fine with ground that isn't flattened completely (except some of the props like barrels which are supposed to sit on the ground), but since there are also buildings that wouldn't work well with bumpy terrain, there would have to be something (in the buildings' templates, maybe) to tell the engine which buildings need flat terrain.

[FeXoR]

I think the thing is that terrain flattening should be smooth and affect the area around it and not just below the building. I think there are three parts to good building placement: restrictions (if the ground is too uneven it won't work well even if the ground is flattened underneath the building - the difference to the surrounding area would be too large and cause "pits" etc where the building is), foundations for the buildings to make them possible to place even on slightly uneven terrain, and smooth terrain flattening to make it work on slightly uneven terrain

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.

Some buildings have foundations that would work fine with ground that isn't flattened completely (except some of the props like barrels which are supposed to sit on the ground), but since there are also buildings that wouldn't work well with bumpy terrain, there would have to be something (in the buildings' templates, maybe) to tell the engine which buildings need flat terrain.

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.

Edited September 20, 2012 by FeXoR

[zoot]

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.

How would you use triggers in RMS? (Not saying that you shouldn't, just trying to find out what exactly people understand by 'triggers'.)

[FeXoR]

How would you use triggers in RMS? (Not saying that you shouldn't, just trying to find out what exactly people understand by 'triggers'.)

"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.

Edited September 20, 2012 by FeXoR

[zoot]

But that way not only RMGEN can use them, but e.g. the AIs too (to build walls for example).

What is the advantage of AIs having access to the RMGEN stuff? Isn't RMGEN filled with functions for terrain manipulation and other stuff that no player (whether human or AI) should have access to? Can't the AIs build walls with the usual AI API?

Edited September 20, 2012 by zoot

[FeXoR]

What is the advantage of AIs having access to the RMGEN stuff?

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).

Isn't RMGEN filled with functions for terrain manipulation and other stuff that no player (whether human or AI) should have access to?

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.

Can't the AIs build walls with the usual AI API?

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).

Edited September 20, 2012 by FeXoR

[MishFTW]

Awesome update Fexor

On the other hand glas to see a bit of a debate going on

BTW I created ticket 1634 specifically for that issue.

[zoot]

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.

It's usually not considered good practice to arbitrarily allow one part of a program to modify other parts of the program, hence scopes.

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).

Why not just break the common stuff out into include files?

[FeXoR]

Awesome update Fexor

On the other hand glas to see a bit of a debate going on

BTW I created ticket 1634 specifically for that issue.

Thx. I'll follow the tickets and am thinking about how to implement it for RMGEN.

It's usually not considered good practice to arbitrarily allow one part of a program to modify other parts of the program, hence scopes.

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.

Why not just break the common stuff out into include files?

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.

Edited September 21, 2012 by FeXoR

[zoot]

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 later obsolete code OR a much less spectacular/modifiable/usable end product.

Can you give a "better" example of how triggers would be beneficial in the implementation of RMS? "Event: new game started, Condition: true (no condition), action: [all the random map code]" doesn't seem too mindblowing?

I actually would like to see triggers in part 1 too, but mainly because it enables single-player missions - not for programmatic reasons.

[feneur]

I cannot say much about the specific programmatic reasons for why to do things one way or another, but I do think that regardless of whether or not the bulk of the engine will need to be rewritten in part 2 for triggers it will probably need to be rewritten more or less completely anyway to make it possible to make use of more than one CPU. Which kind of invalidates the "but you will have to rewrite everything" argument as the rewrite will be needed anyway, and that might actually be another reason to postpone the addition of triggers, better to add both things that require a rewrite at the same time as there's the need for two rewrites otherwise. There might still be other reasons that would make it worth adding triggers at this point, but I think that unless we decide to do something as major as that (at least if it's as major as you describe it with more or less a complete rewrite of parts of the engine) we're getting really close to the finished game. Not as in "we could release part one within a couple of months", but as in " we should decide now if we want to have a release out within one or two years or within four to five years". Each individual piece we add might not increase the development time immensely, but I think it's time to start evaluating things more strictly to see if they're worth increasing development time for. Otherwise we'll keep working forever on the "perfect game" and never reach it, it's better to be able to release a good game soon and then keep improving on it in subsequent releases.

[zoot]

(Perhaps the last few posts should be migrated to a separate topic?) I'm actually curious why triggers are considered a 'major' addition insofar that a trigger is just "something that calls something else on some condition". At first blush, that seems pretty straightforward compared to some other recent additions, like click-drag walls and the new sound manager. So what is the catch?

[FeXoR]

Can you give a "better" example of how triggers would be beneficial in the implementation of RMS? "Event: new game started, Condition: true (no condition), action: [all the random map code]" doesn't seem too mindblowing?

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).

I actually would like to see triggers in part 1 too, but mainly because it enables single-player missions - not for programmatic reasons.

Thats another thing. It would enhance gameplay.

I cannot say much about the specific programmatic reasons for why to do things one way or another, but I do think that regardless of whether or not the bulk of the engine will need to be rewritten in part 2 for triggers it will probably need to be rewritten more or less completely anyway to make it possible to make use of more than one CPU. Which kind of invalidates the "but you will have to rewrite everything" argument as the rewrite will be needed anyway, and that might actually be another reason to postpone the addition of triggers, better to add both things that require a rewrite at the same time as there's the need for two rewrites otherwise.

There might still be other reasons that would make it worth adding triggers at this point, but I think that unless we decide to do something as major as that (at least if it's as major as you describe it with more or less a complete rewrite of parts of the engine) we're getting really close to the finished game.

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!

Not as in "we could release part one within a couple of months", but as in " we should decide now if we want to have a release out within one or two years or within four to five years". Each individual piece we add might not increase the development time immensely, but I think it's time to start evaluating things more strictly to see if they're worth increasing development time for. Otherwise we'll keep working forever on the "perfect game" and never reach it, it's better to be able to release a good game soon and then keep improving on it in subsequent releases.

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.

(Perhaps the last few posts should be migrated to a separate topic?) I'm actually curious why triggers are considered a 'major' addition insofar that a trigger is just "something that calls something else on some condition". At first blush, that seems pretty straightforward compared to some other recent additions, like click-drag walls and the new sound manager. So what is the catch?

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.

Edited September 21, 2012 by FeXoR

[zoot]

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 am pretty sure the AI and RMS stuff was split into different APIs because it was deemed to be the best design - not because it was too hard to combine them into a "one API to rule them all" sort of thing. I would be interested to see any evidence to the contrary, though.

Edited September 21, 2012 by zoot

[feneur]

I'll try to shut up for a few (hopefully many) month about this.

Well, if we take what both you and I have been saying into account you should probably either speak up louder now or wait a couple of years

I'm not really against adding triggers now per se, but to me it seems better to add them when they are the most useful (together with the more story-based parts of gameplay) and together with the other things story-based campaigns brings with them they would take a long time to implement. And not to think of creating the actual content. To me it seems better to add it all at the same time

[MishFTW]

I'll try to shut up for a few (hopefully many) month about this.

Never do that. I still haven't given up on a new GUI engine (but then again haven't made significant progress anyway)

[FeXoR]

I am pretty sure the AI and RMS stuff was split into different APIs because it was deemed to be the best design - not because it was too hard to combine them into a "one API to rule them all" sort of thing.

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 would be interested to see any evidence to the contrary, though.

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.

Well, if we take what both you and I have been saying into account you should probably either speak up louder now or wait a couple of years

I'm not really against adding triggers now per se, but to me it seems better to add them when they are the most useful (together with the more story-based parts of gameplay) and together with the other things story-based campaigns brings with them they would take a long time to implement. And not to think of creating the actual content. To me it seems better to add it all at the same time

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!

Never do that. I still haven't given up on a new GUI engine (but then again haven't made significant progress anyway)

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...

Edited September 30, 2012 by FeXoR

[Mythos_Ruler]

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...

Siege engines could turn in place, they'd just be slow at doing it instead of snapping around 45 degrees (or whatever angle) instantly. Same for any other unit.

[FeXoR]

Siege engines could turn in place, they'd just be slow at doing it instead of snapping around 45 degrees (or whatever angle) instantly. Same for any other unit.

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

Edited October 1, 2012 by FeXoR

[feneur]

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.wildfire...com/ticket/1688

I think the "don't turn in place" restriction is mostly something we've hoped to have for the ships. Slowly turning would probably work fine in that case as well if it turns out to complicate things too much to do them otherwise. I would think that at least rowed ships could even move backwards though, but I'm not sure if that was practical with e.g. biremes/triremes/etc. (I doubt it would be possible to implement well since it might be hard for the pathfinder to know when the ship has to move backwards and when it can turn around etc )

[FeXoR]

I think the "don't turn in place" restriction is mostly something we've hoped to have for the ships. Slowly turning would probably work fine in that case as well if it turns out to complicate things too much to do them otherwise. I would think that at least rowed ships could even move backwards though, but I'm not sure if that was practical with e.g. biremes/triremes/etc. (I doubt it would be possible to implement well since it might be hard for the pathfinder to know when the ship has to move backwards and when it can turn around etc )

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?

Edited October 1, 2012 by FeXoR

[Mythos_Ruler]

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?

There are tons of grass and stone and plant objects in Atlas. Take a looksee.