FeXoR
-
Posts
1.426 -
Joined
-
Last visited
-
Days Won
28
Posts posted by FeXoR
-
-
Added a patch to also make them available to the RMGEN lib wall_builder.js and added them to the RMS "Wall Demo":
http://trac.wildfire...com/ticket/1855
They look very nice!
(I also noticed that Hellenic defense towers now have the entrance on the correct side. I added a ticket for this some time ago but can't find it any more (maybe it was changed). If someone finds it plz let me know, thx).
-
1
-
-
That's another very nice thing with exponential armor increase: There is no limit in armor "level"! And it always reduced the same amount of damage compared to the last level no matter how high it is (of cause only if the accuracy of the calculation allows it. Even integers would give a reasonable accuracy until armor 25 (93%). Changing to float values would be good though).
Level 50 would be silly levels of armour strength so enemies would need to deal 200 damage for every hit point reduction. level 9000 armour is absolutely ridiculous needing 10^409 damage for every hit point reduction.
That's not necessarily true. If damage scales the same way per upgrade this would work too. Just the hitpoints would look poor compared to the extreme damage that would be dealt then. Still units would need the same amount of hits to kill each other due to the extreme damage reduction on the other hand.
-
Sry, zoot, forgot to point out that in general you are right: Armor is more like subtraction than multiplying (with a number smaller than 1) the force of an attack (in context of games referred to as "damage"). How balanced a game is on the other side mainly effects its "playability" IMO and with it the amount of fun playing it grants. So making it "easy" to balance to me is equivalent to making it more fun. I like fun games ^^.
I don't have any objections though if anyone wrote a physics engine and abandon all the game rules that got obsolete with it! I just don't think that will happen...
(On the second thought I can't remember a game based on a physics engine - e.g. total annihilation - that was as much and as long fun to play as games with a more "synthetic" ruleset - like Starcraft, Warcraft 3 or Age of Empires 2: AoK/AoC)
-
And yes, Warcraft 3 used it, but it didn't use "upgrade 10% of this armor", it was more like "add 1 armor point to every unit with this kind of armor"
What should "upgrade 10% of this armor" mean? That's what this discussion is about.
In WC3 "add 1 armor point to every unit with this kind of armor" exactly means "reduce the damage compared to the damage done before the upgrade by 8% (to every unit with this kind of armor)" (in our example it would be 10%).
-
I like the current system
It's straightforward, and doesn't lead to counter-intuitive cases like a wooden shield absorbing 50% of the blast from a nuclear bomb.In reality mechanically "dealt damage" (so not considering lasers or nuclear bombs) and the "reduction" of it by other material depends on the force divided through the area it is focused on and the absorbing materials hardiness to be deformed. So for weapons of the 0 A.D. time-frame that would mean piercing weapons might deal less damage to a body but get absorbed much less by armor also. It indeed extremely depends on the angle an attack hits because the absorbing material might be a lot thicker in that direction than it's thickness normal to it's surface. Such complex considerations might be helpful for RPG/H&S games but due to a lot harder balancing it seams unsuitable for RTS games to me.
Besides: It is hardly intuitive that the damage dealt to a catapult is considered when hitting the catapults wooden frame (like it is considered for armor values as it seams). I pretty much doubt that (non-fire) arrows where used to destroy the catapult but to kill the operating crew. So the armor values of catapults against piercing attacks are much to high IMO. On the other hand an axeman could disable a catapult with a single blow by cutting an essential rope. So non-tank mechanical units are quite vulnerable to attacks - that's why they where heavily guarded.
-
I think showing the armor value (that might seam arbitrarily to some PPL) and the percentage damage reduction would be fine for most PPL like:
Armor (Damage reduction)
1 (10%)
2 (19%)
3 (27%)
4 (34%)
5 (41%)
...
Only showing the armor value in the GUI and the percentage damage reduction in the tooltip/mouseover and adding an explanation to the manual would do IMO.
Note that Warcraft 3 was and is a very popular game and uses that as well. Most players are not at all interested how a game works in sense of game rules and are just happy when they works fine. They don't notice/care "why" it is fine in most cases IMO (sorry if I do the gamers wrong but that's my experience).
So focusing on good game rules while making the GUI as informative as possible and explaining them to interested PPL in the manual seams the best way to go for me. The game rules should not depend on the average understanding of math but on the fun PPL have in average playing this game. Most will find out by try how the game "works" anyway rather then calculating everything before actually playing.
-
Another advantage of exponential armor increase by upgrades is that balancing applies equally despite the level of upgrade . So a specific unit 2 times as strong against an other specific unit will exactly remain 2 times as strong against that other unit if both got the same number of upgrades (This only exactly fits if the units have the same range because higher armor favors melee while higher damage favors ranged units, just to mention that side effect).
Same with attack upgrades if done exponentially.
-
It just came to my mind that an AI saving it's data to evolve over more than one game will break sync in multiplayer games if the data (in this specific case the rules if I get that right) are not shared before the game starts.
-
I think he means some sort of adaptative AI that would learn from the player/games and slowly improve. They're quite in fashion right now, I'm not sure how efficient they could get though, but it'll be very interesting to see anyway
.IMO that aproach would still be static in code. Just the data the code uses change. To get dynamic code with C++ would mean you'd have to compile during runtime. In that sense uncompiled/JIT-compiled languages seam the right decision to me if "dynamic code" is indeed the aim.
So Yves question seams quite relevant.
Could you tell us a little more detailed what you intent to do, agapsguy?
-
In AoE 2: AoK/AoC playing together meant you are indeed considered one player - just you share control of that player. That doesn't mean you are weaker than 2 separate players though. The game is complex enough to be efficient enough together as one player. How the two players arrange responsibilities should be their decision IMO.
-
Simulation components can be done in C++ (the AI manager is itself an example of this), so it shouldn't be completely impossible to extend it to support C++ AIs.
Thx! Good to know. I thought mods where js exclusively and since AIs are part mod/simulation it would not really fit into the design.
-
Hi and welcome to the forum
What you want to do is at least ambitious as well as problematic because it does not fit to the overall design with mods and simulations (both done in js) AFAIK. It's for sure possible though.
I have no overview of the files you'd need but CCmpAIManager.cpp seams like a good point to start as zoot.stated.
For more detailed information you might want to visit the development chat and ask there: http://webchat.quake...hannels=0ad-dev
Good luck with your project and have a nice stay.
-
...I put here a version of such a mod...
Where is it (I can't see any download link)?
-
Ah good to know, I removed handling of that path because nothing got created in it and it seemed pretty obscure and unused.
You can also use My Games\0ad\mods\user and create the files (same folder structure) there and the game will load them, but by passing -noUserMod to the executable you can disable loading of the user mod (eg You found a bug and want to see if it is something that is caused by your mod).
Perfect! Thx for letting me know
Recollecting issues on random maps (to get an overview about how helpful player restrictions would be):
Legend:
Connected to number of players to map size ratio.
Connected to wall_builder.js in general or specifically to Iberian Civ bonus defensive structures.
Connected to not enough space for players bases
Not really RMS related
General issues:
- Iberians on Tiny maps (General issue): By default tiny maps don't grand any defensive capacity to Iberian players. Fix: Only changing the start positions (so they are at least 20 tiles away from the map border) and add player caps can help here IMO so there is enough space to place the Iberian Civ bonus defensive structures.
- 8 Iberians on Small maps (General issue): Iberian Walls are to close to each other (shooting at each other right from the beginning of the game). Fix: Only player caps would help here IMO.
- Entities inside walls obstruction (General issue): Walls placed with wall_placer.js functionality may be placed on trees. Fix: Grand RMGEN access to the entity templates, add a "remove entity" function to RMGEN, add "remove obstructed entities" to wall_builder.js.
- Walls in unreachable areas: Sometimes Iberian walls (or walls placed with wall_placer.js in general) may wind up on cliffs or in water. Fix: Grand players enough room for the walls (20 tiles radius) on Small or bigger maps (Irregularity of the wall still might cause issues). General fix: Make the wall builder check if walls can be placed in that area. For that RMGEN would need access to the entity template data and information about how step the terrain can be to place buildings.
- Many RMS take long to be generated (historic_bruno thinks that is a big issue). Fix: More or less complete rewrite of all RMS and eventually the RMGEN API as well (I think this might help but is also a little drastic. Current RMS have issues but are far away from being unplayable).
Map specific issues:
- Aegean Sea: Unreachable trees on islands. Fix: Check in the Unit AI if target is reachable.
- Alpine Lakes: Iberian Walls reach into cliffs and lakes. Fix: Grand the players more space.
- Alpine Valley: Iberian Walls reach into cliffs. Fix: Grand the players more space.
- Anatolian Plateau: OK.
- Archipelago: Not sure how it should work.
- Ardennes Forest: Iberian Walls reach into cliffs. Fix: Grand the players more space.
- Atlas Mountains: Iberian Walls reach into cliffs. Fix: Grand the players more space.
- Belgian Uplands: Iberians get no Civ Bonus defensive buildings. Fix: No idea. The map is not always fair. "Fix": Add a category for random maps that are not as balanced but more realistic or random than the "standard" RMS.
- Cantabrian Highlands: Iberian Civ Bonus towers are placed on cliffs. Fix: Add a keyword argument to change the radius of the Iberian Civ Bonus to placeCivDefaultEntities() in rmgen/misk.js.
- Canyon: This map causes an error when generated with 1 player. Fix: Hunt down the bug in the code. Iberian Walls reach into cliffs. Fix: Grand the players more space.
- Continent: Iberian Walls reach into each other on Small maps with 8 players. Fix: Grand walls to Iberian players only on medium and larger maps or add player caps.
- Corinthian Isthmus: Iberian walls/circle of towers excess the map border: Fix: Change players start positions.
- Corsica vs Sardinia: Iberian Walls overlap each other and wind up in Cliffs. Fix.: Remove Iberian Civ Bonus defensive structures and add player caps.
- Cycladic Archipelago: On Tiny maps islands sometimes are connected. Fix: Add Player caps.
- Deep Forest: On big maps the many trees cause huge CPU/GPU usage. Fix: No idea. Formations get stuck in the forest. Fix: Fix Unit AI, Pathfinder and Formation functionality. With high player to map size ratios there is not much wood left on this map. Fix: Not really a bug, it's just nut much space left. The numbers of paths could be reduced though.
- English Channel: Iberian walls/circle of towers excess the map border: Fix: Change players start positions or make it a rectangular map..
- Fortress: On tiny maps with 8 players walls overlap. Fix: Add player caps. On small maps with 8 players walls are so close to each other that they might shoot arrows right from the start of the game.
- Gear: Iberian Walls reach into water. Fix: Place towers instead. Unreachable trees on island. Fix: Check in the Unit AI if target is reachable.
- Guadalquivir River: Iberian Walls overlap. Fix.: Change start positions.
- Gulf of Bothnia: Iberian Walls reach into cliffs. Fix: Grand the players more space.
-
WIP...
NOTE: I am just summarizing issues and tell how they could be fixed. That does in no way mean that they have to be fixed like I suggest. IMO we have to gather ways to fix them and then decide what to do. Pointing out things are bad but then rejecting a way to fix them without telling an another suitable way to go does not help so please focus on (alternative) ways to fix issues (and at some point we have to agree on something ofc.).
-
Try My Games\0ad\mods\public (or mods\user). Just curious, but did you create the first folder yourself, or was that generated by the game (Where there any files in it)?
I created it myself (from mods on, no files put there by the game) to test changes to RMS while still having changes applied made in SVN without interfering with my changes.
My Games\0ad\mods\public works perfectly, thx. It would be nice though to reload mod data in Atlas if they changes during Atlas is opened. It's not doing that for some time now (long before the path change) but in the beginning reloaded them depending on the last date of change (so if the latest changes where made to the specific file in the 0ad dir this is used, otherwise the one in the cache or hopefully now My Games). It still uses the newest version when Atlas is launched but does not check if a file is changed while running. Reload during runtime would make debugging/designing much more easy.
EDIT: Oh! Changes in RMS are applied during runtime of Atlas! Checking RMGEN lib changes... Whow! They too! Thx much for this! Wonderful!
-
Just to make you aware of http://www.wildfireg...showtopic=17097 the first issue mentioned. Judging by the first reporters later tests it seems as if it might be something GUI related, so maybe it would be easier for Spahbod to fix it, but that's not to say that no one else can look into it of course
Thx, saw it. I'll not have much time in the next weak but after that, who know
I just noticed that RMS are no longer loaded from AppData\Local\0ad\cache\mods\public\maps\random so is there another folder maps are loaded from now (like Documents/My Games or so)?
-
Eventually getting round to replying, after far too long.
First of all thanks for the reply.
This is an issue, I think we should drop this feature.
I agree.
This is something that I implemented so I have given it significant thought. It used to work like you said, with a simple 50% hit chance. I'm pretty uncertain about this. Some people like being able to dodge missiles but this does introduce a big element of micro.
I think I read somewhere that CPU usage is quite high to simulate (if done, not sure) that a projectile can hit a unit not initially targeted by the unit the projectile comes from. That might be considered as well for a decision here. I'm uncertain about this as well.
Simply having attack/armour types just doesn't seem to be flexible enough for what we want. Just having bonuses leads to having to create a huge amount of bonuses which also means the player needs to learn a lot of things. I think it is reasonable to have both, the armour gives the broad picture with bonuses giving extra detail to create more interesting interactions.
Thats OK for me just think that picking one of them would do.
I'm not sure why you put "Bugs" in quotes. This is a genuine bug that is unintended behaviour, it is a release blocker for the v1.0 release.
Good to know. What are the plans to fix this? Give ranged units a melee attack that is weaker that their ranged attack seams bad to me because ranged units then by default fight "imperfect". That seams to be stupid and will result in more micromanagement. In combination with the yet crappy formation behavior it will be a pain for the player to manage.
I'm not convinced about it being better to pick one or the other. I can see your argument about it being cleaner, though I think the armour/attack type is actually more in the physical simulation camp. I would say that we should treat the more "physical" stuff as the core and give little boosts with the "artificial" stuff to introduce variety.
I didn't make myself clear here. I meant 1.) (Physics engine, not many other game rules) or 2.) (Complex game rules, graphics "unlinked" from the game rules just representing the action mainly) not damage/armor type or "bonus vs.". Sorry.
Attack move will definitely be there, perhaps some of the others as well.
Good to here. But it is still planned to stick with orders+stances+formations? That's my main concern. It results in a vast amount of combinations to be handled sanely which seams to be a quite impossible job.
-
Since I got no response whatsoever concerning player caps on random maps I can only assume that there will me no such thing in the near future.
However there are other matters:
- Load an RMS (it's js and json) from within another RMS.js (mainly for "The Unknown" maps):
So far AFAIk only a hole directory but not a single js file can be loaded from within an RMS.js (with RMS LoadLibrary([Directory to load]) in public/ps/trunk/source/graphics/MapGenerator.cpp line 149)
So it would be nice to be able to load a single js file as well.
In addition to that the json file has to be reloaded to adjust the settings appropriate to the map chosen by "The Unknown" RMS after or during its runtime.
Any suggestions how to do this?
I guess we need the agreement of the coding team here as well so please check if they want to do it themselves or if they in general agree to add this functionality at all or what other suggestion they have for "The Unknown" maps to be easier to debug and contain less duplicated code. So if any of the team members read this a comment would be highly appreciated.
EDIT: It seams that there are at least 3 ways to do a similar thing (not sure if all of that works as wanted):
1.) Add different "Random" maps in the gui code that then randomly chooses from a given map pool (e.g. "Random Land" etc.).
2.) Add finer categories like "Naval Maps" or such and let "Random" then load a random map of this category.
3.) Add a LoadRms() function in MapGenerator.cpp similar to LoadLibrary().
- Fix the maps so none of them raises errors with any number of possible players and reduce wired things like walls reaching into water, other walls or the map border or towers starting to shoot at each other right from the beginning of the game as far as possible:
Canyon: Fix the PathPlacer() function pathplacer.js or see if wrong values are given to it. I used my own functions to generate paths so far so I don't have any experience with this. Better someone else look into this if possible.
Iberian Civ Bonus in general: This can be determined as an optional argument to placeCivDefaultEntities() in binaries/data/mods/public/maps/random/rmgen/misc.js line 171 already so only the RMS.js would have to be changed. I'll look into this.
If any agreement is needed here as well please let me know.
-
I'm not sure if this changes are indeed wanted.
Please try to avoid assigning a task before this is certain.
EDIT: I think the patch is helpful and working as it should. I'm open for changes ofc.
Avoiding limitations and trust the intelligence of the user is IMO a good thing, too, so this argument is valid for me as well.
EDIT2: I would like to know which decision was made on this matter:
- Reject player caps because a number of players to use on the different map sizes is recommended already in the map size description and the host should decide on this basis by himself?
- Reject the patch but in general agree to let RMS choose the player caps?
- Anything else?
- None?
-
THX for the reply.
Done:
- Guadalquivir River: Removed Iberian civ bonus walls for Small map size.
NOTE: I made a mistake in the code though (Fail by one, in the last post, not in the patch ^^)! The right code is:
placeCivDefaultEntities(fx, fz, id, BUILDING_ANGlE, (mapSize/64 - 2 < 2) ? {"iberWall" : false} : undefined);- Phoenician Levant: Set max. player caps to [4, 4, 8, 8, 8, 8, 8].
- Pyrenean Sierra: I oversaw something here: If only one player is used he is placed so close to the water. So I choose to:
Set the min. player cap to 2 and only add towers on small maps as civ. bonus for Iberians.
NOTE: If 2 non-allied Iberian players are next to each other on the same side of the mountains on small maps towers will start shoot each other right from start!
But if it is meant as a team map, OK ^^.
(Just noticed that mapSize is set to getMapSize()+1 here so used round here)
- All the "Unknown" maps: Set min. player caps to 2 and max. player caps to [2, 4, 6, 8, 8, 8, 8].
I agree with this mainly but still I see the problem: How to communicate this to the player? The player should know what civ bonus he gets IMO but can only find out by playing the map so far.
Patch/files replaced in http://trac.wildfire...com/ticket/1834
Checking if this can easily be auto-added to the description...
Not very readable I fear. Well. No more ideas ATM.
I'd say add the patch and look how confused players get
Oh, wait! It's not that bad! Adding patch... Done!
(The minimum players caps (if present) as well as the maximum player caps by map size are now automatically added to the RMS description in gamesetup.js. Guess that's better than nothing...)
Sorry for the string voodoo but I found no other way without looping (normally I try to avoid regular expressions):
MAX_PLAYERS_BY_MAP_SIZE_RMS.toString().replace(/,/g, ", ")
OK. Done!
Please check the ticket and test if everything works as wanted and is self-explanatory enough. THX!
-
Nice script
-
Resuming to finish this (was caught by carnival ^^):
It would be nice to have a statement of a team member concerning the Iberian civ bonus walls.
IMO just a brief "Up to X players." comment in the map description would suffice. If they need more detailed info than that, they'll have to click the various sizes and see. People will quickly learn how many players the various size-map combinations accommodates.
Well, the shortest I can think of is still quite some text and the description widget is not that big (it's fitting ofc. but needs scrolling in most cases):
Tiny: 2 Players, Small: 4 Players, Medium: 6 Players, Normal+: 8 Players
Information about the defaults are not needed?
Done:
- Gulf of Bothnia: Set min. player cap to 2.
- Phoenician Levant: Set max. player caps to [4, 4, 8, 8, 8, 8, 8].
- Snowflake Searocks: Set min. player cap to 2.
- All the "Unknown" maps: Set max. player caps to [2, 4, 6, 8, 8, 8, 8].
ToDo:
- Guadalquivir River: On small maps with Iberians walls are placed for them but sometimes exceed the map border
To reproduce: Guadalquivir River, Small, 1 Player (Iberian), Seed 0
To fix: Move the start positions further away from the map border or avoid placing walls for Iberian players on small maps.
Replace line 145 with:
placeCivDefaultEntities(fx, fz, id, BUILDING_ANGlE, (mapSize/64 - 2 < 1) ? {"iberWall" : false} : undefined);Waiting for a team-member to decide...
- In General: Iberian civ bonus if towers should be reduced to 5 instead of 7 mainly because of the population increase. Number of towers and average distance to CC (radius) should be added as keyword arguments to misk.js placeCivDefaultEntities(). Default is 15 for towers, 20 for walls (That's OK).
This will be another patch because not that close linked...
- Phoenician Levant: On small maps with 6 players Iberian walls nearly touch each other.
To fix: Reduce max. player caps to [4, 4, 8, 8, 8, 8, 8] or don't place Iberian walls in small maps.
Replace line 180 with:
placeCivDefaultEntities(fx, fz, id, BUILDING_ANGlE, (mapSize/64 - 2 < 1) ? {"iberWall" : false} : undefined);Waiting for a team-member to decide (though fixed by max. player caps for the time being)...
- Pyrenean Sierra: Players start positions are placed to close to the water. Iberian walls extend beyond the shore sometimes.
To reproduce: Pyrenean Sierra, Small, 1 Player (Iberian), Seed 0
To Fix: There is enough space on the map! Please move the starting locations so the walls have enough space to be placed.
The RMS designer himself should look into this IMO...
- Rhine Marshlands: Sometimes the Iberian Walls extend into water here as well. It's not that bad but I think the the amount of space granted for players bases could be slightly increased. Alternately to use towers instead of walls could work better here.
The RMS designer himself should look into this IMO...
- All the "Unknown" maps: I refuse to check them! However, I will try to add a function that enables loading from RMS inside other RMS.
This will be another patch since not related...
Updated ticket: http://trac.wildfire...com/ticket/1834
Waiting for a decision on Iberian civ bonus wall problems on Small map sizes and/or review of the ticket before proceeding with the other issues...
-
FeXoR has been clamoring for a way to access things such as template data from RMGEN for a while: http://www.wildfireg...120#entry262357
What is the recommended way to approach this? My suggestion would be to create some kind of 'manager' separately from the simulation and move functions which don't strictly require the simulation to be running out of simulation components and into this new 'shared functions' manager. Both RMGEN and simulation components would then invoke this manager when they require any of this shared functionality.
THX for picking up my clamoring
-
Thanks for working on this FeXoR. Hopefully one of the devs will be able to take a look and commit the patch soon
It's a pleasure!
A question remains: If different maps have different number of players caps on different map sizes and it's about the same for the Iberian civ bonus how to make the player understand which map has which caps? Add a comment to the map description?
Making him "try and error click" around in the GUI to find out which caps each map has seams hardly appropriate.
Even worse with Iberian walls: The game would have to be started with iberians chosen to find out what type of wall the player gets dependent on the map, it's size and eventually on the number of players selected.
Any suggestions?
EDIT: It might be a good idea to add such things to the "advanced settings" window. Even if the player cannot change it there (though allowing him to change it would be better IMO) the default settings of the map could be shown/seen there. Not sure if that are more like game settings or map settings. Perhaps a new window specifically designed to choose such map settings would be better.
AoEII HD
in Introductions & Off-Topic Discussion
Posted
Steam is a no-go IMO. It breaks the law in many countries especially the right of usage of bought software (that with steam depends on the settings of the steam servers, not the setup of your system).