[ANN][HUC] Huntercoin - Worlds First Decentralized Game/World on the Blockchain

[wiggi]

Again where to find the documentation regarding rules in the game?😂

I've actually been recommending his client to beginner players because of the tutorial inside. The core client has instructions at this link, but they're out of date, now. Mainly, generals are no longer a thing--they're all called Hunters--and destruct doesn't kill you, but instead drains surrounding hunters' life

sounds like a lot basic work to do

A technically accurat description of 90% of the current rules is in domob's GameLogicChanges.txt.

No, it's not a picture book for beginners.

[ShooterXD]

Hi sir, do you need a portuguese translation to your thread?

I hit you a pm.

CYA

[wiggi]

Design of the zombies vs lemures arena, normal obstacle map will be used.



It's almost finished. With 20 critters alive on testnet, it looks rather empty. (and given how stupid they are, interactions are rare)
I guess 50-75 would be a good balance for this small section of the map.

The critters will compete with hunters for the old gem spawn (0.86 gems per day) and they will compete among themselves for the new gew spawn (4.8 gems per day)

A new creature is always spawned if an address in the adventurers.txt list receives >3000 coins. These coins can be immediately recycled to spawn more creatures.
Amount must end with the magic number "5501" but other than that, any amount would result in a valid critter. (offspring and random mutations ahoy!)

this list has also some stats for the critters

Code:

 Inventory (chronon  328727, testnet)
 ------------------------------------

                                                                                   (raw coin amount)
                                          hunter                         conjured           magic
storage vault key                           name      gems    outfit     creature  order    number   chronon   position  life  magicka

hd9Wpfswhp89MXaivoNnotbZeUzd3RbrA5          gaga      2.75          -      lemure  4035.0000 5501    328180    474,234    144       0

Setting the eight numbers in the "order" column is all you can do for a creature. This is the point (to demonstrate how to kill all botting and farming with fire)

The hunters here can be long dead. And for the start on mainnet at block 1400000 I can set up any address so that it's ready to go, and no interaction with hunters in the normal Huntercoin game is needed.
Just send me PM with an address.

I'll also come up with a technical description of what all the numbers actually do

[bucktotal]

wiggi,

whats your preferred donation address ?

[wiggi]

whats your preferred donation address ?

I don't have one. What I meant was that forum readers can send me one of their Huntercoin addresses and I'll set it up to play the zombie vs lemures game right away.

The method to set it up yourself is

- get the betterQt client (link in OP)
- read the 2 readmes, start client in advanced mode
- make an hunter and visit the tile where Tia'tha the dark elf stands (currently on the right side of the map)
  (then the address is the one where the hunter was transferred to, see "Config.." button)
