Experiments in text adventure

Like many who were into computers “back in the day” I still maintain a nostalgic, warm and fuzzy feeling at the memory of early text based adventure games.

Back when all I knew were the PRINT and INPUT commands in QBASIC, these were the very first programs I created.

Where am I going with this?

Well over the weekend I was learning the Impress.js presentation library and thought to myself that it really was a beautiful way to display text in a web browser. Then a little light bulb went off in my head.

3 hours later, I had forked impress.js and used it’s HTML5 canvas and CSS3 animations to create an engine for a modern text adventure game.

You can see the results of that intense session of programming here http://csainty.github.com/ImpressGame

I have quite a few other ideas for what I could do with this underlying concept. If it eventually comes together as I see it, it will be beautiful.

Getting deeper into Open Source

It’s about 8 months since my first contribution to an open source project. It was followed up minutes later by one to reverse all the accidental formatting changes I made. Damn you Visual Studio!

I am happy to say that it was not an isolated contribution though.

Now I am by no means a prolific contributor and my spare time is more often spent tinkering with my own ideas and projects rather than working hard on open source. However, there has been a steady enough flow of pull requests and projects to keep me satisfied that I am at least involved.

RavenDb and Nancy are where most of my focus has been. Two great examples of modern C# open source development.

In my own right there have been RavenDb plugins for Glimpse and MvcMiniProfiler.

Straying from C# there is even a start being made on a Node.js client for RavenDb. Getting started with Node has been an absolute blast, and my first serious attempt at adding a new language to my skill set since C#. Sure I’ve dabbled with jQuery heavy javascript in the past to add a little life to a web page, but truly learning the object model and scoping rules of javascript is a different beast entirely.

Most recently, as in last week, I have been pitching in at Code52, a new idea for this year which tackles a new project every week. It has been very .NET focussed so far, but that is simply a product of the founding core of developers having .NET backgrounds. At the end of the day, the people who are in the chat room at the start of each project are the ones who decide the technology stack. I hope to get them doing a Node project at some point this year.

The project from last week was IdeaStrike a UserVoice inspired (clone?) site that you can simply deploy to AppHarbor and manage yourself to track ideas and gather feedback about your product. You can see it in action at http://ideastrike.apphb.com/.

It uses Nancy and Entity Framework. I wouldn’t call it a best practice example of either at the moment, it is tough to refactor a project that goes from start to finish in a week. It is however a good example of a non-trivial application, with (some) tests, in Nancy.

Even though the week is up, the project does not stop there. People are always welcome to fork, change, commit and send through a pull request.

A full list of previous projects, that will update over the year, can be found at http://code52.org/projects.html.

This week the focus is a cross-platform multiplayer game. Much further out of my comfort zone, but a great chance to learn some XNA, and eventually Android and iOS when those clients are added.

Now this is a fairly reflective post, not my usual style, but the point is really just to spread the word. There are lots of interesting projects around, big and small, in almost any language you care to use. Just pick one and jump in.

Running a NodeJS server alongside your NodeJS desktop app

The node-webkit project added a new feature yesterday, one which I requested. So I feel I should put up a quick post about it and why I think it could be useful.

The change was simple enough, giving you the ability to pass a callback to node-webkit that is called when the application is closing.

The primary reason I wanted this was to allow you to create, and then clean up, a local web server within the lifetime of your application.

It was previously possible to create the server, but when you closed the app, the process would stay open with the webserver waiting for requests.

The callback looks something like this.

So why exactly is this useful? Well I have a couple of uses in mind.

1. Some libraries and UI controls have only been coded to fetch their data with an HTTP request. This gives you a simple way of using such a library or control. You just point it at the local server and handle the request.
2. If you did all data access across the HTTP layer, then you remove one more piece of uncommon code between a web and desktop application, now the difference between the two is just the URL it is pointing at.
3. It allows you to pre-process previously static files. This means you could compile your LESS or CoffeeScript files as they are being served. It also means you could serve HTML from a ViewEngine such as Jade instead of from static files on disk.

