Topic: [ANN][HUC] Huntercoin - Worlds First Decentralized Game/World on the Blockchain - page 56. (Read 879724 times)

It's ready for mainnet now. Newest github or Windows build from today (20160925, linked in github readme) is required.

Works with the same blockchain files as Huntercoin v1.3, but not Huntercore yet. Copy the gamestate file game_sv4.dat to the data folder (where game.dat already is).
And the blockchain must be equally or more up-to-date than the gamestate file (or it may crash)

For the anonymous zombie in the pic, I did "Receive coins"|"New Address", which happened to be "HSoxogPWFQCyApNzcQMQPCMV9c9FBDLWru".
Then I did:

sendtoaddress HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX 250 comment1 comment2 "GEM HSoxogPWFQCyApNzcQMQPCMV9c9FBDLWru"

to create the storage vault at this address.

and then sent 3023.60005501 HUC with the normal "Send coins" tab to HSoxogPWFQCyApNzcQMQPCMV9c9FBDLWru

3023.6000 is actually not a good order, 3025.8000 would make the zombie wait and teleport earlier.

Also there's no point in making lemures until at least 18..20 zombies exist and 1 or 2 are near the spawnpoint, because lemures have only 100 blocks before they must make their first kill.



The big 4-gems prize will spawn for the first time at block 1400976



edit: all stats are now in adventurers.txt, including how successfull a creature was during its lifetime

Sounds super neat wiggi, but I have a hard time grasping all the details. I'll try to give it a shot when you make a mainnet version. Will it work with the same blockchain files as huntercore (I know it's same blockchain, but are you storing/parsing anything differently I guess)?

More like they can do a speedrun if in a group. Then players could just send them at the optimal time, but I want that it requires some strategic thinking to win.

I also thought that probably no one will play this because it's too much hassle to set up a vault when you first need to make a hunter and all.

Then there is this line in the console help:

What tag? Could it be... a transaction message? (it is) So I added another function that allows instant storage vault setup just with coins, no hunter. Readme will read as follows:


New: instant creation of storage vaults (20160923)
enabled on mainnet after block 1400000
======================================

(Cortez's test continues, first part was conversion of gems to coins at a fixed rate, see
https://bitcointalksearch.org/topic/m.16312993)

After block 1400000, it will be possible to convert coins to gems at a fixed rate,
instantly, trustless, and with a single (atomic) transaction.

While Cortez's Huntercoin address (HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX) still belongs to the
same user (wiggi), it's also a game entity now, and can act independently
with no need of a specific node being online.


Example use (see also "help sendtoaddress" in the client's console window):

to send gems to the storage vault of "some_huntercoinaddress" (will be created it not already existing):
sendtoaddress HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX coin_amount comment1 comment2 "GEM some_huntercoinaddress"

to donate 1k coins worth of gems:
sendtoaddress HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX 1000.0 comment1 comment2 "GEM HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX"


Notes:
- the coin:gem rate is variable and taken from the in-game auction settlement
- standard fee of 0.02 gems for storage vault generation applies
- this function uses the "transaction comment", aka OP_RETURN
- in Huntercore client and daemon, sendtoaddress command is different.
  They probably can't be used for this right now.

- Each gem bought will result in -1 "immature gems from trade P/L" for Cortez, with a hard limit of -100
- the total amount of gems in existence will be unchanged (but short term spike of gems in circulation is possible)
- The adventurers inventory page (adventurers.txt) will state the available amount,
  recalculated for each block


Thats about it. We'll see if it really works on mainnet. But that's the way to do smart contracts in Huntercoin, by making a modded client. I'd have no problems to run several of them at the same time if my "accounts", perhaps addresses + a hunter in spectator mode for added functionality, will naturally show up in all of them and can interact with all of them.

It comes down to grant writing.

At some point in the future grants for things like ai will probably go to a mix of academics and cryptocurrencies.

Just something to start noticing.

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


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?

Cortez's test (https://bitcointalksearch.org/topic/m.16080926) 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 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.


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)



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

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/

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.

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

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

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


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.

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.

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)



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)

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

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


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


Correct.


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



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.

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.

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/


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.


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.

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

Subscribed.

I might try this one of these days.

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://bitcointalksearch.org/topic/m.16080926 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