Replace tournament jousting system

[thefinestsieve]

Tournaments should allow you to joust through the duel engine with appropriate flavor. The prizes given out at the end should also reflect actual win/loss records. At first this would probably be plugged into vanilla tournaments, but eventually I'd like to overhaul them more thoroughly.

[zijistark]

Also, you should add a "sizing up the tournament" event chain portion where you can see the top competitors (variable values can be shown in localisation, so maybe as custom tooltips).

Next, you should be able to actually watch two people dueling or jousting (a sword / pike fight or a mounted joust). Give the spectator(s) (in theory, multiple non-AIs could attend the same tournament-- see below) the play-by-play.

Finally, consider a system of grand tournaments like I assume GoT uses (they definitely use something that suggests this level of sophistication): You actually send riders out announcing the the tournament to your whole subrealm. The prizes are increasingly high the higher the tier (and also the rate at which the AI calls such tournaments is lower the higher the tier, both to compensate and to avoid shit-tons of tournaments code running all the time).

Any ruler in your subrealm that's not at war could choose to come participate or spectate, as could theoretically anyone from their courts. Spectation awards the holder proportional prestige (like +3 prestige per spectator, +5 per competitor, +10 per ruler competitor). Avoid all this extra overhead by just auto-banishing random_realm_characters (esp. those that have competed before or are rulers) in as spectators and ...

Fuck it, this is an EMF idea, not an HDE idea. I was about to go into how this spectation and competition is a social opportunity for events of all types of flavors (that are actually EMF events) to come into play.

Yeah, save the ultra-grand tournaments for EMF. I'd love to work on them with you. There's a line you've got to draw on reusable, modular core code components.

[thefinestsieve]

Yeah, at this time I'm not interested in pursuing an overhaul of that magnitude. I just want slightly neater tournaments. In the future if a chance to work on something more comprehensive presents itself, I'm certainly open to the idea.

And it would definitely feature spectation. Simulated or rare for AI (don't want to waste the cycles, but some event chains could have side effects that might affect those around them, so those would be worthwhile), but multi-player support for spectation and/or competition (dunno how well the HDE works in MP for the actual competitors, but interactive-immediate stuff could work fine for the audience). Basically the HDE would just need to support sending notification events regarding what event just fired for the competitors out to N targeted (by opinion modifier) spectators. The code that sets up the tournament could take care of hooking-up the spectators. Anyway, if they can get a play-by-play stream, then condensed play-by-play spectation flavor can be written.

I'm not opposed to spectating in principle, but it would need to avoid swamping players with events, which would be difficult considering how the AI races through the event chains and how many duels would need to be conducted quickly in order to get results in a reasonable time. In fact, I'm still concerned with how to avoid swamping participating players with duels in order to get enough results to be able to have hand out prizes for 1/2/3 place and have it actually mean something. Simulating a ladder would probably be my ideal, but that would require the player to fight so many duels...

And the way the HDE works, plugging in functionality like spectating would be spectacularly trivial. All the flavor is organized as independent mini event chains, so the tourney flavor would just need to send the appropriate events.

[zijistark]

You should consider spectating support as a general thing for HDE to support external code implementing.

As long as there's some way to send a notification to spectators of meaningful semantic value like "character A injures B, B is on the ground" -> "B gets up to fight again" -> "character A injures B, B is down" -> "B asks for yield" -> "A kills character B" (each quotation is an event of an appropriate pre-defined type or simply one spectation handler event with a bunch of flags indicating all the the basic semantic possibilities of dueling & jousting).

Then that handler event(s) (a stub(s) in HDE that does nothing) can be overridden in mods that directly integrate HDE or by simply ensuring their definition of the event comes last in file load order (as long as that technique continues to work, else you could put it in a special file like the output events file which mods could override.

Then let the mod take care of spectation event stream compression into the level of detail and frequency of occurrence (e.g., maybe play-by-play from 3rd-person perspective for trial by combat or every round's outcome or just the match outcome or just a couple highlights from several duels going on at once or whatever)-- whatever they're interested in providing for that particular type of observation mode.

I particularly like the random highlights idea combined with judges shouting at the top of their lungs for a simultaneous tournament ladder.

Ladder would only need to be 4 duel rounds deep to get 16 matches, which is 32 competitors simultaneously in the first round. Considering in EMF I'd handpick the competitors to be a mix of the best in the realm and those that think they're the best / military commander rulers, that'd be pretty fucking grand to pull highlights from the most interesting outcomes from the play-by-play stream and show them to the user.

[zijistark]

BTW, is there anyway to build support for HDE driver mods to interrupt the duel? Obviously, they'd need to register a spectator character with an appropriate targeting opinion modifier (TOMs, from this moment forward).

Anyway, the mod would need to register a spectating TOM to catch the play by play synchronously, and then based upon whatever arbitrary logic (I'm thinking the King stands up and yells "Enough! Leave him be!" for an important character about to probably die, or for trial by combat situations-- also allows the HDE to offer the concept of duels going awry, e.g. a tournament competitor starts fighting to kill when it's supposed to be a friendly competition of sport), the spectator can then call an event back into the HDE referencing the specific duel (therefore, the interrupting spectator would have to do something like flag one of the two for interruption or set an interrupt TOM on at least one of the duelists).

The HDE interruption handler would then find the match to which the spectator is referring, and set up its state for the next handler event invocation to simply skip to the end state, tear down flags, and send an output event with an interrupted flag. Doesn't need any interruption notification flavor events, cuz the spectator already knows the two characters in the match, and so they can send the appropriate flavor events directly to the duelists, as only that code will have any clue as to the type of flavor to use for interruption.

Note that this would allow HDE driver code to actually interact with the duelists mid-round and let them respond to interruption and either take heed or choose to ignore and keep fighting, indicating that they ignored the request from the interruptor before the interruptor ever calls the real HDE interruption/cancel event hook, and then the interruptor code would simply never call the HDE cancellation code if so, allowing the duel to continue despite the order, probably to great horror.

[thefinestsieve]

That should be possible. But since specific duel types provide their own events, I'm not sure how useful it would be. A hypothetical external mod can just write up their own flavor event set (using the term flavor is a misnomer as the event sets include both the flavor and some of the mechanics) for a specific type of duel and include most, if not all, of that functionality. The only place you'd run into issues would be in the event which calculates the actual outcomes; but even then you could solve that by including your own outcome handler event and calling that instead of the core handler. Since the handlers for each "phase" of combat already rely on being called from the "flavor" event sets, you'd simply be substituting one event call for another. In fact, the entire thing is so modular that you can replace pieces of it with custom versions of the core events at any point without disrupting functionality.