https://stygiansoftware.com/infusion/devlogs/9-new-combat-system.html "
Dev Log 9: New Combat System As I mentioned in the previous dev log, our next goal with Infusion was to produce a short gameplay video that would feature some exploration and combat. The said video is finally here. This is a big milestone for us as the game is finally in a good enough state to be seen in motion, but also with this video we're revealing probably the biggest (and potentially the most controversial) change - the new combat system. Check out the video below.
Underrail 2: Infusion - Alpha Demo (early alpha build) Before I get into the details of the new combat system, I would like to say a few words about the state of the engine and Infusion's development in general.
I think we are finally at the point where we have all the fundamental visual and gameplay features in a stable and robust state, ready to have the content piled on top of them. Of course, many smaller secondary systems are yet to be migrated from the previous game or re-implemented completely, but these are much easier and faster to develop.
For example, this year I spent a lot of time transitioning the engine from tile-based to voxel-based space, allowing for true verticality, which in turn allowed for free-form movement in 3D space for player, creatures and objects. So now we can have platforms above and below, flying (and maybe later swimming/diving) enemies, dynamic climbing and falling, etc.
https://stygiansoftware.com/images/devlogs/infusion/9/walkmeshes.png But because a lot of other mechanics rely on spatial structure, I had to rework those as well, including movement, sight, light, combat interactions and AI in general. For this reason, this was not the direction I wanted to take the engine in initially, but the more we discussed the gameplay features we wanted to implement in this game, the more apparent it became that no half-measure would suffice.
The story is similar with a lot of visual changes to the game. What often started as a smaller change to the rendering engine, eventually revealed itself as inadequate, prompting me to make a more radical re-implementation.
But in the end I regret nothing. The heavy lifting is now done and both the engine and the game will be better off for it. In the coming months and years, I expect us to make rapid visible progress as we transition from the tech phase to the production phase of the development.
Now onto the combat changes.
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.
So what's next? After we take a short break for the holiday season, we're going to into full production next year. We want to produce more environments, areas, equipment, creatures, more of everything. At the same time I will be working on re-implementing all the basic game mechanics of the previous game, such as lockpicking, hacking, trading, as well as redesigning some of the character progression stuff such as feats and, of course, the leveling system itself.
Our aim is that by the end of next year, we have enough material to create a store page and start hyping the game up properly and gathering those precious wishlist additions. At some point in the future, we are likely to release the game in Early Access, as we did with our first game. At the moment, I cannot give any precise or broad timeframe for when that might take place, so don't ask. What is important for us is that we ensure that the game functions well, that it's fun and that there's enough content so you can get some of your money's worth at least.
In the meantime, stay tuned for more dev logs and follow me on
X, where I post smaller tidbits of development regularly (also, thank you very much for all the positive feedback and support you've shown us there so far).
Merry Christmas to everyone celebrating the birth of our Lord and Savior on either calendar and a Happy New Year!
Cheers!
"
