Welcome to the first installment of what I will be a journey from an idea I have to a game you play. Along the way I will learn to code in Elm. I hope you will find the chronicle of my failures and successes interesting and maybe even useful or inspirational.
First of all, I am no coder.
I have a basic knowledge of HTML and CSS that is now a decade old, I understand the logic behind an IF statement, but that’s about it. I wanted to learn to code for a long time, but so far I only managed to accrue a bunch of false starts. New year, new resolution. Let's hope this doesn't jinx the project x_x
The reason I want to learn to code is... I want to make games! Some games I was able to produce already on my own as "normal" tabletop rpgs. They are available to all my faithful Patreons, or through the DriveThruRPG store. But others would require a code developer to believe in me and my vision, to devote me time and effort for the sake of it, and to deal with my winning personality ... realistically I'm better off learning to code on my own :P
To facilitate the success of this endeavour I decided to start a concrete game project, and to document it with a development diary. To help me stay motivated and avoid distractions, and to chat about my learning process, and design process, and development process with whomever might be interested.
The Game
I have a tabletop rpg currently in development named FUBAR Dungeon. It is meant to be a super light and easy to pick up dungeon crawler that follows the philosophy of Old School games, but that also leverages modern design techniques to make it way more immediate and accessible than classic retro-clones, and of course it has to be gmLess because I’m deranged that way.
Its development got to a halt when I started realising that for it to do the things I want it to do, I would have needed to add more and more procedures for specific things and random tables to generate appropriate content. For my design goals this is unacceptable; it would turn a simple design into a fiddly mess, and grow a few terse pages of procedures into a much lengthier and heavier book. The solution I found is to have all the fiddly mechanics be handled and facilitated by a program.
The App
I’m not thinking about a simple smart pdf. Those are just good old digital rulebooks with some quality of life features added to them: better indexing, fillable character sheets, etc.
No, I want my app to be an real "videogame", a program that makes you play by automating and handling the gears and cogs of the actual tabletop play experience. A sort of virtual GM/Facilitator that knows the rules so you don’t have to, that directs the phases and flow of the game, that deals with lists and tables in the blink of an eye so you can focus on the story and the action and the danger and the fun.
What I want to achieve is a classic tabletop rpg experience, with a strong fiction-first / fiction-matters approach, where Players will sit around a table and describe rooms and challenges and epic actions and funny goofs ... and an app in the middle of it all will provide the needed structure for this to happen. In terms of coding this should be a project simple enough and small enough that I can realistically see through to its end while using it to learn the Elm language. And at the same time it poses an innovative game design challenge. I’m both scared and thrilled by the prospect of working on such a thing!
The Elm Language
Elm is a functional programming language that compiles into Javascript. I spent quite some time procrastinating getting informed about it and now I love the idea of it; both its philosophy and practical application remind me a lot of the ones at the root of modern rpg design.
With all sorts of Javascript you can pretty much do whatever you like in however way you like. In theory this means power and flexibility. In practice it is only true for very experienced, very disciplined, very dedicated people... the ones who know JS inside-out and all its best practices and shortcuts and have the mental fiber to actually put all those bits of knowledge into everyday practice. Not something you see commonly (or at all, according to some).
With Elm you take all that knowledge, all those best practices, and bake them into the language. If you write Elm you follow those best practices as a matter of course, period. The compiler will enforce the language rules, ensuring you don’t forget anything, you dot all the i’s and cross all the t’s and avoid pesky undefined elements. And whenever there is an error, the compiler catches it and tells you in a very detailed and informative (and human) way where the error is, what the error is, and even offers suggestions on how to fix it. All of this before you actually run the code in the browser.
These are not just extra features slapped on top of JS. The very language is built from the ground up to support such features, alongside other design goals such as human readability, code modularity, ease of maintenance and refactoring. And ease of learning. This last one I’ll directly put to the test myself. Obviously I'm being enthusiastic and Elm can’t possibly be the best thing for everyone, to do everything, every time. But for my own needs and purposes it looks terrific, and I’m very excited about it.
The calm before the storm
In the end what I am saying is:
I will design a tabletop rpg. I want it to be gmLess. I want it to be super easy to pick up and play. I want it to be narrative and fiction-first. I want it do be heavily focused on challenging Player skill rather than Character attributes, like the old dungeon crawls from the 70s.
This game will be playable thanks to an app. I want it to be a Progressive Web App. Mobile first. Offline. Coded with the Elm language. And its development, both the game design and the coding, will be documented by a series of blog posts just like this one.
See you next time.