- alternatively, make an hunter, check out "auction.txt" and have the hunter buy some gems (at least 0.1 but feel free to load up, this would also complete this https://bitcointalk.org/index.php?topic=435170.msg16080926#msg16080926 test and really help)
  Then the address is also the one where the hunter is transferred to

Later (after block 1400000) in order to play the 3000+ HUCs have to be sent to this address. I.e. to yourself 

[_Django05_]

Subscribed.

I might try this one of these days.

[bucktotal]

whats your preferred donation address ?

I don't have one.

well, what i meant was, i'd like to donate some HUC to you for all your hard unpaid work. up to you though

[The Bitcoin Co-op]

By the way guys, I made a website to promote blockchain-based video games, and obviously Huntercoin is featured heavily. Check it out and let me know if you wanna help me work on it: http://www.blockchaingaming.com/

Design of the zombies vs lemures arena, normal obstacle map will be used.



It's almost finished. With 20 critters alive on testnet, it looks rather empty. (and given how stupid they are, interactions are rare)
I guess 50-75 would be a good balance for this small section of the map.

The critters will compete with hunters for the old gem spawn (0.86 gems per day) and they will compete among themselves for the new gew spawn (4.8 gems per day)

A new creature is always spawned if an address in the adventurers.txt list receives >3000 coins. These coins can be immediately recycled to spawn more creatures.
Amount must end with the magic number "5501" but other than that, any amount would result in a valid critter. (offspring and random mutations ahoy!)

this list has also some stats for the critters

Code:

 Inventory (chronon  328727, testnet)
 ------------------------------------

                                                                                   (raw coin amount)
                                          hunter                         conjured           magic
storage vault key                           name      gems    outfit     creature  order    number   chronon   position  life  magicka

hd9Wpfswhp89MXaivoNnotbZeUzd3RbrA5          gaga      2.75          -      lemure  4035.0000 5501    328180    474,234    144       0

Setting the eight numbers in the "order" column is all you can do for a creature. This is the point (to demonstrate how to kill all botting and farming with fire)

The hunters here can be long dead. And for the start on mainnet at block 1400000 I can set up any address so that it's ready to go, and no interaction with hunters in the normal Huntercoin game is needed.
Just send me PM with an address.

I'll also come up with a technical description of what all the numbers actually do

I just Googled "lemure" and found out its a creature from Dungeons & Dragons, haha. And I thought I was a nerd... I have some dumb questions, though, in my eternal quest to make you explain what you're doing to everyone:

1.  This game map looks like the original Huntercoin map. Will players using your client see players not using your client (or rather, their Hunters) walking around? If so, I would assume Hunters and creatures still can't interact--only compete for gems, the consequences of which Core players won't experience. Would it be possible to let players control zombies/lemures?

2.  What exactly are you showing us in that code box? The status of a particular Hunter according to your client? Where it says "conjured creature" (not plural), does that mean a single Hunter can only have one associated creature? Why does the sent coin amount have to end in 5501, and in what manner does changing it affect the stats of a creature? You said things like fireball range and teleport frequency are adjustable.

whats your preferred donation address ?

I don't have one.

well, what i meant was, i'd like to donate some HUC to you for all your hard unpaid work. up to you though

If he really doesn't want to claim it, you can know that any coins sent to HHtjGBUtxriDHmoHuoNDdLHwyNWVWkW8oS will be used for development bounties & marketing. We're working on a way to ensure that interested developers such as wiggi are compensated.

[The Bitcoin Co-op]

Huntercoin's trading volume has reached historical levels, and its market cap is reaching them quickly. The only reason the price hasn't is that there are now more coins in circulation. Still, reaching the historical market cap would double their value, since they're directly correlated.

[wiggi]

my eternal quest to make you explain what you're doing to everyone

Please keep doing this. I usually reckon it's better to wait for questions than to write walls of text that no one would read...

1.  This game map looks like the original Huntercoin map. Will players using your client see players not using your client (or rather, their Hunters) walking around?

Their hunters, yes of course. Would be really bad if you can't see them.

If so, I would assume Hunters and creatures still can't interact--only compete for gems, the consequences of which Core players won't experience.

Correct.

Would it be possible to let players control zombies/lemures?

Yes. I deliberately don't allow it, so that players with more time on their hands don't have an advantage.

2.  What exactly are you showing us in that code box? The status of a particular Hunter according to your client? Where it says "conjured creature" (not plural), does that mean a single Hunter can only have one associated creature? Why does the sent coin amount have to end in 5501, and in what manner does changing it affect the stats of a creature? You said things like fireball range and teleport frequency are adjustable.

It's not the status of a hunter.

Once, a hunter with this name and this player address (or reward address) acquired a gem (of a fraction of a gem). And because of this, his name address and gem amount was memorized forever, in the gamestate and implicitly in the blockchain.

Thus creating a game entity that is similar to a hunter, but different. It's indestructible (hence the name "storage vault") and more complex than a hunter (has more variables and can hold more information)

The line in the code box shows the status of one of these.

The coin amount gets translated into the initial stats of the creature (e.g. the second digit will set the position to one of the 9 available spawnpoints)

This spawn method (as opposed to, for example, a hunter transferring to the vault address and sending the msg "VAULT:spawn fire dragon, spawnpoint 4, spell range 7" etc), the 1 creature limit, the magic number, is just arbitrary, how I programmed it.

The storage vault system is very flexible. Nothing prevents a vault from playing 10 different games at the same time, having spawned dozens of characters. Well, someone must code these games, and block processing time sets a limit, but it's rather high.

[MithrilMan]

Once, a hunter with this name and this player address (or reward address) acquired a gem (of a fraction of a gem). And because of this, his name address and gem amount was memorized forever, in the gamestate and implicitly in the blockchain.

Isn't the opposite?
What is stored in blockchain, then could (depending on custom modified huntercoin daemon) reflect on gamestate? Because gamestate is obtained from the blockchain and not the opposite
This is why I don't understand how this could work without having implemented a mechanism that store your custom data in ANY huntercoin blockchain, because if you imagine that in a precise moment, your custom game players are composed by just 1 single player (just an extreme example), no other nodes (standard clients) have historical custom data to send back to your custom client, so this ends up in not being synchronized with your custom game because you lack information, but you don't know that for sure because for your daemon the synchronization is fine because you received standard huntercoin blocks and transactions.

Where did you actually store your custom data? if you don't include them on standard transaction, than you are just playing on a fork (is this intended? I think isn't good because it causes players fragmentation and this isn't something we wants I'd say). This was really like having a forked client that accept standards huntercoin tx AND stores custom data (with the limit that this could works only if there is at least 1 connected node with full custom game historical data to send to new connected players)

