PITVYPR Dev Blog #4: Turn-Based Combat to Simulate Real-Time Coolness
Hello!
I have been doing some reflection on the Turn and Time system in my ASCII Roguelike, PITVYPR: Not only its implementation, but also the effect it achieves in gameplay. That said: I think this article will provide an interesting opportunity for understanding the kind of power-fantasy that the game is inevitably pointing towards.
The System
Okay, so, what actually IS this system? Well, its a fairly common implementation of turn-based combat in roguelikes: The Staggered Turn.
Staggered Turns work pretty simply: Each turn is split into a number of arbitrary time-steps, and Actors are placed somewhere within the range of one turn. In PITVYPR's case - turns are made up of 100 Time Units. This is completely arbitrary, but the 100 number is nice and round, and allows me enough variation without needing to make time into a non-integer value. At the 100th unit, a Sentinel is placed. All of these Actors, including the Sentinel, are placed in a queue ordered by their time value.
Actors take their turns, which involve performing an Action, in the order set within the turn. For example, a turn order might look like this:
Player: 0
Rat: 14
Ogre: 36
Grenade: 50
Sentinel: 100
First, we take the Player from the queue, who performs an action as input by the GUI/Keyboard. When an Action is Performed, the casting Actor is then placed back into the queue based on the following:
time = time + ActionEnergyCost
So, if an Action took 100 energy, the Player will be placed back in the queue at 100, where the sentinel is. Since all new queue items go behind those of the same time value, the new turn order would look like this:
Rat: 14
Ogre: 36
Grenade: 50
Sentinel: 100
Player: 100
Then, we'd dequeue the Rat, who would then take his own turn. Let's say that the rat has quick movement, and can move once every half-turn - meaning its Move Action costs 50 Energy, the new turn order would be as follows:
Ogre: 36
Grenade: 50
Rat: 64
Sentinel: 100
Player: 100
When the Sentinel is dequeued, we first subtract 100 from all time values in the queue, and then place it back in the queue at 100.
Pretty simple, right? This system gives a fair amount of flexibility for Action balancing and cost, and still gives the Player the need to react to unforseen, immediate problems that occur in the turn order. It also allowed for actions to take more than one turn of energy, leaving Actors more open to punishment if they made a bad decision.
Another neat property of this system is the ability to have Queued Actions that are placed within the Time Queue. This allows for multi-stage attacks or commands (Cool for boss-fights, and also infinitely useful for Movement along a path: just queue each individual movement in the action queue).
Issues
While no issues have come up for me yet, I will be looking out for them in playtest with people who, unsurprisingly, do not know the ins-and-outs of the mechanics of this combat system. Mostly, it will be an issue of information:
What I mean by "information" is the how much, exactly, a player needs to know about Turns in order to feel as though they are making effective decisions. Of course, the more the better for a lot of games, Slay the Spire comes to mind as a game that provides the player with near perfect information about enemy attacks before turns. But, I wonder if such an approach is good for PITVYPR? It's something for me to consider as things develop. I plan to provide a lot more information than is currently available, as well, in the form of monster information pages. It is possible, too, to make a kind of simple queue vision if needed, but I will hold back on cluttering UI until such a thing actually presents itself as a problem.
The Power Fantasy
What I find most interesting about this approach to combat is how it is, in essence, a “Frame-Perfect” Real-Time Combat System. What do I mean by this? Well, in a real-time system, the player is challenged to react to dangers as they are displayed on the screen, giving them a certain amount of time (coloquially “frames” or, more technically, “delta-time”) to respond: dodge, move, attack, etc. They test a player's quick-thinking and reaction speed. Games that achieve this well can be found everywhere: most action games are real-time now. All of the Souls games, as well as Monster Hunter, and about a million others do real-time combat not only excellently, but also in many forms.
So, how does the “frame-perfect” part of this system come into it all? In a Staggered Turn, you have unlimited time to react to the presented dangers when it is your turn to make a move. The game is pausing when it is your turn to affect things. And, giving actions a certain time cost turns them into, almost, having a simple form of Frame-Data, a term coined from Fighting Games (Street Fighter, Tekken, GG, etc). While not as complex as a fighting game's data - what with their wind-ups, cool-downs, iframes, etc - the principle is the same for our attacks, with a certain Damage, Area (akin to a Hitbox), and cooldown time (Recovery Frames)
This realisation brought to mind one of my favourite games: YOMI Hustle. YOMI Hustle is a “Frame-Perfect Fighting Game" where you and a friend play, effectively, a 20-minute long game of rock-paper-scissors with fighting-game movesets, and then get to watch everything back in real time. It is a lot of fun, and I think that we can draw a line between YOMI Hustle and the Staggered Turn approach that is being used here in PITVYPR. The effect of such a frame-perfect fighting game is the chance to make informed decisions about a wide number of factors, and the same effect is present in the staggered turn.
The fantasy that the Staggered Turn System may promote, then, is one of overcoming challenges with your head, as opposed to your reflexes. What comes to mind, for me, is a number of potential experiences along the lines of:
“I was up against X, so I chose to do Y. But, all of a sudden, Z happened! I thought everything was over, but I remembered that A can B, and I used it to C and escape danger.”
Or, maybe:
“X tried to Y, but I remembered when I saw Z do Y before, and it left a window that would've let me do A if I'd had it. I used A, and got through everything without taking any damage!”
Hypothetical situations such as these are what I think such a system really angles itself towards, and they illustrate the type of experiences I will attempt to design the Demo for as I continue. Mainly, I will be focusing on emergent results of simple Actions, making experimentation exciting, nervewracking, and rewarding. If I can make experimentation fun, and push a player towards doing so, then I think PITVYPR will be in a pretty good spot!
If people want to know more about the technical implementation of Staggered Turns that I used, I am happy to discuss it in a future article. But, I figured a high-level talk on the approach and design was good for now, and you can find further reading on implementation elsewhere that will be written far nicer than I could ever put it. Any thoughts on the system, your own turn-based systems or ideas, or thoughts on how gameplay links to power fantasies and experiences in all genres, please comment!!
I ended up revising and completing this devlog over a fairly extensive development period for the Demo/Prototype, and have added a lot of things to the game as of now finishing up this piece. So, with regards to what I will write about next, I believe that a discussion of the Action implementation itself would, while being a bit technical, be a nice primer for understanding some of the strange UI and the (in my opinion) cool JSON-Based Implementation of Items in another subsequent article.
Here is a screenshot of the new UI and layout, in all of its 16:9 aspect-ratio glory: Notice that the ACTIONS panel has moved to the lower/centre left instead of the lower right? There are also a few extra panels in there now, mainly the INVentory, TURN information table, and a newly blank corner that is, currently, wasted space. UI Design is not my strongsuit. Fun Fact: The TURN table is, effectively, a visualization of the Staggered Turn Queue that we spent half of this blog discussing! You can see the Zombies' upcoming turns in relation to the Player (@)'s current turn. One side-effect of this system that I find funny is the inflated Turn values, giving us a Turn of 11,678 after moving halfway across the map! (Technically, this is the Time value, not the Turn, which would be denoted by the Sentinel at 116. But that number is pretty arbitrary unless we have world-based/sentinel-based effects that are strictly tied to the Sentinel's Turns, otherwise its just a blurry measuring stick)
