FeXoR

IMO victory/defeat conditions should be simple to explain (in the match type description). And they should be clear for all players in all stages of the game. (In general mainly a loose condition is needed and a player wins if no opponent is left. There are some exceptions though e.g. wonders. Changeable/fixed teams may need some different behavior.) The actual (loose when number of units/buildings is zero, win if all opponents lost - for changeable teams it may be if all other players lost, not sure) is the clearest but has its flaws in lategame (the hide and seek annoyance), Mythos_Ruler's tech would fix this mainly (in some cases the dominant player might need to build e.g. a dock to reach a leftover ship though). (Adding a "scout" order that tells every selected units individually(!) to randomly (or better "go to the location with the highest lastTimeVisualBeforeXSecs / distanceToThisUnit ratio that can be reached by this unit and then continue") walk across the map - and if set to "aggressive" stance attack and chase any unit coming into visual range would help as well) This would be my favorite default victory/defeat condition (and default match type conquest). Another match type could be battle: - Players get a fixed starting force (without any buildings or builders - or units simply can't build). This can be chosen by the map designer or (if not) dependent on his civ defined in an XML file (and then placed at the first turn). - A player gets visual on all players that has less then 1/10th units compared to him left (this is only obvious during the game if a player table is in displaying the number of units for all players - and e.g. turn red if visual to any other player). There may be other game types but what I mainly wanted to say is: - Every game type might have different needs in victory/defeat conditions. - Game types should be independent of the map, so all functionality of all (default) match types (that work with "any" map) should be defined outside the map (though they may be tweaked inside the map (to some degree) like the starting forces). That means it would be most pleasant for the map designer to have a "start location" placeholder entity that gets replaced appropriate with the starting entities dependent on the match type at the start of the game (this may include Gaia entities like the "starting resources" for conquest). (This entity could also be the default camera position if not defined otherwise) For more variety victory/defeat conditions could be set inside the map by scripting (AFAIK already possible) but only work if no "default" match type is chosen (for simplicity it might be best to just set the match type fixed to special for such maps - and a descriptive text to (try to) explain the match type). Such maps could get an own map category e.g. "special" to make clear that thy have there own match type and/or victory/defeat condition definition as well as maybe non-default starting entities. I'm not thrilled by the thought of unclear victory/defeat conditions like "is dominant" or something similar (which matches my suggestion for the match type battle though a "leaderboard" might make that a bit more obvious). (Another - not that well thought through - game feature connected to this would be an "intelligence gathering" tech so e.g. the visual range of all buildings (and maybe units) are increased each time the upgrade is researched and it can be researched an infinite amount of times... for a price. Maybe this tech could be added to the market or the civic centre. If "line of sight" checks are/get implemented though this may be a really bad idea due to performance)

Mythos_Ruler: Sounds good. If things don't turn out as planned you can still use "damage vs. unit type" bonus (preferably in rare cases IMO). (In general speed/health/armor/damage per second should do though)

First of all plz. try to differentiate between historically based and game rule based "X is strong vs. Y". The game rules should reflect the historical based counters to some extend but the game is to be balanced in the end. So with no exact simulation in we might have to make some historically not well fitting rules. The more important thing is (as Thorfinn mentioned if I get him right) that units have to be balanced independently from formations, at least to some extend (and same goes for factions). So there are already many things to balance (units, formations and civs) and the base - the units - have more then 10 non-linear stacking variables (arguments in the over all strength function) to be considered for balancing: Live, movement speed, gather capacity, food/wood/metal/stone cost, population cost, attack speed, attack range, piercing/slash/crush damage, damage vs. bonus, piercing/slash/crush armor, units with damage vs. them, possible formations, max. number of units of this type (independent of pop cap like heroes), upgrades supporting this unit type, ... (for sure I miss something). This is already very, VERY hard to balance (if at all possible). So adding more things influencing the over all strength of units would very likely reduce the balancing - and so the over all quality - of the final game. And I didn't even consider formation bonus, stance behavior (and it's gameplay value dependent on the unit type), the micromanagement impact on a unit type nor the civilizations over all balancing (which might in fact be not as bad to balance if - and only if - the units themselves are balanced in the first place as Mythos sais). So before adding more and more features - that will likely never fuse into a consistent gameplay - plz. consider this.

