Hello!

I was looking around here for a while and couldn't get any answer that really covered it with explanation

So a little background, I am working on a room based FPS kind of game.

I need to find a way to manage the data:

Users - Details on the account

Characters - every user may have more than one

Inventory - For each character

(?)Store - Items and prices

(BTW : would you recommend store it in DB or hard code it in the game and update by patch? I will have to send a patch anyway for most of the new Items so they can work)

After some thought I decided as a security measure to not connect to the database directly from the client, but create a costume server that will handle requests and replays by socket connection.

No I am trying to wrap my head around the server logic, what will be the best way...

Should I use a MySQL server to handle everything? Isn't that a little unnecessary?

I could use a file to hold the data and poll it from there?

Or if I stay with MySQL, I could make the server app read all the data from the database and keep it on start up, since Store and things wont change after server start up

and then when user request something I don't need any database access, and when I need to update, I update locally on the server app and have a separated thread update the SQL database every minute, so if I crash I wont lose that much data

So these are my thoughts, what do you think?

If the trade is entirely single-user, then you can build it all into the client.

If the inventory matters, such that you support trade between players/characters, then you need to put it on a server.

And, yes, you never want the user to talk directly to a database; enforcing business rules and authorization is what an app server is for.

So, the easiest way to spin this up is to use some kind of existing web services framework. You then use HTTP (ideally HTTPS) to talk to that "web application."

Interesting web services frameworks include:

- Node.js with

- Ruby with rails

- PHP with recess

- Erlang with webmachine

- etc

These kinds of frameworks can often be backed with a variety of databases -- MySQL, PostgreSQL, Redis, Cassandra, ...

And, no, using an existing, robust database is not "overkill" -- it's a proven pattern that solves a bunch of problems you don't want to solve yourself, like atomicity, consistency, isolation and durability (with different trade-offs for each of the databases.)

And I would do trade/inventory as database transactions. They're not that frequent (how often does a single player trade?) and consistency is more important than millisecond response time for things that affect the economy.

If you have millions of active users, you will have to learn how to scale up such a system, but that has been done before, so don't worry about that now.

Another option would be to go with a platform-as-a-service system like Google App Engine. That can work, too, as long as you're OK with the vendor lock-in that comes with that.

Thank you for the fast replay!

Ok so you are right, normal database it is then

2 questions that I still cant understand

would it be better to access a PHP website that will update the data or an app server that will do the database things?

and if an app server, will it be a good idea to load a few things in advance? like shop items or map list? or would it be smarter just to poll them out of the database each call?

would it be better to access a PHP website that will update the data or an app server that will do the database things?

Web servers running PHP are one kind of application servers. They happen to not provide server-local persistent state, but that's actually a feature, in the sense that if you build an application that requires server-local persistent state, you run into a hard scalability problem when a single app server isn't enough.

I can't reasonably suggest which way to go unless I understand more what your goals are on hosting environment, costs, and scalability needs.

Ok so ill try to specify my game

Its a fps built in unity3d, i use photon cloud to mange the rooms and the game logic
I only need to acess the database to store users, characters, and shop items

About the server budget, we are not worried about that now, we will invest as needed to grow, but thats way i am looking for a way that will be fast and efficent

The reason to use a database is to support "correct" trading and economy, such that users trying to bring servers down won't cause item duplication bugs etc. (This has plagued several MMOs in the past that did trade in-RAM only.)

It's reasonably easy/simple to build a trade system that is transactionally consistent as long as the database lives on a single database server. MySQL, Redis, and all the rest generally support this.

Once you need to scale past what a single database server can support, the approach you need to take changes, and you may need to re-structure your data storage and trade implementation.

For a game that hasn't even shipped yet, sticking with a single database is fine.

Also, if you define one database per world "shard" and one separate database that only contains user/billing information, that will probably also let you scale for a long time, with the limitation that you don't support trade between different shards.

Thank you so much for your replays! I think I got the point and what I need for my game :)

You helped a lot!

Hi!

I hope its ok to post another question here and not in a new post

Do you have an idea on how to keep track on which user is logged in already? (to prevent 2 people to connect with the same account at the same time)

My server is pretty much done other than that...

Pleas use a new thread for a new question.