Echelon Game Design: New Layout Strategy

Echelon Game Design LogoI’ve talked about my data workflows before, but now I’m going to mumble a bit about layout.

In my current workflow I break the game entities (feats, spells, etc.) out by type, then work with them. Each has different rules for rendering. I realized a while ago that from a data modeling perspective they’re actually a lot alike and devised a taxonomy to classify them (linked taxonomy is a starting point and not yet complete).

Last weekend I realized that the way I lay things out, there actually is a great deal of consistency. The multitude of rendering rules I’ve devised really break down to quite a small number of pieces.

  • Each entity has a heading of some sort. This heading might be a simple block (just the name) or include a statblock. There might also be level and ‘type’ (‘Ex’, ‘Sp’, and ‘Su’ are common for creature abilities, but feat types would also be marked here) markers.
  • Each entity will likely have text of some sort, the description of the entity.
  • An entity might have sections (classes and their class feature sections, domains and their domain power sections, and so on).
  • An entity might have subentities (classes and class features, domains and the domain powers, etc.)

All of this is pretty easy with the new workflow. The only thing missing is how to render them, and it turns out there are really only a couple things differentiating the various entity types.

Most obvious, the text style. The body text is consistent, table text is consistent, the only real difference lies in the colors (foreground and background) and font specification for the header. A feat name is presented in black text on a very pale background, a spell name is presented in white text on a very dark background. The spell will have a stat block, the feat might (if it has prerequisites) or might not (no prerequisites).

The second is not so obvious, but will be very powerful. A ‘breaking strategy’ that determines how the game entity is presented on the page… or more specifically, how it starts to be presented on the page.

  • In many cases, simple entities such as feats and rage powers should be presented such that their heading and at least one line of text are on the same page. I’m going to call this ‘needspace’ (because of the command used to make this happen). Spells also qualify here, and class features.
  • Larger entities such as domains, bloodlines, and orders each take up most of a page, the way I render them, so I put each on its own page. This would be a breaking strategy called ‘newpage’ (obviously). After that, though, they get rendered the same as any other entity: heading, descriptive text with subsections and subentities as needed (which follow their own rules).
  • Major entities such as classes, monsters, and so on not only start on a new page, their headers span the entire top of the page. I’ll call this ‘newpagespan’. Again, after that they’re actually rendered the same as anything else: description, sections, subentities, and so on. In the case of a class I might need to take steps to ensure the level table gets presented the way I want, but overall it’s all the same framework.
  • Spell lists have a special case. I have the spell list level label (“1st-Level Druid Spells”) appear as a normal heading with centered text (simple enough) but spanning the page. I’m going to call this a ‘needspacespan’: it works as the ‘needspace’ strategy, but needs to interrupt any ‘multi column’ arrangement I currently have.
  • I’ll also add one simply called ‘none’, which means to not cause a break of any kind, to simply flow the entity with its previous siblings. I’m finding cases where ‘needspace’ makes a wrong decision and forces a break where I don’t want one, so I’ll want to override the default.

There is one other small bit that’s almost a flag, column balancing. I use LaTeX to create PDFs. The native ‘twocolumn’ document mode and the ‘multicols’ environment both allow me to have two columns (or more in the case of ‘multicols’) but each has some different limitations. Multicols doesn’t allow column floats (“put this at the top of the next column and flow text around it”) but automatically balances columns when the environment ends. Twocolumn does not automatically balance the columns (but can be made to in some cases) but does allow column floats. There are other differences, but these are the two I’m interested in.

The newpage and newpagespan strategies should both have the option of balancing the previous multicolumn section or not (if possible; it would be ignored in ‘twocolumn’ mode). The needspace strategy doesn’t need it because if I’m intervening it’s to force a page break and I can thus use newspage+balance, and the none strategy doesn’t need it because it’s explicitly not breaking at all and thus not ending the section in a way that needs balancing. Needspacespan doesn’t need the option because if using multicols I must balance the columns or the span can’t be done at all, and if using twocolumn I must either start a new page in order to span (switch to newpagespan) or not span (use needspace, newpage, or none).

How does this relate to the taxonomy?

The formatting instructions — colors, fonts, and so on — can be stored in the taxonomy entries, along with the default breaking strategy, for each entity type. I can even have them ‘inheritable’: a class subfeature is an ability with the heading having white text on a medium background, and a needspace breaking strategy. A sorcerer bloodline is the same but uses a newpage (or newpage+balance) breaking strategy. Because I’m working with a taxonomy, I can simply inherit the layout parameters.

As a final step, when assembling and rendering the document itself I can override the default layout parameters. This would mostly be done to correct bad breaks, such as by forcing a feat to move to the next page or to override the needspace directive to pull the feat back from the page it got pushed to.

 

No related content found.

Leave a 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.

Back to Top