Author Topic: Gameplay change (hard fork) wish list  (Read 7705 times)

wiggi

  • Global Moderator
  • Full Member
  • *****
  • Posts: 150
    • View Profile
Gameplay change (hard fork) wish list
« on: September 15, 2016, 01:52:09 PM »
Currently, if a player uses less hunters than another player, or his gaming session is shorter, then he is at a systematic disadvantage over that other player.
If the difference becomes larger, the disadvantage also becomes more severe. Basically, Huntercoin has an implicit tax-the-poor behavior like Monopoly.


1) If a player want to start playing, they will spawn on a random walkable tile and must walk to an harvest area of their choice. This will take more than 1 hour on average, because the nearest harvest area is likely to be already occupied, sometimes by more than 1 hunters. (the dysfunctional fee system also plays a role here)

By contrast, the group of players known as the dominator, either have hunters on the map 24/7, or can walk to the harvest areas while another player of this group is still there (so they don't lose coins because of it)


Solution: players spawn only on tiles that are adjacent to a tile that is adjacent to a coin harvest tile.
(easy to auto-generate this list of tiles)

So:
Code: [Select]
#  unwalkable tile
c  coin harvest tile
.  adjacent tile
p  player spawn

 pppppppp
pp......p
p..cccc.p
p.ccccc##
p.cccccc#p
p.cccccc.p
p...cccc.p
ppp......p
  pppppppp

This is also not so psychologically frustrating like being forced to do a long walk. (while watching the action on the map and seeing who the sucker in this game is)


2) Give the banks fixed positions on tiles adjacent to coin spawn tiles. Only some unimportant outer ring harvest areas may not have an adjacent bank, but then they also can't have nearby player spawns (so no hunter is stranded in the middle of nowhere) Because no one will accidentally step on banks, despawn time can be reduced from 3 blocks to 1
this is actually not good because you would see mobs of 4 or so waiting to gank single hunters on the way to the bank.

Solution to avoid this, and keep banks useful: Banks can't spawn on all walkable tiles but only on coin harvest tiles 'c' and adjacent tiles '.'

Bank despawn time is reduced fron 3 blocks to 1 (you can walk over them, but standing still on them means immediate despawn)

Player spawn tiles 'p' work exactly like banks work now. All of them. (so that a newbie player is never forced to fight a mob of gankers just to reach a bank)

This saves players from having to do another 1-3 hours long walk with no guaranteed maximum because you have to despawn all of your hunters. Again, if the dominator does this, then while his buddy is farming (so they don't lose coins because of it)


Enough for today. Next part: how the game wastes not only your time but your coins too and how to fix it


Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1000
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #1 on: September 15, 2016, 06:06:36 PM »
i'm ok to go with this or slight revisions if needed.

no2..
so banks spawn in coin areas? sometimes bank is only 2 blocks away, sometimes in another coin spot (far away?), or always a bank in each coin area?

only worry is -
i'm not sure what happens if we do get more players if it will all work or am i missing something? won't it get saturated around these spots?

do we also need to do something with combat with this fork?



Mithril Man

  • Hero Member
  • *****
  • Posts: 589
    • View Profile
    • Mithril Man Web!
Re: Gameplay change (hard fork) wish list
« Reply #2 on: September 15, 2016, 07:40:46 PM »
@wiggi

i stopped playing for coin costs (fees, etc..), that lead to low or negative ROI and unbalanced gameplay, so I'm fine with changes, even tomorrow!
But what you suggest (spawning near coin harvest cells) can cause more cons than pros, because the dominator(s) (I know who they are, they are 3 and are coordinated and don't fight each other, and they use my client) can just camp there and wait for newcomers to blow them up, and a simple bot would have a lot of advantage to destruct as soon as a new player spawn next to him.

I already talked a lot about issues, more than one year ago, but nothing has changed since than, I hope you'll have more luck about gameplay changes, anyway just to recall about my past proposals, I talked about:
- Teleporters
- ammo/weapon combat system with abilities cooldowns
- very low fees to give a chance to everybody to win 0.0001 instead of few people to win 100 (distribution!)

Mixing your idea with the teleports one, we could have random teleporters like banks that spawn in pair, so you know in advance that taking a teleport X would teleport you to the Teleport X2 and newplayers could spawn in an area where lot of teleporters spawn

@snailbrain
I wouldn't worry about having too many players, because actually the problem is the opposite, I would be very happy about having troubles to fix a overpopulated game.
A fix to overpopulation, in the long term, could be the implementation of an Account system, that allow you to create few hunters at a decreasing price each one, but limited
(e.g. 1st hunter in game costs 50, 2nd 40, 3rd 30, 4th 20, 5th 10 and you can't have a 6th in the same account (just throwing random numbers but explaining the rational)
« Last Edit: September 17, 2016, 12:58:49 AM by Mithril Man »
Alternative GUI client for Huntercoin http://www.mithrilman.com
HUC donation: HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE
BTC donation: 1DKLf1QKAZ5njucq37pZhMRG67qXDP3vPC

wiggi

  • Global Moderator
  • Full Member
  • *****
  • Posts: 150
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #3 on: September 16, 2016, 02:38:08 PM »
Second part, mostly about fees (very low fees and cooldown was recommended by Mithril a year ago, I was against it but for reasons that are now irrelevant)


3) Reduce the 5 HUC fee for a new hunter to 1 HUC. (if someone would use this to recycle hunters rapidly it would still cost them almost 100 HUC to attack 1 specific harvest area with just 1 hunter)

This saves normal players another 30 minutes, because with current hunter population size it takes 1 hunter 30 minutes to harvest 4-5 coins, on average.


4) Currently, if you would play, it's like this: you make 20 hunters, harvest 500 coins, attack or (more likely) get attacked and have to destruct 25 times,
kill 3 hunters, die 3 times.

Result, You: 0 HUC, Dominator: 11500 HUC
No one can play unless able and willing to conquer (and hold, for a long time) large parts of the map, to finance the war efforts.

Solution: Reduce the destruct fee to either 1 or 0 HUC, and (just to be safe that the combat mechanism cannot be broken when transactions suddenly confirm faster, for whatever reason) replace it with a rule that hunters can't destruct if they have destructed in previous block.


5) For the sake of extensibility, allow hunters to spawn in a state where they are unable to harvest, kill, or be killed. (spectator mode)

