As the project is still in an early stage, I’m exploring a lot of different things to have a clear view of what could be done and how, and be able to plan accordingly. Therefore, I took a small break from procedural world building, to play with something entirely different: packaging my Javascript/HTML5 browser game as a standalone desktop app.
Why a desktop app?
The main reason I wanted to be able to pack my game as a standalone app was to be able to distribute it on Steam, Itch.io or similar markets one day. Publishing a game on these marketplaces has become an important step in the release of an indie game. A few Javascript/HTML5 games have successfully done it, such as Duelyst, GameDev Tycoon and Wild Terra, to name a few.
In addition, having the game wrapped as an app allows for a standardized runtime environment (a Chromium one) rather than the plethora of browsers that one can encounter online. If you use Electron or NW.js, that environment also allows you to use Node.js modules in the client, which can be very convenient, for example to use the great Pathfinding.js library, or the dgram module to use UDP to communicate with your server (which might be a necessity over TCP depending on the kind of game you make).
Why a desktop app… in Javascript?
That being said, it might seem weird to want to build a desktop app with web technologies, rather than using a more conventional approach (such as building the whole game in C# or Python). Arguably, the end result would probably be better (at least faster and more efficient). This leads to the important question of choosing your technology.
I have come to believe that engineering arguments are not the only ones to consider when deciding which technologies to use to make a game. Making a game is a usually long endeavor filled with many challenges and motivational pitfalls. Indie projects often fail simply because of the passage of time and the loss of motivation or funding.
An important step to prevent that in my opinion is to produce as fast as possible what is called in the startup world a Minimally Viable Product (MVP). In the case of an indie game, this corresponds to a playable, self-sufficient and polished game with only a relatively basic set of critical features. This minimal game can then be improved upon, but will in the meantime be a source of feedback and motivation (and sometimes even revenues) to fuel the rest of the development. More importantly, it’ll allow to test the waters, and see if the game could actually have a future, or is a dead end unless the concept undergoes major revisions. It’s crucial to discover that as early as possible, which is the whole point of the MVP.
With the development of an MVP in mind, things like premature optimization and feature creep have to be absolutely avoided. To the extent that it may even be interesting to make the game with possibly sub-optimal technologies, for the sake of developing it faster. What matters is to have something that works at the end of the day and which the players can experience. Technical refinements can and have to come later
In my personal case, it turns out that I’m mostly experienced with Javascript and Socket.io/Node.js when it comes to developing a multiplayer game. I could easily learn how to do it in Python for example, and many language-independent concepts would still apply, but it would nevertheless take some time before I reach the same level of proficiency as what I have with the aforementioned technologies. Time which would be diverted from the main goal of actually building the game.
The decision to make a Javascript/Node.js game as a desktop app therefore followed from my proficiency with that ecosystem combined with the need to be able to deploy it as an application.
I recommend watching this GDC talk whose content doesn’t directly match what I discusses here, but resonates with it.
Electron vs NW.js
For those interested, there are two main frameworks nowadays to make desktop Node.js apps : Electron and NW.js. I refer you to this page for a detailed comparison between the two.
I have experimented with both, although relatively superficially. My preference seems to go to Electron, which for some reason feels a bit more “elegant”. Again, not a strong technical argument, but the good thing is that it is very straightforward to switch from NW.js to Electron; it’s almost only a matter of changing a few lines of your package.json file (at least for a multiplayer game, this statement may not hold for some other types of advanced applications with specific requirements).
What’s next
I have explored some possibilities with respect to making an app out of my game and made sure it would work well in the context of a multiplayer game. This was mostly a side quest, which I wanted to explore now to make sure I wouldn’t have nasty surprises later on. The conclusion is that very little code adaptations will be needed, which is good.
I actually made a client for the “basic Phaser MMO” from this tutorial, and I might make a tutorial out of it one of these days if anyone is interested.
In parallel, I have also been busy writing a few development/debugging methods to make the procedural world building experience more fluid and practical. This should help a lot, and I think that the next entry will come back to the topic of procedural terrain creation, hopefully with some more advanced results!
Jerome Renaux
I'm an independent game developer, working mainly on browser-based multiplayer online game (HTML5 & Javascript). I love to discuss about all aspects of game development so don't hesitate to get in touch!
Follow Me:
