Designing a combat system for a survival horror IF

[kVella]

I got the crazy idea a while back to build a combat system from scratch for a survival horror IF I have embarked upon writing. The system I am using for the game is hypertext/html based using the VIBAE 2 system I created for my Spring Thing '23 entry The Mamertine

As always implimenting this sort of thing is more complicated that it first appears, so I thought I would make a thread here in this community to document my progress and get people’s opinions and maybe even a playtester or two as things come together. This forum already has quite a few topics on the general theme of combat in IF but one more probably won’t hurt!

Specifically one of my design requirements was for this system to also be playable as a tabletop system. Not that I am planning to make a physical game based on this system but I would like to design this possibility in. This means all RNG events must be able to be done with D6s (preferably needing less than 12 in total to resolve any one action) and simple lookup tables.

The system would have ranged and melee combat and would be turn based.

The system computes a basic two dimensional combat space with each combatant having a position within it.

What the player sees is a descriptive representation of the combat space. This is where the harder design task lies. A choice has to be made here as to how literal the description is to the actual mechanics being computed. This will be the balance between what I would consider being interactive fiction and being a crpg.

For the UI I don’t think it will be that hard to impliment inside a hyperlink/html game system. Inside a parser would be more difficult perhaps but I think this discussion has already been flogged to death elsewhere on this forum.

The fundamental design question is how to present the player with compelling dialemmas and trade-offs. Specifically regarding the game I am writing the player character will be armed with a machine pistol but in typical survival horror fashion will have very limited ammo for it. The machine pistol also is selective fire therefore the player has the choice to fire a lower accuracy burst (high damage per turn at closer range, uses more ammo) or a higher accuracy single shot (more likely to hit at longer ranges, lower damage per turn, uses less ammo). The accuracy mechanic means that some sort of range judgement is needed. If the player chooses to fire full auto at distant enemies they will chew though their ammo for limited effect, leaving them to spend the rest of the game having to defeat any enemies using melee, which ought to drastically reduce their chances of survival.

If the player is not engaged in melee combat already they may choose to charge an enemy to engage them in melee combat. If the enemy is sufficiently far away from other enemies then this might be a prudent move if the player can defeat them before other enemies can close in on them.

The enemies the PC will encounter do not have ranged weapons and will generally be inferior to the player in a one-on-one melee, howerver if the player is engaged by more than one at a time or attacked from behind their chances of coming out on top will decrease rapidly. This implies that situation awareness of the combat space is going to be an important gameplay factor so how much literal information is given to the player about it is going to be crucial here.

To be continued…

[HAL9000]

First off, I really like the system you’re working on. I like the verb-first point and click mechanic; which works the way my brain thinks. I’m working on a very similar, generic interface system so I’m bagging what you’re mowing here.

I recently worked on planning a battlefield strategy system for a text-only IF game. What started as a large grid-map ended up being a small diamond shape containing major zones that provided strategic advantages/disadvantages and minor connecting zones that offered no benefits. Because of the small, boardgame-like map, it forced battles to play out quickly; and with lots of stressful decision making being so close to the enemy (think of Risk being played on a tic-tac-toe board). Of course, this map idea was designed for moving numbers of different troops (infantry/archers/cavalry) and splitting them up as desired, but this might give you ideas for positional strategy. The map is basically an encounter and more enemies can enter the map as turns progress. Flanking is possible and simultaneous enemies reaching you from the same space or different spaces is possible. It would be turn-based. Shooting 3 connected spaces away would be low accuracy; 2 spaces, average; 1 space, excellent. Occupying the same space is melee combat. I could go on, but I think you get the point. The benefit of a small map is that it’s easier to describe and move around in a text-only manner. The larger the map, the more difficult it becomes to envision what is happening, I suspect. Turn it 45 degrees and it’s all N S E W, if that makes more sense. Anyway, just food for thought.

Another way that I envision the combat possibly happening is like a static-positioned first-person shooter where you advance to the next area and are given a description of what you see happening in front of you (playing out kind of like Time Crisis in the arcade). You must then decide what threats to deal with, when and how to deal with them. In some situations, it might be better to “take some minor damage” to avoid being overwhelmed. (Throw that grenade and get 3 enemies even if it means being hurt in the next turn by an advancing enemy.) How it all plays out, is kind of nebulous at the moment, but it’s another way of picturing the combat, is all. I do think that enemies would come in “waves” and you might have to deal with a certain number before advancing to the next combat or text adventure scenario. With this concept, you’d get to create really unique scenarios where the environment could be altered (shoot out a support and collapse some scaffolding on a bunch of critters… or open that steam valve and use that to retreat from a large number of enemies running down a hall at you) or things could even just pop out from unexpected places (a tried and true horror trope) while in the middle of combat to keep you on your toes. Though, I think it might work best if some enemies can shoot at you somehow and remain at a distance, but this sort of combat mechanic requires a lot of hand-crafted elements. Each combat scenario is like a unique mini-puzzle/story on its own, though some could be quite straight forward and simple as well. It would allow for very creative ways of dispatching enemies, just saying.

Anyway, it’s fun to talk about these sorts of things.

@kVella

