Red5 Showcase: Flash MMO games

[Łukasz Groszkowski]

I'm almost finished with a multiplayer game in Red5. This suppose to
be a plane fight (dogfight) in 2d. Quite simple game, but there seems to
be some troubles. My employer wants me to confirm if red5 for server was
the right choice so he wants me to supply some links to other red5 based
flash real-time multiplayer games.

Concerning the efficiency of my application - is there any restrictions
(theoretical or practical) invoking methods from client on server and
other way round? Of course I don't expect you to say that Red5 is
something bad
but was my choice accurate?

many thanks for concern, best regards
Lucas

[Dominick Accattato]

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

[Andy Shaules]

I second the motion.

 

Red5 is the first and best choice.

 

There is no other option, really.

 

Andy

[Łukasz Groszkowski]

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).  The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

[Andy Shaules]

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

 

 

Framerate averages between 14 and 30 ?

 

That is too expensive.

 

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

 

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

 

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

 

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

 

Looks like a strong case for shared objects.

 

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

 

Andy

 

----- Original Message -----

From: Łukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

[Andrei Sochirca]

Battle of Britain: 303 Squadron ?

On Sep 17, 4:47 pm, Łukasz Groszkowski <lukasz.groszkow...@gmail.com>
wrote:

[Łukasz Groszkowski]

Well I'm afraid I can do syncs in 5 seconds. The game supposed to be much more dynamic. Moreover - if game has like 8 clients it works fine. It starts to give problems when more rooms are open. You mean that the red5 won't handle this issue? I mean that bandwidth, or resources of servers are not a concern for my client.

In addition client cant do the calculation. The server must be responsible for such calculations due to safety. The winner is awarded a real money prize, so the game must be fraud-proof in this matter.

W dniu 2010-09-17 19:24, Andy Shaules pisze:

[Łukasz Groszkowski]

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

[Trevor Burton]

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

[Andy Shaules]

perfect case for using a Resource Feed.

 

1. develop the simulation on the server.

 

2 develop the controller and web services to interface with the simulation.

 

3. develop resource feed that spits out corrected node data of the sim to synchronize the clients view.

 

4. all clients broadcast their game piece control parameters to the service and the controller/feed handles the broadcasted paths and events of the sim. The clients set their field data for node props perform RPC's for actions. Then you could record the games for playback later, and even filter node types to allow spectator-only clients.

 

But this is also a perfect case for using SO's too. This is limited by overall sim design layout and graphics rendering lag. More often than not, when you make an event to the server, some graphics element gets updated on the client. In a very poor design, Client A makes a call to server, and the call does not return until the graphics of client B is updated. The main thing here seems to be the volume. As Trevor says, sending all in one messages is better than multiple calls.

 

Recommended : http://code.google.com/p/comserver/

 

Depreciated : http://code.google.com/p/redsandy/

 

Andy

----- Original Message -----

From: Trevor Burton

To: red5in...@googlegroups.com

Sent: Friday, September 17, 2010 11:27 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 ?ukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

?

?

Framerate averages between 14 and 30 ?

?

That is too expensive.

?

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

?

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

?

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

?

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

?

Looks like a strong case for shared objects.

?

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

?

Andy

?

----- Original Message -----

From: ?ukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).? The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 ?ukasz Groszkowski <lukasz.gr...@gmail.com>

I'm almost finished with a multiplayer game in Red5. This suppose to
be a plane fight (dogfight) in 2d. Quite simple game, but there seems to
be some troubles. My employer wants me to confirm if red5 for server was
the right choice so he wants me to supply some links to other red5 based
flash real-time multiplayer games.

Concerning the efficiency of my application - is there any restrictions
(theoretical or practical) invoking methods from client on server and
other way round? Of course I don't expect you to say that Red5 is something bad
but was my choice accurate?

many thanks for concern, best regards
Lucas

[Łukasz Groszkowski]

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

ďż˝

ďż˝

Framerate averages between 14 and 30 ?

ďż˝

That is too expensive.

ďż˝

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

ďż˝

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

ďż˝

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

ďż˝

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

ďż˝

Looks like a strong case for shared objects.

ďż˝

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

ďż˝

Andy

ďż˝

----- Original Message -----

From: �ukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).ďż˝ The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

I'm almost finished with a multiplayer game in Red5. This suppose to
be a plane fight (dogfight) in 2d. Quite simple game, but there seems to
be some troubles. My employer wants me to confirm if red5 for server was
the right choice so he wants me to supply some links to other red5 based
flash real-time multiplayer games.

Concerning the efficiency of my application - is there any restrictions
(theoretical or practical) invoking methods from client on server and
other way round? Of course I don't expect you to say that Red5 is something bad
but was my choice accurate?

many thanks for concern, best regards
Lucas

[Łukasz Groszkowski]

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

[Trevor Burton]

In the past i've had a setup where the server keeps a shared object updated... clients make calls to the server via a NetConnection.call() and then listen on the shared object for changes so the calls to the server can be handled and validated and then the clients just listen for SYNC events off the SO... Andy might know more about what the optimum set-up is but it also depends on how you're going to secure things... i'm guessing if money's involved then you're going to want to do your best to make sure that calls coming from players are genuine (detect 'impossible jumps' etc.) 

If you want someone to take a look at error logs then use something like pastebin and post the link in the thread rather than pasting into a mail. or just attach the file somewhere :)

T

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

 

 

Framerate averages between 14 and 30 ?

 

That is too expensive.

 

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

 

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

 

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

 

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

 

Looks like a strong case for shared objects.

 

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

 

Andy

 

----- Original Message -----

From: Łukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).  The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

I'm almost finished with a multiplayer game in Red5. This suppose to
be a plane fight (dogfight) in 2d. Quite simple game, but there seems to
be some troubles. My employer wants me to confirm if red5 for server was
the right choice so he wants me to supply some links to other red5 based
flash real-time multiplayer games.

Concerning the efficiency of my application - is there any restrictions
(theoretical or practical) invoking methods from client on server and
other way round? Of course I don't expect you to say that Red5 is something bad
but was my choice accurate?

many thanks for concern, best regards
Lucas

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

[Dominick Accattato]

so you're doing 2-3 calls per frame? How many frames per second are you running the swf? I'm imagining at least 15. That would be 45 calls per second. That can actually grow to be quite expensive as the others have alluded to. For instance, here's a breakdown.

2 players = 90 calls/sec

3 players = 270 calls/sec

4 players = 1,080 calls/sec

...

and you say that your latency requirements are 150ms... i'm still guessing it's due to this. Also remember that a SharedObject is not just sending a number like "22" etc.. it has to send an entire object with status codes etc...

does everyone agree with this or do I have some funny math going on ;)

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

 

 

Framerate averages between 14 and 30 ?

 

That is too expensive.

 

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

 

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

 

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

 

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

 

Looks like a strong case for shared objects.

 

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

 

Andy

 

----- Original Message -----

From: Łukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).  The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

I'm almost finished with a multiplayer game in Red5. This suppose to
be a plane fight (dogfight) in 2d. Quite simple game, but there seems to
be some troubles. My employer wants me to confirm if red5 for server was
the right choice so he wants me to supply some links to other red5 based
flash real-time multiplayer games.

Concerning the efficiency of my application - is there any restrictions
(theoretical or practical) invoking methods from client on server and
other way round? Of course I don't expect you to say that Red5 is something bad
but was my choice accurate?

many thanks for concern, best regards
Lucas

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

[Andy Shaules]

Yup thats the picture Dominick.

 

 

" And I
> must be certain that every player sees exactly the same thing in the game -
> so no local calculation to make display is allowed."

 

Its not impossible to make that work, but since you are running close to what me and trevor suggest, then I would optimize the order sending.

 

The server sim could listen to so updates rather than web service calls too.

 

You biggest obstacle are the two constraints:

 

1. "must be certain that every player sees exactly the same thing in the game -"

 

2 "the whole project is not very expensive."

 

So's could be very effective using a combination of setting data, and sending method calls.

 

Optimize a little and you could be fine.

[Łukasz Groszkowski]

Yeah, I know what you mean - the number of calls per second is enormous. I was really dumb not to notice that before. But I don't want to fail this project and I still hope that there may be some simple workaround.

About SO: if I have and shared object with properties: x, y, rotation, deltaPitch, deltaThrottle, firingMissle, firingBullet, and the client would alter deltas and firing flags, only during KEY_DOWN, KEY_UP events it would be many times more efficient then making calls every frame to serverside function. And moreover it could be a good idea to separate planeSO from planeControlsSO, so that other players don't get SYNC events when player presses a key. That would probably reduce number of calls from these annoying 48/s to say 0.3-4/s shared object setting. Maybe such optimization would be enough.

W dniu 2010-09-17 21:36, Dominick Accattato pisze:

so you're doing 2-3 calls per frame? How many frames per second are you running the swf? I'm imagining at least 15. That would be 45 calls per second. That can actually grow to be quite expensive as the others have alluded to. For instance, here's a breakdown.

2 players = 90 calls/sec

3 players = 270 calls/sec

4 players = 1,080 calls/sec

...

and you say that your latency requirements are 150ms... i'm still guessing it's due to this. Also remember that a SharedObject is not just sending a number like "22" etc.. it has to send an entire object with status codes etc...

does everyone agree with this or do I have some funny math going on ;)

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

ďż˝

ďż˝

Framerate averages between 14 and 30 ?

ďż˝

That is too expensive.

ďż˝

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

ďż˝

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

ďż˝

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

ďż˝

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

ďż˝

Looks like a strong case for shared objects.

ďż˝

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

ďż˝

Andy

ďż˝

----- Original Message -----

From: �ukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).ďż˝ The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

I'm almost finished with a multiplayer game in Red5. This suppose to
be a plane fight (dogfight) in 2d. Quite simple game, but there seems to
be some troubles. My employer wants me to confirm if red5 for server was
the right choice so he wants me to supply some links to other red5 based
flash real-time multiplayer games.

Concerning the efficiency of my application - is there any restrictions
(theoretical or practical) invoking methods from client on server and
other way round? Of course I don't expect you to say that Red5 is something bad
but was my choice accurate?

many thanks for concern, best regards
Lucas

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

[tom]

wow - never did the math myself , but quite impressive math -  and call frequency.
thx

2010/9/17 Dominick Accattato <dacca...@gmail.com>

[Łukasz Groszkowski]

And one more aspect: is it okay for serverside calculations to perform say 500 calculations concerning planes (x, y, rotation) per second (I think that this is total amount for full game)? I guess its not really depends on red5 but Java itself. And in fact I can't do much about optimizing this calculations (moving planes, projectiles, gravity etc.). Can you provide me with any clue about this? So far I feel somehow better even thou I screw up in the beginning. :)

W dniu 2010-09-17 21:51, tom pisze:

wow - never did the math myself , but quite impressive math -ďż˝ and call frequency.
thx

2010/9/17 Dominick Accattato <dacca...@gmail.com>

so you're doing 2-3 calls per frame? How many frames per second are you running the swf? I'm imagining at least 15. That would be 45 calls per second. That can actually grow to be quite expensive as the others have alluded to. For instance, here's a breakdown.

2 players = 90 calls/sec

3 players = 270 calls/sec

4 players = 1,080 calls/sec

...

and you say that your latency requirements are 150ms... i'm still guessing it's due to this. Also remember that a SharedObject is not just sending a number like "22" etc.. it has to send an entire object with status codes etc...

does everyone agree with this or do I have some funny math going on ;)

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

ďż˝

ďż˝

Framerate averages between 14 and 30 ?

ďż˝

That is too expensive.

ďż˝

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

ďż˝

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

ďż˝

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

ďż˝

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

ďż˝

Looks like a strong case for shared objects.

ďż˝

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

ďż˝

Andy

ďż˝

----- Original Message -----

From: �ukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).ďż˝ The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

I'm almost finished with a multiplayer game in Red5. This suppose to
be a plane fight (dogfight) in 2d. Quite simple game, but there seems to
be some troubles. My employer wants me to confirm if red5 for server was
the right choice so he wants me to supply some links to other red5 based
flash real-time multiplayer games.

Concerning the efficiency of my application - is there any restrictions
(theoretical or practical) invoking methods from client on server and
other way round? Of course I don't expect you to say that Red5 is something bad
but was my choice accurate?

many thanks for concern, best regards
Lucas

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

[Dominick Accattato]

Yeah, the server can handle this I'm sure of that, but the bottleneck is that each client will exponentially be getting more and more call frequency. When you think about a typical roundtrip taking an avg of 30-50 ms, then you quickly realize that you will be choking that pipe with chatter.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

And one more aspect: is it okay for serverside calculations to perform say 500 calculations concerning planes (x, y, rotation) per second (I think that this is total amount for full game)? I guess its not really depends on red5 but Java itself. And in fact I can't do much about optimizing this calculations (moving planes, projectiles, gravity etc.). Can you provide me with any clue about this? So far I feel somehow better even thou I screw up in the beginning. :)

W dniu 2010-09-17 21:51, tom pisze:

wow - never did the math myself , but quite impressive math -  and call frequency.
thx

2010/9/17 Dominick Accattato <dacca...@gmail.com>

so you're doing 2-3 calls per frame? How many frames per second are you running the swf? I'm imagining at least 15. That would be 45 calls per second. That can actually grow to be quite expensive as the others have alluded to. For instance, here's a breakdown.

2 players = 90 calls/sec

3 players = 270 calls/sec

4 players = 1,080 calls/sec

...

and you say that your latency requirements are 150ms... i'm still guessing it's due to this. Also remember that a SharedObject is not just sending a number like "22" etc.. it has to send an entire object with status codes etc...

does everyone agree with this or do I have some funny math going on ;)

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

 

 

Framerate averages between 14 and 30 ?

 

That is too expensive.

 

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

 

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

 

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

 

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

 

Looks like a strong case for shared objects.

 

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

 

Andy

 

----- Original Message -----

From: Łukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).  The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

I'm almost finished with a multiplayer game in Red5. This suppose to
be a plane fight (dogfight) in 2d. Quite simple game, but there seems to
be some troubles. My employer wants me to confirm if red5 for server was
the right choice so he wants me to supply some links to other red5 based
flash real-time multiplayer games.

Concerning the efficiency of my application - is there any restrictions
(theoretical or practical) invoking methods from client on server and
other way round? Of course I don't expect you to say that Red5 is something bad
but was my choice accurate?

many thanks for concern, best regards
Lucas

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

[Łukasz Groszkowski]

Now I feel little lost: why call frequency will be growing exponentially? Moreover - each game will take about 2-3 minutes. If I have 8 players, there will be 8 SO for planes representations, 8 SO for user interaction and a SO for projectiles (containing 3 arrays x, y, r). Each player will be SYNC only to 10 SO totally (assuming full game). Each of the 8 planes SO will be updated 24/sec and if clients can make it they'll feel the lags. About the user interaction SO, they wont be in sync on the client side, only on the server (in fact the data will be read in the update loop; the value will only change on key events). I thought that such approach would make a more-less fixed number of SO update /sec.

Have I missed something?

W dniu 2010-09-17 22:14, Dominick Accattato pisze:

Yeah, the server can handle this I'm sure of that, but the bottleneck is that each client will exponentially be getting more and more call frequency. When you think about a typical roundtrip taking an avg of 30-50 ms, then you quickly realize that you will be choking that pipe with chatter.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

And one more aspect: is it okay for serverside calculations to perform say 500 calculations concerning planes (x, y, rotation) per second (I think that this is total amount for full game)? I guess its not really depends on red5 but Java itself. And in fact I can't do much about optimizing this calculations (moving planes, projectiles, gravity etc.). Can you provide me with any clue about this? So far I feel somehow better even thou I screw up in the beginning. :)

W dniu 2010-09-17 21:51, tom pisze:

wow - never did the math myself , but quite impressive math -ďż˝ and call frequency.
thx

2010/9/17 Dominick Accattato <dacca...@gmail.com>

so you're doing 2-3 calls per frame? How many frames per second are you running the swf? I'm imagining at least 15. That would be 45 calls per second. That can actually grow to be quite expensive as the others have alluded to. For instance, here's a breakdown.

2 players = 90 calls/sec

3 players = 270 calls/sec

4 players = 1,080 calls/sec

...

and you say that your latency requirements are 150ms... i'm still guessing it's due to this. Also remember that a SharedObject is not just sending a number like "22" etc.. it has to send an entire object with status codes etc...

does everyone agree with this or do I have some funny math going on ;)

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

ďż˝

ďż˝

Framerate averages between 14 and 30 ?

ďż˝

That is too expensive.

ďż˝

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

ďż˝

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

ďż˝

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

ďż˝

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

ďż˝

Looks like a strong case for shared objects.

ďż˝

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

ďż˝

Andy

ďż˝

----- Original Message -----

From: �ukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).ďż˝ The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

I'm almost finished with a multiplayer game in Red5. This suppose to
be a plane fight (dogfight) in 2d. Quite simple game, but there seems to
be some troubles. My employer wants me to confirm if red5 for server was
the right choice so he wants me to supply some links to other red5 based
flash real-time multiplayer games.

Concerning the efficiency of my application - is there any restrictions
(theoretical or practical) invoking methods from client on server and
other way round? Of course I don't expect you to say that Red5 is something bad
but was my choice accurate?

many thanks for concern, best regards
Lucas

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

[Trevor Burton]

Well, you could just use a single SO per game and just set parameters on that rather than using one per object/parameter.

I'd still be inclined to batch the key events - otherwise if someone hammers the keyboard and you're sending EVERY event you're going to get some problems. Set a maximum rate, push the events into a batch and then check the batch at some rate, if there's anything in there, send it.

It's long overdue for this sort of knowledge to be collected and put in a wiki somewhere (or something) but there aren't many of us that do this sort of thing and we're all busy (which is both good AND bad).. must get around to it at some point.

T

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Now I feel little lost: why call frequency will be growing exponentially? Moreover - each game will take about 2-3 minutes. If I have 8 players, there will be 8 SO for planes representations, 8 SO for user interaction and a SO for projectiles (containing 3 arrays x, y, r). Each player will be SYNC only to 10 SO totally (assuming full game). Each of the 8 planes SO will be updated 24/sec and if clients can make it they'll feel the lags. About the user interaction SO, they wont be in sync on the client side, only on the server (in fact the data will be read in the update loop; the value will only change on key events). I thought that such approach would make a more-less fixed number of SO update /sec.

Have I missed something?

W dniu 2010-09-17 22:14, Dominick Accattato pisze:

Yeah, the server can handle this I'm sure of that, but the bottleneck is that each client will exponentially be getting more and more call frequency. When you think about a typical roundtrip taking an avg of 30-50 ms, then you quickly realize that you will be choking that pipe with chatter.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

And one more aspect: is it okay for serverside calculations to perform say 500 calculations concerning planes (x, y, rotation) per second (I think that this is total amount for full game)? I guess its not really depends on red5 but Java itself. And in fact I can't do much about optimizing this calculations (moving planes, projectiles, gravity etc.). Can you provide me with any clue about this? So far I feel somehow better even thou I screw up in the beginning. :)

W dniu 2010-09-17 21:51, tom pisze:

wow - never did the math myself , but quite impressive math -  and call frequency.
thx

2010/9/17 Dominick Accattato <dacca...@gmail.com>

so you're doing 2-3 calls per frame? How many frames per second are you running the swf? I'm imagining at least 15. That would be 45 calls per second. That can actually grow to be quite expensive as the others have alluded to. For instance, here's a breakdown.

2 players = 90 calls/sec

3 players = 270 calls/sec

4 players = 1,080 calls/sec

...

and you say that your latency requirements are 150ms... i'm still guessing it's due to this. Also remember that a SharedObject is not just sending a number like "22" etc.. it has to send an entire object with status codes etc...

does everyone agree with this or do I have some funny math going on ;)

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

 

 

Framerate averages between 14 and 30 ?

 

That is too expensive.

 

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

 

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

 

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

 

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

 

Looks like a strong case for shared objects.

 

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

 

Andy

 

----- Original Message -----

From: Łukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).  The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

I'm almost finished with a multiplayer game in Red5. This suppose to
be a plane fight (dogfight) in 2d. Quite simple game, but there seems to
be some troubles. My employer wants me to confirm if red5 for server was
the right choice so he wants me to supply some links to other red5 based
flash real-time multiplayer games.

Concerning the efficiency of my application - is there any restrictions
(theoretical or practical) invoking methods from client on server and
other way round? Of course I don't expect you to say that Red5 is something bad
but was my choice accurate?

many thanks for concern, best regards
Lucas

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

[Łukasz Groszkowski]

