Volcanoes

[Thunderbrd]

If it wouldn't slow things overly much to roll randoms for each qualifying-as-possible-to-occur event (big filter there!) then that's how it should be done really. The idea to have only one random roll each round working against randoms for each event stored at init would lead to some events happening repeatedly while others ignored entirely and it would all depend on how long you played a given session as to how long you could keep a given pattern active. That would again mess with the odds in irrational ways so if its not all that bad to process, I'd think it better to simply roll for each every round but filter out the events that can't take place before making the roll. Combat rounds cycle through pretty quickly so surely randoms don't take much in the way of processor time...

I like the idea that some events would be global (not based on a given player and checked once per game) - that could certainly keep some events more manageable AND rational - but we could probably keep things at least on a player by player level (without going down to a city by city or unit by unit basis) since there would be potentially quite a few randoms rolled on each turn as it is.

I believe there are far more processing intense regions of code where the processing need not be anywhere near as voluminous as it is to take care of the need where we could make some simple tweaks to save a lot more than this would cost us in terms of turn time expansion.

 

[Koshling]

@n47
It should be using 50 civ dll.
In fact, there are many mods which do use the 50 civ dll...
Whether 2 players are in the game, or all players are in the game, a loop through all players will still loop through all 50 slots, although isAlive() checks can be used.
Whether your computer can actually run a fully filled game is another issue.

@Koshling
I do agree that once in a blue moon when you change a 50 iteration loop into a 10000 iteration loop, it is not a big deal due to how fast computers are nowadays.
But when you start doing these every now and then, "not a big deal" pile together and start becoming a small deal
Anyway, knowing C2C's motto is "the more the merrier", what is just 200 events now may become 400 next few years.
Then the 10000 loop will become a 20000 loop, whereas the current system will remain as a 50 iteration loop which only loops through whole event list when event triggers.

It doesn't matter whether you roll the number once and use it for every event, or roll a new one for every event.
You still have to loop through the whole event list to check if the number is jackpot for each event.

That's why I run the profiler every week or so to identify new hot-spots and optimize them. You shouldn't second guess what actually costs effort without measuring, and when deciding on the functionality you want (unless it's OBVIOUSLY going to be expensive) performance should not be a major INITIAL consideration (prototype, profile, optimize or redesign as necessary). It's most unlikely that events are ever going to be a significant factor - AI for a single unit costs more than the entire set of event processing (decision making, not execution once you've decided to fire an event that is) for all players in a game turn currently. They total turn time, and the event decision processing time are so widely different in order-of-magnitude hat it's just not a scary prospect for any of the proposals made so far.

However, I am very much on the fence about what we WANT to achieve (functionally), and that debate should be the starting point (if it somehow gets so complex that it could be a performance impact then we can revisit at that time, but I really don't see that as at all likely)

 

[Koshling]

If it wouldn't slow things overly much to roll randoms for each qualifying-as-possible-to-occur event (big filter there!) then that's how it should be done really. The idea to have only one random roll each round working against randoms for each event stored at init would lead to some events happening repeatedly while others ignored entirely and it would all depend on how long you played a given session as to how long you could keep a given pattern active. That would again mess with the odds in irrational ways so if its not all that bad to process, I'd think it better to simply roll for each every round but filter out the events that can't take place before making the roll. Combat rounds cycle through pretty quickly so surely randoms don't take much in the way of processor time...

I like the idea that some events would be global (not based on a given player and checked once per game) - that could certainly keep some events more manageable AND rational - but we could probably keep things at least on a player by player level (without going down to a city by city or unit by unit basis) since there would be potentially quite a few randoms rolled on each turn as it is.

I believe there are far more processing intense regions of code where the processing need not be anywhere near as voluminous as it is to take care of the need where we could make some simple tweaks to save a lot more than this would cost us in terms of turn time expansion.

Could do it stochastically and still limit to at most one event per player per turn -

1) (logically) roll for each possible trigger to determine if it 'wants' to go off
2) If > 0 want to fire then roll amongst them weigthed by their fire probability normalized by the total for those that 'wanted' to go off, firing the winner

However, the tendency would be (as events were added) to reach a point where SOMETHING goes off every turn. I'm still not sure that's what we want.

 

[Thunderbrd]

Could do it stochastically and still limit to at most one event per player per turn -

1) (logically) roll for each possible trigger to determine if it 'wants' to go off
2) If > 0 want to fire then roll amongst them weigthed by their fire probability normalized by the total for those that 'wanted' to go off, firing the winner

However, the tendency would be (as events were added) to reach a point where SOMETHING goes off every turn. I'm still not sure that's what we want.

That might be an improvement for processing yes.

But why would we want to limit ourselves to only having one event ever possible in a round? Particularly when we have property based likelihoods in play?

 

[Koshling]

That might be an improvement for processing yes.

But why would we want to limit ourselves to only having one event ever possible in a round? Particularly when we have property based likelihoods in play?

We wouldn't have to I guess, but my point was that I don't want us to get into a situation where we have 'event spam'. It's one thing to have 2 events with 10% chances, but quite another if a bunch of independent modders add 100 events with a 10% chance - something needs to perform some global normalization.

 

[n47]

We wouldn't have to I guess, but my point was that I don't want us to get into a situation where we have 'event spam'. It's one thing to have 2 events with 10% chances, but quite another if a bunch of independent modders add 100 events with a 10% chance - something needs to perform some global normalization.

That is why I proposed the second class of events. Events falling in "oh, it is so cool, I will add that" I would put into bonus events category. Whole category would be triggered once per player and would work the way you described -- with weights. But event like volcanoes eruptions or bunt down buildings (especially bunt down buildings) would be checked for hit in the ordinary way. -- Roll and check. (About burnt downs, I would even roll for them each city.)