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.)

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!

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 ?