Building Dungeon Key, a Vanilla JavaScript Application
Flatiron Project number four — finally! Catch the repo here.
How many projects have I finished now? Well…
Lets rewind back to the beginning though. Dcode has a great supplement to the Flatiron instruction set with a fantastic tutorial https://youtu.be/6BozpmSjk-Y Essentially a one-stop run through of using Node JS and using it’s Express library to serve up a pretty nifty single-page application (SPA) framework. In the interests of meeting our requested minimum viable product however, I realized I’d be delving into coding material beyond our requisite code-base and would probably not be eligible for submission to our project review. So now, that version — which was once a repo with a solid number of commits is currently sitting in a now neglected branch. Time and patience permitting the opportunity to thaw it out.
After that was a severe underestimation of the complexity of formatting markup that goes into building a role-playing game character sheet. For the uninitiated, role playing games use a collaborative narrative construct, i.e., you and your friends have a shared set of game rules to tell a typically free-forming story at the behest of one player functioning as the game-master — think like the referee, but they tend to use dice to adjudicate the cruelties of fate. Important to most of these games, is a your character.
Essentially a form document that details the imaginary person that will adventure in the imaginary world. These sheets can vary in complexity from game to game, and playing group to playing group. Some can have the nitty gritty of tallying up every single element in their fictional inventory down to the ounce, or building elaborate backstory timelines. While other games are less stringent, and maybe just care about the character’s appearance and a few of their noteworthy abilities.
Now that was not a waste of course, that kind of deep delve into the public repos of ongoing online applications like Roll20 and Foundry VTT really drove home a lesson in just how much HTML and CSS goes into building the appearance and functionality of modern front end applications, only for much of it to largely be invisible in the form of white space, or document node names and ids. For example something like a character sheet for Dungeons & Dragons, the currently most popular game in the industry in it’s currently fifth edition, is massive. My original goal as part of this learning jaunt was the hope of using JavaScript to build a character generator for my favorite game Eclipse Phase. The game being fantastic sci-fi/horror game set in a dystopian world where technology has progressed to the point that the very human mind itself can be copied, forked and edited like software, and transferred and downloaded into a new body. Much like the books and now canceled Netflix series, Altered Carbon. Building a character creation wizard for this game certainly is a fun idea, but holy hell, building a character sheet alone, even forking the existing repos as a base and building the sort of minimum viable product we’re expected to produce, would take way more expertise to jam out a working application in a week. So I stowed that idea and ambition away, turned past those pages in my pen and paper notebook and carried on.
About a week into our JavaScript lectures, a classmate in my cohort asked an instructor: “What is the coolest thing you can do in JavaScript in 15 minutes?”
The instructor responded: “JavaScript? 15 minutes?….. Cry… Crying is about all you can do with JavaScript in 15 minutes.”
Okay so, back to square one. The idea was follow Laura & Aysan expert examples, and follow the age old engineering adage: ‘keep it simple stupid.’ That in mind, I still wanted to build something I could connect with, and in the same vein as before. So I started thinking about need niches inside the RPG thought-space. Essentially any person that is in charge of running a role-playing game no matter what the game system is, or the setting — they are inevitably going to have a cast of characters that aren’t directly controlled by the players, NPC’s — explicitly ‘Non-Player Characters.’ Keeping track of these NPC’s is typically the sort of thing people fork and build whole wikis — or even businesses models, around. That in mind, the final idea that drew everything into focus was a single image on Game-icons.net.
That did it, I’d build an indexing application. Leveraging my new knowledge of Ruby on Rails (v 6.0.0.0) to build the backend, with traceable version name-spacing.
So Rails provides a full ActiveRecord powered data basing with a many to many relationship. A ‘Campaign’ object, can have many ‘Npcs’ — although using acronyms leads to some interesting camel-case and snake-case issues. With the backend constructed using a `has-many` and a `belongs-to` relationships. Such that a Campaign can have many NPC’s, and each Npc belongs to a specific campaign.
Ideally this will be replaced in a future variation with a polymorphic association, so that that a character could theoretically belong to multiple campaigns. For example multiple stories across different games and settings could be menaced by some big recurring villain, like the legendary Dr Doom, the accursed undead Vecna, or the most pernicious of all…taxes.
Dungeon Key’s front-end is built using newly acquired knowledge of JavaScript. In the interests of supplying a well polished MVP, the application is currently only serving a few of the CRUD components. Namely viewing, creating, and deleting Campaigns. Currently the backend is using the `has_many :npcs, dependent: :destroy` variation such that when a Campaign deletion request is sent via a fetch from the front, the associated npcs stores are also deleted.