1

I've looked all around for someone having a similar problem to me and can't find anything. Basically I am creating a real time multiplayer game with NodeJS, Socket.IO, Express, and Jade.

Everything so far is working great, but this is looking to be a relatively large game, and so I've decided to use OOP concepts for it, but I can't figure out how to tie that in with Socket.IO.

Let's say for example I have my main server file, we'll call this server.js:

var express = require('express');
var app = express();
var server = require('http').createServer(app);
var io = require('socket.io')(server);
var port = process.env.PORT || 4040;

server.listen(port, function() {
    console.log('Server listening on port %d', port);
});

app.set('views', __dirname + '/client');
app.set('view engine', 'jade');
app.engine('jade', require('jade').__express);
//Have a custom routing setup, works fine.
app.get('/', routes.index);

//The /client refers to where the views and css and everything is located
app.use(express.static(__dirname + '/client'));

io.on('connection', function (socket) {
    socket.on ...
}

Now that all works fine, but let's say I introduce a player class, we'll call player.js:

var name = '';

function player (name) {
    this.name = name;
};

player.prototype.getName = function () {
    return this.name;
};

module.exports = player;

Then import that to the server.js class like so:

var player = require('./player.js');

Everything is still working fine to here. I can create new player objects and call their functions.

Where I'm stuck is using Socket.IO outside of the main server.js file.

As far as I can tell, all of my socket.on or socket.emit calls need to be within the io.on('connection') because that's where the socket is created.

The only thing I've seen close to this is using socket.io namespaces, which doesn't really seem to solve my problem because things still have to be in their own io.on('connection').

I've seen socketio-emitter as well, but I certainly will need to listen for socket.on calls and not just emit things.

It seems like there should be a way to use this in a more global scope.

Darren
  • 1,774
  • 4
  • 21
  • 32
  • It generally does not make sense for a player to 'own' a socket, much less one being listened on. (FTP uses connection-per, and look how that ended..) Instead the listening socket should process and dispatch messages to interested handlers. – user2864740 Jul 25 '15 at 00:25
  • I'm not sure if this is what you're looking for, but I think you just need to architect some controller-like logic inside that global connection handler to handle what to do with the socket, depending on what data it contains. Much like a server decides what to do with a normal http request, depending on its URI. Kna mean? – JohnnyFun Jul 25 '15 at 05:04
  • JavaScript is not a real OOP. You could only use something ike TypeScript, which adds real OOP on top and compiles to JS. This is not like a real OOP like C# or Java, but comes really close. And you've the benefits from using a single language, which could result e.g. in sharing models/DTOs between server and client. – Lion Feb 20 '18 at 15:20

1 Answers1

1

So what what I can see, it looks like you need to get the socket out of the connection listener and into the player object.

How you do this depends on your architecture, are the player objects already around when the socket connects? If so you'll need to track down the player the socket is 'for' (probably by appending a playerid or something to the socket request query string as per Send custom data along with handshakeData in socket.io? and then searching for that player in your list of players) and give the player object the socket, so it can communicate with it's frontend player object counterpart.

If the player obejct isn't around yet that's even easier, because you can just construct it there and pass it

Community
  • 1
  • 1
BrightEyed
  • 366
  • 2
  • 10