Movement Shenanigans

 

lightningrider01aMovement is a highly underrated and complex aspect of a tabletop RPG. Being in the right position can mean the difference between you being able to strike your foe or them being able to strike you. Every tabletop RPG goes through some pains to try to balance the idea of making movement simple against it being tactical and Chronos is no different. I needed to make movement an important part of the game, but balance it against the bookkeeping involved.

It wasn’t readily apparent to me at the time, but I had a notion about movement on a battlefield that was my biggest stumbling block it. This notion set me back developmentally for a while and this stemmed from my experiences playing other roleplaying games from Hero Quest to Dungeons and Dragons 3rd Edition to Descent. I thought of movement in squares on the battlefield. Some of you might also think of them in Hex Grid format, but I never played in one of those games. Squares were ingrained into my mind and the battlefield I envisioned was always covered in them. It wasn’t always like this. I used to be a 2nd Edition Dungeons and Dragons player as well and we never used miniatures or squares, we just talked out our positions on the battlefield and it worked fine. So why was I so hung up on squares? Because I liked them. I found out quickly how difficult this was to implement with the Real Time Combat Engine (RTC Engine).

Trying to keep the Square Grid

The battlefield was always covered in square grid marks for me and the task I set myself to solve was how I could make those grid marks work in RTC Engine. I started with a movement statistic of X feet per Time Interval (TI). When someone wanted to move, they would count how far they wanted to move and then added all the TI required for them to get to that square. This worked 80% of the time and that was part of the problem. It worked most of the time, so that kept it lingering for far longer than I should have let it. The other 20% of the time it was difficult to manage and very time consuming. It killed the flow of combat when multiple people began to move at the same time. It got even worse when a chase scene occurred. It was really ugly when people wanted to move TI by TI to stay out of reach of a particular combatant. It turned out that there was no solution within my experience to allow me to implement a traditional square grid battlefield within RTC Engine. It was beyond my creative vision. It had to be scrapped.

Inspiration arrives

Sometimes, all it takes is taking a step away from something to get a good perspective and it sure helps when you get a nudge in the right direction. I received both when I decided to step away and start playing the Dresden Files RPG based on the FATE system. I am not an expert on the FATE system by any means and I didn’t play it for a very long time, but it helped me get over the need for a battlefield filled with square grid marks. Realization dawned on me like the sun rising in the morning. What if I didn’t focus on how “far” I could move per TI, but rather how “fast” I could move from place to place? I started to think, what if I didn’t need to think in small squares, but “big” squares? What if I didn’t need squares at all, but instead thought of things as Battle Zones? This began the wheels turning in the direction that RTC Engine currently implements.

Big Squares vs Little Squares

I learned that starting with how I was going to handle movement was not the right question to be asking. It should have been how am I going to set up the battlefield. The notion of little squares in a grid was the hang up before, so I changed it into very big squares in various patterns to remedy that. The concept of Battle Zones was formed. With Battle Zones I could keep some of the tactical aspects of movement, while injecting a large degree of simplicity for movement. Movement “within” a Battle Zone became irrelevant, only movement “between” Battle Zones mattered anymore. With that, I could focus on making a Move Action a simple rule such as: the time it takes in Time Intervals to move from one Battle Zone to the next. This vastly improved pacing and timing in combat. Now, when someone said they were going to move, I could have an Action Time assigned to that and those that were faster could shorten that time to smaller and smaller levels. Let me illustrate the scenarios:

Little Squares Movement = 5 Feet per TI, each TI the Combatant moved 1 square. If they wanted to move 50 feet, they had to move 10 squares. After each TI, they might have to pause as a different Hero’s action occurs. Total Action Time 1oTI, required 10 touches of a miniature to get it where it needed to go.

Big Squares Movement = Move to adjacent Battle Zone with an Action Time of 10. When 10 TI passes, they move to the next Battle Zone. Total Action Time of 10TI, required 1 touch of a miniature to get it where it needed to go.

If you think about these two scenarios, you can see how much simpler it is using the “Big Squares” method that we call Battle Zones. Movement is still important because some actions require you to be in the same Battle Zone to occur, but the finer details of how close one person is to another is no longer necessary. Distance becomes abstract.

Battle Zones of any Shape

The idea that the shape and form of the Battlefield was the main factor behind how movement works started to give me more ideas. For one, we didn’t need to have have them as squares, they could be any size and shape that I wanted them to be. They could be triangles, pentagons, long, short, big, and small. The formation of the Battle Zones added new dynamics and new movement tricks that I could deploy to keep the movement interesting while still keeping it simple. Battle Zones would be sections of the Battlefield that fit a specific purpose, like a bridge, a road, a forest edge, a field, a common room, a bedroom, and so on. With this new mentality, I could imagine the battlefield and then divide it up into logical partitions that would have similar properties. They would be defined, but their size could be nebulous. Within that Battle Zone I could apply terrain features like “muddy” or “hot sand”, making footing precarious or uncomfortable. I could define how Area of Effect spells would function and the eligible targets much easier as well.

The Dynamic Battlefield is Born

All of the concepts we have summarized combined to form the Dynamic Battlefield Concept for Chronos. Our movement shenanigans conundrum ended up being solved by the redefining the field of battle; moving away from the square grid concept to the Battle Zone concept. I called it the Dynamic Battlefield to emphasis that the field of battle should be as much a part of the encounter as the abilities you can use within it. With the Dynamic Battlefield, movement was an Action to be performed in one step rather than multiple steps. I could find ways to modify movement in a logical manner by adding or subtracting seconds to the Action Time. On top of that I created the Three Pillars of the Dynamic Battlefield: Terrain, Environment, and Formation. Terrain involved the physical aspects of the battlefield such as rocks, tables, ground cover, and so on. The Environment Pillar covers rain, fog, visibility, and the like. Formation covers how to place your Battle Zones and how arrangement affects movement, actions, and targeting.

To illustrate these Pillars in action, lets imagine the smoking ruins of a keep, in the harshest depths of winter. There would be an open courtyard, the remains of a few battlements, and the smoking rubble around the keep. On top of that, the wind is blowing and snow is falling. Breaking that down, we have at least 3 Battle Zones: the open courtyard would be snow covered and slippery because of the heat from the dying fire; the battlements would be ice covered and hard to traverse while granting a height bonus to attacks; the smoking rubble of the keep would be precarious to walk through and possibly causing damage from touching the still burning rubble. Lastly, the entire battlefield has high winds that make range attacks difficult and snow that reduces visibility to the adjacent Battle Zones. All of this combines to make a very dynamic battlefield that gives options for high ground, ways to slow the progress of foes, tactical reasons to use the snow blind to your advantage such as shielding you from deadly attacks. When you have this level of description for a battlefield, it also makes it easy for the players to hold it in their Mind’s Eye. Three distinct areas of Battlements, Courtyard, and Keep are easy enough to keep track of, so there is no need for miniatures unless you are so inclined. The Dynamic Battlefield is meant to be friendly to both styles of play.

Bringing it to life

In the end, the Dynamic Battlefield has as much or as little life as you desire. It is flexible enough to be used on a battlemat, a whiteboard, or in the “theatre of the mind.” The rules are meant to help accommodate the tactical and keep it simple. With that in mind, I leave you with a look at an example of the Dynamic Battlefield in picture form. Here we have a battle with a giant squid guardian that is protecting an enchantment within a well. You can see with nothing but a blue marker, a whiteboard, and some tokens, you can add a lot of life to a battlefield.

 

Leave a Reply

Your email address will not be published. Required fields are marked *