So I decided to wait

Until webgl was more advanced, and I’m glad I did. The new Google Chrome Beta and Firefox Beta 7 are both amazingly good for webgl, and they now both support arraybuffers over xhr. Thanks to Alan Chaney for help with this.

function getDisplayable(disp) {
    disp.xhr.onreadystatechange = function() {
	if (disp.xhr.readyState == 4 && disp.xhr.status == 200
	    && disp.ready!=true) {
	    if (disp.xhr.responseType=="arraybuffer")
        else if (disp.xhr.mozResponseArrayBuffer != null)
        else if (disp.xhr.responseText != null ) {
	        var data = new String(disp.xhr.responseText);
		    var ary = new Array(data.length);
		    for (var i = 0; i <data.length; i++) 
                {ary[i] = data.charCodeAt(i) & 0xff;}
		    var uint8ay = new Uint8Array(ary); = uint8ay.buffer;
	}}"GET", disp.url, true);
        {disp.xhr.overrideMimeType('text/plain; charset=x-user-defined');}
Posted in Uncategorized | Tagged , , , , , , | 4 Comments


So, not many updates here- however, I’ve made progress in several fields.

First of all, I’ve finished the procedural dungeon generation, and if I can just get some clarity in how to do the webgl datastream (e.g, how to get javascript typed ArrayBuffers from an XHR request) I will be able to finish the client as well.

Next, a guide which is sorely needed on the web: How to get a jar of RubyInline: (You need the latest version of jruby-complete)

This, of course, is for java_inline

java -jar jruby-complete-1.5.2.jar -S gem install -i ./RubyInline RubyInline –no-rdoc –no-ri

jar cf RubyInline.jar -C RubyInline .

You can then run it via

java -jar jruby-complete-1.5.2.jar -rRubyInline.jar <filename>

Posted in Uncategorized | Tagged , , , , , | Leave a comment

Graphical MMO, in 282 lines

Boy, it’s always to see something work first time you write it.  As you can see from the screenshot, I now have canvas working, and with the last refactoring, adding it turned out to be just as easy as I imagined, and no changes in the server were needed to make this work. You can also toggle between ascii and graphical mode, in case your client does not support canvas.  I’ve also added a webgl button- for now it does nothing.

The tiles are, as I’ve mentioned, by David Gervais.

Posted in Uncategorized | Tagged , , , | Leave a comment

An MMO, in 261 lines

Calumny is now a working MMO, in the sense that this is the first version of Calumny which does not have server state. All the information which is used in a thread is derived from the cookie and what voldemort says about the character that that cookie links to, and as such this version could easily be loadbalanced without any kind of hideous source hashing.

I also have put the final touches to the client-server communications protocol, and while there are still changes to be made (such as run-length encoding and diffs, and probably sending motions instead of keyboard characters), but I am going to put those off until much later.

This communications protocol is now display-independent, and it will be trivial to add the canvas display option. This also means that I can now begin work on the client and server individually.

Future features for the client are

  • Canvas display option, using the Gervais tiles
  • Webgl display option
  • Nicer CSS
  • Options panel
  • Character information, including equipment (needs server modification)
  • Event animations, via canvas or gifs.

Future features for the server are

  • Rules
  • Monsters
  • NPCs
  • Procedural Terrain
Posted in Uncategorized | Tagged , , , , , | Leave a comment

Almost an MMO, in 163 lines

This version stores the terrain data in JSON blobs in Voldemort, and with each motion the @ gets inserted and removed in the main terrain database.

To run this version, you need gson, all java libraries that come with voldemort 0.81 (in lib/ and dist/), and jruby. Go here and run the single node cluster.

That, of course, means that voldemort is finally integrated. Boy, it’s been grueling- I’d originally intended to post the next version last sunday. First of all, it turns out that python isn’t really a good language for this.

  • Did not run out of the box due to missing _has_error with the latest pbuffer version.
  • Showed corruption using latest pbuffer when doing lots of gets and storing pickled python objects
  • Did not have UpdateAction from java
  • My OS X python was old, and did not have JSON libraries

So I switched to jruby. Problem is, rails is such a big thing in the ruby world that it colors all other ruby activities, for example web serving. It’s assumed that you want a jruby web server for rails and rails alone. Of course, I can’t use rails for this, because rails demands a database model, and I am using voldemort.

What I finally picked, was jetty. It only added some 20-30 lines to my project, a bit more than cPythons cherrypy, but that is outweighed here by much less voldemort infrastructure.

I wavered back and forth on this, but eventually I decided that my storage strategy is going to be the following: If there’s empty space somewhere, that means that the tile is filled. Rock is emptiness. That means that the edges of your map are always shown as infinite rock. Each tile has a key and a value, and the value is a list of things in that place. A place you can go is not empty.

Because of this storage philosophy, I need to get a value for each tile visible per display. So far, getAll seems slow already for 400-800 gets. I’m not sure how much of that is from jruby and how much is from voldemort, but I may need to either use java_inline (as seen here) or, if it’s voldemort that’s the problem, try to lump the terrain up, in 4x4s or 16x16s. Something like that. Of course, I will not be doing that optimization until I have the NPCs ready, since it’s just fast enough for one player. (On a i5/X25-M)

Missing features that a real MMO has:

  • NPCs and Monsters
  • Rules and Combat, watch for my post on this.
  • An Avatar agent that continues running after disconnection. This is probably next, since I’ll have to launch a specific server thread for everything else on this list.
  • Large terrain (I’ll have to do something semi-procedural eventually)
  • Graphics (I will begin with the David Gervais tiles)
Posted in Uncategorized | Tagged , , , , , | Leave a comment

Servers and distributed data consistency

Obviously most modern MMOs are sharded. This means that they only allow a couple of thousands of players at one time. Well, let me take this opportunity, as an internet tough guy, and while no-one is listening, to call the developers of those MMOs wimps. If your MMO can’t take a couple of million players in the same self-contained non-instanced world, maybe you should be programming in a dress. (this expression stolen from Jeff Vogel, from back when he was still into lead pipes and not childcare, sigh)

I wouldn’t be saying the above if I didn’t think I had a better idea.

There are two issues that need to be solved. First, distributed data consistency, and second, high density areas.

The distributed data consistency will be solved via Project Voldemort, (hence the name of the MMO project). Project Voldemort (found here), is a distributed key-value store, which scales (or so I’m told) completely horizontally, meaning I only have to add more servers to get more performance. Write consistency is solved by vector clocks, explained here and here. Read those two links? No? Well, go back and do so. Now, isn’t that awesome? Well, I think it is.

High density areas will still trip you up, however, because they will cause high IO with the same keys, and that’s why we need collision detection- nature’s way of preventing high-density areas. Now, in a roguelike, with a discretized ground, this is easy.

Posted in Uncategorized | Tagged , | Leave a comment

100-Line Roguelike Client Mockup

Version 1

All this does is read keystrokes and report them to an integrated server mockup via an XHR, and the response is just put into the page via innerHTML. To run, you will need python-cherrypy3 and numpy, and the “dun” file, from the same repository.

It’s been tested it in firefox, and chrome, and safari, and of course, as any web developer might have told me, I ran into compability issues with keystrokes. Well, I manfully hacked around them (for now), but as I’m currently not even getting my XHR in a Microsoft-compatible way, I think my next client version will use some type of javascript library (which will not count towards the 1000 lines, obviously),

Currently I’m planning using the “dojo” javascript library, which seems to have retrofitted one browsers’s version of keystroke handling into all the others.

This will imply some reading of APIs, obviously, but man was meant to suffer, as the sparks fly upward.

Posted in Uncategorized | Tagged , , , | Leave a comment