Instead if we introduce the chances we are talking about (namecoin style name/value) then your custom logical transaction could be sent updating your custom game names data

But here problems arise about blockchain bloating, but this is another matter

Can you clarify your "custom game" vision, in therm of lifecycle/boundaries of your data and how this propagate on standard nodes?

P.S.
my custom game client, is written above the RPC infrastructure, so i could even create custom graphics to handle custom huntercoin daemon like your, but i'm worried about players fragmentation and confusion

[wiggi]

Where did you actually store your custom data? if you don't include them on standard transaction, than you are just playing on a fork (is this intended? I think isn't good because it causes players fragmentation and this isn't something we wants I'd say).

Relax, the blockchain is the same, and the coins are also the same.

Fortunately, the blockchain chat messages allow to store "extra data" in the blockchain that has no meaning for the coin.
(transaction messages would serve the same purpose)

This is why I don't understand how this could work without having implemented a mechanism that store your custom data in ANY huntercoin blockchain, because if you imagine that in a precise moment, your custom game players are composed by just 1 single player (just an extreme example), no other nodes (standard clients) have historical custom data to send back to your custom client, so this ends up in not being synchronized with your custom game because you lack information, but you don't know that for sure because for your daemon the synchronization is fine because you received standard huntercoin blocks and transactions.

You are mistaken about the "custom data to send" part. There is nothing to send.

Both standard clients and betterQt or any other hypothetical "non-standard" client receive standard huntercoin blocks and transactions, and only standard huntercoin blocks and transactions.

If the custom game players are composed by not 1, but 0 players, and the network consists of only standard clients, the custom game would continue normally (even if no one is there to watch, and physically the calculations are done only when a non-standard client catches up with the blockchain)

[Murch]

Hi, I have some questions if someone would be so kind as to answer.

I see in the initial post that HUC has a supply cap of 42m coins, but there's no mention of a tapering of the block reward. Will coins be distributed to the game world and miners solely from hunter deaths and other fees past that point, or...?

And with the current cost of 200 HUC to summon a hunter plus the price where it is right now, it's about $3-4 per hunter. If the game scales up to more players in the future, I can envision a stable price at least 10x what it currently is. If the goal is to make the game accessible to as many people as possible, how could the average player be expected to throw down $30-40 (or more) for a single crack at playing? Is there some plan in place to address radical changes in HUC value? Or is this not actually a problem?

From what I understand, the game becomes prohibitively more expensive as it increases in popularity. I very much understand where Huntercoin is coming from from a conceptual standpoint. I just don't understand it from an economics standpoint.

[The Bitcoin Co-op]

I see in the initial post that HUC has a supply cap of 42m coins, but there's no mention of a tapering of the block reward. Will coins be distributed to the game world and miners solely from hunter deaths and other fees past that point, or...?

I'm pretty sure the block reward does taper off like Bitcoin's, actually. Everything is just doubled.

