Author Topic: simple change proposal  (Read 1909 times)

Mithril Man

  • Hero Member
  • *****
  • Posts: 589
    • View Profile
    • Mithril Man Web!
simple change proposal
« on: February 10, 2016, 09:34:45 AM »
ok, it has been a lot of time since last contrib to dev discussion, but during last days i've tought about a simple changes that could help a lot during the game

one of the worst thing about the game is the fact that you can't predict when your action will take place, this mean that there is a big chance of random fights where you think your action will be executed the next block but it will take twice the time, or viceversa

to partially solve this problem, and even complicate a bit the eventual bot scenario, the idea is to allow to specify a new tx parameter where you can specify the max block height that you want your transaction to be executed. Of course this require an hard fork but we'll need that anyway so this could be an easy and useful improvement

this way a player can e.g. put a constraint on his action in order to disallow his move to take place if the tx isn't processed the very next block. implementing this, the logic of course should be at miner level and at daemon too, in order to take back funds (cancel tx) if the constraints aren't satisfied

an improvement upon this idea would be to add another parameter that says "execute at block height nnnn" so that you can "schedule" an action precisely

of course those parameters should be optional, and if not specified the behaviour should be the actual

what do you think?
Alternative GUI client for Huntercoin http://www.mithrilman.com
HUC donation: HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE
BTC donation: 1DKLf1QKAZ5njucq37pZhMRG67qXDP3vPC

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1002
    • View Profile
Re: simple change proposal
« Reply #1 on: February 11, 2016, 03:19:02 PM »
ok, it has been a lot of time since last contrib to dev discussion, but during last days i've tought about a simple changes that could help a lot during the game

one of the worst thing about the game is the fact that you can't predict when your action will take place, this mean that there is a big chance of random fights where you think your action will be executed the next block but it will take twice the time, or viceversa

to partially solve this problem, and even complicate a bit the eventual bot scenario, the idea is to allow to specify a new tx parameter where you can specify the max block height that you want your transaction to be executed. Of course this require an hard fork but we'll need that anyway so this could be an easy and useful improvement

this way a player can e.g. put a constraint on his action in order to disallow his move to take place if the tx isn't processed the very next block. implementing this, the logic of course should be at miner level and at daemon too, in order to take back funds (cancel tx) if the constraints aren't satisfied

an improvement upon this idea would be to add another parameter that says "execute at block height nnnn" so that you can "schedule" an action precisely

of course those parameters should be optional, and if not specified the behaviour should be the actual

what do you think?

i'm not sure if it's much of an improvement imo, but maybe i've missed something.

95%+ of the time your attack goes off not in the next block, but the block after. not really a big chance of random fights?
Also, even if your attack does or doesn't go in the next block, 99.99% of the time if both hunters destruct at the same time, they will go in the same block as each other? (thought/discussion - if one players destruct goes in the next block which kills the other, then does he not deserve to win because he pressed it first [probably pressed it first]?)
note : to kill someone with your destruct going in the next block you would have to be stood next to them or on the same square.

I think we need mostly to work on the current main problem (after chain size) which is, deadlock/stalemate play. Add some skill/chess to the fights - i think adding a small out of randomness is better than taking out what there already is (if not adding some chess style complexity). just my opinion.

