Diary: Scenario Guide – Update 2

It’s been quite a bit of work on the Scenario Guide.  Most of the text in the core scenarios (basically, everything that isn’t the bonus section) is outlined, but none of the setup diagrams are at this point.  Even then, it’s just over 200 pages in length, so I would imagine that the completed Guide should clock in at 300-350 pages.  (I blame one of the new scenarios in the Guide – you know, that new one with 37 diagrams – for making me do more and more diagrams.)

So here’s an update on what we have going on in the 2017-1 version of the Guide:

• The section on “The First Island” is completely rewritten, with a whole new section on the game frame, and a write-up on certain key aspects of the base game rules.  This is actually quite a bit of work, going by how many pages of scratch paper I’ve used to do some trig calculations.  There are some portions that I have not yet rewritten from r13 (or my draft r14), such as the “fixed hexes” and such, but that’s relatively low on my priority list.
• The section of the Guide on “First Islands of A Different Kind” is something I’m considering dropping, since it’s more of a spinoff showcase rather than something you can play with the core game components.  If anyone wants me to keep it, then I might consider re-adding it down the road.
• Most sections of the Guide now have a sizeable writeup on the new equipment introduced in the specific scenario.  For example, the section on “Cloth for Catan” has a section on the original special hexes that were part of its original presentation, but was dropped when it was adapted for Seafarers.  Other things include a short section on the trade hexes in “Traders & Barbarians”, and so on.
• Each section has a larger “section overview” which details equipment that is common to multiple scenarios.  For example, the Traders & Barbarians section overview contains the general rules for gold pieces.  In general, you’ll see a lot more cross-referencing in the new edition, which is a distinct change from r13 (where the rules were written so as to have individual scenarios be entirely self-contained).  The reason for this is the fact that scenario combinations were, for me, incredibly difficult for me to write up, and the fact that Explorers & Pirates is presented in a way that makes copying and pasting things not worth it.  (Right now, the longest writeup is for “Barbarian Attack”.  “Traders & Barbarians” had that title, but that was before I ultimately decided to separate out the base scenario from XL and Ultimate, since Ultimate plays nothing like the base “Traders & Barbarians” or even BA+TB.)
• As a result, a lot of the “rules proper” sections are reduced by a great deal, and in most cases I can’t justify splitting the setup notes from the rules proper anymore…
• Oh yeah, there are a lot of corrections to some of the sections in the Guide.  I don’t have an exact changelog, but one of the most egregious is “Transport Settlers”, in which the rules wouldn’t make any sense if you also considered the entries on it in the official FAQ.
• I’ve also consolidated a few things – for example, “Atlantis” is presented in only one place in the Guide now.  I’ve also moved a few of the early “pre-Seafarers” stuff (“Seas for the Poor”, “Catan-Plus”) to the section on “The Second Islands” for a bit of a better flow.
• More diagrams!  There are a few places in r13 where the wording wasn’t so hot, so a few rules diagrams would help.
• I’ve decided to drop some of the inline images that I’ve used for resource costs and number tokens.  It’s not that I don’t like them, but it’s because my computer’s starting to strain from adding so much inline graphics.  (There is a reason r9 was split across multiple documents…)  If I ever revisit the live version, I’d definitely be using inline graphics for that.

There are a couple of things that I haven’t fully decided on in the Guide just yet:

• Whether I should have actual photos of game components (for example, a comparison between traditional and Viking wood pieces), or other graphics that I did not come up with originally (for example, cropped images from Catan-News)
• Whether I should have setup diagrams in the “correct” orientation (the Guide has long presented most setups on its side, so that the two-column setup layout would work without shrinking down the longest setup diagrams)
• Whether the Bonus Section will return or not.  I have to double check if there will be new additions to the Bonus Section, or if I have to refine the criteria for inclusion of the Bonus Section at the moment.

Any input on some of the changes is definitely appreciated.  The 2017-1 version of the Guide is, so far, I’d say about 30% complete (the graphics take some time).  Again, I don’t expect that the final version of 2017-1 will be done before the release of Legend of the Sea Robber or the 2017 promotional scenarios.  There are still a number of places where my personal Catan collection has noticeable gaps, where I have to rely on second-hand sources for the information needed in the Guide.

