I was wondering if people here are already using blockchain for storing in game items and points, etc. I was playing around with the syscoin blockchain. It let's me make my own tokens very easily, I can also make my own blockchain marketplace, the speed of transfering these tokens is awesome. I was wondering if there are people with experience in using a blockchain as central storage? More info about blockchain API's : https://syscoin.network/syslinks/ (check the API & Development resources) . It seems to me this could also be used for registering software (for people that buy a paid license).

Is there already a place in the forums for this (I could not find it). What are you guys doing with blockchain?

Happy programming.

The problem with most blockchains is that they are publicly auditable, and they move slowly.

It turns out, most games need neither of those. Most players don't want their entire inventory to be publicly seen, and most players want transactions to be instant.

The kinds of games that DO work on blockchains, are those that rely on public auditability (think gambling,) and scarcity (think Ethercats.)

Blockchains are a neat computational primitive, but it's fairly limited in scope as it only adds value where you need a public, distributed, consensus among potential adversaries, and you are OK with slower update times, the cost of perhaps choosing the wrong continuation fork for a bit (number of confirmations,) and spending a lot of resources for the "distributed consensus" part.

In 99.9% of games, a single mysql database will work better.

Something which I haven't seen yet, is some kind of smart contract bet which depends on the future outcome of the chain -- say, use the hash number of the next accepted block as the "roll" of the dice for a betting system. Pay 0.1% of prize pools to the operator of the contract; pay 50% of the prize pool into, say, 10% of players each turn, roll 49.9% of the bets to the next iteration, with some one-in-a-million chance to get 500,000x your payment back. Basically, lotto-on-blockchain, using the block hash as presumably un-tamperable RNG.

The shilling of syscoin in the original post aside, if I were to build some gaming infrastructure on a block chain, I'd pick one with a little more maturity. Probably Ether main fork, or perhaps Neo (formerly antshares.) And even so, the main problem with all of these "put your trading on the blockchain!" systems, is that the blockchain has no way to enforce physical compliance for physical assets, and in the end, physical force is what all physical ownership is all about. You couldn't "own" a house unless there existed a police force that would evict people who tried to squat on your property (or you could afford private security, like a feudal lord.)

Sorry for the shilling, it was enthusiasm, tried ether and bitcoin. Ether was soooo slow, everybody tells me Ether, but I think they all did not actually use it themselves, only hearsay... Bitcoin was to limited in capabilities and to slow and expensive. Somebody told me about Syscoin (actually an old project from 2014), and shilling or not it just really actually worked and was fast and cheap and easy. Don't know about Neo, could be cool as well. Will take a look, could not find a lot of resources on gaming and blockchains.

Ethereum and Bitcoin are a hassle, need lot's of diskspace and are painfull slow. Impossible to contact the devs on slack for ethereum and bitcoin. Just try a local ethereum/ bitcoin /syscoin (I tried the blockmarket one) wallet and you will understand what I mean (bitcoin and ethereum took a week to sync..) . Don't want you to "invest" in any of them, just try doing something with them.

And I don't care about all these different blockchains at all. Just want one that is operational and works. 

Thanks for your reply, highly experimental all those blockchains, nice to see more people looked into this. Are there special gaming/blockchain forums you know of?

We've been toying with ideas for years but haven't committed to any.

As above, most games don't need a decentralised model and can do better with centralised. e.g. Valve hosts inventories for free already, gives devs full economic control over the game, and has an out of game market for player trading. Even making one yourself and hosting it on your own server is cheap and easy... 

Decentralised can solve a trust problem, where users don't want a central authority... But most people are fine with trusting a game developer to be the authority over their own game (excluding gambling, as above). 

IMHO the best use case I've come up with for a decentralised game economy is for a game that exists as a platform for many service providers besides the original developer. e.g. Many games allow you to host your own dedicated servers, so a 3rd party industry (not the dev) exists to service that... Or many games have tournaments that are organised by 3rd party companies... Or rely on user-generated content, etc... A decentralised game economy could allow players of the game to financially interact with these kinds of 3rd parties directly, in-game, without requiring approval from the developer. 

At the same time though, AAA publishers would probably balk at giving up control and would rather keep centralised authority so they can skim off these providers... 

Ethereum and Bitcoin are a hassle, need lot's of diskspace and are painfull slow.

Any blockchain that is popular will have exactly that same problem, because it's inherent in the design of the technology. If it's small and fast, then it's not popular, and if it's not popular, you will have a real problem trying to keep mining from becoming centralized such that a Sybil attack can take it over.

I'm currently employing some concepts I've taken from blockchain, hashing based proof of work(simplified of course) as my game employs resource mining in a server authoritative scenario it seemed the best way to prevent scripting/cheating(in addition to encryption).  I may use a "hash chain" to keep track of user generated content as well(much of it will be "chained" through linear parent/child relationships).  Still haven't decided if any of the consensus parts of the whole blockchain picture can give my game any benefits.  Either way I'm not using any established code, just using ideas I've taken from write-ups and technical documents/etc..  I think there are some really interesting things going on with blockchain code, just not sure that most of it is useful for my environment.

Happy Coding!

On 9/24/2018 at 2:26 PM, dalofs said:

Ethereum and Bitcoin are a hassle, need lot's of diskspace and are painfull slow.

Not a blockchain expert, but this is the inherent nature of blockchain. Since all ledgers are public, everytime somebody makes a transaction, they get added to the chain. The chain will grow and eventually gets really long, and transactions taking longer and longer since everyone must verify them.

If it's short and fast, that means no one is using it.

transactions taking longer and longer since everyone must verify them

You don't need to verify past blocks more than once, because they never change. You just verify the next block against the hash of the previous block plus the new transactions.

What makes the systems slower, is that the more popular they are, the more competition there is for the hash reward, and the harder the hashing needs to become to keep the reward challenging. Plus, if they get so popular as to fill up each block, then you have to start paying more to be included in blocks, which is another kind of friction. (Both BTC and ETH have seen this at times, in slightly different fashion.)

(I'm certainly no cryptocurrency expert either so add salt)
Etherium is heading for a disaster in that the data growth rate (the rate of rate of data) is trending to a point where eventually no one who isn't already a full node, would be able to become a full node (by the time you sync'ed the chain, it would be out of date). That would be a disaster so they're obviously scrambling for solutions, such as light nodes that don't need to know the full history (but rely on full nodes that do). Another thing that many networks are looking at are "side-chains", which basically adds the "fork and join" idea to the blockchain. Many of them are actually designed to be pegged against bitcoin itself, so you can do many fast transactions on the side-chain, but with slow conversions back-and-forth between the side-chain tokens and actual bitcoin. This basically allows bitcoin, being fatally flawed as a currency, to instead act successfully as a "store of value", while the side-chains successfully implement features required by currency.

That would be a disaster so they're obviously scrambling for solutions, such as light nodes that don't need to know the full history

Yes, Ether has the problem that any previous block may contain a smart contract that may trigger based on new inputs. Bitcoin is similar, because the state of the block chain grows by somewhere between the square root and linearly in the number of blocks, as people are encouraged to use new addresses for each transaction (rather than, say, allow a per-transaction destination memo to say who the payment was from for a purchase.)

Horizontal sharding could solve some of these problems for a more-or-less strict store-of-value system like Bitcoin, but Ether is kind-of screwed in that they are too flexible for their own good ?