Recent Posts

Pages: 1 ... 8 9 [10]
91
Development / Re: Gameplay change (hard fork) wish list
« Last post by wiggi on October 12, 2016, 09:17:45 PM »

1 - about blocks ghosted
I don't think that is a good idea because it limits at some extents the game for casual players who just want to go in, play some minutes and go out and didn't help about dominator issue, because my direct experience with them says that they are always active even for pvp (at least one of them). I'm always a beliver that the main anti-dominator will be having lots of players to face, so the more the map is populated, the less the dominators can ...dominate

this mode rises even some technical aspect to consider (but not that importants): the GUI should reflect that coins aren't pickable (so remove them from the map or change the aspect) and it should be clear to users, so game_state (thinking to my client extensions or other possible ones) should include that block is in "block ghosted" mode (but I think that at a gameplay level, that features doesn't fit well)
But i'm more concerned on the feature itself that technical aspects


Because of encapsulation issues, I did implementation for GUI by copying the formula that calculates the state from block height. So:
https://github.com/wiggi/huntercoin/blob/master-timesave/src/qt/gamemapview.cpp#L97
All clients can do this too.


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.

92
Development / Re: Gameplay change (hard fork) wish list
« Last post by Mithril Man on October 12, 2016, 05:33:11 PM »
some considerations:

1 - about blocks ghosted
I don't think that is a good idea because it limits at some extents the game for casual players who just want to go in, play some minutes and go out and didn't help about dominator issue, because my direct experience with them says that they are always active even for pvp (at least one of them). I'm always a beliver that the main anti-dominator will be having lots of players to face, so the more the map is populated, the less the dominators can ...dominate

this mode rises even some technical aspect to consider (but not that importants): the GUI should reflect that coins aren't pickable (so remove them from the map or change the aspect) and it should be clear to users, so game_state (thinking to my client extensions or other possible ones) should include that block is in "block ghosted" mode (but I think that at a gameplay level, that features doesn't fit well)
But i'm more concerned on the feature itself that technical aspects


2 - Hunter cost
(Talking about hunter cost, we should consider even other fees, Destruct fee is INSANE and prevent having a fun PVP, it should be set to a 1/100 ratio , so if a hunter costs 10, a destruct costs 0.1)
Hunter cost is not an easy aspect, but I think that's better to have an overcrowded map with lot of human players that an empty one with just few players.
This mean that in the long run I'm for popular fees and the blockchain bloating has to be solved with technical implementations and should not be a limit of the system.
Would be nice to change the cost dynamically but various proposed ideas have pros and cons but I'm not fully convinced by any suggestion.
Let me explain replying to foglight:

Quote
A) regular scheduled hard-forks to update the hunter_cost
- ex, if its scheduled once per 100 days, this could be a simple solution to keep the costs within some desired $ range.

B) hard code cost of hunter to usd value
- ie, $1 dollar per hunter. continuously calculated via exchange rate

C) hunter_cost = median(num_players_per_sq) * A; // where A=100 or some other constant.

A) is too invasive. Hard fork is something that should be avoided, it requires exchanges to be updated and legacy system too, with the risk of causing incompatibility, etc...
Personally i'm against this solution.

B) being bound to a FIAT could change constantly the balance between the PVP potential income and the Looting aspect of the game. This could be at some extent positive because the game dynamics change constantly and at a given time, some action my have a better ROI than another. On the other hand this could help the dominators, because if huc price increase, hunter cost decrease and he may build up more hunters to collect. But low price mean even that more player can play, so he would have an hard time fighting in pvp.
This mode can be fun, but the problem i see is that it would be quite tricky to be implemented in a proper way: a player should know in advance how much he will pay for an hunter, so how did he get that value? from where? a decentralized coin shouldn't depend on a centralized asset or resource, so how did you solve that?

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


C) the goal should be to stimulate the game adoption, and the formula that "the more players the more it costs" goes to the opposite direction, moreover the dominators could create lot of hunters to increase artificially the price, preventing casual players to join.
Probably a curve is a better choice, because you can chose target areas where the cost increase/decrease, but anyway a cost based on the numbers is something that, without an account system, could be artificially changed to dominate in another way

Another aspect to consider when talking about dynamic hunter cost, is that the cost itself is the PVP value too, so if i spend 1 HUC for a hunter and you spend 100, if i kill you i gain 100 while you gain 1, not sure this is what we want... and could be a possible argument fom players... if using your formula i join a populated map and spend 100, while the dominator had time to create 100 hunters at a very cheap price, i would pissed off to be killed by him... a lot :)

An alternative could be (but i'm not fully convinced from this too), that the price change every XXX blocks, linked maybe to a fixed disaster
e.g. once every 2 days and 2 hour (roughly 3000 blocks) so that no one has advantage on timezone because of the 2 hours offset that happen every disaster (let me call this concept a "game session")

So everytime the map is cleaned, the hunter price change, based on the previous game session.
We could then chose how to change it, It may change:
- randomly in a range of values
- using a formula that takes into account those variables :
   * previous game session population
   * previous game session  fee cost
   * random variation
   * previous game session game_fund amount (the amount collected only during that game_session

note even that the "game session game_fund amount" is a vauable information that can be taken into account to even distribuite all that amount into the map, as bonus coins or other things, so that we don't risk to run out of game_funds!

I wanted to write more but it's late, sorry
93
Development / Re: Gameplay change (hard fork) wish list
« Last post by wiggi on October 12, 2016, 03:18:45 PM »
testnet in a box: it's always for Windows. Traditionally put it in C:\hunttest then just use the 2 links. It will also run while the windows machine (or VM) is offline.

waiting for domob: would want him to take a look before the fork is actually deployed for Huntercoin mainnet. Everyone else should take a look too.

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.

Hunter cost: I think, even with expensive hunters, every harvest area will get at least 1 hunter (i.e. 80 hunters on map)
When it comes to fighting, hunter cost determines both player fear, and player greed. ;)
We could vote hunter cost.

But unless hunter cost is *very* low, I expect population around 100, so the game would cater to >= 100 actual players at the same time. If overcrowded, it gets kinda nasty (maybe in a fun way), with both risk and reward skyrocketing.

Other proposed features: I wouldn't want to add anything else because of complexity.
For viewing pleasure, there's now a v1.3 old-Qt based version with exactly 1 "FORK_TIMESAVE" per code change. (Github branch master-timesave) Count is 24, this is more than enough already.
I'll make another testnet in a box, and of cause port it to Huntercore (without the graphics part) when needed.

chronoDollars: is fully functional, but should first have lots of use and testing under heavy load conditions before it can become part of the Huntercoin core protocol
94
Development / Re: gameFund - 2017
« Last post by foglight on October 12, 2016, 03:04:25 PM »
2x btc so 42 million, my mistake.

ok. so these coins in the gameFund are scrapped off the board from the players and placed in the gameFund. the coins are real! great!

imo, these coins are for the player and should promote game play. they will eventually hit the exchange, but that is ok, it must happen.


SO... random distribution around the board, at a slightly greater than the rate they are being put in there, for now ?




95
Development / Re: gameFund - 2017
« Last post by Mithril Man on October 12, 2016, 02:54:51 PM »
ok back up a second...

Do these gameFund HUCs exist as part of the 48 million total supply?

yes they are parts of the total supply because are the fees collected during the game (not sure about the total suppli, wasn't 42? could be wrong)
96
Development / Re: gameFund - 2017
« Last post by foglight on October 12, 2016, 02:48:33 PM »
ok back up a second...

Do these gameFund HUCs exist as part of the 48 million total supply?

97
Development / Re: Gameplay change (hard fork) wish list
« Last post by sirwagginston on October 12, 2016, 09:35:19 AM »
Brief recap: it looks like we've settled on tile reduction as the solution to our gameplay problems... it looks like he's successfully made it so that Hunters always spawn near coins (spawn tile reduction), but the bank tiles haven't been reduced, yet.

You didn't actually look at it, right?

Player spawn tile reduction is working.
Bank spawn tile reduction is working.
Additionally you can logout on the player spawn tiles, faster than currently on banks
Fee reduction to 1 HUC is working.
Hunters who stand there for longer than 5 chronons will irrevocably become spectator.

I didn't run the testnet, no, my apologies. I'm a Windows guy, and a disaster at my IRL fiat job (a female ESL student murdered) has kept me very busy.

I just recalled a statement on Skype about you waiting for domob for something. Is that not the case? If so, then great. :) There's other fork stuff we should continue to discuss.

I like the ghost coins idea, but I think the frequency is too high.

Yes, could be reduced a bit. perhaps:
 for 100 blocks after every full 1000 blocks, and
 for 50 blocks after every full 500 blocks?
If nerfed too much, it might be not enough to serve its purpose.

That would be 20% of blocks ghosted, correct? We just need to think about how much casual players will tolerate. Could come down to vote.

Also, we must not forget to adjust the fees and Hunter cost, especially with recent price increases. We also really need to revisit the feasibility of tapping the gamefund with something like random coin drops, because it's getting too big. I predicted a while ago that it could scare investors, who view it as a ticking timebomb waiting to hit exchanges.

Yes. Perhaps *not confiscating* hunter loot for the gamefund (in case of disaster) would be a one-liner (in HandleKilledLoot?) and could easily go into this fork. If we've managed to un-dominate the game there will be time to think of intelligent gameplay ideas to tap the gamefund.

Or perhaps it's better to not thinking about gamefund at all because this is what creates the irrational fear of it being dumped (which is just as impossible as with the other 27000000 coins that are not mined. They don't exist. The gamefund coins don't exist, too)

I like the not confiscating idea. I agree that we should try not to harp on it overly much, though, since the funds technically don't exist without a fork.

still reading and thinking but want to try to help improve game play.

1) Cost to play - needs to be cheap when no one is playing and expensive when people are playing,

