Wednesday, January 28, 2009

Creating a (small) MMO is a worthy challenge!

Ya know, it's kind of a cliche in the industry that every noob wants to create his own MMO.

Now, I've been programming games for over 20 years now, and I'm very good at what I do, but I'll tell ya - this is challenging.

Even the very small scope I have set out for this first game can be daunting - for instance, today I am tackling visibility.

In this game, the players can only see things that are within sight range of their units/territory. Pretty standard war game stuff. However, it gets less standard when you're talking about an MMO. With a standard single player, or even non-server based multiplayer war game, you can store the visibility state locally and it's all good.

With an MMO you not only have to handle visibility for all of the arbitrary number of parties that could be involved, you also have to do it asynchronously - so in my case, if a player moves one of his Squads into another players sight area, I have to:

  • Remove the squads old visibility record from anyone who could see him before
  • Check to see who can see him at his new position
  • Send a message to anyone who can't see him anymore so that the client can remove the piece and show the Squad moving off out of sight range.
  • Send a message to the players who CAN see him so the client can add the piece and show it moving in from the fog.
  • Check to see what the Squad can see at its new position and then relay that back to the player that moved the squad in a message as well as adding those new records to the db.
Then, add in that the fact that the player doesn't have perfect information about the things he sees unless they are his or an allies, and then add in that the player shares visibility info with his "Family.."

Now add in scalability -you have to make sure your server cluster is going to be able to handle this for potentially hundreds or thousands of concurrent players. In my case, that might mean firing the visibility check off to a JMS queue that then is consumed by one of the servers in the cluster that has some time, which then fires off a message to the client when it's done.

It's interesting. I'm loving it.

0 comments:

Post a Comment