To be continued…

Can’t wait!

---

Also, you mentioned a variable number of 6-sided dice being rolled. Are you planning on showing the dice being rolled? If so, I happen to have made a JS/CSS die roller for an old Harlowe project that was super satisfying to see in action (looked very believable with a variable number of 3D dice rolling all in a row, wrapping as necessary, randomly tumbling in place and showing the proper results). If that interests you, let me know and I can dig up the code. I think you are using SugarCube, if I’m not mistaken. It should be easy to implement.

[faf]

The idea is very interesting and the miniature map would make it approcheable even if relayed to the player just in plain text format. Well done!

[kVella]

I’m definately interested in the die roller. For the specific game I am planning to use this combat system in the actual mechanics will be taking place ‘under the hood’ and represented to the player within the story text only. However as I develop the system I am necessarily using an UI that can show what is going on more directly. I think of the two types of implimentation as being analogous to a horror FPS that uses a minimal HUD for immersion (player has more limited and implicit information on the gamestate and mechanics) vs a CRPG or tabletop experience where all the information and mechanics are made explicit (player has more complete and explicit information on the gamestate). I think it would be good to have a basic UI that is more akin to the tabletop experience with the die roller, health/stat bars, etc and then elements of that can be removed as desired by the game author.

I envisage this as being basically a minigame within a peice of IF so the combat mechanic is entered into from the general VIBAE system as enemies are encountered although it could be possible to keep a whole game within the combat system as a standalone game a bit like a text based ‘FPS’ that you describe. Spacially what I have works on coordinates and vectors rather than a grid. Currently the player is given the initial coordinates (0,0) by default and the enemies a starting coordinate relative to that in what is currently a boundless and empty virtual tabletop. Somewhere further down the line something like a ‘map’ with bounding walls, exits and things like cover could be implimented.

[Piergiorgio_d_errico]

@kVella

What the player sees is a descriptive representation of the combat space. This is where the harder design task lies.

Concur and agree plenty. because of my actual work (military and Naval historian) I have read plenty of military manuals, from the earliest, 1600s, to the most modern FM’s, and trust me, there’s plenty of pages dedicated to the single point “how to write reconnaissance reports”…

Best regards from Italy,
dott. Piergiorgio.

[Draconis (Daniel Stelzer)]

I think tactical movement and positioning is going to be important, because one of the most common problems for combat in IF is not having meaningful choices (“I don’t want to just type ATTACK TROLL over and over until the dice come up in my favor”), and movement is a lot easier to intuitively explain than different forms of attacks (or attack/block/dodge/parry, or the like).

My experience here is mostly with tabletop games, but in case it’s useful, I’ve seen two main ways games handle this:

• D&D-style, where your exact position on a grid matters. Usually with multiple units to coordinate. Movement matters a lot more, but you pretty much need a graphical display to keep track of it.
• FATE-style, where you have a small number of “zones” you can move between. Movement matters less, but this is easier to explain in typical IF text.

[HAL9000]

Alright, man. Here you go! (It runs on its own in the HTML file.)

My very first D&D dice set was transparent blue with white numbers so that’s what I made the dice look like. You’re stuck in my 80s childhood unless you change the colours.

if-dice-engine.zip (2.2 KB)

---

Technical Notes (click to expand)

I prefer seeing numbers on dice and I wanted them to be slightly rotated, but mostly appear upright. If you want to change them to standard dice with dots (or those cool fate dice), it’s not hard to do, but I’ll leave that in your hands. If you decide to go dot-style, I’d recommend changing the rotation factor to a wider range (currently +/- 15 degrees). The code is straight forward enough. I do wonder if my random number code is “randomy” enough though.

The weirdest thing that I’ll point out is that I targeted the container dice <div> by name instead of ID. This was because Harlowe creates named hooks that I used, but (by virtue of always targeting the last element in the page that matches that name) you can have multiple dice rolls displayed above; like a normal parser text adventure might output and they won’t be affected by the new rolls. Another weird thing is that I use a root variable for font-size and all references of rem units are based on that set pixel size. (1 rem = 24 px in this case.) I like sizing things to be relative to the font size in most cases. Weird. I know.

The other weird things are weird because they have to be. Mess with that stuff at your own risk. You don’t want to know the details of how I tweaked the rolling transformations. Narrow the browser window to see how the dice wrap, like text does. Also, a keen observer will notice that not all dice stop at the same time… oooooooooh.

---

I don’t need any mention if you use it (and others are free to use/change it too). Just remember the little people that helped you out when you’re sitting in your big mansion from the millions made by our your awesome dice combat mechanic game.

Edit: I should also mention that if anyone has any questions about tweaking it or making it work in their project, feel free to PM me.

[kVella]

That looks really slick!

[kVella]

I think the problem with movement when there is no graphical representation of the combat space is that the only meaningful options for the player are to either advance towards or retreat from an enemy or object that has already been described in the story text.

A movement choice such as ‘move two meters along a heading of 135 degrees’ is not going to be meaningfully represented in text unless the text is going for a literal description of the combat space approach (ie; each turn the player is given a complete ‘sitrep’ of each enemy/object’s exact position). That could be an valid implimentation of the combat system but not really for the type of game I am designing it for.

