This article is a comprehensive explanation of the history behind and current state of Huntercoin. It will fill you in if you don't have time to read through the mass of posts in the Huntercoin thread. You can trust it to be correct and not outdated for the near future. Cool, interesting details about these other projects. Games-on-a-blockchain are on a sliding scale of fake vs real. If coins are sold to players so they can buy items or whatever in-game it's 100% fake. If Blizzard would have WoW gold as cryptocurrency but the accounts with PCs and gear belong to Blizzard (that can ban players) it's 90%+ fake. (with characters and items being all fungible bitassets they could still change the game that is running on their servers at will: 75% fake) Speaking of bitasset, the early versions of Bitshares (if it were a game) looked like pretty close to the "real" end. Then something went wrong. A second sliding scale is game vs cryptocurrency, how much value in percent of the crypto is, or can be, in-game. |
|
|
|
if anyone wants to test the better-qt by wiggi, they can take a look here for the windows version - he's already compiled but here is my compiled version https://mega.nz/#!MM9G3SKI!Va9xWaP1iBffX5x8HYT1HXxjQjQQaK3qRGy6M3LBwHMgraphics are much better but may suffer from some performance issues odd little bugs but would be good to get peoples feedback. (this doesn't include the extra features he has been experimenting with atm) The windows version of Huntercoin 1.3.01 linked in OP comes with Qt 4.8.5 dlls, so I assume all qt client variants can be built using the original guide from bitcointalk. Which is now difficult to find if not already knowing an exact line, like "4. Setup Qt 4.8.5 and compile Bitcoin-qt" to help google a bit. It would be interesting if someone manages to build with Qt 4.8.6, or a newer boost version than 1_54_0 on windows. |
|
|
|
Update for https://bitcointalk.org/index.php?topic=435170.msg13478921#msg13478921It's an in-game auction (gems <-> coins) and price feed system (HUC in USD), in need of some testers (on testnet). For Windows, with up-to-date testnet gamestate for the experimental version. https://mega.nz/#!qQ0lgLRT!xmzSlbxP-HV0t-3LwkInJmMzoVohUQ6ZKgSy3uADnHA Source https://github.com/wiggi/huntercoin/tree/betterQt-with-storageuncomment "#define PERMANENT_LUGGAGE" to get the experimental version. Nodes can switch between safe mode and experimental version (exit, rename executable and gamestate.dat, continue). To use: - Start client, wait until blockchain download is finished, open game tab, click middle mouse button to start tx monitor. (2 files are updated for each new block: adventurers.txt and auction.txt) - Set autoupdate without asking in Qt-creator: Tools | Options | Environment | when files are externally modified: reload all unchanged editors (Vim, or Notepad++ can do the same) - If an action is possible (buy, sell, feed, or send coins), auction.txt will come up with an example line to be copied as chat message or console command. Provisional rules: If a hunter owns a "storage vault", i.e. is transferred to the vault address, they can post 1 (one) sell order. It will stay active when the player is offline and the price is reduced by 1 tick every 100 blocks, until filled. (dutch auction) To cancel: "GEM:HUC set ask 0 at 0", or just set it higher: "GEM:HUC set ask 1 at 1000000" The "settlement price" will slowly move up or down, depending on the best ask price, and the game can later use this as estimated/collateral value. It's not possible to place sell orders below the settlement price. Every hunter can post a "fill or kill" buy order, which can fill against the current best ask. For now, the client will refrain from sending coins all by itself but it would be trivial to do. To get the feed reward (on testnet every 100 blocks, on mainnet this would be 10000), the feed price must be within +-5% of median feed from all players Offline testing is also easy, with a setup like the testnet-in-a-box linked here https://bitcointalk.org/index.php?topic=435170.msg13371058#msg13371058just copy the official testnet blockchain to hunt1\testnet *and* to hunt2\testnet. |
|
|
|
Any competition between bots and humans is negative right now for a "human mineable" coin but at some point someone will put that tension to good use and a whole new type of algorithm process will develop. Huntercoin is in a better position than any other coin to start that, even though it is a very small coin right now.
Yep, it's a complicated matter. Right now a new player (using an unknown name) will likely get stalked by some of the regulars, and killed if not paying attention for 10 minutes. Or killed by an absent-minded hunter who then forgets to collect the loot. Or get stranded on the map with no bank in sight. A relatively simple assistance system that normally just sits in the background until needed would make it more likely that the new player enjoys the game. First there has to be an influx of new players of course. And the strongest group of players is playing 100% manually, having to sleep some hours per day is probably their only weak point. |
|
|
|
I've yet to see another game developer quite as committed to P2P & blockchain technology.
Last year I half expected 100 blockchain based indie games to pop up, with an ensuing cacophony on par with all altcoins together. But lots of reasons why it didn't happen, and probably is still not in the pipeline now... Updated the above links, and tested the full version on mainnet. No problems. If mainnet game.dat is deleted, it takes about 5h to regenerate (1 cpu thread, and there is very little disk activity). The result is included in the windows version, but should work everywhere. Basically the gamestate can store any kind of data, do any kind of calculations with it, and run the perfect turn based game if we want (backed up by the blockchain even if the scope of the game goes beyond Huntercoin) Click middle mouse button 2 times to get the list of what's currently in the safes. (and do dumpprivkey on the addresses) It should look like this: adventurers.txt hunter
storage vault key name gems
H7HKACUUgxTVFrgqwtzk7rjfAirh2oPm9L soto 1.00
H9a1y1BVfTy7wMydc4v5Bd6DNGUcmfoffD mimpo 1.00
HASfuy2bztDuFVDXRWQuZBDSUGmV5bTGKH vert3 1.00
HDj1dX9AJYRbZqRwsxi2MBJiAVRAxk8rGn Julia 1.00
HEAmWh1QuujiQLAmn7twg7f3NYsKov6N4f oku 1.00
HEDwK8gvde2tyEr9Bb5Cs28X4JXZMCxhv6 Nada 1.00
HEaPz4EGME7oJ53Gu6n4UCStxGfDwS6n94 ahzek 2.02
HGSeTEV5Cbg83U67na9hs9stiU5sCTfHg9 oku4 1.00
HGvtSnXWyQGFihfHEd2XAzCzfJCg8ofnJR zero 1.00
HKepczEtZMZVk9odw2nCDqEiJTNHsDJ9xS noir3 1.00
HUyUXaqw6qmhALSY1AHFSq2sMBqK2uaCGj Glub 1.00
total
11 12.02
|
|
|
|
Update to fix a critical bug with the gem spawn positions, please don't use the old version anymore. Source: https://github.com/wiggi/huntercoin/tree/betterQt-with-storageFor windows: (updated Jan. 7, 2016) https://mega.nz/#!TIM3SC4L!O4rrr2gXc9sA6BxsSYNzikOCPkS2iPPet3s2FS2cSVE The betterQt client is not affected. Normal Huntercoin gameplay with betterQt-with-storage is not affected. No gem is lost, if it was visible and a player picked it up, it will be in the inventory, but players must upgrade by block 1037070. |
|
|
|
This is a special version of the Qt client that kind of stretches the boundaries of what Huntercoin protocol as it is can do. Hunters can now own items. At block 1030860 (testnet: 315600), and then if height is divisible by 1242 (testnet: 100) a gem will spawn in the stone cave either on the right side or left side of the map. As it appears on the official testnet:  1 block after an hunter steps on this tile the gem is stored in gamestate with the reward address as key, or the name address if reward address is not set. By default, save mode is on, with only client-side prediction, not touching the gamestate at all (good enough to fetch the gem, but not accurate all of the time). Then you can // uncomment this line and delete "game.dat" if you dare
//#define PERMANENT_LUGGAGE and stuff becomes retroactively real. On testnet, game.dat regenerates in ~10 minutes. (it's the blockchain that can decide "who was on the right tile at the right time", gamestate is just the same data in different format for fast access) Currently, only actions that are of no consequence (the hunter will die anyway and item is absolutely safe) are possible: - set reward address to same as name address: this puts all gems in characterstate, amount is displayed after hunter name. - set reward address to something different from name address: put gems back into storage Another hunter can later inherit the inventory if they transfer to the "storage address". Source: https://github.com/wiggi/huntercoin/tree/betterQt-with-storagehttps://github.com/wiggi/huntercoin/blob/betterQt-with-storage/src/makefile.unixis a generic bitcoin makefile adapted for Huntercoin. No mystery dependencies anymore. Daemon build can be either identical to 1.3.01 release, or with full items/storage handling like the Qt, making this all "client-agnostic", aside from visual effects. For windows: (both builds, save mode and full) https://mega.nz/#!2J0gza4C!_CGoc2_DsgjSLBc_pzkIgIJpWvjnQIdiS82K8Oh4h9E Also for windows, a testnet in a box, showcasing a bunch of ideas that can now be ported to Huntercoin. https://mega.nz/#!fUMWFRAZ!mYceRV0s91iokbMvkN6_vSKKbIzroi_WnnPa0uOhbeY |
|
|
|
probably dangerous
Yes, probably, and the best course of action is to do nothing but have something prepared for the worst-case scenario. Plus earn HUC while you wait that 120 mins while moving across the screen  This point is nonesense. If you stake coins, you simply increase the nominal number in your wallet. The total fraction you own stays constant, i. e., staking just makes up for the inflation you introduce. (More or less, at least.) Depends on the details. If (right now) ~10 million coins exist, and block reward + death tax yield ~1 million coins per year, that's really enough to support a pure POS algo. |
|
|
|
isn't the high hashrate completely dominated by a single pool? Even though there are two algos, doesn't f2pool control more than half the hashrate on both at any time? So, even though there is a high hashrate, isn't Huntercoin completely at the mercy of a single entity?
Was f2pool completely down (for Huc mining) when block time was 5-10 minutes a few days ago? If f2p has just >51% and not really 100% then it would almost be ok for the moment and the current marketcap. It's different tiers of "at the mercy of", vulnerable vs instadeath if kicked out. |
|
|
|
|
Seems like forum.huntercoin.org truncates passwords after the 9. character, and the login page (forum.huntercoin.org/index.php?action=login)
after the 15. character. (only since today, so anyone with longer pw is locked out)
|
|
|
|
Also an update for the betterQt client: https://github.com/wiggi/huntercoinhttps://mega.nz/#!CB0R1bga!KFw25d1CcSA-x7SvVc0tM_ZmyssCyW-y2jBzJlHjJYY - Windows build has run ~20 hours via Tor, no problems. - There is now a readme. Btw, it's dangerous to have names of hunters that are not alive on the map in names.txt (an imposter could sneak up on other hunters without triggering an alarm) - Most improvements are for the map editor, but it's still trial and error what works and what not. "Rectangular copy&paste" is basic function for text editors, so it's easy to prettify a small snippet of the (asciiart) map and post it.   |
|
|
|
Is there a reason for the past 3 days now i have had to reload the QT wallet? Seems i am losing connection to other nodes ..  Case examples (node seems to be connected but suddenly stops receiving blocks) - Mint13 32bit (in Virtualbox on windows host): ~1000 hours since v1.3, works absolutely flawlessly - Old notebook (2GHz centrino duo), Windows7, connected through Tor: stalls about once per day - Same as above, but connected directly: stalls every 2 or 3 hours - Same as above, but additional load (like bitcoin node starting): QT wallet need restart, always. I think it's caused by a combination of Windows, system load, and possibly ISP-specific quirks. But it's a general problem, not limited to Huntercoin. |
|
|
|
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.
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? |
|
|
|
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?
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) |
|
|
|
continuing from https://bitcointalk.org/index.php?topic=435170.msg12289266#msg12289266and https://bitcointalk.org/index.php?topic=435170.msg12485242#msg12485242It seems to me that we are talking about different things, you are more about "procedural generated maps" but this doesn't work (or at least is not easy) if someone wants to change themes, etc.. because your descriptors should be agnostic too (not "this is a tree" but more a "this is a tall element that cover a player") etc...
Basically, the tall element that cover a player will become a tree if you use maptiles for it that look like a tree. For example, duplicate these 6 lines https://github.com/wiggi/huntercoin/blob/betterQt/src/qt/gamemapview.cpp#L486-491only with a new letter and 6 new map tiles. Voila, an alien looking tall element (that cover a player). What's the purpose of Calculate_AsciiArtMap? Can't it "patch" the map and generate a final fixed map with all layers patched, that can be shared with any client?
It has reversed gear, from reading the gamemap and figuring out what it means, to rebuilding it (from the asciiart file, the old gamemap is commented out) So it's not a procedural generated map, all the (manually placed by snail iirc) trees are on their old position, with most cases of missing or garbled tiles repaired. updated for windows: https://mega.nz/#!2AUGkKKS!rwth5Rmfea5qpHyfkBSDdJ3xcqW-6d3MVchaa_ZPCNc  |
|
|
|
and add the tile index in a layer like the ones in gamemap.cpp?
this way the enanched map can be ported in other clients like the unity3d and mine and the code would be a lot cleaner too
When a client (any) paints the map, it must know the numbers like in the tables in gamemap.cpp. Easy to save, copy and paste to gamemap.cpp of another client. Or to itself, of course. That's the real "client agnostic" format, without any overhead. |
|
|
|
Small update to https://bitcointalk.org/index.php?topic=435170.msg12289266#msg12289266- each hunter (if name is in names.txt) has now an individual alarm that resets itself if the enemy is out of range or dead. - hunters (if name is in names.txt) ignore each other for alarm purposes. - ctrl + middle mouse button now toggles "silent" mode. - the wooden palisades cast shadows. - visual gamemap data is saved as human-readable and editable text file. (next version will use this text file for painting the map) Windows: https://mega.nz/#!rN9FyZRL!8spi-us8w_B5-eFvXFHWgyu1Pl7cGfgTbUONSVOZ5Fk Source: https://github.com/wiggi/huntercoin
graphics are taken from royalty free archives, to do what you ask a graphic designer is needed, if someone have the skil and want to help he's welcome, btw i could use new graphics on my client, but it will only be valid on my client of course, i think this should be "client agnostic" but... maybe having custom graphics on different clients could be interesting
even custom maps could be used (i could crate a space theme in theory), the only important thing is to respect the "walkable/non walkable" tiles, all the other things can be changed
Yes yes! Mapping while playing.  I think a first step towards client agnostic graphics would be to only add to the list of map tiles (e.g. old beta map is difficult to salvage because the tiles are in different order) and to maintain a list describing each tile (source file, exact pixel, scaling factor, rotation etc)
if you make a pull request and all looks stable i don't see an issue with merging it?
I'll do that when it's halfway finished. But it will take some more weeks...  |
|
|
|
Actually, the Namecoin port is long finished and the Huntercoin port is not only planned but progressing very well. I do not have any ETAs or a roadmap, but at least the up-to-date implementation can be found on https://github.com/domob1812/huntercore/ at any moment. It is already able to sync the full blockchain and to serve game_getstate calls. It is also able to prune the blockchain based on Bitcoin's feature, which according to some tests snailbrain did reduce the blockchain size to something like 1.5 GiB. Even less may be possible in the future with some more tuning of parameters. Note, however, that the new client does not yet handle the wallet well (game transactions won't show up), nor can it be used for mining. Can it serve the blockchain too, i.e. is it possible/recommended to use a huntercore node to connect to the network and then connect a v1.3.01 daemon or Qt-client to your local huntercore node... ...if the v1.3.01 node has no blocks? ...if the v1.3.01 node already has an almost up to date blockchain? |
|
|
|
Quick hack to make the Qt client more usable for game play: https://mega.nz/#!GU0hFCjJ!0oFP-u7KRs9tm3WbqQzObanp7i0sdgdmwK_sIuBtTaE - "pending tx monitor" to reroute output from the console command "name_pending" to GUI input:
name_pending 5 start the "pending tx monitor" so it will update every 5 seconds (console is not available while it runs)
middle mouse button stop it (need 5 seconds to stop)
Ctrl+middle mouse button toggle between active and inactive (i.e. no alarms).
names.txt up to 20 player names + distance to trigger alarm (2...9, 0 to disable alarm for this player). Changes are effective after restarting the tx monitor.
output:
small_wave_file.wav played (by asking the OS to open it) on alarm, must be in same folder as debug.log (not included, windows system sounds work just fine)
*ALARM* <name> [<name>] after player names in case of alarm
*Idle* <name> after player names if a player is out of waypoints and there is currently no alarm
x,y->x2,y2 after player name, coors currently and expected after next block
wp:... after player name, next waypoint
tx*<age>:... after player name, value of pendig tx, and how "old" it is
CONTACT*<age> we will be in destruct range with an enemy player after next block. If started with "name_pending 5",
then "CONTACT*4" or "CONTACT*5" (20 or 25 seconds) is basically seeing the white in their eyes
- banks show remaining blocks, and a gauge that is visible when zoomed out  |
|
|
|
A mobile client with built in automation (or at least defense tactics) would be an amazing evolutionary step. It may be a bit difficult to market huntercoin as a mobile app in its current iteration though as the trend in mobile gaming is heavily skewed towards the ~1 minute game time. If you could take the ron propeil approach and "set it and forget it" and return at random irregular intervals, I would certainly use it daily.
I absolutely agree, but is it consensus that an "AFK" mode (i.e. automated destruct if neccessary for self defense, and perhaps also an "I'm done playing today, you guys go to next bank as soon as one comes in range" mode) would be beneficial for HUC and the market cap. Should all clients have such a thing built in? |
|
|
|
|
Show Posts
