GOG.com
Donate to Codex
Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
u7buy.com

Underrail 2: Infusion Dev Log #9: New Combat System

Click here and disable ads!

Underrail 2: Infusion Dev Log #9: New Combat System

Development Info - posted by Infinitron on Wed 25 December 2024, 20:51:03

Tags: Stygian Software; Underrail 2: Infusion

https://stygiansoftware.com/infusion/devlogs/9-new-combat-system.html



In Underrail's design I drew from what I considered to be the high point of western RPG tradition and tried to build up and out from there. This was the case with combat system as well. I adopted the action/movement point design with sequential turns that worked well (enough) in a number of classical RPGs, adjusting it for my specific needs. Over the years, however, I came to realize that, while it's a solid way to approach party-based combat, it has some significant disadvantages when it comes to single character RPGs, even more so when coupled with free-form exploration:

Reactivity, or rather lack of it. As Underrail veterans know all too well, if you happen to stumble into combat with multiple powerful enemies and lose an initiative roll, you are going to get "100-to-0-ed" more often than not, probably getting stunned in the process as well. This is because giving a long turn to a powerful character in this system, without any opportunity to react to or counteract their actions, puts the party on the receiving end into considerable disadvantage. While in party-based combat, you could tolerate having one of two of your characters nuked or temporary disabled, if you are controlling a single character, this is often an unrecoverable situation. To a lesser extent, same is true with the player character getting the jump on the NPCs, though often, unlike the player, they can afford to lose a unit or two.

Dual time modes. Every active thing in the game requires two implementation for polar opposite modes. One is the real-time mode where things happen simultaneously and can and should be reacted to immediately, and the other one consists of long sequential turns where each actor can only react to the end state of the previous turn. This goes beyond the combat itself and goes into general AI and the behavior of the environment itself.

Sluggishness. This system scales badly with large number of participants if the player is controlling only a single character. The ratio of player waiting to player acting gets worse and worse with each NPC added to the encounter. Even worse, because there is a need to keep all the combat turn-based in order to avoid having to implement and maintain real-time combat AI, sometimes in Underrail you are just a passive observer of third-party combat.

The new combat system is designed to address all these and more. It is a combination of traditional roguelike combat, where turns are still sequential but short with atomic actions, and simultaneous turns combat. So here is the basic rundown of how it works:
  • Under normal conditions, game is in real-time mode.
  • When required due to the presence of hostile entities, the game will transition in and out of combat mode. Usually player will not be able to activate combat manually except under special conditions.
  • In combat mode, everything is paused until the player performs an action. The action takes a certain amount of time and this amount is granted to all non-player participants to use for their new or ongoing actions (such as moving, attacking, activating special abilities).
  • When exactly this time is granted to the NPCs is critical as sometimes they might act immediately to interfere with the player. This time may also be granted in bulk or in smaller amounts (e.g. channeled abilities such as bandaging).
  • Player is free to act and give additional time to NPCs unless he is "blocked" by an ongoing relevant NPC action. An enemy trying to move out of the player's melee range is relevant and the player must "respect" their available time; a neutral crab roaming on the other side of the map is not relevant and it can do what it pleases.
  • NPCs usually won't block each other. Meaning they will act simultaneously for the most part.
  • Because NPCs are just executing their real-time AI while stopping for time allowance, there is no need for a separate AI implementation, and they can also take the time when player is acting to "think" about their situation. That is, their AI state machine is running at all times.
Hopefully this grants you some clarity regarding what you saw happening in the combat demo. This is the basic gist of the system, but, of course, the devil is in the details. The amount and the, uh, timing of the time transfer between the player and NPCs, as well as determining which actions (and under which circumstances) are simultaneous and which are blocking (sequential) - these things are going to be critical. I am going to tweak and shuffle these things throughout the rest of the development with the aim of making combat as fast, fluid and fun as possible while still keeping it cerebral and tactical. You should be able to go fast and furious when you can and as slowly and deliberately when needed. And you should be able to transition between those seamlessly.

The extent of the combat changes goes further than just time management, though that is the most radical one. There are others factors and considerations, such as focus, momentum, stamina, range, different speed categories to replace action/movement points modifiers, different combat stances and attacks, etc, etc. I will go into more details regarding those in future dev logs.​

There are 29 comments on Underrail 2: Infusion Dev Log #9: New Combat System

Site hosted by Sorcerer's Place Link us!
Codex definition, a book manuscript.
eXTReMe Tracker
rpgcodex.net RSS Feed
This page was created in 0.040382862091064 seconds