Speeding up the Spartan Engine, Part 2

imageedit_6_9426372647

Introduction

Last week, I took a look at the idea that games based on the Spartan Engine, especially Dystopian Wars (DW) and Firestorm Armada (FSA), take too long to play. I’m not going to repeat myself too much in this post, so please take a look at last week’s post before reading this one if you haven’t yet. To summarize, I concluded that DW and FSA should probably be about 33% shorter; so, if an “average” game takes about 3 hours, it would be better for it to last more like 2 hours. I stopped short last week of getting into specific changes that could be made to the Spartan Engine to reduce play time, so that is going to be my focus this time around. The approach I’m going to be taking is more of a brainstorming list; I would not expect all (or perhaps even most) of the changes I’m proposing to appear in a single game. Indeed, if all of the suggestions I’m about to make were implemented at once, I think the result would probably be a game that is a little too simplified to satisfy fans of the existing game (like me!). In line with my post on the Spartan Engine, I’ll be talking about proposals for the Core Rules, followed by some ideas on changes to the various modules. Along the way, I want to share some of my thoughts on exactly what makes games of DW or FSA take so long.

What Takes So Long?

Over the years, I have developed some ideas about what are the biggest time sinks in the Spartan Engine.  In the next few paragraphs, I’m going to discuss the ones that strike me as the biggest culprits. Now, a couple of disclaimers are in order. First, this list is not all-inclusive; there are plenty of other things that one might point to as taking a lot of time in a game turn. Second, the things I’m listing are not necessarily problems; in fact, the time spent on some of these time sinks is likely where a lot of the appeal of Spartan Engine-based games derives from. That out of the way, here is what I think takes a lot of time during a game turn.

The Interplay Between Movement and Shooting

I have seen a number of players note that the movement portion of a unit activation in FSA or DW takes a substantial amount of time to resolve, seemingly more than it should. This in turn has led to the targeting of the movement systems in both games by Spartan (see DW Fleet Action using only a single turning template) and fans alike. Superficially, this makes sense; if it is taking longer than it should to move models around the table, then clearly something about the movement system is too clunky and needs to be streamlined. There are certainly some reasonable changes that can be made to the movement system of the Spartan Engine, but I contend the actual mechanics behind moving models are not really to blame for the amount of time it sometimes takes to execute the movement step of activation. Instead, I think the problem actually lies with the shooting mechanics. In particular, the fact that many models in FSA and DW have confined firing arcs (especially fixed channels) and multiple weapon systems with conflicting arcs (i.e., some weapons with fixed channel fore and others with broadside arcs) means that the exact positioning of a given model has to be carefully thought out, checked, executed, and often fine-tuned. This is made even more challenging when having to deal with multiple ship squadrons, and line of sight (LOS) blocking terrain and models. Balancing all of these factors can often lead to “analysis paralysis” as players strive to maximize the effectiveness of their units.

Shooting Complexity

Resolving the shooting step itself is often a non-trivial task. The process of calculating the amount of dice for a linked attack dice pool, properly adjusting that number for model damage, determining the correct to-hit number, determining the effects of ordnance types/weapon types/coherency effects, etc takes an appreciable amount of time and mental horsepower to complete. Granted, learning and understanding this process is one of the core skills for players of Spartan Engine games, and it can go pretty quickly with sufficient repetition. In fact, I suspect (though I have no hard evidence to point to) that familiarity with the mental math and applicable special rules associated with compiling dice pools is one of the main ways that active gaming groups have managed to cut down on the playtime for their games of DW or FSA.

Activation Selection

Unlike some other game systems that employ some form of initiative rating for various units to help determine activation order, the Spartan Engine leaves this decision making process entirely in the hands of the player. This permits a lot more tactical flexibility, but it does mean that players are often faced with difficult decisions on which squadron to activate next, and can generate bouts of analysis paralysis. This is most often seen during turns 2 and 3 of an average game, as it is these two turns where games can often be won or lost.

How to Speed Up the Games

