Hello, I am eying/evaluating facebook platform and I am wondering what does it take to make a full-fledged online flash game for that platform. I am not talking about just a tech demo that you can show to your friends and say "Look I made a facebook game!", but a complete game that would be for example free to play, however it would also include some elements that users could buy. A game that would have system for high scores, saving user data, a system for transactions etc...and all of that networking stuff would have to be implemented in a way to prevent abuse. So could anyone be so kind and give me a quick general overview of what needs to be done to make a complete facebook game in flash, primarily focusing on all those things that are beyond basic flash game development?

So I am going to write my findings in this post and update it when I learn new things.

These are for a single player game, with business model of free to play game with additional items that can be bought.

First the obvious part (I am not asking about these things):

• create content (graphics, animations, sound)
  
• write in actionscript the core game code (aka engine) and part of game logic that will run on client-side in flash.
  

Process of creating these things is what most of the tutorials and books focus on.


Less obvious things (to me - I should also note here that all networking related topics are currently my weak points):

• implement a system for micro-transactions. There are two reasons to use existing services (like MochiCoins, Gamersafe, HeyZap): 1) Implementing this would require me to have a very good understanding of how on-line transaction systems work and to keep track of security issues regarding them. 2) It is more convenient for consumers that already use one of the existing services....
  
• communication with server: from what I am reading "the best" way (fastest communication) is using a socket server? Would using a socket server be an overkill for this kind of project?
  It seems that in order to prevent hacking most of the game logic (or at least the critical part) would need to be run on server side?? That would significantly increase client-server communication. ...
  
• server - hosts the game and runs server side code. Would I need to lease a full machine? Are lesser options relevant? I guess it depends on how client-server communication is implemented... (problem is that almost everything I find on networking is about multi-player games)
  
• update game regularly in order to keep users interested and to patch security holes (a great deal of maintenance). Important because design of the game must be flexible enough.
  
• work with Facebook API (well that one is pretty obvious :)
  

[Edited by - zz2 on February 23, 2010 4:58:09 AM]

I'm currently going through the same process. Here's what I've found so far.

Server wise get yourself a cheap, dedicated server. VPN's are usually oversold, great for basic websites where response time isn't as critical, but if you are going leave your gameplay code on the server you'll need to be able to say I can run X concurrent sessions with a response time of Y. When your server can be thrashed by other users, finding accurate values of X and Y becomes impossible.

When I launch initially I'll be going for a Atom based server with 2 gig of ram goes for 25 bucks a month.

AS wise, an socket server sending binary messages will be a lot faster than a XMLSocketServer (or whatever it was called). Have a look in the network programming forum and read the FAQ. A few things to consider:

* Identify the range of a data field, if player health only goes from 0-100, only transmit 7 bits, not the full 32 bits of an integer (assuming 32 bit platform). Google bit packing <your language> for code samples.

* TCP/IP (no udp support in flash) will automatically resend dropped packets and put them in the right order for you. But if you send a message, greater than the max packet size (MTU from memory, dont quote me :P), additional packets will be sent, but if one gets dropped, the whole set needs to be resent. If you can try really hard to keep all your messages under the MTU, it means more messages can be processed, so more clients running for the same amount of bandwidth. The IP standard requires a MTU of atleast ~70-80 bytes (wiki it). I read it's possible to have a connection with a greater MTU and theres a method to discover the MTU for the connection, but I haven't had any personal experience doing so.

* Microtransactions, never used them, but if you are using a 3rd party provider they should be responsible for security. Chat to each provider about security as they are the ones that can advise you the best.


Hope that helps you.

Thanks! That server sounds like a very good deal for a dedicated server. Prices I was looking all started at 50-60 dollars range.

Is having gameplay code on the server for a single player game needlessly complicating things too much? It would be great if someone could share some more insight on this topic.

I've been pondering the same question. Here's how i see it:

Pro server side:

- Harder to cheat. If the gameplay logic is all on the client all a hacker needs to do to get the high score is send the 'game over this is my score message' to your server.

- Far more work in ripping off your game. AS3 can be decompiled and your asserts extracted from the swf. If the gameplay logic is on the server then they have to recreate the guts of your game.

Con server side:

- Input latency. If -all- input needs to be processed by your server then your entire game is going to feel slugish. You can mitigate it by having more logic on the client side, but that might defeat the purpose of putting the game play logic on the client in the first place.

- less clients per server. If all your server does is host the swf and receive the high score you can have far, far, far more people playing at once.

It comes down to what you are trying to achieve. Both are valid approaches, it comes down to whether increasing amount of processing required by the server and increasing the latency experienced by the client is worth it to achieve a more secure game.

All very good points. So in other words pro server side is mostly related to securing game and associated business model, while on the other hand, game logic being on server side can affect user experience negatively (input lag) and increase costs (because of increased server load and more complex client-server communication logic).

I have been thinking of hybrid approach where portion of game logic (that is sensitive to lag) is run on client side and the other portion on server side (just enough game logic that would prevent at least the easiest hacks). But in order to achieve that, game design would need to be adjusted to allow splitting of game logic like that. For example in a game where player shoots stuff, the important factor would become something like surviving for a given amount of time. Client would need to communicate to server in regular intervals of a few seconds to make sure that the player is really playing for a given amount of time. After that server side would give player points/allow him to advance to the next stage/stream next level...

I know that this is not completely hack-proof, but considering this would be facebook only game it is not so bad. Only facebook users could play the game and because each player would have facebook profile associated with him it would be possible to ban cheaters if they are detected.

Edit: Also in case of micro-transactions, game currency must not be convertible back to real money and trading or free gifts between players need to be limited in order to prevent black market and that in case if someone successfully hacks your game, he only effects his profile and high score list.

Where your core game logic exists depends on what type of a game you are doing. This isn't an issue related to it being a Flash or Facebook project.

If you're doing a game like pool, then it doesn't really matter who "owns" the calculations. If you're doing a strictly multi-player cooperative thing, then you can leave a lot more on the client side. If you're doing multi-player competitive, then you absolutely have to have the server validate the actions your clients want to perform. It is slower yes. The alternative is to have no one play your game because some cheater has a hacked version.

You can help deal with the increased lag by having the client assume that its actions are valid and then correcting if the server later contradicts. For example, if player A wants to shoot his gun, let him assume he still has enough ammo left to do so. He sends his message to the server, and the server responds with a yes or no, but in the meantime, player A's client moves forward as if it were okay.

As for socket servers, there is the commercial EletroServer from ElectroTank and the open-source Red5. The former has a free license wherein you can have 25 concurrent players before needing to pay for a license. Red5 is obviously "free" in the sense that you don't have to cough up cash-- just more time figuring out how to use it.