This project has been my full-time for the past six months or so (coming up on a
year since I joined the Great Resignation and decided to try my hand at
self-employment). I release somewhere between 2 and 10 times per week.
I set out to build something that I could use as a game master at the table
without having to put the game on hold as I navigated through menus and
bookmarks for the various references and generators I use. My general design
principle is that everything in the app should be available at any time, with no
need to navigate menus on one extreme, or read documentation on the other.
The core is written entirely in Rust with a couple of hundred lines of JS glue.
I was running it as a command-line app for the first month of development, and
it still works as such. However, since I added autocomplete to the web
interface, the web version is now more feature-complete than the command line. I
don't see much value in the extra work of backporting features to the command
line at this point. (Turns out Rust was the wrong choice for this particular
project, but the die is cast for the moment, and it has been fun.)
I've barely scratched the surface of the feature that I'm most excited by,
namely context. Soon it will be possible to tell the app where the party is and
what they're doing, and the demographics of suggestions (and ultimately music,
lighting, and other integrations) will be updated accordingly. In a seedy bar in
the docks district? You're more likely to run into sailors down on their luck.
Pick a fight? Cue the epic music. Sun sets? Dim the lights.
I do have plans to monetize this project in the future, charging for the
server-side features (integrations and cloud sync) while keeping the client-side
features free. Everything that is currently implemented will always be free.
I run an active PbP on Paizo.com and pre-covid I ran a lot of in-person games.
Before I was active DM, I thought computer initiative and rule aids would be great. As a DM, I don't imagine they would be for several reasons. A) I have accumulated an encyclopedic master of game rules (running the Pathfinder system, perhaps the most complex D&D variant). B) Dice and tables have a certain "feel" to them that stopping and doing something on one's laptop just doesn't. C) In person, I keep each players stats on a 3"x5" and stack the cards for initiative - this solve 99% of initiative problems, it has a nice physical feel and all my players, some of who will be computer-incompetent if not computer-illiterate.
I say all this because I think there are places where computer aids could shine:
1) Character generation - despite lots of projects, there's nothing yet that quickly and complete edittable characters for Pathfinder at least.
2) Map-aids for PbP. Roll20 and related systems simulate the whole in person game framework. Discord and most PbP basically just let you roll dice and maybe change stats with markup. A markup system that also allows change one's location on a map, along with system to manage that, would be cool and make the PbP system richer without forcing it into a "heavy" Roll20 type approach.
My experiences have been similar. I do still need to look up spells and item prices and such from time to time, so I did integrate those from 5e since the data is readily available[0] under a free(-ish) license. I figure if you need to look up rules, you're probably better off pulling out a book and using the index.
I don't expect my character generators to surpass the many resources that are out there already. The one way in which they might be superior is that they'll offer suggestions that make more sense given the current setting, as well as being readily available. I do want the app to help with stage management, since I don't have the attention to spare for picking out music or managing lighting as I'm trying to tell a story.
Definitely agree about Roll20 being too heavy. I just want to drag tokens around on a map. Unfortunately, that's also a very different project from the one I'm building. I haven't used it at the table, but Schmeppy[1] might be closer to what you're looking for. I look forward to trying out the Dynamic Dungeons Editor once I'm back to playing in-person, too.[2]
Feature request: up-arrow support (like bash shell has). IE: I want to reply the last command, or fix something in it (because I typed it wrong). Being able to up-arrow through my command history is something I use regularly on my normal command line, and would be cool to have here.
I'll write a blog post on the subject in a few weeks, which will probably end up here because Rust. The short version:
* This use case involves tons of string parsing and concatenating, which vanilla Rust does not make intuitive. A garbage-collected language would also probably handle this more efficiently than I can, given that Rust is doing exactly what I tell it and I don't have the time or inclination to microoptimize piles of parsing code.
* Generally, the work is sufficiently high-level to require large swaths of the standard library and a fair number of dependencies despite my best efforts.
* I've built a brick wall between myself and my data store. Ultimately persistence happens in IndexedDB with a JS shim, but currently the application loads the entire contents of your IndexedDB database into memory and runs based on that.
The WASM binary weighs in at 1.6 MB (500 kB over the wire). The source, without excluding tests, comes in at 580 kB (estimate 400 kB of actual code). If it were Typescript, I could probably minify that down to 200 kB or less, and that would still be plain text and achieve a better compression ratio than my WASM binary.
Mind you, I haven't put in a huge amount of work to stripping down the binary. But that's more or less the point: choosing Rust/WASM ended up having a lot of down sides without much in the way of up side, save for one: it's been a lot of fun to do, and I probably wouldn't have made it this far in a language I didn't enjoy as much.
This is great! Charging for integrations is a nice idea.
I wrote a Discord bot to trade stocks for my current industrial revolution campaign, as our DM maintains a stock market in Google Sheets. If I could upload my node modules somewhere and have it run on command like the Discord bot, I'd never have to leave this command line.
One of my biggest complaints about Discord for D&D is that it doesn't have command line functionality. Excited to hear that up-arrow is coming to this.
Wow, this is one of those elegant solutions that seems so obvious in retrospect - I tried developing a custom iPad app for DMing and found the huge amount of complexity of DMing really difficult to design around - a text interface is a really fantastic idea
Surprised noone has asked - any plans to make it open source and/or a self-hosted option? Would love to hack away at it, and would love to see the source or at the very least an API for integrations
Currently the core is planned to remain closed source, although if I decide to put the project on ice at any point in the future I'll definitely put the source out there, that being a general pet peeve of mine.
I do have plans to build out integrations, starting with webhooks triggered on events like creating characters, advancing time, or moving between places. I've also heard some requests for a bona fide command-line binary, which I might do if the demand is there. The maintenance overhead is not insignificant, though.
Sounds like a good plan - hooks for datastores or even data types along with event hooks would also be good, but not as key. Being able to place arbitrary notes on characters/items/objects would be good (For example - I'd like to say this NPC is a ranger, and someday you may add classes, but arbitrary notes would be also just as good)
This is where my mind goes - If this acted like a very thin layer that integrated with the plentiful amount of DM tools that already existed, and brought the context info with it, it would be a very powerful tool to centralize all this info. For example, I create a dungeon, the name generated either by your tool or by an API call to an existing service that parses and passes data into your system, then another hook generates a map and saves the persistent url/hash/some identifier into a custom field on that object.
If done right, there could be a minimal but flexible API with purely client side hooks that the community could leverage to bring more features - off loading a lot of work without needing to opensource it.
Of course, having said all that, even just as it is right now is super useful and exciting and I likely will use it even without any of those things!
This is an interesting tool and I could easily see it becoming a great add-on to campaigns as-is, and hopefully become more usable and feature-rich as you develop it further. Reading your replies to other comments about what you want to add to it and the ability to make changes to the world based upon input sounds awesome. Keep up the great work!
Very nice. Small suggestion: The commands are case-sensitive, and that's not immediately obvious. For example, entering "dagger" does nothing, as you have to instead enter "Dagger"
Awesome! Looks like a great way to learn a new programming language. I suggest attempting to recompile to WebAssembly as part of the learning process - it can be a bit frustrating, but very cool to see your code running in browser!
I use Caith[0] to handle dice parsing and rolling, although if this is a learning project you may want to reimplement that part yourself.
This looks really cool! One small suggestion -- I found it difficult to read the text that I was typing. The black text on dark grey is hard to read. The dark theme is nice, but I could only read what I was typing when there was a tooltip showing possible commands.
Oops, that's a bug! The site responds to your browser's dark mode preferences, and apparently I've been using it exclusively in light mode for a while. I'll get a fix out this afternoon. :)
Nope, ironically that's one feature that I don't have and is filed in the "maybe someday" bucket on my roadmap. Improved Initiative[0] is one of the few tools out there that I use at every session. It does just about everything I need it to do, and its interface doesn't make life harder for me.
I'd love to link things in the journal. Here's an example of what I mean.
First I create some entries...
character named "Rocky"
city named Snootville
bar named "Drunken Pug"
character named "Nick"
But then I want to do some little associations like this...
Drunken Pug is noisy <arbitrary attribute, not just gender related>
Drunken Pug at Snootville
Rocky likes perfume <another arbitrary attribute>
Rocky likes Drunken Pug <Show character and location associations>
Nick likes Drunken Pug
Nick hates Rocky
This lets me define relationships as well as attributes, and doesn't limit me to just gender related ones. Gender is just one of many attributes one may have, and may or may not have any relation at all to gameplay. Rocky's gender is secondary to the fact that they like perfume for example.
And by showing that Nick hates Rocky, but they both like the Drunken Pug (which is noisy), we've got a whole scenario defined for a DM. And given Rocky likes perfume, well there's the reason for the conflict right there if you want. "Nick didn't hear Rocky enter the Drunken Pug, but his nostrils flared at the scent of their cheap perfume..."
You could do a lot with a sort of "contains" relationship too. Create an island, which contains a city, which contains a district, which contains a neighborhood, which contains an inn.
I love the idea of cataloguing (and presumably generating) a lot of attributes about a character, but in general I'm not anticipating leaning too heavily into the generator side of things, so much as general campaign and world management. It's still up to the DM to breathe life into the world.
That said, I definitely intend to add relationships (initially hierarchical, which will be reflected in the journal view). It seems like it would be valuable to support arbitrary user-defined relationships between entities, although syntax and interpretation start to get fuzzy the more user-provided terms you throw into the mix. If you tell me "nick is at war with rocky", does that define a relationship between Nick and Rocky or does it tell me that Nick is at a place called "War With Rocky"?
One small bug - clicking on the "Roger is a non-binary halfling" example says it's unable to interpret the command, and neither of the suggested interpretations work either.
More of a miscommunication than a bug, but still something that needs fixing. Since the command renames an existing NPC, you already need to have created a `character named Roger`. Once that's done, the command should work as expected.
This is cool. I just posted the link on a blind gamers' Discord. I don't do much D&D--really want to change that at some point--but they're frequently complaining about D&D Beyond being an accessibility dumpster fire and looking for something else.
I poked it a bit, and really appreciate that command output is automatically spoken under NVDA. I don't imagine that is accidental. :) Thank you.
Now you have me wondering what web-based command lines I might build. Maybe a crazy idea, but have you thought about adding external command support somehow? Accessible map representation is vastly unexplored, and it'd be fun to build that in the context of initiative.sh somehow. Maybe a web service, or a wasm module if you want to be one of the cool kids.
I could also see this being an embeddable widget in something like a Matrix room. Give everyone a shared context that all their commands can reference, maybe with different permission levels. The context might share all characters with the DM, each character with its own player, a representation of the map which they could move their character on in turn, etc. I've probably just scope creeped the hell out of your project, but this is really neat and I'm intrigued.
> I poked it a bit, and really appreciate that command output is automatically spoken under NVDA. I don't imagine that is accidental. :) Thank you.
I'm gratified to hear that. It occurred to me early on in development that this could either be fantastic or an absolute disaster from an accessibility standpoint, so I made a particular point of getting the aria tags correct. However, I'll confess that I haven't actually tested it with a screen reader yet, so perhaps it's better to say that it's not entirely accidental.
You're right that there's plenty of scope creep in what you're suggesting, and it's probably beyond what I'll be able to handle. However, you've given me a strong motivation for open-sourcing the frontend. It's an absolute disaster from a code standpoint, but it's very simple and could be used as a jumping-off point for just about anything that simulates a screen reader experience.
Just wanted to chime in and say that I think this is a beautiful piece of software: fast, responsive, and intuitive. It's a pleasure to use, and your tutorial did a great job walking me through it. Congratulations!
I've already tossed this into our DnD Discord, and our DM may use it in the next session.
This is super cool! I love it overall but couldn't help but want for it to let me link NPCs/things to locations and just generally add more metadata for when campaigns progress and the world fleshes out more
Yup, notes and relationships are high on my list! I've been mulling those over this morning. I added a ton of place types yesterday, and another high priority is to give them name generators to get rid of that clunky error message about needing to name your kingdoms.
Sounds great, I didn't know that was a thing! I don't see a public email address on your profile, though. You can reach out to me at support@initiative.sh.
Can you give a log of using this product in a real session or such? I'm playing with it some but I'm finding it hard to find much use other than generating character and place names. An example of commands you entered would do a great job of demonstrating what it does.
I suggest walking through the `tutorial` for a hands-on example of the various features and how they might be used in a game scenario. It does jump around a little bit, as there are some important features that haven't been implemented yet.
This is amazing! I dungeon master for a online D&D experience (https://www.haze-saltborne.com/). Look forward to using this when I'm generating NPCs and such.
Thank you! The best complement I receive is when I hear that people are actually using this at the table. I'd appreciate if you stopped by the Discord (linked on the homepage) to share your experiences using it.
I've included all of the spells that are available under the Open Game License. In the future, I'll introduce the ability to upload your own reference material, but I'm being careful to avoid copyright infringement in this project.
Agreed! The first integration I build will be webhooks to allow people to extend it however they see fit. Currently my built-in integrations are planned to skew simpler, like switching Spotify playlists when the location changes. However, it really comes down to a time investment/feature desirability tradeoff. If users are really excited about something like that, I'm not going to argue!
I would dearly love that. The D&D ruleset speaks imperial, so so do I. (I'm assuming that's because they're trying to be old timey.) Adding metric alongside is easy enough, though!
It was a deliberate design choice, but one that I've come to regret. (A lot of people are also commenting on this.) I'll be switching to case-insensitive in an upcoming release.
If you want an alternative to GM (I can see why you might want to, but I'd be curious to know how many people see it as a problem), "referee" works well. Has an old-school flavor, and because it's an old term it won't really raise any eyebrows or "why don't you just use game master?" questions.
I'm curious as to the reasoning here. I know the word "master" has some seriously negative associations when opposite the word "slave", but that's not the case here. Nobody that I'm aware of calls D&D or other RPG players "slaves". If anything, a good GM is there to serve the players, not the other way around.
Edit: I support replacing usages of the paired words "master" and "slave" so as not to reference the very real history of slavery. I'm also totally fine with using "referee" instead of "game master". But I'm concerned that other senses of "master", like "master craftsman" or "gold master" or "game master" which refer to mastery (of a craft or some such) and don't (to my knowledge) connote "master/slave" are being lumped in here.
GMs develop the narrative that players work through, so why not call them story tellers or narrators. That would be a more literal description of their role.
I set out to build something that I could use as a game master at the table without having to put the game on hold as I navigated through menus and bookmarks for the various references and generators I use. My general design principle is that everything in the app should be available at any time, with no need to navigate menus on one extreme, or read documentation on the other.
The core is written entirely in Rust with a couple of hundred lines of JS glue. I was running it as a command-line app for the first month of development, and it still works as such. However, since I added autocomplete to the web interface, the web version is now more feature-complete than the command line. I don't see much value in the extra work of backporting features to the command line at this point. (Turns out Rust was the wrong choice for this particular project, but the die is cast for the moment, and it has been fun.)
I've barely scratched the surface of the feature that I'm most excited by, namely context. Soon it will be possible to tell the app where the party is and what they're doing, and the demographics of suggestions (and ultimately music, lighting, and other integrations) will be updated accordingly. In a seedy bar in the docks district? You're more likely to run into sailors down on their luck. Pick a fight? Cue the epic music. Sun sets? Dim the lights.
More details are available on my blog:
https://mikkel.ca/blog/introducing-initiative-sh/
I do have plans to monetize this project in the future, charging for the server-side features (integrations and cloud sync) while keeping the client-side features free. Everything that is currently implemented will always be free.