Sheet layout

Tabs, grid and the full widget catalog. How things reflow on mobile, conditional visibility, sub-tabs and per-class layouts.

Fields say what your character has. The design says how it looks: what appears, where and in what shape. It is edited in the Design tab.

A sheet is tabs, and each tab is a grid where you place widgets. A widget is a card: a big attribute, a health bar, a skill list, a table, a roll button…

The grid

• At the top you choose how many Columns the sheet has on desktop (2 to 6; 4 by default).
• Each widget takes a Width (columns) and a Height (rows), which you adjust when you open it (1 to 4 rows).

With that you can build anything from a single-column sheet to a dense six-column page.

Leaving gaps

By default widgets pack without spaces: each one goes wherever it fits. There are three ways to leave some room, all in the widget's settings (Placement section):

• Starts at column N: the widget starts there and leaves the previous columns of that row empty. Use it to center something or open a margin.
• Start on a new row: cuts the current row and moves down. Whatever was left of the previous row stays empty.
• The Gap / space widget: an invisible block that reserves the cells you give it. You drag and place it like any other, and it's the easiest option to see while designing.

If the widget doesn't fit from the column you choose, it is clipped to the edge instead of jumping rows, so the design never shifts by itself.

Sheet tabs

At the very top you manage the tabs:

• New sheet tab to add.
• Rename by double-clicking its name.
• Move left / right to order them.
• Delete tab.

A common setup is Main with what is always used, then Equipment, Spells, *History*… An empty tab warns with "No widgets in this tab.".

Adding and moving widgets

• The palette on the left groups widgets by category: press one and it enters the active tab.
• Drag to reorder.
• Duplicate widget to repeat one already configured.
• Press a widget to open its settings: size, which field it shows and its own options.

Most widgets hook to a field (you choose which in their settings). Some work without any field, because you define them right there:

• Counter without a field: you define minimum, maximum and initial; it saves by itself.
• Select without a field: you write the options yourself and it only saves the choice.
• Checklist: you define the boxes (empty if you want) and it counts x/total.
• Fixed text / Note: title and body written by you.

Widget catalog

Statistics

Tables and lists

The storage moves items, it does not copy them. If you take the last rifle, it is no longer on the ship. This is deliberate: if the stock never went down, sharing out gear would turn into a conversation ("did you take it?") instead of a fact. It is set up in two places with similar names, so they are easy to mix up: - On the party sheet, the Inventory widget. That is where the shared things are stored. - On the character sheet, the Party inventory widget. That is the one that shows the ship's hold and lets you take and return. Any member of the table can take items and return them.

Rolls

Advantage is not a modifier. It adds nothing to the total: it rolls more dice and discards some. A +2 raises the floor of the roll; advantage raises the average without touching the maximum. Mixing the two up is a very common mistake. If your game wants it that way, in Roll rules → How it applies choose Fixed modifier (+2 / −2 by default) instead of extra dice. In roll-under systems, tick "On advantage, keep the low die" so advantage keeps the good die (new systems already come that way). It stays off unless you turn it on, because in a pool system (World of Darkness) "advantage" means dice that add successes, not dice that compete. Turning it on there would take successes away from the player. The state is stored on the sheet as _ventaja (1, 0 or −1), so a formula can read it: IF(_ventaja > 0, 2, 0).

Cards

The Card hand uses the same deck the GM put in the Decks tab, not a copy, so whatever you draw here they see instantly. It has draw, reveal (the card stays in your hand and the whole table sees it; if there is an active combat it offers to send it to the Initiative order with its value), play to the table and burn. It sits on the sheet because in card games cards are spent while you roll, and switching tabs to discard breaks the flow.

