Subscribe to Six's Game Programming Adventures        RSS Feed

Thoughts on mutliplayer games

Icon Leave Comment
My current side project is an electronic TCG. Ideally this type of game should be a multiplayer game. Making a game multiplayer can be a daunting task. There are a lot of variables that you need to keep in mind when designing a multiplayer game. What protocol will you use for the game. Are you going to go with a client/server, peer to peer or hybrid architecture? What messages need to be sent from the player to the server or to other players? How do you keep the player from cheating?

In my case I decided to design my game to work in a browser. I also decided that I wasn't going to use Flash. I was going to use the HTML5 suite/stack as the front with PHP/MySQL on the back end. With each "sprint" that I had I needed to keep in mind how my decisions would impact multiplayer play. So, what have I already considered and worked around?

Right off it is better to user a secure communication messaging system. To that ended I've create a test certificate in my VM for serving the game over HTTPS instead of HTTP.

Since a TCG wouldn't be any fun if you can't grow your card collection to build better decks you need to have a persistent game world. When the user opens your game their last state will be retrieved form the back end. What were the challenges here? First, I am asking the user for input for their email, password, possibly other items in the future. Verify text input is vital for XSS attacks and potential cheating. So, email field is verified that it is the right format and then is stripped so that it will not be executed if it was ever presented. Granted, the server should never present the email provided or any of the other registration details. It is also recommended to use both client and server verification at this step. One other note is that passwords should never be stored in plain text. Make sure to use a hashing/encryption algorithm for storing passwords.

Logging In
Security needs to be kept in mind here as well. Again, we're asking for user input so it needs to be verified and sanitized to stop malicious intent. Logging in should be done over HTTPS instead of HTTP. That means you'll need a security certificate when your game goes live. When you are checking if the user exists and can log in take the provided email/username and password and count the number of records where they exist.

Decks/Card Collections
This is mostly for cheating as there is no, to very little, text input. The player is browsing their card collection in order to view their cards or create a deck. What you need to be concerned about here is are they only using cards that they actually own and are not trying to inject cards that they do not own into their deck or library. This requires server validation against the back end database. The database also needed to be set up in a way to verify this relationship. I ended up using a many-to-many structure between players and cards. That is a player can have many cards and a card can be owned by many players.

Game Play
I haven't gotten too far into PVP combat, just PVE combat. This will require a lot of the same time of validation. When the game starts you check to make sure that they own all of the cards in their deck. Also when ever they draw a card that it actually comes from their deck and not out of thin air, so to speak. The game also needs to render the cards on the field. To that ended I ended up have two different game states. The first state is everything, all cards and player details. The second is a view state. This view state is all that gets sent back to the player. In some cases I need to get a bit more information such as which card on the field their current play handles. This is done similarly to the game state view. What is also important is that the player never "sees" what the opponent has. If you send the opponent's details to the player then they will "see" what the opponent has and can make their plays based on this information.

The other point I should mention is that no processing is ever done in the browser. Requests are generated and sent to the server. The server does all processing and returns what needs to be drawn to the clients.

There is a lot more that could be written about multiplayer gaming and indeed books have been written on the subject. I'm just relating the few issues that came up for me so far and what I did to resolve these.

0 Comments On This Entry


May 2020

24252627 28 2930

Recent Entries

Recent Comments

Search My Blog

1 user(s) viewing

1 Guests
0 member(s)
0 anonymous member(s)