A few weeks ago, I mentioned that I might put together an HTML5 Roleplaying game tutorial and inquired how much interest there was in the subject. There was sufficient interest, so I dove into the subject a little bit closer and came to a bit of a conclusion. It’s ultimately the tools that make the game in this case. So, in addition to a game, I would have to create an editor, which is actually where most of the guts would reside.
- single language, end to end
- server based editor, that can be run locally on the client
- code reuse between game and editor
- MVC/MVP or MVVM based. ( if you don’t know these acronyms, don’t worry )
- event driven
- rich UI
- run on a tablet’s browser
- database and local/remote filesystem support
- json-based level output, which can be used by clients in any language
Part of these requirements are driven by personal interest, I have always wanted to try making an MVC based game editor. MVC means, model-view-controller ( MVP == model view presenter and MVVM == model view viewmodel ) and it is a manner of design for decoupling your data ( your game’s/editor’s objects ) from your view ( your application or webpage ). There are a number of great advantages to implementing things this way, including testability, maintainability, reuse and perhaps most importantly, it imposes a clean separation of responsibilities between systems.
Now the whole running on a server and locally, that presented a bit of a trick. I want people to be able to follow along, and run it from their own computer for their own projects, so offline is a must. However, I also wanted an editor available for people who are only interested in game side of the equation, which is why I want to host one on my server. That said, I also don’t want to bog my own servers down too badly. This presented a bit of a problem, but it was solved soon enough when I started looking into….
HTML5 has some options when it comes to local storage, such as well… webStorage. There are some pretty heavily limitations here, one of the biggies is the lack of support. Size limits are also rather severe size limitations, in the area of 2.5-5MB, a limit that you will run into extremely quickly. The alternative to persist these files on the server isn’t really appealing to me, when I am the one paying the server bills!
This is where Node comes in. Node nicely solves just about all of these problems. Essentially I am going to develop the editor as a node based client/server, where the user has the option of installing the client and server locally, and running it just like any other application. This gives me access to the local file system and whatever other libraries I need. However, it also allows me to use the exact same code to provide a hosted version of the editor other users can simply run in their browser. Essentially Node will act as the host for the DB, as a web server and as the interface between the local machine and the view.
Speaking of which, this leaves the view…
jQuery for the UI
jQueryMobiel for the mobile UI
Node for the backend
CouchDB or redis for the database layer
Express for the server bits
Backbone.js for the um, backbone ( this is where MVC comes in )
Moustache and icanhazjs for the templates
underscore, well, just to make things work
YUI for the front end (desktop and mobile), routing, MVC and server bits
Node for the backend
CouchDB or redis for the database.
Handlerbars for the templating.
Both have benefits and detriments, especially from the perspective of a tutorial.
jQuery is easily the most popular UI library out there, and there is a gigantic amount of support available ( and dozens of books ), with a gigantic community. Backbone and Moustache are less used, but still well supported. Unfortunately, this also means introducing a half dozen pieces of tech, a very confusing prospect. Development on all of these products moves extremely fast, which is a double edges sword. Finally, and this is highly personal, I hate the look of jquery and underscore code, it feels so… hackey.
YUI on the other hand, is from a single vendor, with much less supporting material but very good documentation and a very clean modular design. More to the point, it is an end to end system so it is very consistent. However, if something goes wrong the community is much smaller and the supporting materials aren’t as readily available. Perhaps the biggest downside with YUI is the newness of it. YUI3 is still in transition away from YUI2, and YUI App ( the YUI equivalent to Backbone ) is young and at times it shows. From an engineering perspective though, YUI just feels more solid and less like a clever hack.
Right now, ease of explanation is winning out, and I am leaning towards using YUI. Going with on all encompassing library is much easier to configure and explain to readers, so that is a big plus.
Any thoughts or opinions on the subject?
Oh, and if this is all sounding extremely confusing, don’t worry, it really isn’t that bad. The end product should still be a single archive you download and execute with a simple click.
So, over the next few weeks ( or more ), we are going to be going off on a slightly odd tangent here at game from scratch, and crossing over into the world of web app development, I hope many of you find it interesting. For those that don’t, don’t worry, I will still be publishing game development specific contents and tutorials too!