So, I want to talk some about rules today. Not rules content – rules presentation. Let’s start with what is more-or-less my traditional presentation, derived-from but not identical-to the wargame rules of my youth, particularly those of SPI, which sort of imprinted on me what it meant to write rules for this sort of game.
Below are the first page of the rules for each game, side-by-side:
|Bonaparte at Marengo||Napoleon’s Triumph|
(Click on either page to open it in its own window.)
Now, the main thing I would call your attention to is how text-heavy they both are. The type is small and the line-spacing is tight. They also don’t really teach you very much. Mostly what you learn is the names of things: THIS is an “approach”, THAT is an “infantry unit”, THAT is a “locale capacity”, and so on. There is a little more taught than that: you learn, for example, how unit strength and losses work, and how to flip units between sides.
Now, let’s take a look at the rules to NT again, this time alongside the first page of the rules for Stavka:
|Napoleon’s Triumph||Stavka Latest Draft|
(Click on either page to open it in its own window.)
There are a lot of differences, but let’s start with just some data. The first page of NT has about 830 words. The first page of Stavka about 560. This is almost entirely due to the increase in type size. Stavka uses a larger type space and has more open spacing: fewer words per line and fewer words per line. But here is another data difference we can look at: how are column inches used in the two rules sets?
|NT Space Usage||Stavka Space Usage|
The space used for graphics in the two is actually pretty much identical. The biggest structural difference is that the first page of NT uses a significant amount of its space for tables, whereas the first page of Stavka has no tables. Tables in this page of NT are pretty much the result of its primary function: teaching the names of things. So, you have a lot of table rows where on the left side there is a thing, and on the right side is the name of the thing.
It isn’t that this page of Stavka doesn’t teach the names of things: it does. But it does it in a more compact way. Let’s look at how the two teach the names of some terrain features:
|NT Teaches Names||Stavka Teaches Names|
One reason that the Stavka approach couldn’t be used in NT is, ironically, NT was saving space by using a smaller type face. The lines were too short to easily accomodate inline graphics: hence, tables. In working on the rules for Stavka, providing space for inline graphics was the driving reason for making the lines taller.
The above example, though, suffices to show how to use inline graphics to make a more compact dictionary, but it doesn’t really properly exploit the potential of using inline graphics. For that, we need a different passage. Like this one:
In the above, what we’re seeing isn’t just a dictionary. It doesn’t just teach you the names of the different kinds of routes, it is teaching you what the functional differences are and how to count distances on the map. More is being taught in fewer words and in less space.
But more deeply than that, I’d like to avoid the split-presentation problem that dogged NT. In NT, commanders are intimately connected to corps, but although I introduce commanders in section 3, I don’t explain corps until section 8, and in one of my worst structural decisions, I also explained corps (partly) in the game set-up rules in section 6. Commanders and corps really needed to be introduced at the same time, and that time needed to come BEFORE I tried to explain set-up.
Let me give an example in Stavka of how I’m trying to do better. Stavka has front line pieces. These pieces are introduced at the same time as the front line rules, in section 4. There is no NT-style gap between the introduction of the pieces and the rules explaining their basic function in the game.
And the same structural approach applies to front-line dividers and breakthrough markers. The pieces are introduced and their game function explained together. This takes less space, fewer words, and produces less strain on the reader’s memory. By the time you’ve finished the first page of rules in Stavka, you’ve had to read a lot fewer words than NT and you’ve learned a lot more. None of this means that Stavka will therefore be a better game than NT, but I do hope it will be more approachable. That’s what I’m aiming for, anyway.
And with that, I think I will be closing up this entry. Until next time!
So, although I’ve been seriously banging away at the game for the last week and a half since the last update, I haven’t posted anything here. Most of that time has been spent working on the rulebook, and that just isn’t that exciting as far as this blog is concerned. But here, I have done some map work, so have a cookie and take a look:
|June 1 (old) Legend|
|June 19 (current) Legend|
So what’s new? Well, we can start with something that isn’t new: the elevation table (left edge). The map elevation layer was created programmatically. I found a set of digital elevation data for Europe, and then wrote a program to process it and output an image file. The image file was then processed to produce a vector art file, which was then massaged a little to make the current map. I don’t think it likely that it will ever change. It is (more) than good enough for game terms - far more, if we want to be serious about it, since the elevation image is largely eye-candy and doesn’t have any actual game function.
But if we move to the right, we can see the legend for the cities, and see that 10 different classes of cities have been slimmed down to 5. This was done as part of a simplification push. I had become concerned that I had over-designed the game in a lot of ways, and instead of adding more details I really needed to focus on essentials, and that meant taking a critical eye to any distinctions in the game that might be more fussy than substantial. And the number of city classes was pretty high on the list.
At the top, the largest cities are in the the class labeled Sehr Grosse Stadt (”Very Large City” in bad German translation), which came in 3 sub-types: non-production (Rome), single production (Leningrad) and double production (Moscow and Berlin). Well, Rome got dropped from the map: Italy was out of theater and in cleaning out “dead” areas on the map that were out-of-scope for the game, Rome got the axe. Leningrad got demoted to the next size down, where all the cities were single production cities, leaving just Moscow and Berlin, both double production and both capital cities, allowing the sub-types to be eliminated in favor of just the base type: Hauptstadt (German for Capital City)
One other detail about the Hauptstadt change you might notice is that the map symbols have been shifted. Hauptstadt is using the symbol that was associated with Grosse Stadt (more bad German), and GroßStadt (better German) is getting the symbol that was associated with Mittelgrosse Stadt (Good German? Bad? Not sure.)
And finally, what were the classes Mittelgrosse Stadt and Kleine Stadt have been collapsed together into one class: Stadt, given the symbol that was associated with Kleine Stadt
Still moving down, if you see the little square that was labelled Überschneidung, which was SUPPOSED to mean “intersection”, but which greatly puzzled a native German speaker as to what it could mean. (Never a good sign for a translation.) It is now Dorf, meaning “village”. This is actually a deeper change than it appears, because if you look at the row above the map scale you can see something called Routenpunkt supposedly meaning “Route Point”. Route points are gone: what were intersections and route pointes have been collapsed together into villages.
You might ask: “What the hell were route points, and why were they in the game to begin with?” Well, sometimes you reach a design by inches. In the first design from years ago, all the routes connecting the points in the network were the same length with the same movement cost. When I redesigned the route network I needed different length routes with different movement costs, so I used a design with alternating black and white segments where the number of segments was the movement cost for crossing the route. Then I got the idea of allowing the units to stop on the positions where the segments switched between white and black, and those were route points. Then it was suggested I needed a different design to make it more obvious that the routepoints were places where units could be, so I replaced the black and white band transitions with rectangles. And finally it was suggested that it didn’t really make any sense to have Überschneidung AND Routenpunkt and that I should combine them. And thus: here we are.
Now there is actually a lot more I could say: after all, I haven’t even been over half the Map Legend yet. But I am starting to think that for the sanity of all concerned that I should wrap it up. The fact is that the exciting life in game design is a lot of this stuff. Grinding away at details, over and over again, trying to make it a little better each time.
Hopefully, eventually, you end up with a game where everything fits together and everything makes sense as you come to understand it. God knows I don’t always get there but it is never because I didn’t try to do better. I try until I just can’t figure out how to do anything that doesn’t make the game worse. Then I stop. Every game represents a series of decisions, and eventually you reach the point where the game is as good as its oldest, deepest decisions allow it to be, where the only way to hope to make it better is to tear it all down and start again. Hopefully, by then, the game has gotten pretty good and it is something you think people will enjoy, but sadly there are never any guarantees that you will get there.
Herre’s crossing my fingers for Stavka.
So, the big news today is that the first prototype 3D printed pieces are here! Below is are a couple of sample front-line pieces in my daughter’s hand.
They’re pretty cute, I think. You can compare them to this rendering of the 3D model from which they were made:
The prototype surface is a little rough, which is pretty common with 3D printing, and I need to widen the holes in the 3D model because the fit is a little tight - with these you have to push the peg a little to get it to go into the hole, and I would rather that the peg just fall in. Still, it isn’t too bad, and once the peg is in the rotational motion is pleasantly smooth.
I also printed some prototype unit pieces, one German and one Soviet:
And again, for comparison, here are the 3D models from which the pieces were made:
As before, you can see the surface roughness introduced by the 3D printing process. You can also see a softening of the hard edges of the design, as we bump into the resolution limits of the production process. Color accuracy, by the way, isn’t something this process does. When I ordered the pieces I could specify “black”, “blue”, or “red”, but not what shade of each color. The actual production colors will be darker, and for the Germans basically a blue steel, which is pretty close to gray.
But I knew before I got these that the color was just going to be whatever it was. A larger issue is that the units were supposed to have slots in the back into which the tabs on the fronts could slide, but the slots didn’t really come out — they were present, but very shallow, so the basic idea of being able to snap pieces together front-to-back simply doesn’t work with these.
My plan is to revise the designs, and submit the revised designs, along with samples for two other types of pieces (penetration markers and front-line dividers) for prototyping as well.
While I was waiting for these, I’ve continued doing work on the rules. I’ve begun the process of converting from handwritten notes to typed, illustrated, and composed, and that’s coming along ok. A little less than halfway done with the first typewritten draft I think. In the process, I’ve also made some map revisions. But I think I will save the details of those for another day…
So, clearly we have another map update. (What can I say? The blog is about what I’m doing, and what I’ve been doing a lot of lately is map work.)
(Click on the image to open it in its own window.)
The most visible change since last time is pretty clearly the map legend. Now, this doesn’t actually mean the legend is done: all the text is machine translation from English, and no native speaker of either language has yet reviewed it, so the probability that it contains dubious-to-very-dubious labels is pretty nearly 100%.
That said, I’ll talk about it a little. The biggest (literally) thing about it is the giant Russian-German versions of "Stavka", the game’s title. Now, it very much was not my original intention to do this: I meant to put the game’s title untranslated there. I was tweaked by a person who will remain nameless about my inclusion of English on the game board, pointing out that consistency required German and Russian. I did it more or less as a joke, then wondered, “Should this be a joke? It is consistent.” And, to myself replied, “Are you serious? It looks stupid. What is wrong with you?” From there, my internal conversation got ugly, with abusive name-calling, ending with me refusing to speak to myself again until I apologized to myself and admitted I was wrong.
So, I never really enjoy work on legends. It consists largely of fussy alignment issues, along with trying to figure out someway to organize a bunch of items so their layout looks vaguely intentional. I have my doubts that the legend as-is really meets those basic goals of design and layout. But honestly, before you can do a revision, you have to have something to revise, and so, here we are.
Anyway, if we move on from the map legend and talk about the time track, we can see a vastly more successful layout. Since the last blog entry, the track has been enlarged somewhat so as to make it take up the entire east edge of the map. At the same time, making the individual cells larger meant that the amount of white space in a cell increased, making the cell design more open, which I think is a good thing.
If we move on to the map proper, the whole map is now shifted slightly to the west, such as some cities that were on the west edge are now off-map. None of the lost terrain will, I think ever be missed in play. The reason this was done was to provide space for the enlarged time track, and yet keep Baku (which could matter, in that it was a German war objective) comfortably on the map.
Next, and even though this is a small thing, I think it was pretty overdue: to bump up the size of the city names some for readability. I have long noted a tendancy that, when working on a computer where you can zoom in as much as you like, to tend to make things smaller than they should be. Constantly looking at things in 200%, 300%, 400%, etc. gives a very distorted perspective about how small a map element can be and still have it fulfill its purpose. And that was certainly true for the game map and the city size names.
Finally, I’ve mentioned in a previous post that the game’s “Card Economy” right was critical to the game functioning properly. As a result of quantitative spreadsheet modeling and the results of the last playtest, I became convinced that I had gotten too far away from the card economy concept: originally, I had the idea of production cities as being solely about determining the number of Rebuild Deck cards that could be drawn in a turn, but increasingly I had introduced other uses for production points directly: as a result, some things were paid for with production points and other things were paid for with cards, and there really wasn’t any logic as to which was which. Really, what I needed, I thought, was to return production as solely a means to buy cards, and that everything else would be bought with cards.
Another aspect of the clean-up and simplification of the production system was that there needed to be fewer production cities. Of coure, the entire distinction between production and non-production cities is a gross economic simplification to what was necessary to drive STAVKA as a game. And here is where I needed to focus: What was I trying to achieve in designating something as a “production city”? A very large part of that is that it drives game strategy, and since this is a game, that matters. With that in mind, I made the following cuts:
A final advantage to cutting production cities is that a larger number poses more of a countability problem than a smaller number, especially when counting widely scattered objects that aren’t ordered in a particular pattern. Even if players didn’t have to count them very often, a smaller number is inherently less challenging to deal with than a larger one. Six is an easier number to handle than ten, and nine is an easier number to handle than fourteen. It isn’t, of course, that players couldn’t deal with the larger numbers, it just that it is better for them not to have to. This is, after all, a game.
Anyway, that’s it for now.