Archive for Dirk Knemeyer
I've long considered myself a "wargamer". I owned Squad Leader as an eight year old; I've played my fair share of "monster" wargames over the years. But despite calling myself a wargamer, and despite buying Case Blue and other wargames in recent years, I realized that it had been a long time since I had actually played a wargame more complex than Command and Colors: Ancients. Despite continuing to act like a wargamer in terms of identity and buying choices, I did not choose to spend my time playing wargames. Ever. At all.
Thinking about why, the world has just changed. In the gaming hobby, fast-playing Euro games have introduced mechanics and game structures that deliver a tight experience in what can be an order of magnitude less time than the wargames I used to play. In the broader world, the rise of the Internet has conditioned me to expect to wait mere seconds when jumping between very different content, games or other experiences. The pace of those games I used to love now seem glacial. Whereas I used to say "when I retire I'm going to break out World in Flames and have a great time!", now I find myself with no interest in those games. The world has changed and, as a result, so have I.
That was a long-winded way of leading into our mindset when designing map construction and unit movement in the War Stories system. The old tropes of tactical wargames that I know so well from years gone by - consulting movement ratings, applying terrain modifiers, and inching my units forward hex-by-hex - instinctively felt that it needed a reconsideration. Of course, that is easier said than done: the system was created by smart people because it worked.
In traditional tactical games, the least fun and most cumbersome part of the process is going from "game start" to "getting my units to the positions I really want them at, and/or being interrupted from doing so". Yet many scenarios in traditional games first require you to traverse thru relatively meaningless hexed terrain in order to reach your destination, or enter an opposing unit's field of fire. We wanted to cut that, what I would call "boring", part of the battle out.
In traditional tactical wargames, the hex is the base unit of measure. Along with the geometric benefits of hexes from a mapmaking and field of fire perspective, they also help to regulate both movement and firing range. Representing a particular distance, and each being further governed by the "terrain" that they represent, hexes allow a variety of complex rules to be layered on the action in relatively lightweight ways. The challenge, in innovating from the hex, was to preserve the benefits conferred by the shape into any new solution.
Three things were quickly obvious:
1. Maintaining hexes or a near 1-to-1 equivalent was important for regulating combat. Particularly at the scale we were planning - 50m "per hex" - this level of granularity was necessary to allow realistic battles and determining results across a wide variety of weaponry.
2. Our solution had the opportunity to take many factors previously governed by charts, map symbols and unit modifiers and bake them into the terrain solution itself.
3. Not only did movement not need to be regulated per the hex, it probably shouldn't be regulated per the hex from a realism and playability perspective.
So, we needed a new system for movement, that supported the old solution for combat, and also solved for the myriad of terrain modifiers and movement allowances at the same time. At its core, our solution is to replace hex-based movement with area-based movement. This accomplishes a few things:
- Have "areas" be varied in size and shape, each representing one "full" movement inclusive of terrain and other factors
- Enable units to get thru "irrelevant" terrain more quickly, clipping across entire areas as opposed to hex-by-hex
- Because there are substantially fewer "areas" on a scenario map than there would be "hexes" on a comparable map, we can integrate unique fog of war characteristics (these will be discussed in a subsequent article)
The way area movement works is pretty simple. Here is a plain, base "map section" for War Stories (all graphics are simply prototypes):
A plain, generic base map section is made up of seven "open ground" areas (indicated by the larger lines), each area made up of seven hexes. Open ground does not have to be seven hexes in size, but that is the "typical" open ground area. While that is the base for our map sections, in most cases the sections used in scenarios will already have other terrain built into them, like this:
Individual hexes remain recognizable - a requirement for measuring fire range - but the larger lines regulate movement. There are thus only eight areas for movement on this map section: the five "open ground" areas around the top, right and bottom edges, and the three fields in the center-left. The pond is impassable. If you are in one of these eight areas, to move to a different part of that same area, requires one of the two actions that a "ready" unit has. To leave your current area and enter an adjacent area on the shared side it is also one action. To leave your current area and cross the adjacent area, it costs both of your actions.
That's the extent of it. Units do not need movement ratings or allowances. The areas, by their very construction, regulate the correct uniform distance a unit should require to traverse that type of terrain. This allows us to also ignore terrain modifiers, as the terrain size and shape itself represents the modifier. It allows unit movement to shift from:
"This infantry is going to move. It has a base movement of 4. The first hex is open ground but after that it is trees. What is the modifier for trees? OK, so it will cost me three to cross the open ground and the first tree hex. Can I get into the next tree hex since I still have one point left, even though it costs two to move into trees? No, OK well I will stay there, then."
"This infantry is going to dash across this open ground and get to the edge of that field."
This prototype map section, like all of our pieces of base map terrain, only contains terrain that does not block line of sight. If it is on the map - if it is "flat" - then you know you can see or shoot over it. As such there is absolutely no need for a player aid or rulebook section to cover terrain. The map, in its essential state, communicates the movement regulation and line of sight.
So, what about trees and hills and buildings? Stay tuned...
PS [from Michael W. Tan] We'll post images that illustrate movement more clearly once we get the latest files from our artist Heiko.
Working with Mike on the "War Stories" system has been an enjoyable process. I kind of liken it to being a father. Note that I chose the word "father" instead of "parent" very carefully. See, as a father, I have watched my wife do all of the hard work. The DNA of the final little one is ultimately about half mine, but the hard work and time was done in those cases by my wife or, in this case, by Mike. While the "father" sounds like pretty good work if you can get it, I do like being the final decision maker on my own designs. So, the process of compromising - and ultimately letting Mike make the final call in many cases when there is a conflict - is not necessarily a comfortable one. It has all been a learning process, but one I am surely enjoying.
Mike is a legitimate World War 2 expert. Whereas I have what I suspect is a "typical Grognard" level of knowledge about WW2, Mike knows more about the subject than any of my university professors. It is THE historical period that he cares about and studies. As such, the bulk of his historical research, game playing, and game design efforts have been focused on Sturm Europa on the grand strategic level, and now War Stories on the tactical.
When he and I first started working on this project together, he already had the old Pocket Armies system he showed in previous posts roughly conceptualized. He had done the heavy lifting around all of the equipment, from armor to guns to speed and more. He had concepts for it to live in mini-CRT's on cards. At that point we came together and collaborated pretty fully at a "making it real" creative direction and system design exercise. We would have long, working sessions, hacking thru major aspects of the game - designing cards and player aids one weekend, brainstorming events the next, talking about assets the next. In between, Mike would do the heavy lifting on the details, and I would work on my other games.
My role has been one of creative director and designer, whereas Mike has been more of the lead designer and engineer. Now, don't take that to mean Mike doesn't contribute to the big ideas; in the way we cooperate, he wears the hat of "this game is going to be chromed to the max" while I wear the hat of "this game is going to be as elegant and streamlined as possible". The consequence is that Mike's starting point is "I'm going to get everything they have in ASL into this game, but more elegantly" whereas mine is "This will play faster and easier than Axis & Allies Minis but with more chrome than Combat Commander and Conflict of Heroes". We both believe in what is motivating the other, we just each ultimately service a different primary end.
Those are VERY, VERY different mindsets. Mike is committed to heavy wargamers being shocked and delighted that (some arcane thing) is in a lighter game. I am committed to non-wargamers feeling like they are playing a wargame on their PS3, laughing and having fun with friends. In the design process, it lets me say things like "There cannot be more than three range bands on the result cards" and "There cannot be more than two modifiers to those range bands". Because I don't care what gets lost chrome-wise. I intuitively know that, within those constraints, we can play faster and with more detail than other games on the market, with a minimum of clumsiness. That leaves Mike to do the harder, and ultimately incredibly powerful, work of fitting all of the chrome that he knows will really get its hooks into serious wargamers into those constraints.
Now, of course not all of my sweeping declarations of what we "needed" to do proved possible. But from my perspective, we had to start on that end. It is about playability first, stretching it only so far as we are able in order to "chrome it up" to some minimum baseline level. Mike balances that by demanding that the constraints allow a certain level of chrome to always get in. Where we end up as a consequence is what we hope gamers will see as a pretty sweet balance.