While I am at it, I do have some special requests for the Guide.  Here are the Guide’s most requested things at this point:

• Copy-editors.  I’m the first to admit that I don’t have consistent language in the write-ups, and a second set of eyes would be able to see things that can possibly be refactored.
• A good templating engine.  This is more for the live version than anything, but may be useful down the road.  It is becoming more of an effort to compose the Guide, and I have been mulling over the live version’s backend more than anything.  Right now, most of the writing is there so that I can reuse most of what I write in the live version, where the benefit of things like hyperlinks can be useful.
• In terms of me completing my collection: rare English versions of the German promotional maps, stuff that used to be on sale at the English Catan shop but not anymore, and a few other things.  (For one, I still don’t have a 4th or 5th edition Seafarers, as my Catan collection is 3rd edition vintage.  I do have a few German things, like frame piece extensions, but lack an actual German frame.)

Diary: An Update on the Scenario Guide

I’ve started on rebuilding a new version of the Catan Scenario Guide, once again.  I’d like to say “for real this time”, but this new version of the Scenario Guide is taking its time, partly because it will be completely rewritten from scratch.

Part of this is entirely practical: it has been years, and the last public version (Revision 13) was before Explorers & Pirates was released, and the last private version was before the current 5th edition was released, so there’s a lot of stuff that is going to be rewritten and reorganized either way.  There is also the rebranding and adding the chapter introductions that need to be done, but some of the most important changes are in fact to complete some of the things I had been working on for Revision 14.  (Yes, I had a partial changelog.)

Revision 14 would have been a considerable graphical overhaul of the Guide, to be introduced over time.  This was necessary for the following reasons:

• It was hard to label edges, especially in the promotional scenarios where I had to determine hex by hex which edges were part of the board and which were not.
• I had, up until that point, wanted to expand the first few chapters to include information on how the board game frame changed over time.  The hexes that you find in the finished Guide is the actual size that I was working with in my line drawing program, which made drawing frame pieces incredibly difficult.  In the upcoming version, I’ve actually created all of the graphics in a new, larger size, and shrunk them down to fit the printed page.
• I wanted to redo the harbor graphics so that they matched the Seafarers “harbor keys” from the 3rd edition, rather than the “geometry block” motif that was taken from a fan’s homemade set posted on BoardGameGeek.

Unfortunately, because I made the decision to completely rewrite the Guide from scratch, it will be a while before it’s ready for release.  (I’m not intentionally delaying the Guide so that it will be released after the Seafarers 20th anniversary scenario, honest!)  This is compounded by the fact that my word processor died without a backup, meaning that I had to rewrite the entire Guide from scratch several times already.

But here is what I can tell you about the new version of the Guide, as I am outlining this:

• Of course, I’ll try to keep up to date with everything officially released, but that’s a very hard ask since I’ll have to acquire some of the materials personally.  Some are easy to do that since you can buy them on Catan Shop, others not so much.
• There will be a new section dedicated to Cities & Knights.
• I’ve spun off the Catan Geographies promotional scenarios and the Catan Scenarios line to their own sections.
• I’ve reorganized some scenarios that were particularly hard to categorize.  For example, “Greater Catan” was originally in the Seafarers section, then moved to SD&E, and now, I’m moving it back to Seafarers.  (If SD&E gets an English release, I’ll move it back, of course…)
• For the most part, the scenario rewrites are primarily so that equipment dedicated to a particular scenario will be introduced in its own section in the Guide, as opposed to all at once near the beginning.  For example, the Council of Catan hex will only be introduced in the Explorers & Pirates section.  Some things will still need to be introduced more broadly to avoid repetition – for example, crews will be part of the Explorers & Pirates preamble since multiple scenarios make use of them.
• All of the graphics will be redrawn.  The same colors will be reused for the most part, but there will be plenty of changes.  For example, number tokens will reflect the English language version of using a single consistent size of numbers with dots below them.  Land hexes will have a yellow border to differentiate them from edges where no roads can be built (for example, the mouth of the river pieces in “The Rivers”).

