FeXoR

OK, maybe I mean the game engine (simulations?) that is not run when pyrogenesis is executed but after the map is loaded (or loads the map). And in case of a random map it is first generated by RMGEN and then loaded AFAIK. Not sure how to name it, I'm very bad of following naming conventions, sorry. If parsing data to RMGEN is trivial please tell me how to get the data for entities inside RMGEN.

Which lines? Sorry edited my last post after you added your's but it's way OT anyway ^^. EDIT: Oh, didn't read the last one. Not sure. Perhaps because I'm in love with them ^^ (See the ending of my previous post).

That would be OK for me too but you'd have a great amount of data very close or even right inside the engine. I thought that would be not wanted and a layer between is already implemented (simulations). If it can be used easy to implement triggers there (or not even needed) we just have to change the map loading/random map generation part. But still that would be a lot of work. On the other hand it would still not work to restrict map/player settings dependent on the map used because simulations is started with the engine after game settings are chosen. So the engine has to run while map/player settings are chosen or a restriction for possible map settings has to be loaded before opening the settings screen (e.g. a settings file for all maps like for random maps it is JSON right now). So back to your question: Because then we would have only one layer of code to maintain and in it very general functions that can be used by more than one part of the game (e.g. RMGEN/AI) instead of parsing data to every part separately. Another example is the terrain analysis that could be done right at map generation and then can be used by the AIs or even pathfinding. You still might be right that I am overrating triggers. Perhaps because I loved how to manipulate maps in Warcraft III. But I'm not the only one. It was so simple and intuitive that a vast amount of maps came out of that some even followed by an own game for this map e.g. Defense of the Ancients: http://en.wikipedia....of_the_Ancients and here an in-game video: ...resulting in this game: http://blog.dota2.com/ and an in-game video: NOTE: Wikipedia states DotA would be a mod but actually it's just a map. WC3 just allows wide manipulation of maps. DotA 2 however is an entirely different game!

No, that concerned general game rules. I though I said that. Changing things ingame and having access to more things in RMGEN as well as AI API (so you load a set of triggers just into the map that manages the AI players rather than the current approach) could be done with triggers (If powerful enough). So all parts get all information (currently RMGEN has about zero information about anything outside the map like entity properties and cannot manipulate anything outside map generation e.g. the possible player settings or build restrictions or the chosen mod).

This all would be so easy if everything was trigger based (Just dreaming I guess ^^). For example it would be nice to have an array "players" in RMGEN that has properties like e.g. "slotStatus" that shows if the player is a person or an AI. Not to mention the entity properties that would help a lot to have access to in RMGEN... Well, guess we should focus a bit and for now on performance: http://www.wildfireg...showtopic=16991 ...and cleaning up the general game rules (that are pretty a mess right now IMO): http://www.wildfireg...showtopic=16986 http://www.wildfireg...?showtopic=6352 ...among others causing e.g.: http://trac.wildfire...com/ticket/1496 http://trac.wildfire...com/ticket/1537 http://trac.wildfire...com/ticket/1010 ...among others. Still a wide variety of "features" (indeed most tickets issues) could be easily fixed by having triggers (which ofc. would take a huge amount of work and time to implement that widely/powerful in the first place) but would interfere with the actually implemented mod design (suggesting a much less powerful trigger approach like http://www.wildfireg...showtopic=16887).

I totally agree ^^. But AFAIK there's no way to limit options by the random map right now. I think this should be included in the random maps JSON file because it's the only thing loaded (if at all? Hope...) before map generation. Not sure who did the JSON approach in the first place. Maybe he could look at it. I have no idea how to do this. If no one is willing to do this I'll look into it though when I have time.

It happens on: Unknown Land, Medium, 3 Player, Seed 2560 (Just an example of cause. In this case it closes the gulf instead of only dividing it though) I think the code for this is line 949-1054. This seams to be a Gulf of Bothnia map though the bug seams never to appear on this map. The difference seams only to be the chosen biome and that the gulf is always opened to the south on Gulf of Bothnia but Unknown Land can have the gulf be opened anywhere. Hope that helps. Investigating further... NOTE: For maps like The Unknown/Unknown Land it would be good to be able to call a random map instead of putting all the code in one map IMO. That way we wouldn't have to debug two or more maps but only the map called (in this case Gulf of Bothnia) that doesn't seam to even be buggy at all.