This would also facilitate a possible crowdsale with the resulting tokens directly on Huntercoin's blockchain,  (proposed by Bitcoin Co-op) thus demonstrating that Huntercoin gamestate is as powerful as the systems of Nxt, Bitshares, Ether, Lisk etc.
And because this is Huntercoin, buyers of the crowdsale tokens will need a live hunter to administer their "accounts". without a spectator mode for hunters, the buyer's user experience won't be that good.


Implementation:

Currently when hunters spawn, the "color" variable can be set to 0-3 for the 4 team colors. If it can be set to 0-7, then (color&4) would render them unable to harvest, kill, or be killed. They would also spawn at the bases, like in the old times. I think the normal fee (200HUC refundable + 1HUC not refundable) is enough for spam protection.

And, if a hunter destructs, then (color|=8) is set. If (color&8 ) is set, then destruct is ignored. Then this flag is always cleared.


6) If the gamefund need more coins (it probably does) it would be ok if a fee is charged similar to deathtax (i.e. double deathtax). Ok because it would hit everyone equally, and 10% would replace the "cash flow" from current destruct fee.


wiggi

  • Global Moderator
  • Full Member
  • *****
  • Posts: 150
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #4 on: September 16, 2016, 03:02:41 PM »

no2..
so banks spawn in coin areas? sometimes bank is only 2 blocks away, sometimes in another coin spot (far away?), or always a bank in each coin area?
just as randomly as now, only the list of possible positions is reduced. No guaranteed bank at every harvest area because the player spawn tiles also work as banks, just a bit slower. The layout is so that players don't accidentally despawn.

only worry is -
i'm not sure what happens if we do get more players if it will all work or am i missing something? won't it get saturated around these spots?

I'd expect more players but not necessarily more hunters. Except outer ring, each hunter already sticks to 1 harvest area.

And with more players, if someone makes too many hunters, they would face near simultaneous attacks on many hunter by the other players. I don't know what will really happen, but the current dominator would lose big if 10 of their hunters get attacked at the same time by 10 different human players.