It is my hope that the rules are a bit more clear with less use of inline graphics, which hopefully gets us a Guide that is not significantly longer than Revision 13.  At this time, I’m still thinking of what to do for a Live version at the moment; for now, the Live version project will be on hold in order to try and finish the PDF version in a timely manner.

Diary: Kelvin’s Third-Party Add-Ons

It’s been a year or so since I’ve last made a blog post here, and, spurred on by the fact that people have been wanting another public release of the Catan Scenario and Variant Guide (no, I have not done any new releases since R13 – for the last few years, I’ve either been half-heartedly rewriting it, or haven’t been involved in the community at all).  I’m actually going to start reworking all of the graphics in the guide, and likely going to finally figure out how to incrementally post updates to the guide as it happens, as I lack the will to release entire volumes all at once (and I’ve been out of the community for so long that there are going to be many gaps in the guide anyways).

But enough about the Guide and my other projects.  This post is going to be about augmenting the games that I have in my collection.  I’ve moved around a lot, and in the few years that I’ve been neglecting this blog, I’ve moved twice, and my board game collection still fills up my spare bedroom.  Worse of all is that a good chunk of the game boxes I have has been damaged from storage or wear (some are moulded over), so I’ve been getting replacement containers for them.  (Thankfully, game components are largely intact.)  And generally, when I have to do that, I tend to take them out for a spin and get familiar with them.  (I still have the ultimate crime of not being able to play with a steady audience, though, so a lot of it is mock games and maybe some hobby programming.)

Now, most games, you can’t complain about the components a whole lot.  Having said that, I’ve had to augment some of my games with a bunch of parts that are either homemade or otherwise not included with the game.  For example, my Catan set uses the Viking pieces, and because Das Buch sum Spielen doesn’t come with equal parts for all players, I’ve had to augment some components with either cardboard or acrylic pieces so that all six player colours have roughly the same pieces.