Yeah, I see your point. When user will be pressing repetitively space to fire more bullets then such situation could occur. However, how I can batch such events and to make it transparent? I mean, that if I assume to check this batch event holder every 1/24 sec (because it's the highest frequency that would be used in game) it would be almost as bad as current situation. Of course I would send only if there would be something, but in case of hammering the keys it becomes the same. Well I guess that key events can be dispatched at higher rate then framerate, but it seems unlikely in 24fps, but I'll make a safety restriction, not to pass more SO changes. I just don't want users to have the feeling that they are "planning" their movements in advance.

Using one SO would really reduce the server load? Well currently I have kind of clear structure and making just one large SO would mess my things up. But if my above optimizations won't be enough I guess I'll have to do it as well. Hmm... on the other hand - I also see the point - each plane is updated and SYNC's with client and this is way less efficient if there were just one SO for all objects in game. However I think keeping separate shared objects for controlling planes would be necessary. I don't want to SYNC everybody when any of players presses a key. So instead of 8 + 8 + 1 SO for game I'd have only 9 total. Seems much better.ďż˝

W dniu 2010-09-18 09:50, Trevor Burton pisze:

Well, you could just use a single SO per game and just set parameters on that rather than using one per object/parameter.

I'd still be inclined to batch the key events - otherwise if someone hammers the keyboard and you're sending EVERY event you're going to get some problems. Set a maximum rate, push the events into a batch and then check the batch at some rate, if there's anything in there, send it.

It's long overdue for this sort of knowledge to be collected and put in a wiki somewhere (or something) but there aren't many of us that do this sort of thing and we're all busy (which is both good AND bad).. must get around to it at some point.

T

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Now I feel little lost: why call frequency will be growing exponentially? Moreover - each game will take about 2-3 minutes. If I have 8 players, there will be 8 SO for planes representations, 8 SO for user interaction and a SO for projectiles (containing 3 arrays x, y, r). Each player will be SYNC only to 10 SO totally (assuming full game). Each of the 8 planes SO will be updated 24/sec and if clients can make it they'll feel the lags. About the user interaction SO, they wont be in sync on the client side, only on the server (in fact the data will be read in the update loop; the value will only change on key events). I thought that such approach would make a more-less fixed number of SO update /sec.

Have I missed something?

W dniu 2010-09-17 22:14, Dominick Accattato pisze:

Yeah, the server can handle this I'm sure of that, but the bottleneck is that each client will exponentially be getting more and more call frequency. When you think about a typical roundtrip taking an avg of 30-50 ms, then you quickly realize that you will be choking that pipe with chatter.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

And one more aspect: is it okay for serverside calculations to perform say 500 calculations concerning planes (x, y, rotation) per second (I think that this is total amount for full game)? I guess its not really depends on red5 but Java itself. And in fact I can't do much about optimizing this calculations (moving planes, projectiles, gravity etc.). Can you provide me with any clue about this? So far I feel somehow better even thou I screw up in the beginning. :)

W dniu 2010-09-17 21:51, tom pisze:

wow - never did the math myself , but quite impressive math -ďż˝ and call frequency.
thx

2010/9/17 Dominick Accattato <dacca...@gmail.com>

so you're doing 2-3 calls per frame? How many frames per second are you running the swf? I'm imagining at least 15. That would be 45 calls per second. That can actually grow to be quite expensive as the others have alluded to. For instance, here's a breakdown.

2 players = 90 calls/sec

3 players = 270 calls/sec

4 players = 1,080 calls/sec

...

and you say that your latency requirements are 150ms... i'm still guessing it's due to this. Also remember that a SharedObject is not just sending a number like "22" etc.. it has to send an entire object with status codes etc...

does everyone agree with this or do I have some funny math going on ;)

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

ďż˝

ďż˝

Framerate averages between 14 and 30 ?

ďż˝

That is too expensive.

ďż˝

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

ďż˝

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

ďż˝

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

ďż˝

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

ďż˝

Looks like a strong case for shared objects.

ďż˝

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

ďż˝

Andy

ďż˝

----- Original Message -----

From: �ukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).ďż˝ The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

I'm almost finished with a multiplayer game in Red5. This suppose to
be a plane fight (dogfight) in 2d. Quite simple game, but there seems to
be some troubles. My employer wants me to confirm if red5 for server was
the right choice so he wants me to supply some links to other red5 based
flash real-time multiplayer games.

Concerning the efficiency of my application - is there any restrictions
(theoretical or practical) invoking methods from client on server and
other way round? Of course I don't expect you to say that Red5 is something bad
but was my choice accurate?

many thanks for concern, best regards
Lucas

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

[Łukasz Groszkowski]

So far big thanks for help. Thanks to your I have at least some ideas how to try solving the situation and I'm more aware of restrictions imposed by red5. I still have hope that my optimization will suffice and the game will go to production phase. Currently they released it as beta >.< without complete testing I asked for.

W dniu 2010-09-18 12:03, Trevor Burton pisze:

yes, other servers *should* show the same restrictions.ďż˝

Some points to mention to your client/employer:

Because tcp traffic is 'reliable' there's all sorts of stuff going on to make sure packets arrive and that they arrive in order. This is why you see 'fast twitch' multiplayer games using UDP as the basis for their network layers - with UDP you can just process packets as they arrive and drop them if they're out of order.. Bang, you're done... makes like easier.

Yes, FMS now support RTMFP which is based on UDP but it's encrypted which adds a load of overhead and it's restricted to 30 (i think) users in the dev version - you'd need around $55k to get an enterprise version - so you could mention that to your client.

smart fox uses XMLSocket (i think, someone here should correct me if i'm wrong) so that will be slower than the AMF serialisation that's being used to communicate with Red5 and more data will be sent over the connection (AMF is a pretty compact beast)

Basically there's no reason why Red5 should not have been your first choice for a multiplayer game... the problems you're experiencing are due to the fact that the Flash Player can't support the sort of network load your game design seems to demand. So either the design has to change somewhere or you have to change platform

my 2 centsďż˝

keep hitting the list for advice... it's always nice to see people trying to push what Red5 can do... just a shame when you're under the cosh from work to do it :)

T

2010/9/18 �ukasz Groszkowski <lukasz.gr...@gmail.com>

I guess that other servers (FMS, SmartFox) will have the same problems, right? Since you said its the protocol problem, not server... I need to say something to my employer about that, he starts to claim that I did wrong choosing red5, but now I think that the whole project is very risky by its terms and requirements.

Since the game is developed I'll optimize the things and just forward it to the testing team. They should take care of the load tests and such. Oh, and the memory and processor load haven't changed much when many games were on - say just 0.5% increment per game of processor use and about the same value for memory.

About the animations - well as it's a kind of fraud-proof mechanism it will be hard to omit it. So far there were no serious problems with animations while testing the game even by 8 players. The SYNC events seems to stack in the client if client's ping is to high, so then it's the classic lag choke animation, but as I wrote before - it's up to users to have good connection for the game.

W dniu 2010-09-18 11:35, Trevor Burton pisze:

I think expecting your network updates to drive your animation is going to cause problems... they'll never arrive in an even manner, i strongly suggest using some sort of 'easing' to make the animation look smooth otherwise it's going to be choppy and poor.

How do you know there'll be enough resource to run that many games? I'd be very wary of making an assumption like that until i'd done some load testing.

It would be worth you spending some time writing a test harness that'll send some randomly generated game objects to your server, you can then ramp up the rates you send and receive and monitor your server to see how it handles it in terms of memory and processor load. Then you'll know for sure whether it's worth investing the time in actually writing the rest of the game or if you need to do more work on the network layer.

As for using instances of Red5 on the same machine i can't say, i've never tried it or worked with anyone who's used it that way so i couldn't give you any sort of reliable answer, sorry.

2010/9/18 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Hmm.. well so maybe I can reduce to say 12fps. I don't want to make animations look poor. Anyway, I want first of all to make this thing work. Currently when the game was tested with say 8 players, the Flash Player did not crash (but only if one game was running on the server, otherwise the players were unable to maneuver the planes - too many invoke calls I guess), so I hope that this will suffice. The game was playable and no problems were detected until another full game was launched on the server. I think that if I perform all this optimization, there should be enough resources to run say 5-10 games simultaneously which in fact is my goal.

On the other hand, how about launching say 5 virtual red5 servers on the server machine with different IP's and assigning clients to them? I don't need all game rooms to be in the same server, since the user verification and other things are done by other means. Maybe it sounds crazy but since I don't really care about physical resources of machine, maybe that would solve some issues. What do you think?

W dniu 2010-09-18 11:17, Trevor Burton pisze:

The problem is you're operating over an HTTP connection - the overhead involved means that sending 24 updates a second to the server is going to cause problems when you have more than a few players... If you were using a lightweight networking protocol built on top of UDP then 24-30 game packets a second would be acceptable.ďż˝

Red5 can work with UDP but the Flash Player can't.

Also, receiving more than a few shared object updates a second is going to crash the flash player - i know, i've hit this problem before. Batching was what got me around it. I receive the same number of updates, but they're batched, i get them less often and i play through them so it 'looks' as if they're arriving in a constant stream.

This does seem like a case where Andy's streaming approach could help you - i'm not sure about the sort of frequency of updates it can cope with but if absolutely have to have that level of frequency of updates then i don't think Shared Objects are going to cut it so it might be your only option.

Sorry if this sounds harsh but the platform and networking protocols you're working with just weren't designed for this sort of use - if the Flash Player supported UDP outside of AIR then you might be ok :(

T

2010/9/18 �ukasz Groszkowski <lukasz.gr...@gmail.com>

[Andy Shaules]

Hello,

 

Yup, those are not restrictions imposed by red5. Those are restrictions imposed by the network. Buy another server and refactor your game code, you will be in the exact same boat, but out of more money. The problem is simple, and two fold.

 

1) When a user is pressing a key and holding it, why would you send repeated signals, when a single 'on' and single 'off' can be sent? Shared object do this automatically if the property gets dirty locally. They only send changes, and only at a specified 'frame rate' so rapid changes may not go through. When it 'must' get through, use so.send(); 

 

2) The jumpy animations are from taking the data as it comes, which may or may not be regular, so a game-view may not be synchronized. Best results seem to come from running a local sim that is gently/tween corrected by the real server sim. Another compelling reason to use flv cue points for transmission is cue through time.

 

 

 

Andy

----- Original Message -----

From: Łukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Trevor Burton

Sent: Saturday, September 18, 2010 3:08 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

So far big thanks for help. Thanks to your I have at least some ideas how to try solving the situation and I'm more aware of restrictions imposed by red5. I still have hope that my optimization will suffice and the game will go to production phase. Currently they released it as beta >.< without complete testing I asked for.

W dniu 2010-09-18 12:03, Trevor Burton pisze:

yes, other servers *should* show the same restrictions. 

Some points to mention to your client/employer:

Because tcp traffic is 'reliable' there's all sorts of stuff going on to make sure packets arrive and that they arrive in order. This is why you see 'fast twitch' multiplayer games using UDP as the basis for their network layers - with UDP you can just process packets as they arrive and drop them if they're out of order.. Bang, you're done... makes like easier.

Yes, FMS now support RTMFP which is based on UDP but it's encrypted which adds a load of overhead and it's restricted to 30 (i think) users in the dev version - you'd need around $55k to get an enterprise version - so you could mention that to your client.

smart fox uses XMLSocket (i think, someone here should correct me if i'm wrong) so that will be slower than the AMF serialisation that's being used to communicate with Red5 and more data will be sent over the connection (AMF is a pretty compact beast)

Basically there's no reason why Red5 should not have been your first choice for a multiplayer game... the problems you're experiencing are due to the fact that the Flash Player can't support the sort of network load your game design seems to demand. So either the design has to change somewhere or you have to change platform

my 2 cents 

keep hitting the list for advice... it's always nice to see people trying to push what Red5 can do... just a shame when you're under the cosh from work to do it :)

T

2010/9/18 Łukasz Groszkowski <lukasz.gr...@gmail.com>

I guess that other servers (FMS, SmartFox) will have the same problems, right? Since you said its the protocol problem, not server... I need to say something to my employer about that, he starts to claim that I did wrong choosing red5, but now I think that the whole project is very risky by its terms and requirements.

Since the game is developed I'll optimize the things and just forward it to the testing team. They should take care of the load tests and such. Oh, and the memory and processor load haven't changed much when many games were on - say just 0.5% increment per game of processor use and about the same value for memory.

About the animations - well as it's a kind of fraud-proof mechanism it will be hard to omit it. So far there were no serious problems with animations while testing the game even by 8 players. The SYNC events seems to stack in the client if client's ping is to high, so then it's the classic lag choke animation, but as I wrote before - it's up to users to have good connection for the game.

W dniu 2010-09-18 11:35, Trevor Burton pisze:

I think expecting your network updates to drive your animation is going to cause problems... they'll never arrive in an even manner, i strongly suggest using some sort of 'easing' to make the animation look smooth otherwise it's going to be choppy and poor.

How do you know there'll be enough resource to run that many games? I'd be very wary of making an assumption like that until i'd done some load testing.

It would be worth you spending some time writing a test harness that'll send some randomly generated game objects to your server, you can then ramp up the rates you send and receive and monitor your server to see how it handles it in terms of memory and processor load. Then you'll know for sure whether it's worth investing the time in actually writing the rest of the game or if you need to do more work on the network layer.

As for using instances of Red5 on the same machine i can't say, i've never tried it or worked with anyone who's used it that way so i couldn't give you any sort of reliable answer, sorry.

2010/9/18 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Hmm.. well so maybe I can reduce to say 12fps. I don't want to make animations look poor. Anyway, I want first of all to make this thing work. Currently when the game was tested with say 8 players, the Flash Player did not crash (but only if one game was running on the server, otherwise the players were unable to maneuver the planes - too many invoke calls I guess), so I hope that this will suffice. The game was playable and no problems were detected until another full game was launched on the server. I think that if I perform all this optimization, there should be enough resources to run say 5-10 games simultaneously which in fact is my goal.

On the other hand, how about launching say 5 virtual red5 servers on the server machine with different IP's and assigning clients to them? I don't need all game rooms to be in the same server, since the user verification and other things are done by other means. Maybe it sounds crazy but since I don't really care about physical resources of machine, maybe that would solve some issues. What do you think?

W dniu 2010-09-18 11:17, Trevor Burton pisze:

The problem is you're operating over an HTTP connection - the overhead involved means that sending 24 updates a second to the server is going to cause problems when you have more than a few players... If you were using a lightweight networking protocol built on top of UDP then 24-30 game packets a second would be acceptable. 

Red5 can work with UDP but the Flash Player can't.

Also, receiving more than a few shared object updates a second is going to crash the flash player - i know, i've hit this problem before. Batching was what got me around it. I receive the same number of updates, but they're batched, i get them less often and i play through them so it 'looks' as if they're arriving in a constant stream.

This does seem like a case where Andy's streaming approach could help you - i'm not sure about the sort of frequency of updates it can cope with but if absolutely have to have that level of frequency of updates then i don't think Shared Objects are going to cut it so it might be your only option.

Sorry if this sounds harsh but the platform and networking protocols you're working with just weren't designed for this sort of use - if the Flash Player supported UDP outside of AIR then you might be ok :(

T

2010/9/18 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Yeah, I see your point. When user will be pressing repetitively space to fire more bullets then such situation could occur. However, how I can batch such events and to make it transparent? I mean, that if I assume to check this batch event holder every 1/24 sec (because it's the highest frequency that would be used in game) it would be almost as bad as current situation. Of course I would send only if there would be something, but in case of hammering the keys it becomes the same. Well I guess that key events can be dispatched at higher rate then framerate, but it seems unlikely in 24fps, but I'll make a safety restriction, not to pass more SO changes. I just don't want users to have the feeling that they are "planning" their movements in advance.

Using one SO would really reduce the server load? Well currently I have kind of clear structure and making just one large SO would mess my things up. But if my above optimizations won't be enough I guess I'll have to do it as well. Hmm... on the other hand - I also see the point - each plane is updated and SYNC's with client and this is way less efficient if there were just one SO for all objects in game. However I think keeping separate shared objects for controlling planes would be necessary. I don't want to SYNC everybody when any of players presses a key. So instead of 8 + 8 + 1 SO for game I'd have only 9 total. Seems much better. 

W dniu 2010-09-18 09:50, Trevor Burton pisze:

Well, you could just use a single SO per game and just set parameters on that rather than using one per object/parameter.

I'd still be inclined to batch the key events - otherwise if someone hammers the keyboard and you're sending EVERY event you're going to get some problems. Set a maximum rate, push the events into a batch and then check the batch at some rate, if there's anything in there, send it.

It's long overdue for this sort of knowledge to be collected and put in a wiki somewhere (or something) but there aren't many of us that do this sort of thing and we're all busy (which is both good AND bad).. must get around to it at some point.

T

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Now I feel little lost: why call frequency will be growing exponentially? Moreover - each game will take about 2-3 minutes. If I have 8 players, there will be 8 SO for planes representations, 8 SO for user interaction and a SO for projectiles (containing 3 arrays x, y, r). Each player will be SYNC only to 10 SO totally (assuming full game). Each of the 8 planes SO will be updated 24/sec and if clients can make it they'll feel the lags. About the user interaction SO, they wont be in sync on the client side, only on the server (in fact the data will be read in the update loop; the value will only change on key events). I thought that such approach would make a more-less fixed number of SO update /sec.

Have I missed something?

W dniu 2010-09-17 22:14, Dominick Accattato pisze:

Yeah, the server can handle this I'm sure of that, but the bottleneck is that each client will exponentially be getting more and more call frequency. When you think about a typical roundtrip taking an avg of 30-50 ms, then you quickly realize that you will be choking that pipe with chatter.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

And one more aspect: is it okay for serverside calculations to perform say 500 calculations concerning planes (x, y, rotation) per second (I think that this is total amount for full game)? I guess its not really depends on red5 but Java itself. And in fact I can't do much about optimizing this calculations (moving planes, projectiles, gravity etc.). Can you provide me with any clue about this? So far I feel somehow better even thou I screw up in the beginning. :)

W dniu 2010-09-17 21:51, tom pisze:

wow - never did the math myself , but quite impressive math -  and call frequency.
thx

2010/9/17 Dominick Accattato <dacca...@gmail.com>

so you're doing 2-3 calls per frame? How many frames per second are you running the swf? I'm imagining at least 15. That would be 45 calls per second. That can actually grow to be quite expensive as the others have alluded to. For instance, here's a breakdown.

2 players = 90 calls/sec

3 players = 270 calls/sec

4 players = 1,080 calls/sec

...

and you say that your latency requirements are 150ms... i'm still guessing it's due to this. Also remember that a SharedObject is not just sending a number like "22" etc.. it has to send an entire object with status codes etc...

does everyone agree with this or do I have some funny math going on ;)

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

 

 

Framerate averages between 14 and 30 ?

 

That is too expensive.

 

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

 

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

 

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

 

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

 

Looks like a strong case for shared objects.

 

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

 

Andy

 

----- Original Message -----

From: Łukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).  The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

[Łukasz Groszkowski]

Yeah, Andy - I got you: when I meant about sending keyUp, keyDown events I meant that to send exactly as you said: only start and end of action. Anyway so far I haven't expected jumpy animations, but I cannot exclude that from product version. How could I make tweens from position to position if I don't know the time between SYNC events reaching client and new positions? And I think making local situation could mislead some users aiming at their targets. Well anyway I'll think about it. Thanks for advice.

W dniu 2010-09-18 17:27, Andy Shaules pisze:

Hello,

ďż˝

Yup, those are not restrictions imposed by red5. Those are restrictions imposed by the network. Buy another server and refactor your game code, you will be in the exact same boat, but out of more money.�The problem is simple, and two fold.

ďż˝

1) When a user is pressing a key and holding it, why would you send repeated signals, when a single 'on' and single 'off' can be sent? Shared object do this automatically if the property gets dirty locally. They only send changes, and only at a specified 'frame rate' so rapid changes may not go through. When it 'must' get through, use so.send();ďż˝

ďż˝

2) The jumpy animations are from taking the data as it comes, which may or may not be regular, so a game-view may not be synchronized. Best results seem to come from running a local sim that is gently/tween corrected by the real server sim. Another compelling reason to use flv cue points for transmission is cue through time.

ďż˝

ďż˝

ďż˝

Andy

----- Original Message -----

From: �ukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Trevor Burton

Sent: Saturday, September 18, 2010 3:08 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

So far big thanks for help. Thanks to your I have at least some ideas how to try solving the situation and I'm more aware of restrictions imposed by red5. I still have hope that my optimization will suffice and the game will go to production phase. Currently they released it as beta >.< without complete testing I asked for.

W dniu 2010-09-18 12:03, Trevor Burton pisze:

yes, other servers *should* show the same restrictions.ďż˝

Some points to mention to your client/employer:

Because tcp traffic is 'reliable' there's all sorts of stuff going on to make sure packets arrive and that they arrive in order. This is why you see 'fast twitch' multiplayer games using UDP as the basis for their network layers - with UDP you can just process packets as they arrive and drop them if they're out of order.. Bang, you're done... makes like easier.

Yes, FMS now support RTMFP which is based on UDP but it's encrypted which adds a load of overhead and it's restricted to 30 (i think) users in the dev version - you'd need around $55k to get an enterprise version - so you could mention that to your client.

smart fox uses XMLSocket (i think, someone here should correct me if i'm wrong) so that will be slower than the AMF serialisation that's being used to communicate with Red5 and more data will be sent over the connection (AMF is a pretty compact beast)

Basically there's no reason why Red5 should not have been your first choice for a multiplayer game... the problems you're experiencing are due to the fact that the Flash Player can't support the sort of network load your game design seems to demand. So either the design has to change somewhere or you have to change platform

my 2 centsďż˝

keep hitting the list for advice... it's always nice to see people trying to push what Red5 can do... just a shame when you're under the cosh from work to do it :)

T

2010/9/18 �ukasz Groszkowski <lukasz.gr...@gmail.com>

I guess that other servers (FMS, SmartFox) will have the same problems, right? Since you said its the protocol problem, not server... I need to say something to my employer about that, he starts to claim that I did wrong choosing red5, but now I think that the whole project is very risky by its terms and requirements.

Since the game is developed I'll optimize the things and just forward it to the testing team. They should take care of the load tests and such. Oh, and the memory and processor load haven't changed much when many games were on - say just 0.5% increment per game of processor use and about the same value for memory.

About the animations - well as it's a kind of fraud-proof mechanism it will be hard to omit it. So far there were no serious problems with animations while testing the game even by 8 players. The SYNC events seems to stack in the client if client's ping is to high, so then it's the classic lag choke animation, but as I wrote before - it's up to users to have good connection for the game.

W dniu 2010-09-18 11:35, Trevor Burton pisze:

I think expecting your network updates to drive your animation is going to cause problems... they'll never arrive in an even manner, i strongly suggest using some sort of 'easing' to make the animation look smooth otherwise it's going to be choppy and poor.

How do you know there'll be enough resource to run that many games? I'd be very wary of making an assumption like that until i'd done some load testing.

It would be worth you spending some time writing a test harness that'll send some randomly generated game objects to your server, you can then ramp up the rates you send and receive and monitor your server to see how it handles it in terms of memory and processor load. Then you'll know for sure whether it's worth investing the time in actually writing the rest of the game or if you need to do more work on the network layer.

As for using instances of Red5 on the same machine i can't say, i've never tried it or worked with anyone who's used it that way so i couldn't give you any sort of reliable answer, sorry.

2010/9/18 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Hmm.. well so maybe I can reduce to say 12fps. I don't want to make animations look poor. Anyway, I want first of all to make this thing work. Currently when the game was tested with say 8 players, the Flash Player did not crash (but only if one game was running on the server, otherwise the players were unable to maneuver the planes - too many invoke calls I guess), so I hope that this will suffice. The game was playable and no problems were detected until another full game was launched on the server. I think that if I perform all this optimization, there should be enough resources to run say 5-10 games simultaneously which in fact is my goal.

On the other hand, how about launching say 5 virtual red5 servers on the server machine with different IP's and assigning clients to them? I don't need all game rooms to be in the same server, since the user verification and other things are done by other means. Maybe it sounds crazy but since I don't really care about physical resources of machine, maybe that would solve some issues. What do you think?

W dniu 2010-09-18 11:17, Trevor Burton pisze:

The problem is you're operating over an HTTP connection - the overhead involved means that sending 24 updates a second to the server is going to cause problems when you have more than a few players... If you were using a lightweight networking protocol built on top of UDP then 24-30 game packets a second would be acceptable.ďż˝

Red5 can work with UDP but the Flash Player can't.

Also, receiving more than a few shared object updates a second is going to crash the flash player - i know, i've hit this problem before. Batching was what got me around it. I receive the same number of updates, but they're batched, i get them less often and i play through them so it 'looks' as if they're arriving in a constant stream.

This does seem like a case where Andy's streaming approach could help you - i'm not sure about the sort of frequency of updates it can cope with but if absolutely have to have that level of frequency of updates then i don't think Shared Objects are going to cut it so it might be your only option.

Sorry if this sounds harsh but the platform and networking protocols you're working with just weren't designed for this sort of use - if the Flash Player supported UDP outside of AIR then you might be ok :(

T

2010/9/18 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Yeah, I see your point. When user will be pressing repetitively space to fire more bullets then such situation could occur. However, how I can batch such events and to make it transparent? I mean, that if I assume to check this batch event holder every 1/24 sec (because it's the highest frequency that would be used in game) it would be almost as bad as current situation. Of course I would send only if there would be something, but in case of hammering the keys it becomes the same. Well I guess that key events can be dispatched at higher rate then framerate, but it seems unlikely in 24fps, but I'll make a safety restriction, not to pass more SO changes. I just don't want users to have the feeling that they are "planning" their movements in advance.

Using one SO would really reduce the server load? Well currently I have kind of clear structure and making just one large SO would mess my things up. But if my above optimizations won't be enough I guess I'll have to do it as well. Hmm... on the other hand - I also see the point - each plane is updated and SYNC's with client and this is way less efficient if there were just one SO for all objects in game. However I think keeping separate shared objects for controlling planes would be necessary. I don't want to SYNC everybody when any of players presses a key. So instead of 8 + 8 + 1 SO for game I'd have only 9 total. Seems much better.ďż˝

W dniu 2010-09-18 09:50, Trevor Burton pisze:

Well, you could just use a single SO per game and just set parameters on that rather than using one per object/parameter.

I'd still be inclined to batch the key events - otherwise if someone hammers the keyboard and you're sending EVERY event you're going to get some problems. Set a maximum rate, push the events into a batch and then check the batch at some rate, if there's anything in there, send it.

It's long overdue for this sort of knowledge to be collected and put in a wiki somewhere (or something) but there aren't many of us that do this sort of thing and we're all busy (which is both good AND bad).. must get around to it at some point.

T

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Now I feel little lost: why call frequency will be growing exponentially? Moreover - each game will take about 2-3 minutes. If I have 8 players, there will be 8 SO for planes representations, 8 SO for user interaction and a SO for projectiles (containing 3 arrays x, y, r). Each player will be SYNC only to 10 SO totally (assuming full game). Each of the 8 planes SO will be updated 24/sec and if clients can make it they'll feel the lags. About the user interaction SO, they wont be in sync on the client side, only on the server (in fact the data will be read in the update loop; the value will only change on key events). I thought that such approach would make a more-less fixed number of SO update /sec.

Have I missed something?

W dniu 2010-09-17 22:14, Dominick Accattato pisze:

Yeah, the server can handle this I'm sure of that, but the bottleneck is that each client will exponentially be getting more and more call frequency. When you think about a typical roundtrip taking an avg of 30-50 ms, then you quickly realize that you will be choking that pipe with chatter.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

And one more aspect: is it okay for serverside calculations to perform say 500 calculations concerning planes (x, y, rotation) per second (I think that this is total amount for full game)? I guess its not really depends on red5 but Java itself. And in fact I can't do much about optimizing this calculations (moving planes, projectiles, gravity etc.). Can you provide me with any clue about this? So far I feel somehow better even thou I screw up in the beginning. :)

W dniu 2010-09-17 21:51, tom pisze:

wow - never did the math myself , but quite impressive math -ďż˝ and call frequency.
thx

2010/9/17 Dominick Accattato <dacca...@gmail.com>

so you're doing 2-3 calls per frame? How many frames per second are you running the swf? I'm imagining at least 15. That would be 45 calls per second. That can actually grow to be quite expensive as the others have alluded to. For instance, here's a breakdown.

2 players = 90 calls/sec

3 players = 270 calls/sec

4 players = 1,080 calls/sec

...

and you say that your latency requirements are 150ms... i'm still guessing it's due to this. Also remember that a SharedObject is not just sending a number like "22" etc.. it has to send an entire object with status codes etc...

does everyone agree with this or do I have some funny math going on ;)

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

ďż˝

ďż˝

Framerate averages between 14 and 30 ?

ďż˝

That is too expensive.

ďż˝

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

ďż˝

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

ďż˝

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

ďż˝

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

ďż˝

Looks like a strong case for shared objects.

ďż˝

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

ďż˝

Andy

ďż˝

----- Original Message -----

From: �ukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).ďż˝ The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

[Cristian Rusu]

Maybe you can use few SO for low frequency data change and some SO for high frequency like ship movement. This way you don;t send redundant and usless data around each time one steer.

For the keyboard event, maybe you can pile up the user input and send at controlled rate, whatever is too much in a pile you can drop it. You have to figure out a decent "real time" scenario optimization for players not to feel they travel in time :)

---------------------------------------------------------------
Cristian Rusu
Web Developement & Electronic Publishing

======
Crilance.com
Crilance.blogspot.com

2010/9/18 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Yeah, I see your point. When user will be pressing repetitively space to fire more bullets then such situation could occur. However, how I can batch such events and to make it transparent? I mean, that if I assume to check this batch event holder every 1/24 sec (because it's the highest frequency that would be used in game) it would be almost as bad as current situation. Of course I would send only if there would be something, but in case of hammering the keys it becomes the same. Well I guess that key events can be dispatched at higher rate then framerate, but it seems unlikely in 24fps, but I'll make a safety restriction, not to pass more SO changes. I just don't want users to have the feeling that they are "planning" their movements in advance.

Using one SO would really reduce the server load? Well currently I have kind of clear structure and making just one large SO would mess my things up. But if my above optimizations won't be enough I guess I'll have to do it as well. Hmm... on the other hand - I also see the point - each plane is updated and SYNC's with client and this is way less efficient if there were just one SO for all objects in game. However I think keeping separate shared objects for controlling planes would be necessary. I don't want to SYNC everybody when any of players presses a key. So instead of 8 + 8 + 1 SO for game I'd have only 9 total. Seems much better. 

W dniu 2010-09-18 09:50, Trevor Burton pisze:

Well, you could just use a single SO per game and just set parameters on that rather than using one per object/parameter.

I'd still be inclined to batch the key events - otherwise if someone hammers the keyboard and you're sending EVERY event you're going to get some problems. Set a maximum rate, push the events into a batch and then check the batch at some rate, if there's anything in there, send it.

It's long overdue for this sort of knowledge to be collected and put in a wiki somewhere (or something) but there aren't many of us that do this sort of thing and we're all busy (which is both good AND bad).. must get around to it at some point.

T

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Now I feel little lost: why call frequency will be growing exponentially? Moreover - each game will take about 2-3 minutes. If I have 8 players, there will be 8 SO for planes representations, 8 SO for user interaction and a SO for projectiles (containing 3 arrays x, y, r). Each player will be SYNC only to 10 SO totally (assuming full game). Each of the 8 planes SO will be updated 24/sec and if clients can make it they'll feel the lags. About the user interaction SO, they wont be in sync on the client side, only on the server (in fact the data will be read in the update loop; the value will only change on key events). I thought that such approach would make a more-less fixed number of SO update /sec.

Have I missed something?

W dniu 2010-09-17 22:14, Dominick Accattato pisze:

Yeah, the server can handle this I'm sure of that, but the bottleneck is that each client will exponentially be getting more and more call frequency. When you think about a typical roundtrip taking an avg of 30-50 ms, then you quickly realize that you will be choking that pipe with chatter.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

And one more aspect: is it okay for serverside calculations to perform say 500 calculations concerning planes (x, y, rotation) per second (I think that this is total amount for full game)? I guess its not really depends on red5 but Java itself. And in fact I can't do much about optimizing this calculations (moving planes, projectiles, gravity etc.). Can you provide me with any clue about this? So far I feel somehow better even thou I screw up in the beginning. :)

W dniu 2010-09-17 21:51, tom pisze:

wow - never did the math myself , but quite impressive math -  and call frequency.
thx

2010/9/17 Dominick Accattato <dacca...@gmail.com>

so you're doing 2-3 calls per frame? How many frames per second are you running the swf? I'm imagining at least 15. That would be 45 calls per second. That can actually grow to be quite expensive as the others have alluded to. For instance, here's a breakdown.

2 players = 90 calls/sec

3 players = 270 calls/sec

4 players = 1,080 calls/sec

...

and you say that your latency requirements are 150ms... i'm still guessing it's due to this. Also remember that a SharedObject is not just sending a number like "22" etc.. it has to send an entire object with status codes etc...

does everyone agree with this or do I have some funny math going on ;)

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

 

 

Framerate averages between 14 and 30 ?

 

That is too expensive.

 

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

 

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

 

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

 

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

 

Looks like a strong case for shared objects.

 

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

 

Andy

 

----- Original Message -----

From: Łukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).  The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

I'm almost finished with a multiplayer game in Red5. This suppose to
be a plane fight (dogfight) in 2d. Quite simple game, but there seems to
be some troubles. My employer wants me to confirm if red5 for server was
the right choice so he wants me to supply some links to other red5 based
flash real-time multiplayer games.

Concerning the efficiency of my application - is there any restrictions
(theoretical or practical) invoking methods from client on server and
other way round? Of course I don't expect you to say that Red5 is something bad
but was my choice accurate?

many thanks for concern, best regards
Lucas

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

--
Trevor Burton
http://www.flashmonkey.org
http://www.quick.tv

[Łukasz Groszkowski]

Good news!
Thanks to your advices I've optimized my code to use SO for control. Now the game works smoothly. There are some other issues anyway. I am going to implement these motion tweens for smoothing animations, due my client started to press on this. In fact I don't know what is worse: jumpy animation or seeing something in wrong place, never mind. Also he started to press for migration to SmartFox. I have absolutely no clue about SmartFox, and so I'll try to stick to red5.

Again: Big thanks. If you can rally me a bit how to make these motion tweens I'd be grateful. Currently my application receives at say more-less constant rate Shared Object SYNC event with new coordinates and rotation for each plane. Should I do something like tweening the move over the time of update period? I'd like to avoid using local sim.

