To clarify, in an online game you should see every action a player does as a request. In fact a player does not take a “shoot” action when he presses a mouse button, what is actually happening down the hood is that the player’s client sends a request to the server/consensus group that he’d like to shoot. That server/group does checks to see if the request is valid (do you have a weapon equipped? Is the weapon loaded? Are you even alive at all?), and if so, then the server/group handles the shot and it’s consequences.
If it doesn’t work like that the player could hack the game software running on the local system and still send “shoot” actions to other players despite having no weapon or ammo or even despite being dead.
Ok, so in order to discuss this issue intelligently we need to know the SAFE network’s benchmarks for verified (consensus confirmed) transactions, which I don’t think we will have until Testnet3, when they introduce testcoin. Does anyone know if there will be benchmarks released prior to that?
I’m amazed at the intelligent discussions going on. We don’t even have a public Test Network up yet, and we are formulating how an MMORPG game can function. You guys/gals are awesome!
XOR handles encryption and decryption. That’s different than handling game mechancis. So basically you’re saying you need a referee. If A scores a point on B you need a ref to make sure A didn’t cheat in order to do it. So when A scores send the data to B and C. B is the recipient of the hit and C receives the replay data. If A’s score/move is illegal C reports it to both A and B and A is penalized. But again none of this requires the network to make decisions. C could be a third party player (most likely in terms of an MMO) or they could be a DAO of some kind. The network itself, again, only relays messages. In fact you could set it up that a move is only valid to execute if it’s been validated by C. In fact many MMOs do this with their game programming, but since you’re worried about cheating you could add this extra layer of protection. So say you want to swing your sword and use an attack, you issue the command, the system checks: Does this command comply with the game rules? Yes. Then it sends a message to C and checks to see again if it’s valid with the rest of the federated game rules. If C pings back a green light then you proceed with the attack. If no you get “Invalid attack, non networked ruleset” or something like that which prevents people from using rules that don’t apply across the network. C doesn’t have to be anyone particular, they could be the player that just happens to be the closest to A in the network and this could cut down on time immensely.
Based on what @dirvine has said in this thread there will be, but we already know that it involves more subsequent messages between different systems than in a classic centralized trusted server architecture (client<->server<->client), so SAFE is most likely at a disadvantage. Minimizing latency is very important in real-time games, and most gamers are not willing to suffer second class service on that matter.
That’s why I’m personally in favour of playing on SAFE’s unique strengths, rather than struggling with it’s weaknesses. Reflex-based games are probably not a great choice here. SAFE would be better suited for slower paced games that require communicating huge amounts of dynamic data. For example, a classic centralized server architecture would struggle if you’d let tons of players terraform and build on one huge world, while SAFE would handle that without problems.
Replay data from whom’s perspective? Due to latency the states of players on the player’s clients are always somewhat out of sync. Here we come again to the causality problem we discussed a little further back in this thread. A and B will always have slightly different realities running on their local clients because of the delay in communicating changes in state between them. Those differences in state will cause different outcomes, yet neither are incorrect (provided that none cheated).
No MMO works like that, I understand it may appear like that from the outside, yet there’s a subtle but essential difference. C doesn’t give a green light after which the client proceeds with the attack, C gives a green light and processes the attack and it’s consequences. The client will play animations and sounds and all that, but the trajectory and damage calculation and the reduction of health is all handled by C. What happens on the player’s client is all just a representation of the world as it exists and evolves inside C.
So your client doesn’t proceed with your attack, C proceeds with your attack, and your client merely plays animations and sounds that represent C proceeding with your attack.
The point is that all actions, processes, and their calculations (including physics) of the world need to be handled by one system, which dictates the state of the game world. Those calculations cannot be spread over multiple systems, because when those systems would exchange resulting information (information that again influences the next calculations), the delay in communication (latency) will cause inconsistencies in the states and calculations between those systems, essentially creating multiple different worlds with different states where different things happen.
That one system that handles the calculations and dictates the state of the game world cannot be one of the players, because 1) that player’s actions wouldn’t suffer from latency which gives an unfair advantage and 2) it would allow that player to cheat.
Picking a random system from the SAFE net is not an option either for several reasons.
First, in the case of a real-time game that server system cannot be properly monitored by other systems, since monitoring would mean processing the same things as the server and comparing the results. But since the inputs are slightly different for every monitoring system due to differing latencies, there will never be corresponding results. Also, none can monitor at what time exactly every packet arrived at the server system, so requesting a log won’t help either, since the server can just lie about the log. Because monitoring is not possible, this is actually not a decentralized architecture, we merely used SAFE to pick a random system to serve as the trusted server in what is essentially a classic centralized architecture.
In addition, handling large amounts of players in the same game world location is a very resource intensive task that most regular machines can’t handle. The load increases exponentially for every player that is in the same location, since every player’s actions need to be send to all other players.
The only solution that I currently see to this problem is not continuously processing incoming events from players, but processing them at intervals that are greater than the time it takes for a concensus group to reach a decision plus syncing the new game world state with other participants. That way we can resolve the problem of different systems having different gameworld states due to differences in latency. An incoming action is either processed at interval X or at interval X+1. If this interval time can be sufficiently low (depends on the SAFE benchmarks), it might be possible to still make it feel semi real-time. It won’t be as twitch-based as a true real-time game though.
If we really want a real-time MMORPG, a hybrid model may be a solution. Use SAFE as the database, which handles trade, dynamic world data, etc, and use a centralized dedicated server for all real-time aspects (movement and combat). In terms of performance we’d have the best of both worlds.
The real-time server would cost money though. Yet the usage of SAFE as the database already makes this hybrid model a lot cheaper than a fully centralized model. MMORPG development costs should not be underestimated. I wonder if something like this is best done by a for-profit group or as a community project where individual developers are rewarded for their contributions somehow? If it’s the latter, how could funds be allocated for maintaining the real-time server(s)?
Ok this may be a crazy idea but couldn’t we create like an action blockchain, or series of blockchains, or something. Or link actions to the spending of micropayments of safecoin so that when you performed an action it was either performed or not, and you knew whom it was performed on just like you knew who you would send safecoin to and whether it was spent or not.
I like this idea, and obviously a for-profit corp could integrate a centralized dedicated server.
Another thought is that at some point, everyone has talked about integrating a pure computing power component into SAFE. One of the things that I like best about SAFE is the fact that things are set up so that the static data services as you put them are inherently decentralized, and likely to be centralization resistant, due to the nature of data storage as a resource.
But we have also talked about integrating arbitrary computing resources and for something like that I don’t see how that can be centralization resistant. So I would suspect that once that integration takes place, that we will see massively centralized and powerful servers on the SAFE network, because that is the most cost effective way to get computing cycles as a network resource.
So at launch, the hybrid model would be the best, but as we move on to integration of arbitrary computing power, that problem may solve itself.
@Blindsite2k Because we don’t know how quickly SAFEcoin transactions will be confirmed we don’t know if this will work. Based on what @Seneca said above realtime game latency CANNOT be more than
without interfering with gameplay.
But we don’t have benchmarks for SAFEcoin transfer confirmations yet. When those come out, if the confirmation speed is under 100ms then we could build a realtime game structure on the SAFE architecture. If its over 100ms then we will need a hybrid solution, or move away from “twitch-base” realtime gaming at least initially.
Sorry @dallyshalla, I don’t know what “frequency in order of occurrence” means or how its different from a network confirmation of a SAFEcoin transaction?
If there is 100 data requests, and 100 SAFEcoin transactions
clearly they might not take place simultaneously perhaps; though I think that they might be in the same pool of transmissions. So likely scratch this comment;
What I meant was that - you might get data processed before SAFEcoin processed, and therefore a lag could exist based on the order in which one is processing some data, relative to a SAFEcoin plus the number of those transmissions would add to that lag.
Yet I do not think the design has a difference in processing between data and SAFEcoin.
If I hit with a sword first, I want to be registered first after I hit the button. It is a matter in “life or death” “conquering or being conquered” in battle.
In trading - if I hit the button to buy or sell first I better get it in order that it has been transmitted in actuality, against the forces of network latency.
I know the best of combat will make the best of transaction transmission and vice versa. Perhaps combat is usually more complex.
yeah won’t this whole decentralized MMO work once SAFE has distributed computation?
Then it will have the massive storage capabilities to host all the world data, and the massive computation capabilities to run all the insanely demanding processing of the real-world time events like shooting etc.
Won’t this work?
Remember that they ARE planning to add in distributed computation after a while!!
What I meant is that it’s okay if trades take a second to be handled by the network, at least as long as it’s about the same for everyone. It doesn’t really matter whether you receive your Sword of a Thousand Truths 20 ms or 2000 ms after clicking the “buy” button in an in-game auction house.
Most of the discussion of the past few days has been with distributed computation in mind. Feel free to read up on it if you want my view on the challanges that we face.
@Seneca, I think @dallyshalla means in real world trading, like a boiler room stock exchange set up, where people set up bots to buy and sell according to pre-determined settings.
So say you are dealing with a stock which isn’t very liquid, and you want your bot to buy it, and then need to be able to turn around and sell it to 3rd parties very very quickly. Latency becomes an issue in these scenarios as well.