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

estimated altcoin inflation or total supply over the next 10 years?

the information is needed for http://alt19.com/19/cryptocurrency.php

thank you

The stuff being discussed recently sounds cool. A lot of the conversation is over my head technically but I'm intrigued.

I've now finished a more elaborate manuscript about the game-channels idea posted above: http://extra.domob.eu/gamechannels.pdf

If you have any more feedback, I highly appreciate it!

This is an entirely different thing - a decentralised rating system seems very complex and has not really been tried before.  But one experiment that will launch soon is OpenBazaar - if it works there, we can copy from them, of course.  The game channels as introduced, however, are fully secure even with disputes and without any trust - that's the whole point.  It is so far mostly a theoretical concept, though, and I'm not planning on implementing them (especially not with custom rules) "soon".  As hinted by HMC, it looks like Tau Chain could be used for that, though - but I know too little about it to comment further on that possibility at the moment.

I think that the more interesting application in the future is channels where the rules are predefined by Huntercoin.  E. g., a fighting arena (snailbrain likes this idea, I think) or even really something like the hinted "infinite game world" stuff (although that is really more for a future where we have a cryptogaming foundation with millions of dollars of funding...).

i like the idea of having side games, i could have fun implementing some but I'm not sure about how to handle disputes.
Ok, if all go well and any client agree on the game result it's fine, but what to do if clients don't agree?

To be really trustless, and used as a "general game coin" the huntercoin core should implement a "rule language" where custom game can write their rules in that language, but  it would be probably too much complicated (at least for more than a chess game)


