Load sharing between client and server?

#1 It is possible, but an interesting programming task. Think SETI@Home. But, for most conventional types of games, I'm not sure what good it would do.

After all, there is a reason the engine is divided between client and server code.

And if the processing you wanted to "share out" was equal for all clients at tall times, then it would make no sense to add the overhead necessary to pool resources.

This sounds like a solution in search of a problem. Are you trying to solve a problem with this?

#2 I'm planning on making an RTS/FPS game where the entire online mode is a massive war that is constantly going. The most obvious choice to do this would be to have servers for each and every territory or region, but I can't afford that many servers. What I was hoping for with the plan above was to have everybody on the same server so I could avoid buying a lot of servers and I was hoping to remove the max number of players per server/area problem that this game would have otherwise.

What I'm trying to do is find a way to have only one or two servers for gamplay while having an unlimited (or close to it, anyway) player capacity. I guess you could say that I want the server load to be constant (if not reduced) as more players join the game. That way the server will never be overloaded and it would be able to handle more players, if it can be maxed out at all (in which case the clients themselves would also be overloaded resulting in a gamewide computer crash as the worse-case scenario, with the best-case being a simple disconnect from the server).

#3 Well that's a really interesting idea. It strikes me as a great project for someone who has already implemented a MMOG of some sort. Because I think that that experience would be essential to implement the advanced scheme I think you are thinking of.

I'm always struck by Bittorrent. For the first time in the history of humanity, higher demand leads to higher supply of a thing. The fastest and easiest file to download is the one everybody else is getting, too. It turns classical economics on its head.

But more seriously, it comes down to exactly what processing needs to be done, and when. And that is totally down to the detailed design of your game. What, exactly, is it you are going to process on clients rather than the server? After all, you need to know this, as compilers are notoriously unwilling to make their own decisions about what to process, and where.

#4 Let's take the idea further. Let's turn the clients into servers and have them connect to each other similar to bittorrent. This way any data being sent is bypassing the server making the server itself unnecessary, for the most part. Now, let's pool the server's resources so the server itself is taking an equal load to the clients. If all goes well then the server will rarely be overloaded (if at all) and the number of players is still practically unlimited.

This is assuming it even works that way. I don't know if this kind of concept has been proven (or even used) before.

If you want the extremely short version then I'm turning the game into a giant online LAN-party with bittorrent as the basis for data distribution (which shouldn't be much since it's transferring call functions and tags instead of entire files. In the 100 KB range at the most because of the sheer number of connections to send to at the same time.).

Oh, and just for your information, they will be connected by territory. This way only the people in the same territory will be sent the data (the whole world doesn't need to know where you are and what you're doing, now does it? I might need it to make a fast replay of how the war went as soon as a faction wins, but not that many people.). This will also prevent you from going slow by sending too much data at a time (assuming you have a high-speed connection in the first place).

#5 Well, I still think this is a solution in search of a problem. Using bittorrent specifically would be a bad idea, actually--I was just using it as a metaphor. For one thing, bittorent doesn't care what order you get pieces of data in, just that you get them all. In a game environment, timing is generally vary important.

Again--do you have a problem you are trying to solve? It really a question of exactly how your game works.

Your ideas are actually very old, in some ways. After all, "client" and "server" are merely convenient descriptions for the way a particular machine is acting. Older FPS's were frequently peer-to-peer systems (Doom1 comes to mind), although ultimately one machine had to be a kind of "arbiter", or ultimate authority about what happens in the game. Kinda like a server.

The first time I saw "client" and "server" used in games was Quake1, which Carmack eventually opensourced and if I'm not mistaken the core code of which is used in nearly all FPS engines today, one way or another. Although I don't know about Torque. Anyway the client/server model became standard because it made sense to do things that way.

Right now your ideas are sense without purpose. What problem are you solving this way?

I will say that turn-based strategy games could work this way just fine.

