   Multiplayer games using a bittorrent style network?
  Does it sound like a reasonable idea to have a multiplayer game be essentially distributed much like bittorrent? Where your own servers mearly act as the tracker and then the clients themselves work together to do the heavy lifting of the game world and serving content?With a well designed distributed system you should be able to offload the vast majority of processing requirements by setting each one up as a packet of data and processing on the least busy client in the same way as SETI@Home and others work.Does this sound like a realistic prospect or is it pie in the sky stuff? If it is realistic does anyone know of any articles discussing the principles in more detail (sorry I don't actually know what the technical name for this is so I don't have much to Google with).   
  Look into P2P networking. It distributes the task of authority among clients such that no one client is authoritative. (Each player sends their state changes to all other players or something similar.)SETI and other distributed programs are built to not send very much state. Instead they rely on the client to use that state and process it for a while and then send back information about that state. (It doesn't really require a constant connection.)It's possible to design P2P games. Unless you can't host servers or don't want one person to host them then P2P isn't that great and the Client/Server model is better. With P2P you have to rely on everyone having a good connection. Under the client/server model only 1 person has to have a good connection.Also bittorrent relies on the fact that everyone has part of the data and it's serialized and built on the other clients into a full set of data. For instance, sending a file makes perfect sense with bittorrent because all connected clients have the data. In a game this doesn't make much sense unless the game is running at a deterministic time step. But even then you're just having each client send their piece of the state to the other clients and building the full state on the other side so it's a P2P setup.   ;  This sort of question has come up in the past, have a search through this forum and see if you can find any relevant topics.The main problem is that if the whole network is P2P, there's no authoritative answer on what's correct. If one client says they moved to a certain position, and another client sees that there's a wall in the way, there's no way to find out which client is correct because both of their opinions are equally valid.Bit torrent gets around the problem because each chunk of the file is hashed, and the hash stored in the .torrent file (As I understand it) - so you know if a downloaded piece is valid.   ;Quote:Original post by Cromulentbittorrent?BT is built for redundancy but is completely unsuitable for anything real-time. Its connection strategy also causes many home routers to die.Quote:SETI@HomeS@H tolerates latency of 1 month for each request/response. It's the very anti-thesis of real-time. The very design of S@H is aimed at entirely different problems.The both share some traits which make it impossible for real-time interaction. The most important one is that they operate on immutable shared state. The other consequential limitation is that peers can only opt-in to receive some part of data, but they cannot specify which and when.Neither of the systems is real-time (as per definition) in nature as they are incapable of enforcing deadlines on any operation whatsoever.   ;  The VAST project aims at solving those kinds of problems.In my opinion, the negatives outweigh the benefits, as long as people are willing to pay for reliability and fairness.;  Thanks for the advice. I was not actually thinking of using Bittorrent itself just a custom protocol that takes its inspiration from it. It was the first thing I could think about that people would know the sort of thing that I was talking about.I'm sure it would be possible to overcome the problems that have been brought up. As for the distributed processing it should be possible to create a system that keeps itself in sync I just don't know how expensive that would be in terms of bandwidth and server latency.   ;Quote:Original post by Cromulent As for the distributed processing it should be possible to create a system that keeps itself in sync Sure it is but the main problem is how to do that in the face of game hacking.  Mostly you can't give authority to clients because someone will hack your app.   ;Quote:Original post by stonemetalQuote:Original post by Cromulent As for the distributed processing it should be possible to create a system that keeps itself in sync Sure it is but the main problem is how to do that in the face of game hacking.  Mostly you can't give authority to clients because someone will hack your app.Surely using an encrypted connection would be sufficient to stop hackers? I have not done any testing to see what the effects on latency would be if you used an encrypted connection but I can't imagine it would be that bad if it was just 128 bit or so.   ;Quote:Original post by CromulentQuote:Original post by stonemetalQuote:Original post by Cromulent As for the distributed processing it should be possible to create a system that keeps itself in sync Sure it is but the main problem is how to do that in the face of game hacking.  Mostly you can't give authority to clients because someone will hack your app.Surely using an encrypted connection would be sufficient to stop hackers? I have not done any testing to see what the effects on latency would be if you used an encrypted connection but I can't imagine it would be that bad if it was just 128 bit or so.Incorrect sir.  There are different levels of hacking.  If they hack their computers memory and change values and instructions before they even leave their PC, then your encryption serves no point.  Even if they were packet editing, they could still crack the encryption with a debugger of sorts.  They would be able to reverse engineer the method, and all they would have to do is make a program that uses the current key in memory, which wouldn't be that hard for someone who knew what they were doing.  Then they just send out the packets, under your encryption scheme.  But still didn't stop them.What we mean by the server having authority, and the benefit of server/client models is that the clients request 'permission' to do something.  So player pushes the forward key, the code sends out a request to the server, the server says ok there is or isn't anything in front of you to stop you, authenticates it.  Then based on the results sends back all of the data to the clients so that they merely mirror the information the server has, so everyone is on the same page.With the P2P scheme, with no central authentication server, then it becomes tricky to know who to trust, because no client should be trusted.  You end up having to create all these weird schemes to make sure everyone is on the same page, and no one is trying to pull a fast one.  It becomes more complicated than it's worth, and probably really easy to design completely flawed anyway.Edit: Not to say it can't be done, but for personal projects and indie games, a client/server model would be best.  It's probably the easiest to design and implement, makes the most sense, and is the easiest of the two to debug for the most part.  A small indie game typically is easily hosted on a home computer or inexpensive dedicated server.  You won't be trying to avoid having some huge server farm and save thousands of dollars, so the straight forward client/server model is most likely the one that fits your needs.  Unless of course you're just doing this for learning purposes, then that's completely fine but you'll want a better understanding than what you have now before moving on and attempting what you've proposed.[Edited by - Xelen on May 21, 2009 1:04:13 PM];Quote:Surely using an encrypted connection would be sufficient to stop hackers? I have not done any testing to see what the effects on latency would be if you used an encrypted connection but I can't imagine it would be that bad if it was just 128 bit or so.No, it can't. Let us assume your program is compromised. The hacker can use it to send any kind of data to other peers. Just because the information is encrypted doesn't mean it can be trusted.In any case, it would probably be easy to decrypt and encrypt your packets. This is because you must give the key to the peer (else how can you communicate) and the algorithm will be known.The hacker will find the weak point in your system, whether that is the data stream or the code that creates it.   