Oh, and also a question: there were some problems regarding flash player it self. Its not due network but probably due large number of generated clips: if there are plenty (40, 80) clips of 30 frame vector smoke tween anim, would it better for the app to make this smoke png?

Thanks for help! You're the best!ďż˝

W dniu 2010-09-18 17:50, Andy Shaules pisze:

In a jumpy network for the slow connected player, he could never make aim or see his plane fly in a normal path. Plus you try to set the graphics larger than the 'position delta' . I think 'so.send()' is more reliable and timely for control and events. Use the props of the so for everything else.

ďż˝

Using so.send is very timely so many cases you can use the player clock. Duplicate the math that the server is doing�within the client. Using your favorite tween lib, you tween the local to the global.

ďż˝

Seems to me, if the server is setting the values to the so, then it could probably perform an 'so send' to insure instant delivery.

ďż˝

You have really got me curious about how the flv feeder would do at 24 fps. I have done video at 40fps so I know�red5 can pipe it. Can the flv framework invokes�do it too? hrmmmm..

ďż˝

How many class objects does it take to get to the center of a tootsie pop?

ďż˝

ďż˝

Andy

ďż˝

ďż˝

ďż˝

ďż˝

ďż˝

[Andy Shaules]

Excellent!

 

Sounds like too many over complicated clips.

 

You may find that replacing your clips with static sprites would enable the client to keep up.

 

I have found that running a sim and correcting with server values is the smoothest animation when showing physics. ( air planes, cars, tanks). Although there is a steady stream of messages from the server, there is no steady rate implied, so you might get events stacked up on a slow client which try to execute as fast as possible.  

 

It is unfortunate you are pressured with such short time and budget in the area of shared physics sim. It can take many many hours to get it smooth and synced on both slow and fast cpus.

 

I cannot count the hundreds and hundreds of hours I've tried to do so, or can I remeber all the way's I have tried.

 

Best bet is so's, local tweened sim, and reasonable graphics. Scale the x/y/z co-ord system so that the sim interpolation is always close or within the display size of the graphics.

 

Andy

----- Original Message -----

From: Łukasz Groszkowski

To: red5in...@googlegroups.com

Sent: Tuesday, September 21, 2010 11:24 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Good news!
Thanks to your advices I've optimized my code to use SO for control. Now the game works smoothly. There are some other issues anyway. I am going to implement these motion tweens for smoothing animations, due my client started to press on this. In fact I don't know what is worse: jumpy animation or seeing something in wrong place, never mind. Also he started to press for migration to SmartFox. I have absolutely no clue about SmartFox, and so I'll try to stick to red5.

Again: Big thanks. If you can rally me a bit how to make these motion tweens I'd be grateful. Currently my application receives at say more-less constant rate Shared Object SYNC event with new coordinates and rotation for each plane. Should I do something like tweening the move over the time of update period? I'd like to avoid using local sim.

Oh, and also a question: there were some problems regarding flash player it self. Its not due network but probably due large number of generated clips: if there are plenty (40, 80) clips of 30 frame vector smoke tween anim, would it better for the app to make this smoke png?

Thanks for help! You're the best! 

W dniu 2010-09-18 17:50, Andy Shaules pisze:

In a jumpy network for the slow connected player, he could never make aim or see his plane fly in a normal path. Plus you try to set the graphics larger than the 'position delta' . I think 'so.send()' is more reliable and timely for control and events. Use the props of the so for everything else.

 

Using so.send is very timely so many cases you can use the player clock. Duplicate the math that the server is doing within the client. Using your favorite tween lib, you tween the local to the global.

 

Seems to me, if the server is setting the values to the so, then it could probably perform an 'so send' to insure instant delivery.

 

You have really got me curious about how the flv feeder would do at 24 fps. I have done video at 40fps so I know red5 can pipe it. Can the flv framework invokes do it too? hrmmmm..

 

How many class objects does it take to get to the center of a tootsie pop?

 

 

Andy

 

 

 

 

 

 

----- Original Message -----

From: Łukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Andy Shaules

Sent: Saturday, September 18, 2010 8:35 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Yeah, Andy - I got you: when I meant about sending keyUp, keyDown events I meant that to send exactly as you said: only start and end of action. Anyway so far I haven't expected jumpy animations, but I cannot exclude that from product version. How could I make tweens from position to position if I don't know the time between SYNC events reaching client and new positions? And I think making local situation could mislead some users aiming at their targets. Well anyway I'll think about it. Thanks for advice.

W dniu 2010-09-18 17:27, Andy Shaules pisze:

Hello,

 

Yup, those are not restrictions imposed by red5. Those are restrictions imposed by the network. Buy another server and refactor your game code, you will be in the exact same boat, but out of more money. The problem is simple, and two fold.

 

1) When a user is pressing a key and holding it, why would you send repeated signals, when a single 'on' and single 'off' can be sent? Shared object do this automatically if the property gets dirty locally. They only send changes, and only at a specified 'frame rate' so rapid changes may not go through. When it 'must' get through, use so.send(); 

 

2) The jumpy animations are from taking the data as it comes, which may or may not be regular, so a game-view may not be synchronized. Best results seem to come from running a local sim that is gently/tween corrected by the real server sim. Another compelling reason to use flv cue points for transmission is cue through time.

 

 

 

Andy

----- Original Message -----

From: Łukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Trevor Burton

Sent: Saturday, September 18, 2010 3:08 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

So far big thanks for help. Thanks to your I have at least some ideas how to try solving the situation and I'm more aware of restrictions imposed by red5. I still have hope that my optimization will suffice and the game will go to production phase. Currently they released it as beta >.< without complete testing I asked for.

W dniu 2010-09-18 12:03, Trevor Burton pisze:

yes, other servers *should* show the same restrictions. 

Some points to mention to your client/employer:

Because tcp traffic is 'reliable' there's all sorts of stuff going on to make sure packets arrive and that they arrive in order. This is why you see 'fast twitch' multiplayer games using UDP as the basis for their network layers - with UDP you can just process packets as they arrive and drop them if they're out of order.. Bang, you're done... makes like easier.

Yes, FMS now support RTMFP which is based on UDP but it's encrypted which adds a load of overhead and it's restricted to 30 (i think) users in the dev version - you'd need around $55k to get an enterprise version - so you could mention that to your client.

smart fox uses XMLSocket (i think, someone here should correct me if i'm wrong) so that will be slower than the AMF serialisation that's being used to communicate with Red5 and more data will be sent over the connection (AMF is a pretty compact beast)

Basically there's no reason why Red5 should not have been your first choice for a multiplayer game... the problems you're experiencing are due to the fact that the Flash Player can't support the sort of network load your game design seems to demand. So either the design has to change somewhere or you have to change platform

my 2 cents 

keep hitting the list for advice... it's always nice to see people trying to push what Red5 can do... just a shame when you're under the cosh from work to do it :)

T

2010/9/18 Łukasz Groszkowski <lukasz.gr...@gmail.com>

I guess that other servers (FMS, SmartFox) will have the same problems, right? Since you said its the protocol problem, not server... I need to say something to my employer about that, he starts to claim that I did wrong choosing red5, but now I think that the whole project is very risky by its terms and requirements.

Since the game is developed I'll optimize the things and just forward it to the testing team. They should take care of the load tests and such. Oh, and the memory and processor load haven't changed much when many games were on - say just 0.5% increment per game of processor use and about the same value for memory.

About the animations - well as it's a kind of fraud-proof mechanism it will be hard to omit it. So far there were no serious problems with animations while testing the game even by 8 players. The SYNC events seems to stack in the client if client's ping is to high, so then it's the classic lag choke animation, but as I wrote before - it's up to users to have good connection for the game.

W dniu 2010-09-18 11:35, Trevor Burton pisze:

I think expecting your network updates to drive your animation is going to cause problems... they'll never arrive in an even manner, i strongly suggest using some sort of 'easing' to make the animation look smooth otherwise it's going to be choppy and poor.

How do you know there'll be enough resource to run that many games? I'd be very wary of making an assumption like that until i'd done some load testing.

It would be worth you spending some time writing a test harness that'll send some randomly generated game objects to your server, you can then ramp up the rates you send and receive and monitor your server to see how it handles it in terms of memory and processor load. Then you'll know for sure whether it's worth investing the time in actually writing the rest of the game or if you need to do more work on the network layer.

As for using instances of Red5 on the same machine i can't say, i've never tried it or worked with anyone who's used it that way so i couldn't give you any sort of reliable answer, sorry.

2010/9/18 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Hmm.. well so maybe I can reduce to say 12fps. I don't want to make animations look poor. Anyway, I want first of all to make this thing work. Currently when the game was tested with say 8 players, the Flash Player did not crash (but only if one game was running on the server, otherwise the players were unable to maneuver the planes - too many invoke calls I guess), so I hope that this will suffice. The game was playable and no problems were detected until another full game was launched on the server. I think that if I perform all this optimization, there should be enough resources to run say 5-10 games simultaneously which in fact is my goal.

On the other hand, how about launching say 5 virtual red5 servers on the server machine with different IP's and assigning clients to them? I don't need all game rooms to be in the same server, since the user verification and other things are done by other means. Maybe it sounds crazy but since I don't really care about physical resources of machine, maybe that would solve some issues. What do you think?

W dniu 2010-09-18 11:17, Trevor Burton pisze:

The problem is you're operating over an HTTP connection - the overhead involved means that sending 24 updates a second to the server is going to cause problems when you have more than a few players... If you were using a lightweight networking protocol built on top of UDP then 24-30 game packets a second would be acceptable. 

Red5 can work with UDP but the Flash Player can't.

Also, receiving more than a few shared object updates a second is going to crash the flash player - i know, i've hit this problem before. Batching was what got me around it. I receive the same number of updates, but they're batched, i get them less often and i play through them so it 'looks' as if they're arriving in a constant stream.

This does seem like a case where Andy's streaming approach could help you - i'm not sure about the sort of frequency of updates it can cope with but if absolutely have to have that level of frequency of updates then i don't think Shared Objects are going to cut it so it might be your only option.

