Flash Voip Api's

I've been investigating some of the voip API's available for Flash and Flex projects. The possibility to create applications which engage and interact with the user on an audio level is exciting. Ribbits Killer App challenge should certainly provide some cutting edge inspiration.

After dabbling with Ribbits API briefly, I felt disappointed. Firstly its seems you cannot send text messages from the UK (its a US company), although this problem may be limited to applications in development; it may work live. I also felt that the amount of control provided by the API was lacking, in reality it does everything one could expect from a voip api: voicemail; messaging; call bridging; inbound and outbound calls; transcription; conference calls and so on. But for all the hype I want more control over data; how about giving the developer the ability to store the audio data on our own servers.

Obviously the ability to store audio in house is appealing since calls to Ribbits service cost money; a one time cost of a call with multiple accesses to an in house server is cheaper giving companies full access to data and seems like a more commercially viable solution.

A feature which i'd like to see implemented is audio search, this would be a great feature for rich app's which require phone in's and audio interaction: an audio search could pull out related calls. Although Ribbit does not provide this, perhaps one could achieve this by utilising their transcription service. Store a call id along with its transcription (audio to text), simply search the text and pull out related calls. This could also work for a negative filtering process, aka remove calls with swearing or inappropriate language,

Ribbit has an 'ideas' wall for suggested implementations of their services and reading it is a good way to get creative juices flowing. I am especially interested in implementations which can converge medias and input, platforms and provide for the 'whereevers/ whenevers'.

One point to note is Ribbit is based in America, I don't know much about telecommunications, but i get the impression the call would be routed via a server based in the US. This would be one explanation as to why the quality of the call is so poor, unfortunately I'm not sure whether using Ribbit is commercially viable because of quality issues. However my tests were conducted making calls between computers which were close to one another, other people may not experience the same issues. But its definitely a point to investigate. Also note that Ribbit does allow you to set the service up with your own telecommunications provider, which could be useful in improving quality/ service.

As far as other voip solutions go, another US company TringMe offers a very similar service, although the documentation is pretty poor for this api, but they do provide convenient little widgets :). One to watch is Adobes Pacifica which is said to be very high quality. I believe its still under development, though nothing seems to have been announced in a while. More info here.

Socket Servers and bulding multiplayer games in Flash

The speech last night at Brighton Flash was quite interesting. It was fairly informal but down to earth and Iain was speaking about realistic implementations of multiplayer flash games in a commercial setting. I was slightly disappointed he didn't mention any of his 3d work for the bbc, but then this wasn't particularly relevant to the topic of the speech, since Meta4orce is single player.

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
• -Smart fox
• -Electroserver
• -project Darkstar (queue starwars-esque music, dun dun dun dun....)

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
flash.

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.