I think that once engaged in melee the game does inevitably turn into ‘ATTACK TROLL’ ad nauseum. Giving the player an option to attempt to break contact in order to create space to use a ranged weapon or perhaps to escape the encounter entirely might be the only alternative to ‘ATTACK TROLL’.

I am not keen on designing a micromanaged melee combat system with options like choosing different attacks and defending moves. I think this may lead to decision fatigue, especially considering that this is intended to be a mini-game and not a standalone experience. I think to avoid too much drawn out ‘ATTACK TROLL’-ing the melee combat just needs to be quite quick and decisive, which suggests weighting the odds towards the attacker.

[Piergiorgio_d_errico]

There’s another handling, the one used in the Bard’s tale series (the 8 & 16 bit ones, not the current CRPG ones), based on the range to target plus the distinction between the front and rear ranks. much more accessible to a text based interface:

there’s X critters 30 feet away, X-Y critters forward, Y critters 10 feet behind

whose IMVHO should be an interesting concept/starting point.

Best regards from Italy,
dott. Piergiorgio.

[HAL9000]

@Piergiorgio_d_errico

there’s X critters 30 feet away, X-Y critters forward, Y critters 10 feet behind

That’s quite brilliant! It’s like a terse radar system description. You da man!

It reminds me of how the old X-Wing game split their radar and shield system into front and back. Notice how the shield indicator on the console wraps 180 degrees in front and behind. The radar system in the upper corners shows half-spheres of targeting data, again for front and back.

I think you nailed it, Piergiorgio!

Extra nerd bonus points for people who can identify the model of ship being flown.

[HAL9000]

I also think movement (in these in front/behind fight scenarios) should be limited to advancing or retreating. It might be advantageous to advance while shooting enemies in front, knowing that you can dispatch them in time, giving you more time to deal with those on your tail. This would create a real ebb and flow strategy with a few different types of enemies: slow/fast moving, melee/ranged attacks, weak/strong attacks, fragile/tough armour… let alone special abilities that some may have. (Spits thick ooze at you restricting your movement for a turn, etc.) Besides, lots of board games have linear movement, like snakes and ladders, stock ticker, trouble… linear movement is still very much a boardgame mechanic.

There’s also the idea that you are advancing toward certain environmental objects as well. Like, if you make it to the tree, you could climb it and blast enemies from above. I don’t know, but it’s a solid foundation for building the illusion of free-roaming combat, I feel.

@kVella If you like Piergiorgio’s concept and you want to have a visual/radar indicator that only supports the content of the text descriptions, I’m well versed in SVG vector drawing and manipulation. It wouldn’t be hard to make a radar that reflects the monster location data. However, if you’re showing the dice being rolled in a long line amongst the prose, you could do a linear radar without SVG, kind of like…

…and then it’s just a graphical sliver amongst the story prose (maybe make the center icon be the player from a side view and flip the image to show what’s in front and what’s behind more clearly – I have no idea why I used a Space Marine helmet ); no different than seeing a long line of dice rolls. I could see something like this actually being used as a proximity piece in an actual boardgame, while scenario/encounter cards are drawn from a pile.

Anyway, I hope that gives you more ideas to chew on.

Edit: The advancing/retreating linear battle movement works really well when you consider that a fight might happen when you move in a compass direction to a specific location. Then while traveling to that location, you are either moving toward or away from it. You basically fight your way to your destination.

[kVella]

My current plan is to give the player three zones of awareness. First there is the focus which covers one enemy, usually the enemy that was last engaged. This is basically the direction the PC is facing. Then there is the Field of View which is of course centered in the focused enemy and thirdly the area outside the field of view to the back of the player. Each zone will be given a level of intelligence:

INTEL ON ENEMIES
INT LEVEL	Distance	Movements	Identity
0	Unknown	Unknown	Unknown
1	Vague	Vague	Unknown
2	Estimated	Vague	Known
3	Exact	Vague	Known
4	Exact	Exact	Known

The implimentation I am trying out for instance will assign intelligence levels to the zones like so:

SITUATIONAL AWARENESS
ZONE	INT LEVEL
focus	3
Inside FOV	2
Outside FOV	1

Examples of descriptive text based on the intelligence levels:

INT LEVEL 1	From somewhere behind you hear something moving in the distance
INT LEVEL 2	The green goon continues to approach you menacingly. They are still some half a dozen or so meters away in the middle distance.
INT LEVEL 3	The red goon is closing in on you rapidly. They are now only three meters away.
INT LEVEL 4	The blue goon advances another 2 meters in your direction. They are now only two and a half meters from you.

The only time the player gets a complete sitrep would be at the beginning of the encounter. Once an enemy is focused the zone system will be in place. The player can shift focus by choosing to attack enemies who are behind them, therefore turning the player around. There could be a penalty for turning perhaps, depending on how punishing that would be.

[Zed (Zed Lopez)]

I think a good choice for survival horror would be to not make the representation of injury public. Report that some injuries are mild or serious or grievous, and some leave you bleeding, bringing you closer to collapse… but don’t let them know how close to dropping they are.