Sorry if this sounds harsh but the platform and networking protocols you're working with just weren't designed for this sort of use - if the Flash Player supported UDP outside of AIR then you might be ok :(

T

2010/9/18 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Yeah, I see your point. When user will be pressing repetitively space to fire more bullets then such situation could occur. However, how I can batch such events and to make it transparent? I mean, that if I assume to check this batch event holder every 1/24 sec (because it's the highest frequency that would be used in game) it would be almost as bad as current situation. Of course I would send only if there would be something, but in case of hammering the keys it becomes the same. Well I guess that key events can be dispatched at higher rate then framerate, but it seems unlikely in 24fps, but I'll make a safety restriction, not to pass more SO changes. I just don't want users to have the feeling that they are "planning" their movements in advance.

Using one SO would really reduce the server load? Well currently I have kind of clear structure and making just one large SO would mess my things up. But if my above optimizations won't be enough I guess I'll have to do it as well. Hmm... on the other hand - I also see the point - each plane is updated and SYNC's with client and this is way less efficient if there were just one SO for all objects in game. However I think keeping separate shared objects for controlling planes would be necessary. I don't want to SYNC everybody when any of players presses a key. So instead of 8 + 8 + 1 SO for game I'd have only 9 total. Seems much better. 

W dniu 2010-09-18 09:50, Trevor Burton pisze:

Well, you could just use a single SO per game and just set parameters on that rather than using one per object/parameter.

I'd still be inclined to batch the key events - otherwise if someone hammers the keyboard and you're sending EVERY event you're going to get some problems. Set a maximum rate, push the events into a batch and then check the batch at some rate, if there's anything in there, send it.

It's long overdue for this sort of knowledge to be collected and put in a wiki somewhere (or something) but there aren't many of us that do this sort of thing and we're all busy (which is both good AND bad).. must get around to it at some point.

T

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Now I feel little lost: why call frequency will be growing exponentially? Moreover - each game will take about 2-3 minutes. If I have 8 players, there will be 8 SO for planes representations, 8 SO for user interaction and a SO for projectiles (containing 3 arrays x, y, r). Each player will be SYNC only to 10 SO totally (assuming full game). Each of the 8 planes SO will be updated 24/sec and if clients can make it they'll feel the lags. About the user interaction SO, they wont be in sync on the client side, only on the server (in fact the data will be read in the update loop; the value will only change on key events). I thought that such approach would make a more-less fixed number of SO update /sec.

Have I missed something?

W dniu 2010-09-17 22:14, Dominick Accattato pisze:

Yeah, the server can handle this I'm sure of that, but the bottleneck is that each client will exponentially be getting more and more call frequency. When you think about a typical roundtrip taking an avg of 30-50 ms, then you quickly realize that you will be choking that pipe with chatter.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

And one more aspect: is it okay for serverside calculations to perform say 500 calculations concerning planes (x, y, rotation) per second (I think that this is total amount for full game)? I guess its not really depends on red5 but Java itself. And in fact I can't do much about optimizing this calculations (moving planes, projectiles, gravity etc.). Can you provide me with any clue about this? So far I feel somehow better even thou I screw up in the beginning. :)

W dniu 2010-09-17 21:51, tom pisze:

wow - never did the math myself , but quite impressive math -  and call frequency.
thx

2010/9/17 Dominick Accattato <dacca...@gmail.com>

so you're doing 2-3 calls per frame? How many frames per second are you running the swf? I'm imagining at least 15. That would be 45 calls per second. That can actually grow to be quite expensive as the others have alluded to. For instance, here's a breakdown.

2 players = 90 calls/sec

3 players = 270 calls/sec

4 players = 1,080 calls/sec

...

and you say that your latency requirements are 150ms... i'm still guessing it's due to this. Also remember that a SharedObject is not just sending a number like "22" etc.. it has to send an entire object with status codes etc...

does everyone agree with this or do I have some funny math going on ;)

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

 

 

Framerate averages between 14 and 30 ?

 

That is too expensive.

 

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

 

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

 

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

 

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

 

Looks like a strong case for shared objects.

 

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

 

Andy

 

----- Original Message -----

From: Łukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).  The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 Łukasz Groszkowski <lukasz.gr...@gmail.com>

[Łukasz Groszkowski]

Again, many thanks to my saviors ;).

I've optimized further my app: I'm using currently just 3 shared objects per client (10 shared objects total for 8 player game). I've implemented a very basic sim on client side (using only vx and vy as deltas, no rotation recalculation etc. since this is somehow unreliable in my case). Shared objects of planes/bullets (2 so per game) are synced 24/per frame, but everything seems to run smooth even with bigger number of players.

Maybe my thought will also come handy for someone: one of my client optimization problem was a really obvious one - I've used embedded swf symbol (smoke, explosion) and created movieclip using them. Then I attached enterFrame action to check if currentFrame==framesTotal... well it worked but when I created ~40 of smoke clips 15 frame each, that was way too much for client. Now I use a compiled clip with classes inside, and in each such animation on the last frame is something like if(parent)parent.removeChild(this); and it works much better. I forgot that when using embedded assets (swf symbols) the action script is unavailable. Now I got things to work.

Everything seems to work smooth now. The app is undergoing final tests before release. Currently its still "beta".

Oh, one question: is it okay to do on the serverside something like: SO.setAttribute("plane"+index, planeObject); where planeObject is a class with appropriate getters/setters for delivering properties? Or is there any way more efficient method?

W dniu 2010-09-21 22:15, Andy Shaules pisze:

Excellent!

ďż˝

Sounds like too many over complicated clips.

ďż˝

You may find that replacing your clips with static sprites would enable the client to keep up.

ďż˝

I have found that running a sim and correcting with server values is the smoothest animation when showing physics. ( air planes, cars, tanks). Although there is a steady stream of messages from the server, there is no steady rate implied, so you might get events stacked up on a slow client which try to execute�as fast as possible.��

ďż˝

It is unfortunate you are pressured with such short time and budget in the area of shared physics sim. It can take many many hours to get it smooth and synced�on both�slow and fast cpus.

ďż˝

I cannot count the hundreds and hundreds of hours I've tried to do so, or can I remeber all the way's I have tried.

ďż˝

Best bet is so's, local tweened sim, and reasonable graphics. Scale the x/y/z co-ord system so that the sim interpolation�is always close or within the display size of the graphics.

ďż˝

Andy

----- Original Message -----

From: �ukasz Groszkowski

To: red5in...@googlegroups.com

Sent: Tuesday, September 21, 2010 11:24 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Good news!
Thanks to your advices I've optimized my code to use SO for control. Now the game works smoothly. There are some other issues anyway. I am going to implement these motion tweens for smoothing animations, due my client started to press on this. In fact I don't know what is worse: jumpy animation or seeing something in wrong place, never mind. Also he started to press for migration to SmartFox. I have absolutely no clue about SmartFox, and so I'll try to stick to red5.

Again: Big thanks. If you can rally me a bit how to make these motion tweens I'd be grateful. Currently my application receives at say more-less constant rate Shared Object SYNC event with new coordinates and rotation for each plane. Should I do something like tweening the move over the time of update period? I'd like to avoid using local sim.

Oh, and also a question: there were some problems regarding flash player it self. Its not due network but probably due large number of generated clips: if there are plenty (40, 80) clips of 30 frame vector smoke tween anim, would it better for the app to make this smoke png?

Thanks for help! You're the best!ďż˝

W dniu 2010-09-18 17:50, Andy Shaules pisze:

In a jumpy network for the slow connected player, he could never make aim or see his plane fly in a normal path. Plus you try to set the graphics larger than the 'position delta' . I think 'so.send()' is more reliable and timely for control and events. Use the props of the so for everything else.

ďż˝

Using so.send is very timely so many cases you can use the player clock. Duplicate the math that the server is doing�within the client. Using your favorite tween lib, you tween the local to the global.

ďż˝

Seems to me, if the server is setting the values to the so, then it could probably perform an 'so send' to insure instant delivery.

ďż˝

You have really got me curious about how the flv feeder would do at 24 fps. I have done video at 40fps so I know�red5 can pipe it. Can the flv framework invokes�do it too? hrmmmm..

ďż˝

How many class objects does it take to get to the center of a tootsie pop?

ďż˝

ďż˝

Andy

ďż˝

ďż˝

ďż˝

ďż˝

ďż˝

ďż˝

----- Original Message -----

From: �ukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Andy Shaules

Sent: Saturday, September 18, 2010 8:35 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Yeah, Andy - I got you: when I meant about sending keyUp, keyDown events I meant that to send exactly as you said: only start and end of action. Anyway so far I haven't expected jumpy animations, but I cannot exclude that from product version. How could I make tweens from position to position if I don't know the time between SYNC events reaching client and new positions? And I think making local situation could mislead some users aiming at their targets. Well anyway I'll think about it. Thanks for advice.

W dniu 2010-09-18 17:27, Andy Shaules pisze:

Hello,

ďż˝

Yup, those are not restrictions imposed by red5. Those are restrictions imposed by the network. Buy another server and refactor your game code, you will be in the exact same boat, but out of more money.�The problem is simple, and two fold.

ďż˝

1) When a user is pressing a key and holding it, why would you send repeated signals, when a single 'on' and single 'off' can be sent? Shared object do this automatically if the property gets dirty locally. They only send changes, and only at a specified 'frame rate' so rapid changes may not go through. When it 'must' get through, use so.send();ďż˝

ďż˝

2) The jumpy animations are from taking the data as it comes, which may or may not be regular, so a game-view may not be synchronized. Best results seem to come from running a local sim that is gently/tween corrected by the real server sim. Another compelling reason to use flv cue points for transmission is cue through time.

ďż˝

ďż˝

ďż˝

Andy

----- Original Message -----

From: �ukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Trevor Burton

Sent: Saturday, September 18, 2010 3:08 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

So far big thanks for help. Thanks to your I have at least some ideas how to try solving the situation and I'm more aware of restrictions imposed by red5. I still have hope that my optimization will suffice and the game will go to production phase. Currently they released it as beta >.< without complete testing I asked for.

W dniu 2010-09-18 12:03, Trevor Burton pisze:

yes, other servers *should* show the same restrictions.ďż˝

Some points to mention to your client/employer:

Because tcp traffic is 'reliable' there's all sorts of stuff going on to make sure packets arrive and that they arrive in order. This is why you see 'fast twitch' multiplayer games using UDP as the basis for their network layers - with UDP you can just process packets as they arrive and drop them if they're out of order.. Bang, you're done... makes like easier.

Yes, FMS now support RTMFP which is based on UDP but it's encrypted which adds a load of overhead and it's restricted to 30 (i think) users in the dev version - you'd need around $55k to get an enterprise version - so you could mention that to your client.

smart fox uses XMLSocket (i think, someone here should correct me if i'm wrong) so that will be slower than the AMF serialisation that's being used to communicate with Red5 and more data will be sent over the connection (AMF is a pretty compact beast)

Basically there's no reason why Red5 should not have been your first choice for a multiplayer game... the problems you're experiencing are due to the fact that the Flash Player can't support the sort of network load your game design seems to demand. So either the design has to change somewhere or you have to change platform

my 2 centsďż˝

keep hitting the list for advice... it's always nice to see people trying to push what Red5 can do... just a shame when you're under the cosh from work to do it :)

T

2010/9/18 �ukasz Groszkowski <lukasz.gr...@gmail.com>

I guess that other servers (FMS, SmartFox) will have the same problems, right? Since you said its the protocol problem, not server... I need to say something to my employer about that, he starts to claim that I did wrong choosing red5, but now I think that the whole project is very risky by its terms and requirements.

Since the game is developed I'll optimize the things and just forward it to the testing team. They should take care of the load tests and such. Oh, and the memory and processor load haven't changed much when many games were on - say just 0.5% increment per game of processor use and about the same value for memory.

About the animations - well as it's a kind of fraud-proof mechanism it will be hard to omit it. So far there were no serious problems with animations while testing the game even by 8 players. The SYNC events seems to stack in the client if client's ping is to high, so then it's the classic lag choke animation, but as I wrote before - it's up to users to have good connection for the game.

W dniu 2010-09-18 11:35, Trevor Burton pisze:

I think expecting your network updates to drive your animation is going to cause problems... they'll never arrive in an even manner, i strongly suggest using some sort of 'easing' to make the animation look smooth otherwise it's going to be choppy and poor.

