Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 2012-05-05 in all areas

  1. These features would be nice, if you were on a map with islands, so once you have destroyed the enemy, tidying them up after is easier =p the scouting option would be good too. Also UPnP would be good, because on older routers with no port mapping functionality the games multiplayer function would work and it saves the hassle of mapping ports in the first place.
    1 point
  2. I need someone with some time on their hands and who has an up-to-date SVN copy of the game top help out with some map design stuff. It might be tedious or it might not be. Point is though you help add something to the game. Basically, we might be giving the Iberians an interesting bonus: Essentially, the Iberians would start every match with a prefab circuit of walls as one of their civ bonuses. So, what I need is someone to go through the maps in SVN and add a circuit of walls around the Iberian starting point. I have already done about 3 different maps, but there are a bunch more. All you'd have to do is look at the maps I've already done and do all the other maps where applicable (for the Iberians only). The circuits should be organic looking, not a big square or circle. Just approximate what I've already done on the other maps. Anyone up for the challenge? Could let multiple people claim different maps. Attached are a few examples of that I'm talking about to make things clearer.
    1 point
  3. Sometimes grammar is relevant "Were originally" and "were not intended" Now palisades are included and will continue to be so.
    1 point
  4. Not bad. I wish they had towers at the "gates" and the wall layout wasn't so geometrical. See the Oasis 10 map for example.
    1 point
  5. Palisades were originally just a side project I was working on for my own personal enjoyment and were not intended for their current usage, hence the weird naming.
    1 point
  6. please, remember to let the player set the default stance for new units at the options menu, it's very useful.
    1 point
  7. The 'standard' X wall length that almost all walls use is 6 Blender units. When using Imperial measurements with a Blender unit scale of 0.0254 this makes the X length 6 inches (and therefore 6X is 1 Yard or 36 inches). Using Metric measurements with a scale of 1.0 the X length is 6 metres. The box above is the standard X length and the Dimensions are shown as Blender units If this is true, it makes me happy Carthaginian Walls are 0.2 longer than the standard X length and therefore 1X is 7.2 units I can't remember what I used for Palisades
    1 point
  8. The wall towers are at least X in diameter and provide us with the X value that then decides what length the wall segments are. 2 wall towers placed beside each other are therefore 2X - If a small gap appears between the wall towers a small wall (2X in length) can fit between the 2 wall towers without protruding but still allow for a longer wall to be created up to 4X in length with the wall towers at either end. The medium wall is 4X in length and the long wall and gate are 6X in length. If you want to try your system, there are over 40 models that you will need to remodel to match your dimensions
    1 point
  9. 1 point
  10. Have been tired (remnants of a cold + lots of pollen in the air doesn't make things better =) ) and fairly busy the last couple of days, but now here's my reply True But it wouldn't be as versatile, it would just be a search and destroy thing =) But it's probably best to implement it as one in either case Hmm, this is probably the hardest part. We can't give the UnitAI too much power because that would lessen the role of the player (and it's probably hard to make sure it makes the correct choices in all cases), but on the other hand we should remove things which are just tedious micromanagement without any strategical value. It's hard to decide exactly where to draw the line imho. Yeah, attack-move interfering with stances (or stances interfering with it rather I guess =) ) doesn't sound too good
    1 point
  11. Actually, personally I guess it's mostly the Stand ground stance I want to avoid having ranged units moving around too much/getting in harms way =) Michael probably has bigger expectations for them/greater motivation for them being there, so I'll let him comment on that. (I write a bit more later, but am too tired to combine the answer to this question with my point below Hope you still is able to read it all and see the arguments further down ) Hmm, we're talking about the same thing with different words It's the current behavior of the units moving together to shape a specific form that I meant with (as opposed to actually have some effect of them moving around next to each other apart from them looking nice and orderly) I guess I could have been clearer. In either case my point was exactly what you said above about the formations currently only being a visual thing Currently formations only "work" for movement (and the only way to move groups of units is to move them as a formation, which does make sense in many cases, but not when you want scattered units to get away from danger asap =) ). If we're able to implement formations in a useful way though the units will fight in/as a formation and not be scattered unless the formation breaks. We'll have to see exactly how formations end up being implemented, but one thing that has been suggested is for them to work like "if you put a group of units into formation they will essentially be as one big/wide unit, moving together, taking damage together, dealing damage together, and not break up unless either the user breaks up the formation or enough of them get killed that they're too few to be a formation so they get scattered as individual units".There is a "scatter" formation (might use another word, I'm too tired right now to check exactly what it is, might be loose ), which currently doesn't seem to do what you suggest (just move the units around a random distance apart from each other, but in all other regards work as an ordinary formation), but that could be changed to work like what you suggest, or something similar, where the units move together, but aren't set up in a predefined shape but rather just moving near each other to the same goal. Hmm, partly we're getting into a philosophical discussion here "What is a player order, and how do you define it in a way that includes all possible situations?" I do think there is a slight point to it though, so I'll continue. =) Well, at an abstract/higher level it was a player order to "search and destroy", but if you break it down into smaller move and attack orders the individual move/attack orders are automatic (you didn't order the unit to move from point A to point B, to point C, etc, you didn't order it to attack the enemy soldiers it encountered while it moved from point X to point Z, etc). If you just want the units to always move around and attack anything they come near (i.e. a search and destroy command), the definition really is pretty moot. However, if there isn't a pure search-and-destroy action, but rather a search and destroy effect from using an auto explore mode together with an aggressive stance there is some merit to make a distinction as it then is just that, automatic behavior defined by the stances you've set. (I'm not saying it's the best way to implement it, and you're probably right that at least from a user point of view it's easiest if there is a search and destroy command as you don't have to understand the different combinations but rather can just click a button and the units do the job for you. As it'd mostly be useful in late game for hunting down individual units it would be fine to implement it in this way, so my main point with the rest of this discussion is to discuss stances in general, not as part of a way to implement a search and destroy feature ) I guess you're right about not interacting with player given orders, not sure where I got move orders from I don't think it's possible to create a unit AI that can handle all situations good enough, mostly because it cannot know what your plans are. (And here comes some deeper/better arguments for stances as a whole than above ) You might be gathering up your troops for a big assault on your enemy, but a few scattered enemies come close. Now, what is the best way for your units to behave? If just judging from the perspective of these unit (which is all UnitAI is capable of, unless you hook up a proper AI to it, in which case you could just as well just watch two AIs fight ) it's probably best to all-out assault the enemies and destroy them completely, even if that means moving far away from the original point. In this case a defensive stance where they would attack the enemies if they get too close, but not move far away; a stand ground stance where only ranged units can attack unless the enemy walks right up to your units; or a passive stance where they don't do anything, probably would be best as they (depending on the exact stance) can defend themselves, but won't move away from the place you placed them. In another case you might be near your enemy, but don't want to provoke the enemy units to attack yet as you don't have enough units. The enemy units might be just out of sight of your units most of the time, but moving around gathering resources etc, and the enemy player hasn't paid any attention to your units yet (say you have units with greater LOS or he just hasn't looked at that part of the map for a while, either way once his units are attacked he will get a notification and will be aware your units are near). In this case it could be fatal to have your units attack the enemy units before you has had the chance to move more troops there to make a greater assault at a time, so you place your units in passive stance where they don't attack. A short while later your main force is near and you order the mass of ranged units to attack the unsuspecting enemy (a direct player order should of course override the passive stance and while the units attack you can change to e.g. aggressive, or defensive if you don't want your units to move too close to the towers the enemy has built closer towards the center of his camp, but not yet near his resource gatherers where you attack). Or you might be in the middle of a battle and want to have your ranged units keep attacking any enemy getting close enough too get within range, but not move closer (especially not past the protection of your melee units) and get killed by the enemy units, nor move further away and not be able to attack units that get closer, you put them in stand ground mode and they stay where you put them. Etc, etc. My point is that I seriously doubt that a completely automatic system would be able to handle all possible cases/human plans. Take for example the last situation, maybe it's possible to create a system that can take care of the ranged units well enough to do that, but you might want them to be more aggressive and attack the enemy at closer range even though it means an almost certain death of them. Perhaps because you want to fool the other player that you're a beginner or desperate, while in fact you're just making him focus his attention on this fight while you're moving in another, larger, force from another direction/in another place where he doesn't expect it. A stances system is a way to give the player more control over how his units behave rather than less (though it currently works in the opposite way as stances takes priority over player orders, something I don't think they should ), by making it possible for the player to tell how the units should behave when idle. Not sure exactly what you're asking for here Are you talking about what you mentioned in the first sentence here or something else? If so I don't think it should be a part of stances at all, but rather of a more basic priorities system, something like: "a direct player order takes highest priority, even if it would be more logical from other code to attack a nearby unit it would still attack another unit further away (it's a bit hard to decide what the units should do if you've given them a direct order to attack - or for non-siege later capture - a building, but units start to attack them, should they continue to focus on the building - direct player order - or respond to the enemies - direct threat?); next comes units attacking it; later nearby enemy units, later still enemy units further away but still within range/LOS. Apart from that there should be another priorities system so e.g. melee never attacks ranged units (unless by direct player order), cavalry prioritizes ranged infantry, ranged infantry prioritizes enemy melee infantry. And apart from that there should be the stances which should define e.g. whether the units follow enemy units far away or not, whether they stand still even while attacked etc. In other words, even if set to aggressive units should still attack an enemy unit they have a greater chance to defeat, the stances should just define e.g. how far they pursue them/whether they attack at all. (Phew, that was a lot of text, hope it all makes sense. I hope I haven't left any unfinished sentences/points somewhere, if so I blame them on being tired and ask that you'll require me to explain myself tomorrow )
    1 point
  12. I think auto explore/search and destroy should be continued after units auto attacked something due to an offensive stance. Yeah, but that's not a player order But rather an automatic order from the explore/search-and-destroy system My point was rather that player orders would not have to be taken into consideration for the auto explore/S&D system Something like this yeah =) But player influence is the issue here =) I do think it's nice to retain some of that though, but the final implementation of formations is likely to be a bit more like that. Right now formations is more like "these units move around kinda close to each other" and doesn't provide much benefit/effect of any sort. Either way I think at least part of the problem (apart from the absence of a priorities system - that would prioritize direct player orders over stance effects etc) is that melee infantry is too fast =) At least as far as I understand it, historically speaking melee infantry shouldn't really be able to even get close to moving ranged infantry (apart from the units which are both melee/ranged), but rather have enough armor to withstand quite a few ranged attacks, to hunt down ranged infantry cavalry should be used. I would say all player orders apart from move orders should completely ignore stances (even if they include moving to e.g. a building to garrison there). Maybe. Most of the time they should run to cover though, and melee units shouldn't be much use in fighting them in the first place. =) Perhaps a (minor/part of a) fix for the issues would be to make them less likely to turn to move again, i.e. run to max range, stay and attack until the enemy gets into min range, rinse and repeat It should not try to attack the archer So there we agree for sure That depends on how the groups/formations are implemented, currently they're explicitly tied to each other and a move order for a group of unit first means they have to form up into formation (and it would probably be a pain to have the formation system try to find out whether there are enemy units nearby and thus have the formation form up later). For most cases it should work fine though, so perhaps it would be wiser to add a "flee" command, where they would move directly to a safe spot? (Probably easiest to have the user set a spot rather than the game trying to find out where it's safe to go =) ) This should be fixed yeah It should be independent on unit behavior in terms of implementation, but either way, there's no reason it can't wait until unit behavior has been improved I'm trying to discuss the final behavior, not how things are now (And I'm probably confusing myself over all the replies so if something is unclear blame it on me and ask what I mean rather than assume I mean something weird )
    1 point
  13. There's no reason to complain about the future of a feature based on the present of another =) That said, perhaps implementing it separately might be easier. However, we already have stances, so however search and destroy/auto-explore is implemented it will have to take them into account in one way or another (if only to ignore them ). Search-and-destroy/auto-explore shouldn't need to take player orders into account as they should cancel out previous orders and later orders should cancel search-and-destroy/auto-explore. I wouldn't call it different behaviour for different unit types (most of it at least), part should be user controlled (you should never try and use infantry to catch up with cavalry for example), part should be things like ranges. And the part which is behaviour would have to be fixed for normal stances use anyway Hmm, looking at your comment again I guess you might have been talking about stances apart from search-and-destroy/auto-explore all the time Ah well, either way, I still think there is a value for stances. I think there might be reason to differentiate melee infantry/ranged infantry/cavalry speed even more though running should change a bit once we have it, that way cavalry should be able to get close enough to fleeing infantry units etc. And I don't think the unit type issues are mostly related to stances anyway. Perhaps part of the issue is that we try to have units be too exact? I.e. if archers would fire even if it's not 100% sure they would hit their target it's probably more likely they will actually hit something than if they're moving around to get to where they'd perfectly hit the unit they're trying to hit. Either way I'm almost starting to lean towards Michaels old pet idea of using battalions for everything =) Most of the unit behavior issues seems to stem from the the way individual units interact
    1 point
  14. Maybe this can be implemented just as 'explore' command affected by the stance system. I.e. when unit is exploring and have 'ignore enemies' stance ('standground' or whatever it called) it is just exploring; but if it explore and have more aggressive stance it should try to kill all enemies which it see and then proceed exploring if survived.
    1 point
  15. +1 Can be annoying for very large maps to have to follow a cavalry unit in order to find the remaining enemy workers.
    1 point
  16. As long as it works for most maps, and then on the maps where it doesn't work we give them some defense towers, I think is more than acceptable.
    1 point
  17. This wall won't work for some of the random maps. The ones with "natural" barriers like bodies of sea and cliffs (e.g. archipelago, cantabrian highlands, etc.). For those maps, some towers would suffice. Or it'd be a pain to create different shapes of walls for every random map.
    1 point
  18. Yeah, there would probably have to be something added to the rmgen folder so all random maps could take advantage of the Iberian wall bonus properly without having to duplicate the code.
    1 point
  19. Walls are very likely to get an overhaul in the next couple of months for implementing a wall building system for the user. It's good that you offer your input from the RMS point of view though, so all things are taken into consideration
    1 point
  20. This is looking and working really well FeXoR. Great stuff
    1 point
  21. Hmm, the Iberians do have a wall tower like all the other civilizations. So I'm not sure what you mean by that (Also, if you're using SVN there are Roman walls and wall towers as well =) But that's up to you, it is definitely recommended to use the SVN version for any kind of development though )
    1 point
  22. Nice work Fexor, that is great. Neat shapes How do the scripts do if you ran it on a map that wasn't flat?
    1 point
  23. This reminds me that we really need to redesign GUI for more rms options.
    1 point
  24. This would be useful to create "Fortress" variations of random maps.
    1 point
  25. Excellent work The larger wall could work very well around starting bases, while the smaller ones could surround pre-built fortresses or towers.
    1 point
  26. Let's imagine it: You're a spearman on the frontline, druing a battle. There are horsemen coming, you have to stand firmly against the impact that, you know for sure, will be heavy. The horsemen come, some horses refuse to throw themselves into the spears, some die, some trample the spearmen. This is formation breaking by trampling. But, just to be sure you guys remember, there were also formation breaking by low morale (some soldiers simply flee in fear of dying) that played important roles in the outcome of some roman battles, for a sample. There is, also, the 'surprise element', ambushes may scatter the units. Surrounding and attacking by behind contribute for some casualties, so the side the formation is facing is also important. I know it's not a thing to think about now, it's just too early, but, as a programmer, i know things need to be thought of before starting to implement. And even if it won't be implemented in 0 AD, who knows the future? Maybe in 1 AD...
    1 point
  27. I think it would be cool to be able to set the 'default' stances of different types of units even before a match. You could even save these under different presets. Call them "Play Styles" and bundle them with other pre-configurable things too, like hotkey sets, etc.
    1 point
  28. Any chance of getting stances for siege units, in particular telling them to stand still?
    1 point
  29. I prefer to keep the C++ interfaces simple, since that makes them easier to understand and to maintain, and then put the logic in the scripts since they're more flexible. Whenever you do anything with entity positions you have to check for e.g. !IsInWorld() and then respond in some appropriate way, and it's usually easier for the script to decide how to react than the C++ (since only the script knows the context in which it's running - maybe it will ignore the target, or maybe it will have remembered the last known position, or something). So I'd prefer not to pass entity IDs into C++ unless it's either necessary or hugely more convenient. If it's a script that needs to know the distance, it's probably better to have the script do the computation (to keep the C++ interfaces simple; performance won't matter), and it should probably go in a new file in helpers/ since other code might want to use it (e.g. Attack.js already does some computing distances between units). Probably not with any accuracy at all. If you build in Debug mode then the F11 profiler should show script functions, but it disables the JIT so it's very unrepresentative. Alternatively you can do Engine.ProfileStart("some name") / Engine.ProfileStop() to explicitly add a region to the profiler tree (it'll be somewhere in the 'simulation update' branch, I think), though the profiler has some cost itself so it'll distort the results if you're timing very short intervals.
    1 point
  30. Nice guide(s) More info: http://trac.wildfiregames.com/wiki/XML.Entity.Traits.AI
    1 point
  31. 2 things: In defensive mode, have units stop pursuing enemies once they exit the 10-tile radius. If they pursue them into the SoD, you may find a defensive unit wandering around the map if they're faster than the unit they're pursuing. In passive mode, units should still respond to being attacked. If they just stand there and let themselves be killed, there is no purpose to this stance.
    1 point
×
×
  • Create New...