Server capacity for Flash game

A1: You'd want to target Unity/Java. Both allow mouse control. Doing anything in 3D in flash tends to get prohibitively expensive and becomes more of an academic challenge into optimization.

A2: Impossible to answer really. It depends on your server. You're more often I/O bound than CPU bound in most online games.

I'd start small. I get that you want to make a huge game, but with no game programming experience you're going to have to learn the basics first. These kinds of questions you're asking are learned with experience. Pick a language (C#/Python) and buy a beginners book. After you get the basic idea of general programming you can start learning networking by reading this book. Make small games like snake and stuff before jumping into networking. There's a lot of foundation you need to build before tackling a large game. (Oh and don't worry about your beginning language. Once you learn how to program with an imperative language they all look the same).

A1: You'd want to target Unity/Java. Both allow mouse control. Doing anything in 3D in flash tends to get prohibitively expensive and becomes more of an academic challenge into optimization.

A2: Impossible to answer really. It depends on your server. You're more often I/O bound than CPU bound in most online games.

I'd start small. I get that you want to make a huge game, but with no game programming experience you're going to have to learn the basics first. These kinds of questions you're asking are learned with experience. Pick a language (C#/Python) and buy a beginners book. After you get the basic idea of general programming you can start learning networking by reading this book. Make small games like snake and stuff before jumping into networking. There's a lot of foundation you need to build before tackling a large game. (Oh and don't worry about your beginning language. Once you learn how to program with an imperative language they all look the same).

Thanks for quick response. I used several languages before I have programming experience and programming logic , I am just a bit rusty and alien to game programming. And I may not even make game myself or involved a little.

A1: I looked at some Molehill examples (like Zombie Tycoon), they seem nice but Molehill is still in incubator. And unity has no Flash support yet afaik. But still thank you.

A2: I can understand it relies on server but still I don't know if a FPS game with TCP packets on web is achievable with a reasonable server? Or is it possible to use UDP with Unity? If so , it seems that Unity will be natural and sole choice.

A1: I looked at some Molehill examples (like Zombie Tycoon), they seem nice but Molehill is still in incubator. And unity has no Flash support yet afaik. But still thank you.

heh that's pretty cool. I didn't know such an API existed for Flash. Unity can run in its own player so you really don't need flash support.

A2: I can understand it relies on server but still I don't know if a FPS game with TCP packets on web is achievable with a reasonable server? Or is it possible to use UDP with Unity? If so , it seems that Unity will be natural and sole choice.

Yeah TCP can be used for an FPS. It would probably run alright except if a user has packet loss which would then cause intermittent lag spikes. TCP isn't an ideal choice basically. Unity can use UDP. You can find more information on their website.

Actually here just play this (wasd/arrow keys and left mouse). It's a game I made that's been running for a few weeks using WebSockets which is TCP. There is no client-side interpolation for the clients so it should give you a general idea of what just sending position updates looks like.

I can understand it relies on server but still I don't know if a FPS game with TCP packets on web is achievable with a reasonable server? Or is it possible to use UDP with Unity? If so , it seems that Unity will be natural and sole choice.

Both TCP and UDP are good, they just behave differently when network issues occur.


Most of the time both of the protocols are very quick and will give you the expected results. Hardware is robust and the Internet's infrastructure is mature to the point where major route changes are hardly ever necessary. Depending on the nature of your connection you can go for weeks or months before seeing any kind of networking issue. For example your connection across a local network will be very robust, and a virtual LAN may be designed to provide perfect connectivity as long as the connection exists.

As you cross the global Internet there are occasional issues, although they are relatively rare.

The duration of the network issue is roughly the same between them, usually just long enough for the Internet cloud to find a new route between the machines.


Both of them tend to start with a brief stall, followed by recovery.


Under TCP it recovers by automatically resending any missing data. Normally it recovers at the cost of a single additional round trip (normally just a few milliseconds).

Under UDP you will generally see the problem as a pause followed by a combination of dropped packets, duplicate packets, and out-of-order packets. You will likely continue to receive duplicates and reordered packets during the brief network glitch. It is up to your game to recover in a reasonable fashion. Recovery will take as long as your design requires.




The benefit of UDP is that you have control to (hopefully) use some of the data during the glitch, and can potentially continue part of your work with incomplete data.

If you don't want to write your own logic to handle dropped, duplicate, and out-of-order packets, or if you don't think you can do it as efficiently as TCP does, then choosing to let TCP do it for you is probably a wise choice.


I've seen several cases where their manual UDP error detection and recovery routines were worse than those provided by TCP; they had more overhead to maintain than TCP's sliding windows, and took longer to recover from errors. The protocol was written and implemented by experts in the field writing for the general case; you generally need to be an expert in order to do better for your specific case.

Q1 ) Would it be possible to do such thing even with crappy or minecraft level graphics for web? I will prefer to based on Flash so I'll also appreciate if someone has any idea about using Unity or Molehill or Away3D or? Afaik there is no UDP for Flash (except P2P which is not possible in this game)

Yes, 3D games can be developed in 3D APIs. Something running in a web browser will likely run less well than something running in C++ in full screen, say by a factor if 1/2. (The specifics vary)
For Flash, you'd have to wait for their 3D version to actually ship, and then actually be installed by users. Don't know about driver support.
For WebGL, later versions of Firefox and Chrome will actually allow you to do it straight in a HTML Canvas, but a large amount of installed drivers for users are black listed, because the fact that GL drivers suck for regular users was apparently a complete surprise to the Firefox and Chrome teams.
For Unity3D, driver support is good, and browser support is good; the main obstacle is that about 50% of all users will have to download the plugin.

Q2) Real question is how much player this server could handle at the same time in a room? I will need 50-80 except spectators. There are some service providers like player.io , but I am not sure if it is possible. Tbh, I'd not invest in such game only if 10 people will be able to play together.

