Customizable win criteria

[Whiteknight]

DO NOT MERGE YET

This PR starts playing with an idea of customizable win criteria. In the game normally there are basically 7 criteria to win: min culture, min prosperity, min peace, min favor, min pop, time limit and survival time. These values were each individually stored and handled in game data.

This PR replaces those individual fields with a single array of win_criteria_t. Each criteria can have a type, a goal and (as yet unused) arbitrary data. Currently I set the size of the array to 10 (but only 7 can be used without manually twiddling bits in the debugger)

In theory this system allows us to start thinking about adding new types of win criteria. For example:

1. Build a specific type of monument (.data would be the building type to build)
2. Have N houses of a specific level (.goal would be the number and .data would be the level)
3. Repel N invasions (especially useful in a world where we have re-occuring invasions)
4. Sell N of trade good Y
5. Earn N denarii
6. Do a minimum amount of trade with natives etc.

TODO:

1. We need to display win conditions somewhere. We could hijack the ratings screen, but there's only space for 4 columns there (5 if we squeeze). So we would need a scrollbar or some other way to display the data.
2. Also, we're going to need to add messaging for each condition. The existing conditions have built-in messaging ("you meed more academies!") but custom criteria would need new messaging and translations.
3. Likewise, we probably also want to hijack the sidebar to show custom criteria instead of just pop/culture/prosperity/peace/favor.
4. We need to update serialization to hold this extra data.
5. We would need to update the editor to be able to specify extra win conditions.
6. The CCK Selection dialog still only shows Culture/Prosperity/Peace/Favor/Population requirements. We need to edit this to display custom criteria

[crudelios]

Some of the checks are failing, first order of business should be to get everything to pass.

I want this, and this could be merged with something like @b483's mission briefing on custom scenarios for ab improved scenario experience.

[crudelios]

I had a quick look at the code.

I like the fact that you're trying to abstract the win criteria.

How willing are you to make this even more complex? Because I have some complex ideas, like grouping criterias together and set the criteria within a group as either cumulative or alternative, with each group allowing sub-groups.

To be fair, this would work better using xml rather than the clunky editor UI.

[Whiteknight]

We can definitely go more complex! I started with a simple list of 10 possible criteria because I was worried about two things:

1. Properly serializing everything into a map file, and
2. being able to display the win criteria on the UI for the user As it stands now, I already have trouble trying to figure out where to put even 10 custom criteria on the UI, I'm hoping somebody with an eye for UI design takes a look at it. More complicated win criteria would involve a different data structure to store them, though I think most of the interface I've put together should continue to work fine. Let's go over it on discord and see what we can come up with

[UberWaffe]

@Whiteknight To fix the compile error on MacOS, see this PR "https://github.com/Whiteknight/augustus/pull/1" One liner, will likely be quicker to just make the change yourself.

[UberWaffe]

@Whiteknight Take a look at how I plan to handle conditions in the scenario events PR #831. Example: "src/scenario/conditiontype/conditiontype_time.c"

Basically that PR has all the plumbing needed to save and load conditions to the savegame file.

I've defined conditions in such a way that they can be linked to anything, not just scenario events. Look at the "scenario_load_link_condition" function. Currently only supports events, but can easily be expanded.

So we could add a new file piece for "win_lose" conditions, let the map maker define under what conditions you win (or lose). Then we can define the win conditions you are working on as new types of conditions. (Which would also make them usable in scenario events, and vice versa.)

Most of that would be copy-paste of parts that now exist already, and just tailoring them to work for "win_lose".

Alternatively, we could just create two new actions for win and lose, and then create the conditions. Then win and lose criteria are just standard events. Would still require work for mapping older scenario data into the new events. (I.e. your "load_static_data" function.)

[crudelios]

Is this ready for review? @UberWaffe

[UberWaffe]

Is this ready for review? @UberWaffe

@crudelios No, I have not worked on this at all. I was just going to assist @Whiteknight.

[crudelios]

No idea why, I thought this was your work! Probably due to the similarity of the scenario events PR.

I'm not sure how both features can be brought together, but it would be great if that was possible.