#13 closed enhancement (fixed)
[PATCH] Formations
Reported by: | Stuart Walpole | Owned by: | Badmadblacksad |
---|---|---|---|
Priority: | Should Have | Milestone: | Alpha 5 |
Component: | Core engine | Keywords: | |
Cc: | Badmadblacksad | Patch: |
Description (last modified by )
- Allow running
- (Requires better pathfinding): attacking, and switching between formation shapes on goto.
- Redirection angle and "take closest position"
- Formations can grant units unique idle, ready, and attack animations.
- Formations will require a flag in the cell that triggers special animations for a unit in a particular location of that formation. See special formation such as these:
Attachments (4)
Change History (30)
comment:1 by , 18 years ago
Description: | modified (diff) |
---|
comment:2 by , 16 years ago
Description: | modified (diff) |
---|
comment:3 by , 14 years ago
Owner: | set to |
---|
comment:4 by , 14 years ago
comment:6 by , 14 years ago
Milestone: | → Backlog |
---|
comment:7 by , 14 years ago
Owner: | removed |
---|
comment:8 by , 13 years ago
Milestone: | Backlog → Alpha 4 |
---|
comment:9 by , 13 years ago
Type: | task → enhancement |
---|
comment:10 by , 13 years ago
Milestone: | Alpha 4 → Alpha 5 |
---|
by , 13 years ago
Attachment: | diffFormation-15-02-2010.patch added |
---|
comment:11 by , 13 years ago
Keywords: | review added |
---|
Hi. the patch is a fast attempt to handle formations. waiting feedback to pursue, or not.
comment:12 by , 13 years ago
Milestone: | Alpha 5 → Alpha 4 |
---|---|
Summary: | Formations → [PATCH] Formations |
comment:13 by , 13 years ago
Hmm, I'm not currently convinced that defining formations in JSON(/XML/etc) is a great way to go, compared to defining them algorithmically in JS. The JSON seems quite verbose and error-prone when it supports a large number of units (with all the explicit slot ordering), and seems inflexible.
I expect it's typically better for unit classes to be used as priorities, not as rigid requirements, so e.g. all your melee units will go towards the front and all your ranged units towards the back regardless of how many of each you have (even if you have zero of some). We might hypothetically have some units that need to take up an unusually large space in the formation (elephants, siege equipment, etc) and they wouldn't really work in the current slot-matrix model. We might want formation shapes that aren't grid-based, and/or that aren't filled up incrementally as units join, e.g. a circle formation that expands in radius as units join.
If formations were defined by algorithms instead of static data files, I think we'd gain useful flexibility to do these things, and it probably wouldn't be much more complex to implement the formations, hopefully. Thoughts?
comment:14 by , 13 years ago
Milestone: | Alpha 4 → Alpha 5 |
---|
by , 13 years ago
Attachment: | diffFormation-13-03-2011.patch added |
---|
follow-up: 16 comment:15 by , 13 years ago
Hi. I agree that defining formations in code is more flexible. For now, there is only one priority queue containing the type (melee, ranged, ..) for all slots in the formation (could eventually be adapted for each formation). I didn't want define a priority for each slot, because it would add complexity and it may not be necessary.
The slots are filled fifo-style, first defined, first filled, with a unit of the greater priority. It seems we can create any formation this way. I didn't use specifics bonuses or separations, I don't think they should be hardcoded. Please comment. :)
comment:16 by , 13 years ago
Replying to Badmadblacksad:
Shouldn't formations be remembered? I'm seeing that each time I have a group of units selected and tell them to move, the formation is reset to the default. I guess I expect formations to be remembered for each unit, so that if I select 20 infantry together and tell them to move in a box, I should then be able to later select 10 of them and they should still use the box formation. At the least, the formation shouldn't change if I have the same units selected and only redirect them.
by , 13 years ago
Attachment: | diffFormation-16-04-2011.patch added |
---|
follow-up: 18 comment:17 by , 13 years ago
Hi. The formations are now saved. I still don't know what Syntagma and Formation12 formations really are.
When "stay in formation"/"hold position" stance will be implemented, the patch will become more interesting I think.
A way to set formations direction could also be useful.
comment:18 by , 13 years ago
Replying to Badmadblacksad:
Hi. The formations are now saved. I still don't know what Syntagma and Formation12 formations really are.
When "stay in formation"/"hold position" stance will be implemented, the patch will become more interesting I think.
A way to set formations direction could also be useful.
Thanks for the new patch, I'll check it out. Does this forum post explain the formations better? It was not in the public forum I'm afraid, but has been moved now. We probably want to follow that as a guideline :)
follow-up: 20 comment:19 by , 13 years ago
Hi. Thank you for the link. The patch needs further changes in order to match the requirements. :o)
comment:20 by , 13 years ago
Replying to Badmadblacksad:
(Also there's #600 which may already be addressed by your patch. Just mentioning that here so we don't forget.)
Phalanx, Syntagma, and Testudo seem to be faction-specific and also have other complex requirements/behaviors. So I'd say as long as the other formations are working, that's good :) It should be easy enough to come back later and flush out those details.
comment:21 by , 13 years ago
Cc: | added |
---|---|
Owner: | set to |
follow-up: 23 comment:22 by , 13 years ago
Minor question: What's the reasoning for the formations that check count
and do this.LoadFormation("default"); return offsets;
if it's too high/low? Why can't/shouldn't they do a best-effort attempt to get the right shape regardless of count? If they have to fail, they probably ought to notify the player (like how Player.prototype.TrySubtractResources
does insufficient-resource notifications) to explain the problem (and/or the GUI shouldn't offer unusable formation buttons in the first place - maybe that's a better solution than notifications?)
I think this patch works well enough and is a useful improvement so it'd be good to commit before Alpha 5 (though obviously there's a lot more details to sort out later) - do you want to make any further changes first or is it fine for now?
comment:23 by , 13 years ago
Replying to Philip:
Minor question: What's the reasoning for the formations that check
count
and dothis.LoadFormation("default"); return offsets;
if it's too high/low? Why can't/shouldn't they do a best-effort attempt to get the right shape regardless of count?
I think that's because I wanted to respect the limitations find there
and we don't set limits, people will select a formation to get undue bonuses. e.g. a formation of only 2 romans in testudo formation will get their 100% armour bonus
If they have to fail, they probably ought to notify the player (like how
Player.prototype.TrySubtractResources
does insufficient-resource notifications) to explain the problem (and/or the GUI shouldn't offer unusable formation buttons in the first place - maybe that's a better solution than notifications?)
I think the later is much better
I think this patch works well enough and is a useful improvement so it'd be good to commit before Alpha 5 (though obviously there's a lot more details to sort out later) - do you want to make any further changes first or is it fine for now?
I will change a few things, a new patch will come soon. (if not too late)
by , 13 years ago
Attachment: | diffFormation-01-05-2011.patch added |
---|
comment:24 by , 13 years ago
comment:25 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Thanks, looks great! (Just made some trivial changes to formatting to make it more consistent, and changed a few comments.)
Not everything mentioned in the ticket's description is working yet, but they should be moved into separate tickets (assuming they're all still wanted) so we can track progress individually instead of lumping it all together here; I'll mark this ticket as fixed for now.
comment:26 by , 8 years ago
Keywords: | review removed |
---|
The XML is probably different as there is a new simulation system, so please check the following pages: http://trac.wildfiregames.com/wiki/TDD_Simulation (there may still be some useful information on those pages, i.e. http://trac.wildfiregames.com/wiki/TDD_GameObjectXml (and more specifically http://trac.wildfiregames.com/wiki/XML:_Formation ) and http://trac.wildfiregames.com/wiki/XML.Entity.Actions.Formation etc, but be aware that the TDD_Simulation pages are the most up to date in the case the pages are conflicting. I'm sure Philip will have more to add when he gets back from his vacation though).
The formation Mockups is just a fancier way (mockup with in-game units) to show http://www.wildfiregames.com/~gamedesign/dd/formation2.htm so I hope you survive without out it for a day or two until I've reuploaded + linked those files.
In the mean-time I suggest you take a look at some info about Running (afaik not reimplemented in the new Simulation system, but that's just a matter of time, and you'll probably be busy with getting the basics done + reading up + getting into the code so hopefully it shouldn't delay you. I'm not a programmer so I don't know for sure, but if nothing else Philip should be able to tell you more about that as well.), I'm sure taking a look at Pathfinding won't hurt either as that's fairly closely related (both how it's currently implemented and to read some info on how it's generally done as the current implementation is just a base for a more advanced system), and it can probably be useful to take a closer look at how the animations work as well (I don't mean how the 3D models/animations work as much as how the XML+Javascript interaction works in this case).