How do you know there'll be enough resource to run that many games? I'd be very wary of making an assumption like that until i'd done some load testing.

It would be worth you spending some time writing a test harness that'll send some randomly generated game objects to your server, you can then ramp up the rates you send and receive and monitor your server to see how it handles it in terms of memory and processor load. Then you'll know for sure whether it's worth investing the time in actually writing the rest of the game or if you need to do more work on the network layer.

As for using instances of Red5 on the same machine i can't say, i've never tried it or worked with anyone who's used it that way so i couldn't give you any sort of reliable answer, sorry.

2010/9/18 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Hmm.. well so maybe I can reduce to say 12fps. I don't want to make animations look poor. Anyway, I want first of all to make this thing work. Currently when the game was tested with say 8 players, the Flash Player did not crash (but only if one game was running on the server, otherwise the players were unable to maneuver the planes - too many invoke calls I guess), so I hope that this will suffice. The game was playable and no problems were detected until another full game was launched on the server. I think that if I perform all this optimization, there should be enough resources to run say 5-10 games simultaneously which in fact is my goal.

On the other hand, how about launching say 5 virtual red5 servers on the server machine with different IP's and assigning clients to them? I don't need all game rooms to be in the same server, since the user verification and other things are done by other means. Maybe it sounds crazy but since I don't really care about physical resources of machine, maybe that would solve some issues. What do you think?

W dniu 2010-09-18 11:17, Trevor Burton pisze:

The problem is you're operating over an HTTP connection - the overhead involved means that sending 24 updates a second to the server is going to cause problems when you have more than a few players... If you were using a lightweight networking protocol built on top of UDP then 24-30 game packets a second would be acceptable.ďż˝

Red5 can work with UDP but the Flash Player can't.

Also, receiving more than a few shared object updates a second is going to crash the flash player - i know, i've hit this problem before. Batching was what got me around it. I receive the same number of updates, but they're batched, i get them less often and i play through them so it 'looks' as if they're arriving in a constant stream.

This does seem like a case where Andy's streaming approach could help you - i'm not sure about the sort of frequency of updates it can cope with but if absolutely have to have that level of frequency of updates then i don't think Shared Objects are going to cut it so it might be your only option.

Sorry if this sounds harsh but the platform and networking protocols you're working with just weren't designed for this sort of use - if the Flash Player supported UDP outside of AIR then you might be ok :(

T

2010/9/18 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Yeah, I see your point. When user will be pressing repetitively space to fire more bullets then such situation could occur. However, how I can batch such events and to make it transparent? I mean, that if I assume to check this batch event holder every 1/24 sec (because it's the highest frequency that would be used in game) it would be almost as bad as current situation. Of course I would send only if there would be something, but in case of hammering the keys it becomes the same. Well I guess that key events can be dispatched at higher rate then framerate, but it seems unlikely in 24fps, but I'll make a safety restriction, not to pass more SO changes. I just don't want users to have the feeling that they are "planning" their movements in advance.

Using one SO would really reduce the server load? Well currently I have kind of clear structure and making just one large SO would mess my things up. But if my above optimizations won't be enough I guess I'll have to do it as well. Hmm... on the other hand - I also see the point - each plane is updated and SYNC's with client and this is way less efficient if there were just one SO for all objects in game. However I think keeping separate shared objects for controlling planes would be necessary. I don't want to SYNC everybody when any of players presses a key. So instead of 8 + 8 + 1 SO for game I'd have only 9 total. Seems much better.ďż˝

W dniu 2010-09-18 09:50, Trevor Burton pisze:

Well, you could just use a single SO per game and just set parameters on that rather than using one per object/parameter.

I'd still be inclined to batch the key events - otherwise if someone hammers the keyboard and you're sending EVERY event you're going to get some problems. Set a maximum rate, push the events into a batch and then check the batch at some rate, if there's anything in there, send it.

It's long overdue for this sort of knowledge to be collected and put in a wiki somewhere (or something) but there aren't many of us that do this sort of thing and we're all busy (which is both good AND bad).. must get around to it at some point.

T

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Now I feel little lost: why call frequency will be growing exponentially? Moreover - each game will take about 2-3 minutes. If I have 8 players, there will be 8 SO for planes representations, 8 SO for user interaction and a SO for projectiles (containing 3 arrays x, y, r). Each player will be SYNC only to 10 SO totally (assuming full game). Each of the 8 planes SO will be updated 24/sec and if clients can make it they'll feel the lags. About the user interaction SO, they wont be in sync on the client side, only on the server (in fact the data will be read in the update loop; the value will only change on key events). I thought that such approach would make a more-less fixed number of SO update /sec.

Have I missed something?

W dniu 2010-09-17 22:14, Dominick Accattato pisze:

Yeah, the server can handle this I'm sure of that, but the bottleneck is that each client will exponentially be getting more and more call frequency. When you think about a typical roundtrip taking an avg of 30-50 ms, then you quickly realize that you will be choking that pipe with chatter.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

And one more aspect: is it okay for serverside calculations to perform say 500 calculations concerning planes (x, y, rotation) per second (I think that this is total amount for full game)? I guess its not really depends on red5 but Java itself. And in fact I can't do much about optimizing this calculations (moving planes, projectiles, gravity etc.). Can you provide me with any clue about this? So far I feel somehow better even thou I screw up in the beginning. :)

W dniu 2010-09-17 21:51, tom pisze:

wow - never did the math myself , but quite impressive math -ďż˝ and call frequency.
thx

2010/9/17 Dominick Accattato <dacca...@gmail.com>

so you're doing 2-3 calls per frame? How many frames per second are you running the swf? I'm imagining at least 15. That would be 45 calls per second. That can actually grow to be quite expensive as the others have alluded to. For instance, here's a breakdown.

2 players = 90 calls/sec

3 players = 270 calls/sec

4 players = 1,080 calls/sec

...

and you say that your latency requirements are 150ms... i'm still guessing it's due to this. Also remember that a SharedObject is not just sending a number like "22" etc.. it has to send an entire object with status codes etc...

does everyone agree with this or do I have some funny math going on ;)

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

No, I don't want to give the local-play impression to clients. If they lag - it's theirs problem. The game has built-in ping limit that kicks players of higher then 150ms ping and they're notified about this restriction. And I must be certain that every player sees exactly the same thing in the game - so no local calculation to make display is allowed.

Anyway I'm sending this commands right now - like you said "Move Right", "Move Left", but it still may be too much for server to cope with. Please tell me is updating a SO object preferable to calling a method from NetConnection from client side? I'm pretty sure that this solution with shared objects would be much more preferable and reliable anyway. It would greatly reduce total number of calls to server.

Again thanks for help. As I said it is my first project using flash server, and honestly I chosen red5 due it is available at no cost.

Oh and one more issue: would it be okay if I asked you to check my error log from red5? There are some errors I'm not certain of their origin. If you say it's ok, I'll attach this logs, however I'm not accustomed to mailing groups etiquette so I wanted to ask first.

W dniu 2010-09-17 21:14, Trevor Burton pisze:

Yes, you should absolutely only be sending commands to the server 'Move Right', 'Move Left', 'Fire' etc and let the server decide what it should be doing. But if you want to give the players the impressions that they're playing locally and don't want to have to wait for a round-trip before the client sim responds then you'll have to do some calc on the client.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Now honestly I don't see the point in sending deltas and values. Both are numbers and if I'm sending +3 or 33 it does not matter much for request it self. In fact the orders are used to increment or decrement pitch and throttle of planes. Currently at each frame I'm using call from client to server. How about I changed that to values in shared object, like SO.data.pitchDelta= +1, and respectively SO.data.fireBullet = true, SO.data.fireMissle = true, SO.data.throttleDelta = -1. And instead of assigning that values each frame, this values would be only assigned during press/release of keys?

Honestly, these things you wrote me Andy are black magic to me. I'm not asking for explanation since I haven't googled them yet, but I will if this fails. So far BIG THANKS for helping me with this issue. Your brainstorming pointed me to at least an idea how to solve this things. But expect more mails from me.

W dniu 2010-09-17 20:27, Trevor Burton pisze:

I think what Andy means is that you send 'deltas' - that is, the 'changes' in values - regularly then every few seconds send the 'real' values so they can be validated (so any errors can be adjusted for that have built up).

Can you measure how many individual requests are being handled by the server each second when it starts to creak? You can reduce it by sending the message less often and instead of one-at-a-time send them in batches instead. Let the server receive the message and then iterate over them - add a timestamp if you need to so the server knows how far apart they 'should' have been (depends on the type of game you're working with.)

T

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>

Oh, and by the way: the client reads data from shared object. The server alters them to reflect the movement. There are only few requests done on client by server. And in fact only these client "sendOrder" requests are numerous. What do you suggest for limiting them?

"The client invokes
method SendOrder with a param what does client do - and this may happen
very often (1 or even 2 per frame)."

ďż˝

ďż˝

Framerate averages between 14 and 30 ?

ďż˝

That is too expensive.

ďż˝

It appears to me that you should be doing more math on the client and less network packets to transmit changes.

ďż˝

Each client should be running a local simulation, and transmit only velocity changes. Also they should send periodically between one and five seconds, a full set of coordinates and velocities.

ďż˝

Also, the client must return from the doOrder method before you run the invocations from the server for best performance.

ďż˝

I recommend that even the local client does not get their own movement input processed until it is echoed back from the server.

ďż˝

Looks like a strong case for shared objects.

ďż˝

Personally I'd go with the comserver flv stream, with a sprinkling of shared objects.

ďż˝

Andy

ďż˝

----- Original Message -----

From: �ukasz Groszkowski

To: red5in...@googlegroups.com

Cc: Dominick Accattato

Sent: Friday, September 17, 2010 10:04 AM

Subject: Re: [Red5] Red5 Showcase: Flash MMO games

Ok, so troubles are that the application suffers a symptoms similar to lags. Sometimes it seems that red5 does not reflect user interactions. Sometimes it does not permit user to connect to a game room. I'll introduce you to logic of my application briefly:

There are 2 main classes (and some supporting ones, describing objects). Application class using the marvelous red5 eclipse plugin and a GameRoom class. A GameRoom object stores data about planes (class Plane), projectiles (class Projectile) and users. Application stores data of game rooms (and array of GameRoom's).

Upon connect, the client passes id, name, max planes hp, max planes in game. These are used only by first user to set-up GameRoom's properties (that in fact are used later to configure Plane objects).ďż˝ The passed id is used for setting client id (client.setId()) and is also stored in a clients = new HashSet<IClient>() and then used when clients are doing some actions. ... well I'm going to much in details. The client invokes method SendOrder with a param what does client do - and this may happen very often (1 or even 2 per frame). This parametrs alter the properties of plane and this is reflected by moving planes.

Well I could use a volunteer to take a look at the complete code of my game. I'm willing to share some credit for the task, but anyway the whole project is not very expensive.

Thanks for your time

W dniu 2010-09-17 18:32, Dominick Accattato pisze:

what type of troubles are you having. I would of course suggest Red5 as a multiplayer server and the game you mention should impose no real problems.

2010/9/17 �ukasz Groszkowski <lukasz.gr...@gmail.com>