Topic: Scenario objectives concept
Posted at: 2020-11-11, 16:27
I am currently working on the third frisian scenario. I've been doing this for like two years already and am still unhappy with the fighting-heavy and linear storyline, which is unfortunately required for the story's progression. So I had an idea how this problem could be mitigated:
In the game Imperium Romanum (© Kalypso), which is a bit like Widelands, the player is not given the objectives by a scenario script; instead there is a stack of objectives and the player can draw a new objective from the top of the stack whenever he likes. The player can have up to three active objectives at the same time (the number varies in some of the scenarios), and if that limit is reached he needs to fulfill at least one of the open objectives before he can draw a new one. The scenario is won when all objectives have been completed. The objectives as well as their order is prescribed by the game creators, but the time when they are drawn is entirely up the player. This puts a lot of importance to the choice when to draw a new objective, because some of them perform an action immediately when drawn, e.g. giving the player extra money, doubling plantation production for the next five minutes, or sending a barbarian horde that needs to be quickly repelled.
Several of the existing scenarios with their parallel objective lines (especially bar01, bar02, atl01) are already a bit like that in effect, while especially fri01 and fri03 could benefit greatly from such a concept because then players could choose their preferred pace (e.g. the lengthy introduction of the building supply chains in the beginning of fri01 would be less boring to advanced players if they are allowed to work on three tasks at once if they like).
Should we implement a scenario objectives concept like in Imperium Romanum for Widelands? If yes, should we convert all scenarios to it or – probably better, though more code to maintain – make it the scenario designer's choice whether to use "classical" or "stacked" objectives (in which case I'd use the new concept for fri01 and fri03 but not for fri02 and the already completed fri04)?
Posted at: 2020-11-11, 19:54
While designing the emp03 and emp04 scenarios I got constantly feedback to walk away from a to linear storyline. So therefore I'd like to pretend they are already concepted in this direction. However this had a lot of side effects to consider as the possible permutations of objectives and their influence on each other increases and needs to be considered. (e.g. some objectives might be already fulfilled while not triggered yet). This is difficult and might be the same for the "selection" principle. Especially since it is hard to imagine how different players could do things and leave the foreseen path. But the depth added to the game is more then worth it.
so +1 for having more parallel tasks and +1 for having side objectives to get a bonus / malus unrelated to the story evolving.
I am open to any suggestion in this direction for the empire scenarios as well of course.
However I am somewhat against a completely free user selection from given objectives as it would mean they need to be completely independent which might reduce complexity and depth that cpuld be created by dependent chains of objectives, and it would mean complete redesign of all existing campaigns.
However +1 for a user interface to make decisions in the game like directly chosing whether to decline any demand from a scenario character rather the determining it from a specific action (like destroying the warehouse in fri02 fro example )
Hope this is not to confusing as I tend to express myself misunderstandable in recent times.
Posted at: 2020-11-12, 09:34
This problem can be solved by recording the state of the objectives in a scenario-wide variable, and then have coroutines running to check the state. I did some of that for the training wheels, because they have to deal with a lot of non-deterministic circumstances.
So, I recommend solving this entirely via Lua scripting, and when it works, pull out helper functions that can then be used by any scenario.
Then of course you have to accommodate all the crazy things the player can do, which is the tough part.
Busy indexing nil valuesTop Quote