if specifying max height you mean specify either 1 block in future or 2? (i've yet to have a destruct go in 3 blocks ahead, but i guess i'd be dead so i wouldn't know, unless the enemies did the same)

If (your improved idea) the player can select when to destruct, will it help at all because everyone can see it? also what happens if he destructs while moving to a destruct so does 2 destructs in a row, we'd need to consider that but no biggy.

let me know if you think i misunderstood and some scenarios as to why it will help a lot, and against bots


Mithril Man

  • Hero Member
  • *****
  • Posts: 589
    • View Profile
    • Mithril Man Web!
Re: simple change proposal
« Reply #2 on: February 11, 2016, 11:51:10 PM »
my thought was not related to current game play that i already said it's pretty broken atm. I think that randomness is good as long as it doesn't give to players the feels that something nasty is happening, because i really experienced many time the feel of being cheated, because opposite to what you said here:

Quote
thought/discussion - if one players destruct goes in the next block which kills the other, then does he not deserve to win because he pressed it first [probably pressed it first]?

because my direct experience here is that i sent (not just 1 time but several times, even if not very often but the feel is real) my moves before him (and not just 1 second but even about 20+ sometime) and his move have been processed the next block while mine not.
Sometimes i even experienced my move has been processed after 3 blocks instead of average 2 (of course i noticed it when i wasn't in a direct fight and i had the chance to notice that)

note that a technical problem could even be a latency issue or bad connected peers, but this doesn't change what players feels when it happens

I consider this a major problem because a player can legitimately think that there is something going on wrong (altered mining software, peer that doesn't relay some player moves properly, etc...) and this is something that damage the perception of the game. I think it's important to limit at maximum the problems that may someone thing the game isn't fair


anyway this could even be useful as a game strategy, even considering that players can see pending moves, because who follow pending moves should consider those constrain to perform a counter move, so more thinking and more chance to do something wrong

about your questions, don't stop just considering during a destroy action, but even on a positioning move: knowing exactly that you'll be at a point in a precise moment (if we can enforce the second suggestion of "execute this move at block nnnn") help in doing strategies and coordinate your players

Quote
If (your improved idea) the player can select when to destruct, will it help at all because everyone can see it? also what happens if he destructs while moving to a destruct so does 2 destructs in a row, we'd need to consider that but no biggy.

I didn't consideret this scenario (set destruct at the end of a path) but i think that it shouldn't do double destruction but just update it's move like it's doing now, so cancelling the previous path
I don't know if I explained me properly, anyway what i wrote in bold why i think this is important (more than the gameplay aspect per se)

Random events are ok, if they are provably fair (like events that trigger because of random blockchain generated numbers like the one you use to chose where to drop coins) and we could use those random events to cancel a destruct (like "oh, your is jammed and you can't attack for 3 blocks" or "you fall on your knee because of an hidden rock and you can't move for 2 blocks") but not events that are hardware/software dependant like bad connections or malicious software

P.S.
i think that the two random events of jammed weapon/stuck player could even help on the deadlock/stalemate problem (togheter with the old ammo/armor system though)
Alternative GUI client for Huntercoin http://www.mithrilman.com
HUC donation: HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE
BTC donation: 1DKLf1QKAZ5njucq37pZhMRG67qXDP3vPC

domob

  • Developer
  • Sr. Member
  • *****
  • Posts: 285
    • View Profile
Re: simple change proposal
« Reply #3 on: March 24, 2016, 01:53:13 PM »
I've not thought through the game mechanics, just a tiny technical comment:  Introducing such a change could potentially be a softfork rather than hardfork, although it probably depends on how the max height is encoded.  It doesn't really matter for Huntercoin, anyway.  Also, this is of course very similar to Bitcoin's nLockTime, although with "opposite sign".
Use your Namecoin-ID as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | HBkxA5QmYSATFoPN1wFk8eBkgwPpY97Mfu

sirwagginston

  • Newbie
  • *
  • Posts: 48
    • View Profile
Re: simple change proposal
« Reply #4 on: March 28, 2016, 03:37:47 AM »
The idea of scheduling your destruct sounded good to me until I realized that everyone would be able to see when you plan to do it by checking the blockchain. I think a fancy solution for that may exist, and that it should be an option, but it's better to focus on the basic problem, which is that Huntercoin is still too slow and buggy. People need to be able to execute moves and attacks in the very next block, or else we force players to think about how the blockchain works instead of just focusing on the game.
« Last Edit: March 28, 2016, 03:54:20 AM by sirwagginston »

wiggi

  • Global Moderator
  • Full Member
  • *****
  • Posts: 150
    • View Profile
Re: simple change proposal
« Reply #5 on: March 29, 2016, 12:43:21 PM »
The idea of scheduling your destruct sounded good to me until I realized that everyone would be able to see when you plan to do it by checking the blockchain.

The negative locktime would be optional, players would only use it when they think advantages outweight the "visible to everyone".
More options for tactical tricks are generally a good thing.

But currently if hunters disengage with next block
Code: [Select]
  <----G
        B---->
they will usually not send destruct. Everyone will/must try when it can be made to only confirm with next block or not at all.


If tx cannot confirm after a specified block height, the coin becomes also a bit smarter, more like Nxt or Bitshares.
and it would be even better if additionally the tx can only confirm if current best block didn't get reorged.

I'm not sure if existing variables could be used for this, but if implemented like
- it's "negative locktime" -- 1 bit
- look back 1, 2, 3 or 4 blocks -- 2 bit
- check if last N bits of block hash match our last N bits (or tx cannot confirm)
then N=29 is "no one would notice but not cryptographically secure". Perhaps the 100 byte "tag" string can be put to good use.


sirwagginston

  • Newbie
  • *
  • Posts: 48
    • View Profile
Re: simple change proposal
« Reply #6 on: March 30, 2016, 01:08:21 AM »
Oh, auto-cancelling a move (optionally) if it fails to process in the very next block is a great idea, actually. I was thinking more about his idea for telling a Hunter to destruct in the future after a specified number of blocks

wiggi

  • Global Moderator
  • Full Member
  • *****
  • Posts: 150
    • View Profile
Re: simple change proposal
« Reply #7 on: March 30, 2016, 11:00:32 PM »
Oh, auto-cancelling a move (optionally) if it fails to process in the very next block is a great idea, actually. I was thinking more about his idea for telling a Hunter to destruct in the future after a specified number of blocks

Postponing confirmation like that is what regular locktime does.

nLockTime and IsFinal look like this is fully functional. ( ! tx.IsFinal()) is reason to not include tx in block, or to reject a block)

this is the minimum block height, auto-cancelling would be fancy word for maximum block height :)