MegaGlest Forum
Archives (read only) => Glest Advanced Engine => General discussion => Topic started by: Little Helper on 28 February 2010, 01:56:05
-
Is it possible to create a unit formation in glest? Its an Idea!
-
Yeah, I thought about that too...
It's actually a bit annoying that you can pack 16 units in whichever way you want but... onece you get it moving... it's all scr**d up!
Some command like:
* "keep formation" (even when moving). Slowing down all units's speed to that of the slowest unit would help. But of course, narrow passages would naturally break the formation so... Whether this "keep formation" was used or not, you could always implement the following commands:
* "Mark formation" and "Return to formation" which I think are self-explanatory.
Should a ticket be opened? Or was it already?... ;D
P.s.: Was something like this you were thinking of, Little Helper?...
-
Yes thats was one of my issue ::)
-
P.s.: Was something like this you were thinking of, Little Helper?...
Yes its identical of what I was thinking ;)
-
@ The GAE developpers / anyone who'd actually know:
Is the following ticket related?
Ticket #8: Cooperative A* (http://sourceforge.net/apps/trac/glestae/ticket/8)
If so, would it be possible to push it a bit forward (I understand the A* had been suspended til upcoming 0.2.13 and may still be unstable)?
-
Having unit formations make glest more strategic!!!
-
Yeah, this would be great if it was implemented. Or if somehow it already is... ::) :P
-
Is the following ticket related?
Ticket #8: Cooperative A* (http://sourceforge.net/apps/trac/glestae/ticket/8)
If so, would it be possible to push it a bit forward (I understand the A* had been suspended til upcoming 0.2.13 and may still be unstable)?
On cooperative A*:
No, cooperative A* will just make units move more intelligently in congestion, they will take into account where other units are, and where they will be in the future.
On A*
A* is/was already in GAE 0.2.12. It is 'switched off' by default because it is too slow to be used with a sufficiently high node limit, but can be enabled from the options menu. 0.2.13 adds hierachical A*, and has no node limit and no performance problems, the old algorithm has been removed.
On Formations:
I sat down and spent an hour or two with some graph paper trying to figure out how this might be doable some time ago. I didn't come up with anything good. It may be possible to do by treating several units as one larger unit, but even this would I think have some problems. Glest's grid constrained movement doesn't lend itself well to this feature :(
-
Type of formations:
4x4 formations?
A:
x
x x
x x
x x
B:
x x x x
C:
x x x x
x x x x
x x x x
-
Some RTS games solved this by making it not "move in formation" but "move to position X in the formation". So when the move command is being "aimed", the player sees a series of indicators that show where the units will end up - as a formation. From there the engine just passes individual move commands on to the units simultaneously.
In an open field this results in a sorta formation move.
-
Some RTS games solved this by making it not "move in formation" but "move to position X in the formation". So when the move command is being "aimed", the player sees a series of indicators that show where the units will end up - as a formation. From there the engine just passes individual move commands on to the units simultaneously.
In an open field this results in a sorta formation move.
A true formation move would of course be better but unless your squad is going to be ambushed on it's way to location X it's not a problem.
-
Of course, with pathfinding you hqve to be careful using this method. What can happen is any units "in front" will start walking forward - but the units behind them will try to walk around them right away. It's b/c the pathfinding generates a "walk around that unit to reach your goal" - even though that unit won't be there in a moment.
As mentioned above, better pathfinding options can eliminate this. True formation movement would also.
-
Ok, trying to "solve" a bit of the puzzle of what was said here and expanding on my thoughts...
Type of formations:
4x4 formations?
A:
x
x x
x x
x x
B:
x x x x
C:
x x x x
x x x x
x x x x
I actually had thought of that too. Namely on a faction-specific rule. E.g. Romans or Greeks would have several different kinds of formations to choose from (that tactical strength was one of both armies' biggest advantages), say three to four (square, "triangle" (not sure what the word for it is in English, two flanks, circle, ...). Now Barbarians would have no formation at all or maybe just one like "circle" (and this is where the ideas I presented earlier came from, Barbarians (or other not so tactical army, would always move around scattered, but they would be able to regroup in a circle).
But that's not what I was talking about. Apparently, it was in Little Helper's mind. Ok, he did start this thread but he also agreed my ideas were part of his meaning so... I'll just focus on what I said before, even more so because those fixed-shape formations would, in my view, need the rest to actually work so...
My proposed "commands" were:
- Keep formation
- Mark formation
- Return to formation
Now, the "keep formation" would actually need the later too already coded (if not as a user-command, at the very least as an internal sub-routine) so... (yes, I've been thinking this in reverse... "top-down"). So let's start at the begining, the "bottom":
Mark formation and Return to formation:
Mark formation #1
+ You can already select a group of up to 16 whatever units you have.
+ You can give a command to all the units in this group that will be executed by each one individually (the same command).
Return to formation
+ The relative geographical positions of each unit in the group are already "memorized" by the engine - if you give the "Move" command to the group and they are moving on open leveled-out terrain, they will reach the final destination in the "formation" (relative geographical positions to each other) they were on departure. Provided you do not change the destination while they are still moving (which will "mark" a new formation)!
- If there are obstacles in the way, different paths with uneven terrain-levels for each unit's (I think!!!), possibly something else, the formation on departure will not be
exactly the same on arrival. This is where the Return to Formation command (internally or user/AI deployed) would become useful! ;)
+ The engine already allows you to center on the "major sub-group" of a numbered group (numbered through the Control + # shortcut) by pressing the group-number twice (or the Space key in vanilla glest).
+ By "major sub-group" I mean the largest group of units that can fit in a normal camera view range (for what I've seen ingame, I believe this is how it works, it looks for the biggest sub-group of units of that group-number that fits in a standard view and moves the center of the view to the median of that sub-group units' positions). Hence, we have the position around which we will make the units return to formation!
Mark Formation #2
* Now, in order to execute the Return to Formation command, we just need the original relative positions of the units (formation) to their point of departure's center.
+ We had this point of departure before we issued the Move command. The center was the same we would have gotten if we had the group number-marked and we pressed that number twice (as above for the point of arrival)
* We need this point (group center) for later use. This is first step of Mark Formation command.
* We need to remember the relative positions of each unit (including those not on the standard view screen), direction and distance (or x,y if applicable), to the above mentioned group center.
Return to Formation #2
* We set the new center to the center of the largest group on destination (or even on the move! But let's not think of this now...) and set the destination position of every unit in the group to be the same relative to the new center (direction and distance or x,y) it was to the center marked earlier.
Voila! Mark Formation and Return to Formation implemented! (erm, in theory! ;D)
Some RTS games solved this by making it not "move in formation" but "move to position X in the formation". So when the move command is being "aimed", the player sees a series of indicators that show where the units will end up - as a formation. From there the engine just passes individual move commands on to the units simultaneously.
In an open field this results in a sorta formation move.
The above is my view, based on what I think I know about the Glest/GAE engine, on how to implement exactly that in GAE. ;D
As I said, it could be implemented internally (as the standard group move) or be issued by the player (human or AI). I dunno, maybe some people got used to the current behaviour and found ways to take advantage of it...? (different unit speeds, ...).
Of course, to be player-issued, the AI would have to be told how (using variables such as different move speeds, attack ranges, sight, unit eficiency/cost etc, possibly to make a one direction formation (front to back) or more (something like outside to inside or something) taking into acount stuff like whether the AI knows the direction the foe is expected to be encountered) and when (when moving to attack, when moving through unexplored terrain (related to SoD))...
On Formations:
I sat down and spent an hour or two with some graph paper trying to figure out how this might be doable some time ago. I didn't come up with anything good. It may be possible to do by treating several units as one larger unit, but even this would I think have some problems. Glest's grid constrained movement doesn't lend itself well to this feature :(
Does any of the above I said help regarding the grid constrained movement? Did you mean it is constrained to an x,y grid? Does it help to set the units' positions relative to the group center in a x,y coordinate? :-\
I believe these two commands/functions alone would be very helpful in playing formations. ;)
Keep Formation
- Obstacles and terrain levels will break the formation.
+* You could use Mark Formation and Return to Formation (automatic or user issued) to well, return to formation once back on open-enough terrain... (for automatic use: Pathfinding permiting... ;D)
- Different speeds for different units may break formations a lot, specially on long "walks".
* Sollution for the above speeds problem: when moving in formation, make every unit in the group move only as fast as the slowest unit in the group! ;)
- Air units and land units in a group: reducing speed will not solve...
*? For air units: Mark F. and Return to F?... ;D Might add a periodic check to see if we can / whether it's worth to return to formation, even if temporarily.
- Regarding:Of course, with pathfinding you hqve to be careful using this method. What can happen is any units "in front" will start walking forward - but the units behind them will try to walk around them right away. It's b/c the pathfinding generates a "walk around that unit to reach your goal" - even though that unit won't be there in a moment.
As mentioned above, better pathfinding options can eliminate this. True formation movement would also.
+? Won't this here bellow help, once implemented?
On cooperative A*:
No, cooperative A* will just make units move more intelligently in congestion, they will take into account where other units are, and where they will be in the future.
I think that, to implement formation designs such as Little Helper posted and I discussed a bit above, you would need to have those three commands/funcionts above implemented, as automatic (from as soon as you'd selected a formation).
-
Its not just a big problem to move formations!
Another serious problem is to make the AI use this formations in an effectice way! I think this is the real problem for most new ideas :(
Other nice faetures "affected" by this problems are:
Walls and their handling
Water units ( ships )
Transport units.
...
Even existing defensive buildings like towers or beehives are often used in a wrong way by the AI!
-
It sounds to me like the AI needs an overhaul before a lot of other features become worthwhile.
-
Its not just a big problem to move formations!
Another serious problem is to make the AI use this formations in an effectice way! I think this is the real problem for most new ideas :(
Other nice faetures "affected" by this problems are:
Walls and their handling
Water units ( ships )
Transport units.
...
Even existing defensive buildings like towers or beehives are often used in a wrong way by the AI!
WHAT THERE CAN BE WATER UNIT?
-
Yes, water units are already capable in GAE.
-
Its not just a big problem to move formations!
Another serious problem is to make the AI use this formations in an effectice way! I think this is the real problem for most new ideas :(
Other nice faetures "affected" by this problems are:
Walls and their handling
Water units ( ships )
Transport units.
...
Even existing defensive buildings like towers or beehives are often used in a wrong way by the AI!
Goddarn dumb AI! >:(
Erm, could you not fix it, titi? I mean, you did do two new AI's... ;)
Yes, water units are AKAIK completely funcional (three new fields besides land and air: amphibious, shalow water and deep water if I'm not mistaken...) since GAE 0.2.12 (I think).
But I didn't actually get to see a mod that uses it ... yet. ;)
-
Whats the xml code for the field type?
-
Whats the xml code for the field type?
See the 0.2.12b thread. It includes discussion of the then novel feature. ;) That's to look at from page ONE. :P
Hint: for normal Glest, it's:
<fields> <!-- Where is it considered to be for purposes of being attacked;
land weapons can attack land, etcetera -->
<field value="land" />
<field value="air" />
</fields>
This is actually from GAE's Unit XML page on the wikia (https://docs.megaglest.org/GAE/Unit_XML). But it's outdated, does not reference the new water fields. :(
-
Why does AI have to be the deciding factor when implementing a new feature? Make the new feature first so it can be used in mods and when playing against other humans, then expand the AI to support it properly once the details of the feature are sorted out. The AI can't possibly be expanded to automatically support every new feature that comes along, which means that the AI needs to be modified every time someone tries to add to the game anyway.
-
In my (humble) opinion, unit formations would be best suited to be like AoE2, where you chose from 4 popular formations, except here we'd choose from 'x' formations, where at least one is to have NO formation (the current default).
I liked that aproach in AoE, and it would probably suit Glest well. Basically, they 'loosely' follow that formation, which seems to be recalculated every time you click a location/target.
-
For formations, AoE arranges the units according to classifications like archer, infantry, cavalry, artillery, etc. We'd probably need a similar system for Glest. I have kind of a big idea of how this might work, but there's a lot more to it than just formations.
-
@zombiepirate:
Glest is not a real multiplayer game up to now! I have the feeling its only me and my sons and softcoder with his sons who play multiplayer regulary! And the latest GAE version is the first one with some sort of a playable multiplayer mode!
I think as long as multiplayer is not very popular indeed the AI player is the most important thing for glest! Even in network games we often play coop games vs the CPU!
So I don't want any feature that the AI doesn't use yet. If glest gaming changes to multiplayer ( lots of players, Masterserver ....) I will surely change my mind on this, but at the moment I think its a bad idea to add things that are not used by the AI.
-
@zombiepirate:
Glest is not a real multiplayer game up to now! I have the feeling its only me and my sons and softcoder with his sons who play multiplayer regulary! And the latest GAE version is the first one with some sort of a playable multiplayer mode!
I think as long as multiplayer is not very popular indeed the AI player is the most important thing for glest! Even in network games we often play coop games vs the CPU!
So I don't want any feature that the AI doesn't use yet. If glest gaming changes to multiplayer ( lots of players, Masterserver ....) I will surely change my mind on this, but at the moment I think its a bad idea to add things that are not used by the AI.
Fair enough. However, in my experience with RTS games AI rarely uses features to their full effect, and sometimes there isn't even a point in what the AI does. For example, many AIs build multiple buildings for research or only send one or two units at a time in a transport unit when they have more units to move.
-
I agree with the point that the AI will probably have to be updated as we go, in order to keep up with new features, but I think currently it doesn't even properly use the features we already have, so maybe an AI update is in order.
-
for unit formations you probally have to group up the units up to four in order to make the formations I guess..
-
I agree with the point that the AI will probably have to be updated as we go, in order to keep up with new features, but I think currently it doesn't even properly use the features we already have, so maybe an AI update is in order.
I agree. If the AI is outdated (regarding other features already implemented for humans), then updating the AI should be done before implementing a new feature such as this one.
And yes, the AI does have a lot to learn:
- if an unit has two different attacks that hit the same field, the AI will always use only one. AI should use the best attack it has in every situation (e.g. ranged but weaker attack when enemy is farther away, switching to stronger melle attack when enemy is right in front)
- when there a faction has two different kinds of resource-gathering units, the AI will produce and use only one - shoudl be able to determine the best one to produce/use in each case and do it.
- etc
BTW I think there are open tickets for these former two.
@ Little Helper: I don't think that would help. You can already group units up to 16. So I guess it would be just as easy as to make formations with 16 as with 4.
-
<OT>
The AI definitely needs work, and it's gonna get it. But a good AI that can 'think for itself' is going to be difficult to build and take a long time to get right (Game AI is not easy, RTS game AI is not even remotely easy).
In the mean time, the current (C++) AI interface I believe can and should be exposed to Lua, which I'm confident will be fast enough (with some slight changes to the way the AI currently works)
Then the more traditional scripted AIs (for specific factions) can be developed, and hopefully by a wider audience than the current C++ interface appeals to ;)
</OT>
I've nothing on-topic to say, sorry... just doesn't seem feasible with Glest's mechanics.
-
The OT part sounds good to me. :)