Flame me or anything, I gotta find out what you guys know, this stuff is fascinating!!! ================== What price is being charged to intergrate with the butterfly.net system? is it even affordable for indie developers? ================== I had some ideas about how one might go about creating their own grid based networking engine with very little $$$. 1) Create grid software. 2) Set up traditional server. 3) Server starts getting traffic, *hopefully* developers/publishers start getting money... (more traffic means more players means more games sold) 4) Another server is installed. 5) goto 3 =================== NOTE: I''m using the word ''user'' when I actually mean ''user''s instance of the game'' As broadband becomes more prevalent, and in my opinion, the only fun way to do online gaming, would distributed gaming allow the developer to ignore providing servers entirely, or at least only add servers to places where lag is high? It seems that almost all the current services offered by online game providers could be made distributed so that no central server backbone is even required, or at least a minimal one. 1) Master server (list of games in session) The function would change, since all players are in the same ''game''. However, using the same type of system that kazaa uses with their nodes, one could have a request that transverses the system to find out which host owns the position in the game world that you wish to connect to. (Network in a network so to speak) 2) Game sessions In a distributed model of gaming, a cluster would be what a game session used to be. I would define it as a group of players with high interactivity over a small time period. If I walk into the throneroom and there are 10 other players fighting each other, I have joined that cluster. 3) Sync/Server authority issues. Everyone in a cluster would have an authority ranking, based on their net bandwidth, their computer''s power, their online time, and possibly some reliability metric that can basically calculate how correctly that person''s game computes the object behaviors. For any object that is within a user''s visible region and not in another user''s region, that user can update the object as he wishes. For any object that is within multiple user''s visible regions, the user with the highest authority controls the exact behavior of that object, and surrounding users must do their best to stay in synch and accurately approximate that object''s position. 4) Game object management by the larger system. Say that in a cluster someone shoots a supermissile but it flies out past the collective cluster''s visible region. At that point, the last user to own the missile must do a server location lookup to see if any nearby clusters care about the missile and then pass the ownership to that cluster. If no clusters are nearby, the missile is checked in to the server backbone. 5) Server backbone Ok so I did lie, there will have to be servers. The server backbone does not attempt to simulate the game for millions of players, it simply contains a section of the game world environment and updates the game objects in that environment. 6) Cheaters Anyone who cheats will get bad reliability metric and will lose their authority ranking. Simply put, if Bob''s game says that he has 100000 gold and everyone else''s game simulating the same input says that he has 70, then his reliability starts looking bad, which hurts his authority. In a very real sense, his game becomes more of a dumb terminal, since it does not update the game the same way as everyone else''s and he has too little authority to affect other people''s games. In fact, he only has authority to cheat when he is not interacting with other players. Depending on what type of game this is, that alone could be pretty helpful. 7) Object checkin-checkout system. The game system without players is a server grid with each one running a game simulation for a piece of the world. When an object crosses server boundaries, ownership is transferred to the other server. When an object reaches a cluster, the cluster is notified, and the cluster itself arranges who owns the object, or it can deny ownership entirely. The server hides its copy of the object and waits for any *occasional* updates that it might hear about that object. When an object leaves a cluster, it can be checked in to the server system, so the server takes care of manipulating the object again. 8) High traffic volume and lag For a worst case scenario, we are screwed anyway, no one will be able to handle 100s of players in a very tiny space. This is where one more concept will help... Nowadays, if there are too many players for a game world, the world is simply replicated entirely in order to lower the density of players and solve this issue. My proposal is that unique clusters can overlap! Obviously there are a few issues to doing so smoothly so that one does not see wierd artifacts. 9) Dropped computers Perhaps you wonder what happens if an important game object is checked out (aladdin''s lamp ) and that computer drops without properly checking out. Where does that one and only precious lamp go? This is where clusters and server daemons could be helpful. If the person of highest authority that cared about the object dropped, then the person of next highest authority that cared about the object would automatically keep track of it. If only one user ''knew'' about the object and he dropped, then the server would start updating that object according to the latest info that it did have about the object. And if a very important object simply disappeared completely, a server daemon could spawn a new one. 10) The game objects The game objects must use guids to uniquely identify them at all times, and allow servers to know when cached copies and new updates about that object are in fact related. 11) Persistance model - Servers know everything. They only don''t know what they havent been told yet. - The users check out pieces of the world and trash it and the server may choose to ignore the results of their actions or accept them. Using guids for game objects, the servers will always know which actions have been done on those objects. - If users disconnect from the system without checking stuff back in and eventually the server is given control again, the server can simply pick up rendering the object from where it left off. - The server reserves the right to ignore persistance when no one is looking. - The server can decide whose version it prefers more when concurrent clusters submit info regarding the same object. 12) Empty regions and resetting puzzles Say that we have a persistant game world, but certain components of the game are expendible and need to be replenished. We might not want these to just randomly spawn, or they may require an elaborate setup that we wish for players to only see in two states when they first discovered it: trashed, because someone is here and they trashed it, or interesting and puzzley, because it ''appears'' to be the first time that anyone in the history of the whole game ever has come to this place. An example of this is Super Mario Bros 3, where when you kill a Gumba and then walk off the screen and back a few seconds later, there is another gumba in the same spot. If it was more multiplayer oriented, you either might want another player to come along and be able to enjoy the toughness of killing that gumba or youd want to make sure that the player who just killed it doesnt have to see it pop up from nowhere again. Your server logic might be like this: if(noPlayersHere) resetRegion(); Hmm thats about two hours gone. What do you guys think? Is there anything that is just too unclear for you to know what the heck im trying to say?