Go To Page 1
It’s time, once again, to talk about my experience in the world of game development. For those who don’t know me, I’m a full-stack engineer that has become dissatisfied with my job and the software industry as a whole, and am aiming to improve my outlook by getting into independent game dev. Along this path, I started several (unpopular) blogs in the last few years, that were primarily focused on my experience using different technologies and frameworks, such as PyGame (and variations) and Unreal Engine 4. While I did appreciate UE4 for the mere fact that it supported a correct object-composition structure made up of entities and components, most frameworks I used were always lacking in a major way. Some were either way too opinionated about game architecture (e.g., UE4), or they just didn’t offer enough support to make it a viable framework for the lighter-weight games targeted at web/mobile (e.g., Kivy). After years of learning what felt right and wrong from these frameworks, I decided it was time to see what I could do using my preferred environment (javascript/es6 stack) starting from scratch.
Earlier this year, I began writing a WebGL/JS framework, using BablylonJS as a model for the WebGL library, and using React for page construction (HUD/UI/etc). The project was split into two major stories: the framework and the game. Both were going quite well, and are in a decent state, though I have taken a bit of a hiatus from them due to time restrictions. I plan to get back to it sometime this fall, so you can expect some pretty sweet posts about that in the future. In the mean-time, if you would like to check out the current public state of the engine, feel free to browse around here. But let’s get back to the meat of the post; the reason I started the new blog.

Whether or not you’re old enough to remember the originals, most gamers have encountered the “Choose Your Own Adventure” book. I would argue if you’ve played Monkey Island, or even the more-recent The Walking Dead Telltale series, you’ve experienced this book. Often structured like single-player D&D campaigns, these games take you through a deep story, only to have you make the important decisions that tailor the adventure to you. It’s a great experience when done correctly and a boring when when not.
My latest venture is to do some creative writing, expressed through this game structure. To write a story that will, hopefully, be a rewarding experience for others to read and play. My first step was writing a story parser, that will essentially parse and interpret a script. I approached this using a cursory method, where at any point, the current state of the game is a data tree and a story entry (one block of narration, speech text, a menu, or input). From this story entry (or cursor), I can then proceed next or back along the story as defined in the script. This helps abstract the story writing from the actual programming, and makes the overall writing a better experience. Here’s an example of a possible script structure being used in my first game implementation using React Native (i.e., story):

The snippet above shows the script for a portion of a chapter. It’s definitely not as abstracted from the code as I’d ultimately like, but I believe it’s a step in the right direction, compared to other story-driven frameworks, such as Ren’Py. I broke out entries into a few different types which have corresponding react components for visual representation: Dialog, Menu, and Input. Each of these have a defined contract of properties they can handle, but you’ll notice from the above code, that they all share some common properties, some optional, like actions, and some not, like next. You’ll also notice that nearly all the properties are lambdas, so that they can be parsed upon load and change depending on the game state, which makes it much easier to customize the story to the player’s name, gender, etc., or any variable set along the course of the game. Actions, which are emitted by the story’s EventEmitter, in this example are being passed along through to my redux store’s dispatcher like so:

The actual story parser is a separate module, completely independent to the script and view (it’s not dependent on any other libraries), so it can be used by any framework for any device (that runs javascript). It just so happens, that I wanted to target this game towards iOS/Android devices, so I’m writing the interface layer with React Native. I may release the story parsing utility as a free open-source project in the future, but I’m keeping it proprietary for now in order to build it out, and make sure it’s a robust solution.

My biggest hurdle with the current story I’m working on is the artwork. As one or two of you who have read previous blogs of mine may know, I am not an artist by any stretch of the imagination. This is particularly unfortunate in my situation, because much like this game, most of my ventures are pretty dependent on good artwork. Currently, I’m using free-licensed artwork I can find from reputable websites, but I intend to eventually find an artist I can work with to create original art for the story that will greatly enhance the player experience. But of course artists cost money, so this is a constant battle.
I’m about 90% done with the game’s groundwork (mechanics, UI structure, etc), and have just finished the first chapter of the story, so it’s going well. My plan is to start releasing alpha versions / demos with my updates once I have some artwork to go with the game, so for anyone interested in that, stay tuned.
Dave
Thanks for reading, and of course, sorry you had to read that.
Please comment here with any feedback, or feel free to email me:

