Though we still don't know what the "1, 4, 10" room thing is all about

[quote:3upa4pqv]peers can only handle 15 other peers connected because host collects info from peers and broadcasts to peers and peers broadcast to peers via host...

I believe this is inaccurate ; we've run the numbers already - but while bandwidth requirement is exponential on the host/server, quadratic O(n^2), it's only linear on the peers O(n).

Since peers don't connect to other peers directly and only send/receive data to/via the host, peers only send data about themselves and only receive 1 update about other peers.

Session with N peers - n bytes of data per peer to store their status. Size of the data to describe the entire "world" = N*n bytes

Peer : sends n bytes to the host ; receives N*n bytes of world update

Host : sends N*N*n bytes (broadcast the world update to all the peers) ; receives N*n bytes (peer updates)

If peer download bandwidth is the limiting factor, I think there are bigger issues to sort at the architecture level than room sizes !

[quote:3rxtlxru]The number of player in each room depends on the host connection

Sorry, I must be missing something - I am probably just confused but I thought from previous discussions you didn't want a player to be the host ("I don't want to use a player as the host"). So why would it depend on anything else than the infrastructure and bandwidth you provide

Btw, if I may ask, are you working on your creations full-time ("pro" activity), or in your spare time ("amateur"-style, which doesn't exclude a game-creation-related full-time job / freelance) ?

[quote:cumh8n6x]Team 7Soul - designer and artist

Enough said, I'm sold ! (my apologies to the programmer, I don't know him -yet-, but that's definitely a familiar name ! )

I discovered your work a while ago when looking for pixel art resources on DeviantArt and OpenGameArt - I am a huge fan and I was delighted to be able to buy your asset packs when they were made available for commercial use.

Copy Girl looks amazing ! I *love* Megaman- or Metroidvania games, I can't wait to play yours

+1 ; most of my groups are for organisation purposes only as well

[quote:2823bbuw]Do you think i can make the server outside of the actual game? A different project

The C2 project is where you define the objects to synchronise, what to synchronise, and the format of the data. Then C2 handles it all under the hood for you.

If you don't do that, it means you'll end up fighting the system more than using it.

It doesn't mean it's not doable (I'm sure DuckfaceNinja has some clever tricks to share ), it means it'll be counter-productive. You still have the option of web sockets. But when talking "easy" C2 multiplayer, think "Risk of Rain", not "Realm of the Mad God", for example.

As for a standalone "server", if you have the knowledge to analyse the C2 marshalling to write a separate system that will interact with a C2 peer or multiplayer-enabled object, you have the knowledge to write your entire system altogether, which would be easier in the first place as you wouldn't need to fight the existing structure. Though we're talking significant amount of work for a veteran networking programmer.

C2 is designed to fast productivity for simple games. If it's not saving you time, you're not using the right tool.

"can we make a standalone node-webkit (or browser) build and use it only for sending and receiving infos?"

It can be the same C2 project, with significantly different event sheets, depending on being the host or a peer ; then you can ensure your instance is the host, by having it join the session/room first using the Scirra signalling service.

Your "host" events would :

• interface with the database, to read/write centralised data
• receive inputs from peers
• run critical gameplay logic
• broadcast updates to all peers

The peers "just" send user inputs, display the world based on the host updates, and run non-critical logic (visual effects, animations, etc.)

Bandwidth issues remain though, and you still need your host on a box with a big pipe if you need to handle lots of peers and data.

If you know the details of your project, it's "easy" to calculate how much bandwidth you need (or at least get a good estimate). Just be aware it grows very quickly.

With the C2 built-in host/peer model, you can ensure "your" instance is running as the host ; the console is irrelevant and does not reduce or increase the complexity of the networking problem.

There are several questions that can be discussed separately, as there is little overlap.

1. Console. It's a nicety, and shines in automated/scripted environments to be able to pass/process complex commands, but in the end it's only an interface to the underlying systems. If you need an actual console for low-level management of objects/sessions, C2 might not be the best choice. C2 gives maximum productivity when working at high-level, on entities, behaviours and events.

2. Data management. There are some good tutorials to get C2 to interact with a remote SQL database. Beyond that, it all depends on your projects. Your specifications need to be analysed to deduce a relevant set of data structures, tables, interfaces, queries, etc.

3. Bandwidth. As the previous posts mention, the user connection if the limiting factor. C2 provides a built-in host/peers architecture, not a server/client ; subtle difference.

"the server hosted by someone should be able to handle more than 100+ players"

If a user is hosting the session, we can break it down and analyse what it means in terms of bandwith. A typical ADSL2+ connection gives you a 800kbits/s upstream bandwidth. 100kbytes/s, that's the maximum hard-limit to play with. What follows is a bit simplified, but gives an idea of the order of magnitude of the problem.

Also, bandwidth requirement is exponential (more players = more data to send to more peers, see mutliplayer tutorials 1 Concepts page 9)

Say you have 100 peers controlling a sprite that moves around smoothly on a shared map. You need at least a position (x,y) that we'll encode into 4 bytes (2 16b floats or int). The state of the game requires 400 bytes (position of all of the players). At an update rate of 15fps to be conservative, that's already : 400 bytes data x 100 peers * 15fps updates = 600kbytes. Way above what a home-user connection can handle.

Even if we're clever (less updates, better packing, partial prediction, etc.) and save a factor 10x, that's still more than 50% of the bandwidth and the players are not doing much yet.

It's very different if you have 100 players in a turn-based grid layout. Or if you have a dedicate host and a much larger connection.

But bandwidth is the limiting factor. There's no software technology or plugin around it, it's a technical hard limit. Basically, it's very hard to give specific advice without more infos about the specifications of the project, but "large scale multiple" and "user hosted" don't work well together.

[quote:2hjk33ff]There are things that you can let the peer to process

Definitely ! Usually, when cutting it down to the core critical gameplay logic, there isn't that much in terms of processing that needs to be happening on a dev-controlled server/host.

Though if the idea is to go with the suggested scenario (i.e. 1 host handling multiple game sessions in parallel, every player is a peer), I'll want to have realistic estimates for min/max bandwidth bounds (i.e. knowing the load I can put on the host connection, how much game sessions can it handle at the same time), to assess the practicality of the whole solution. A working technical implementation that is not viable in terms of scalability wouldn't get me very far, therefore this is still a major risk.

Coming from a background of much lower-level programming (consoles, etc.), it is always tempting to try to push the boundaries, but beyond a certain point it simply becomes counter-productive (time invested vs. technical advantage)

Btw, thanks for all the input It's always great to be able to bounce ideas and make sure we're not missing the obvious !

Ah ah, well, at least this thread confirms I haven't missed anything obvious that would make it all very easy