Candidates for RPC.

[LiamKarlMitchell]

https://github.com/LiamKarlMitchell/mongoose_rpc http://eureca.io/ https://github.com/c9/smith

[alaa-eddine]

Hi, your project is really interesting :) I'm the author of eureca.io, if you need any help with the library let me know .

I recently added "early" WebRTC support which is best suited for MMO.

[LiamKarlMitchell]

Hi @alaa-eddine thanks for your message,

I did look at eureca recently after being told about it by a friend who was looking to use it over web socket or WebRTC in a browser based remake of an old windows 95/8 game.

Our server has something we made called vmscript which lets us re-execute our code to replace functions in prototypes and what not whenever a file is saved. So I would have to guarantee that it can work with that.

We were looking into RPC solutions because we are splitting the server up to have a child process per Zone (lets say 300) as well as a world server and a login server.

WebRTC is not so useful for this one as its not a browser based client just a server side emulation project. But I will certainly keep it in mind for future projects :). (It could be useful for a web interface however @Ane2 )

I was thinking of contributing to eureca to add a Pipe transport like what smith has. But since smith already had one it lead to me using that since I am short on time.

I have not yet experienced type script. A tad off topic but how are you finding it?

[alaa-eddine]

it was only a proposition :) I'm actually working on a game server project based on eureca.io, and I understand your need :) what do you mean by Pipe transport btw ? is it a specific transport library or something like linux Pipes ?

About Typescript it's really amazing ! especially since MS decided to make Visual Studio available for free, and released a specific add-on to support nodejs with debugging features, npm manager ...etc (never thought I'd say that about a MS product :D ) I'm an early adopter of TS and what's encouraged me is that the generated code remain readable, and TS syntax is very similar to ES6. the downside of this is that you have less contributors to the code because developers usually don't like to change their habits, and are scary to put hand on something they don't know (and made by MS!). for internal projects I only use TS, for community project when I use TS I make sure to provide lot of JS examples to help people adopt it easily.

[LiamKarlMitchell]

Ah I was thinking of pipe like what you do on the terminal with a |. But for the input and output streams.

In Linux and Windows I think you can also create named pipes, but that is different to what I am thinking of here I got muddled up sorry.

A child process has a standard input and a standard output. So you can send the bytes over those streams for two way communication. This was mentioned in the node.js manual for ChildProcess as process.send blocks.

Maybe something like this

var client = new Eureca.Client({ input: child.stdin, output: child.stdout });

smith does it something like this

var child = spawn(process.execPath, [processEnv]);

// Not part of the communication but used to output errors from child.
child.stderr.pipe(process.stderr); // Pipes the childs standard error to the parent processes standard error.

var transport = new Transport([child.stdout, child.stdin]); // Passes output and input streams for the child process
var agent = new Agent(this.api);

And the child process would do something like this

process.stdin.resume(); // Resumes input stream
var transport = new Transport([process.stdin, process.stdout]);

I couldn't see that this was supported in eureca.io but I have not had too thorough of a look. If it were added then there is another use case for eureca :) for when you have child process on same machine, you don't need to open a tcp socket or udp etc for communication if it has inherited the input/output stream handles.

What kind of game server? if you don't mind me asking :)

[alaa-eddine]

aha I understand now, so this is not really RPC, it's more inter-process communication ; maybe a special optimization case to avoid opening a TCP connection while emitter and receptor are on the same machine.... this is not supported by eureca.io, I'll see if it fits well with the actual API and maybe add it in a future version :)

the server I'm developing is a general purpose game server based on eureca.io. the idea is to have a generic server which can have a role : login, router, area server, NPC server ....etc a role is determined by handler dynamically loaded when the server start.

to make it clear, here is a typical configuration .

Login server : implements login service and load local auth handler and Facebook auth handler frontend server/router : implements public service (it receive RPC commands from clients and execute them), this is usually called area server in MMOs. backend server : implements backend service and is bound to a public server (for NPC for example)

with this configuration we can have for example : one login server which authentify users and redirect them to Area server/router depending on some condition (ip localisation, player in-game area ...etc it's up to the developer to decide)

when connected a client can call public functions in the frontend server if he export any, but in general an area server will only take commands and redirect them to the backend server which will handle them and return back result.

backend servers can connect/disconnect from area server, when a backend server connect to an area server, it exported functions become immediately available to the client (browser side). for example a backend server can define a function called : talkToNPC(npcId, message) one launched, the backend server will expose this function to area server which will expose it to all connected clients, connected clients can then call it like a local function throught eureca.io .

if multiple backend servers expose the same function, they all receive the client call.

this make the architecture very flexible since it help you separate concerns if you want by using a backend server for each type of action, or multiple backend servers for the same action to load balance them.

for smaller games, you are not forced to use this complex architecture since a frontend server can handle server calls alone throught custom handlers. and it cal also handle authentication if you give it the role of login server.

all the described above already work, but there are still some dirty code I need to eliminate, and some API decisions to make before releasing it as npm module .

(sorry for the long post :D )

[LiamKarlMitchell]

No worries about long post game dev is interesting. Maybe we should add each other on skype to discuss more game server related things if you like? mine is mb10241

A blog you might find interesting: http://gafferongames.com/networking-for-game-programmers/ http://gafferongames.com/game-physics/networked-physics/

Can visual studio do class diagrams for the TypeScript code? Those were always quite helpful to me when working with C#.

[alaa-eddine]

Sure, I need to check my skype account, didn't used it for several months :D

I never checked if VS generates class diagram for TS, but don't seem to be supported yet (https://github.com/Microsoft/TypeScript/issues/1479)