Is it possible to do real time network games in Actionscript 3.0

Question

Question: Is it possible to update 100+ objects in the Flash Player over Socket Connections? More details and my own try's below!

Details

For my internship I got the time to create a multiplayer physics game. I worked for a steady three months on it. My internship is coming to an end and I couldn't finish my game.

My problem is that its hard to send multiple packets each time-step to the server and back. The packets I send are position updates of the objects and mouse of other clients.

I will try to explain the network/game flow.

1. Client connects to the server using the binary Socket class in AS3
2. Server ask for verification and client sends name and thumbnail.
3. Server waits until 4 clients are connected (Some matchmaking etc)
4. Server picks 4 clients and makes them run on a separate Thread(Combined as a Team)
5. Client sends his performance score to the server range 1-100.
6. Server makes the best client the host machine for the physics and the other 3 slaves
7. Host game sets up the level and makes around 1-100 shapes in the level(primary shapes and complex shapes like bridges, motors, springs)
8. Every time-step the host gets all updated property's of the shapes and sends them to the clients (x, y, rotation, sleep)
9. The client applys all the shape property's to the correct shapes

I tried different time-steps and noticed that until a time-step of 1/15 second the client(slave) won't notice any lagging in the game. I also tried to pick a lower time-step and tween the movement of the shapes but that did give some strange movement on the client(slave) side.

I will give an example of a single object update packet.

<O|t=s:u|x=201|y=202|f=automaticoo</O
<O|t=m:p|x=100|y=345|f=automaticoo</O

I noticed that the Flash Player can stack a lot of packets in the buffer before sending. For example if I send a lot of packets at once it stacks them up and send them together to the server. With faster time-steps you don't get more updates on the client(slave) side but more updates in the same packet row.

Tries

1. Use the new RTMFP(udp & p2p) protocol for updates. (little bit better in performance but less in reliability)
2. Code my entire socket server in c++ instead of Air(with the ServerSocket) (better in performance but noticed the lagging part is not the server but the Flash Player)
3. Use the ByteArray compress method and the AMF serialized format (performance about the same except the c++ server can't unserialize the messages)

Do you guys think it is possible in the Flash Player too handle so many update request each time-step.

Discoveries

There is a stick arena game that is multiplayer in ActionScript 3.0. They used a lot of tricking and even then I get a ping of about 300ms and it only updates the players constantly (4 players in a lobby).

Sorry for the long post.

Answer 1

I believe your problem comes down to type of game and data.

This again is broken up into:

• server speed (calculations need in CPU + RAM requirements for world/player data)
• connection speed (bandwidth on server)
• data size (how much info is needed and how often)
• player interaction form (event or FPS)
• distance from client to server (ping)

---

MMORG

Eg. World Of Warcraft, is to my knowledge on the none-PVP worlds using a "client is a viewport" and "client sends keystrokes", "server validates and performs, and tells client what happens" on a CLIENT-SERVER base.

This gives the game a lot of acceptable latency as you only need to transfer commands from client and then results to the client. The rest is drawn on the client.

Its very event driven and from you click an icon or press a key, its okay that your "spell" needs some time to fire on the server. Secondly there is no player collision needed. This lets the server process less data too and keeps the requirements to the server CPU smaller.

---

Counter-Strike / Battlefield etc.

FPS, fast paced action, with quick response needs to get information about every detail all the time. This makes a higher demand on precision. Collision is a must for both player and weapons.

This sort of game usually doesnt handle more than 32 players on a single map, as they all need to be able to share their positions, bullets, explosions etc. very fast and all this data has to go through the server-validation which again is a bottleneck for any type of online game.

---

Network latency

In a perfect world this would be 0 ms, but as we all know. All the hardware from client to the server and back takes time. Both going through the network stacks and through the internet connection (switch, router, modem, fiber centrals etc) so the way many modern real time games fixes this is by "prediction". The let the server look at your direction and speed. Then they try to predict (much like the GPS do in a tunnel too) that you were last seen moving forward with a speed of +4 so given timeframe you have moved (timeframes x 4) - but what if you had slowed down or speeded up? then they either instantly "hyperjump" you from A to B in a split second and this you feel like a lagging game or they easy up to the real position so your "hero" slides a little faster or slower into the right possition.

This technique is explained many places on the net, so no need for details in here, but it takes time and tweaks to get a good performance from this - but it works and saves a lot of headaches for the programmers.

---

What network data is needed?

I read your question and thought: that could be compressed quite a lot. Secondly, I have made a Flash socket chat with pure ByteStream and that worked awesome. It was hard to get running for a start, but once I got it up and running it was fast.

The flash client/player itself isnt the biggest networking client, so expect a lot of lost speed there too. I would go for 10-15 fps for the networking part and then use a more RAW approach for the data sent back and forth.

Lastly, try to keep the data as simple as possible.

Eg. use COMMANDS/SHORTCUTS for certain data/events. Like a server data bytestring could be: 0x99, 0x45,0x75,0x14,0x04,0x06

Where 0x99 means : BIG EXPLOSION at the following COORDS: (0x45,0x75) Then 0x14 means: PLAYER 0x14 (player 20 in decimal) has moved to (0x04, 0x06)

So the staring opcode tells the networking protocol handler in your client and server what to expect next. (Its how a CPU knows how to read memory btw.)

For my chat I had commands for each type of data parsed. One for login, one for broadcasting, for for telling the name of a user etc. So once the client made a login, the client received a command + a packed of online users. This was only transfed once to the client. After that each attached client received a "new user online" command too with the name of the new user. Each client maintained its own list with current users and ID's so that I only needed to tell which client number say the text. This kept the traffic at a minimum. Same would go for coordinates or commands of what to do. "Player #20 goes north" etc. could be be 0x14, 0x41, 0xf0 (0x41 could be MOVE, 0xf0 could be NORTH, 0xf1 EAST etc.)

---

This physical distance to the game

This one you cant change, but you can put in some restrictions or make the servers run in multiple locations worldwide, depending on what type of game you wanna make. Amazon EC2 is a great platform for such projects as they have data-centers all over the world and then you can benchmark the users network against these and then redirect the users to the nearest datacenter where you are running a server.

---

Hacking/cheating

Also remember, if something gets popular and you start earning money on it, sooner or later SOMEONE will try to break the protocols or break down the accounts to gain access to servers, informations or cheat to get further items/points in the games. You could also be attacked by DDOS where they bomb your network with wrong data just to crash everything and render the game unusable.

Dont mind it so much for a start, just remember that once you go online, you NEVER know who in the world or where in the world they are. I'm not trying to make you paranoid, but there are sick people who will try to earn money by cheating others.

So think this into your structures, dont show data in network packages that isnt needed. Dont believe data from client always is correct. Validate data on server-side.

This also takes time if you have 100 active players at the same time.

But once you do it, you can sleep much better if it gets to be a big success for you, which I really hope.

---

That was my thoughts from experience. Hope some of it might be usefull eventhough I didnt quite answer if 100 players are possible.

Infact I would say: YES 100 players is possible, but it depends if they all move at the same time and there is collission testing involved and if you will accept lag or not.

Answer 2

Question: Is it possible to update 100+ objects in the Flash Player over Socket Connections?

Phosphor 2 seems to pull it off.

Answer 3

Maybe the best option was do the physics on server AND on each client, with synchronization (server object positions are overwriting client's). This way all clients get equal lags. Until discrepancy is low (as it should be) corrections will not be noticeable. If you use Box2D, you have both AS3 and C++ version ready. But this is totally different architecture, worth 3 month to implement by itself. What lag do you get on empty/simple arena? In limited time, simplification may be your only option.