Leaderboard

More ideas, Gallic slingers Basic = Undyed clothing Advanced = Dyed clothing + Shield Elite = Dyed clothing + Shield + Cape

Well, here is the rough code I have so far. It achieves what I wanted it to do - large armies can stick together fairly easily without formations as long as they are in an open area, and it does reduce short range pathfinder use in those situations. However, there is still a problem, which is that units can get stuck against static obstructions. I think that may have something to do with the short range pathfinder being too optimistic about being able to walk around static obstacles when the navcells block the way (and the units have been bumped off the long range path by sliding). I'll still be tweaking it to see if I can solve that problem. Meanwhile please give it a try! For the most part this is 2 changes. First, units slide against each other parallel to the path, as I mentioned above. Second, units move in an order determined by their long-range path length - units with shorter paths move first to make room for those behind them, who usually have longer paths. A note - one interesting thing Starcraft II pathfinding does, is allow moving units to push stationary allied units out of the way. It might give a nice aesthetic to try that as well. Another note - this patch is far from polished. "It compiles" is about what can be said for it! Please don't murder me over the coding style, which I'll clean up a bit before submitting on trac if I can fix the units-get-stuck problem. sliding.diff

I want to talk about some problems with pathfinding for large armies and proposed solutions. I would implement these solutions and submit a patch. If you have a big group of units gathered together with no formation, and select them and click for them to move somewhere across the map (or even relatively nearby), two things happen. The units in front start moving immediately, but it takes a long time before the entire group is moving. The group narrows into a single-file column as each unit tries to follow exactly along the planned long-range path. Neither of these things is what the player wants. The army would get to the destination faster if every unit started moving immediately, and it would be more effective once the fighting starts if it stayed together as a clump. The more spread out the army is, the more vulnerable it is. I want to pause here and say that I don't intend to do anything with formations. These changes can be accomplished through individual unit pathfinding alone. I want to compare this to other RTS games such as Starcraft II. In Starcraft II, if you have a clump of units and tell them to move, the entire clump instantly start moving, and stays together as a clump. You can see examples of Starcraft II pathfinding here: https://www.youtube.com/watch?v=x0gSVKVZ4YU. Throughout the video, notice how units stay in tight groups, even as they move around and change direction a lot. If they split up, that's generally because the player manually split them up by telling part of the group to go one way and another part to go another way. Starcraft II has no formations. So how can 0ad work like this? I plan on the following changes. For reference, this is the current pathfinder doc: http://trac.wildfiregames.com/browser/ps/trunk/docs/pathfinder.pdf Add additional information to units giving their expected direction. This is a vector saying where and how fast the unit is probably going to move in the next turn. It doesn't have to be perfect. If you give a unit a walk order, its expected direction would be immediately set to be parallel to the long-range path to the destination. Otherwise, a unit's expected direction would be set to the direction it moved in the previous turn. This information would only be updated once per turn. For the purpose of short-range pathfinding, units ignore units whose expected direction would move away from them fast enough that there is no expected collision during the next turn. This should solve the issue where it takes a long time for a group to get moving because of units treating units in front of them as obstructions. As a side benefit, this would improve performance because the short-range pathfinder would have fewer edges to consider!! After short-range paths have been selected for units, units with short-range paths that are nearly parallel to allied units adjacent to them, should have their paths adjusted to be exactly parallel. This would prevent units from converging into a single-file column over long distances, by keeping a group moving in a parallel direction. A unit is considered to have passed a waypoint (but not a final destination) if the closest point on the long-range path is at or beyond the waypoint. This is necessary in combination with change 3, to keep units from insisting on stepping directly on every waypoint even when other allies who were going in the same direction are in the way. edit: After further examination, I see there's another major reason for why groups of units take a long time to fully start moving. Units ask for a new short term path as soon as they encounter an obstacle, even if the obstacle is moving. Asking for a short term path causes the unit to stop for a bit. You can see this by ordering a cluster of stationary units to move with the speed set to Turtle (0.1x). You can see units freeze in place for a second, waiting for a path, before starting to move in a direction perpendicular to where they were ordered. To fix this, units should keep trying to move for a short period of time if they were obstructed by a moving unit, and only ask for a new path if this doesn't work. This would be in addition to the other changes. As it would result in fewer calls to the pathfinder, this would also improve performance. staticsliding.diff