So, now that I’ve covered in general terms some of what I see as the causes for the slower pace of games using the Spartan Engine, here are some of the things that I think can be done to make the game play faster. As I mentioned earlier, I’m going to give some ideas that fall more under what I’ve defined as the engine’s Core Rules, followed by some ideas regarding Modules.

Core Rules

  • Implement rules that provide some restrictions on what squadrons can be activated when. This could be a full-blown initiative system (think X-wing), or it could be something like how DW deployment works, where squadrons are activated in descending size order. The goal, though, would be to limit player choice in this area to reduce analysis paralysis.
  • Get rid of fixed channel arcs! This one is more of a personal pet peeve of mine; I find them inconvenient and somewhat annoying to deal with. To Spartan’s credit, they seemed to have recognized fixed channels are a bit more trouble than they were worth, as later versions of FSA and DW seemed to use them less and less. In most cases, fixed channel arcs can be replaced with a 90 degree or Broadside arc with minimal impact on the power level of a unit. If some sort of concentrated narrow arc is needed, I would put forth a 45 degree arc as a good option.
  • Reducing the number of weapon systems on models. Many models have 5 or 6 different weapon systems/mounts, and trying to get as many of these weapons on target as possible is one of the things that I think drives players to take longer during the movement step. For example, perhaps a cap of 1 weapon system on a frigate, 2 on a cruiser, and 3 on a battleship could work. As a balancing measure, the AD might need to be raised in some cases in order to keep the relative damage dealing capability of models roughly the same.
  • Simplifying link-fire mechanics by removing the need to subtract damage from the base AD value of the weapon’s profile. Instead, the damage on a model could simply be subtracted from the number of hits that result from an attack. This is a mechanic that we have seen in DW FA, FSA TF, and in Halo Fleet Battles, where it seems to work pretty well.

Modules

  • Simplify carrier mechanics. Carriers are a major part of DW and FSA, and I can’t imagine either game without them. However, as their currently implemented in DW 2.5 and FSA 2.0, their rules tend to have a disproportionate impact on the flow of both games. The “extra weapon system” method used by FA and TF shows some promise in this area. The big thing for me is that I would prefer a system that doesn’t completely shut down an avenue of attack (like interceptors and torpedoes in FSA), and also isn’t abusable as a way to dictate the entire flow of the game (as in DW 2.0).
  • Reduce/consolidate the number of MARs in each game. There has been a bit of “MAR Creep” over the years, where more and more have been added to both FSA and DW, and some of them are very under-used and/or are starting to overlap with other game mechanics. I think some pruning in this area would reduce the amount of stuff that players need to remember during a game, speeding things up somewhat.
  • Reduce terrain types/rules. In both DW and FSA, there are a lot of different terrain types, each with their own accompanying special rules and interactions. As with MARs, reducing the different types of terrain by a few types might provided for a more streamlined (and hopefully faster) experience.
  • Limit the number of weapon/munition/coherency effect types. Granted, this is something that impacts DW more than FSA at the moment, but having so many different special rules for so many different weapons types has invariably resulted in a lot of rules look-ups during my games. Taking away a few would make that easier.

Conclusion

As I stated at the beginning, these ideas are the result of me brainstorming on how to have FSA and DW play faster (I bet you wish you had an umbrella by now!). I wouldn’t want all of them to be implemented at once; I think if Warcradle was to do that in future editions, it would simplify the games to the point that they wouldn’t have the same feel anymore. However, implementing one our two would, I think, streamline gameplay nicely, while still remaining recognizable to the established fan base. I hope that this post inspires my fellow fans to come forward with ideas of their own!

Until next time…

 

This entry was posted in Dystopian Age, Dystopian Wars, Space Naval Gaming and tagged , . Bookmark the permalink.

1 Response to Speeding up the Spartan Engine, Part 2

  1. avatar Mike says:

    Several good points and suggestions here. I hadn’t thought much about how the ‘analysis paralysis’ of shooting might be to blame for the game length. You are correct on the ‘MAR Creep’ that slows down the game. For a while (at least when SG was still running things) the answer to game issues seemed to be add a new MAR and that will fix things. Having MAR’s is one of the attractive features of the game, but we do need to reduce the number of them.

Leave a Reply to Mike Cancel reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.