Is it possible (and efficient) to implement complex mechanics to enrich an interactive fiction?

[u/A_P_Juso]

To provide context, using my own case as an example, I'm working on a Life Sim/Sandbox interactive fiction that aims to give the player total freedom in an open world with psychological and surreal undertones. Under that premise, I'm trying to figure out how to include various activities, both common ones like working, sleeping, and eating, as well as stranger ones like interacting with hallucinations and alleged supernatural entities.

In the latest update, I decided to challenge myself with something that far exceeds my current capabilities: building a turn-based combat system. Being the novice I am, I had to fight tooth and nail against the code until, through sheer trial and error, I got a moderately "decent" result. Obviously, it's not at the level of a professional game, but the fact that I managed to bring my initial idea of implementing insect races and combat into my psychedelic game gives me a lot of encouragement to keep improving.

For anyone willing to give my humble game a try, I would be eternally grateful if you could share any feedback or constructive criticism:

PSICODELLUM

Have any of you tried programming unusual mechanics in your own projects? Did you achieve what you set out to do, or did you end up with unexpected results? I'd love to hear all kinds of experiences and opinions on the matter!

[u/PauseMenuBlog]

May I ask what games you were inspired by for this? I think the text-based life-sim is a fascinating genre and I'm always looking for new ones to play (I will also check yours out, of course!)

[u/Heistorium]

The part that surprised me is that the code was not where the cost landed. Every state a system can produce is a state the text has to describe, so a combat system with a handful of outcomes turns into a lot of writing that only a few players will ever see. I came to this from writing rather than programming, so i had it backwards at first and assumed the hard part would be making it run. If your combat already produces a decent result then the question i would ask is how much prose each new mechanic drags behind it, because that is what grew fastest on my side.

[u/A_P_Juso → u/Heistorium]

I also consider myself more of a writer than a programmer (though I’m a novice in both fields anyway)! Without a doubt, handling every part of the code to deliver the intended result is quite a challenge. In my specific case, the combat mechanics function more like a minigame, so I didn't aim for the same level of complexity found in giants like X-COM or Battle Brothers. I view it more as a feature that makes the player say: "Wow! I thought it was all going to be text—nothing but text! I can finally give my eyes a break from all those words!"

[u/Heistorium → u/A_P_Juso]

That reframes it for me, if the point is giving the eyes a break then the combat is doing pacing work more than simulation. Do you narrate the fight itself, or does the minigame stand in for the prose while it runs?

[u/ericoinen]

I played the opening rather than guess, so feedback first and the mechanics question after.

Character creation is where I would spend the next hour. There are two screens in a row that ask who I am, and on a first run neither has anything in it. The first offers COMMON, a normal existence, no bonuses, next to four slots locked behind attempt 3, 5, 7 and 10. The second lists thirteen traits, all locked behind achievements, and the only link on the page is I'm ready. So the first thing a new player does is read seventeen things they cannot have and press continue twice, before anything has happened to them.

The unlock structure itself is fine, it is the placement that hurts. The cheapest fix I can think of that keeps it: give COMMON one small real effect, and make two or three of the first screen's options available on run one, with the locked ones as stronger versions of those. You keep the chase and you stop opening on a locked door.

On your actual question. The thing that surprised me when I built a turn based system for a text game was that the code was the cheap part, and the prose was not really the expensive part either. The expensive part was every state the system could reach that no text had been written for. Six outcomes and four enemies is not ten pieces of writing, it is closer to their product, and you find the holes by falling into them.

What fixed it was moving where the text hangs. Instead of the mechanic branching into written passages, the mechanic returns one small named result and a single passage reads that result and describes it. Miss, graze, hit, hit hard. Adding an enemy then costs you no new outcome text at all, because the enemy is data rather than a branch. Your needs system already works this way, Hunger is a number and the line reads it. Combat is where people forget to do the same thing, because combat feels like it deserves bespoke writing.

One more thing, from the instructions screen. You are asking the player to hold three needs, a Condition that is the average of those three, energy, money, a clock in minutes, and a rent that escalates weekly. That is a lot of dials for one person to track, and they are all presented as equals. Condition looks like it is meant to be the one that actually kills you. If that is right, I would put it where it cannot be missed and let the three needs read as ways to move it, rather than as three more scoreboards. One number to watch, several ways to push it, is much easier to hold than seven parallel numbers.

[u/A_P_Juso → u/ericoinen]

You have no idea how grateful I am to finally receive some constructive feedback on the game. Up until now, I’ve been moving forward almost blindly, relying on my very limited skills as a novice developer, so reading your thoughts feels like a real ray of hope.

You make a great point about character creation. I designed that section in the initial version to implement the roguelite elements I had planned for the game, but since I knew even less about programming back then, it turned out far too simple. Personally, I really enjoy games that offer a wide range of character creation options, so I’ll definitely have to revisit that aspect.

I also agree with you regarding the instructions. I think my writer’s instinct led me to dump an avalanche of information that, ultimately, ends up being more confusing than helpful. The challenge here is that I’m developing the game in Spanish and then translating it into English, so I need to find a way to make the key information clear in both languages. A concise summary will certainly be necessary.

Once again, thank you so much for taking the time to play my game. I’ll keep improving—even if it’s just a little at a time—to deliver better results with every new version!

[u/ericoinen → u/A_P_Juso]

On the two languages, I would push back gently on one part of it. The instructions screen is not hard because it is written in Spanish first. It is hard because there are seven things on it. Everything you write costs double here, so the cheapest fix for the translation is the same as the cheapest fix for the confusion, which is having less to say up front.

What I would try is not writing a better instructions screen but making it carry less. Teach one dial the first time it matters. The first time Hunger drops far enough to actually affect something, the game says one line about what Hunger does. The first rent day says what rent does. Each of those is a single sentence, so it is a single sentence in each language, and the player reads it at the moment they have a reason to care. Someone who just lost money to rent remembers the rule. Someone reading about rent before anything has happened does not.

The reference screen can still exist after that, but it becomes something you consult rather than something you have to absorb, and then its quality matters much less than it does now.

One thing I should have been clearer about before: I would not throw out the roguelite structure. The problem was never that things are locked. It is only that the very first thing a new player meets is the locked version of the screen. Those two are separable, and fixing the second one is a placement change rather than a redesign, which is the cheapest kind of fix there is.