- caveat, a user can create as many accounts as they like, so account-dependent behavior doesnt make sense.

Potential Solutions:

A) regular scheduled hard-forks to update the hunter_cost
- ex, if its scheduled once per 100 days, this could be a simple solution to keep the costs within some desired $ range.

B) hard code cost of hunter to usd value
- ie, $1 dollar per hunter. continuously calculated via exchange rate

C) hunter_cost = median(num_players_per_sq) * A; // where A=100 or some other constant.

- if, 100 x 100 grid: 10000 squares, and A=100.

a) few hunters    - ~100 hunters, 0.01*100 = 1 HUC to play.
b) some hunters - ~1000 hunters, 0.1*100 = 10 HUC to play.
c) many hunters - ~10000 hunters, 1*100 = 100 HUC to play.

- Cant enforce players paying more per additional hunter as they will just create new accounts. However, this would serve to regulate cost by popularity across the board.


2) use gameFund to randomly distribute coins on the map.
- this will start using the massive account and give back to the players.
- this will provide additional incentive to travel around the map to all tiles.

3) if keeping disasters, keep them randomized.

4) other stuff for later.

Some interesting thoughts, here. Follow up points:

  • We have considered altering the gameplay such that creating additional accounts is penalized. For example, removing the color-based system could enable a friendly fire dynamic... if the game doesn't know your Hunters belong to the same person, they might incidentally hurt each other.
  • Wiggi has put chronoDollars on the Huntercoin blockchain using his client, but I don't know how robust it is, yet. Also, everybody would have to be using his client. So this might require a lot of work. It would be particularly suited to handling Hunter base cost, though (currently 200 HUC, which is separate from the fee and not lost if your Hunter survives)
  • I really like your idea of making the fee vary based upon how many Hunters are on the map (not spectating). It doesn't sound too hard to implement, to me, but I could be wrong about that. If I am, somebody will probably correct me.
98
Development / Re: gameFund - 2017
« Last post by sirwagginston on October 12, 2016, 09:09:55 AM »
so no one has a private key for them to dump any coins.

That's the crucial point
99
Development / Re: gameFund - 2017
« Last post by Snailbrain on October 11, 2016, 08:18:29 PM »
Hi

Originally it was going to be for NPC drops and the Crown of Fortune (maybe a small percent each time goes to whomever gets/does something with the Crown)

For now there isn't a solid plan in place but i think it will just trickle into the game as per the original plan when we do come to utilise it rather than some big spends.

it's "untouchable" as those coins don't really exist, it's just a number. To utilise the coins outside of the game a fork would be required to mint some coins out of thin air and then subtract the numbers from gamestate funds number.

so no one has a private key for them to dump any coins.

all open for disucssion :)


100
Development / Re: Gameplay change (hard fork) wish list
« Last post by foglight on October 11, 2016, 04:41:28 PM »
still reading and thinking but want to try to help improve game play.

1) Cost to play - needs to be cheap when no one is playing and expensive when people are playing,

- caveat, a user can create as many accounts as they like, so account-dependent behavior doesnt make sense.

Potential Solutions:

A) regular scheduled hard-forks to update the hunter_cost
- ex, if its scheduled once per 100 days, this could be a simple solution to keep the costs within some desired $ range.

B) hard code cost of hunter to usd value
- ie, $1 dollar per hunter. continuously calculated via exchange rate

C) hunter_cost = median(num_players_per_sq) * A; // where A=100 or some other constant.

- if, 100 x 100 grid: 10000 squares, and A=100.

a) few hunters    - ~100 hunters, 0.01*100 = 1 HUC to play.
b) some hunters - ~1000 hunters, 0.1*100 = 10 HUC to play.
c) many hunters - ~10000 hunters, 1*100 = 100 HUC to play.

- Cant enforce players paying more per additional hunter as they will just create new accounts. However, this would serve to regulate cost by popularity across the board.


2) use gameFund to randomly distribute coins on the map.
- this will start using the massive account and give back to the players.
- this will provide additional incentive to travel around the map to all tiles.

3) if keeping disasters, keep them randomized.

4) other stuff for later.

Pages: 1 ... 8 9 [10]