Jump to content

FeXoR

WFG Retired
  • Posts

    1.426
  • Joined

  • Last visited

  • Days Won

    28

Posts posted by FeXoR

  1. - In the old HP there where 2 different newlines: 1.) "Normal" newline entered with strg+enter 2.) 1 1/2 newlines entered with enter They seam to mess up things quite often (an added newline added space before the paragraph it was entered after or after submitting additional newlines where added strangely). This issue seams to be no more, great job :notworthy:

    - When trying to edit a long post you could not reach the end of the post with the cursor. This issue seams to be fixed as well :thumbup:

    - Before and after smilies spaces are added automatically. This issue is still there. In addition a smiley is wrapped ti a newline if it is entered directly behind it.

    - If the right (next) button of the smiley-bar is presses too often no smilies are in any more (instead of starting with the 1st smilies again). If you then press the smiley button again the bar is hidden, presses again the bar shows up again but still no smilies in. The "show all" button of the smiley-bar opens a new page with the smilies in which seams bad for me because with many topics opened you don't know to which topic the smiley-tab (or windows) belongs to.

    - I don't seam to be able to change my avatar. "Change" appears at mouse-over the avatar in my profile but clicking does not do anything. Animated gifs does not seam to work any longer (but I can't tell for sure since I can't change my avatar and you said there where an issue with that and they might have to be changed). Plz help me with this one.

    In general: Good job :thumbsup:

  2. I think the phases are too short. You don't need to play long to advance to the next phase. I suggest from phases 1 - 2 you need a certain pop also. Then an increased pop for phases 2 - 3 and a certain amount of techs researched

    The phases will have longer duration when starting resources are lowered. ATM you have enough resources for 10 female citizens (500 food), 5 citizen infantry soldiers (250 food and wood) and the 5 needed buildings (~750 wood). If you start with 250 of each resource only you just have enough for 5 citizen soldiers or 5 female citizens and about 2 buildings. That will slow things down. The final costs of the phases can be balanced if more ingame experience is there IMO.

  3. It's probably easiest to do any kind of 0 A.D. related scripting in JavaScript as that is the current scripting language used :)

    I think lua is used already in the build environment but I agree to stick with one language in the "binaries" (JavaScript). In general I prefer Python :man_in_love:

  4. There are other considerations besides a simple cost:population ratio, like construction speed, armour, health, building footprint, villager time (time spent building that seemingly overpowered 150W house could have been spent fighting or gathering resources), etc. But yeah, I think it all balances out.

    True, with the build time taken into consideration houses may be balanced ok.

    But in general the game is not balanced at all (but I think you agree though perhaps not in the parts I have in mind but that's a thing for the beta phase IMO)

    BTW: I updated my latest post while you wrote yours. A bad habit of mine x) 

  5. In scenarios there can be existing structures placed on the map which are not Village structures.

    5 isn't too many. You can reach that pretty fast with the standard starting resources. I haven't done much testing yet though. One balance issue is that come civs have houses worth more pop that others though.

    Having two types of houses that AFAIK are: Cost 150 Wood/+10 pop cap and Cost 100 Woods/+5 pop cap is imbalanced on its own because the first grants +1 pop cap for 15 Woods the second needs 20 for the same amount.

    Needing 5 buildings make them a bit more balanced because the hose type with the lower pop cap/wood ratio (bad/less efficient) is cheaper per house and so the needed structures can be reached faster (with less wood) with such civilizations.

    Hmm, if you have 5 Town Phase buildings it's weird the map designer didn't let you start at the Town Phase =) In either case you will be able to upgrade to the City Phase more or less as soon as you reach the Town Phase in that case, so giving a player a full set of Town Phase buildings and limit them to the Village Phase, or even the Town Phase, does seem a bit weird imho :)

    Iberians start with walls and towers by default (which are city phase buildings) but they don't start in city phase (which I think is good. The walls seam already hard to balance for me).

    For me most things are not considered "logical" in RTS games so having the goal of being "historically accurate" for me applies mainly to the text and the story told in a game. I could wright a list of 100 items right know that are unrealistic but it's not the question for me. It's a game and it should be fun and on the one hand complex enough to stay interesting for a long time on the other hand not too complex that you can't catch up with what you want to do in theory while the game runs in realtime. So both, realism and historical correctness, don't count for me when it comes to gameplay issues. Those should be clearly separated! Art, text, story and others would be good if historically accurate and realistic (as long noone feels offended by this, well, or at least not too many). But gameplay should be purely practical, easy and intuitively to use and balanced (and we're far away from being balanced but this will be a main goal in the beta phase AFAIK).

    So for me the phases of a game should have a gameplay impact to have a reason to exist. RTS games are often divided is such phases like building up resource infrastructure, building up decent defenses against a possible counter attack, and than the (main) expand and attack phase. In the German RTS wikipedia side it's described about as I see it.

  6. So here's something concerning Iberians.

    Iberians will have defensive structures in all random maps and most scenarios as their civilization bonus:

    Oasis 10 (Scenario):

    Iber%20-%20Oasis%20X.jpg

    Acropolis 2 (Scenario):

    Iber%20-%20Acropolis%202.jpg

    Anatolian Plateau (Random Map):

    Iber%20-%20Anatolian%20Plateau.jpg

    Cantabrian Highlands (Random Map):

    Iber%20-%20Cantabrian%20Highlands.jpg

  7. But if you have a apple mouse, you can't use left and right clicks at same time.

    You don't need to click left and right at the same time. Left click on build button, left click at start of the wall, left click on end of the first wall part and beginning of the second, left click on the end of the second wall part and the beginning of the 3rd, continue until you are finished, right click to break up. I still don't mind if shift has to be pressed or it's build further as default.

    What I mind (though a little off topic) is that placing a new building foundation with the shift key pressed shouldn't actually send the selected units there if they already got a build command. Just the foundation should be placed and the units should continue finishing the foundation they are send to/working at already.

  8. If a random map is generated with Hellenes (which is the default in Atlas) or Thebans as a players civilization selected it states a warning similar to:

    WARNING: Invalid or unimplemented civ 'hele' specified, falling back to 'hele'

    This is of cause bad. Here is the fix that now falls back to 'rome' and skips the test against g_CivData[civ].SelectableInGameSetup (added a comment) since in the game the races aren't selectable anyways and in Atlas they should work for testing reasons.

    civ_fix_2012-5-9c.zip (rmgen libs)

    However, the default selection in Atlas should be changed to Romans for example as well.

  9. I would say that's included in the capturing of buildings we intend to include :)

    About using shift: I played a bit, and I guess it works. It does feel a bit awkward to have to use a modifier key to keep building what to me is one building (or structure rather, but that's not really the point), but I'd say we can keep it as is for Alpha 10 and see what people think about it and so on for a while.

    I agree but ATM I feel like building further automatically and break with right would be the way to go. But I think both makes sense.

  10. Maybe for skirmishers and archers (both infantry and cavalry), we should give them a penalty (reduced damage) against siege units and reduce Crush damage of ranged cavalry since it's not a good practice for ranged cavalry to ram their opponents?

    If they deal piercing damage they already deal very little damage to siege engines because of high piercing armor of siege engines. Ranged units have less armor and health compared to melee units but I don't know if that makes up for the range (didn't check the attack speed yet). So it might be OK in the end.

    It's mostly the Iberian ranged mounted elite unit with crush damage that seams a bit strange to me. It's more like a siege weapon but still effective to units due to their low crush armor. I think units in general should have higher crush armor and perhaps the Iberian elite mounted ranged should have a piercing attack and attack bonus against buildings. Tweaking the piercing armor of buildings should be possible so that the 'fire arrows' deal enough damage but normal piercing units don't. Still the higher crush armor for non-siege units would be good because until now 'catapults' can take about 5 times the numbers of melee citizen soldiers, which seams quite unrealistic to me and means they are more cost efficient than normal units and have range and can attack everything. 

  11. Each unit type has a primary counter and a secondary counter (and some have further tertiary counters). What units they are good against can be seen in their tooltips.

    I'll give a good rundown here for everybody:

    Infantry Spearman

    • 2x vs. All Cavalry

    Infantry Swordsman
    • 2x vs. Infantry Spearman
    • 1.5x vs. Infantry Skirmisher
    • 1.5x vs. Elephant

    Infantry Archer

    • 2x vs. Infantry Swordsman
    • 1.5x vs. Cavalry Spearman

    Infantry Skirmisher
    • 1.5x vs. Infantry Spearman
    • 1.5 x vs. Cavalry Archer
    • 1.5x vs. Elephant
    • 1.5x vs. Chariot

    Infantry Slinger

    • 2x vs. Infantry

    Cavalry Spearman
    • 2x vs. Infantry Swordsman
    • 1.5x vs. Infantry Skirmisher
    • 0.5x (attack reduced by 50%) vs. Elephant
    • 0.5x (attack reduced by 50%) vs. Camel
    • 2x vs. Siege

    Cavalry Swordsman

    • 2x vs. Support Unit (Traders, Healers, Female Citizens)
    • 1.5x vs. Infantry Archer
    • 0.5x (attack reduced by 50%) vs. Elephant
    • 0.5x (attack reduced by 50%) vs. Camel
    • 2x vs. Siege

    Cavalry Skirmisher
    • 2x vs. Infantry Archer
    • 1.5x vs. Cavalry Swordsman

    Cavalry Archer

    • 2x vs. Infantry Spearman
    • 1.5x vs. Infantry Swordsman

    Champions and Heroes of the same above types generally have the same bonuses, but with better base stats (attack, armour).
    Siege Rock (Rock Throwers)
    • 2x vs. All Structures

    Siege Bolt (Bolt shooters)

    • 2x vs. Organic units (anything with a mouth and two eyes)

    Siege Ram
    • 2x vs. All Structures
    • 3x vs. Wall Gate

    Siege Tower

    • No bonuses

    Most of the above information can be seen in tooltips in the game.

    Hm... cavalry skirmisher does not only have a very nice resource cost ratio of 2 food, 1 wood 0 metal, they also got no units with dammage bonus against them, are fast and ranged. Only disadvantage: Cannot damage siege weapons well.

    Even worse: Iberians ranged mounted units deal crush damage so they rape sige units as well! And Iberians are not rushable because of there walls so it's quite likely for them to get a fortress to produce these...

  12. Recent changes in misc.js (starting entity placement including civ bonus start walls for Iberians) made me notice that functions are not that perfectly named, organized and written in general (e.g. the order of arguments and the arguments taken at all).

    I added placeCivDefaultEntities(fx, fz, playerid, angle, kwargs) to make starting entity placement suffice Mythos_Ruler's request here (It includes further infos and possibilities for Iberian wall placement as well). That function now (in most maps) replace createStartingPlayerEntities(fx, fz, playerid, civEntities, BUILDING_ANGlE). He added my files to the repository after some discussion but I'd like to exchange some thoughts about that and the rmgen libs in general :gossip:

    I added keyword arguments to the function so edge case usage doesn't require all possible arguments (don't know if that is a usual practice in javascript though) and avoid the need of changing all random maps when a new feature is added (only the libs has to be changed and the maps using the new feature). As you might already have noticed the new function doesn't take the civEntities as an argument (they are got inside the function itself by playerid). That makes the starting entity placement a 'one liner'. In some cases (like used in random map fortress) the civEntities might need to be adjusted though (the number of units or even the unit types). This could now be added as an other keyword argument (but actually isn't). Well, it was somehow unexpectedly added :D (for me it was rather a demo version than something to commit)

    The naming should IMO always start with 'place' if something is actually placed, that's why the different name (and to stay compatible to custom maps maybe out there at least until some ppl agree with the concept I left the old function as was). But in the end there should be only one function for starting entity placement IMO. The placement angle should be a kwarg, too, and default should be the (strangely named) BUILDING_ANGlE IMO.

    So please let me know what you want have changed in the near future so no log-spamming and in the end maybe even unwanted code winds up in Alpha 10...

    Until then I'll further check the default Iberian wall placement function's especially a 'while' loop that caused an out of memory error (infinite looping) in an earlier version when random seeds where much lower/higher then average. I think it's fixed in the actual version but I better check again... :sweatdrop:

    • Like 1
  13. Doesn't look too shabby. I would cut down the number of "gates" to 3 or 4, and make the area the walls enclose a little bigger.

    To reduce the number of gates (entries for now) just reduce the number of corners in rmgen/misc.js line 200. They where set to randInt(5, 10), changed max to 7 so perhaps it's ok already. If you like more corners but less gates tell me so I can drop every 2nd or so (though with 5 corners min. there might be only be 3 gates and them ending up in the woods of the random maps would cause the player to be trapped).

    The default fortress radius should definitely not be larger! Just raise the fortress radius in rmgen/misc.js (iberWallRadius line 193) and load a few maps. There's just not enough space on most. However, I can easily add an additional keyword argument to make the radius adjustable for each map (though I doubt this will be largely used).

    I dug out the old code for more organic looking fortresses and adjusted it a bit. I got the size more stable at the same randomness. Added it and it can be setup in line 203 of rmgen/misc.js. They are closed by a linear wall so not all parts of the wall are bended. I'll try to reduce the length of the linear part further.

    I replaced the entries with gates just to show how it looks. I will change them back before committing ofc. To make them playable just replace 'gate' with 'entry' in rmgen/wall_builder.js line 634 (for irregular polygonal fortresses) and for the others in rmgen/misc.js line 203, 206, 209 and 212.

    Since there are 4 shapes working fine (for me) perhaps the style could be chosen randomly... I'd like that.

    iber_wall_civ_bonus2012-5-4b.zip

    Edit: Since it's already in the SVN repo I assume you like it :D

    It seams you're not a big friend of discussions :laugh:

    However, that was not considered final for me :acute:. There is much debug logging left and if we only want to use one fortress shape the other shape's code (documented out anyways) should be removed from misk.js. IMO. I'll post a cleaner version (only the files to update) later somewhere... ;)

  14. Not really. When we have gates there will need to be towers there anyway. :)

    Here we go...

    iber_wall_civ_bonus2012-5-4.zip

    Best map to test this is the good old "New RMS Test" map.

    Perhaps you might want to play around with the arguments in rmgen/misc.js line 200.

    Or try the other possible fortress types by documenting them in after line 200 (and document out line 200 itself ofc.).

    Concave angles are not supported. I did that before but ran into problems making the last wall entity fit. It would need some tries to get a well fitting fortress and sometimes walls crossed (when random numbers where significant lower than average). In addition it was not really possible to determine the final size of the fortress in any way (only the average size which isn't enough on most random maps). So I abolished that approach. 

  15. Well, here's a start:

    iber_wall_civ_bonus2012-5-3.zip

    I added a new starting unit placement method to rmgen misc and adjusted all random maps to it. Iberians now have walls added to their starting entities automatically. They can be set (e.g. to towers only) for maps where walls doesn't fit by an optional keyword argument so the function can be easily adjusted to any further needs without adjusting all rms again (which sucks). Rms no further need to get the starting entities - the place function does it now.

    I didn't test if the trees caught in the walls cause trouble...

    The fortresses are not randomizes yet but will be.

    Some variation might perhaps be nice (sometimes elliptic, sometimes irregular polygons, ...)

    See the wall_demo rms for some examples.

    Most naval maps only have towers added.

  16. The naming convention that is used for civ building entities ('structures/' + civ + '_' + type with type in [wall_short, wall_medium, wall_long, wall_gate, wall_tower, outpost, fortress]) could be used for palisade entities as well like 'structures/palisades_wall_short', 'structures/palisades_wall_medium', 'structures/palisades_wall_long', 'structures/palisades_wall_gate', 'structures/palisades_wall_tower', 'structures/palisades_outpost', 'structures/palisades_fortress'. This would be nice to have.

  17. To send commands to the game you use

    Engine.PostCommand({"type": "walk", "entities": [this.id()], "x": x, "z": z, "queued": queued});

    The commands are shared with the GUI so your AI can give all of the same commands a player can. See simulation/helpers/commands.js which is where he commands are handled. Alternatively you can read the entity.js file in common-api which is where most commands are sent for AI's.

    In order to train a unit you must first find a structure to train the unit from. The other AI's use functions in gamestate.js which filter the list of entities that the game gives to find the correct entities to train from. The process is similar for finding a worker to construct the building (working out where to put it is quite complicated), then you need to send a repair command to make the unit actually build it (slightly strange, but that is how it works).

    If you look at the existing AI code it should help you figure out how things are done. The demo/test bot is the simplest demonstration.

    Thanks for the reply.

    I'll start with demo bot to get the concept as a whole. Tried with qbot but gave up half the way on.

    I seam to be somehow handicapped in matters of reading foreign code :S

    Was a bit stupid of me to ask for the code I imagine :D

    I'll try harder...

×
×
  • Create New...