Electrotank at E3

Just a quick announcement before I go catch my plane. Electrotank is at E3 this year (we were at GDC too). Come see us at our booth in the South Hall!

Running ElectroServer on EC2

If you are interested in running ElectroServer on Amazon's EC2, we have made our scripts for starting instances available on GitHub. Check them out here.

Documentation is still a bit light, but if you are familiar with EC2, it should be enough to get you started. We have put it on GitHub to make it easy to fork them and make modifications to suit your environment. (And contribute useful changes back to the master copy, of course!)

Get Through Firewalls with ElectroServer 4.06!

Today we released ElectroServer 4.06 - check it out!

You can now get through firewalls, opening your applications to the widest audience ever using the new HTTP connection option. If a client can't successfully establish a socket connection with the server due to firewall security then HTTP connection can be used and it will just work. As a developer, the only difference in the way that you use the API is you will call createHttpConnection instead of createConnection. All other calls and events are identical!

There is no additional cost for this feature.

This release also brings with it a series of subtle bug fixes seen in the game manager, sending multi-byte characters, and a few other things. See the release notes here.

Last notes:

• It is still recommend to use sockets wherever possible. You will get the most real-time communication this way.
• When testing this feature from the Flash CS3 IDE it is possible to achieve an IDE crash. This is due to a Flash CS3 issue with handling HTTP request/responses. The stand-alone Flash player and the Flash player in the browser will not crash.

ElectroServer 4.05 Released!

ElectroServer 4.05 is here! This release brings more documentation, all reported bugs are fixed, new features, and some new examples.

Read the release notes for the full details.

Download ElectroServer 4.05 here.

ElectroServer Wiki!

For several months we have been filling out an ElectroServer wiki with a lot of documentation and great tutorials! You can check it out here:
http://es-wiki.com/index.php?title=Main_Page

Simulating Latency

Internet or network latency is a fact of life in multiplayer games. The amount of time it takes a message to travel from a client machine to the server or from the server to client machine isn't something we as developers can control. You can effectively handle latency through various latency hiding tricks not discussed here.

It is difficult when programming games to test high latency conditions because developers are usually testing on an ideal set up. In the ElectroServer client-side API we introduced a way for you to simulate latency. There is never a better test than the real thing, but this is great for testing your game under higher message delays. You can crank up the latency to see how your game handles it.

Turning this setting on and off is pretty simple. Here is an example of turning on the latency simulation:
var es:ElectroServer;//created and connection established elsewhere
es.startSimulatingLatency(500);//time in milliseconds

To stop the simulation:
es.stopSimulatingLatency();

Using ES4 to Protect Your Code

It is widely known that if something can be downloaded to a client machine, then it is hackable. Someone who is dedicated enough can rip apart the file and do things like:

• Decompile the application to get at the code.
• Modify the code and recompile.
• Steal the code.
• The person can just extract assets such as images and audio.

There is nothing you can do to guarantee the protection of your file. But you can take measures to make it very difficult for people to mess with. For instance, obfuscating code makes code unreadable.

With ES4 there is something else that you can do to help protect your client-side Flash application. ES4 fully supports a true binary protocol. ByteArrays can be exchanged between the client and the server. Any binary file can be represented in a ByteArray.

The idea is very simple.

• Put the important SWF somewhere non-web-accessible, but where ElectroServer can get at it.
• Have another Flash client (one whose code you can stand to lose) connect to ES4.
• This client then requests the SWF file from ES4. The SWF is streamed to the Flash client over binary socket as a ByteArray.
• When the load has completed, the Flash client uses the Loader.loadBytes() technique (see Flash help) to convert the bytes to an actual MovieClip.

So what does this buy you? Well, now it is is substantially more difficult for someone to grab the SWF file that you are trying to protect.

This is just another layer of security. A person can still intercept the client-bound stream using some other tool and, if they understand the complex ES4 protocol, they can extract the specific SWF bytes.

Obviously you can add another layer of security in here by encrypting the byte stream so that anyone just grabbing the bytes still can't do anything with them, short of knowing encryption information.