-2

I've just started playing around with Node.js and Socket.io and I'm planning on building a little multi-player game. Probably something simple like each player has a character that they can run around in an arena and try and kill each other.

However I'm unsure how best to store the data. I can imagine there would be some loose relationships between objects such as a character and its weapon but that I would likely load these into the system by id as and when they are required and save them back out when I no longer need them.

In these terms would it be simpler to write 'objects' out to file instead of getting a database involved. Use a NoSql document database or just stick to good old Sql server?

James
  • 2,609
  • 3
  • 20
  • 27
  • In this scenario, all three options would work. Which one is better depends on a lot of tiny little details which are much too specific to list them all. This question is really opinion-based. – Philipp Mar 26 '14 at 22:27
  • 1
    Too general a question to get great answers here. You should work out the details of your data structures and how/where (client v server) you will intend to use them. Some types of relationships can be modeled and managed trivially in NoSQL databases, in other cases the variety of ways in which the relationships are traversed means SQL will probably be more straightforward. And yes, you could also just treat a flat file (or sort-of-flat, such as a `.json` doc) as a record of sorts, although I would probably be inclined to opt for a NoSQL document DB rather than using the filesystem for it. – barry-johnson Mar 26 '14 at 23:09
  • @Philipp I realize that three options 'could' work as much as I 'could' use a spoon to spread butter but I'm looking for information relating to other peoples experience and the technical restrictions of the technologies in terms of the scenario I've put forward such as read-write performance. Server load etc. – James Mar 27 '14 at 17:26
  • @James Unfortunately we don't know if you are dealing with butter or olive oil, so we can not tell you whether to use a knife or a spoon. – Philipp Mar 27 '14 at 18:15

2 Answers2

2

My advice would be to start with NoSQL.

Flatfile is difficult because you'll want to read and write this data very, very often. One file per player is not a terrible place to start - and might be OK for the very first prototype - but you're going to be writing a huge amount. File systems are not good at this. The one benefit at prototype stage is you can debug quick - just cat out the current state of a user. Using a .json file, or similar .yaml format, will start you on your way very rapidly (and you can convert to the NoSQL approach as the prototype starts coming together).

SQL isn't a terrible approach. If you're familiar with this, you'll end up building a real schema, and creating a variety of tables and joining the user data against them quite a bit. This can be a benefit for helping you think through your game, but I think you'll end up spending a lot of time trying to figure out how to normalize your data and writing joins. Since it seems you're unfamiliar with the problem (thus are asking the question), you're likely to do this wrong (and get in the way of gaming awesomeness) and/or just spend too much time at it.

NoSQL - using a document store model - is much like just reading an writing a user object. You'll end up re-writing your user object every time - but this kind of access (key-value, accessed by the user id) is hyper efficient. You'll probably get into a prototype really, really quickly, and to the important aspect of building out your play mechanism. Key-value access is highly scalable in the long run.

Brian Bulkowski
  • 866
  • 1
  • 7
  • 10
-2

If you want to store Player information, use sql. However if you're having a connection based system. As in something where you only need to store information while the player is connected and after the connection is lost you don't need to "save"; then just store it in Memory.

Otherwise, I would say that you should stick with Sql. Databases are optimized, quick, tried, tested and true. You can't go wrong with a Sql database.

James McDonnell
  • 3,600
  • 1
  • 20
  • 26