Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Telling stories - Ideas and related observations #11501

Open
SomeTroglodyte opened this issue Apr 21, 2024 · 3 comments
Open

RFC: Telling stories - Ideas and related observations #11501

SomeTroglodyte opened this issue Apr 21, 2024 · 3 comments

Comments

@SomeTroglodyte
Copy link
Collaborator

SomeTroglodyte commented Apr 21, 2024

Problem Description

Imagining where support of modding to tell stories could go. Events are a step, Scenarios were a step. Loose collection of ideas... Looking for coder's input.

Related Issue Links

PR #11474

Desired Solution

  • Implement Signposts - layered TileSet imagery, and a unit moving onto them displays a message - now aka triggers an event. Can already be much more than "Fertile land to the east, challenging battles to the west" message on reading such a sign... But we need the trigger first.
    • Unit moving onto a Tile can already "fire" TerrainGrantsPromotion, which is older than Triggers and could be revamped to use one.
    • That one is stored in the Terrain json, which is intuitive for a modder - make the Signpost a Tile feature (maybe even improvement, opening the ability of workers dismantling it), need a new trigger conditional <when a [mapUnitFilter] unit visits> or somesuch? That condition could mark the entire Unique as to-be-considered together with TerrainGrantsPromotion in moveThroughTile.
    • That code could then benefit from a cache, as per Tile the applicable uniques won't change during gameplay.
    • Could also be placed in Unit json - or most of the time probably UnitTypes, we already got TriggerUponEndingTurnInTile and TriggerUponDiscoveringTile, could easily do a TriggerUponEnteringTile.
    • TriggerUponEnteringTile with a tileFilter extension "adjacent to [subFilter]" - like MultiFilter non-[] but simply like this: if (filter.startsWith("adjacent to [") && filter.endsWith("]")) return isAdjacentTo(filter.removeSurrounding("adjacent to [", "]")) in Tile.matchesSingleFilter - could already replace Fountain of Youth's TerrainGrantsPromotion - but elsewhere in json. Possibly needing a Comment unique so Tile civilopedia is informative enough...
  • Multipage storytelling - like Wesnoth does all the time.
    • Could extend Events and/or CivilopediaText to allow paging, then refurbish existing multistep tutorials to reuse that.
  • Events with imagery could be the first place in Unciv where images might need localization (or not - that WorldScreen tutorial). Think displaying a campaign map.
    • Idea: Same as Wesnoth, support by looking for an image inserting /languagecode before the last slash in the path - no matter whether texture-atlased or external - then looking for image exist, and overlay it over the explicitly named one?
  • Campaigns. Think multiple Scenarios in one Mod wrapper, then a flow diagram specifying how they connect.
    • A Scenario would need a "result" - could already be lose/Victory-type, maybe new ideas.
    • Campaign flow-map specifies per Scenario / result what happens - lose campaign / start scenario "X"
    • Unit carryover - units with all their promotions XP and renames - limited by the flow-map using mapUnitFilter and max counts.
  • EventChoice altering the map. Possibly mandatory by being the only option. But stories will very likely benefit from the ability ("The enemy hero is annihilated, but your reckless use of explosives collapsed that bridge").
    • Refurbish Terraform unique to be alternatively a UnitAction and a triggerable sounds easy enough.
    • But then - which tile(s)? Having all places where a Scenario wants to alter the terrain use unique terrain the mod needs to prepare for just this would be a way, and need little to no additional code. But that's a lot to ask, is it? How about supporting "@x,y" as tileFilter - simple, and scenario builders will long have discovered how to display the numbers?
  • Which brings me to MultiFilter.
    • Structurally - code and otherwise - supporting OR logic would be trivial. Why didn't we do it yet? All real problems like parsers not fully supporting nesting would be no different from AND logic...
    • I suspect the wiki is wrong in its examples. The nesting of []for the non filter will either only work if the outer filter brackets enclose a text ending in ] - or never work in that case but work in all others. Mind-boggling. Still thinking - should I test all cases that I can imagine and fix the wiki, or should I re-urge adoption of the nested-brackets-parser or - is there a kludge somewhere I overlooked that just makes it work regardless?

Alternative Approaches

Play some other game - yea that's the ticket. 😈

@SomeTroglodyte
Copy link
Collaborator Author

As for MultiFilter - the wiki claim "[non-[{Wounded} {Armor}]] units will not work" is true, but the reason is not to the point. It is because the applicability test for the and test is lax. Testing all elements of the syntax actually makes that example work correctly.

@yairm210
Copy link
Owner

I like the idea of tileFilter supporting specific tile locations, has a lot of merit!

I'm all for tile-entering triggers, would be easy to implement as long as we don't mind it triggering multiple times - if we need to keep track that's more complicated

Campaigns - so far we hardly have any real scenarios, so talking about campaigns is very premature

@SomeTroglodyte
Copy link
Collaborator Author

very premature

True, very, but having a vision leaking to the modder community may spark interest in scenario development..

as long as we don't mind it triggering multiple times

Which signposts should normally do. But a repeat control for any type of event is a good to-do anyway, and - isn't there a comment saying so already? Don't we have <once> already, we'd just have to make it work for events (and choices!)... "Just" - famout last words...

tileFilter supporting specific tile locations

@(x,y) would be a better syntax than @x,y - easier, reuse Vector2.toPrettyString...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants