It was pretty easy to set up the skeleton of a game that will run on the Huntercoin blockchain alongside the normal game. It will look like this and I think will be playable at block 1400000.


While the creatures are named after hunters, these hunters can be long dead. (theoretically they could also be anons)

Things to choose when making a new critter: fireball range for the lemures but at exponentially increasing mana cost (they have a lifetime limit),
tendency of the zombies to teleport away (but this will also bring them away from the gems), and randomness of movement.

Basically the game is about guessing the population dynamics several hundred blocks in the future.

Once sent into battle there will be no way to control the creatures and they'll live out their lives (on the blockchain)


Compared to "Allow Standard Names in Huntercoin" (http://forum.huntercoin.org/index.php/topic,22249.0.html)
this is the pirate version. Doable right now and, of course, no 1000 Huc fee per name  

The client only interprets the (blockchain chat) messages, and some regular "send coins" transactions. When I need "markers" then the method of choice is to have the client's open source code initialize gamestate variables at certain block heights. (to avoid preloading the gamestate with "secret" data)

Compared to the normal processing of tx's and game moves, there is no noticable performance impact.
(but betterQt client need an extra minute to start because the gamestate is pruned, would be 300MB to download if not)


I don't see any bot on the map, just human farmers (they probably use the stock version of Mithrilman's client)


Yes, this is very necessary.

I can't do rule changes. Only Snailbrain can do rule changes.

So, things like gems, chronoDollar or the AI market maker just using the existing framework, which is rather flexible (but not enough).

Current game rules reward being relentless in such an extreme way that the economic metagame (plus some other things) has choked normal
gameplay. (If someone don't believe this, just go out and play for several hours, win most fights with a kill to death ratio of 2:1, then look at your bottom line, and then guess your opponents bottom line!)

Thats why the game rules need to change asap, pruning is nice but by itself won't change a thing.


If you had the power to change 5 rules (in a simple way), what would it be?

Yes, it lives on the blockchain, or rather, all its data is saved there. If you start with an empty gamestate and replay the entire blockchain, then the marketmaker will be in exactly the same state as before. (for any given block height) There's also no server or similar for it, all calculations are done by the Huntercoin node.

I think alongside HUC is much easier, so many parts are already in place.

The game will be at first very simple: 2 factions (zombies and zombie hunter), the latter must make a kill every X blocks to not starve, the former is defenseless but has no needs. Both can take gems if they find them (they will all be dumb like Doom monsters)

And...send coins to yourself, and the conjured monster appears on map like magic, without a (live) hunter (exact amount determines what kind, spawnpoint, and behavior tweaks)

I hope this can be up and working in a month, and then regularly updating it and making it more complex will be fun. Running alongside Huntercoin makes this less difficult, only players need to update. (and they can't be forced to because there is no cost to run a Huntercoin add-on like this)

The antithesis to Huntercoin's gameplay is perhaps a game that does require (and allow) player input only at time of character creation.
This would be a programmable alife predator-prey simulation.

Once the (totally stupid, hence almost no memory or cpu footprint) critters are sent into battle, players can only watch. (but don't have to, in case of players with jobs)

It could run alongside Huntercoin, no player input also means almost no UI programming (not my thing)
A challenge is to make it so that no "hunter" is necessary to play (i.e. to communicate with the Huntercoin blockchain without a hunter)

The principle is similar to Bitshares really, including the 3:1 initial margin requirement for shorts. (*)

Main difference is probably, pegged asset and collateral is not conflated into one thing (bitUSD) but longs own both (like ES futures, you buy stock futures and keep the dollars, they only get "frozen")

Then, price data is only needed (and rewarded) every 10k blocks, so that feed can be done manually by players without cost or special expertise.
This also means settlement (getting in or out at a fixed price) is only possible every 10k blocks.

And I included a "free insurance" against drop of gem price while getting out (would not be needed if the in-game markets had lots of liquidity) The entire system is too complex to describe in a single post, just watch it in motion, it's fascinating

(*) the short in this case is a NPC (one with no visual representation in-game yet)

If you think about it, this could be the first AI in history who (and not just it's human masters) owns something, assuming code changes to steal his stuff are generally unacceptable, and Ether didn't have a bunch of these guys earlier.



If a player (and their hunter) can enter contracts involving "loot" (i.e. the coins they pick up around the map, before banking them) it must not be allowed to just walk the hunters to bank and take it away. And impossible for the hunter to die and lose the loot.

This would require a hardfork that must also specify exactly what can be done with the loot.

In a way, currently they instantly autobank. It's the privkeys in the player's wallet that decide who can do stuff, like sending to other addresses, or trade.


Theoretically, I would do the "bring coins already banked back into the game as loot" thing in the way that you can send coins to a coin-eater address that is associated with a hunter's name address, and the coins get re-issued to that hunter as "loot2_deathtax_already_paid". Naturally, this hunter wouldn't want to walk around on the battlefield.

I started a test: the task is to convert 50 USD worth of HUC into a fiat-pegged form aka chronoDollar, hold it for 2 weeks, then convert it back, avoiding all fees or slippage if possible.

Let's see if a Huntercoin add-on can do this better than the big inspiring example, which in this case would be Bitshares, and where the bugs and shortcomings are.
(also updated readme.md for www.github.com/wiggi/huntercoin and did my best to explain what the advanced mode is and how to get it)

I'll post and comment on every step here.


Part 1

We don't have a slick, stylisch black UI, only plain text files. (I guess it's not too difficult to have some NPCs project the order books over dark water, in-game) On the bright side, no spreads to pay between settlement prices and lowest ask.

For the test I used a new hunter ("Cortez"), and a new name address. The first 2 of the orders (they also show up in www.huntercoin.info/blockExplorer Recent Block Chat) were sent with the auction bot (the auction bot also sent the correct amount of coins), the third manually copied from adv_chrono.txt. It's a 2 step process, first gems, then chronoDollar.

The order to buy 50 chronoDollar "at settlement" was filled at chronon 1360001 at a rate of 0.0505 chronoDollar per gem, with the AI market maker acting as counterparty. (it's an altruistic market maker, giving buyers and sellers exactly the same quote, once per 10000 blocks)

Cortez got a "liquidity reward" because the standing sell order at 1980 was in need of buying ("old" and at settlement). Weird rule...

adventurers.txt

Adventurers who own something are what would be called "delegates" elsewhere, and can do price feed (once per 10000 blocks)

This was also the "median feed", and the rate of 0.0505 was calculated from this and the gem / HUC settlement of 1980.

adv_chrono.txt

Reward for feed was paid at block 1360050. Currently, Cortez is long 50 chronoDollar (which is a futures contract) and owns 2.94 gems (an asset).
Sadly, in Huntercoin, hunters cannot own Huntercoins. This would make things so much simpler

There was a time when Ripple (with the help of coinmarketcap showing the full not so available supply) came very close to Bitcoin's market cap. 10% or so difference, for a very short period. I don't think stronger and stronger competitors are a trend, otoh probably nothing is safe or guaranteed.

Perhaps it's better to also wait until next update of game rules. Currently new players would just have a bad experience and they won't come back. (and tell everyone they know how much the game sucks)

3 or 2 month ago the "game doesn't allow to stop playing" was the main issue, but now there's a worse one: the 20HUC destruct fee will drive every new player into "playing at a loss" territory. Specifically, noobs will not be able to avoid combat with a group of players that has always 60...80 hunters, and it's too easy to deliberately abuse the destruct fee to make everyone else not coming back next day, so they get really all the coins.

These 2 issues need to be fixed asap, and before that, anything to promote Huntercoin, or to make playing easier with a lite client, would only backfire.

I think you'll have to build latest version from source https://github.com/domob1812/huntercore
(can be done exactly the same way as with latest Bitcoin-Qt)

When fully updated, make sure to have a copy/backup of the entire blockchain. Easy to damage even without power failure
(e.g. "Temporarily allow all this page" -> VM freezes -> bricked. Mount external drive to VM while blockchain on drive is online -> bricked)
I do this at least once per week.

Specifically a nerdier, turn based, World of Warcraftish MMO. One that is just as motivating for players, just as accessible for new players, doesn't make all players the dev's bitches, and with an in-game economy that is not a joke but for real. It's possible if we want it (and if we do look at what WoW does gameplay-wise and what it would never do).

In a decentralized game, you can't hide portions of the gamestate. If the game is designed to be decentralized, the gamestate can be made to contain as little information as possible (enemies spawn only at FoV perimeter and despawn if not visible for X turns, items in containers spawn only if opened etc)

If the game is off the shelf with only minimal modifications, then players would have clairvoyance from the start and know everything the gamestate knows. I don't think this makes the gap between human and bot performance smaller. The more you know, the more you can make strategic plans that would never occur to a bot. You "see" if a specific level or area is worth cleaning out or not when every turn counts.


Otoh, there has never been a monetary incentive for making such a bot, and I've not yet seen a bot that would do systematic savescumming every time it thinks the RNG made a decision that is less than optimal. No one knows how good these buggers get if coin can be won.


Btw, to clarify: "gamestate" here has nothing to do with the Huntercoin gamestate, right? Only the collected player input (2000 or so keystrokes) would be part of it, until it gets replayed by an encapsulated part of the Huntercoin client (which may mostly consist of the original off the shelf game code). The result of the replaying (just "ok" or "invalid") is also saved in Huntercoin gamestate until reward is paid to the winner with the shortest string of keystrokes.


edit: quickly verified by a computer == CPU budget would be a few microseconds per turn, or <100 milliseconds per game replay, and the code must be trusted to not crash

I'm also sure a solution exists. (One that could be of actual use for Huntercoin)


(*) my assumptions, didn't play or do source diving.

Motocoin uses block hash (*) to seed the RNG for creating a level, and when the first player has solved it, they submit the result: the complete player input,
keystrokes (*) with timestamps (*) measured in terms of ticks of the game's physics engine (*). Verifying a block means replaying the level to see if the submitted player input solves the level.


The standard example of a un-bottable game would be Nethack, but it takes at least some hours + expert skills to solve.
(result is also a bunch of keystrokes, quickly verified by a computer)

If the game is simpler (but still a turn based "roguelike" game) and bots can win, they need less time than a human, but more game turns.
Example: Angband bot, if very lucky: 10.000.000 turns, Human expert: 50.000 turns

If the game is too short (same turn based "roguelike" game) then bots can simply try every possible action and brute force (if it's possible to win in ~100 turns)
Example: You start as high level char in the deepest Angband dungeon level, but stripped of every possession: try to escape as fast as possible.


Huntercoin doesn't need the result for the next block, it could create a random "instanced area" once per day, hunters that would enter this area would be alone, playing a (local) single player game against (deterministic) computer controlled monsters. Only after winning, results get posted to the blockchain, and only after the day is over, the fastest winner (in terms of game turns) get coins. (game turns != Huntercoin blocks)

The number of game turns would have a (not too low) target value, fast win today == extra nasty dragons tomorrow.

to clean up the confusion, on a new Linux (tested with Mint18 in a VM) the build process for Huntercore is exactly the same as for Bitcoin. Installed dependencies decide of whether the Qt-client is made:

Need right-click on desktop|Create Launcher to execute the resulting /home/workgroup/huntercore-master/src/qt/huntercoin-qt
(default working dir is .huntercoin but should probably be .huntercore)

To work with the pruned blockchain from http://forum.huntercoin.org/index.php/topic,22255.msg26622.html#msg26622
it needs a huntercoin.conf to get connections and to not insist on reindexing which would take almost as long as chain download, e.g.

It really exists. Huntercore-Qt (with qt5, capable of autodetecting and using all kinds of GPUs)

Awesome

I think your posts are a very interesting read, you shouldn't delete them.

Even an "empty" Huntercore Qt client with only a console window and nothing else would be valuable for the development of a modern Huntercoin Qt client. But there's probably a good reason why Namecore/Huntercore don't use Qt at all.

Using the RPC interface from the core blockchain daemon is moderately difficult, keeping the old client code compatible seems to be the easiest option for now.

It's feasible to rebase the non-gameplay, trading stuff on the Huntercore codebase of course.

I still think the way to do it is a "spectator mode" for hunters, this has all advantages of the standard names, plus:

You probably could upgrade the client (give hunters the choice to be suspended from killing, being killed, and harvesting coins; easy implementation)

Hunters can switch modules, and communicate with hunters from other modules.
Example: no matter what they are currently playing, they can short chronoDollars (== use this particular "module") because, as hunters, they are in the main player loop, and show up in all clients. Standard names can't do that.

Can trade loot from one module for zorkmids from another module (if the module developers allow it)

And spectator mode solves the logout problem too

Any person can play because the game is so simple, or any person can play because no coins required to play?

What are other examples, would you say a game like the original Rogue (the gameplay, not the old-school interface) is also so simple that anyone can play? (if you don't need coins to start playing)

I was under the impression that Huntercore can be built as a windowed, Qt- based executable only in principle, but without functionality for gameplay.
To play, you must plug another client into it. The advantage is, players on Windows get a stable system (using MithrilMan's client) and a smaller initial download.

This would be fine and dandy if Snail would vow, in case of a game rule change or other hard fork, to update the old Qt-client so it remains compatible. Otherwise it's a plan to burn bridges and force everyone to play the game using proprietary software, at least for some time.