Note: this is in reply to @Tag365’s post but the forum unhelpfully auto-deleted the quote which is a bit shit.
Sorry for the confusion, your post was straight after the one where I mentioned a Keep Talking mod I was working on.
Yaffaif is a project I’ve wanted to build for many years before I started it, and it contains lots of ideas that I’d wanted to try out, particularly in the engine. It’s hard to pick which bits are my favourites. Most of the things I’m proud of are very much under the covers.
If I had to pick one bit, I’d probably have to go with the way it internally handles actions; the things the character and NPCs do, as it’s pretty unique. There are two traditional approaches:
- Traditional text adventure: take the player input text and then try to parse the text against the game model to work out what the player meant. This leads to the standard problems with text parsing. Some variants have links or buttons for common actions, but this tends to lead the player into an illusion that they can do everything with these links - Inform and Quest can both suffer from this. I wonder how many players know that “x me” is a valid thing to type into Quest’s text box? It’s kinda important for the games we play!
- Build a GUI: Have buttons/controls some of which are standard (like direction arrows) which are enabled/disabled, and others which are set up from the game model. This can lead to problems with actions the player wants to try not being available in one context when they are in another.
Yaffaif takes a different approach. The game model/control creates a list of all the “possible” (not necessarily successful) things a character to try before you get to interact with it on each turn. The UI then turns these suggestions into the controls you see. It also vastly simplifies text parsing - and allows the text box to do predictive completion as it knows all the valid things that you could ask to do at any point (getting around verb/noun guessing).
In the engine there’s no difference between the player character and the NPCs save for a single variable indicating which character the player is currently controlling (you can play with this in debug mode). This means I can use the same system for NPCs; on each of their turns a list of possible actions can be built, and then the code that controls the NPCs can choose from them just like the player can and the same actions invoked - I don’t have to code one way for the PC to do things and a separate version for NPCs. This saves a huge amount of coding, once you get the hang of it. It also means NPC-NPC interactions can happen (this will be a thing!).
The obvious problem with building my own engine and trying to stick to a very pure separation of model/view/controller is that it takes much longer to get things done. Part of the development is me exploring what is possible - which gives me a lot of satisfaction. Right now there are lots of things the engine can handle that aren’t exposed in the story. I’m working on that at the moment, the path(s) for Orion’s quest will open some more of this up.