#6 I'm only using Bittorrent as a basic idea to get off the ground with. Really, what I would have to do is create my own peer-to-peer network application that is similar to bittorrent, but doesn't send info randomly and would be faster (since bittorrent is actually slower than what I really need). It's like bringing order to chaos, in a way.

What I'm planning with this idea is to remove the "arbiter" (or make everyone "arbiters", whichever way you want to take it) so that each person processes his own data and only sends what is required to tell everyone else what he is doing.

To accurately tell you my problem I would need to tell you how I have the game planned, but I'll try to explain it without doing so. Combining RTS and FPS in the way I'm doing it, (instead of being a single battle, it is an entire war with 5 or more battles going on at all times) can't use most other networking styles. For example, A single Starcraft game has 1 host at all times with everyone else as a client. I can't use it because the sheer number of connections will make everything slow (which is probably why Starcraft has only 8 players). A Battlefield 2142 game has a single server that receives and processes all the data and then sends it out. It also starts to go slow with 64 players playing at the same time. I can't use this one either. My current budget doesn't allow for that many servers (I would need more than 30 servers this way, one for each territory), plus the server would get overloaded with a major battle (think at least 100 players defending a base, with 3 bases attacking with about 70 players or more per base, on a slow day. If this gets popular enough.). MMO games also aren't what I need since they typically use several servers to represent an area or a world. I want everyone to play together without being seperated by a server, and without having to use several servers. So I need a way to connect everyone using only one server (without overloading it) and without making anyone slow down, with a high (preferably unlimited) player capacity. My above idea is the only way I can accomplish this with a game like the one I'm making. I hope this explains my problem.

#7 croquet is a peer-to-peer shared virtual environment. the idea over there is that there is no central server. it's OpenGL via smalltalk.

#8 Thanks. It sounds like exactly what I need so far, I'll look into it more later. I wonder if I can combine it with Torque or some other engine.... Maybe I can modify it to use DirectX as well as OpenGL.... Hmmm....

#9 I found it to be fairly difficult to work with, partially because smalltalk took a lot of getting used to,
but there's some good concepts in it.
i wish they would abstract out the p2p networking from the graphics.

#10 It is an interesting idea. Nothing for it but to check out the netcode, in detail.

I don't know what country you're in, but here in the third world (USA) most people have very slow UP connections, and this could present a real problem, potentially.

Why don't we have fiber to the home, yet?

On a side note, it would be very amusing to include, say, a Gnutella client in-game, with the game server as an ultrapeer. Let players swap music and porn while they're playing. Would make for some nice publicity.

For that matter, the in-game music could be uploaded by the players. That would actually be pretty cool, wouldn't it? (except for those who would abuse it with noise, like Pearl Jam or something).

#11 It is a good starting point at least. Use some of the concepts from Croquet to make a game network while also separating the graphics so the graphics run on each individual computer.

As for the music, I was thinking of a built in mp3 player of sorts so people can play to their own music individually.

#12 I would raise two points here:

First, the reason that peer-to-peer networking really isn't used anymore is that it opens up your game to a *massive* amount of easy cheating.

For example, if my "server" is the authority of what happens in region A, then it is a pretty straight-forward hack to make all of the player on my team/side/faction have unlimited ammo or to run twice as fast or to be invincible (seriously...most hackers could introduce those cheats in 20 mins with a hex editor and your executable). Since there isn't a central server checking to make sure that the players are moving at normal speeds and aren't teleporting through walls then your "server" has free reign.

The second point is that it is a little early to start worrying about how to handle 1000's of players when you don't have enough of a game to even attrach a 100 players. Start small...is it fun to have 6 people running around and attacking each others' bases, yet? Do you even have the art for a single base or player?

Build a single level with some basic art assets and a minimum number of classes/weapons/vehicles/etc. If people really like/play it and really like the art style then you can move onto bigger things. At that point you will also have more money to use towards getting the help you need to make the "massive" environment you want.

