I'm considering developing a real-time multi-user game, and I want to gather some information about possibilities before I do some real development. I've thought about how best to ask the question, and for simplicity, the best way that occurred to me was to make an analogy to the field (or playground) game darebase.
In the field game of darebase, there are two or more bases. To start, there is one team on each base. The game is a fancy game of tag. When two people meet out in the field, the person who left his base most recently timewise captures the other person. They then return to that person's base.
Play continues until everyone is part of the same team.
So, analogizing this to an online computer game, let's suppose there are an indefinite number of bases. When a person starts up the game, he has a team that is located at, for example, his current GPS coordinates. It could be a virtual world, but for sake of argument, let's suppose the virtual world corresponds to the player's actual GPS coordinates.
The game software then consults the database to see where the closest other base is that is online, and the two teams play their game of virtual tag. Note that the user of the other base could have a different base than the one run by the current user as the closest base to him, in which case, he would be in two simultaneous battles, one with each base.
When they go offline, the state of their players is saved on a server somewhere. Game logic calls for the players to have some automaton-logic of some sort, so they can fend for themselves in a limited way using basic rules, until their user goes online again. The user doesn't control the players' movements directly, but issues general directives that influence the players' movement logic.
I think this analogy is good enough to frame my question.
I've been looking at smartfoxserver, but I'm not convinced yet that it is the best option or even that it will work at all.
One possibility, of course, would be to roll out my own web server, but I'd rather not do that if there is an existing service out there already that I could tap into.
Note that darebase is not the game I intend to implement, but, upon reflection, that might not be a bad idea either.
What I'm looking for, specifically, is an appropriate architecture that can do the following things:
-
Act as a repository of saved game states
-
Provide a framework that allows multiple players to communicate with each other.
-
(optionally) executing some of the gaming logic, for example, in the
game of darebase, who determines who tagged whom? Is it one or both
clients or is it the server?
I've never been involved with such a multi user real-time environment, so I can only guess at the pitfalls of one decision vs. another.
Best Answer
Overall, your question is probably too broad to be answered in any depth, but I will try to give you some pointers in the right direction.
There are a number of good reasons why you will need to have your own server (web or otherwise):
Firstly, any game of moderate complexity will be unique enough that you won't find an existing service to simply hook into to run your game logic. I'm not really even aware of any services which attempt to provide things like that (other than basic services, such as data or game resource storage, etc - you typically still need to write and host your own code).
Second, as with any networked application, you cannot really trust the client side (you simply cannot be sure that the client code hasn't been tampered with - period). The typical solution is to run most of the game logic on the server side (or to at least validate whether what the clients are telling you is correct or not). If you don't do this, sooner or later, someone is going to modify the client side to keep reporting victories, and ruin the game experience for others.
Here, we need to keep the above point in mind, but also the practicalities. A lot will depend on how you would like the game to play out. Is it a game of skill, where players have some kind of mini-game to play, or is it simply random? The difference is in the amount of communication happening between the client(s) and the server. In the latter case, I'd definitely have the server do all the calculations, and simply serve up the result to the clients. In the former case, it's far more complicated, since you'd want to have the game as responsive as possible for the players, while still being validated on the server-side. Implementing something like that can be very difficult, so for your first game, I'd pick the simpler option - base the game around things that you can easily code, such as simple random number "rolls", which can then be translated into actions on the client like "you lunge at your opponent, but she dodges!", or something along those lines.
These are the basic realities of the situation. You will almost certainly need your own server, where the majority of the game data and logic will live. Regarding your fears that you are reinventing the wheel, don't worry too much - as long as you don't try to write the web server from scratch (as Jimmy Hoffa pointed out), you're fine. In fact, judging from the confusion in the comments, I think most people took that for granted; I was just trying to convince you.
EDIT: If you would like to read more about actual architectures, here's an article which outlines IBM's PowerUp MMO game (it's in Java, but the overreaching concepts stay the same). It should be noted that this example caters for heavy communication between many clients and servers; you may be able to design your game to be far simpler, with only occasional communication (e.g. once per "battle").