A large proportion of the talk was dedicated to selecting the right socket server. This is important because as Ian put it "once you've made your decision you're pretty much stuck with it", aka make sure you choose the correct server for the project. However he did show us a game he's currently developing which he has implemented using two different servers: SmartFox and ElectroServer, essentially as an experiment for comparison. In order to do this he's created a class for all server specific activities, so from what I gather one one 'server class' for each server, decoupling it from the game processing.
He advised not to be a smart ass and create your own server, since these implementations have been tested thoroughly and are optimized for a large number of users, therefore would be less likely to break.
There are four main servers which were mentioned, each have their own pros and con's.
Red 5 is open source, so free/cheap. The downside is that from what I gather there are less tutorials than those for Smart fox and ElectroServer. Its written in Java which seems to be the standard for Flash Socket servers. Its pretty general so can support Streaming Audio/ Video, Remoting etc. This server wasn't spoken about too much, but someone at the meet did mention that it had a feature which the others don't, object remoting : making a flash object and pairing it with a java object on the server side.
Smartfox- The most costly solution out of all the servers mentioned. However it is very well documented and supported as it is a popular solution. Unfortunately it was written by an Italian so some of the English is a bit poor with bad spelling, but funny rather than too much of a hassle. Smart fox comes with its own gui admin tool where you may edit the config files, included rooms, banned word list, max users, you can kick and ban users and keep track of the health of the server. Ian did mention that although this feature is nice, its more of a crutch and not completely necessary. I cant recall is this server allows binary rather than XML to be sent- worth investigating. Disney's club penguin uses this server.
Electroserver- Very similar to Smart fox and seems to work at a similar speed, as in the differences aren't very noticeable. You can extend the classes using java or actionscript 1. Electroserver also uses Strong typing, its better practice and you know what kind of data you will be receiving back from the server. Ian mentioned that although Electroserver and Smart fox are very similar technologies, he is currently preferring Electroserver, simply because its nicer to use, the classes are cleaner and prefers the architecture. This server can use binary rather than XML, so reduces the size of the data being sent to the server- faster.
DarkStar- OpenSource- can support a huge number of users and has been used for live commercial projects which prove this. Again its written in Java with a flash api. Although Ian did not recommend this for anyone who preferred not to extend classes server side. I think perhaps, in contrast to the other servers, you cant modify this server functionality from within
Red 5, Smartfox and Electroserver, you can affect server functionality client side. Ian did not recommend this for a project with a large number of users, since its less efficient and the server would be prone to fall over (smartfox was the server he was using at the time, with PHP for
persistent user data). He gave an example of a game he produced where modifications were only made in flash with no extra server side programming. Although the game works well, when the game received a huge influx of users, (I think he said about 700) the server fell over and needed restarting, and a couple hours later again. Despite this draw back he did emphasis that the game does work well and that the games usual user count are about 70 at a time.
A couple of other useful points...
- -Although clients prefer data capture it does put off users if they have to fill in a form before playing. 'quick play' buttons are very useful and login facilities need to offer the player an incentive such as keeping their game character.
- -Storing game stats and other persistent data can done using another technology in combination with a socket server, for Zwock PHP was used.
Multiplayer games are about creating an illusion-
- -Its good to create a number of 'bot' opponents, this is particularly important during the early days of release. If a player enters a lobby and theres noone else to play, they will exit immediately. Create realistic bots, Ian actually has an algorithm for producing realistic opponent names. Depending on the game, you can swap real players in for bots as more people join the game. This depends on the context of the game as can get quite confusing for players.
- -In addition to the problem of an empty lobby, users don't want to wait a long time to enter a game. Therefore if noone joins after a set amount oftime, Ian recommends sending bots in to fill up the spaces
- -With fluid movement of games characters, you wont be wanting to send every move the player makes. Send a limited number of coordinates per second. Then ease between the coordinates to create an illusion of fluid movement. For example with a car game send the coordinates, direction, speed etc to work out where to move the car, when you receive the next location of the car move to minimize the offset.
- -Fighting/ shoot em ups- this genre (in flash) its important to get the level design correct. Generally these games are quite open plan because of lag and the offset of characters, everyone is literally playing a different game. They think they are playing the same game and its important not to shatter that illusion, player A may fire a bullet, player B ducks behind a wall, to Player B it appears that the bullet missed, but to player A it may have hit. Iain also suggests giving a player feedback straight away, show player A blood splats from player B, even if in the end logic has decided not to take health away from player B. There are complex ways to get around this problem involving calculations of players future positions etc, although iain didn't think this would be necessary for a flash game and was overly complex.
- -Game differences such a conflict between what clients think has actually happened- Iain suggests this can be decided at random, or that the games host's version of the game is always correct.
- -Although users like chat areas it creates legal obligations- pedophiles, child molestation etc etc etc. The Disney virtual world has a huge number or moderators in comparison to developers. One game he produced has a number of preselected messages you can send to players during game play. An interesting feature is that the number of the message is sent to the server and depending on the selected language/country the actual message which appears is translated.
- -Score boards are an invitation to hackers to see their name plastered all over your web page. To get round this for Zwock, Iain made sure that the highest score you could get for a game was limited, therefore to get to the top of the league table to had to play games over and over.
- - Obviously turned based games are obviously a lot easier to implement.
As an example of a game with very good implementation, Iain showed us stick arena . The talk at Brighton Flash was certainly inspirational and very useful regarding the practical implications of producing commercial muliplayers. Personally I can't wait to get stuck in.
I hope this information is useful, I've tried to remember the topics as best I can. But as I mentioned some topics will require some further investigation.