Actually, Tribes is a great example of this. The developers always had in mind a large scale persistent environment but they moved in smaller steps (Starsiege, Tribes 1, Tribes 2) towards getting there with each stage helping to pull in more players and helping to fund the next larger step. Sadly, outside forces came into play and they were unable to complete their goals (yet ;) but they were on the right road. Looking back it is really easy to see how the next iteration of Tribes could have been an MMOFPS.

#13 Thanks for the advice.

Unlimited Ammo cheats won't be needed with the way I have most of the weapons. My weapon's are going to use an energy meter so when someone uses a clip to reload, the energy meter starts to fill up and when that's full another clip will be generated. This way everyone has "unlimited ammo" of sorts. Although I get your point (though, people will be their own authority, only being in charge of their own data).

I was planning on putting in a profile system. Every time someone buys an upgrade (or logs out) it contacts a server and transfer the player's profile (which is copied to and processed on the player's computer during the game session at log-in) to the server and is then checked for cheating. For example, large numbers of kills with no deaths will be considered suspicious activity (I can also use it to reconstruct the war like a replay). If someone is found cheating, that player will be punished by being forced to do some sort of task in a pit and is unable to play normally until it is done with the other players trying to stop him in some way (either by directly shooting at him or by taking control of something to go after him with). This will happen three times. On the fourth offense, however the cheater will be locked in a pit and become a ragdoll until he submits a formal apology. I will then "unlock" his account. But on the fifth offense the cheater will be forced to survive for 30 minutes, and on last 5 minutes 3 people (me, and 2 others) will come in and start slaughtering everything (there will be several players being punished at the same time). If the cheater dies the account is deleted. If he manages to survive, he escapes until the next time he breaks the rules (in which he will have to fight for his account again). Not sure if this will be accepted or even tolerated by the players of the game, but it is a unique way of doing things (people will get to watch/inhibit the players that have cheated or have broken the rules). The proflie itself will contain the player's stats, kills(who,and when), deaths(by who and when), upgrades, and other items that cheaters are prone to hack (although the walking through walls part I'm not sure what I'll do. It partly depends on which walls they go through. I plan on having a report system so that honest players can turn in cheaters).

#14 I dunno. as a player i'd rather play the game and not have to worry about who's cheating and then reporting them. .. unless you want cheating to be part of the gameplay, of course.

#15 I agree. I wouldn't want to worry about reporting either. I thought of having player moderators as well, but the only problem is that I wouldn't know who to put in as a moderator. I guess I could have applications for that, though the problem is that it can be easily faked.

#16 Disclaimer: i think that for games it's probably a mistake to leave the fairly traditional client/server model.
however, it's interesting to think about !

one thing you could possibly do is have a handful of clients authoritative for the same events.
ie "was it a headshot ?" - you don't want one client to be authoritative for decisions like that, since it's a huge cheating hole. however, if say four or five clients chosen at random were all making the same decision and then voted, you could perhaps automatically detect cheaters.
due to the nature of networking, it's inevitable that two good-faith clients will report different conclusions for events like that, but perhaps if one client consistently voted differently than its peers, you could uh, punish it somehow.

#17 That's an interesting idea. I should keep that in mind. I could probably do something similar to that line of thinking.

#18 How about using a hybrid P2P MMOG infrastructure as a model?

#19 I've been researching that idea and I think I can use it. If somebody can point me to anything that can help with this, then I'd be grateful. The only problem I'm concerned with right now is integrating it into Torque and making sure it works.

#20 Just a note,
i would expect that you're starting on a long, difficult, and very infrequently-travelled road with a prize of dubious value at the end. i would expect neither the fidelity nor performance offered by such a system to be as high as a traditional many-clients, single-server model. remember, now the server essentially is a client to every plain client, which means its own network traffic is doubled.

in our experience with hundreds of simultaneous clients connected to a single server, the primary server bottleneck is in network bookkeeping, not in simulation.