wiggi

  • Global Moderator
  • Full Member
  • *****
  • Posts: 150
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #5 on: September 16, 2016, 03:29:41 PM »
But what you suggest (spawning near coin harvest cells) can cause more cons than pros, because the dominator(s) (I know who they are, they are 3 and are coordinated and don't fight each other, and they use my client) can just camp there and wait for newcomers to blow them up, and a simple bot would have a lot of advantage to destruct as soon as a new player spawn next to him.


That's the reason why I want the player spawn not directly adjacent to the harvest tiles, and the player spawn tiles also working as banks.

If a player spawns, he can look at the number of campers, and decide to not fight by just standing still for 3 blocks to despawn
like with the banks now.

The chance to actually spawn in destruct range to another hunter, or have another hunter spawn in destruct range to your own, is very low. (made even lower if you find a bank on one of the coin spawn tiles, which is very likely). I'd guess for single hunter's lifetime (spawn, go to harvest tiles, then go to bank, despawn), if 2 new hunters spawn per block, the chance, or risk, is 2 * (2 blocks spent before stepping off the player spawns) * (3 player spawn tiles within range) / (80 harvest areas) / (30 player spawn tiles per harvest area) = 0.005

Slightly more if there's no bank and the hunter must go back to the player spawns to use them as bank.

(and if it happens, every client must be able to deal with the situation)

edit: The current dominator can often be encountered with pants down, they aren't really that strong or eternally vigilant.
It's mostly the wide space of the map that saves them in such cases from taking more losses.

I tried to make this list as technically simple as possible, and cut out all the fancy things that would be nice to have, but discussing them now would increase the risk that we can't decide anything in the end.

« Last Edit: September 16, 2016, 04:31:21 PM by wiggi »

sirwagginston

  • Newbie
  • *
  • Posts: 48
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #6 on: September 17, 2016, 03:28:10 AM »
I'm gonna chime in from time to time to try to keep things concise and on-track. Here's what I'm seeing so far:
  • We should go with wiggi's idea of extending the color system. Not only could we make an additional "color" for spectator mode, which we will need for our plans, but it could be adapted even further for other things down the road. For example, we could have another set of colors (yellow2, blue2, red2, green2) that don't interact with the first set, allowing us to choose different maps that we don't want to be linked by portals of any kind (different worlds).
  • We need to revisit wiggi's reinforcements idea. Allowing one Hunter to summon another controlled by the same player reduces the logout time vastly, which is a major complaint. It also may help with the issue of taking a long time to start the game if you start somewhere far from the action. Any remaining kinks in the existing gameplay after that could be ameliorated with portals, so we might need to revisit that now, too.
  • We need to think some more about the fee structures for Hunter creation, destruct, etc. It could be a while before we get to change them again. I don't think we need to worry about boosting the game fund; last I heard from snailbrain, it's relatively wealthy. We should avoid getting into new weapons and armor until the aforementioned is sorted out, or else I fear things will stall.
« Last Edit: September 17, 2016, 07:10:07 PM by sirwagginston »

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1000
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #7 on: September 17, 2016, 03:20:22 PM »
I think just go with Wiggis ideas for now -
I agree we don't have the man power and will result in more stalling if we starting thinking about more complex changes (as previously discussed)
@mm we don't have the man power to do these changes yet/still unless you can find someone. Domob is very busy and still needs to finish off Huntercore.

best with little simple changes unless someone can put some $$ up to get things done faster..

--

Quote
Solution: Reduce the destruct fee to either 1 or 0 HUC, and (just to be safe that the combat mechanism cannot be broken when transactions suddenly confirm faster, for whatever reason) replace it with a rule that hunters can't destruct if they have destructed in previous block.

If destruct fee is 0, what is to stop someone covering all spawn areas with a script spamming destruct every other block? (or same colour hunters on the same block, spamming destruct so when a hunter spawns he dies next block)

Quote
5) For the sake of extensibility, allow hunters to spawn in a state where they are unable to harvest, kill, or be killed. (spectator mode)

are we not better just implementing the "allow normal namecoin names" to save the complexity? (and then allow people to create games on top of huntercoin VERY easily, i could probably do one myself)... this change will probably be very easy.

« Last Edit: September 17, 2016, 03:25:04 PM by Snailbrain »

sirwagginston

  • Newbie
  • *
  • Posts: 48
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #8 on: September 17, 2016, 07:03:11 PM »
Quote
Solution: Reduce the destruct fee to either 1 or 0 HUC, and (just to be safe that the combat mechanism cannot be broken when transactions suddenly confirm faster, for whatever reason) replace it with a rule that hunters can't destruct if they have destructed in previous block.

If destruct fee is 0, what is to stop someone covering all spawn areas with a script spamming destruct every other block? (or same colour hunters on the same block, spamming destruct so when a hunter spawns he dies next block)

