what kind of features are you thinking of that rule out a large player count?
[/quote]
Dwarf Fortress level AI for the NPCs?
Radars that track the position of all other players in real time?
Game design that creates very dense areas where all players congregate?
Any other feature that requires N-squared examination of all player pairs?
Where Is The Line Drawn For Too Many Clients?
I dont know, seems doable. In 2000's NWN ( a great game, but horribly coded for mass multilayer ) was easily hosting 250 players on the big servers. This loaded all areas into memory and was doing some silly things. For an indie developer not using any of the newest technologies you should easily be able to handle 100 players on a single server. Minecraft ( which currently has shit for netcode ) can host up to 75+ with a decently sized world ( 5gb ) and have little to no lag unless you are doing some seriously massive world changes. That said, with the right code I am almost certain you could triple that.
As for games like TF2, they were not designed for bigger numbers and thus they are limited. It is not because they are not capapble, they just didnt want a game that would work with anything past the current cap. I run, and have hosted for 4 years, one of the top tf2 servers and we have been hosting it at 32 players ever since the crack came out to do that. We asked them for more player slots on several occasions as our server could have easily handled 64 players, but they said it would break the concept of the game... and I can see how it would. We had to make several changes to the core systems in order to allow it to work for the 32 player setup.
Anyway, all in all i think what you are trying to do is possible.
As for games like TF2, they were not designed for bigger numbers and thus they are limited. It is not because they are not capapble, they just didnt want a game that would work with anything past the current cap. I run, and have hosted for 4 years, one of the top tf2 servers and we have been hosting it at 32 players ever since the crack came out to do that. We asked them for more player slots on several occasions as our server could have easily handled 64 players, but they said it would break the concept of the game... and I can see how it would. We had to make several changes to the core systems in order to allow it to work for the 32 player setup.
Anyway, all in all i think what you are trying to do is possible.
Author
I'm not sure if this could even be taken seriously, but do you guys think that an ethernet-connected Raspberry Pi could handle a multiplayer game? I mean, it does have a 700mhz processor, 256mb of RAM and you can add a HDD, so its not like its worse than anything they had in the 90's back in the days of Everquest.
I'm not sure if this could even be taken seriously, but do you guys think that an ethernet-connected Raspberry Pi could handle a multiplayer game? I mean, it does have a 700mhz processor, 256mb of RAM and you can add a HDD, so its not like its worse than anything they had in the 90's back in the days of Everquest.
Again, it depends entirely on the game.
A game where the server must run all the physics and other simulations, heavy bandwidth requirements, where the server must coordinate between a large number of clients, or where the server must handle a wide range of non-gameplay tasks like matchmaking and lobby service and authentication and possibly even financial transactions ... That is a situation it would likely struggle with.
A game server where the CPU load and bandwidth are both fairly light, where memory and performance requirements are well within the system's hardware, in that case a well-coded game could potentially handle a thousand or more clients.
For an old-style text based MUD the system could probably support tens of thousands of connections and not be limited except as far as your network bandwidth could handle it.
I'm not sure if this could even be taken seriously, but do you guys think that an ethernet-connected Raspberry Pi could handle a multiplayer game? I mean, it does have a 700mhz processor, 256mb of RAM and you can add a HDD, so its not like its worse than anything they had in the 90's back in the days of Everquest.
They have both hosted and played Quake 3 on the RPi.
It's an error to think of networking and computational power in terms of 'force'.
There are reasonable limitations to both, but they relate to the specific tasks that each is being asked to perform. Contrary to what may have been said in congress, the internet is not actually a series of tubes, and data on the line is not a dump-truck.
Network libraries do nothing more (hopefully) than send data down the line. If you've not worked with it before then working with a 'normal' TCP connection is something like reading and writing to a file, except that what you write is what gets read by the machine at the other end of the connection. The main factor here is how well you design the client/server interaction. If you're concerned about how much load you can handle then focus on designing in such a way that you never send data that doesn't need sent.
In the end the only practical limitation comes from the NIC itself. I think my NIC at home can run something like 8 simultaneous full-duplex TCP connections before it starts getting tetchy. Using UDP can get past that a bit because a single UDP socket can accept datagrams from any number of sources, but you're just shifting work to the CPU in that case because you'll probably have to design a more complex application-level protocol to make up for the loss of TCP's reliability. Even in that case, if the NIC's input buffer gets filled with UDP datagrams you're going to start losing them, so there's still a limit to what the hardware can do.
Expensive server hardware can, of course, handle a much larger amount of data, but you don't need that hardware in order to know what kind of performance you'd get from it. It's all about the scalability of your design. Like hplus0603 mentioned earlier, N^2 complexity is going to hurt you a lot. You want to design in a way that eliminates redundant work, both for the CPU and in terms of how much data you're putting on the line. Once again, in effective design, brevity is power. The fastest and most bug-free code is the code that doesn't exist.
If you think about it, the huge web servers like google and yahoo and msn handle a ridiculous amount of clients at the same time. More impressively, those are TCP connections (since HTTP runs over TCP), so good design can accomplish a lot more than you'd probably think possible.
There are reasonable limitations to both, but they relate to the specific tasks that each is being asked to perform. Contrary to what may have been said in congress, the internet is not actually a series of tubes, and data on the line is not a dump-truck.
Network libraries do nothing more (hopefully) than send data down the line. If you've not worked with it before then working with a 'normal' TCP connection is something like reading and writing to a file, except that what you write is what gets read by the machine at the other end of the connection. The main factor here is how well you design the client/server interaction. If you're concerned about how much load you can handle then focus on designing in such a way that you never send data that doesn't need sent.
In the end the only practical limitation comes from the NIC itself. I think my NIC at home can run something like 8 simultaneous full-duplex TCP connections before it starts getting tetchy. Using UDP can get past that a bit because a single UDP socket can accept datagrams from any number of sources, but you're just shifting work to the CPU in that case because you'll probably have to design a more complex application-level protocol to make up for the loss of TCP's reliability. Even in that case, if the NIC's input buffer gets filled with UDP datagrams you're going to start losing them, so there's still a limit to what the hardware can do.
Expensive server hardware can, of course, handle a much larger amount of data, but you don't need that hardware in order to know what kind of performance you'd get from it. It's all about the scalability of your design. Like hplus0603 mentioned earlier, N^2 complexity is going to hurt you a lot. You want to design in a way that eliminates redundant work, both for the CPU and in terms of how much data you're putting on the line. Once again, in effective design, brevity is power. The fastest and most bug-free code is the code that doesn't exist.
If you think about it, the huge web servers like google and yahoo and msn handle a ridiculous amount of clients at the same time. More impressively, those are TCP connections (since HTTP runs over TCP), so good design can accomplish a lot more than you'd probably think possible.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