And with the current cost of 200 HUC to summon a hunter plus the price where it is right now, it's about $3-4 per hunter. If the game scales up to more players in the future, I can envision a stable price at least 10x what it currently is. If the goal is to make the game accessible to as many people as possible, how could the average player be expected to throw down $30-40 (or more) for a single crack at playing? Is there some plan in place to address radical changes in HUC value? Or is this not actually a problem?

From what I understand, the game becomes prohibitively more expensive as it increases in popularity. I very much understand where Huntercoin is coming from from a conceptual standpoint. I just don't understand it from an economics standpoint.

This is a problem, yes. We are already discussing what changes to make in the next fork after Huntercore on the Huntercoin forum. Lowering the fees was one of the first things agreed upon, although by exactly how much, we're not yet sure.

[Murch]

And with the current cost of 200 HUC to summon a hunter plus the price where it is right now, it's about $3-4 per hunter. If the game scales up to more players in the future, I can envision a stable price at least 10x what it currently is. If the goal is to make the game accessible to as many people as possible, how could the average player be expected to throw down $30-40 (or more) for a single crack at playing? Is there some plan in place to address radical changes in HUC value? Or is this not actually a problem?

From what I understand, the game becomes prohibitively more expensive as it increases in popularity. I very much understand where Huntercoin is coming from from a conceptual standpoint. I just don't understand it from an economics standpoint.

This is a problem, yes. We are already discussing what changes to make in the next fork after Huntercore on the Huntercoin forum. Lowering the fees was one of the first things agreed upon, although by exactly how much, we're not yet sure.

Thanks for the quick response. I'll read through that thread and see if I can think of anything to contribute.

[MithrilMan]

Where did you actually store your custom data? if you don't include them on standard transaction, than you are just playing on a fork (is this intended? I think isn't good because it causes players fragmentation and this isn't something we wants I'd say).

Relax, the blockchain is the same, and the coins are also the same.

Fortunately, the blockchain chat messages allow to store "extra data" in the blockchain that has no meaning for the coin.
(transaction messages would serve the same purpose)

This is why I don't understand how this could work without having implemented a mechanism that store your custom data in ANY huntercoin blockchain, because if you imagine that in a precise moment, your custom game players are composed by just 1 single player (just an extreme example), no other nodes (standard clients) have historical custom data to send back to your custom client, so this ends up in not being synchronized with your custom game because you lack information, but you don't know that for sure because for your daemon the synchronization is fine because you received standard huntercoin blocks and transactions.

You are mistaken about the "custom data to send" part. There is nothing to send.

Both standard clients and betterQt or any other hypothetical "non-standard" client receive standard huntercoin blocks and transactions, and only standard huntercoin blocks and transactions.

If the custom game players are composed by not 1, but 0 players, and the network consists of only standard clients, the custom game would continue normally (even if no one is there to watch, and physically the calculations are done only when a non-standard client catches up with the blockchain)

I'm not worried about HUC coins but about custom gamestate correctness but even more on junk transactions:
if only your nodes can validate your custom transaction (in therm of content and not on cryptographical correctness) this mean that huntercoin can't discharge invalid game transaction because huntercoin doesn't know custom game rules, so you could easily see (if some wants to ddos is very easy) lots of junk transactions (maybe even not malicious one but because of a program error) and you'll see a 1000 transactions block of nonsense data

anyway i'm writing on the other forum about a proposal for rulesets definition, that can't resolve this issue (with current huntercoin features) but can help in future and can ease the validation process even now

[The Bitcoin Co-op]

I'm not worried about HUC coins but about custom gamestate correctness but even more on junk transactions:
if only your nodes can validate your custom transaction (in therm of content and not on cryptographical correctness) this mean that huntercoin can't discharge invalid game transaction because huntercoin doesn't know custom game rules, so you could easily see (if some wants to ddos is very easy) lots of junk transactions (maybe even not malicious one but because of a program error) and you'll see a 1000 transactions block of nonsense data

His client just uses the client's built-in messaging system and send coin transactions to interact with the blockchain... if somebody wanted to DDoS or bloat the chain, they could already do that. There is nothing stopping anybody from inserting data into the blockchain as they please, so long as they're conforming to the protocol. Let's hope they don't.

