Random Map Script: Belgian Uplands

[FeXoR]

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

Yes, and they are all entities so using them lowers the number of possible entities with a gameplay impact (or big maps will wind up with an out of memory error). However, using them infrequently would be OK. I'll give it a try.

[feneur]

Yes, and they are all entities so using them lowers the number of possible entities with a gameplay impact (or big maps will wind up with an out of memory error). However, using them infrequently would be OK. I'll give it a try.

Hmm, any actors (i.e. non-gameplay impacting entities) shouldn't be as much of an issue as entities. I would say that e.g. stones which doesn't have alphamaps could be used a lot more frequently though. Big maps will have to be worked more on anyway, so don't let that concern stop you from making the maps look good. And as far as I can tell the OOM issues are when generating the maps rather than playing on them? Speaking of that, would it help to have objects which consists of several smaller objects? If the issue is that there are too many objects for the game to go through in the RM generation phase that should help I would guess. Michael had some ideas for what I believe he called POGs (I think it was short for predefined object groupings or something similar) which would essentially be small "scenes" that a scenario designer/RMS scripter could include in his maps. That should work even for less ambitious things like a bunch of stones and grass objects.

Hmm, did a quick look among old mockups and found the attached image, seems like POG is short for premade object groupings =) At least I wasn't too far off

[FeXoR]

Hmm, any actors (i.e. non-gameplay impacting entities) shouldn't be as much of an issue as entities. I would say that e.g. stones which doesn't have alphamaps could be used a lot more frequently though. Big maps will have to be worked more on anyway, so don't let that concern stop you from making the maps look good. And as far as I can tell the OOM issues are when generating the maps rather than playing on them? Speaking of that, would it help to have objects which consists of several smaller objects? If the issue is that there are too many objects for the game to go through in the RM generation phase that should help I would guess. Michael had some ideas for what I believe he called POGs (I think it was short for predefined object groupings or something similar) which would essentially be small "scenes" that a scenario designer/RMS scripter could include in his maps. That should work even for less ambitious things like a bunch of stones and grass objects.

Hmm, did a quick look among old mockups and found the attached image, seems like POG is short for premade object groupings =) At least I wasn't too far off

The OOM error occurs when exporting the map due to the iteration over the objects. Javascript (or the interpreter, spidermonkey?) can't handle loops bigger than 1,000,000 (not sure about the exact value). There's not much I can do about it.

EDIT: Correction: The OOM error occurs only on giant maps AFTER the map is exported and saved so while the engine loads the map I guess. This only happens when the number of "Entities" (shown in the mainlog after "Saving map...") is bigger then 10,000 (not sure about the exact value again). That means on giant maps (512*512 = 262144 Tiles) only one entity every 26 tiles...

Another Correction: It indeed seems that it's not the number shown in the mainlog but depend on something else. Deep Forest raised OOM errors with roughly 13,000 "Entities" while Belgian Upands generated fine with 27,690 "Entities" according to the main log. A giant Belgian Uplands map seed had 37,960 entities which is to much though.

ADDITION: A Giant map with half the prop density still raises an OOM error though it contained "only" 20,222 entities according to the mainlog. The number of interactive objects, however, was unchanged. So indeed there seams to be a difference but in the mainlog the number of objects are shown (not the number of "Entities" as it states). The exact error (only this one):

"ERROR: JavaScript error: simulation/components/ResourceSupply.js line 37 out of memory"

