Background code doing fancy stuff.
Player code.
Region code/sublocation/location npcs.
Enemy code.
The goal is to be able to add, edit/restrict/expand and remove easily.
I require guidance.
Tips and advice on good order. Efficient design and ease of overview.
Assistance on building an engine for combat, and non-complicated control. Im thinking of equipping outside of combat, and limiting combat to attack/defend/flee. However, I would also enjoy the option to have 1v1, 1v2 and 1v3 combat.
Assistance on building enemy encounters that the game can adjust to suit the player’s ability and actions.
After playing Gotomomi and Brain Guzzlers and interacting with those npcs I too would like a CYOA looking conversation engine. Any help is welcome.
Requesting assistance on design and/or (efficient) code.
Gotomomi uses Quip-Based Conversation by Michael Martin for the NPC interactions. As far as I know, this hasn’t been updated to the current Inform generation and might not work out of the box.
For your combat system, I’d suggest you take a look at Kerkerkruip ATTACK by Victor Gijsbers (it’s on github). This is very comprehensive, but also quite specific for Kerkerkruip (what a strange dialectic dichotomy, Hegel would be proud of me), so maybe you should write your own system, modelled on his and taking only what you need. Since the system is initative-based, it fiddles with the turn sequence rules, which may or may not be a problem for you. One thing it has is a simple change mechanism between combat and peacefull world interaction. I think you could easily use this as a hook to disable the Conversation System during combat by writing a simple check rule like so:
Check an actor quipping when the combat status is not peace (this is the stop the babbling we're trying to kill someone here rule):
if the actor is the player:
say "[We] [have] better things to do right now!";
stop the action.
Which would spare you a lot of headaches, if it works.
As to how to build a nice, modular program in Inform 7: good question. Make some extensions of your own and put much of the functionality in those, I guess. Also, write proper rulebooks. Inform projects are generally a terrible mess, thanks to the one-story-one-file and the everything’s-based-on-rules-which-are-executed-in-implicit-order design decisions.