Options: deck_key picks which deck (empty = the table's first one) and show_corruption shows the "take card" button of the games that use it. If the sheet is not in a campaign, the widget says so: decks go per table.

Cards can touch your fields. If a card carries effects (they are written in the builder's Decks tab, with the same format as perks), they apply while you have it: a Blessing of "+2 health" raises your health cap as soon as you draw it and lowers it as soon as you let it go. Depending on the card, it counts in hand or from the moment you play it to the table, and always on the sheet of whoever holds it (a card someone else plays does not change yours). It enters the same calculation as everything else, so derived values that depend on that field recalculate by themselves. The player does not need this widget for them to apply, but they do need it to see why their numbers changed.

Text and Notes

Fixed image and Portrait are different widgets, and mixing them up is the most common mistake. Portrait stores a piece of data of each sheet; if that sheet has no URL of its own, it falls back to the character's avatar. So for a handout that must look the same for everyone, Portrait will never work (not even pointed at a text field), because each player fills in the field and it starts empty. A cheat sheet is part of your system, not character data, so it goes in Fixed image, which stores the image in the widget itself.

In Fixed image you can choose how it fits. Whole (default) shows it complete even if there is room left over, which suits a table, where cropping would cut the rows at the edges. Fill the space crops what is left over, which suits a border or a background.

Structure

The shop: when there are many purchasable fields

A field with "Can be bought" shows its ▲ wherever you place it. That works for one or two fields. With thirty, you end up with five columns of permanent counters on the sheet for something done once at the end of the session, and the sheet starts to look like a form.

The Upgrade shop widget keeps all of that in one place you open when it's time to spend. You tell it which pool pays and it shows all the fields whose upgrade charges from there. It is closed by default, with the pool on the flap and how many things you can afford right now.

It is not painted if there is nothing to buy, not even the title.

Each row says from where to where you go, not just the price: "+1 for 18" tells you little, "Professional → Specialist · 30" tells you what you get. The names of each step are set by the system in upgrade.step_labels; without them the number is shown.

Purchase and charge go in a single save. With two writes, a failure in between would leave the step charged and not granted, and that cannot be fixed from the table.

Clocks: what lasts less than the game

Almost every system has things that expire: the defenses stacked up this round, a use per scene, a "once per session". None of that resets by itself, so it gets tracked by hand, which in practice means it gets forgotten. The number stays put and something later goes wrong without anyone connecting the two.

In Fields, each field can say "Goes back in place on" a scope. A perk with uses can say the same. Then you place the Clocks widget and one button per scope appears.

You invent the scopes: asalto, escena, sesion, descanso, luna… The engine does not know what they are or which goes inside which. That is deliberate, since any built-in hierarchy would break some system. It only groups and applies.

What "in place" means: a counter goes back to the value you tell it (or to its default value); a resource goes back full, because resting is not going down to zero; a perk's uses go back to the maximum.

The button turns off when there is nothing to reset, and when pressed it says what has changed, since a reset touches several things at once and some are not in view.

The grimoire: when casting is what gets pressed most

A spell is a perk with an action that rolls and charges a resource, not a separate entity. You could already build that, but the perks panel shows them as loose cards of the same size, with the cost in small print, mixed in with traits that are never cast.

The Grimoire widget shows those same perks the way a D&D sheet shows them:

• The pool at the top, in boxes. "3/5" does not tell you whether you have enough for the one you are about to cast; five boxes of which three remain does. It is spent and recovered by pressing them.
• Grouped by family, in the order you list the families, with the count next to it.
• Rows, not cards: name, what it does and the cast button on the same line.
• What you cannot afford shows dimmed, before pressing it.
• What is free (a passive with no cost) goes separately: it does not compete for the pool.

When placing it you choose the pool they spend (a Resource-type field), the field it is rolled against (shows as a button in the header) and the families it shows, matched by the start of the perk's category, so Conjuro picks up "Conjuro común", "Conjuro Menor"…

Daily preparation (optional)

If your system prepares spells every morning ("you prepare N and can cast only those today"), point the widget at a List-type field in Daily preparation. Each spell gains a checkmark: the ones you do not have checked show dimmed and with the reason. The header says how many you have out of how many fit (How many fit = any field with that number, usually a derived one).

They are saved by name, because it is the same List field as always and what is written there has to be readable by a person. The comparison ignores accents and case.

Also remove the loose List widget that pointed to that field. Two controls writing the same thing end up out of sync: you could note down by hand a spell you do not have, or cast one that was not in the list.

If your system has several traditions and only one prepares, put the condition in Only when… (hechiceria > 0). The rest do not see the checkmark anywhere.

The cost of each spell is not set in the widget: it is that of its action, in the Perks tab. There, next to the amount, you have "on failure": what it costs when the roll does not succeed ("failing spends 1 anyway"). The full cost is charged when casting and the difference is refunded when the die settles. A fumble never costs less, since it is the worst result. Its partner, crit_amount ("a critical spends nothing"), is currently written only when importing JSON. The price can also be a formula (amount_formula, for now only when importing JSON) when it depends on who casts and not on what is cast, such as "this tradition pays +1 over normal". A fixed number can't express that, because the same spell costs different amounts for two characters.

Roster and databases (the "Team / companions" widget)

The roster widget carries a list of card-sheets inside the sheet (pets, mechs, familiars, a squad, the trainer's Pokémon…). Each card has a name, portrait (URL), resource bar and the stats you define. When you press it in Design you have:

• Custom card: you choose which fields of your system appear on the card: the stats of the grid, the resource bar, the subtitle, the details of the dropdown, the roll die and whether there is a "send to combat" button. The card uses your fields, not fixed ones.
• Databases: a database is a dataset of your system (a list of entries with the values of your fields) that auto-fills the card. You manage them in the builder's "Databases" tab (or with the "Edit databases" button of the widget itself): you create databases, choose their columns (your fields), search entries, edit them by hand or import in bulk by pasting CSV or JSON (you map each column to a field). The entries table works like a spreadsheet: arrows and Enter to move, and a block copied from Excel or Sheets can be pasted into any cell (extra rows become new entries; with a filter on it only touches what's shown). Copy as table takes it back out. Importing also takes a file (CSV, Excel .xlsx with its sheet, JSON) or fetches from a link (Google Sheets, GitHub, a public CSV or JSON). With "Remember the link", the database keeps where it comes from and an Update button appears: it fetches it again and merges by name (existing entries keep their effects, new ones are added, nothing is deleted). What's fetched is stored in the system: the player's sheet never calls that link. If a site won't let other websites read the file, download it and upload it. With a database, "Add" opens a search that fills the card with the chosen entry; without a database, they are filled in by hand.

Databases live in the system (they travel when you export or share it) and work for any game: your companion bestiary, a database of ships, of summons…

Placement and appearance of each widget

When you press a widget, besides its size and its own options, you have:

Placement

Appearance

A widget you hide still appears in the editor, dimmed and with the eye crossed out, so you can show it again. On the player's sheet it does not appear.

Referencing a widget from your CSS

If you write custom CSS (Style tab), you do not have to guess what anything is called: each widget's settings include a Reference from CSS block with its selectors ready to copy (press one and it goes to the clipboard).

Each widget on the sheet comes with these hooks:

The Custom class is a free text field: write destacado and that widget will come out with sysc-destacado. You can put several separated by spaces and reuse them across several widgets to style them at once.

/* All stat blocks, with more air */
.sys-widget-stat_block { padding: 12px; }

/* Only the ones you marked as "destacado" */
.sysc-destacado { border-color: gold; box-shadow: 0 0 12px rgba(255,200,0,.25); }

/* The widget bound to the "vida" field */
[data-widget-field="vida"] { background: rgba(200,0,0,.08); }

The sysc- prefix is added automatically, so your class can never collide with the app's (writing hidden or flex as a custom class cannot break anything). All your CSS is also scoped to your sheet, so it cannot affect the rest of Roliando.

What CSS you can write

You get real CSS, with full selectors:

/* Every other row, half a tone darker: 30 skills in a row on the
   same background read terribly */
.sys-widget-skill_list button:nth-child(2n) { background: rgba(0,0,0,.22); }

/* The widget that CONTAINS a bar needs to breathe at the bottom */
.sys-widget:has(.stat-bar) { padding-bottom: 4px; }

/* Manuscript drop cap: the letter takes two lines and the paragraph adjusts by itself */
.sys-widget-custom_block p:first-of-type::first-letter { initial-letter: 2; color: #7a2410; }

/* Something that breathes. Very slowly: a fast pulse makes you dizzy after two minutes */
@keyframes brasa { 50% { box-shadow: inset 0 0 50px rgba(176,58,46,.28); } }
.sysc-tirada { animation: brasa 9s ease-in-out infinite; }
@media (prefers-reduced-motion: reduce) { .sysc-tirada { animation: none; } }

You have 60,000 characters, which is enough for a fully painted sheet.

What you cannot do, and why: nothing that runs code (expression(), javascript:), url() to an outside server (only data: or your images and fonts uploaded from the editor itself), and position: fixed (it is downgraded to absolute, so no system can cover the application). The editor reports anything it discards, with the reason.

Mobile

The sheet reorders itself on small screens, but you can take control:

• The Desktop design / Mobile design switch toggles between the two.
• On mobile you choose Mobile columns (1 to 3; 2 by default).
• If you do not define a mobile design of its own, the desktop one is reused with a proportional reflow: a widget that takes half the sheet on desktop takes half on mobile, and one that takes the full width keeps taking it.
• If a specific widget does not look right with the reflow, set a Width on mobile in its settings, or hide it on mobile if it is in the way there.

Check mobile: it is where most people play.

Resource bars: continuous or in blocks

A Resource bar can be drawn two ways:

• Continuous bar: the usual one.
• Blocks: one block per point, switching off as they are spent. With short resources (four luck points, six mana) it reads much better, since a bar at four points jumps in huge steps. Up to 40 points; above that it falls back to the bar, where no single block would be visible.

You also pick its thickness (thin, medium or thick).

The skin: a sheet that follows the theme

In Style → Skin you choose how the sheet is dressed without writing CSS:

• Theme: the sheet is the app. Background, text and accent are the viewer's own (light, dark, Escena, their accent colour). What belongs to your game is the texture, the shape of the boxes and the titles.
• Paper and Night: the sheet has its own tone (you pick the hue and how much colour the paper has) and reads the same with any theme. The player's accent is kept, but darkened (paper) or lightened (night) just enough to contrast.

On top of any of the three:

The individual colours further down (background, panels, text…) win over the skin: use them only to pin one.

In your CSS you can branch on the viewer's theme: html[data-app-claro] .my-box { … } applies only when the app is on a light theme.

Compendiums: big lists outside the system

A database travels inside the system, and with hundreds of entries it makes it heavy. For big lists (every item, the spells, a bestiary of a thousand creatures) there's Content → Compendiums: each entry is its own row, read in pages and with a search, and the system stays light. A compendium takes the columns of a database or has its own, and each entry can carry effects.

Fill it by hand (the table is edited in place and takes pasting from Excel or Sheets), importing a file or a link, or with Copy its database (the database doesn't change). Changes are saved at once, without pressing «Save».

On the sheet, the Compendium widget searches and adds entries with a click. The sheet keeps a copy with its reference: if the compendium changes or is deleted, the sheet stays the same, and Update brings the new version whenever you want. While an entry is on the sheet its effects apply (the bolt switches one off without removing it).

Taking a style to another system

Under the themes in Style there are three shortcuts:

• Copy the style of another of your systems: pick one and this sheet takes its colors, font, skin, CSS and roll template. Fields and layout aren't touched.
• Save to file: downloads the style as a .json to use in another system or give to someone; Open a style… applies it here.
• Undo: after a theme, a template, copying, opening or Reset, goes back to the style from just before.

Images you've uploaded to the system are kept when the style changes.

The sheet's type

Under Style you pick two faces, not one:

• Font: the body text (values, descriptions, tables).
• Heading font: labels and big numbers. This is what gives the sheet its character; without it, headings look like the app's in every system. It rules inside your sheet, and elsewhere each user's accessibility choice still wins.

Among the options there are two screen/label faces (Screen terminal and Condensed label) besides the usual ones.

Columns in the skill list

The Skill list can carry extra columns to the right of each row, like the paper sheet of many games:

• Checkbox (yes/no): the "class / specialised / tagged skill" mark. It comes from a boolean field whose name is built from the skill's key plus a prefix or a suffix (prefix tag_ over sigilo reads the field tag_sigilo), and it can be ticked from the sheet.
• Number from another field: the same, showing its number.
• Roll target: needs no field: it evaluates the skill's own roll formula, usually attribute + rank. That is the number you actually roll against.

Each column has its own label and width, and the builder warns you if the prefix matches no field in the system.

Show only if (conditional visibility)

In any widget's settings, at the bottom, you have Show only if (optional): a formula on the sheet's fields. If it is true, the widget is painted; if not, it disappears. Empty = always visible. It works the same on the character sheet, the creature sheet and the group sheets (a creature with tipo_criatura shows BODY/MIND and a character its SPECIAL: two blocks in the same design, each with its own condition).

nivel >= 3
vida <= 0
clase == 'mago'

Use it for sheets that grow with the character (the spells section appears when becoming a caster) or for warnings that only show when due.

Subtabs

The Subtabs widget puts tabs inside a tab, with their own widgets ("Actions", "Spells", "Traits"). They are managed with Add inner tab.

Use them when a tab accumulates too much, but do not overdo it: two levels of tabs already hide plenty.

Per-class designs

You can define a different design per class or archetype: the mage sees their spell table and the warrior their maneuvers, without anyone having half a sheet to spare. It requires a select field marked as class/archetype (see the Fields guide).

Tips

• What is used every turn, at the top and big. The background can live in another tab.
• Dividers to break things up. A couple of Divider / Title organize more than ten aligned cards.
• Gaps help with layout too. A Gap or a "starts at column 2" centers a block and adds room without touching CSS.
• Test in the Preview after each batch of changes, and check mobile as well.
• Do not repeat the same field in two widgets unless it makes sense: it gets confusing when editing.

Known limits

• A widget's height goes up to 4 rows (the minimum height in px lets you fine-tune within).
• Starts at column and Start on a new row only apply on desktop: on mobile, with 1-3 columns, they would leave the sheet half empty. For mobile use Width on mobile, the mobile design of its own, or the Gap widget.
• The design is saved per tab: there are no design "templates" reusable across systems (for that, export the system and import it).

Next step

With the sheet built, define how it rolls and how it hits: the Rolls and Combat guides.

All Roliando guides