Sorry for the double post but theres another thing that interferes with the Damage/Armor Type (or other bonuses), how the graphics and the game rules are linked and Unit AI in general so I added another post to clearly separate it: It's about Stances/Formations (again ^^). I don't know if I can explain this clearly. I'll try anyway. As "Attack Bonus VS [unit Type]" feels unnatural to me so feels adding a bonus (of any kind) just for entering a formation. There are several ways to make it more natural but none of them are easy to implement (as far as I though, yet). Damaged units could be take from the outer areas of a formation and could be drawn in to be healed (if healers are present). If there is usage for Stamina (and maybe Moral) the same could be done for exhausted units. Stances should not interfere with player given orders in any way. Instead there should be Orders that work similar to it. The reason is that you have to click less buttons (only the Order, not the Stance and the Order) and the unit enters exactly one Stage (that of the Order) not two States interfering with each other (Order and Stance). That all influences the Unit AIs behavior that is - if all (Formations/Stances/Orders) are used - quite unclear to determine how a Unit/Formation will react to a given situation for both, the player and the developer. For me - personally - it would be much more valuable/handy to have an Attack Move order (as well as a Hold Ground/Defend Order if wanted or something similar). A Guard Target Order and a Search And Destroy/Auto-Explore Order would be handy as well. As can be seen there will be more Orders to implement than the number of Stances + Orders but it will be much cleaner in code and behavior than the Stance/Order combination and they can be implemented one by one.

