a very small suggestion for the next patch for ryhleh ( devs plz read )

[Arryn]

Originally posted by Graeme Dice:
What, you mean the poll where you flat out told the devs that you knew more about how the game should work than they did?

Yes. I'm paid pretty good money to do exactly that sort of thing (telling people what their software products should or should not do) in my professional life. The fact that I've been doing it for 28+ years implies that I've been fairly successful at it, too.

The additional fact that the poll rubbed you (one of the worst fanboys on this forum), the devs, and many others with too-sensitive sensibilities the wrong way does absolutely nothing to lessen the underlying point. I don't believe in tap-dancing around issues or sugar-coating replies for ease of consumption. I assume other people are adults (until they prove otherwise) and have the maturity to accept arguments in a rational and logical manner. Alas, I find way too few people that understand the concept of reasoned discourse, much less are willing to practice said concept.

Finally, I'd also call your attention to the statistically significant number of poll respondents who agreed with me.

EDIT: PS - this is about as polite a response to flamebait, GD's obvious intent in his reply, as I can make.

[ July 12, 2004, 14:52: Message edited by: Arryn ]

[Chazar]

Umh, does UI stand for User Interface?

If so, then dismissing isnt a UI problem, imho: Just add a "get lost"-command, which tells a commander to drive his assigned troops away during a fake maneuver in the woods. The commander should then go away himself by a percentage chance based on the troops' experience points, because of his bad remorse due to disbanding his loyal servants...

(Oh, wait, this would also implement another new option: the option of resigning a game, if you give this order to your pretender... )

[Arryn]

Originally posted by Chazar:
Umh, does UI stand for User Interface?

Yes.

[PvK]

I've mentioned this idea before, but I think ideally, most or all units who are dismissed without pay, or who retreat and are eliminated due to no-retreat-province, or retreating mercenaries...

... should be remembered, grouped by compatible type (hopefully no paladins mixed with undead, or iceclads with hot abyssians), and occasionally reappear in the form of either good event reinforcements for the lucky (not necessarily for the side they originally served), or as independent attacks on provinces, or as new mercenary bands.

PvK

[Arryn]

Originally posted by PvK:
I've mentioned this idea before, but I think ideally, most or all units who are dismissed without pay, or who retreat and are eliminated due to no-retreat-province, or retreating mercenaries...

... should be remembered, grouped by compatible type (hopefully no paladins mixed with undead, or iceclads with hot abyssians), and occasionally reappear in the form of either good event reinforcements for the lucky (not necessarily for the side they originally served), or as independent attacks on provinces, or as new mercenary bands.

An interesting idea ... that I suspect would be extraordinarily hard to code. You get points for original thinking though.

[PvK]

Sounds easy enough (and fun enough) to code, to me...

The tricky/annoying part would/might be deconflicting incompatible types for the new Groups.

PvK

[ July 12, 2004, 17:27: Message edited by: PvK ]

[Arryn]

Originally posted by PvK:
Sounds easy enough (and fun enough) to code, to me...

The tricky/annoying part would/might be deconflicting incompatible types for the new Groups.

IMO, the tricky part is what's involved with the "remembering" aspect of your proposal. I think you underestimate the data structures that'd be needed to do this.

In light of what I've previously posted on this subject, were I the responsible dev, I'd first code a basic (and no-cost) "dismiss" functionality (to close the existing hole in the game's design) and then, later, enhance the dismiss functionality (in one or more ways as per various suggestions) in the form of a new "feature" added to that basic function. It's the principle of stepwise refinement. Build complex systems up from simpler ones. It's easier to do than biting off a big task in one chomp. Nibble around the edges ...

EDIT: the "deconflicting" aspect should be an inherent property of the aforementioned data structure(s). IOW, once you've stored all the relevent info regarding the unit(s) to be disbanded, then conflict-resolution should be automatically derived (inherited) from the data structure when you go to apply the event that accesses that data later on. Fundamentals of modern OOD/OOP.

[ July 12, 2004, 17:55: Message edited by: Arryn ]