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!
Statistics: Posted by Derrick — Thu Apr 07, 2011 3:53 am
]]>
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.
Statistics: Posted by Stuck — Wed Apr 06, 2011 9:11 am
]]>
If you do get into this please keep me/us posted.
Statistics: Posted by Derrick — Mon Apr 04, 2011 3:29 am
]]>
]]>
]]>
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?
Statistics: Posted by Stuck — Fri Mar 25, 2011 8:45 am
]]>