Sign in to follow this  
justkevin

Multiplayer server: What problems might I not be thinking of?

Recommended Posts

I've been plugging away at my multiplayer project for a month plus and would like to solicit opinions on problems that a first timer might miss. Some basic details of the project as it is working so far: Flash clients connect to a Java server. Clients are authenticated and assigned to whatever sector the database thinks they're in (sectors are independent game regions, like zones or realms). If the sector isn't currently running, it starts it up. Each sector is updated by a timer task thread. The in game flow is: Clients submit commands that can arrive at any time, when they do they change the client entity's intent, e.g., accelerate, turn, fire on such and such. The timer task updates the game sector (runs about every 200 ms). The server tells clients about the changes they can see. Repeat. For networking, I'm using JBoss's Netty library. Obviously, there's more details than that, but I'm looking for things like, "When I developed my first multiplayer game I completely forgot about X, which turned out to be very imporant".

Share this post


Link to post
Share on other sites

The main thing is to also have your method for conveying non-entity things, like game/world states, which I suppose could be done inherently by making the world a sort of entity.

I'm striving for making everything driven by entities and their game-logic... so if the server tells a client that player A is shooting, then the client is responsible for drawing player A's shooting animation and also playing the sound that would match his gun, etc.. as opposed to the server telling the client what animation player A should have, and also when/where to play a sound, etc.

But certain things like when someone achieves some sort of goal that alters the world in a non-entity-specific way, you need a system in place for things like that.

Other than that you sound like you are well on your way to having a full multiplayer gaming experience to deliver to the public.

Share this post


Link to post
Share on other sites
Well, the obvious thing lots of people seem to forget about is the challenge of designing a fun multi-player game, and then building the art for it. A boring multi-player game won't have many players...
With a large number of free-trial and low-cost multiplayer games already on the market, it's actually quite hard to compete these days!

Share this post


Link to post
Share on other sites
@radioteeth: Thanks for the encouragement, but I'm still a long way from having a full experience to deliver.

@hplus: Yes, actually crafting the gameplay and content will be a huge undertaking and critical to the game's success.

I was wondering more about technical & logistical elements I might be forgetting, things you might not realize were necessary during development.

Share this post


Link to post
Share on other sites
What kind of game is it? How complex is the simulation/physics? What do you do when more players want to be in a sector/zone than what a single server box can handle?
Make sure you enforce any update/change that affects game outcome/fairness on the server, and don't just trust the client.
Make sure to turn on TCP_NODELAY if you're using TCP :-)

Share this post


Link to post
Share on other sites
It's a tactical space game, each player directly controls a single ship exploring the galaxy. Imagine controlling a ship like the enterprise in 2D space-- players can steer, raise shields, fire on enemies, etc. There are almost no collision detection scenarios-- even if two entities happen to pass the same point at the same time, the player recognizes that one is passing "over" the other.

My tests suggest that this allows for some pretty large differences in the players' world view without creating problems. It shouldn't matter if Player A thinks Player B is at 1500 x 750 where Player B thinks he's at 1600 x 800, so long at they're within a few ticks of the correct position.

And yes, the server models everything.

As for sector limits, I'm not sure of the details, but it will probably be some kind of lampshade where different sectors have different ship limits as a result their warp lanes.

Share this post


Link to post
Share on other sites
So, to figure out what you haven't thought about, go through the checklist of a new player:

1) How does he find out about the game?
2) How does he sign up to play the game?
3) How does he get the game client installed locally?
4) How does he match up to other players or the world server?
5) How does the world server and other players know about his stats?
6) How do players get told about moves of other players?
7) How are rules resolved?
8) How are scores or persistent data saved?
9) How does a player come back for more play later?
10) How does a player with an out-of-date client get updated to the current version?
11) How is persistent data re-inflated when a user comes back?
12) How do you, the operator, know the current "health" of steps 1 through 11?
13) How do you, the developer, gather feedback from and communicate updates to players?

Now, go through this checklist, assuming that 10 players do all of these things at the same time.
Now, go through this checklist, assuming that 10,000 players do all of these things at the same time. (Hey, it could happen!)

If you think you're good, then you're ready. You'll still find problems in production, of course, but at least you have the most important bases covered and can respond as appropriate.

Share this post


Link to post
Share on other sites
Also security would be in order, make sure a player can't make it so he can shoot through walls or through friendly ships. Maybe make a scanning system on the server/client side where it checks for illegal programs. WindProc can do this fairly easily. Also maybe even have a built in virus scanner, I believe you might be able to find a small virus protection company that might be willing to invest in your client if it's good enough that could bring you endorsements.

Also I'm not sure if your planning on it but you should really find someone to do the gfx for the game an not do it yourself so then you can lighten the work load on yourself but then you might have to pay someone something so that would come into another problem how are you going to pay for servers or for some helpers it's hard to find volunteers. Even for Game Moderation most people these days want to get paid.

Happy Holidays :-)

Share this post


Link to post
Share on other sites
@hplus:
That's the sort of thing I was wondering about. For most of those items I have at least a solution in mind, even if not implemented, although I'm not sure I understand #12. Could you clarify what you mean by "operator" and "health"?

@Arc:
There's not going to be much client side security, since this is a Flash game. Anyone with the technical skills can decompile the swf. There will always be the potential for some advantage to using a hacked client in an online game, but I hope the game design minimizes that (server is authoritative on everything and the game doesn't rely heavily on reflexes).

I may outsource some of the art, for now I'm recycling art from my last game.

Share this post


Link to post
Share on other sites
The operator is the guy with a pager. The guy who takes back-ups, re-boots wedged processes, etc. The "health" is the ability of your server(s) to play the role they're supposed to for all the players you have.

For example, if a matchmaker process wedges, how long does it take before the operator gets a page, so he can kick it? It shouldn't wedge often enough that you'd need an automatic kick, because such "solutions" generally end up being worse than the problem they're trying to solve...

Share this post


Link to post
Share on other sites


Parts not covered:

Handling player shutting down/termination of playing

Handling a broken connection - how to decide its happened and to clean up connection.

Handling slow downs (especially if its an internet game) playing catch up on required info and discarding out of date info (not sending if a later update overides it)

Sync'ing server while the game is up to be able to recover when the server burps
(preferably continuously by aslo at frequent syncs that can be rolled back to when the server recovers)

Others:

handling multiple access using same account (part of security)

handling DOS attacks (general server network functionality)

The usual server side verification of commands issued.

Compression of network streams (ie- delta compresions, LOD frequency methods etc..)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this