next »

[TheHermit]

I'm nearing release of my first game and I've been trying to think of things now that will make it nicer for me to handle the post-release life cycle of the game. One thing I'm not really sure of is how to best design the game to be easy to patch and update.

First of all, there's one big limitation - this is a Node-Webkit based HTML5 game, so people who buy the game will receive a .nw package, the Node-Webkit executable, and under Windows some installer framework that will dump them in a directory and create a desktop icon that automates running the thing. Because this is HTML5-based, I can't really have something in the program itself that downloads and self-updates transparently; Javascript doesn't have those sorts of permissions with the user's filesystem. Thats my own little dilemma, but I think the general question is interesting too:

In general, what are the best-practices involved in making sure that your software can be easily updated by its users? What are the things to watch out for or plan ahead for before the initial release?

[xptnd]

If your game is small, then don't bother with architecture. Just nuke and replace everything, except the save data. You could create a launcher which downloads and cleans the game folder on update, or just link to a new download.

There's nothing stopping a js application from accessing the filesystem. That's an arbitrary restriction placed on web browsers.

[TheHermit]

The content package will only be about 15-20mb, so nuking the whole thing every time is probably the thing to do. I wasn't aware you could modify the local system in Node-Webkit, so thanks for that info!

Probably the best thing to do would be to have the game check for updates on the server and have a button that does an XMLRequest to get the new package file and backup/replace the old one. I've read a lot of user complaints for (much bigger) games on e.g. Desura which take a few days longer to get patches than the Steam versions, so I think having the in-game option to update is important.

[nikki]

node filesystem : http://nodejs.org/api/fs.html

[eaz]

I made something like this before using node-webkit.

Have a json file on your server with the latest build number and have a zip of the current build on their too. On launch, node-webkit requests that json file (without caching) and compares it to the local build number. If the build is newer, use a http request to download the zip. Then extract the contents using node fs and node zlib. (Make sure zlib is set to overwrite)

I have the code somewhere at home. I can dig it up later and share it with you.

[Evan Balster]

A PSA I say whenever the auto-updater topic comes up:

It can be really dangerous to make your own autoupdater since you're downloading code to the user's machine.  Homebrew autoupdater systems are one of the most frequent targets for malware distributors as a successfully hacked one will broadcast whatever the attacker gives it to a large number of people.  Unless you have a few years' worth of experience in crypto and security it's a bad idea to approach this kind of liability.

However, in this particular case it sounds like the game's code is aggressively sandboxed and wouldn't have the capacity to do harm to the user's machine in excess of what a malicious website could do through the browser.  Just don't update any executables/java and you might be in the clear.

[eaz]

Homebrew autoupdater systems are one of the most frequent targets for malware distributors...

However, in this particular case it sounds like the game's code is aggressively sandboxed and wouldn't have the capacity to do harm to the user's machine...

This is true. Node-webkit is sandboxed and won't allow node fs to access anything outside of its own directory (the contents of the project in the .exe or .app) or the temporary directory that Windows allocates for the application.

[TheHermit]

Is there actually a reason to extract the .zip? Node-Webkit packages are basically zip files already.

Actually, if Node-Webkit is sandboxed like that, I probably can't actually update the .nw file from within the program, can I? The program itself will just see the contents of the package, so I guess I would have to unzip.

Anyhow, I'd appreciate the code.

On the subject of security, I've been using JSONP for some stuff in the program - basically because the demo version will be something you can just play in your browser, which I wanted to distribute as widely as possible (so cross-origin stuff will be a problem). I figured even if my server gets hacked its no worse than someone putting that same javascript code up on the homepage of the site.

But with using Node-Webkit, does the JSONP stuff become more dangerous because of the possibility of filesystem access and other such things?

[eaz]

Is there actually a reason to extract the .zip? Node-Webkit packages are basically zip files already.

The zip would contain the game code. As far as I know, I can't run any javascript, html, or css files from inside a zip.

Extracting the zip would put the files in the AppData/(node-webkit project name)/ folder assigned to the node-webkit application. Then after that the game would then use the files. I'm almost certain that the files in the AppData folder take precedence over files of the same name in the .nw file.

[TheHermit]

So my original thought was just to use process.pwd() to get the working directory and actually have the game download and overwrite its own .nw file. But it sounds like you can't do that because of the sand-boxed environment.

If the AppData thing works though, it'd also give me a way to let people make and install mods to the game without having to unzip the .nw themselves - basically let them submit a zip file to the game and have the game clear out AppData except for its stored zip files and unpack, in order, all of the enabled zip files.

[eaz]

Caveat: This code is educational and not intended to be fully functional.

Download Link
To run: Download zip above. Extract zip. Drag folder "updater_template" onto "nw.exe"
The magic:

• [updater_template/js/main.js:lines 219-223] This will display the "update available"  bar if an update is available.
• [updater_template/js/update.js] This contains all of the update functionality.
• [updater_template/js/update.js:line 36] Loads local file "update.json"
• [updater_template/js/update.js:line 37] Uses the loaded "update.json" to find the url of the server json file. The local json file claims the url is "http://www.eazimmerman.com/tss/current.json", however that file does not exist.
• [updater_template/js/update.js:lines 39,41-47] Loads local file "current.json" and compares to server version.
• [updater_template/js/update.js:line 88] This line contains the url for the download. (Currently set to "http://nodejs.org/dist/node-v0.2.6.tar.gz")

Notes:

• The gif doesn't illustrate how beautiful my background shader truly is
• I included "D3DX9_43.dll" because it is necessary for node-webkit to properly run webgl_fragment_framework.js
• The application will not detect a new version because I am not hosting the necessary files. To force the update bar to appear just place [updater_template/js/main.js:line 220] in the scope of window.onload()
• Click the bug on the bottom left to open the node-webkit debugger

[TheHermit]

Awesome, thanks!

[woodenrabbit]

This is fantastic! Thanks for putting this together.