How hard / difficult would it be to create a template_unit_support for thieves which would be market traders that had one way deduction from an enemies resource? I am trying to determine if this is something which could be completely accomplished outside of the game engine itself (in simulation .js) before attempting. What I think is mainly missing is the ability to be a non-detectible entity, for example one to be used for spying as well (to open the fog of war, etc), so you can not cloak the player color so they are not detected. What I could picture is having an entity like that + the enemy does not realize they are attackable until they hover over them. In this way a thief or spy would be uncovered. I am mainly trying to understand if these 2 entity types would be programmable in the current state or requires alot more development in the engine itself. I can't remember offhand how they worked in AoE but I remember they gave LOS (spying) ...

Can perform a sabotage in production building for a while.

Could make thieves as well able to garison in a building and steal some resources The concept is rather simple. The unit appears as a standard villager most of the time, except when it garisons into a building, steal resources and after a short time, gets out. then it's a thief.

Rather than simply making spies or thieves invisible - wouldn't it be much cooler if the spies could disguise themselves as enemy civilian-soldiers? Maybe something like http://wiki.teamliquid.net/starcraft2/Changeling_(Legacy_of_the_Void) . It could work like this: the player produces the spy and sends him towards the enemy. When the spy sees an enemy civ-soldier, it automatically changes allegiance to the enemy and takes on the appearance of the enemy soldier, so it is actually an enemy unit now, able to blend in by e.g. gathering resources. The spy remembers its former allegiance however, so the player who produced the spy can also give it orders and see what it sees. As soon as the spy changes allegiance, its stamina starts to decrease, and when the stamina reaches 0 (after several minutes) the spy changes back to a spy and will be targeted by enemy units. The enemy player could also select the spy and delete it, if he notices. If the spy escapes, he has to wait until his stamina reaches full before he can go undercover again. Thieves could work the same way except that they have a tiny vision range while converted to the enemy (spies should have a large vision range), and when thieves return resources to an enemy dropsite, they actually decrease the amount of that resource for the enemy. Before a thief's stamina runs out, he should be able to steal several times his cost in resources if the enemy player doesn't notice. There could also be "assassins" which work like spies, except that after having been undercover for a while (stamina below a threshold), the player who produced the assassin can order it to attack an enemy unit with a melee attack. If the melee attack connects, the enemy unit instantly dies and the spy is unmasked (stamina set to 0). Assassins should be pretty expensive, like 200 metal 200 food, to counterbalance the fact that they can kill heroes.

You might need to reenable stamina though. I had a working patch somewhere on trac for that. Gonna need some tweaks though cause some references where deleted by @sanderd17 recently Edit: r18002 did that and http://trac.wildfiregames.com/ticket/3468 contains an old patch that should apply prior to that.

@Enrique what do you think of wackyserious' textures ? Here is some other stuff for differentiation taken from this topic last is from @wackyserious You can find higher resolution of celt textures there art_source\trunk\art\textures\skins\skeletal\old

The Britons will use the current slinger actor file, while the Gauls can have something similar to the image above.

Actually it isn't even necessary, now that Visibility is a scripted component. You can take a look at this patch for a example of how to do that, just take a look at the change to Visibility.js and at the new Stealth component. The patch lacks disabling the range queries though, so it might be a bit broken. It is an old POC patch anyways

It wouldn't be that hard to make a unit invisible, though that will probably require a small change in the C++ part of the simulation. The hardest part is the game mechanics around it, like sending a "make visible" command on hovering, disabling reactions of units and buildings on invisible units, AI support, ...

Soldiers can be seen on their ships in this case like the marines in 300 (2) and also that you could see the archers on the ships fireing