mikkelpaulson

Thanks, I appreciate the support.

initiative.sh[0], a web-based text interface for creative D&D play. After a promising response on HN[1], I had hoped that I might be able to monetize the project, but traffic has since crashed to almost nothing. I would say that after six months of full-time development it is about halfway to being complete as a freemium product, so instead I've opted to open-source it.[2]

It turns out that the challenge with launching a freemium product is that you need something that's both useful as a free tool while also having a compelling value-add for paid users. That's a lot for one person to build. I don't think I'll be aiming for that monetization strategy with future projects.

I have to confess that I'm (barely) missing the qualifying income bracket - some kind soul is supporting me for $5/mo on buymeacoffee.[3]

[0] https://initiative.sh/

[1] https://news.ycombinator.com/item?id=29106581

[2] https://github.com/initiative-sh/initiative.sh/

[3] https://www.buymeacoffee.com/initiative

initiative.sh is a context-driven web-based command line for D&D game masters. I approached development as my day job, devoting about 6 months of full-time work to this project. That's no longer a development cadence I can sustain, although I still plan to be an active maintainer and contributor.

By popular demand, or at least popular inquiry, I've decided to open-source the project at its current state. It's useful in its current state (I used it every week as GM), but some of the really cool features lie on the horizon. I'm now inviting contributors to help me make that a reality.

Previous submission: https://news.ycombinator.com/item?id=29106581

My LinkedIn recruiter spam dropped substantially when I added "literally a wizard" to the skills section (and removed everything remotely tech-telated).

https://www.linkedin.com/mwlite/in/mikkelpaulson

Update: done!

Update: this is now done.

Update: done.

Update: this is now done.

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.

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.

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

I've been hearing that one a lot. It's next on my to-do list.

That's coming up (or going away) in the next few days.

I currently have no plans for D&D Beyond integration, or maybe more to the point they have no interest in integrating with me.

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.

[0] https://improved-initiative.com/

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]

[0] https://github.com/5e-bits/5e-database

[1] https://shmeppy.com/

[2] https://store.steampowered.com/app/1694430/Dynamic_Dungeons_...

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"?

I've wondered about that myself. I did swap out "race" for "species", but I don't know of a preferred term there.

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.

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. :)

Edit: Fixed now.

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.

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!

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.

Yup, that's planned for the next milestone. :)

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.

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.

[0] https://crates.io/crates/caith

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!

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.

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.

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.

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.