It may be related to this : EDIT: It doesn't seam so though, see below Reducing the number of players set the (now unused) players civs to undefined. Raising it again does not change that (at least in Atlas). In random maps the players just gets fallback civ's entities but the civ string (used by the engine and so likely by gamesetup as well) does not change (it's still undefined). Maybe the AI has problems with that because (in opposite to human players) he used the civ string (not the entities he's given) to determine it's civ. (I mentioned that before and still think it's a bad behavior. The civ string should be set to a fallback/default case, not the starting entities) However, that was some time ago so I'm not sure it's still like that. EDIT: It doesn't seam to be related. It also happens if I just choose Sicilia (2) and start the game. (So it seams to be map related)

To reproduce (if not hardware dependent): - Update to SVN revision 15075 - Delete cache (also happens after another start of Atlas so may not be needed) - Open Atlas Rectangular Areas in the default (empty, grass) map turn just green (without any structure) for about half a second. Then they disappear and after about 1 to 2 seconds some other rectangular area turns structureless. This happens independent of any input (I can just lean back and watch the show ^^). Moving the mouse above the grass, however, makes the process much faster (More like flickering then). Screenshots: Opening the game and starting a map leads to more weirdness: ...and some warnings are logged: mainlog.html Informative files: system_info.txt default.cfg.txt (Renamed to .txt to be able to upload it) EDIT: Taking a big screenshot in atlas crashes (May be unrelated since reported by niektb_ as well (09:38): http://irclogs.wildfiregames.com/2014-04-30-QuakeNet-%230ad-dev.log): Error Message:: crashlog.txt crashlog.dmp EDIT2: Disabling Shadows fixes this partially (only terrain texture blended borders flicker). Disabling preferglsl fixes this. Big screenshot still crashes...

I can't confirm this. For me the menu item has the right size for all subitems to fit in the dropdown (At least in Firefox and Opera). My screen width is 1280 pixels and it also works properly if resizing the window (I just have to scroll horizontally as well to see everything). Maybe it's your screen resolution (and changing windows size does not act the same) or something different I can't tell at first glance.

The engine does not really support multiple water levels (though they can be set) AFAIK. At least it's not tested at all (and thought to be very buggy if used). Water (e.g. Waviness) can be set with the environment settings:http://trac.wildfiregames.com/wiki/Rmgen_Library#EnvironmentHelpers

I don't think it's the developers(?) @Zeta1127: That's what customers are for (from some PPS point of view, I guess ^^).

I agree that well made 2D units are better to separate. I also agree that the clean graphics allowing a good oversight in general is a good thing. However, I also like graphics supporting different ambients (which likely contradicts the top point).

A 3D outline shader should do like: http://i.imgur.com/WVE3f.jpg

It is easy to add to ramdom maps. Though settings are not yet supported. (If RMGEN lived in simulations it would be easy for all maps...) However, building lots of javelin infantry is not bad for economy so I don't see the need for a palisade. (I'm not playing a lot though so this might be better judged by a more active player)

Why would that be wanted? In the end that would mean that the creator of a topic could erase posts of other PPL (which is bad in the first palace IMO). Also there might be other PPL finding partial answer to their question in a topic while still have related questions so they may ask them in this topic though the creator of this topic might have all her/his questions answered.