I agree that 0 is untenable, but the current fee is too high.

Quote
5) For the sake of extensibility, allow hunters to spawn in a state where they are unable to harvest, kill, or be killed. (spectator mode)

are we not better just implementing the "allow normal namecoin names" to save the complexity? (and then allow people to create games on top of huntercoin VERY easily, i could probably do one myself)... this change will probably be very easy.

Remind me about the normal names thing and what it's needed for? I thought extending the color system doubled as a good way to allow other maps and games on top of Huntercoin, like before when we were talking about having a world variable saying what world a Hunter is in, chosen at spawn.

EDIT: just refreshed myself. It seems that your "normal names" idea requires setting up a new variable, anyways. When you say normal names, you're talking about the world system and having one world that's spectator-like? In that case, wiggi's idea of extending the color system might be simpler, because it just extends the range of an existing variable--the color system.
« Last Edit: September 17, 2016, 07:14:48 PM by sirwagginston »

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1000
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #9 on: September 17, 2016, 08:11:25 PM »
it should be simpler to enable normal names - basically, exactly same as creating hunter, except you are not in the game and you do not affect gamestate.

I suspect it would take domob 10minutes to do..
no complexity. it's just making huntercoin also act like namecoin - except you can make it so your name is 200 hucs or more, but it never dies or expires in the huntercoin chain - of course it could die in someones own built gamestate (alternate world/reality).

Quote
EDIT: just refreshed myself. It seems that your "normal names" idea requires setting up a new variable, anyways. When you say normal names, you're talking about the world system and having one world that's spectator-like? In that case, wiggi's idea of extending the color system might be simpler, because it just extends the range of an existing variable--the color system.

no, all you doing is probably changing a couple of lines of code, and making huntercoin 100x more powerful :D

nothing as complex as what you are thinking -

when you create a hunter in huntercoin you are just creating a name like in namecoin. except huntercoin has a "gamestate" which also puts you on a map and calcualtes were you are and if you are dead.
all the idea is, is that you don't appear in that gamestate. you are just a name ready to assign values to - so you could be in 0 or 1000 games - imagine it like creating an account.
« Last Edit: September 17, 2016, 08:13:50 PM by Snailbrain »

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1000
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #10 on: September 17, 2016, 08:18:25 PM »
could do both

also could just be - set colour 5, and you just act as a normal name

sirwagginston

  • Newbie
  • *
  • Posts: 48
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #11 on: September 17, 2016, 09:54:43 PM »
I think we should do both. Normal names have additional gameplay value for players who are on the map--others can't impersonate you by picking the same Hunter name. Reputations can be established more officially. You can still fuck with people for fun by making additional normal names.

We could thereafter use colors to decide what world to put a Hunter in (or none, to spectate). We could leave a range of values open for independent modders

Mithril Man

  • Hero Member
  • *****
  • Posts: 589
    • View Profile
    • Mithril Man Web!
Re: Gameplay change (hard fork) wish list
« Reply #12 on: September 18, 2016, 12:41:16 AM »
are you sure that the color is still useful?

I mean that probably, to counter who fights with too many hunters, turning on friendly fire (so let a yellow destroy another yellow) would be good
Colors where useful in the past, when hunters spawns at their corners and so friendly fire would generate a massive mess with the gameplay, but now the color is pretty decorative and not really adding much to gameplay.

So I'd remove completly the color concept, and maybe add an attribute for the skin or in future the class of the character.
I agree with snailbrain about implementing the namecoin stuff (afaik current limitation on huntercoin was done by purpose to not have a full clone of namecoin, that in their (snail&mikhail ?) thoughts could cause a namecoin price drop) so this would be really convenient to have it implemented and would open all kinds of custom contests and fancy stuffs more easily.

If registering a name you could add some custom properties, this would mean having an open container to place anything, even for creating the account system

about the color, if it's simplier (but i found it confusing) use it as a "skin" or "class" selector, we could at least rename it ingame
Alternative GUI client for Huntercoin http://www.mithrilman.com
HUC donation: HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE
BTC donation: 1DKLf1QKAZ5njucq37pZhMRG67qXDP3vPC

sirwagginston

  • Newbie
  • *
  • Posts: 48
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #13 on: September 18, 2016, 02:08:03 AM »
are you sure that the color is still useful?

