Scope and technology

Underlying technology does not actually matter in some sense - if a game is good, people will play it. But in another sense, technological choices made early shape the project until it dies. So it's good to put some thought into these choices early, and see how well it works with the initial version.

Initial version should be a minimum viable product: it should be playable in some form. No nice UI, no VTT, no voice chat - only minimal core. First version should have basic mechanics, couple of options for players, connectivity. After playtest is successful, I can move forward with niceties.

Some requirements for future solution:

• (Relatively) high performance. Most solutions to play complex TTRPGs online now are simply a bad experience. They are on the web, and they usually struggle with non-trivial scenarios. In full a campaign system need to crunch hundreds of rules multiplied by hundreds of stats per character and thousands of entities. My game would be even more complex, so I don't have the option to stick to Javascript.
• Cross-platform. It's absolutely required to work on major phones and major desktop OS. It's not strictly required, but it's a huge plus if it can work in a browser. Even if one player in a group can't use it, group would not use it.
• Fun to develop. This one is simple. The less fun it is, the less chance to finish it.
• Availability of high-quality libraries to rely on.

And what I picked:

• Rust is currently the main language. It's a bit risky - Rust isn't known for ease of prototyping. However tooling saves a lot of time, it actually works on all target platforms and in browser with WASM, it's as performant as it gets. And most importantly, it's fun.
• Dioxus is the current GUI. I'm trying to write code not too tied to specific GUI, and keeping a door open to switch to something more mature like Flutter if needed. However for prototype it's perfect.
• Iroh for networking. P2P is at core of project philosophy, and this is a solution which worked very well in initial tests and was extremely easy to use.
• Bevy Entity Component System. I don't actually need full game engine, so whole Bevy is overkill. But Entity Component System is something which works really nicely with TTRPG framework: best pen and paper TTRPGs already kinda split data into entities/components and systems. And it should allow me to soften some pain from using Rust.

So far this set works well for prototyping, and I have moderate levels of confidence in it. Would be interesting to go back and see how this project evolved.