JoinUO Forums

I've been considering trying to port some of the UODemo code to javascript. Sounds insane: why javascript? Because has a fairly thorough among other things and it runs on google's v8 javascript engine so there's crazy black magic happening to ensure the JS executes extremely fast. I've been using node.js for its capabilities as an http server(s) for the past month or two, which is what got me thinking about its potential for making a UO server.

It's single-threaded, but all the IO is asynchronous, so the end result doesn't appear to be single-threaded. It seems like it's a very basic and understandable platform (at least for me). I'm certainly not a veteran programmer, but I'm learning more and more about TCP every day and I understand enough C (or any basic procedural language) to start porting some of the UO-C scripts. (it might even be possible to create some kind of parser to preprocess or compile the uoc scripts into javascript.)

What do you guys think? Would this be reasonable? If the demo code was ported to a more malleable platform, maybe it could be put to work in the real world. The best part about this is, if it were ported to node.js, the code would have the potential to easily be converted to interface with a web socket API which leaves open the possibility of running UO in a web browser, completely native to any modern browser, no installation, no flash, no plugins required. This would utilize WebGL and the html5 canvas element on the frontend.

Realistic or no?

Node look pretty interesting.

It seems to me like this is could be a good platform for a UO server, it's really preferable that it's a single threaded.

As far as porting the scripts though, it's worth noting that the bulk of the Server code is not in the scripts. You'd need a pretty robust API in order to handle these scripts even once you get them to pure javascript.

Sounds doable and exciting. Although It'd be pretty much a from scratch project, for the Server/js-API, and for the web client.

Node certainly looks like it could handle the connections very elegantly.

I read a lot about node after this post. I really think this could be a cool project. I can completely relate to "work on obsessively", usually without any care to the end benefit at all, but always with high hopes

If you do get into this please keep me/us posted.

So I started up a simple TCP server and tried to login with the UO client just to see what the login packet looks like.

Things sort of took off from there. I've been spending the few hours studying up on UO packets from this very good reference I found (http://docs.polserver.com/packets/), and writing the appropriate functions for them. That might be the most tedious part: Javascript doesn't have the variety of data types a lower level language does. i.e. It has one number type: Number. To work around this Ryan Dahl, creator of Node, implemented an object called a Buffer, which is essentially a byte array whose existence is unknown to v8, so v8's (sometimes overly-aggressive) garbage collector can't be mean to it, and then it also offers a way of dealing with binary data. So I've spent a little while writing helper functions to easily create and analyze packets in the context of Buffer objects. It's a bit of work, but I hope to at least get a character logged in and walking around soon.

The small .js file I originally started writing for this is growing very fast. I imagine I'm even going to have to write my own kind of framework for a project of this magnitude.

Another thing I'm considering is what kind of data store to use if something does come of this project. Since all data on a UO server must be readily available at practically any given time, in-memory seems to be the only sensible option. So I might just write something simple specifically for this project. Something which stores everything in memory, and writes JSON data to flat-files during world-saves, and then reads it in chunks and parses it when the server boots up. I'm not sure though, how much data does a typical UO shard have in-memory during runtime, given all the items/mobiles?

Anyway, I'm pretty obsessed with this now. I'll let all you guys know how it goes if you're still interested.

The memory requirements can get pretty big; but definitely having everything in memory as you suggest is going to be pretty necessary. However it's likely very beneficial to have an object structure much like what OSI did, where the contents of an object are only known to that object, making it portable.

This would allow you to offload a lot of stuff to disk when it's logged out; and also opens up the possibility of having node.js same box subservers, or multi box. As Ryan put it regarding the single threaded architecture of node.js, you don't need threads to take advantage of multi-cores, etc, just more processes.

Please let me know if node.UO needs it's own forum

Really glad to hear you started on this!