Unintentional bloat seemed like more of a concern to me, so I asked wiggi about that a few pages back. He claims it's having very little effect on block size, at least when working as intended.

[no-ice-please]

Maybe some interesting links on this website http://ai.eecs.umich.edu/ will help devs.

add
There is huge money available for grants in fields in which Huntercoin develops. Some single grants are worth more than the Huntercoin marketcap, e.g. http://www.eecs.umich.edu/eecs/about/articles/2016/Jenkins_NSF_Grant.html . Generally these grants go to academics, but a good grant writer who was familiar both with ai and Huntercoin could probably snag some, if his or her credentials were decent.

http://www.nsf.gov/news/special_reports/robotics/

[wiggi]

Cortez's test (https://bitcointalk.org/index.php?topic=435170.msg16080926#msg16080926) is finished.
he had 2.78 gems + 0.11 immature gems (from trading profits) and requested settlement of 2.7 (at 1980 per piece = 5346)

The automatic process went like this:
liquidity fund grabbed 0.5 of his gems
auctioned off 2.2 (sold at 1260 = 2772)
liquidity fund auctioned off 2.0 of it's own coins for Cortez (sold at 1250 = 2500)
Cortez was paid a total of 5272 coins (remaining 74 is 74/1250=0,0592 gems, less than auction minimum of 0.1 gems, refunded 0.05 gems)
he still owns 0.08 + 0.11 + 0.05 = 0.24 gems

This is also the intended behavior, not perfect but it works.

I just Googled "lemure" and found out its a creature from Dungeons & Dragons, haha.

I think these guys don't really like each other, and the map had a balancing problem: it was possible to spawn a group at "lemure spawnpoint #1"
shortly before the "new gem spawn" resets, this pretty much would always succeed.

So the rules are now updated (and a technical description in the readme)

"2 lemures, if in spell range, will pelt each other with a weak lightning attack for (1d8 - 1) damage per chronon." 


It will run together with the normal Huntercoin game in the client, and I think they won't step on each others toes.

I'm not worried about HUC coins but about custom gamestate correctness

There's a strong way and a weak way to enforce gamestate correctness.
The strong way is, when any code is changed, also to put more variables in the gamestate (to make an incompatible new version, currently it's the 4th version) and generate a new gamestate from scratch by replaying the blockchain. If done, everything must look exactly like with the previous version of course.
The weak way is a shelf-life for the client (Use it 1 block longer and it puts a big warning on the Huc:Gem auction page that doesn't go away, because the gamestate has missed data and is no longer correct)

Unintentional bloat seemed like more of a concern to me, so I asked wiggi about that a few pages back. He claims it's having very little effect on block size, at least when working as intended.

It's usually 1 trade = 1 or 2 transactions.
And 1 creature = 1 tx. (for it's entire lifetime)

[The Bitcoin Co-op]

There is huge money available for grants in fields in which Huntercoin develops. Some single grants are worth more than the Huntercoin marketcap, e.g. http://www.eecs.umich.edu/eecs/about/articles/2016/Jenkins_NSF_Grant.html . Generally these grants go to academics, but a good grant writer who was familiar both with ai and Huntercoin could probably snag some, if his or her credentials were decent.

http://www.nsf.gov/news/special_reports/robotics/

Do any of us have credentials? I think we're just a bunch of hackers, but it's worth asking.

I just Googled "lemure" and found out its a creature from Dungeons & Dragons, haha.

I think these guys don't really like each other, and the map had a balancing problem: it was possible to spawn a group at "lemure spawnpoint #1"
shortly before the "new gem spawn" resets, this pretty much would always succeed.

So the rules are now updated (and a technical description in the readme)

"2 lemures, if in spell range, will pelt each other with a weak lightning attack for (1d8 - 1) damage per chronon." 



It will run together with the normal Huntercoin game in the client, and I think they won't step on each others toes.

Soo basically you made the lemures start killing each other with lightning because you thought there were too many or they were too powerful compared to the zombies?