How can clever gameplay design hide technological inadequacies?

[DecentralisedGaming]

We know that blockchain technology isn't the best for speed right now, although there are some interesting innovations in the R&D stage (rollups etc). Until these technologies are widely tested and deployed, we might need to come up with gameplay reasons why a game is slow at certain times. Basically, coming up with a story as a reason for keeping a player immersed even though the real problem is technology.

Let's brainstorm ideas where and see if we can whittle them into something useful for the book.

Slowness / block time

• Abstract network lag as a need-to-wait story element, such as "strong wind in a desert so you have to wait it out".
• Abstract block confirmation time as some maturation time story line for an in-game item. E.g. smithing an item will take time, so the character graphic can be hard at work while the human player waits on the next block.

Transactions Fees / Costs

• Can be disguised as food (cf. http://ethernal.world/). You need to buy food to play. If you run out of food you are hungry and can no longer move.
• In a multi-chain game, the fees to play could be different. So different kings exert different taxes. It could perhaps be one chain too.... although it might be strange if gas costs are not the same everywhere.
• Perhaps high loot areas have higher tx fees / gas costs? Some of these tx fees can go to a pool that then subsidizes the costs for new players to join. Having a free-to-play solution in a decentralised game is tough. This is perhaps one mechanic.

Staking

• If players owned an inn, they could have NPC guests that pay rent. You need to stake(?) to buy the inn perhaps, and the NPCs pay you a reward (inflation for staking).

Fundraising

• Devs need funding, but that's tricky for a decentralised game that's already running. ICOs/pre-sales are probably not a long term solution. Perhaps some of the block reward goes to the developers. This could be like a King taking some tax from the citizens.
• If food = tx fees, then some of that food could also be paid to the monarch.
• A popular game has a lot of eyeballs on it. A real-world company could pay for advertising to the player base, which could be outside of the game, but the company could donate money to each player to cover some transaction fees. The gameplay reason is that crop yields were good this year so everyone has more food. An in-game company / guild, might want advertising too!
• Filecoin mechanism to incentivise full-nodes. The story justification is something like: the player is a land owner who receives a tax from NPC residents.

(anti-)Botting

• Bots can be a problem and require careful consideration to combat. However, there might be a way to include bots in a good way that also has a gameplay aspect: Players could just buy or rent the bot script and in the game, which controls an NPC. Naturally they need food in order to work. - h/t: @Codie-Petersen
• Allowing for PVP can help to reduce bots too. Players tend to be better at PVP than bots.

[Codie-Petersen]

(anti-)Botting

• If the game design permits, the concept of bots can be programmed into the game rather than programmed out of the game. You can lessen the severity of the bots by requiring action fuel, like food or wages, or you could even make the design require equipment for the bots to do anything useful. For example, a bot with only his fists can not mine or fight, so you must by him a sword or a pick axe.

[yanganto]

Slowness / block time

• A small sub-game is also good to cover the slowness problem. For example, there may be a 1~2 minute 2D maze for the scene changing in a third-person shooting escape game.

[DecentralisedGaming]

Anti-botting - Speed tax

Actions could get more expensive the close they are in time. So a burst of actions would be more expensive than those wider spaced in time. It is a rate limiter that increases the cost whenever a single agent is generating a lot of traffic. It wouldn't completely mitigate bots, but reduces some of their edge over humans.

Where bots can easily outclass humans then perhaps the game suffers, while if they are evenly matched then humans shouldn't be as annoyed.

This could be represented as an exhaustion bar. (h/t: @KillariDev)

Some games have something like an exhaustion bar, where if you do many actions at once you get tired quicker, then need some time to recover. Of course, that needs to be coded in a way that everyone can verify each other's exhaustion bar.