maybe a better idea is to introduce the concept of "account" so that we can know if game partecipants are trusty or not, using a rating system e.g. (example
- every completed game (without problem) gives +2
- every completed game (that generate  disputes) gives -2
- every time a user client help solving a dispute it gets +1
- every time you lose a dispute you get -5
etc...

then accounts with an high rate, can "vote" for games with disputes (automatically of course), so the net can use the rating system as a way to solve disputes by itself

then we can add some fraud protection (e.g. someone behave good for some time, to rise his rating, then start "cheating") so that an account that have active disputes can't vote for another disputes (or some formula like "if you had more than XX disputes in last xx days, etc...)

this way, we can even use the account system in future into huntercoin game itself, so that we can enforce hunter creation limit per account, creating special contests bound to accounts (this way you could know how many kill a player has done, etc...)
To prevent creating multiple account we can then give some bonus (an experience concept, so you can "level" and be more powerfull, etc... so going thoward an RPG game concept

If everything goes well and no disputes arise in the private games, the public network and blockchain will only contain an opening and a closing transaction of the private game.  There's no need to have the full game nor even the end state of something like that -- just the transaction releasing funds according to the result, signed in agreement by both players.

Yes, losing the connection presumably leads to losing the private game.  However, it is, of course, possible to define the "threshold" for losing according to the actual game you have in mind -- if it is a chess game, each player may have a day or more for the move.  In this case, the system could be designed very well to allow for disconnecting and only connecting once a day to publish the current move.

If this is standard behavior it would also make fog of war between players on a huge map possible (playing normally and sending your moves to the main blockchain is then the equivalent of continuously broadcasting reconnaissance from your area to everyone)


Huntercoin network (all nodes) need to know the winning condition (and really the complete set of rules) for all playable "private games" or disputes can't be resolved. Also, lose connection, lose private game?

This sounds like an almost ideal use-case for what we are designing over at the tauchain project...  You should stop into #zennet on freenode and prompt a discussion! 

I've been thinking for some time now that a concept like payment channels could be used to implement a "real-time aspect" in Huntercoin or a related system.  Now I've had some time to think about it and I will describe a rough idea below.  I welcome any comments!

Game Channels for Near Real-Time Interaction among Players

For this post, let us assume that we want to add a simple "fighting arena" to Huntercoin.  Two peers on the network mutually agree to put up a HUC price and then enter a (possibly private) fight for the price based on some rules.  Using an idea similar to payment channels and the Lightning Network, this can be done in such a way that everything is off the blockchain (avoiding bloat as well as allowing for fast interaction not waiting for confirmations) as long as the peers agree.  In case that one of them drops out or disagrees, the other one can claim the price on the blockchain.  This makes everything trustless but still efficient.

Turn-Based Games

We consider a game that is turn based, with the peers taking turns to make a move and modify a shared game state.  This can also be done with more than two players if some order of turns is defined (round-robin or whatever suits the actual game rules).  To initiate the game channel, both peers create a transaction spending coins to some locked output (multisig or based on some new consensus rules in Huntercoin).  This transaction can contain additional details about the planned game negotiated by the players.  It also contains, at least, a public key identifying each player during the game.  The locked coins can only be spent by providing the Huntercoin network with a proof of who won the game.  As soon as this transaction is sufficiently confirmed, the game can start.

If no disagreement happens and no player drops out, the basic idea is that all players build a "private blockchain" similar to how Huntercoin works itself:  Starting from some predefined initial game state (which can be determined by the game rules alone and the initiating transaction on the blockchain), each turn taken by some player constructs a "miniblock" that contains the move signed by this player's private key.  This allows everyone with access to the private blockchain to compute the current game state; in particular, the player whose turn is next can continue to build a new block upon the current blockchain, and each participant of the game can verify that all rules are being followed.  Ideally, at some point the game reaches a state where someone won.  If each player is still fair and does not claim a dispute, all together can construct and sign a transaction unlocking the price and paying to the respective winners.  This is the only thing that needs to be put again on the real Huntercoin blockchain in this case.

However, of course the more interesting situation is what happens if someone disagrees with the game or stops to respond.  It seems not unrealistic that a losing player may choose to do that on purpose; or it could be due to a network failure or some other unintentional issue.  In this case, there needs to be a way for the other(s) to claim the price in a secure fashion.  For this, I propose the following mechanism:

• When a player stops to respond (after, e. g., some timeout has been reached), the remaining player may escalate the situation and claim a dispute.  This is done by publishing the current private blockchain including all signed moves made so far to the Huntercoin network in a special transaction.
• If this transaction gets a sufficient number of confirmations and/or has been on the network for a sufficiently long time (compare the locktime of Bitcoin transactions), the player may unilaterally spend the locked price output.
  
• Unless the contrahent actually starts to respond again:  When they see the claim on the network, they have the possibility (until the timelock threshold runs out) to post their next move publicly on the network.  This transaction, when confirmed, invalidates the claim; this is not a problem since there now is a next move and the game continues.  If the contrahent stops to respond again in the future, a new claim can be filed.
  

This procedure ensures that the game continues with at least a certain minimum frequency of moves, even if one of the players may prefer to drop out.  If it does not, then the non-dropped-out player is able to claim the price anyway.

Shared Turns

This situation of a turn-based game can also be extended to "shared turns" as it is the case with Huntercoin currently.  I. e., we do not want the players to take a turn after each other, but instead we want them all to perform some move at the same time but without learning their opponents' moves before they make their own.  This can be achieved by introducing "pseudoturns":  We define some order of the players, and each one publishes a hash commitment of their move in this order as "their" turn.  Afterwards, in a new round of pseudoturns, each player reveals the move.  This reduces the situation of shared turns to a pure turn-based game as discussed above.

Near Real-Time Interaction

Similarly, one can also reduce a "near real-time" interation to a turn-based game:  We allow "do nothing" as a valid turn, so that each player's client may immediately respond to the other's turn by posting a "do nothing" turn unless a "real-time player action" was initiated at this moment.  This allows for a rapid succession of moves, as fast as the network and processing power of the clients allows.  Of course, it is not clear how useful such a situation really is -- after all, by claiming a dispute the moves can be delayed in case of disagreement, so that no enjoyable real-time playing can happen.

Conclusion

Using the ideas introduced above, one can really implement private games between players (fights based on some rules to extend Huntercoin, but the same protocol can also be used to define, for instance, a blockchain-based chess game).  They are trustless but unless a real disagreement happens, they can be played off the blockchain and faster than the block confirmation times (as well as without causing blockchain bloat or requiring transaction fees).

The ideas described are still rough, and I'm pretty sure that one can work on minimising the "blockchain fingerprint".  For instance, one could try to construct a suitable set of proofs (based on, e. g., Merkle trees) that can be used to claim disputes without requiring to post the full (possibly long) sequence of moves so far.  This is, for now, out-of-scope, though.

I believe that this concept may even be used not only to add a "fighting arena" to Huntercoin, but even to scale the game for much larger (or possibly infinite) worlds.  This idea here could be the following:  The game state of each part of the world is only propagated in time if there are players nearby.  These players could then for themselves create a game channel and process their moves privately without causing growth of the Huntercoin blockchain, unless a dispute happens.  Of course, there are still a lot of issues to resolve for such an approach -- not least how to spawn coins there in such a way that everyone (not just the players interested currently in the game part) can verify that the total (and global) rewards are correct.  But this is, as well, a separate issue out-of-scope for now and can be addressed by a follow-up design.

That's true. Back in the day it was bad with bots, it was so hard to play. Initially it was easy to play, but it got real hard and I stopped playing. I made a bitcoin, can't even imagine how much the people with the bots made. I am excited to see how the game has changed since I have played it many months ago, gotta update my wallet, i still have the 1.00.06 wallet lol

could use a median filter on the last n blocks, instead of the mean. was also thinking about a longer time scale, where n is like blocksPerDay*0.8. 

i think dynamically auto-regulating the costs to play would be useful for many reasons. and having multiple hunter types with different skills would just be cool in general.

Dynamic cost depending on available coins seems fairer, but on the other hand, finding a time slot where you can get the most coins from the map most easily is an aspect of the game, or metagame.

The main problem is, playing a quick game is out of the question because it takes 1-3 hours to reach a good harvest area, and also 1-3 hours to get every hunter to a bank. (which is already an huge improvement compared with the pre-lifesteal and random bank era)

Hi Buck,

we've played with the idea of variable costs for hunters and i think we are all open to suggestions.
an issue basing on how many is on the map or create in a certain amount of time maybe that someone could create 10k hunters in 1 block and then it's expensive for everyone else?
Although I have not thought fully you could be on to something with different classes costs based on how many on the map (or created in x amount of time). This could be a self balancing technique for overpowered classes? i.e. overpowered classes which are created will automatically become expensive -once it becomes expensive though, the population will reduce, then the price will go down again, maybe oscillate?.. something to think about

one idea was for the cost of hunters to be based how many hunters are on the map when the previous disaster occurred - as disaster can happen randomly it could be harder to manipulate?

hoping domob gets some spare time soon and we can see what happens with pruning and then work on the next mechanics update and look at hunter costs (and remove destruct cost).

it could be interesting to scale the price to play with the demand for playing. i havent really thought this through but what if the price of a hunter (or type of hunter if different characters with different skills cost different amounts) could scale with the number of that hunter-type being created. something like if the mean number of hunters created in last few blocks is between n1:n2 then the cost is x, if more hunters are made per min, then cost to create the hunters goes up too.  

This is something more or less suggested in the past, with older gameplay styles but never investigated deeply. A dynamic fee system could be useful, even if it should be belanced to prevent "rich" players rules the map.
Anyway the main problem in CURRENT release is the cost to trigger destruction (20 huc), because it causes the PVP to be costly respect your possible gain and now you most of the time see someone trying to attack another, and if he defend itself, maybe try a second time and if it ends even again, then going away leaving the fight.

Lowering very much game cost will (hopefully) increase the game population but a more interesting gameplay should be implemented too, and the focus of changes shouldn't be toward the fight versus bots because if the map is crowded and the mechanics are "complex" (again armor/ammo, different attack types and spell timers) bot will have an hard time surviving in such scenario, even if smart

About the costs, I've always been a defender of the "let's have a cheap game that allow anyone to win a even little amount" game model while the game is going more  toward "let few win much" game model. imho it's a pity

I found that the starting model 1HUC cost per hunter was cool because was balanced with the fact that a block generate ~8 huc on the map

Unlucky the higher fees was caused by technical problem (blockchain bloating), so to decrease the size of the blockchain the cost increased much, but I think that actually it killed the game

My hope is that soon we'll be able to have a pruneable blockchain and so the "crowded map" will not be such a big problem and we could happily fill the map with our hunters and fight each others to prevail!!

what about having the cost of a player(s) be related to the amount of available coins on the map? some dynamic cost for a hunter(s) thats modulated by game state?

I think this extrapolation doesn't give the right weight to current situation.
While i'm developing the game, i play it and what i see is that actually the game is almost played by just one or 2 person, not bot driven but persons who just have a lot of time to dedicate to the game
currently i don't think bot are involved, except me doing some test of the collector behaviour when i've time (and most of the time i lose them because i work during the day and i haven't yet implemented the "stay away from enemies" behaviour (and as i said i'm planning to release to everyone this behaviours in my client)
current game problem is just that it costs too much respect what you can collect, because paying 20huc every time you try to kill someone, means that you have to spend lot of minutes collecting those coins
and if you don't find someone AFK that forgot one of his hunters around the map, usually fights ends up with both attacking at the same time, so both spending 20 huc, without a winner and so, after 2 or 3 attempt (and both loosing 40/60 huc) they decide to leave the fight and keep collecting coins around. I'm speaking by experience, playing every day or whatching how the game evolves, i can even say that there are probably 2 players that are alternating and i can say more or less their playing times because they mostly use even everytime the same players names

actually BOTs aren't a problem at all, but of course they could become a problem if the coin will rise in value, because it would be worthy for bot creators to invest time and hardware to run their creations

But if we increase the tactical aspect of the game (e.g. ammo/armor ideas already proposed months ago by me), it would be much harder to have a bot that can easily face a human, and fights would be funnier than now. blockchain size is another aspect and it's going to be solved, but the main problem that i see now is really the bad ROI that the game have, and more players that plays and compete to collect coins, worse the ROI would be with current game mechanics.

I already posted my observations last months here on this thread, like this:

https://bitcointalksearch.org/topic/m.12040287

and this

https://bitcointalksearch.org/topic/m.12445593

It's an interesting thing. Huntercoin is certainly a sort of dividing line between the original currencies that were necessarily generated or mined by only a few, and future currencies that will be entirely generated by users, though probably in some process more useful than an online game.

Bots that can mine "human mineable" currency are counter productive at this point. The fact that bots can compete easily with people is not good. 

Here is a brief extract from the super long post Mithrilman made on the previous page:


Everyone understands that bots make some money for those who create them but they destroy the value of the coin. It seems like devs try to address that issue.

It sounds to me idiotic that the most competent here codewise are working mostly on bots. Like "Here we have a human-minable altcoin but it is the one who has the best bot wins game actualy".

@domob, thanks ! i downloaded the chain, and was synced within 5 min.

@wiggi, that map looks awesome. a little depth (3D) goes a long way

@mithrilman, you are still a beast i really like that you are maintaining a perspective to always make the humans more competitive with the bots. that is very important.