Thanks in advance and my apologies if question was really retard.
[/quote]

The capacity of the server has almost nothing to do with how the client is implemented. Well, if you use Flash, and use Flash XML RPC methods for multiplayer, then it would, but you shouldn't do that :-) Unity3D is the best choice here, because it supports native game-style networking. With Flash and WebGL, you currently generally have to resort to trying to tunnel game-style packets inside some protocol that's not really intended for that. Depending on latency requirements (Quake 2 style, or Unreal Tournament 2010 style? very different!) this may or may not matter.

The main problem you'll likely run into is that Flash 3D and WebGL do not have physics engines built-in, so you'll have to use some JavaScript based physics engine, which generally will not perform as well as a native C++ engine. Unity3D integrates a native physics engine -- I believe PhysX -- and thus will perform better on the client.
On the server, you have the option of running the same simulation (uses lots of CPU per player, makes it harder to cheat), do rough correctness estimation of client-provided data (makes it somewhat hard to do gross cheating), or just trust the client (makes cheating easier). On a "typical" server with a "native" physics engine, I'd expect >200 players per server to be quite possible, assuming you have the right bandwidth. Note that clients generally can't handle that many players -- you'd either need some interest management area-of-view, or split the players on more, smaller maps, say 50 each. If you use simple rules-checking, or no rules-checking at all, these numbers go up by a factor of 10, or even possibly 100. (20,000 players connected to one machine, when all they do is forward messages to each other in clumps of 50, is totally doable).

Note that, when provisioning servers, you want to get *real hardware*. The cloud and virtualized options add too much jitter because of the virtualization to be useful for real-time applications like game physics.

Regarding investments: I'd expect > 50% of the effort to be spent on building art and gameplay for the game; 25% to be spent on getting the networking and server infrastructure right; and the final 25% spent on game programming, engine flinging, client integration, and any other programming tasks. These are very rought, and assume that each of the teams know what they're doing. Any team that doesn't know what it's doing will need to double resources, and aim low, and ship early, and then throw away what they did and start over once they know what they're doing :-)

[quote name='Choisir' timestamp='1305044771' post='4809018']
Q1 ) Would it be possible to do such thing even with crappy or minecraft level graphics for web? I will prefer to based on Flash so I'll also appreciate if someone has any idea about using Unity or Molehill or Away3D or? Afaik there is no UDP for Flash (except P2P which is not possible in this game)

Yes, 3D games can be developed in 3D APIs. Something running in a web browser will likely run less well than something running in C++ in full screen, say by a factor if 1/2. (The specifics vary)
For Flash, you'd have to wait for their 3D version to actually ship, and then actually be installed by users. Don't know about driver support.
For WebGL, later versions of Firefox and Chrome will actually allow you to do it straight in a HTML Canvas, but a large amount of installed drivers for users are black listed, because the fact that GL drivers suck for regular users was apparently a complete surprise to the Firefox and Chrome teams.
For Unity3D, driver support is good, and browser support is good; the main obstacle is that about 50% of all users will have to download the plugin.

Q2) Real question is how much player this server could handle at the same time in a room? I will need 50-80 except spectators. There are some service providers like player.io , but I am not sure if it is possible. Tbh, I'd not invest in such game only if 10 people will be able to play together.

Thanks in advance and my apologies if question was really retard.
[/quote]

The capacity of the server has almost nothing to do with how the client is implemented. Well, if you use Flash, and use Flash XML RPC methods for multiplayer, then it would, but you shouldn't do that :-) Unity3D is the best choice here, because it supports native game-style networking. With Flash and WebGL, you currently generally have to resort to trying to tunnel game-style packets inside some protocol that's not really intended for that. Depending on latency requirements (Quake 2 style, or Unreal Tournament 2010 style? very different!) this may or may not matter.