Hephaestion: You are right. I use the "* 0.5" in the lines "vector_x" and "vector_y" because otherwise it would be twice the vector. What I mean is when I go through the grid I calculate "dx" and "next_dx". For x = 0, y = 0 next_dx is heightmap[1][1] - heightmap[0][1]. For x = 0, y = 1 dx would be heightmap[1][1] - heightmap[0][1]. So they are the same but I calculate them twice. For dx/next_dx I could just remember next_dx and use it for the next tile as dx (if it's not a new x line, which is the same as "if y != 0"). That way I'd replace the calculation "heightmap[1][1] - heightmap[0][1]" with "dx = next_dx" and the condition "if y != 0" (in most cases) which should be a bit faster. For dy/next_dy this will not work though (because dy will never have been calculated in the last tiles calculations). Originally I looped and only calculated the dx/dy, put them in an array to then use them to calculate the slope later. That way I did only calculate everything once but then I needed two loops which in the end was at least ugly (and likely slower). Further explanation to disenchant the magic: For terrain placement on realistic terrain demo I only do two different things dependent on the incline (on low and high incline) so I might as well get rid of the "normalization" to increase speed (the " * 0.5" and the " ^ 0.5"). Speed is not critical here though since it only runs once. For erosion and in general I need the normalized vector though so there's not much to optimize. And sadly here performance is vital because it will be used several times.

Thx, sanderd17! For the different water levels I'd need to know the structure of the water planes the engine should get from RMGEN.. Then I'd add it to the Map class in this (or a similar) structure (and maybe add a variable to enable different water levels which would be False by default to avoid breaking existing maps). Not sure which part of code takes the outcome of the RMS then... This would not help for erosion in any way though. For that I'd need some C++ functions somewhere in the non-game-engine code that can be called by RMGEN (since RMGEN runs before the engine starts AFAIK). I have simply no idea how to do that (only did this with C -> Python). So if you could help here that would be terrific. In general I'd really like if variables like min height, max height, gravity, wind speed, wind bumpiness, ... would be defined at exactly one place. Some of those might be useful to be set from different parts of the code as well. I don't know if the parsing will cause more trouble in the end then defining them over and over again in the different parts. Some functions, however, would really be useful to have. As an example fast slope calculation is needed by: Pathfinder, Unit AI, Player AI (simulations), random maps (RMGEN) and the graphics engine. The specific needs for making water erosion for RMGEN faster would be a faster function to calculate the slope map: - getSopeMap(heightmap) Takes: heightmap (An rectangular (or square though I don't see the benefit) array of float32arrays) Returns: slopemap (an rectangular array of arrays of arrays (size two, vector) of width and length one smaller than the give heightmap determining the incline of the surfaces between the vortices) (This will also be useful for (non-tile centered) slope dependent terrain painting... and I don't see why the tile centered version should be used in these cases) A similar function in javascript looks like: It returns floats instead of vectors for each surface and could be optimized (e.g. it calculates every edge vector twice, once for each appending tile) I don't have enough overview to decide whats best to do in general.

The problem with the approach of the link is that the algorithm only works on a uniform map (equal height everywhere). The hight could then be changed according to the shading. However, I think I can make the erosion work reasonably fast (I have a few more ideas). My latest version is indeed more sophisticated then everything I've seen so far in code. It roughly works like: - Let it rain dependent on height (get/change water depth map) - Get slope vector map (from height map) - Get acceleration vector map dependent on slope and gravity (would be nice to have the correspondent variable from the engine at hand) - Calculate total speed vector map considering acceleration, last steps water speed and friction (dependent on the water depth and previously calculated water speed) - Change the water depth map accordingly and the height map dependent on water speed and soil portion (dependent on water speed as well) (This takes longer to calculate for each step obviously but the erosion effect is much stronger then just considering water derivation to appending tiles so much less steps are needed) However, there's only one direction all water flows from one tile (two appending tiles getting it) so in the end the resolution might always be a little bad. And wraitii was right at the start: One problem of the actual implementation is the slope is calculated wrong (shifted half a tile) so the outcome gets edgy at ~100 cycles even if gravitation, rain and soil portion is quite low and friction is quite high (already did this for the realistic terrain demo so all I have to do is puzzle everything together). After this change it might be possible to raise the erosion strength (raise gravitation and soil portion, lower friction) so less steps are needed (10-20 would be OK meaning about 2-3 min calculating for giant maps... yes, still a lot but some other random maps take longer). If this (quite realistic) approach fails in speed I can still use an older, simpler one (though I'd be a bit sad ^^). [ofc. this would all be much faster if implemented in C/C++ and given to the random map libs as a shared function]

I agree with sanderd17. This idea sounds more like a cheat then game content. As player AIs (which as a side note are players) should not cheat (before the hardest settings) the human players shouldn't also (unless specifically determined as cheating).

Thx for the answer. Concerning the snow: I only have a decent overview about RMGEN codebase and not the simulation code (or the engine) so I can't help you here. The "only visual" height change is also used for terrain flattening underneath buildings AFAIK so maybe you could look there. The function would be similar to erosion functions like in here. I also played around with rain amount depending on height (a linear function did do fine). A function to redistribute the snow locally might be similar to getAdditiveWindErrosionedReliefmap() in the above linked map (only 8 possible directions though since tile, not vector-based but fast). A global wind strength parameter will do fine (the local effects could be (randomly) determined in the functions doing things with wind involved). An additional parameter like "windBumpiness" would be helping though. I have no idea where those global parameters should be invoked (guess right in the C++ code since e.g. tree movement depends on it). Ofc. the map/RMS designer should be able to set it.

Hm, got a javascript question: What's the difference of defining a class function inside the body with this.function_name = function () {blablub} or outside the class body with class_name.prototype.function_name = function () {blablub} Code: As is it works. Using the documented out code (inside the class body) Atlas starts but never finishes the random map.

Concerning TILE_CENTERED_HEIGHT_MAP variable: Could someone plz tell me the reasons for/advantages of the two different terrain texture paint methods? It is quite annoying for implementation of some heightmap functionalities (like e.g. using height/slope maps to paint tiles). If one of the methods have proven to work better then the other it may be worth the thought of removing the other one. (If both are suited in different cases (as I suspect) I'll just have to adjust the functions to that)

Oh my. That order got me confused. Thx! So that's an improvement additionally to staying up to date. Great job!

So the conclusion is: All ESR31 versions are slower. So why should we go for ESR31 anyway?

Nice. The things I like most from your latest patch are: - The ripping out guts animations - The sacrificial pits with blood lakes on their ground (I'm working on a blood eroded terrain) - The Golgothan excremental demon (see here) It perfectly fits in the timeframe. EDIT: Oh, just found the pyramidal temple with the constant stream of PPL being quartered. Perfectly done! I don't thing the skeleton spawn points should be restricted to the zombie players territory though. They block each other and stumble about each others bones (and enemy guts) ATM. What about converting PPL to the zombies by ripping of their flesh and transform them to skeletons (until now only the guts are flying around and they are converted to zombies). At least alternatively? (The burning skin shrivel animation is done well. Perhaps burn the PPL? We could add support for the olfaktorik output device to make it smell like burned flesh) Cool power suggestions: Like in this holy book maybe we could add the zombie hero ability of cursing the enemies like: "May your guts entangle the next thornbush!" (at least if they worship Om)

"Happy you are wrong this time:" ~ Hephaestion Me too! I totally missed that development. THX for that. (And if leper, Spahbod and sanderd17 agree on that it's as good as in I guess ^^)

I didn't try it yet but it should work: http://www.wildfiregames.com/forum/index.php?showtopic=18211#entry284318

IMO there's no need for this either. Gaia entities could just randomly walk around (depending on the original point of placement only so e.g. they don't veer away over a maximum distance or something). The exact behavior could e.g. depend on the stance the unit has (though this cannot be set ATM AFAIK). This functionality might however be turned on/off so more specific behavior could be added in scripts. Trigger (that would make such things easy) are not implemented yet though and are not planned to be in part 1 AFAIK. Anyways, you don't need actors like waypoints to deal with this. You can just add these points in the scripts.