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.

  • How much experience do you have writing code? I'm not familiar with any frameworks or libraries for something of this nature, but I have an inkling that you might have a different definition of what you're looking for than I do.. Other than "smartfoxserver" what architectural approaches have you considered? Nov 16, 2012 at 3:15
  • I've been a database programmer since 1990 and some graphics programming before that. I've been learning IOS programming since March. I haven't considered other architectural approaches other than running my own web server, but I figure this is a wheel that probably shouldn't need reinventing. I'm going into unfamiliar territory, and I don't actually know what the options are. That's what I'm looking for - options. Nov 16, 2012 at 4:35
  • 1
    The way you wrote "roll out my own web server" made me think you were talking about writing your own web server from scratch which sounded insane and gave me the impression you might be in a little over your head, I realize now that's not the case. Unfortunately I wouldn't think there is a framework for what you're talking about doing; it sounds pretty specific and usually you'll only find frameworks for general things. I'd start by digging up some iOS GPS frameworks and networking frameworks, possibly a library exists that reports GPS locations to a server, then go from there. Nov 16, 2012 at 4:42
  • Yikes, no. I just meant running my own server rather than using a service. Sorry for the confusion. I've got the GPS covered. That's just core location. What I'm really exploring is data storage and client communications handling. I can see this working mostly client to client, but I can also see a server doing most of the work. I think I'd prefer the former with a server used only for handshaking and storage. Nov 16, 2012 at 15:37
  • @Lorenzo, you may be right. Is there a way to remove a tag? I probably placed the tag there when it was iOS-specific. If I develop the game, it will be for iOS devices. You're probably right, though, that the question as it's stated now is not specific to iOS. Nov 29, 2012 at 1:27

2 Answers 2


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.

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?

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").

  • Thanks. Very helpful, and I will be reading through the article you linked. It looks like it will also inspire other reading, which is just what I was looking for. Nov 17, 2012 at 14:42

Your requirements dont specifically preclude any of the more common server side languages. But you might consider something like node.js, which is particularly good at handling the kind of 'real time' communication you want between clients.

You will probably want a central server. I know you said you were looking at client to client communication. But that can be problematic due to firewalls/routers. There are certainly ways around that (ie, like skype does), but it probably wouldnt be worth the hassle for you.

  • Thanks. I had not heard of node.js but after a brief read it looks interesting. Nov 17, 2012 at 8:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.