A bit off topic (I think there was a thread for this but I can't remember where it was, feel free to move my post there): Concerning "Physical correct" behavior vs straight forward game rules: There are mainly two (clean) ways to make a good RTS in sense of game rules: 1.) Add a physics engine at a very basic level and add very simple game rules (Only Movement(Turning) Speed(Acceleration), Attack Speed/Damage, Projectile Speed/Turning Rate(for missile attacks)/Error but nothing like Armor/Attack Type etc.) Example: Total Annihilation, Spring Engine Advantages: Very realistic, what units are good against what other units comes out "naturally" (Without bonus, just by the physics) Disadvantages: Very Hard to balance, a much harder to implement engine 2.) Add a complex set of game rules that allow units to counter specific other units (either by armor/attack type or by another more "natural" attribute like the Unit Size like done in Starcraft) and let the graphics only represent that rules (In AoE/AoC "Bonus vs Unit Type" is also present but seam enforced to me) Example: Starcraft(Damage bonus against units depending on size, Splash damage), Warcraft III(Damage/Armor Type, Heroes take less spell damage), Age of Empires(Damage/Armor Type) Advantages: What units are good against what other type can be determined by the Attack/Armor Type without seming to be enforced. It can also represent the Armors usually worn by the specific unit type if it's placed in an historical setting (like 0 A.D.). Disadvantages: The game is less realistic especially the graphic representation might seam to not always represent the actual outcome in damage (Warcraft III tries to make it a bit better by making all ranged attacks "missile" attacks which on the other hand seam a bit strange in case of auto aiming arrows). As is 0 A.D. is an ugly mix of all. The graphics does not only represent the game rule but interferes with it e.g.: Melee units that attack does not deal damage if the target is to far away after the attack animation is run. Though there is no fundamental physics engine underneath the game archers shoot in physical trajectories (might be still good for the graphics but bad to let that interfere with the game rules meaning every shoot should hit if not otherwise managed in the game rules like a "Chance To Hit" Attribute) We have Damage and Armor Types but also got "Bonus vs". It would be better to have one of this (I'd much prefer Armor/Attack Types). That mix is quite impossible to be balanced and results in many "Bugs" like the missing chasing melee units (Made even worse by having a min. range for non-siege/fast units like Skirmishers). Another game (and I like it) that mixes a bit of all is Warzone 2100. Projectiles (but missiles) have a trajectory that is fixed at the time it goes off directed towards the predicted point of the unit targeted when the projectile (would) collide with the target with an applied Error determined by the upgrades of accuracy for that type of weapon. It also has Damage/Weapon Types that deal different damage to different units dependent on their propulsion: Cyborgs, Hoover/Wheel/Half-Track/Full-Track Vehicles, VTOLs. Also the speed of projectiles greatly matters for hitting a target. But it turns out to work quite well though not really balanced. But in general I think it would be better and a lot cleaner/much less messy to pick one and stick with it and just make additions in an other direction if it works good with the chosen base rules. NOTE: I tried but not always managed to write words that are involved in the game concept with capital initial letters like "Attack Type". Don't know if that is usual practice and I'm quite sure I didn't do it right all the time but I think it makes it easier to differentiate between game concepts and their explanation. Feedback appreciated.

I don't think that's really a problem. Indeed. I would be OK to stick with it as is or an upgrade for Wall Towers in Town Phase (It could just add the default one arrow or before the upgrade the towers have no attack at all even with soldiers garrisoned in it).

This way citizen soldiers get even more powerful: At the beginning they are good gatherers and then become good fighters...

Welcome to the forum! I think this page should be helpful especially the build instructions and track usage: http://trac.wildfire...rtedProgrammers Have a nice stay

In my opinion most RTS games are to fast. Most don't even really have a build up phase of notable length. Just AoE had a similar feel of gameplay. 0 A.D. has the right speed of gameplay though the performance has to be raised (which is high priority right now). I remember multiplayer games in AoE II where players swapped the island they occupied during the game. It was amazing! Something like that is not possible in most other RTS games.

Towers that don't shoot by default (or at least after an upgrade) are pretty useless. IMO in the and watchtowers are better than walls including wall towers anyway (At least for me). AFAIK defense towers have a larger range then wall towers in general. I like the Iberian walls. IMO another civilization should get palisades as civ bonus. However, I can't see the Iberians are underpowered beyond not having ranged food/wood citizen soldiers. They are overpowered IMO (cheap, fast, self sustaining by gathering mass wood, can be produced right away). Tell me if a decision is reached so I can change the random maps starting entity placement function appropriate.

Not really, but I take this one as a compliment, so THX But I have pretty much no idea how to effectively make formations valuable without seaming enforced but still being easy to implement. It could make use of direction dependent blocking, healing and/or regeneration, moral and stamina but should NOT just raise values like attack or armor (That what makes it "enforced to be useful" for me). Stances is another example that I can't wrap my brain around totally because I find it hard to construct a situation where changing the stance is more useful/less micro intensive then selecting the units in question and give them an order. The second in almost all cases seam better (as far as the units listen to your command what is pretty much the problem as is now). Another thing is that it interferes with the current action of units and so all combinations of stances/action has to be thought about which is pretty much impossible (At least to work sane). The unit AI is hard enough on its own to make work well. But, yes, I have spend several time thinking of good systems for RTS and RPG games (Pen and Paper as well as Hack n Slay).

Yep. Warcraft III game rules are so good that DotA was possible, the most played map of the game right now - and the game is from 2002. Since we don't aim to support attributes AFAIK (like WC3 does for heroes) and it's somehow wired to set the amount of damage bonus per upgrade for every single unit type in the game (like WC3 does) it seams to me using a similar system for units attack upgrades would be the best way to go also. It should have a higher efficiency then armor though to make small battles at the beginning take about as long as large battles at the end. So the basis for damage upgrades could be 1.2 (about 8% damage increase when armor and damage is upgraded by one "point"). The base damage could remain as is (absolute values) while the damage upgrades could be a multiplier of pow(1.2, numberOfDamageUpgrades). Some damage upgrades may also grand 2 or 3 "numberOfDamageUpgrades" like armor could be raised by more then 1 per upgrade (I know it's bad naming then). The tooltip for damage could then show something like: 1 "damage upgrade": 15 + 3 (20%) 2 "damage upgrades":15 + 6 (44%) 3 "damage upgrades":15 + 11 (73%) ... 10 "damage upgrades":15 + 78 (619%) At 10 damage and armor upgrades the average damage dealt will then be raised to 2.16 times the damage compared to no upgrades (so battles would be about twice as fast). BTW: Making the percentage values of damage reduction granted by armor (not the armor value itself) a float value would push the number of possible upgrades making a difference possible (if the damage is high enough, about 15+) close to infinity (for both, armor and damage upgrades). The tooltips I suggested are somehow misleading due to the use of "+" (suggesting upgrades would be additive) and the "%". It might be even better to just show multipliers/divisors like: Damage: 93 (15 * 6.19) - 93 actual damage, 15 base damage, 6.19 damage multiplier by upgrades. Armor: 10 (1 / 2.97) - 10 Armor, 2.97 damage divisor (reducing the life loss roughly to 1/3 of the incoming damage) That way it is easy to see that about 2 times the damage is dealt. Roughly: 6 / 3 = 2

If we target wide to use game rules granting the possibility of close to infinite upgrades (and RPG mods) it would be the percentage armor as quantumstate suggests but still having an armor value connected to it in the way I suggested above. The percentage of damage reduction should then be added to the tooltip and can be got by round(100 * (1 - pow(0.9, armor))): Armor (Damage reduction) 1 (10%) 2 (19%) 3 (27%) 4 (34%) 5 (41%) 6 (47%) 7 (52%) 8 (57%) 9 (61%) 10 (65%) ... 20 (88) ... 50 (99) As stated above 0.9 is just an example. 0 to 10 Armor seams a good area to use while some upgrades could provide 1-3 additional armor. Having fixed values of percentage granted per upgrade would extremely favor units with high base "armor"/percentage damage reduction: A unit with 10% base armor and 3 10% armor upgrades will end up with 40% damage reduction. A unit with 60% base armor and 3 10% armor upgrades will end up with 90% damage reduction. Without armor upgrades the light armored unit gets about 2 times the damage of the heavy armored unit. With upgrades it gets 6 times the damage! If we target a ruleset that allows huge discrepancies in damage taken we should stick with the subtractive armor.approach. However, this is extremely hard to balance since 1 point in armor can make the difference of 50% effectiveness e.g. for a unit dealing 14 damage to a unit with 12 armor (of that type) that makes 2 effective damage. Raising the armor by 1 reduces the damage to 1. Upgrading the attack again leads to 2 damage. So in the end only a few units and only when fighting against a specific other unit will extremely benefit from an armor/damage upgrade while most others just get a small benefit. Attack speed is of extreme importance here as well.

Yes, but what happens after an armor upgrade? Thats what I'm mainly referring to. A changed armor value adding percentages absorbt will be better for units with already high armor. Say the upgrade provides 10% more armor: A unit with 0% armor would get the 10% and then recieves 10% damage less then before the upgrade. A unit with 50% armor gets 60% then effectively reducing the damage taken compared to before the upgrade would be 20%. (100 damage, 50% before the upgrade makes 50 damage, 60% after the upgrade makes 40 damage. 40/50 = 0.8 = 80% makes 20% less then before) It is a damage absorption ratio but is increased by upgrades exponential decaying so every unit gets the same benefit in sense of effective damage reduction. Perhaps I didn't say what I meant clear enough, sry.

I heave not read everything but IMO there's only one way to go for armor: HitpointReduction = DamageIncome * power(0.9, ArmorValue) In this example 0.9 is just a possible value. It's mainy a bit smaller than 1- That way armor can be any positive number or 0 (no damage reduction since power(a, 0) = 1 for any finite value a). Additionally it's continuous so even float values could be chosen (though I don't think that would help in any way). In the end its like incoming damage is reduced by 10% (to stick with the top example) for each single point of additional armor. So compared to 0 armor a unit with 1 piercing armor getting 10% less piercing damage. A unit with 2 piercing damage gets 10% less damage than the unit with 1 piercing armor, but not yet 20% less then the unit with 0 armor but only 19%. Indeed even with an armor value of pow(10, 100) a unit would still get damage (if calculated in 512 Bit float ^^). Changing the basis (0.9 in the above example) can scale how fast damage is absorbed. Here it is 10% per armor because 0.9 = 1-0.1. But it can be more effective e.g. choosing the basis 0.8 or less effective setting the basis to 0.99 only reducing the damage by 1% per point of armor. It might be not that important in this game since the damage values are quite small integer values making damage dealing non-continuous anyway. But this would be important if someone wants to make an "hack and slay/slash" (allthough quite irritating also known as "roll playing games"... Tz, tz! Only pen and paper is roll playing besides perhaps acting and for some PPL the "act" ^^) game mod for 0 A.D. for example. A good ruleset is of value - at least for me. 3 Damage types are a good value. More are hard to balance (3 already are BTW), less seams not worth the effort. Just wanted to let you know my thoughts.

^^

No. Mine is only a rough idea, yours is an actual implementation, so yours is much better ^^. But in the end I think it is of interest that triggers are easy/short/intuitive to use (not only in a GUI but also as code/text/whatever).

Something like: def event = new TriggerEvent("unitGetsAttacked"); def condition = new TriggerCondition("playerToIndex(ownerOfUnit(attackedUnit)) == 1"); def effect = new TriggerEffect("sendMessageToPlayer('Player 1 is under attack!', 1)"); addTrigger(new Trigger(event, condition, effect)); I don't know how the code in maps work. It's for sure bad to give code as a string. But in principle my idea is like that.

For me the links are not linking to an existing page (404). Just to say it...

Sounds good to me. Not sure who has most experience/organizes scenarios and if he would like so say some words in the opening post.

Well, I mean 30 lines of code for a simple trigger (in the map data) seams a bit long to me. Not sure how to say this short ^^ (cumbersome?) Most of them are brackets of cause.