RE: Why we need blockchain-based MMOs
The main reason we need to put MMORPGs on a decentralized ledger (such as the one I’m developing and please let’s stop saying “blockchain” because it is not general enough), so so indie game developers will not need the resources to manage 100s or 1000s of servers, because the decentralized ledger will provide it.
The game will be objectively audited; thus no hidden centralized cheating.
We’ll disintermediate the centralized game developers.
Also some or all (depending on the game design) of the in-game purchases can be returned proportionally to the users proportional to value of the assets in the game, or perhaps some other mechanism. A centralized game could also do this, but it couldn’t be objectively audited and the centralized game development companies have expenses to pay and leverage against less capitalized “indie” competition due to the large capital requirements for 1000s of servers. I’m not quite clear on how Huntercoin put Easter eggs on the game map without it being deterministically computable from the public data, but perhaps there is some homomorphic encryption way of doing it.
In that way game players become investors in the game instead of resources to leech on by centralized entities which hoard the capital and extract it out of the gaming community. Expert players move early to new games and acquire in-game assets which will appreciate in value as more gamers join that game. Indie gaming will explode with innovation and widespread, nearly unfathomable amount of diversity and creativity.
I’ll probably be the first to launch a decentralized ledger which can properly run a MMORPG game decentralized in real-time and scale. Our focus will not only be games, but everything including decentralizing blogging, wikis, forums, etc.. I intend to disintermediate every centralized scam walled garden on the Internet, including iOSknob, Doggle, Twatzar, Suckerbook, Githobo, Redditard, YouTard, etc..
I’m creating a Bitcoin killer as well, because I have a technical document which explains that both proof-of-work and proof-of-stake only are viable when they are oligarchies. I’ve also debunked the DAG technologies for IOTA and Byteball. My decentralized ledger technology is a new concept. Major bombshells are going to be dropped on the cryptocurrency arena some months from now.
My comments section will contain my updates. Note when I edit a comment to add new information, that comment rises to the top, so should be re-read.
My expertise is as a proven software developer, marketer, and paradigmatic innovator. And I have some past experience in developing graphics software. For example, in 1993, I was one of the early hired developers (by the founders) for what is now Corel Painter (the natural media painting program, not Corel Paint). I also created one of the first real-time cartoon line 3D renders Art-O-Matic in 1997. I created one of the first full featured WYSIWYG word processors (Neocept WordUp) for the Atari AT in the late 1980s. At the inception of the mass adoption of the Internet, I created CoolPage WYSIWYG web page creation software launched in late 1998. CoolPage had at one time 335,000 confirmed (by Altavista) websites and more than a million downloads at the turn-of-the-century juncture when the Internet was 1/10th the population size as now. But I have not done any game development. I code in several languages, and can pick up new PLs quickly. I’m also designing a new PL along with @keean, named Lucid.
From roughly 2003 to 2008, I was goofing off after losing vision in my right eye 12/1/1999 and my prior marriage and family life disintegrating. I had been very chronically ill with an unknown illness that was finally diagnosed in Jan 2017 as disseminated gut Tuberculosis (meaning no cough, which is why TB wasn’t suspected before that) since about 2011 (some adverse symptoms even started before that) that made it nearly impossible to work (imagine your worst hangover vomiting, feel like shit, can’t think, etc, but continuously for years). In late June, I completed an intensive 6 months liver toxic antibiotic treatment. I’m gradually improving but still not yet sure if my health will return completely back to normal.
Note I recently wrote the following in a private marketing document.
Chimaera
Chimaera is working on decentralized MMORPG but the whitepaper for their technology appears to have some weaknesses.
Afaics on cursory glance, it doesn’t state that blinding (with two rounds) helps insure randomness (under the nearly certain assumption even one player isn’t complicit with all others, and whose moves are not “bit-level deterministic”—the hash of at least one player’s moves aren’t deterministic), but did mention hash commitments in the “Shared Turns” section. Employing blinding with an epoch to demarcate unblinding is a means of secure multiparty computation of the aggregate PRNG entropy.
Chimaera’s Game Channels proposal is flawed because any (either if only two) party can delay the progression thus removing the realtime aspect (there is no objective clock). The dispute protocol can’t assign blame for delayed response (within the threshold to begin dispute resolution on chain) because need to allow for network latency hiccups. By delaying the progression some parties may be able to position (at a relatively faster pace since the realtime activity has been slowed down) other assets into position which are not party to the channel. It can’t be proven that a user refused to engage (as long as the adversary responds within the slow threshold for initiating dispute resolution), i.e. propagation on the network doesn’t prove anything objectively about the consensus state machine.
The author Daniel Kraft (the lead developer of Namecoin) refers to “Non-stalling”—where he means not repetitively delayed such that each delay would be slower than the block period epoch—but that removes the realtime guarantee as I explained. I realize the author’s goal was more about scaling than attaining realtime performance. He admitted such, “Second, non-stalling guarantees only a certain maximum time between moves. This time must, furthermore, be chosen much larger than the expected time for each move in the game.” But he didn’t state the case that the adversary merely delays without going to dispute resolution phase and gains due to relativity of speed of orthogonal assets, “Thus, it is possible for an attacker to deliberately delay the game and bloat the public blockchain with dispute transactions in the process. We believe that this is unlikely to happen on a larger scale since the behavior produces no meaningful economic benefit to the attacker”. The author’s “5.2. Near Real-Time Interactions” section is absolutely incorrect.
Also their author Daniel Kraft doesn’t know that I also explained that side-chains are irreparably flawed.
Chimaera has some great graphics on their website, but their technical acumen appears to be lacking in some facets as aforementioned. They have a game developer (also archived) listed on their team.
I'm the author of the game-channels paper, so let me reply to the later parts of your post (relating to Chimaera, and there mainly to my paper). From how I read your comment, the main (and actually only) point of criticism you have with the paper is that a defecting player can delay moves in a game channel deliberately up to a certain tolerance, thus removing the real-time aspect. In other words, all the other results of the paper (in particular, about the way to improve scaling by using off-chain interactions and the security of those) seem to be fine also in your opinion; at least, there are no actual arguments for why you think they would not be fine. Regarding your criticism about the delaying, there are a couple of important things to note:
First, both my paper and Chimaera are not only about real-time games. There are a lot of very interesting applications even when restricted to turn-based games, like a decentralised chess tournament, trading-card game or a massively scalable reincarnation of Huntercoin, to name a few. These are the situations at which the paper is aimed first and foremost, and for those, even a delaying opponent is more a minor nuissance than a critical problem.
Second, all that is only a problem if someone actually tries to deliberately delay the game. As long as players are honest, all works fine, including the proposed near-real-time protocol. So your claim that this section is "absolutely incorrect" is just bogus, unless you have additional arguments that you did not yet share in your post. Especially since all your points of criticism are actually pointed out and acknowledged already in the paper. No-one has created and run a decentralised real-time game so far, so we do not yet know how big of a problem such distracting players will really be (given that they can only annoy but not actually cheat others). We will just have to try and adapt to the challenges we see in a live system.
Third, note that the paper was published a year ago and written almost two years ago. Because of that, this paper alone is not the only innovation that we will be using for Chimaera. See for instance our recent post about ephemeral timestamps, which fix a lot of the problems still present in the dispute process of the original paper. (Although it admittedly does not completely fix the issues you mention about delaying a real-time game.)
Fourth, I'm not sure why you mention sidechains at all. It is true that I'm not aware of your arguments that they are "irreparably flawed", but that is not relevant here. The reason why the game-channels paper mentions sidechains is because the protocol it proposes has what can be seen as "private sidechains". But it does not use any of the techniques that the "official" pegged sidechains are built upon, so whatever your arguments against them are, they are not significant here.
By the way, I'm mainly interested in science and engineering myself and not a business person. So if you have indeed found a way to build a massively scalable, real-time distributed ledger that will "bombshell" all of the cryptocurrency space, I'm looking forward to it -- building on that instead of the current state-of-the-art would be good not least for Chimaera as well. So I'm awaiting your publication of the technical details how that will be accomplished -- so far, you only claim that you will be doing so, without describing any actual techniques that would give these claims credibility.