Hello.. i''m creating a new network game with VB (yes VB, no comments!) that supports multiple games on one server... Users can either join existing games or create new ones, but, how can a server handle maybe 10 games at once with maybe 10 users in each? That''s alot of calculations to do!? Isn''t that going to be very "laggy"? It has to keep track of where each player is one each maps, keep track of the ball on each map, keep track of.. Everything! At the beginning i thought I would make everything server side, so i wouldnt have to worry about packag drops, and so everything looked the same to each user, and .. cheating. But, will VB be able to handle all this? Uhm.. I thought of this for a while and, a wierd little idea poped up. Why not have 2 servers. One that handles joining and creating and... one that deals with the game set by server. I mean, when the main server gets a game creation request, it starts the other server (another executable) with the game settings, players.. everything it needs. So theres one server for each game created... I''m very lost here, as you may see... Help me! Anyone!

You''re worrying about nothing. 100 users is insignificant. The main problem is how you keep track of everything. This is where good use of object orientation can help. Each game object is given its own port/port range or whatever, and it handles its own players, without needing to know about the others. It becomes no more difficult than just running a single game object 10 times.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

If doing 100 calcalations slows your game down, you''re doing something horribly wrong. Time all your functions and work on speeding them up.

I''ve already got my server set using OO to allow any number of games to be created (using dynamic memory) and allow up to 6 players to join each game. Even the most complicated rule (involving a series of pathfinding calls) currently implemented doensn''t take even an msec to execute.

With Tombstone the real slow down was bandwidth not the actual server. With the 10Mbit LAN it was very slow with 750 NPCs logged in running around. With the 100Mbit LAN it just whipped right along.

It''s really a combination of factors you need to worry about. The most important is how efficient your packets are. Then how much bandwidth. And then how fast your server PC is.

Before I started taking advantage the streaming property of TCP I was seeing noticible lag even on the 100Mbit LAN with a single client. Now that all the messages resulting from an instance of client activity are put into a single packet there''s no noticable lag. It also cuts down on bandwidth by reducing the number of TCP/IP headers needed to be sent.

If possible (depending on the type of game), maximizing the time between packets also helps. My current project is the type of game where it''s a number of seconds between messages from any given client. That gives the server time to handle everyone else and for the clients to catch up if they need to.

Ben


IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com | GameShot ]