The main problem you'll likely run into is that Flash 3D and WebGL do not have physics engines built-in, so you'll have to use some JavaScript based physics engine, which generally will not perform as well as a native C++ engine. Unity3D integrates a native physics engine -- I believe PhysX -- and thus will perform better on the client.
On the server, you have the option of running the same simulation (uses lots of CPU per player, makes it harder to cheat), do rough correctness estimation of client-provided data (makes it somewhat hard to do gross cheating), or just trust the client (makes cheating easier). On a "typical" server with a "native" physics engine, I'd expect >200 players per server to be quite possible, assuming you have the right bandwidth. Note that clients generally can't handle that many players -- you'd either need some interest management area-of-view, or split the players on more, smaller maps, say 50 each. If you use simple rules-checking, or no rules-checking at all, these numbers go up by a factor of 10, or even possibly 100. (20,000 players connected to one machine, when all they do is forward messages to each other in clumps of 50, is totally doable).

Note that, when provisioning servers, you want to get *real hardware*. The cloud and virtualized options add too much jitter because of the virtualization to be useful for real-time applications like game physics.

Regarding investments: I'd expect > 50% of the effort to be spent on building art and gameplay for the game; 25% to be spent on getting the networking and server infrastructure right; and the final 25% spent on game programming, engine flinging, client integration, and any other programming tasks. These are very rought, and assume that each of the teams know what they're doing. Any team that doesn't know what it's doing will need to double resources, and aim low, and ship early, and then throw away what they did and start over once they know what they're doing :-)
[/quote]

Then considering the fact that Molehill will be available in an unforeseen future without game APIs and Unity3D is right now available and will have Flash support , it is wiser to prefer Unity3D. As I said I am not looking for state-of-the art graphics but a smooth multiplayer experience.

As I haven't seen any example around beyond 12-16 players, I just wondered if 50 to 80 is not feasible. Because it seems that data flow and bandwidth usage increases exponentially.

As I haven't seen any example around beyond 12-16 players, I just wondered if 50 to 80 is not feasible. Because it seems that data flow and bandwidth usage increases exponentially.

Of course. More accurately, n*(n-1), which is almost n squared.

But this has nothing to do with API and all with design. If n-by-n interactions are required, then there is no way around it. So design must take that into account and try to steer away from worst case.

16 or thereabout has long been the pinnacle of multiplayer for precisely this reason. Going beyond that requires switching to "MMO mode", which uses completely different design and expects interactions in the range of 1 per second. Even then much can be faked.

Of course, one could also show that 300ms latency is sufficient even for a FPS, considering the success of console shooters, where such latency may be present even in single player. But they all adapted to this and changed gameplay.

CS, Quake or similar models however will not work. WoW has one worst multiplayer systems I've ever seen with effective latency of up to two seconds (all this at <50ms reported latency), random ordering issues and absurd inconsistencies, but it simply doesn't matter, not even for competitive play. If you read reviews, they'll say it's "smooth" and "polished".

In the end it's always about smoke and mirrors.

[quote name='Choisir' timestamp='1305067744' post='4809168']
As I haven't seen any example around beyond 12-16 players, I just wondered if 50 to 80 is not feasible. Because it seems that data flow and bandwidth usage increases exponentially.

Of course. More accurately, n*(n-1), which is almost n squared.

But this has nothing to do with API and all with design. If n-by-n interactions are required, then there is no way around it. So design must take that into account and try to steer away from worst case.

16 or thereabout has long been the pinnacle of multiplayer for precisely this reason. Going beyond that requires switching to "MMO mode", which uses completely different design and expects interactions in the range of 1 per second. Even then much can be faked.

Of course, one could also show that 300ms latency is sufficient even for a FPS, considering the success of console shooters, where such latency may be present even in single player. But they all adapted to this and changed gameplay.

CS, Quake or similar models however will not work. WoW has one worst multiplayer systems I've ever seen with effective latency of up to two seconds (all this at <50ms reported latency), random ordering issues and absurd inconsistencies, but it simply doesn't matter, not even for competitive play. If you read reviews, they'll say it's "smooth" and "polished".

In the end it's always about smoke and mirrors.
[/quote]

My apologies due to my lack of English. I didn't really get that you say if it is possible or not. There may be workarounds but goal is clear

I consider a project where people have own parties of 30-40 members and will fight each other on a map. I could try separating map zones but simply can't say party members not to be together. and there will not be only one 'room', maybe tens of rooms at the same time.

Btw 80 seems a bit much as even battlefield 3 allows 64 at LAN. maybe 25-25 ie 50 will be wiser.

Btw 80 seems a bit much as even battlefield 3 allows 64 at LAN. maybe 25-25 ie 50 will be wiser.

Planetside did 500 players per map in 2003.
MAG did 256 players per map in 2009. (or 2010? I forget)
I believe both of those are still running games, so you can buy them and try them out and see if it's something you like.

Sincerely,

jw