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

[arransiv]

i'm doing some testing with huntercore -

i sent myself 1050 hucs to huntercore wallet from old-current-wallet - totally skipped "pending" on huntercore (memory pool) and went straight into the wallet after a couple of mins.

I suspect this actually is the issue MM experienced (in my last post).
probably need more connections, or more miners/nodes/better-connected-nodes -

i will keep testing (could be huntercore has issues with memory pool?)

You can introduce masternode feature to keep network alive and clicking. Or introduce active nodes and maintain it on your own.

[snailbrain]

i'm doing some testing with huntercore -

i sent myself 1050 hucs to huntercore wallet from old-current-wallet - totally skipped "pending" on huntercore (memory pool) and went straight into the wallet after a couple of mins.

I suspect this actually is the issue MM experienced (in my last post).
probably need more connections, or more miners/nodes/better-connected-nodes -

i will keep testing (could be huntercore has issues with memory pool?)

You can introduce masternode feature to keep network alive and clicking. Or introduce active nodes and maintain it on your own.

thanks.

i think once huntercore is completed we will fix some static nodes to the client to start with

-

i should have a huntercore / unity client ready for testing today/tomorrow - less then 500mb download (with chain), pretty much instant play for anyone wanting to get into huntercoin. It's a pruned chain so you need to use a fresh wallet, or send coins from your old wallet to a new address in your new wallet.
just run the .bat file and you are good to go.

hopefully we can get this out of the way then start working on game/combat mechanics - maybe get wiggi to put something together?

[MithrilMan]

You can introduce masternode feature to keep network alive and clicking. Or introduce active nodes and maintain it on your own.

You just stated what i was thinking about, I think that for the application type (game) masternodes should be the way to go, we should reengineer the architecture to really makes the game playable, enjoyable and more secure.

I was thinking that having some kind of constraint on block generation, that enforce a block to include all transactions that at least 2 or more masternodes aspects to receive, should ensure that clients know if their transaction is received by the net and miners can't cheat during block generation.

Don't know if i made clear my point. I try to explain in a more descriptive way:

Masternode
Masternodes are special kind of nodes that host pending transaction and are linked togheter, in a way that allow them to be redundant and updated.
They apply validation on incomin transactions, to reject invalid ones, and hold a list of pending transaction that they expect to be included in the next block.
They could have a logic to include the transaction that act like "if transaction is valid, and has been received in 30 seconds since last generated block, include in the "next block expected transaction list", otherwise park it for the further block.

