rpg-cards: a static card generator you deploy as plain files

Mostly static files, with one build step

The first thing the project notes tell you is that this project consists almost exclusively of static HTML, CSS and JavaScript files, but that it needs to be built at least one time to work. That single sentence describes the whole architecture. There is no backend, no database and no account system, and the entry point in the package manifest is generator/generate.html, a page rather than a module.

What the build does is fill the generator and icons folder with assets. The content comes from three places: the game-icons project, the gameicons-font project, and any .png or .svg files you have added to the resources and custom-icons folder yourself. That last one is the extension point, and the documentation is precise about the sequence: you must build the project and refresh the page in the browser in order to use your own icons.

The deployment story follows from the same design. To publish the generator you deploy the content of the generator folder to your server, for example with an FTP client, and there is a hosted instance linked from the project notes along with a documentation page and a discussions board for project updates.

The build scripts and the tools behind them

The build is two Node scripts run in sequence, and the manifest shows them plainly:

  "scripts": {
    "start": "npx http-server ./generator",
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "node resources/tools/update-icons.js && node resources/tools/update-fonts.js"
  },

One script updates the icons and the other updates the fonts, and they are separate because the two upstream projects deliver in different formats, one a set of vector images and the other a font.

The development dependencies explain the mechanics of fetching and unpacking them. An archive library is used to read the downloaded zips, a directory walker finds the files inside, a request library and its promise wrapper do the downloads, a promise based stream helper moves them, and a file system helper with move support puts them in place. The only runtime dependency is a cross-platform remove tool, which is there so the update scripts can clear the old icon folder on a machine where the folder layout differs.

There is also a mismatch worth noting between the manifest version, which is 1.0.1, and the fact that the project is a fork of someone else's work. The manifest still carries the original author as the package author, with the current maintainer listed as a contributor.

Running it locally, and why the address has to be localhost

Setting up locally takes the usual steps. Check out the repository, make sure you have Node.js installed, which usually bundles the npm command line interface, and the notes recommend using a Node version manager such as nvm to install Node and npm. Then run npm install in the repository folder, run npm run build, and run npm start to launch a local HTTP server.

The server serves the generator folder, and the notes tell you to open one of the indicated URLs, for example http://localhost:8080, in the browser. Then there is the detail that trips people up: use localhost rather than another alias, because it is treated as a secure context, and that enables access to more advanced JavaScript features. In other words, if you reach the generator through a LAN address or a machine name rather than through localhost, some of the browser features the generator relies on will not be available, and the failure looks like a bug in the tool rather than a configuration mistake.

For a published site the instruction is simpler: deploy the contents of the generator folder to your server. There is nothing to run on the server side.

Dropbox integration without a shared app

The one feature of the hosted version that involves a third party is cloud storage, and the design choice there is a good one. The hosted generator can support Dropbox without using a shared Dropbox app. Each user creates and configures their own Dropbox app, then connects it from the generator.

The reason is separation of authorisation. A shared application would mean one set of credentials and one set of tokens for every user of the hosted site, which concentrates risk and makes per-user revocation impossible. With each user bringing their own app, the authorisation for each person's files stays separate, and the generator never holds a credential that belongs to someone else. It does mean the setup is more work per user than clicking a connect button, which is the usual trade for that property.

The manifest's dependency list explains part of the mechanism. The request libraries are the HTTP client, and the archive and stream helpers are for handling the file payloads that come back from a cloud storage API.

The FAQ answers the questions that actually arrive

The troubleshooting list in the project notes is short and unusually practical, and reading it tells you what a real user hits.

The first is about browsers. A modern browser is supported, with Chrome, Edge and Safari named, while IE and Firefox are not supported, and the reason given for Firefox is privacy concerns, which points at the browser blocking the local storage or the API the generator uses for saving. The second is about cards generating without icons and background colors, and the answer is not a bug report but a browser setting: enable printing background images in the print dialog. The third is about the card layout breaking, with cards appearing outside the page, and the answer is to check the page size, the card size and the cards per page settings, with the example that asking for 4 by 4 poker sized cards on A4 paper will not fit and will overflow the page.

All three are the kind of issue that looks like a broken feature and is actually a configuration difference, and the fact that they are written down is the difference between a tool people keep and a tool they abandon.

One maintainer, and no tests

The support section says what you need to know about the project's future. The original author is no longer maintaining the project, and it is now maintained by another person in his spare time, so updates may be infrequent. Replies to questions, requests and bug reports may also take some time.

That is a fair and honest statement of the situation, and it is the kind of thing to weigh before you make a tool part of a workflow that depends on it. There is a forum linked for project updates and to start a discussion, which is the right place to raise an issue, and the project also publishes a live preview and a documentation page, both hosted on the same site as the generator.

The test situation is worth a sentence of its own, because the manifest is explicit. The test script is a placeholder that echoes an error message and exits with a failure, so there are no tests in the repository. The code is a browser application, so the risk is concentrated in the asset build scripts and in the generator itself, and neither is covered. For a tool whose output is a set of printed cards, that is a reasonable risk to take, but it is a risk rather than a non-issue.

Two licences, and the icons are a third

The project notes state that the generator is provided under the terms of the MIT licence, and the repository contains a licence file. The package manifest, however, declares ISC as the licence field. The two are similar permissive licences with different notice requirements, so if you are redistributing the project as part of something larger, the file in the repository root is the one to read and the manifest field is the one to fix.

The icons are a separate matter again. They are made by various artists and available through the game-icons project, and they are provided under the terms of the Creative Commons 3.0 BY licence. That licence has an attribution requirement, which is why the credits are stated separately in the project notes rather than folded into the software licence, and it is the part of the licensing that a table organiser who is printing a deck for a game actually has to care about.

The last push to the repository was on 2026-10-20, and the project publishes no tagged releases, so the state of the master branch is the state of the tool.

Editorial conclusion

rpg-cards suits a game master who wants printable cards quickly and does not want to run a service, because the output of the build is a folder of files that any web server, or even a local directory, can serve, and the generator itself runs in the browser. It is the wrong choice if you need a maintained tool with tests, because the test script in the package manifest is a placeholder that exits with an error and there are no tests, and it is the wrong choice if you need automatic updates, since the project notes say explicitly that updates may be infrequent now that it is maintained in one person's spare time. Before you deploy it, decide which licence applies to your use, because the project notes state MIT while the package manifest declares ISC, and remember that the icons carry their own terms, a Creative Commons 3.0 BY licence, separate from the code. The current package version is 1.0.1 and the last push was on 2026-10-20.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mephitrpg/rpg-cards on GitHub
4. Project website
5. README