Recent Posts

Pages: 1 ... 8 9 [10]
91
Development / Re: gameFund - 2017
« Last post by foglight on October 19, 2016, 03:10:44 PM »
treasure chests, zombies running around carrying free coins... way cool.  ;D

ok tbh, i just noticed how huge it was recently and got startled.

92
Development / Re: Gameplay change (hard fork) wish list
« Last post by foglight on October 19, 2016, 02:54:33 PM »
all, thanks for entertaining my thoughts.

wiggi, i will continue to think on adaptive algorithms and if i come up with any reasonably sounding ones, i'll present them here. 

MM, +1 to your idea of implementing changes _after_first_distaster_after_block_N_

wiggi, it sounds like you would prefer a higher cost game with fewer players. did i read correct you would prefer ~50 individuals on the board at one time? is that not orders of magnitude too low for a "successful" global decentralized game? when you have time, i'd like to hear your thoughts on this one?

MM, i know your thoughts on accessibility to the game... i think we're on the same page mostly.

93
Development / Re: Gameplay change (hard fork) wish list
« Last post by Mithril Man on October 18, 2016, 05:28:09 PM »
if i remember the fee change happened after the first disaster after the specified height (not sure tho) anyway you could apply the same logic: after the first disaster with height > xxx apply changes, this way there is no risk that hunters with different value coexists.
94
Development / Re: Gameplay change (hard fork) wish list
« Last post by wiggi on October 18, 2016, 04:04:59 PM »

I think we should release changes on the new huntercoincore.
Yep, release on the old Huntercoin and on Huntercore at the same time.
I'll make the (hopefully) final testnet in a box with both Huntercoin-qt and Huntercore-qt.


Btw, can someone remember, when the "lifesteal" fork began, did old hunters that had cost only 10 HUC co-exist on the map with the new 200 HUC hunters. (What happened if you life-drained them etc)

95
Development / Re: [ANN] Huntercoin Core - ready for first testing
« Last post by Snailbrain on October 17, 2016, 04:20:40 PM »
i got the same issues on windows.. would not shut down the qt after trying to do movies through RPC.

i managed to create some names manually in the console and move them.. and the unity client worked too..

it seems intermittent (the worst sort of problem).

really need some other testers please
96
Development / Re: Gameplay change (hard fork) wish list
« Last post by Mithril Man on October 16, 2016, 08:33:01 PM »
it's a well known guess that having a low fee game and a prunable chain with an easy setup would bost the game popularity because actually what's prevent people from joining the game is the startup difficult and the cost to play, all other issue are secondary.

while we focus now on lowering the fees (even fixed fees are ok at this stage, we just need to have much lower fees) the other aspect is still unknown to me
did you wiggi code on standard old huntercoin code?
how far did we are about using new one with pruning feature?
I think we should release changes on the new huntercoincore.
97
Development / Re: Gameplay change (hard fork) wish list
« Last post by wiggi on October 16, 2016, 12:54:51 PM »
To expand on option C. I was thinking of a longer time window to determine fees - like days. The purpose being to regulate the cost with median map density over days, not short time scales. generally, all players on the board at any given time would cost a similar amount. However, even on shorter time scales, it could add an additional strategic element to the game.

I would prefer option C too, but in practical terms, we don't know what the formula should be. Reacting to sudden popularity when it causes increase in both hunter population and HUC:fiat price (which the formula doesn't know) with a spike in hunter cost would perhaps not be good.

The current gamestate also has no capacity for additional statistical numbers, to add them would cause delay with new rounds of testing and would remove the fallback option for polo and the miners to just put a "new old" daemon in and leave the existing blockchain in place. (We don't know if Huntercore daemon will choke on polo's probably massive wallet which was created by the old daemon)

I personally would prefer a game where 50 human players play a relatively short session, and have 1 or at most 2 hunters each that they monitor personally at all time because they are expensive. (*) If around this time next year Huntercoin is really popular, then hunters can become cheaper, but together with other changes like a map redesign with more harvest areas to accommodate for more players.

(*) and more about psychological tension than clicking alot of things, the "monitor personally" would also level the playing field for mobile/light clients that won't have automatic movement and destruct functions
98
Development / Re: Gameplay change (hard fork) wish list
« Last post by foglight on October 15, 2016, 04:12:52 PM »
Wiggi and SirWaggs, 

   It sounds like you guys like the idea of dynamic fees, and i agree. i prefer that type of solution as well. To expand on option C. I was thinking of a longer time window to determine fees - like days. The purpose being to regulate the cost with median map density over days, not short time scales. generally, all players on the board at any given time would cost a similar amount. However, even on shorter time scales, it could add an additional strategic element to the game.  but i do see the point about it being the opposite of promoting growth. billions of players for example :)

regarding your dislike of pegged costs, just realize this is what has had to happen in the past and is what is going to happen again now... so in reality, something like option A is likely the most practical solution.

overall, i support any attempt to move to a dynamic fee.

simply put, what should the cost to play be?







99
Development / Re: Gameplay change (hard fork) wish list
« Last post by Mithril Man on October 15, 2016, 01:56:50 PM »
Note that important state changes (hunter invulnerable, hunter is spectator, coins ghosted) can directly be calculated from
2 gamestate variables, either characterstate.stay_in_spawn_area or gamestate.nHeight, so visualization should be easy for all clients that work by fetching the gamestate from daemon.

3rd party client like mine, or external GUIs that relay on huntercoin/huntercoincore daemon, shouldn't implement any business logic that compute a status, but just reflect the status it reads from the returned JSON of the game_status call

So any new status should be reflected in those JSON returned.
It's not about lazyness, but about good software architecture practices and separation of concerns
100
Development / Re: Gameplay change (hard fork) wish list
« Last post by sirwagginston on October 15, 2016, 06:23:47 AM »
20% of blocks ghosted: it would be 15%, one 100 blocks break and one 50 blocks break per 1000. We can vote the numbers, or even kick this out in case everyone is confident that it is not needed to un-dominate the map.

I thought it was 50 blocks per 500, which would be another 100 per 1000 = 200 / 1000 = 20%. Personally, I kinda like this idea, but I favor no more than 10% max.

Pegged currencies attempts, afaik, have all failed in their implementation, they aren't reliable and as i said we should avoid being dependend on external services
I'm not against the solution idea per se, but technical implementation prevent this solution to be implemented properly

Yeah, I don't think it's within the scope of what we can do with the upcoming fork. We have to just make a guess on the price and lower the fee to something. The fork after that, we can do something fancy.

Perhaps we can have both, not annoy players too much and still have a big wave of new hunters, by making the ghosting partial.
Example: for 150 blocks, every 4th coin spawn is ghosted (game continues normally but coins already accumulate)
    then for 30 blocks, 3 out of 4 coin spawns are ghosted (2 out of 4 would look ugly graphically)
    then for 20 blocks, full ghosting
repeated every 500 blocks so that every "timezone" has one event per day

can be done by just changing the formula. It's not ghosted if...
Code: [Select]
if ( (((x % 2) + (y % 2) == 0) && (nHeight % 500 < 480)) ||
     (((x % 2) + (y % 2) <= 1) && (nHeight % 500 < 450)) ||
     (nHeight % 500 < 350) )

Would have to check for each hunter if they're allowed to loot at the current chronon and coordinates, but still fast and easy.

I really like this idea, way better than the simple ghosting idea. It gives the game sort of a day/night cycle, and diminishes the likelihood of interfering with players who don't care for it.
Pages: 1 ... 8 9 [10]