agreed
Recent systems like Twine were initially designed to create interactive choice based narratives, similar to things like a Choose Your Own Adventure novel, where the end-user selects a choice from a displayed set of them to further progress through the story-line.
In such projects variables are used to track the choices made and the end-userâs progress through the story. They are also used to allow the end-user to supply information like the point-of-view characterâs name. The value of the variables can be used to dynamically alter what story content is displayed.
Systems like Twine were later used to also create more RPG like projects that require functionality like: Character Stats; Locations; Usable Items; Inventory; Shops; Quests; Events; etc⌠all of which can generally be implemented by any system than allows Object based data-types to be stored in its variables.
One common issue with much of the above listed RPG like functionality is that there is no one ârightâ way to implement it.
eg. An Inventory can be as simple as using Boolean variables to track if an item is being carried, to as complex as an Object based collection system that supports Items having weight & usages counts.
So often each project ends up requiring its own bespoke variation of such functionality, which makes it hard for someone like a Twine Story Format Developer to include a complex enough âone size fits allâ implementation of such functionality.
So instead in the case of Twine each Story Format includes the tools needed to build such RPG like functionality. And some members of the Twine community have released guides & third-party addon libraries that can be used either âas-isâ or as a starting point for a bespoke implementation of the feature the author wants.
I see that youâre aware of Dialog, but Iâm not sure how familiar you are with it so Iâll say this: Dialog not only allows the author to switch between parser mode and choice mode but also allows, if the author desires, the use of parser commands while in choice mode.
Funny! Thatâs at least part of the reason I love testing your Adventurons.
Q: Why does the game respond like this?
A: Dunno. Adventuron mustâve had a personal âmomentâ there.
Q: Why does the game respond like this?
A: Dunno. Adventuron mustâve had a personal âmomentâ there.
A: Dunno. Adventuron mustâve had a personal âmomentâ there.
Ah yes, well you see: I tell Adventuron to do one thing but then it wilfully does something completely different!
Needless to say, this is entirely to do with Adventuronâs âemergent behaviourâ and nothing at all to do with deficiencies in my coding skills.
I keep wondering how many more games itâll take you before stumbling upon the future AI Emergent Adventuron Overlord.
Shouldnât be too long now. I give it two more SpringThings and a ParserComp. If you should compete in IFComp all bets are off.