Here's a game I've been thinking about adapting to the blockchain for a while. Not because it's fun or innovative, but simply because it's easy and almost 100% luck-based.
At it's core, battleship is simply two 10x10 grids (2-Dimensional arrays).
But, Privacy.
Battleship is also the most basic example of privacy required in the gaming space. How are people going to play battleship against each other if ship positions are freely displayed on the transparent blockchain?
As I was falling asleep last night I realized this problem is easily solved the same way my Captchain problem was solved.
Let's say your board was set up as shown above. You can't post this to the blockchain because then your opponent could cheat. Therefore, your opponent is forced to trust that you are telling the truth (just like in a real game of Battleship). However, unlike a real game of Battleship, no one will be able to cheat.
Instead of posting your starting locations on the blockchain at the begining of the game, you simply post a hash of your starting locations. For example:
B2, C2, D2, E2
I2, I3, I4
F4, F5, F6, F7, F8
B5, B6, B7
C10, D10
These are your starting locations. Now you hash them with SHA-256 (Bitcoin's hashing algorithm) to get:
B9A8B75CB11B955C7167B0FF2AE3D3CC88B758B7D20EABE14B870AA7B3BDAD19
This is what you show your opponent, and he has no way of reverse engineering this number to get the answer. How? By adding a nonce. A nonce is a "number only used once". The nonce variable is how Bitcoin miners are able to pump out trillions of hashes a second (they change the nonce then rehash quickly). In the context of Battleship, a nonce is your password. So your hash would be changed to:
B2, C2, D2, E2
I2, I3, I4
F4, F5, F6, F7, F8
B5, B6, B7
C10, D10
password123
Where password123 is the nonce. This would change the hash to:
8BE4F35FB005649C5DBA9D6AEB23FB616B3262B89E6D13CAC8B70551F5296B95
So, at the start of the game, this is what you show your opponent, and at the end of the game, to prove you didn't cheat, you show your opponent your starting locations with the nonce appended at the end. Your opponent (entire community) can then hash this secret key to verify that you didn't cheat.
How is this different?
Besides being able to bet on the outcome because it's attached to the blockchain, this gaming model trusts no central authority.
If you play Battleship online today you have to trust a central authority (the entity running the server). You have to trust that your positions are not being given away. You have to trust that there is no conflict of interest. This logic can be applied to all centralized applications. Online Poker is the most relevant example. There is a lot of distrust out there when money is involved.
Here at Steem we don't need to ask for permission. Can you imagine the regulation and overhead involved in gambling on a game of Battleship? It's easy to see why something like that has never happened and never will happen in a centralized setting. On the blockchain, things like this will start happening, and there will be no way to take them back or regulate them. You can't put the toothpaste back in the tube. Peer-to-peer gaming is so close to becoming reality and the world doesn't even see it coming.
Reducing RCs used.
In a classic game of Battleship each person has a turn. That turn consists of one player attacking and the other player saying hit/miss. Therefore, using this model, every turn would involve both players putting a custom JSON operation on the blockchain.
I'm not sure how expensive custom JSON operations are compared to comments. I assume they are significantly less because they cannot be upvoted or curated, but I'm not sure. It becomes obvious that even playing a simple game on the blockchain could add up and get expensive RC wise. Therefore, tactics should be employed to reduce this cost.
One way to achieve this is with the concept of adaptation from turn-based to block-based. Each player would attack and claim hit/miss on the same block. This opens up weird situations where players could kill each other at the same time and they also wouldn't know if their previous attack hit or miss until the next turn.
Variant games
Another way to lower RC cost would be to play a custom game where you can shoot once a turn for as many ships you have alive. This way at the start of the game each player would be shooting 5 times and the game would end much faster, requiring less JSON ops.
Yet another way to lower RC costs would be to declare your intentions in advance regardless of whether your previous attacks hit or miss. I keep these things in mind not only for Battleship but for all the possible games that could be put on the blockchain. If a game like Battleship became popular enough many might see it as a waste of resources and an attack on the platform.
Does a game of Battleship really deserve to be immortalized on the blockchain for all eternity by every node? Andreas Antonopoulos tells us that there are no good and bad transactions. There are only valid and invalid transactions according to the rules we create.
However, after HF20, it becomes obvious that we are running a fractional reserve on RCs. More RCs have been given than the witnesses can process. This will be an issue in the future.
Getting Started
I spend a lot of time talking and not a lot of time doing. I've been somewhat dreading the grind of hoping back on the development wagon. Steemit Inc. isn't helping. You want to know why I think @almost-digital wrote that fork that nullify ned's stake?
The main API of Steemit (written by @almost-digital) has been technically broken ever since HF20. Yet ned has the audacity to claim that he wants Steem to be developer friendly when they can't even keep the API up to date and nothing is documented and the tutorials are shit? Yeah... fml.
Dlobby Module
The first thing I need to do is create a lobby dapp finder module that will connect two or more people running the same dapp. In this context it would be two people looking to play a game of Battleship, but this module has to actually be modular and usable for wide variety of dapps. Wouldn't it be nice if the Steemit API wasn't garbage and I could simply trust it to handle this function? Yes, but also no.
Trusting the Steemit API means you are trusting that node with all your requests. This is obviously not a decentralized option. It would be much more ideal if each player was running a very light node and didn't have to rely on trusting anyone else.
Running a very light node.
In this context a very light node would be one that is only looking for relevant data; basically Battleship JSONs. It wouldn't need to remember anything else before or after the game. Unfortunately, there is still the issue of trusting the source of whoever you are downloading the blocks from (unless you verify those blocks on your own client, which kind of defeats the purpose of running a light node in the first place).
Soul Coin
Steem does not have customizable smart-contracts, so if I want users to be able to bet on games, I would have to create The Soul Shard idea I've described previously. In effect, the logic behind Soul Shards would be directly connected to dapps like Battleship, so when you lost a game you bet on, the Soul Shards would automatically be transferred to the winner and the loser would be obligated to buy them back with Steem or suffer reputation loss.
Back to reality
I'm still a gross JavaScript novice so I'll just make the single-player version of BattleShip first as a learning experience and worry about connecting it to the blockchain later. Considering this game is simpler than checkers it shouldn't be too hard.