Dispatched Messages
- If a masternode accepts a transaction, he sends a packet to the network, communicating that he is expecting tx XXXX being included into block YYYY so that any client is aware of that. (and here a client can know if a transaction he sent will be into the next block or not)
- When the time threshold to include transactions in the next block has elapsed (in my example it's 30 seconds) MasterNode sends a packet that include the list of transactions the next block has to generate (this way every miners node knows what they should work on, and every new generated block have to include that transactions in order to be accepted by the network
- Generated blocks must be accepted by Masternodes


What does this mean practically:

When a player sends a move transaction, the transaction is sent to one of masternode and the client will have an async feedback about the sent transaction ACK (IncludedInBlockXXX/Rejected), this way the clients can shows the transaction status clearly.
At the same time, the player know for sure that his transaction will be included in that specific block, without having bad surprises like i had.


Masternodes should have a sort of consensus algo that exclude masternodes that act strangely and of course there must be some kind of elasticity in accepting transactions on different masternodes, because of latency, but every masternode must have the same UTC time.
Whenever a masternode receive a tx, it have to relay it to other masternodes that must agree on including it on the next block, so a clever syncronization alghoritm has to be thought, i'm just stating the bare logic behind

P.S.
I'm pretty sure this will remain in the limbo of the "cool things to do but there aren't people working on it"

[wiggi]

it's possible that when f2pool were mining blocks (sha256 and scrypt - both on the same daemon using a mod they did after some time), most people had their IP/nodes connected to f2pool node(s) and saved in addr.dat.

it's possible you are not directly connected to the current miners node or the other players node (limited by 8 connections?) - could be the tx had not yet been received by you but had been received by the miner (tx needs to get relayed and propagate through  the network - people receive txs at different times)

maybe solution would be to open the port 8988 (i think it's that port, will chekc later if not) and forward port to your daemon/PC, or if upnp is enabled and working properly (on daemon and router) it should open up itself.

This should then increase your maximum of 8 connections and you will maybe get a direct connection to the miner and player - the more connections you have the faster you will receive txs

I was once on the receiving end of this too, and kicked the limit out:
https://github.com/wiggi/huntercoin/blob/betterQt-with-storage/src/net.cpp#L36

Must also start the node at least once with

Code:

maxconnections=32

because the old setting of 8 is stored hidden from the user (on windows in the registry iirc)

[snailbrain]

it's possible that when f2pool were mining blocks (sha256 and scrypt - both on the same daemon using a mod they did after some time), most people had their IP/nodes connected to f2pool node(s) and saved in addr.dat.

it's possible you are not directly connected to the current miners node or the other players node (limited by 8 connections?) - could be the tx had not yet been received by you but had been received by the miner (tx needs to get relayed and propagate through  the network - people receive txs at different times)

maybe solution would be to open the port 8988 (i think it's that port, will chekc later if not) and forward port to your daemon/PC, or if upnp is enabled and working properly (on daemon and router) it should open up itself.

This should then increase your maximum of 8 connections and you will maybe get a direct connection to the miner and player - the more connections you have the faster you will receive txs

I was once on the receiving end of this too, and kicked the limit out:
https://github.com/wiggi/huntercoin/blob/betterQt-with-storage/src/net.cpp#L36

Must also start the node at least once with

Code:

maxconnections=32

because the old setting of 8 is stored hidden from the user (on windows in the registry iirc)

ah ok thanks.

yes the 8 limit is outgoing connections, by default i don't think there is a limit for incomming (but requires port forward if behind firewall/router).. (maybe 120 is the limit?)

do you know if increasing the outgoing connections is safe? i'll try to look to see if there is a reason for bitcoin and others using 8 as max outgoings.

[wiggi]

do you know if increasing the outgoing connections is safe? i'll try to look to see if there is a reason for bitcoin and others using 8 as max outgoings.

I think the stated reason translates to "thus who don't contribute (enough) to the network by not being a server shall have only 8 connections". If you try a new coin and see the green bar (without being a server) that's a brownie point.

[snailbrain]

thanks wiggi...

--

huntercore - found a bug with name_list which can crash the daemon in certain circumstances - so won't be ready for testing yet

[wiggi]

i've added a statistic module to my client (wip) and i see that in the past 23 days i spent ~8700 huc as fee to gamefunds, that's insane

from a quick look at the transactions page (not exact values)
 made 70 hunters (-350 HUC due to 5 HUC fee)
 coins harvested (+1200)
 35 * destructed (-700)
 6 kills (+1200)
 3 hunters died (-600)

rather brutal game if you don't have a time zone for yourself



I tested the "betterQt release for block 1300000" (50h+ online), and there are some new things (Currently all but the last is only in the precompiled binaries, but I'll put as much as possible on github):

Floating arrows to show waypoints of "unknown" hunters (configurable).
Not really sure what/when/how to display without cluttering the screen, but the arrows are "player sprites" so they can have a direction, text and icons like players.




The Hit+Run point system has been fixed so they can always be set while in combat/while destructing. (they can be set with normal mouse click or control-click)
If Hit+Run action is executed (i.e. automatic destruct sent) the Hit+Run point now moves randomly (1 tile) and stays active.


If bored and no enemy is nearby but some coins, hunters will harvest them. This looks pretty neat and (somtimes) almost passes the turing test. Almost.


The last point is the most important Imho -- a built in payment server

A NPC or other game entity can now pay any player (any owner of a Huntercoin address) *in HUC*
It will do so by auctioning off as many of its own gems as necessary, until the proceeds meet the amount of coins it owes to the player.

This implementation (https://github.com/wiggi/huntercoin/commit/b64600038a1f6f46b10b7738660f69d06c0e1847)
allows the game to always (updated each block, 24/7) make an offer to convert gems to Huc at a fixed rate.
It's the first test on mainnet, and may still be buggy.

If it works, something similar would be "hunter sharing".
I.e. Alice puts a "desired logout time" on record with the name address of her hunters, and if Bob's 1 hunter want 10 buddies,
Bob will get them, plus an invoice. If Bob doesn't pay then his gems are forfeit, and given to Alice as compensation. (self-enforcing contracts are possible with gems but not with coins)

This would allow faster logout, quick access to the harvest areas, and bypass the 5 Huc fee per hunter. No fork (of Huntercoin itself) needed.

[wiggi]

with only minutes to go, this will be probably be the voting result:

Code:

 Votes (chronon 1299946, mainnet)
 --------------------------------

                                          hunter             coins           motion
storage vault key                           name     gems    (*1k)   vote    id-tag   close

HGWJyadJjFnMaEjUaC645wcUKAtaZ6vyTU    #Anonymous     0.00       69    #9    1299975  1299975
HGnVxAdPpMECmUPBr9kUDQouYdE7ZPHt2C    #Anonymous     0.00      210    #8    1299975  1299975
HKKPtEh5sN8qz2fZMnWnJwgwekZti42m4R    #Anonymous     0.00      158    #7    1299975  1299975
HVJWcbZ7yvkY61FfwmpouDTaf7bL6Ju2Q3    #Anonymous     0.00       33    #9    1299975  1299975
HVhyiJihnePkMxhBwobBXhMaddAJmfWUiq          Tala     1.10       25    #7    1299975  1299975

  Tala: "How fast should a hunter be able to bank + log out? (vote with coins)
#1...100 chronons
#2...60 chronons
#3...40 chronons
#4...30 chronons
#5...20 chronons
#6...15 chronons
#7...10 chronons
#8...7 chronons
#9...5 chronons

Details:
https://bitcointalk.org/index.php?topic=435170.msg15515861#msg15515861"


 Vote tally (chronon 1299975)
 ----------------------------

                                                             coins
vote                                                 gems    (*1k)

#7                                                   1.10      183
#8                                                   0.00      210
#9                                                   0.00      102

 then start working on game/combat mechanics - maybe get wiggi to put something together?

We need a systematic approach, but I keep thinking about this:
https://bitcointalk.org/index.php?topic=435170.msg14230603;topicseen#msg14230603

If Huntercoin is more complex with groups of hunters, what if your hunter buddies can be summoned under specific circumstances. Example : stand still next to a bank, then next block up to 7 hunters stand on the 7 tiles adjacent to the same bank.

Buddies are defined as hunters that point with their reward address to your (the summoning hunter's) name address, to proof edit: Hunter buddies must post (e.g. as message) where they want to go, to proof they *are* yours and to allow easy implementation with the normal gamestate variables.

You could quickly attack any location, just need 1 hunter + 1 bank nearby. Opposing force can call in reinforcements. Or they can easily flee using the same method.

And of course very fast logout if you camp at least 1 bank, somewhere.

Instant strategic depth?

[The Bitcoin Co-op]

with only minutes to go, this will be probably be the voting result:

Code:

 Votes (chronon 1299946, mainnet)
 --------------------------------

                                          hunter             coins           motion
storage vault key                           name     gems    (*1k)   vote    id-tag   close

HGWJyadJjFnMaEjUaC645wcUKAtaZ6vyTU    #Anonymous     0.00       69    #9    1299975  1299975
HGnVxAdPpMECmUPBr9kUDQouYdE7ZPHt2C    #Anonymous     0.00      210    #8    1299975  1299975
HKKPtEh5sN8qz2fZMnWnJwgwekZti42m4R    #Anonymous     0.00      158    #7    1299975  1299975
HVJWcbZ7yvkY61FfwmpouDTaf7bL6Ju2Q3    #Anonymous     0.00       33    #9    1299975  1299975
HVhyiJihnePkMxhBwobBXhMaddAJmfWUiq          Tala     1.10       25    #7    1299975  1299975

  Tala: "How fast should a hunter be able to bank + log out? (vote with coins)
#1...100 chronons
#2...60 chronons
#3...40 chronons
#4...30 chronons
#5...20 chronons
#6...15 chronons
#7...10 chronons
#8...7 chronons
#9...5 chronons

Details:
https://bitcointalk.org/index.php?topic=435170.msg15515861#msg15515861"


 Vote tally (chronon 1299975)
 ----------------------------

                                                             coins
vote                                                 gems    (*1k)

#7                                                   1.10      183
#8                                                   0.00      210
#9                                                   0.00      102

 then start working on game/combat mechanics - maybe get wiggi to put something together?

We need a systematic approach, but I keep thinking about this:
https://bitcointalk.org/index.php?topic=435170.msg14230603;topicseen#msg14230603

If Huntercoin is more complex with groups of hunters, what if your hunter buddies can be summoned under specific circumstances. Example : stand still next to a bank, then next block up to 7 hunters stand on the 7 tiles adjacent to the same bank.

Buddies are defined as hunters that point with their reward address to your (the summoning hunter's) name address, to proof they *are* yours and to allow easy implementation with the normal gamestate variables.

You could quickly attack any location, just need 1 hunter + 1 bank nearby. Opposing force can call in reinforcements. Or they can easily flee using the same method.

And of course very fast logout if you camp at least 1 bank, somewhere.

Instant strategic depth?

Looks like everybody favors faster logout times. Can't say I'm not surprised. It would limit the need for AI being built into game clients.

I like your idea for calling reinforcements. It sounds relatively easy to implement in proportion to the breadth of strategic options it opens up. It could be done at the base protocol level without even requiring the player to use secondary layers like the one you're designing. That means it would be easier for other developers to do cool things in the future (features already built in don't need to be coded from scratch), and I think it should be our goal to foster a modding community.

[wiggi]

I like your idea for calling reinforcements. It sounds relatively easy to implement in proportion to the breadth of strategic options it opens up. It could be done at the base protocol level

Currently testing...it doesn't need to use addresses at all (i.e. no disk access to fetch name address), just the message field and hunter name (plus a '!' in this case) as watch-word so Bob and Caesar can confirm that Alice is really their buddy.
Alice: "summon Bob and Caesar"
Bob: "for Alice!"
Caesar: "I'll stay on that bank, Alice!"

Very flexible, I think in practice clients would autorespond and perhaps add some flavor.

But could it backfire, by making a strong (or an annoyingly aggressive) player stronger (relatively to other players)?

[The Bitcoin Co-op]

But could it backfire, by making a strong (or an annoyingly aggressive) player stronger (relatively to other players)?

That's true... maybe we shouldn't integrate it with the base protocol. Allows more freedom of choice for players and developers

[wiggi]

But could it backfire, by making a strong (or an annoyingly aggressive) player stronger (relatively to other players)?

That's true...

...or perhaps not true. Is there really a scenario or strategy where more mobility would help the numerically stronger player(s), all else equal?

I think this is not the case. More mobility will always help regular players who aren't already everywhere and don't have infinite time to play at their disposal.

[The Bitcoin Co-op]

But could it backfire, by making a strong (or an annoyingly aggressive) player stronger (relatively to other players)?

That's true...

...or perhaps not true. Is there really a scenario or strategy where more mobility would help the numerically stronger player(s), all else equal?

I think this is not the case. More mobility will always help regular players who aren't already everywhere and don't have infinite time to play at their disposal.

I think it would certainly change the way the game plays. If some players decide that they disagree with it, not incorporating it into the base protocol would be better for them and their ability to choose.

[enhu]

its only now that i noticed this coin and its pretty interesting. does the wallet really allow us to play that video game? where can i download such wallet and any information about the hardware requirements for it to work? also has anyone ever created a torrent file for http://chain.huntercoin.org/ ?
it says 8gb .

[jwinterm]

its only now that i noticed this coin and its pretty interesting. does the wallet really allow us to play that video game? where can i download such wallet and any information about the hardware requirements for it to work? also has anyone ever created a torrent file for http://chain.huntercoin.org/ ?
it says 8gb .

Yes, you can play the game in the wallet, and the hardware requirements are pretty low, except for disk space. My data folder (blockchain) is 12.6 GB right now, synced as of a few days ago, but you can bootstrap with the file at chain.huntercoin.org.

[MithrilMan]

Just saw block 1302148 has been generated by SHA256
https://www.huntercoin.info/blockExplorer/block/9f7735909220d8f515107fcda5a972c569dc52aef23f8ae9f653786303adaae6

don't know if someone has been lucky enough or some power has been put in, but this is good for the game (if this isn't just exceptional)

its only now that i noticed this coin and its pretty interesting. does the wallet really allow us to play that video game? where can i download such wallet and any information about the hardware requirements for it to work? also has anyone ever created a torrent file for http://chain.huntercoin.org/ ?
it says 8gb .

if you want check my client in the signature

[wiggi]

I think it would certainly change the way the game plays. If some players decide that they disagree with it, not incorporating it into the base protocol would be better for them and their ability to choose.

Perhaps we can really tweak this feature to everyone's liking.
I did a prototype implementation, only using the message field.

Source: (not compatible with mainnet or official testnet)
https://github.com/wiggi/huntercoin/tree/summon-test

Testnet-in-box:
https://mega.nz/#!TIthjDKC!QjR1zRBDoGLOD7ocbnGFhPrmnie_xyr_pzXtZuVygFg


It works indeed like this

I like your idea for calling reinforcements. It sounds relatively easy to implement in proportion to the breadth of strategic options it opens up. It could be done at the base protocol level

[...] hunter name (plus a '!' in this case) as watch-word so Bob and Caesar can confirm that Alice is really their buddy.
Alice: "summon Bob and Caesar"
Bob: "for Alice!"
Caesar: "I'll stay on that bank, Alice!"

and the hunter doing the summoning must be on a bank tile 2 blocks after the tx with the message confirms, then it actually happens. Only hunters who answered (3 blocks time to do this) get summoned, to the bank tile.


Almost as a side effect, a player who want to stop playing, and has at least 1 hunter 3 tiles away from a bank, can be completely logged out with all hunters 7 blocks later.

I also think the common criticism "this game sucks because you have to wait for next block to move" means something else: in battle for wesnoth, or chess, players have to wait too, but individual moves can be important and not only to the next adjacent coors.

[The Bitcoin Co-op]

Almost as a side effect, a player who want to stop playing, and has at least 1 hunter 3 tiles away from a bank, can be completely logged out with all hunters 7 blocks later.

Oh, that is a neat side-effect... reinforcements means faster logout time. Kills 2 birds with one stone.

I like this, actually, but maybe it would be good to limit its power somehow... for example, if you had an ability that costs gems or something which can temporarily disable another Hunter's reinforcements ability, that would be interesting.

[IconFirm]

Just saw block 1302148 has been generated by SHA256
https://www.huntercoin.info/blockExplorer/block/9f7735909220d8f515107fcda5a972c569dc52aef23f8ae9f653786303adaae6

don't know if someone has been lucky enough or some power has been put in, but this is good for the game (if this isn't just exceptional)

FUpool dropping HUC is the best thing that could have happened. I have erned more merge mining sha256 HUC in the last 7 days than I did in the previous 7 months while FUpool were hammering the hell out of it. It's now less centralised & anyone can mine it - win win.