I've just started trying to use NodeJS and socket.io to create a simple multiplayer online game (similar idea to online chess). I apologise if the answer to my question is really obvious because I have tried googling around, but I think I am missing some key bit of understanding.
Basically, I need to store a few things on the server while the application is running. For example:
I need to store which socket connections are hosts, and which are players.
I need to store the current state of each game (e.g. in the case of chess, where the pieces are and whose turn it is)
It would also be nice to be able to store all the socket.io "rooms".
Feel free to answer the question at this point, information below is for extra reference.
There are a few things that I have tried or seen online:
When I google something with "persistence", I get results based on saving to a database or something, I don't think this is what I want.
I have tried just adding variables at the top of the NodeJS file, like I would with global variables in an ordinary JS file. This seems to work, but just feels wrong to me, if someone could explain how this works it would be great.
I have also seen things called session variables, I think this might be what I want.
I have seen applications that do this by just passing the information back and forward between to client and server, but I would prefer that the client couldn't just edit the information to "hack" to game.
Any help or explanation appreciated.
Nothing wrong with saving to a database. If your server crashes and restarts a few seconds later, you don't really want everyone's data to just be obliterated. I think you're thinking about it in the way that databases are always long-term and slow. But really, there are DB technologies great for this type of thing, and oft used with socket.io.
The one I'd probably opt for is Redis, which is super fast and stores data in-memory. This means that it's not constantly writing to disk, and it's a bit of a halfway house between having full persistent storage like with MySQL, and the slightly dodgy method of just keeping it in Node memory via variables.
When reddit created "Place", that massive multiplayer drawing with a tonne of concurrent users, they used Redis and Cassandra together. You can read a bit about it here.
Related
So, I want to make a leveling/xp system for my discord bot (like mee6 or tatsumaki) but the only way I know how to do this is by using mSQL. Is there a way to do this just using discord.js or is there an eazier way to do this?
I'm sorry for this question being so general but i can't find an answer anywhere, thanks
You could, though using a DB will help more in the future.
Using a Database will probably be the only solution unless you want to write files uselessly or want the levels to be cleared upon restart. From my experience, a database will just work best if you want to store anything like this. Also when using a Database you can use other tables to save more information (Command statistics, etc.) without a problem.
I've been there myself, though once you get over not wanting to use a database and setting one up you'll wonder how you lived without it.
I'm using a point system on my bot. I'm saving it on a JSON file, it's pretty easy to do with node.
You can scan all the users every time you launch the bot for new users and initialize them in your file.
The downside is that you can erase all of the file if you parse it when you boot the bot and you get an error.
I'm considering switching to a DB instead.
I want to save the "state" of my application each time it is changed, and load it each time the application is booted up.
The "state" will be a simple object with a handful of variables in it, the idea is to JSON.stringify it to a file, and JSON.parse it when needed.
From what I understand, this cannot be done using Node's fs, since files on Heroku are not permanent.
I cannot use S3 either, because it's not free (free plan only lasts a year), and this is a hobby project of mine - I am not willing to pay for it.
Another recurring suggestion, is to use some sort of a database, but I think that is a waste of time, since I will only be dealing with one very small file.
Essentially, my question is, how can I achieve something that is closest to this?:
WRITE("filename.txt",JSON.stringify(x));
x=JSON.parse(READ("filename.txt"));
(P.S: I've read somewhere, can't seem to remember where, that Heroku gives free 100MB (Which would be way more than enough). What is that? Does it have anything to do with my code?)
I can think of a few ways to do this for free. They all pretty much boil down to "What free service allows me to read/write arbitrary file content, and access via an API?"…
Do you use or already pay for Dropbox (or something similar?). If so you could you the Dropbox API for Node.js to save/load your application state.
You could use the Github Gist API and just update the same Gist over and over.
Otherwise, you mentioned databases. Sure, a database would be overkill tech-wise, but given your constraints (and the fact that you can get a small db for free on Heroku), and how much overhead implementing one of the aforementioned APIs would be, it might be the best option.
Hope this helps.
I thought I had found the holy grail when I stumbled over PouchDB, a while ago; it allowed me to simply write my code to a local (in-browser) database, and then replicate everything to and from a remote CouchDB without actually having to write a single line of code. (Not entirely true, it is actually a single line of code.)
However, if I use CouchDB as the backend, all users will actually get exactly the same view of the data. That's not all that desirable. I am making an application for different groups of people, and they shouldn't be able to see each others data. Never. Period.
In fact, I'd like to be able to make sure that
Some users only see a subset of the data available
Some users only see a subset of the attributes of the documents
I looked at some CouchDB questions related to this, and having a smart proxy seems to be the way to move forward. But is it really? Are there any implementations of smart proxies like those out there?
Just stumbled across this, the Sync Gateway. That might be exactly what I'm looking for. Would love to hear if there are other solutions though and how to implement one yourself.
I am trying to create a complete session managment in nodejs for logins, chat sessions etc.
I googled a lot and every solution that i got was with some framework/module. I don't want to use any module/framework. I would rather like to build my own solution for this:
So this is the plan:
I will set a session cookie on the client machine (yet to figure out how)
For each cookie, i will be maintaining a unique id in the database instead of files as is the case with php (i am using mongodb)
When a user opens the application, a cookie will be set, a entry will be made in database and corresponding information from the db will be fetched.
I am yet to lay a concrete plan for this. I wanted to know whether doing it this way is a good idea? i read somewhere....'Real men don't use any framework. They make everything on their own' :P
Please correct me if i am on a wrong direction. M just starting with these things....
I'm not aware of any node.js frameworks that are closed-source. Just pick one that seems to do what you want to do, download it, and study the source code to see how the developer implemented it. Then come up with your (perceived) improvement on how they did it. You'll probably find that implementing session management involves a whole bunch of nitpicky details that were never obvious to you.
Ignore all the above advice if this is a school assignment where you're not allowed to look at related code. If that's the case, I pity you because you have an incompetent teacher.
I'm mostly looking for setup advise and pointers on how to go about going about this. I'll explain in as much detail as I can think and also note possible approaches that may be plausible.
The aim of this is to create a real time browser game, the best method that I have found for my needs would to use "long polling" with ajax, which will basically setup a request with the server that will "hang there" til the server has something to send it, then re-establish the connection upon receipt for more data. For my purposes this will handle a chat system aswell as character movement, IE: if a player enters the same area the clients there will recieve a response to inform them and thus update the browser client to show this.
The above is relatively easy to implement and I have already made a test-case for it, however I want to improve on it, on the server side it runs a loop for X amount of time before it'll auto timeout and send back and empty string, so another connection can be made, this is to prevent infinite loops and use up resources in cases where it shouldn't. Instead of looking up the database on each loop cycle (would be expensive I believe) for messages that need sending to the client, I use flatfiles, if a file has a modified timestamp greater than the last message sent to the client, then there is something new to send. However I believe this would also be expensive (not as much as using a mysql database though?) when done a couple of times per second.
My thought process on this was to have a C++ program (for speed) constantly running, and use that for very fast lookups in memory for new messages and so fourth, this would also give me the added bonus of being able to have bots within the game that the server can control for a more real-time feel/approach, however I have no clue if this is even possible and my searches on google have been fruitless.
The approach I would most love to be able to do, is to continue to use PHP to do the rendering and control of the page etc, and have the ajax requests go to the C++ application (that will always be running) that can handle all the real-time aspects.
CGI defeats the purpose of the above approach, as it creates a new instance of the application on each request, which is both slow and exactly what I do not want, I have php for that and don't want to switch one perfectally running language for another that would be better suited, PHP however (to my knowledge) can't store things in memory (ram) and so fourth.
Another approach that I have thought about was to use php sockets to connect into the C++ application, though I have no idea how feasible this may be. The C++ application only basically will need to control bots (AI) and the chat system messages.. I have absolutely no idea how to go about handling bots via PHP.
I hope this fully explains what my intentions and goals are, so if anyone has any pointers or advise then please reply and help me out, it would be very much appreciated. If you need any extra information (for if I didn't cover something or something very well) then I'll be happy to attempt to better explain.
How fast do the reactions need to be? For anything approaching real-time action games, AJAX/Comet is going to be much too slow. The overhead is also really depressing.
The way forward for that kind of thing will probably be WebSocket, with a custom server on the backend. But I don't think that means you need to resort to C[++] for this; the bottleneck is most likely going to be the network and not server processor power.
I'm using a Python SocketServer with a trivial message replication system — all the game logic in my case is on the client-side, with some complicated JavaScript maintaining a consistent game world in the face of lag — but even for a more complex server-side I think a scripting language will probably be just fine.
WebSocket isn't ready yet; there are no mainstream browser implementations. In the meantime I'm using a Flash Socket backup that emulates the WebSocket interface. Flash Sockets have their own problems in that they fail to negotiate proxies, but they are fast and hopefully the need for them will diminish as WebSocket arrives properly.
Reading your post sets alarm bells ringing.
How familiar are you with multi-threaded code? With C++? If the answer is "not very", then I fear you might be biting off a quite a large chunk. Why not take advantage of some existing (tried and tested) COMET server implementations rather than this barebones approach? Whatever application you have in mind, it should be quite separate from the comms implementation.
As someone who has implemented a such a server, I can tell you that it will take many design iterations and a helluva long time to get right. Testing such a product realisticly is also a very tricky process.