Indie-Resource.com

Or I think.

I got node setup for login, character selection and pretty decent start for how I want the session data to look. I got three.js going with my "gameboard" and game objects - everything coming from the database. I actually did a refactor as well during this step, since I kind of cheesed through it the first time while I was learning three.js.

So now I'm ready to drop my player into the world, and this is where I think I should have some socket action. Tracking player movement activity, effects on the world objects etc. But in my head, I want the socket activity to run parallel to the http activity. At least as far as my session tracking, and some of the less time sensitive actions I may have in the game. Initially it didn't make sense to fire up a socket to log in and do basic account and character management, and build the world/level with three.js; but rather start it once the character is entering the scene.

Since I don't know much about sockets quite yet, I'm questioning my logic to start a socket at this point, or start over and just use sockets right from the get go. Can http and sockets work together? I'm also going to add in a redis cache (whether or not a really use it), but this seems like the point and layer that I should be firing the socket up. I hope I'm right and I don't flounder around for weeks and weeks, only to find out that I have to start over with everything I've done so far and remove the whole http / session side of things in favor of a pure socket implementation.

HTTP and Socket.io are happy to live side-by-side. However, there are some issues. Sharing sessions was pretty ugly, at least this time last year. I may still have some session sharing code around here somewhere. I had it working decently, but it was tough and required using some undocumented functionality of Connect's session object. This is because once the login is authorized through Connect sessions, it is "in the wrong place" for Socket.io to access it and add it to its own type of session functionality (named socket references).

In the end, I had problems with it and ended up tearing out the entire HTTP system and rebuilding everything in Socket.io. It just made things so much easier after the initial time investment.

So basically it is possible, but I don't know if it would be worth it unless things have really changed. It was a year ago that I was doing this, so that is very possible.

Oh, no... That is what I was afraid of. Unless it will only be a matter of setting up the sessions in socket.io, instead of http/express/redis. Socket.io is like a dark area to me right now, and I don't know how much I'll need to replace. I do some things with jquery and getjson. Is that all void now? Is the many pages of node code hit, or will it be just a matter of how I present the data (res.send vs. ..., res.render vs. ...)? Is a data cache layer using redis out of the question?

Thanks for your reply!

Socket.io, and WebSockets in general, are just the communication mechanism for the game. You will still likely do some things with jQuery, but probably not much AJAX. WebSockets are superior to AJAX. For the most part, just use the pieces as they were intended: HTTP for transporting HTML pages, and WebSockets for communication between server and client. I can't answer about the node code, because I am not sure what you have written or how it is structured. I am just saying I had a problem a year ago having the login be over HTTP on a separate page, and then the user goes to the game page and they are logged in over Socket.io. It became much easier when I merged it all into a SPA over Socket.io.

What exactly where you wanting to cache in Redis?

I recommend you check out express.io (express + socket.io), very useful for real time applications.

If you check out the github they have got some good examples: https://github.com/techpines/express.io ... r/examples

I remember checking out Express.io, but at least at that time it didn't have very good docs. It did have the examples, but that was about it.