I mean that probably, to counter who fights with too many hunters, turning on friendly fire (so let a yellow destroy another yellow) would be good
Colors where useful in the past, when hunters spawns at their corners and so friendly fire would generate a massive mess with the gameplay, but now the color is pretty decorative and not really adding much to gameplay.

So I'd remove completly the color concept, and maybe add an attribute for the skin or in future the class of the character.
I agree with snailbrain about implementing the namecoin stuff (afaik current limitation on huntercoin was done by purpose to not have a full clone of namecoin, that in their (snail&mikhail ?) thoughts could cause a namecoin price drop) so this would be really convenient to have it implemented and would open all kinds of custom contests and fancy stuffs more easily.

If registering a name you could add some custom properties, this would mean having an open container to place anything, even for creating the account system

about the color, if it's simplier (but i found it confusing) use it as a "skin" or "class" selector, we could at least rename it ingame

I'm not necessarily for or against removing the color-based combat system. Either way, though, renaming that variable makes sense, since we would intend for it to be used outside the original game world. It would allow us to make up new classes in the existing world if we wanted to, as well, but the part where it would allow modding is key.

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1000
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #14 on: September 18, 2016, 10:02:41 AM »
I think we should do both. Normal names have additional gameplay value for players who are on the map--others can't impersonate you by picking the same Hunter name. Reputations can be established more officially. You can still fuck with people for fun by making additional normal names.

We could thereafter use colors to decide what world to put a Hunter in (or none, to spectate). We could leave a range of values open for independent modders

with the normal names, when i said it's like an account, - it would be separate from huntercoin game, no one would know (easily) they were/are your characters on the normal huntercoin map - unless some additional development was done.

with normal names, like namecoin, it would be independent of your huntercoin names.
by account, i mean, an account for everything but huntercoin...

you could do what you said there maybe by transferring hunters to the hunter-name address (or putting the reward address of the hunter-name), then everyone would know it's you..

note, like mm said, we didn't originally want to hurt namecoin by making huc do what namecoin can - and i also would like to try to enforce (not really possible physically) that we use it just for gaming stuff.
i.e. we don't support anything to do with domain name registration, or the other main use cases of namecoin. It will probably be too expensive to do so anyway..



are you sure that the color is still useful?

I mean that probably, to counter who fights with too many hunters, turning on friendly fire (so let a yellow destroy another yellow) would be good
Colors where useful in the past, when hunters spawns at their corners and so friendly fire would generate a massive mess with the gameplay, but now the color is pretty decorative and not really adding much to gameplay.

So I'd remove completly the color concept, and maybe add an attribute for the skin or in future the class of the character.
I agree with snailbrain about implementing the namecoin stuff (afaik current limitation on huntercoin was done by purpose to not have a full clone of namecoin, that in their (snail&mikhail ?) thoughts could cause a namecoin price drop) so this would be really convenient to have it implemented and would open all kinds of custom contests and fancy stuffs more easily.

If registering a name you could add some custom properties, this would mean having an open container to place anything, even for creating the account system

about the color, if it's simplier (but i found it confusing) use it as a "skin" or "class" selector, we could at least rename it ingame

I'm not necessarily for or against removing the color-based combat system. Either way, though, renaming that variable makes sense, since we would intend for it to be used outside the original game world. It would allow us to make up new classes in the existing world if we wanted to, as well, but the part where it would allow modding is key.

i think we need a bit more info on the colour system change - as atm, i think mm is right, we could just remove the colour system and use normal names.

that change would be trivial for domob.

with the names - mm can make his own world / game using his own client, with his own rules and his own coins, MM coins (the gamestate is in his client, maybe need some opensource gamestate calculator or adapted huntercoin client so exchanges know how much coins someone owns)... wiggi can do the same.. i can do the same.. and we could even have some plugin/module in which people can easily put in their own gamestate/rules (or full on super complex cryptocurrency/smart contracts better than all other cryptos combined..)..

the external clients created to use these alternative gamestates (not included in the huntercoin code), would need to do an rpc for every block to sync (to get name transactions) in the alternative game clients.

as wiggi has pointed out - the ultimate thing about huntercoin - is the gamestate - the thing is, the gamestate can be done outside of the box - as long as every move/nametx in huntercoin is crypto-graphically secure then it doesn't matter if the gamestate is outside of huntercoin (just that we can't mint huntercoins, only alt-coins).

for now - just enabling normal names would be an easy start and all complexity above can be ignored.