Further thoughts on NodeJS desktop applications

I have been working on a more complete demo of creating a desktop app with NodeJS.

This one will use a full UI (KendoUI) and a Sqlite database to create a basic CRUD style app based on the Northwind dataset. Someone really needs to put together another (and actually well designed) standard database that people can use for apps like this.

While putting this together I have been considering reasons why you might actually write an application like this.

Something that dawned on me is that I am only really using Node in a very thin data layer. My Views and View Models are all standard HTML/JS. Which means the only thing I would need to do to switch this application I am writing to being on the web would be to replace the data layer which is currently using Node to access Sqlite with one that goes across the network to a REST service.

This means I am effectively writing an identical web and desktop app at the same time. Which opens up some interesting offline capabilities.

Add a build time dependency injector to switch between the Node and REST data layers, and a synchronisation mechanism (assuming you want the user to be able to use either) and you have the web and desktop versions of your app running the exact same codebase.

Now that is pretty darn interesting.

Creating desktop apps with NodeJS

Last week an interesting thread was started on the NodeJS mailing list.

https://groups.google.com/d/msg/nodejs/iy7Re33dwyU/yxwLlx1aUNMJ

Roger Wang from the Intel Open Source Technology Center posted about a new project from their team called node-webkit.

https://github.com/rogerwang/node-webkit

node-webkit brings WebKit to NodeJS. With it, client side applications
can be written with a HTML/CSS UI on NodeJS platform. We believe the
async I/O framework and Javascript language is a perfect combination for
client (mobile) side applications.

Basically it allows you to write HTML/JS/Node client side applications using webkit as the renderer.

This is very interesting, and in some respects like the path Microsoft are taking with the HTML/JS WinRT in Windows 8.

Currently this is Linux only. But with Node and WebKit both being cross-platform, it is only a matter of time until it gets onto other platforms.

Getting started with a fresh Ubuntu 11.10 install in a VM I had to do the following to get it all installed.

• Open up a text editor and edit the file /etc/apt/sources.list
• Add a new line at the end “deb http://libwebkitnode.s3.amazonaws.com/ oneiric/”
• sudo apt-get update
• sudo apt-get install git-core nodejs-dev libwebkitnode-dev libev-dev
• git clone https://github.com/rogerwang/node-webkit.git
• cd node-webkit
• node-waf configure build

You can then test it is running with “node tests/helloworld.js tests/testfs.html”

If everything goes to plan you, up should pop a window that lists the files in the current directory.

Take a look at the tests/testfs.html to see how they have done that.

Now on to my first test project. I am once again making a twitter search, it really is one of the easiest APIs around to quickly run up a test against.

All the below code is on github at https://github.com/csainty/node-webkit-twitter

One note, I put a copy of the node-webkit into the node_modules folder. I am sure it will come to npm eventually, but for now this was the easiest method.
When I tried to reference it from it’s own folder, it could be found, but then my other dependencies couldn’t. I must be misunderstanding something there.

Our app.js is very simple, this is the entry point to the app, configures the webkit browser surface and loads an initial page.

index.html is also pretty straight forward, it is just basic HTML with Knockout bindings. It includes script references for jQuery, Knockout and our own index.js

Now for index.js, this is where the really interesting code is.

You can freely mix your traditional browser based HTML with your node.

So we call in our dependency on the request module.
We then use jQuery to delay our execution until the page is loaded.
We use Knockout to create our ViewModel which binds itself to the HTML.
Then in the search function on the ViewModel we call out to request to fetch the data from twitter.

Now of cource everything in this little demo can be done client side already. But I wanted to keep it simple, we can get to the filesystem (as the intel demo shows) and we can use existing libraries to get to a database or other persistence layer.

To fire it up just run “node app.js”

I hope to put together a more in-depth demo soon, one that involves local storage, and one of the HTML5 UI frameworks to pretty it up a bit. I’ll keep you posted on how that goes.

Remember I am on twitter these days as well @csainty. So follow me there if you want to know what I am up to.