Many of you fellow board gamers will have similar stories.  For example, I have friends who are hardcore Scrabble players who will use ProTiles (http://www.protiles.net) instead of the tiles that come with the game simply because the tiles that come with the game have the letters etched into the tile, allowing you to feel out what letter a tile could be when you draw them.  Others may replace packs of paper money with a poker chip set (customized poker chips, no less) so that they get a more tactile feel of the currency that they are manipulating.

For me, the games that I’d most likely to be augmenting (outside from print-and-play games, as I’ve burned through 10 printer cartridges printing out fan-made Dominion expansions) is the collection of Axis & Allies clones in my collection – but most specifically the two games from Guild of Blades Publishing Group that I have in my collection (1483 series and The War to End All Wars).  The problem with that is that they are horrible games both in terms of the quality of the gameplay (seriously, it’s not a good idea to have a massively multiplayer board game with a board that’s measured in feet, especially if the action is fairly localized) as well as the quality of its components (30 pieces of red construction paper, taped together, to form the board, which is not in color, and takes up four poster rolls – not to mention that all of its pieces are in thousands of pieces of labelled tiddlywinks, for which the labels are off-center and the graphics come straight out of the 1980s despite the game being released in the early 2000s), and they’re largely a huge money pit since it turns out that you don’t actually have enough pieces to play the game if you get it, and have to spring for the “additional army packs”, making those games even more overpriced than they are already.  (Seriously, I’ve been inclined to throw out the game and cut my losses.)

Now, I’m probably going to be posting more on this in the coming months (hopefully).  Everything from how I augment my Catan experience to the Swiss cheese that is anything Guild of Blades.  Let’s hope I can commit to updating this a bit more often…

Kelvin’s Mega Civilization Tool

Wow, it’s been two years since I’ve made any post here, and almost three since I’ve made anything related to games.  Well, the wait is over… sort of.  If you’re looking for a new version of the Catan Scenario and Variant Guide – nope.  That’s still a while off (for reasons I will get into later).

Today, I’m going to introduce a quick and dirty tool for Mega Civilization.  This tool merely keeps track of the Civilization Advances you have researched in the game, as well as the costs of purchasing any advances that you have not yet researched.  It also keeps a victory point count of all of your researched advances.

Note: costs do not reflect additional credits that are granted by Monument or Written Record, if researched.

This tool is provided as-is, and isn’t really licensed: it’s really too trivial of a coding project to do that.  Feel free to fork and improve the code as you wish.

The code is available at https://github.com/kelvSYC/mega-civilization-tool.  This is an SBT project, but SBT is really only needed to compile; “sbt assemble” will produce an executable jar that you can use.

(This code is basically there for me to get familiar with Scala and SBT – if you are a BGG user, you might want to go with Laz’s Mega Civilization Advances-Credits Active Game Aid and Score Sheet, which is more comprehensive and useful in gameplay.  That Excel workbook will properly consider your cards in hand and makes for a better aid in your purchasing decisions.)

IFF Grammar

Hot on the heels of the SimCity 2000 grammar, here’s a quick Generic IFF grammar.  This grammar is made so that anyone can extend it to create their own grammar for file formats based on IFF.  (It is possible to use it on RIFF and AIFF-based grammars as well, but I plan on having more specialized grammars for those.)

The IFF grammar defines a few simple data structures.

• The Base IFF Chunk is the abstract base structure for all chunks, including builtin chunk types FORM, LIST, PROP, and CAT.  To create your own, simply subclass this one, override the “Type ID” by inserting a fixed value, and fill in the contents of the internal Chunk Data structure.
• The FORM Chunk, CAT Chunk, LIST Chunk, and PROP Chunk are all abstract base structures for their specific builtin chunk types.  Subclass them and modify their chunk data where necessary.  However, do not delete the Form Type or Contents Type fields in the Chunk Data, as these are part of the standard.
• The FORM/LIST/CAT structure matches only FORM, LIST, and CAT Chunks.  You may replace them if necessary with something more specific.
• Since FORM Chunk contents may be any user defined chunk type or FORM/LIST/CAT, consider subclassing FORM Chunk Contents for your needs.
• The Properties substructure of the PROP Chunk Data is meant to hold all and only user-defined chunks.

The intent of the generic IFF Grammar is that it should be able to parse in its entirety any generic IFF documents, with a specific focus on FORM, CAT, LIST, and PROP Chunks (all four of which are reserved).  It does not cover the reserved FOR1-FOR9, LIS1-LIS9, and CAT1-CAT9 chunks, nor any commonly found chunk data types.

Limitations:

• This grammar does not check that FORM type IDs are not all lowercase letters and is not punctuation-free.
• The structure references are better represented as a script so as to better do parsing for embedded structures and the like, but script support is still a bit iffy at the present type.
• Be aware that some past versions do not handle structure inheritance properly, and may not respect overrides on fixed values or the deletion of members in a subclass.  If this is an issue, feel free to extend the Base IFF Chunk instead.
• There is no support for the “four spaces” chunk type.

Changelist after the break.

Download the IFF Grammar here!

SimCity 2000 Saved Cities

Here’s a break from the constant madness that is ROM hacking: the SimCity 2000 Saved Game file format.

SimCity 2000 largely follows the Interchange File Format standard, with the notable exception of the requirement that chunks be aligned on two-byte boundaries.  Other notes:

• Most of the data within the SimCity 2000 save file is compressed using a form of run-length encoding.  The RLE structures are mapped out, but I’ve not really implemented the script elements that will map them.  This is because scripting is buggy and is a huge performance hit on the build (it’s a prerelease build that fixes a few bugs from the last official build, as explained in an earlier post).  I’ve been told that the next release will fix this issue, but I don’t have even that build yet.
• Synalyze It! can’t really parse decompressed data while the data is compressed.  The true meat-and-potatoes of the SimCity 2000 data is in fact compressed.
• CNAM chunks may occur at the end of a file, but I have not seen any save that has that.
• The string in the CNAM chunk appears to be “dirty Pascal string”.  Perhaps putting it as a C-string starting at the second byte might be better.

Hopefully I can get a generic IFF grammar going, as well as its cousin the RIFF, based on this.

Changelists after the break.

Download the SimCity 2000 Saved City Grammar here!

The Pokémon ROM

Those of you who do know of Synalyze It! also know that you can download existing fully published grammars.  Through the painstaking process of reverse engineering, I’ve been using it to compile a grammar for the Pokémon Generation III games for the Game Boy Advance.

This grammar ONLY works with the US release ROMs, but they do work on all five games (Ruby, Sapphire, FireRed, LeafGreen, and Emerald).  The development of this grammar in particular has been extremely influential in the development of Synalyze It! as well; a number of things in this grammar were simply not possible in earlier versions of the program.  (I’ve had Synalyze It! since version 1.0.3, and things have changed a lot since then.)

This Pokémon ROM grammar has probably led to some help in exposing bugs and the development or better understanding of certain features:

• Modelling discriminated unions
• Offset to array scripts
• Null-terminated array scripts
• Scripting element scoping (after there was a bug found in the above script)
• Zero-length scripting elements (though it doesn’t appear in this version of the grammar)
• A crapton of bugs relating to structure inheritance (often times, the RS, FRLG, and Emerald versions of the data structure have subtle differences, and sometimes the inheritance from a common structure doesn’t work as expected…)
• A crapton of bugs relating to structure alignment

And that’s only from the emails that I’ve been able to dig up.

In any event, this is the latest version of the file.  Changelists after the break.

Download the Pokémon ROM Grammar here!

The Problem With Offset Arrays

The offset primitive type in Synalyze It! is meant to be a pointer.  An offset field is basically an enhanced integer field, where the parsed integer, along with some context info (“Relative To”, “Additional”, and, of course, the referenced structure type), additionally renders a structure where the parsed integer refers to.  This is fine and all, but the offset model breaks down in many ways, of which I will talk about one here.

Just like any other data type, you can assign a repeat count to an offset to create a fixed-size array.  The problem is that the results tree simply doesn’t look right.  There are two things at play:

• The referenced structures are inserted into the results tree after the rest of the structure is parsed.  This is extremely inconvenient, as one would expect that the structure would be right next to where the integer wold lie.
• The referenced structure does not carry the array index of the offset array.  This means that in an array of offsets, all of the structures would appear to have an array index of 0.  Needless to say, finding the structure for a corresponding offset in your array is painful if the array is large.

Of course, a single script element can be used to actually solve both issues, and has the additional benefit of being able to compute the actual location with greater granularity than what the “Additional” field can provide (the tradeoff is that duplicating the “Relative to” field functionality by traversing the results tree is that much more difficult).  The overall idea in your script element, which will render the entire array, is to, on each iteration, parse the integer (via StructureMapper::getCurrentByteView()) and add it to your results tree (StructureMapper::getCurrentResults()), and then subsequently map the structure based on the value of the integer (StructureMapper::mapStructureAtPosition()).  Both Results::addElement() and StructureMapper::mapStructureAtPosition() take in the “iteration number”, which acts as the array index.  There are a couple of downsides to this, however:

• It presumes that the structure is of fixed size.  Unfortunately, mapStructureAtPosition() takes in a “maximum size”, which is equivalent to giving a structure a fixed size and assuming that any data that’s left after rendering the structure is padding.
• This is not reusable.  You will have to duplicate this code (and make subtle tweaks for array size, offset location, etc.) every time you need it.

All in all, quite a bit of effort to attempt to re-render a tree just because you don’t like where the referenced structures are located in the results tree.  More trouble than it’s worth, but it just seems like the way it is currently is a bug.

Little Endian Bitfields

In Synalyze It!, you can create integer fields of various sizes.  With whole numbers of bytes, you can make this into little-endian or big-endian structures.  This is all fine and good, but because of the fact that Synalyze It! has to process structure members in the order that they are declared, and a structures can have the property that the size of the structures is entirely determined by the contents therein, it means that true bitfields (where multiple integers are being crammed into a whole number of bytes) can only be rendered with Synalyze It! primitives if the bitfield is encoded as a big-endian integer.

This presents a problem: a lot of platforms are little-endian or mixed-endian, for one.  You could somehow get away with it if your fields somehow align neatly with byte boundaries, but this doesn’t always happen.

To get a better idea of what I am speaking of, consider a 16-bit integer acting as a bitfield.  This 16-bit integer consists of a 7-bit integer and a 9-bit integer.  If you try to model it using Synalyze It! primitives, the bitfield will always render it as follows:

xxxxxxx- -------- 7-bit integer
-------x xxxxxxxx 9-bit integer

This is regardless of the endianness of the integer that these two fields have been packed into.  Why is this, given that all structures have an endianness property?  That’s true, but that just refers to the endianness of each individual field, and not an instruction to render the structure with the bytes in reverse order.  (Again, Synalyze It! generally does not know the size of a structure before rendering it, and even if you had a fixed-size structure, Synalyze It! will not reverse the bytes contained within before rendering.)  Thus, bit field parsing only works if the 16-bit integer was big-endian.  If this was a little-endian integer that these two fields are packed into, then we have this in actuality:

-------- xxxxxxx- 7-bit integer
xxxxxxxx -------x 9-bit integer

In other words, the 9-bit integer is now in two pieces, and cannot be modelled by a single field.

Now, there are several ways you can work around this:

• Coding the bitfield as an integer, and extracting the two fields using scripts.  The pro is that you can do this even without the Pro version: bitmasking will, to some extent, allow you to extract individual fields.  This is generally good enough if every field was one byte, but it also makes it impossible to fix some fields while leaving others unfixed, as, after all, Synalyze It! still considers your bitfield as a whole and never each field individually.
• Model any field that spans multiple bytes as separate integers, and extracting the true value using scripts.  In order to create a script element that extracts the value, you would need to traverse the results tree.  This is generally feasible via Results::getResultsByName().  Then you can extract the values, and manipulate them via Lua or Python’s regular integer tools, and then insert a value into the results tree to represent the actual value.  The downside to this idea is that you still either have to deal with cutting the results tree to remove the original values (which also removes the ability to alter a value in the results tree and have the changes propagate to the actual file), or have to live with extraneous data polluting your results tree.
• A custom element.  Custom elements provides the maximum flexibility, in that you have greater freedom to insert exactly what you want in the results tree.  There are two things of note: you are inserting a structure into a tree rather than a single value, and your inserted structure is now read-only: you don’t really have a “structure value” type, so implementing the fillByteRange() function is impossible.

The latter two approaches also means that you would have to custom-make this for every little-endian bitfield you encounter, and their implementations require the use of two techniques that I have found to be useful: zero-length script elements in the second approach, and “manual mapping via prototype” in the third approach.

Zero length script elements are fairly straightforward to implement:

currentElement = currentMapper.getCurrentElement()
currentMapper.addElement(currentElement, 0, 0, value)
return 0

The custom element approach is something entirely different.  First, you must create a top-level structure that will act as your prototype.  This structure won’t actually appear anywhere else in your grammar, but you can set up field sizes, element names, and such.  After creating this prototype structure, then, within parseByteRange(), you can then refer to your prototype structure via

currentGrammar = element.getEnclosingStructure().getGrammar()
prototype = currentGrammar.getStructureByName("Prototype")

From there, you can then use the given ByteView (byteView) to extract the necessary data, prototype.getElementByName() to retrieve the Elements corresponding to your fields, and simply add to the results tree: results.addStructureStart() takes in your prototype structure and results.addElementBits() takes your field Elements and Values.

That’s still quite a lot to do in order to properly render a structure that’s packed into a little-endian integer.  What’s still worse is that the custom element approach will still have a tendency to misrepresent your fields’ actual location in the hex field (the 7-bit integer, despite being solely taken from the second byte, will appear to be coming from the first byte).

In short, none of the solutions will give you the ability to render all and only the fields that you want without sacrificing generalizability, mutability, improper representation of rendering in the hex view, or script-free-ness.  See which approach works for you.

Diary: Kelvin’s Piecepack Pyramid Dimensions

Almost as soon as I finished writing that last diary post, I really looked into the dimensions of my prospective piecepack pyramids, and whether I can get them 3D-printed.  First, I want to investigate the dimensions.

The reference document dictates that the side of a piecepack pyramid form an isosceles triangle with a 36-degree angle at the tip of the pyramid for all sizes.  As stated, the base of the pyramid range from 1/2″ (A) to 27/32″ (F), in roughly 1/16″ increments.  (Pyramid F is slightly larger).  My highly imprecise measurement method also reveals that the distance from the tip of the pyramid to a corner range from 13/16″ (A) to 1 3/8″ (F), in increments of roughly 0.3cm.  Doing some math, the heights of these pyramids would be 0.73 inches (A) to 1.24 inches (F), with Pyramid E (at 1.13 inches) being “pawn-height” (a pawn is 1 1/8″ in height).

With a pyramid base increasing by 1/16″ from one size to the next, it would leave me with a thickness of 1/32″ for the pyramids (and allow the other 1/32″ for some “play”, similar to Looney Pyramids specs).  The problem here is that 1/32″ is a tad too thin for most 3D printers that deal with plastic (a quick look at materials used in 3D printing reveals that most plastics require a thickness of 1mm; 1/32″ is roughly three quarters of that).  If you are willing to print using metal and drive up your materials cost, it’s worth a shot though. But it’s likely to be cheaper to just cut sheet metal to make pyramids if you’re going that route…  So, for the budget conscious (for the definition of “budget-conscious” that goes out of their way to make pyramids out of plastic, that is), it looks like 1/16″ is the smallest thickness that I can realistically use.

A 1/16″ thick pyramid would need 3/32″ difference between pyramid sizes if we were to go by the above.  If we were to keep pyramid F at 27/32″, then pyramid A would have 3/8″ base.  In other words, something slightly larger than a zero-pip Looney Pyramid (a Looney pawn is known as a “one-pip” pyramid, drone “two pips”, and queen “three pips”, their bases and heights form a natural arithmetic progression, so a “zero-pip pyramid”, created in practice by hacking off the tips of other pyramids, is a natural progression in reverse).  If that’s too small and you would like to keep pyramid A at the half-inch square base, then pyramid F would be 31/32″ square – still permissible within the constraint that the base of pyramid F must be no larger than a quarter of a piecepack tile (ie. one inch square), and slightly smaller than a Looney queen.

Can I possibly make things even thicker for good measure? Possibly.  If we had 3/32″ thick pyramids (ie. 1/8″ difference in base sizes), then pyramid A can have a 3/8″ square base and pyramid F can have a 1″ square base.  All fairly good base sizes, and as 3/32″ is roughly 2.4mm, you could work with a wider choice of materials, I suppose.  But 1/8″ thick bases is definitely out.  I would imagine that a pyramid with a 1/8″ base (the base of A if E was 3/4″, like it is with the reference document) would be very difficult to handle.

So, now for the heights of said pyramids.  The problem is that, the thicker we make our pyramids, the less likely that they will, in fact, stack neatly (that is, pyramid A should be completely obscured by pyramid B if you were to place it on top of pyramid A).  While I haven’t tried out maintaining the specified heights and seeing if this occurs, I had been considering adopting the Looney Pyramid model of having a fixed height to base ratio.  Specifically, Looney Pyramids maintains a 7:4 height-to-base ratio (up to 1/32″ of an inch), and if I were to take pyramid E to be “pawn height”, then a base of 7/8″ (used in the 3/32″ model and the 1/16″ model with the larger pyramids) would give these pyramids a height-to-base ratio of 9:7.  Now a 9:7 ratio, rounded to the nearest 1/32 of an inch, almost exactly gives a height difference of 1/8″ between pyramid sizes. (Pyramid A, at 9/14″, would actually be closer to 21/32″ than 5/8″, but the heights for B, C, and D would fall between a nice eighth-inch multiple and the next 1/64″ larger, and for F the 1/64″ smaller)  That seems a bit convenient, let’s see if this actually stacks…