POGs would indeed be good. They lower the number of needed actors (and so the size of the loop during exporting the map) and make it less pain for a map designer to place them (less clicks in atlas/less needed actor types in RMS). Some of the actors seam to be such things already (like many in "campaign"). If it will become another type of objects RMGEN should handle them so entities/actors/POGs can be used with the same syntax (I can't figure out how to place terrain on a tile similar to placeTerrain() with an array of terrain string (and randomly chosen one per tile) that also support terrains with actors, not only templates/entities). Checking other maps for examples...

BTW: The naming is pretty unclear to me:

- While in Atlas choosing "Entities" (in opposite to "Actors (all)") only objects in simulation/templates are shown (is it an "Entity" or an "Template" then?). In RMGEN the Entity() class is a template type with a position on the map.with a certain orientation. However, it works for Actors as well (Things in art/actors) and Entity() instance can be placed with placeObject(). So is it an "Entity", a "Template", an "Actor" or an "Object"? I'd prefer the last at least for RMGEN.

- In Atlas "Actors (all)" additionally shows everything in art/actors but they are placed in random maps with placeObject() or (in Goups though the name "simple object" doesn't make that clear) SimpleObject().place .

However, createSimpleTerrain() supports strings made of a terrain type string, a separator (a pipe |) and an Entity path string like e.g. "temp_grass_mossy|gaia/flora_tree_oak". That, however, doesn't work for actors so here "Entities" and "Actors" are different in RMGEN while in general it seams they are put together as "Objects" with the only difference that the type string of an actor has to start with "actor|" and include the file extension like ".xml" (which is good IMO except the need of the file extension). The problem here is that a string is used while it wold be better to use an array IMO. "temp_grass_mossy|gaia/flora_tree_oak" works but "temp_grass_mossy|actor|props/flora/bush_medit_sm.xml" doesn't because it contains 2 pipes. It would work if createSimpleTerrain() would use an array with one entry being the terrain and the other the "Object" to place on the terrain. So the "Object" could be an entity e.g. "gaia/flora_tree_oak" or also could be an Actor e.g. "actor|props/flora/bush_medit_sm.xml".

If RMGEN had access to the engine (like trigger based RMS generation would provide) there would be no need to differentiate between Entities and Actors at all because it could search in both paths and only throw if the given path string is invalid for both (simulation/templates and art/actors).

Off topic: art/props/flora/grass_underbrush_mediterranean.xml does not "bend" to the terrains surface but looks like it should...

EDIT: Added many props to the map: http://trac.wildfire...com/ticket/1688

EDIT: Trying to reduce the number of props on "Very Large" (slightly) and "Giant" maps (scip most of them) to avoid OOM errors.

Edited October 3, 2012 by FeXoR

[FeXoR]

I successfully got rid of the OOM errors even on giant maps (at least for the about 10 seeds I tested) by reducing the prop density to 3/4 on very large maps and 1/4 on giant maps.

Here's a screen shot of a giant map:

...and a closer look:

Now checking how long each loop takes in average to add progress bar settings...

Edit: Done: http://trac.wildfire...ds2012-10-3.zip

Edited October 3, 2012 by FeXoR

[serveurix]

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 )

Maybe they could move backward in two cases :

- when there are too many obstacles (in combat, in ports, in narrows...) to turn back (but in that case the ship should turn back once it's far enough from the obstacles)

- when it's asked to use ramming (I don't know if such a stance already exists) several times in combat.

[Mythos_Ruler]

A few things... Any way we can get rid of the "black sky" thing happening to water when zoomed out "too far" in Atlas or the game? And also the black shroud of doom that overtakes the whole map when zooming extremely far out. One could say, "Just don't zoom out that far..." but we need to take whole-map screenshots and these issues are a hindrance.

[MishFTW]

There should be a limit to zooming out, and that limit should be determined by map size.

[FeXoR]

A few things... Any way we can get rid of the "black sky" thing happening to water when zoomed out "too far" in Atlas or the game? And also the black shroud of doom that overtakes the whole map when zooming extremely far out. One could say, "Just don't zoom out that far..." but we need to take whole-map screenshots and these issues are a hindrance.

I agree. "Just don't zoom out that far..." is not a good argument in general - the player should be allowed to decide how far he zooms out.

There should be a limit to zooming out, and that limit should be determined by map size.

Why should zoom out be limited? I agree that zooming out that far that tiny maps are only 1 pixel and might be missed by the observer is stupid but that's pretty far. Indeed I never did that and it would take ages to do that if it works.

By the way: A new version of Belgian Uplands is available at http://trac.wildfiregames.com/attachment/ticket/1688/belgian_uplands2012-10-5b.zip

Edited October 5, 2012 by FeXoR

[Mythos_Ruler]

There should be a limit to zooming out, and that limit should be determined by map size.

I'm only talking about in Atlas. In-game, in normal play, I agree that zoom limits are preferable. But in Atlas, the zoom should be uncapped, for screenshot purposes or general overview for the designer. And right now, if you zoom out too far you get the black sky artifacts in the water, and then eventually the whole map is occluded by the sky box.

[MishFTW]

I was only referring to zooming in game.

[FeXoR]

Any further suggestions?

Otherwise I think this map is quite playable now. No out of memory errors, no problems with many players on small maps, decent looking "empty" (no interactive entities) mid level ground (grass), very natural and random design in general compared to other random maps, no problems with the AIs as far as I tested.

So if there are no others ideas at this point I think it can be added to SVN.

Ticket: http://trac.wildfire...com/ticket/1688

Edited October 17, 2012 by FeXoR

[Pureon]

Any further suggestions?

I loaded up a 4 player game (large map size) and saw it didn't have many trees:

Is this the way it's meant to be? Could be a challenging game

Also how much work would it be to slightly flatten the area near the starting locations?

[quantumstate]

I loaded up a 4 player game (large map size) and saw it didn't have many trees:

Is this the way it's meant to be? Could be a challenging game

We should probably start sorting maps into categories. There should be a core set of fairly standard resource density maps and then if people want to create unusual maps like this they can be put separately into something like a 'challenge maps' category. The game balance will be strongly affected and the AI will probably have significant problems, so it would be better for new players not to get a bad experience.

[FeXoR]

I loaded up a 4 player game (large map size) and saw it didn't have many trees:

[...]

Is this the way it's meant to be? Could be a challenging game

Also how much work would it be to slightly flatten the area near the starting locations?

Well, I could add further trees/group of trees on the mid level terrain (Grass without interactive entities but the starting entities) at the end of map generation.

Since it was requested before I'm.willing to add those.

For terrain flattening: The problem is that the players are placed on mid level ground (Grass) and close to both, low ground (Bog with Stone/Metal) and high ground (Woods with trees/berry bushes/deer) to have access to at least some of each resource type. That means the start locations are placed on the side of a hill with a high rate of incline. Flattening it beneath the Civil Centre will lead to a higher rate of incline towards low/high ground. So that's not suitable IMO.

We should probably start sorting maps into categories. There should be a core set of fairly standard resource density maps and then if people want to create unusual maps like this they can be put separately into something like a 'challenge maps' category. The game balance will be strongly affected and the AI will probably have significant problems, so it would be better for new players not to get a bad experience.

I somehow agree but I think the map description pretty much makes clear that this map is not a "standard" map.

Any suggestions how to make the description more meaningful very welcome!

Edited January 7, 2013 by FeXoR

[Pureon]

Well, I could add further trees/group of trees on the mid level terrain (Grass without interactive entities but the starting entities) at the end of map generation.

Since it was requested before I'm.willing to add those.

It's completely up to you I'm not sure how the map handles when there are fewer players, I think I've previously rushed the AI on this map so didn't need more wood resource.