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?
> 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?
----- Original Message ----- From: Dominick Accattato To: red5interest@googlegroups.com Sent: Friday, September 17, 2010 9:32 AM Subject: Re: [Red5] Red5 Showcase: Flash MMO games
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.
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?
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.
> 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?
"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.
----- Original Message ----- From: Łukasz Groszkowski To: red5interest@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.
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?
> 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?
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.
> "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 <mailto:lukasz.groszkow...@gmail.com> > *To:* red5interest@googlegroups.com > <mailto:red5interest@googlegroups.com> > *Cc:* Dominick Accattato <mailto:daccatt...@gmail.com> > *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.
>> 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?
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 <mailto:lukasz.groszkow...@gmail.com> > *To:* red5interest@googlegroups.com > <mailto:red5interest@googlegroups.com> > *Cc:* Dominick Accattato <mailto:daccatt...@gmail.com> > *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.
>> 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?
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.)
> 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 <lukasz.groszkow...@gmail.com> > *To:* red5interest@googlegroups.com > *Cc:* Dominick Accattato <daccatt...@gmail.com> > *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.
>> 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?
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.
----- Original Message ----- From: Trevor Burton To: red5interest@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.)
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: red5interest@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.
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?
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.
> 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.)
> 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 <mailto:lukasz.groszkow...@gmail.com> >> *To:* red5interest@googlegroups.com >> <mailto:red5interest@googlegroups.com> >> *Cc:* Dominick Accattato <mailto:daccatt...@gmail.com> >> *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.
>>> 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
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.
> 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.
> 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.)
>> 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 >>> <mailto:lukasz.groszkow...@gmail.com> >>> *To:* red5interest@googlegroups.com >>> <mailto:red5interest@googlegroups.com> >>> *Cc:* Dominick Accattato <mailto:daccatt...@gmail.com> >>> *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.
>>>> 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
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 :)
> 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.
>> 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.)
>>> 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 <lukasz.groszkow...@gmail.com> >>> *To:* red5interest@googlegroups.com >>> *Cc:* Dominick Accattato <daccatt...@gmail.com> >>> *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.
>>>> 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
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.
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 ;)
> 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.
>> 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.)
>>> 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 <lukasz.groszkow...@gmail.com> >>> *To:* red5interest@googlegroups.com >>> *Cc:* Dominick Accattato <daccatt...@gmail.com> >>> *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.
>>>> 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
----- Original Message ----- From: Trevor Burton To: red5interest@googlegroups.com Sent: Friday, September 17, 2010 12:30 PM Subject: Re: [Red5] Red5 Showcase: Flash MMO games
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 :)
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.
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.)
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: red5interest@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.
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?
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.
> 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 ;)
> 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.
>> 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.)
>>> 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 >>>> <mailto:lukasz.groszkow...@gmail.com> >>>> *To:* red5interest@googlegroups.com >>>> <mailto:red5interest@googlegroups.com> >>>> *Cc:* Dominick Accattato <mailto:daccatt...@gmail.com> >>>> *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
> 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.
> 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 ;)
>> 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.
>>> 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.)
>>>> 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 <lukasz.groszkow...@gmail.com> >>>> *To:* red5interest@googlegroups.com >>>> *Cc:* Dominick Accattato <daccatt...@gmail.com> >>>> *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.
>>>>> 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
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. :)
> 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.
> 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 ;)
> 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.
>> 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.)
>>> 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 >>>> <mailto:lukasz.groszkow...@gmail.com> >>>> *To:* red5interest@googlegroups.com >>>> <mailto:red5interest@googlegroups.com> >>>> *Cc:* Dominick Accattato >>>> <mailto:daccatt...@gmail.com> >>>> *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
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.
> 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
>> 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.
>> 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 ;)
>>> 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.
>>>> 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.)
>>>>> 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 <lukasz.groszkow...@gmail.com> >>>>> *To:* red5interest@googlegroups.com >>>>> *Cc:* Dominick Accattato <daccatt...@gmail.com> >>>>> *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.
>>>>>> 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
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.
> 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
>> 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.
>> 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 ;)
>> 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.
>>> 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.)
>>>> 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
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.
> 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.
>> 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
>>> 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.
>>> 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 ;)
>>>> 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.
>>>>> 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.)
>>>>>> 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 <lukasz.groszkow...@gmail.com> >>>>>> *To:* red5interest@googlegroups.com >>>>>> *Cc:* Dominick Accattato <daccatt...@gmail.com> >>>>>> *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
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.
> 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.
> 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.
>> 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
>>> 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.
>>> 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 ;)
>>> 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.
>>>> 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
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.
> 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 :)
> 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.
>> 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 :(
>>> 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.
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.
----- Original Message ----- From: Łukasz Groszkowski To: red5interest@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 :)
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.
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 :(
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
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.
> 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 <mailto:lukasz.groszkow...@gmail.com> > *To:* red5interest@googlegroups.com > <mailto:red5interest@googlegroups.com> > *Cc:* Trevor Burton <mailto:worldofpa...@googlemail.com> > *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 :)
>> 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.
>>> 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 :(
