Just because an idea is good, doesn’t mean it’s good for this game.
All of the designers I know have more ideas than they can get finished, and this is a good thing. It shows a fertile and creative mind. I find ideas are a bit like the hydra of old: get one into a project and published, and two more spring up in its place, begging to be used too. This abundance of ideas makes it very tempting to crowbar as many into each game as possible, and this is a trap.
Less is more is a somewhat trite cliché, but under the rather shop-worn exterior is an important concept. Sometimes taking things away allows the real strength of the core concept to shine through. Sometimes all the extra “chrome” isn’t adding at all: it’s just obscuring the really good parts. Always, the trick is to know when and what to prune.
This is a bit like murdering your darlings, and can often include that jolly concept, but it is more than that too. What I’m talking about is focussing your design on what is really important for this game. In that process of honing you should definitely murder excess darlings, but you should also look critically at everything else too. As I said at the start: just because an idea is good, doesn’t mean it’s good for this game. And that’s the critical point: for this game. Many, if not all, game concepts and rules are great in the right place and a problem in the wrong one. It’s seldom the rule itself that is at fault, merely the juxtaposition of it with the rest of the design.
Quirkworthy 
Also related to this tip and the “murder” one is don’t do stuff just because “other games do it.”
If every WW2 counter and hex boardgame you know has this mechanic to polish your bombs before an artillery strike, and you’re making a c&h WW2 game, it doesn’t necessarilly mean your game should have it also. This happens a lot on RPGs, where some designers add stuff out of inertia rather than thought and it just clutters the design with no real purpose other than a mistaken view of “it HAS to have this.”
The opposite is true as well though, if something works then not using it just not to be like another game is also not ideal.
I can’t help but feel that KoW not locking units in combat suffers from this.
Both points are true: slavish inclusion is as bad as removal just to be different. Taking something out can add impetus to produce something interesting and better as a replacement, though it is sometimes worth putting it back in if your new approach turns out to be a “darling”. Hard to do though.
Some areas of gaming are more prone to this than others, though it is rife in the world at large. Films, songs and other creative mediums are replete with watered-down versions of successful efforts, riding along on their coat tails.
Of the things that I would change in KOW, this doesn’t come near the top of my list. Reading accounts of ancient warfare would suggest that clash, retire and reform, and then clash again is far more credible than units sticking to each other as soon as they contact. Even in later wars, such as the ACW, battle accounts talk of repeated charges, many of which may get close and then fall back before trying again. The idea that two units who contact must remain touching is one of Dogui’s elements that people do because it has always been thus (well, usually). The same argument holds true in individual combat.
My take on why it was in KOW is that it serves to clarify the break between one player’s turn and the next. Every turn begins with nothing in contact, and a clean slate from which to charge, etc. It’s very tidy, which seems to be what Alessio was aiming for. It’s not my personal favourite, but it works as an integral part of this style of approach, which is why I wouldn’t want to change it.
I have used a similar understanding of battle in my games, where units “stick” sometimes, but not usually. All of this does depend strongly on what bits of combat you are trying to model though, and how detailed you want things to be. Battles are way to complex to model every element in a game, and this is just one facet that has usually been done one way when in fact there are other, equally valid approaches.
Which part of this falling back/breaking off most offends you Sami?
“Reading accounts of ancient warfare would suggest that clash, retire and reform, and then clash again is far more credible than units sticking to each other as soon as they contact.”
I agree with that, but to have a game include such a system needs the system to be designed to emulate that – most systems seem to allow going forward fairly well but have limited opportunities to pull back and redeploy. The current version of KoW is clash, then clash again, but with odd results if you’re charged outside the front arc, and an unsatisfactory compulsion on non-combat characters, particularly spellcasters, to stay stuck in.
The solutions people are putting forward seem to incline towards free or semi-free movement (free as in “not impeded by the proximity of the enemy or that the unit just fought”) and preventing shooting, which raises further issues and personally I don’t like the “we’re in melee, but we’re not” aspect of that solution and how it effectively adds a secondary “you were in combat last turn” movement phase.
More on topic: I would be interested to see you do some sort of system vs system comparison of your battle system (when it’s released, or perhaps the one from your new Tribes set) and one or two others that you’re familiar with or were aware of when writing yours talking about why you chose particular mechanics.
“…most systems seem to allow going forward fairly well but have limited opportunities to pull back and redeploy.”
That’s true, as is your comment about the slightly odd compulsions. I’ve not read any “fixes” for KOW, as I don’t think that is a profitable way forward. Personally, I think that the rules for KOW are so interwoven that you’ll have to change almost everything once you start. However, that could well be because I have already written the fantasy game I wanted to play, so fixing KOW is not something I’d need to do 😉
Your idea of a comparison article is a good one on the surface, but I’m not sure it really works quite the way you think it would. I didn’t consciously think I’ll keep that bit and change that one in a detail sense of which rule was right or wrong for the project. I came to the whole thing with a much more conceptual approach, and fined it down from there. The fantasy game was, in many ways, based on a reading of historical ancient warfare rather than fantasy battles. I have another design theory post to finish about rules versus theme, and this is another example of me starting with theme.
After Tribes, you’ll find the games contain a lot of design notes and explanation in them as I always think it;’s better to explain the why as well as the what when you have the time and space. Letting the reader know where you’re coming from and explaining your ethos usually helps their understanding of the mechanical bits.
I’ll have a think about the comparison idea and see if I can think of an interesting way of presenting it. At the moment I think it would be concept driven.
What’s your thoughts on how DBx/HotT handle it, where a frequent combat result is Recoil?
I am a big fan of DBx, so it’s not surprising that I think it works well in those games. Because of the scale difference, the often formal battlelines, and (most importantly) the way PIPs work, the recoil results do all manner of things that aren’t just about movement. By breaking up the lines they erode the commander’s ability to react, and so show the increasing disorder as the army gets drawn into the battle and battered about. It is a very clever way to get maximum effect out of minimal rules. In the middle of a game it’s tempting to reform your lines, but this is very rarely a practical option and though a recoil result has no long term effect on a unit per se, it does help to beat the army.
Jake if your not doing anything Saturday or Sunday a bunch of us (http://www.ageofstrife.com) from around the country are gaming at Maelstrom. Saturday is a friendly 40k tournament and Sunday is random gaming, I think Sami above is taking Kings of War armies, Im gonna be taking some Malifaux (not that your interested in that) If you wanna come along and continue your conversation with Sami or do some gaming your quite welcome.
Andy
I’ve already managed to double book myself for sunday afternoon, but I might be able to make it up on saturday for a chat. It’s not very likely, but thanks for the heads up. I’ll see what I can do.
I think its a good idea to write the core rules to cover everything important, in the most efficient way possible .(Maximum game play , minimum rules.)
And then have additional rules-expansion to cover the ‘more fiddely bits’ some gamers might want .
(Blood Bowl is a good example of what I mean .)
I quite like using comparson of characteristic values , or simple modifiers.As these can be expanded upon easily.Using dice in a deterministic way can lock down options and prevent easy expansion of the core game.(EG.The game developer(s) have to resort to adding on extra game mechanics/resolution methods.
.
Any game that relies on additional rules to cover core gameplay is not very well designed-developed.
I belive there is an ‘optimum fit’ of game mechnics and resolution methods , for any game .
However , the realy hard part is defining what the game actualy is so you can get the optimum fit…
This is why designer notes are so very important.IMO.(As players can better judge if the game is the right fit for their expectations.)
Comparing sets of game mechanics out of context is pointless.
You have to compare the concept of the game, with the pracatical excecution of processes , (driven by the game mechanics).To see how fit for purpouse they are in each system.
I agree that whether a game succeeds or not depends on what it was setting out to do. To this end I’ll be adding some explanation to the pages on my games, as I find designer’s notes as useful as you do 🙂
Looking forward to that. 🙂
When I was looking at DKH for the first time I was not excited by the use of activation tokens because I had never played a game that used them. Now that I have used them I can see the value for adding color and balance.
Pingback: Tribes Of Legend – Update | quirkworthy
Pingback: Design Theory: Simplicity vs Dumbing Down |
Pingback: Game Design Theory – Busy Doing Nuthin’ |
Curious which system is ‘DBx’ ???
DBx is a collective term used to describe DBA, DBM, DBR… all of which are mechanically related. See: http://en.wikipedia.org/wiki/De_Bellis_Antiquitatis