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

sirwagginston

  • Newbie
  • *
  • Posts: 48
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #15 on: September 18, 2016, 10:31:27 AM »
Well, if it's that easy to do, OK... I didn't realize it could do so many things. I thought it was just a list of names and who owns them, like Namecoin. I can kind of imagine how we could put a map on it, like inserting an array of values corresponding to terrain features, not sure, but how would it enable alternative rulesets?

I think I need to understand how the code works better. I'm curious to see how the discussion continues when wiggi gets back from whatever it is he does. I also asked him some questions on bitcointalk

wiggi

  • Global Moderator
  • Full Member
  • *****
  • Posts: 150
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #16 on: September 18, 2016, 04:22:45 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)


Good point, this could be a can of worms.

I'd like to give newly spawned hunters a timed protection, so they can't get destructed for 3 blocks, or until they send destruct themselves if this comes earlier.

Implementation-wise, this would use up 2 more "color" bitflags.


wiggi

  • Global Moderator
  • Full Member
  • *****
  • Posts: 150
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #17 on: September 18, 2016, 04:43:03 PM »
are you sure that the color is still useful?

I think yes, it's very useful.

For example, even if the map is crowded with 2 or 3 hunters per harvest area, it will be possible to avoid fights against groups that have more than 1 hostile colored hunter.

It's also possible to select the colors of your hunters strategically depending on the hunters already on the map, to either avoid fighting if possible, or not.

Or spawn only one color and try to get some groups of 2 or 3 equally colored hunters on some harvest areas, and despawn all remaining singles without a fight.


wiggi

  • Global Moderator
  • Full Member
  • *****
  • Posts: 150
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #18 on: September 18, 2016, 05:06:06 PM »
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).

But doesn't this also mean, until the alternate world/reality is actually created, they are dead everywhere.

And if many alternate worlds are created, can they be alive in all of them (in the main game too, and buy assets like the proto CKC token) or only in 1?


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

Yes, if it's easy to do, we should do both.


Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1001
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #19 on: September 18, 2016, 06:23:12 PM »
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).

But doesn't this also mean, until the alternate world/reality is actually created, they are dead everywhere.

And if many alternate worlds are created, can they be alive in all of them (in the main game too, and buy assets like the proto CKC token) or only in 1?

yeh they are just names.. they are just dormant.
probably in alternate game worlds, to enter, you must set the value of your name to something like this to enter MMs game world - {game:"mmworld",colour:"2",class:"5",begin:"1"}
in reality, doesn't matter what they put, it all depends on the game(state) creator wants to recognise from json.
They could enter none or multiple worlds. and play in multiple world/games at the same time with one account/name. The game(state) they are taking part in would require a {game:"<gamename>"} so it can process the new gamestate.
It also might be that some game(states) don't allow the same name twice to "begin"/"enter" the world.. so if they die in that gamestate they cannot re-enter (with that name, which is unique).. i.e. dead is dead. or maybe not. whatever their rules say goes..

you could use op-return for this too i think, but i don't think it's as flexible or as easy for newbies? - i think Michael Gronger  (don't know how you spell it atm) from Kraken mentioned about using this for huntercoin before release[in bitcoin] (during convos about namecoin/chronokings when namecoin had a critical flaw which he had spotted) also they are 10mins block times.

Some things to consider -
probably name tx fees would have to be significant (as in, not 0.0000001, but something like 0.05 hucs), to reduce spam.
a Lite client would need to have fully synced from the time the game started in the huntercoin blockchain, then i guess it could be pruned along with huntercore, as long as the "virtual" utxo set is recorded? something like that... the alternate gamestate  needs to record how many alt-coins everyone has as well as the game? (like huntercoin does before they are taken to a bank)

might be some flaws to it but i don't think much harm can come of it..


« Last Edit: September 18, 2016, 07:13:28 PM by Snailbrain »

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1001
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #20 on: September 19, 2016, 03:38:15 PM »
I thought it was just a list of names and who owns them, like Namecoin. I can kind of imagine how we could put a map on it, like inserting an array of values corresponding to terrain features, not sure, but how would it enable alternative rulesets?
bitcointalk

that's all huntercoin is really - just a load of names that have values assigned to them, and those values can be changed each block (ish).
the alternate ruleset is what someone external wants to make, they can do what they want. we don't need to worry about a map or terrain with regards to huntercoin. all huntercoin needs to do is allow standard names in the chain.

in huntercoin you start by doing something like this :

make a name called snailbrain with some values attached to it - colour (& reward address maybe)
it's just a command you issue to the daemon like this (probably not exaclt ylike this :d)

Code: [Select]
name_register snailbrain {color:1}
this does a cryptotransaction (called a name transaction) that spends the coins required, makes a name in the blockchain called snailbrain with it's value (color=1).

and that is all, nothing special happened.

but - the huntercoin gamestate reads this and you spawn in the virutal world (when your tx goes into the next block and the gamestate randomly calculates where you will appear on the map).
You can then change the value of your name and only you can because you have the private key.

So you may issue another command to the daemon/wallet

Code: [Select]
name_update snailbrain {wp:123,4}
wp = waypoint. you have now signed a tx to move your hunter, and it can't have been faked because only you have the private key.. i.e. uncheatable/hackable (today).

when the tx goes in the chain, everyone's client/node calculates where everyone is on the map and where they are heading to... everyone's gamestate is identical.

up until this point, there isn't really any different to namecoin at all, the gamestate could be done on pen and paper or in a seperate program using namecoin... what makes huntercoin different is hucs can be minted by the gamestate events, and you hunter (names) can die and render your hunter (name) dead/expired. where as namecoin names just expire over time if you do not renew them (like i've just done recently -- i forgot :( )

Now, imagine that when you are moving around the map in huntercoin and your hunter has 100 hucs on him - if you land on a bank, those coins are minted into the users wallet and can be spent on exchanges etc...

but - those hucs could be peanuts, or gold bars, or condoms, or spliffs... or wiggi's gems... AND we don't need to take them outside of the gamestate for them to have value and be secure. They are just as secure as coins in your normal wallet, even though they are sort of virtual, virtual coins...


so - all you need for another world/coins is another gamestate, and you don't need to interfere with the huntercoin world/gamestate as long as you are not wanting to mint huntercoins.
everything is still crypto-secure.

you can just make up a new coin, like snailcoin.

all you are using huntercoin for is for the secure key/value, -  you still need to use/spend hucs to create a name and move etc (otherwise would get spammed..)
 in an alternate world you can just transfer altcoins within the new/alt game state by doing something like this -

Code: [Select]
name_update snailbrain {world:"snailworld",transfer:"wiggi 500 goldust"}
whatever the gamestate creator wants to read -
would be better if you could add the modules/gamestate rules to the huntercoin client, so you can see and manipulate your balance like normal and also make it easier for exchanges maybe.. that can wait though.
« Last Edit: September 19, 2016, 03:47:18 PM by Snailbrain »

wiggi

  • Global Moderator
  • Full Member
  • *****
  • Posts: 150
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #21 on: September 19, 2016, 08:25:29 PM »

Some things to consider -
probably name tx fees would have to be significant (as in, not 0.0000001, but something like 0.05 hucs), to reduce spam.

The current tx fee level (both name tx and normal coin send) of 0.01 to 0.02 huc is a bit on the low side. It wouldn't really deter
someone from filling all blocks to the max for an entire month or two.

Tx fees could be 10 times higher than now, but it was always that way and if it ain't broke...

The new "normal names", if allowed, should use the same fees calculation as all other tx.


Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1001
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #22 on: September 19, 2016, 09:18:41 PM »

Some things to consider -
probably name tx fees would have to be significant (as in, not 0.0000001, but something like 0.05 hucs), to reduce spam.

The current tx fee level (both name tx and normal coin send) of 0.01 to 0.02 huc is a bit on the low side. It wouldn't really deter
someone from filling all blocks to the max for an entire month or two.

Tx fees could be 10 times higher than now, but it was always that way and if it ain't broke...

The new "normal names", if allowed, should use the same fees calculation as all other tx.

yeh i agree for now, wil also probably save coding time.
we can do an update later if needed.

off topic - does anyone know who is mining now...

sirwagginston

  • Newbie
  • *
  • Posts: 48
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #23 on: September 20, 2016, 09:26:49 AM »
I recommend keeping the transaction fees low because the price of HUC will go up. We should be more worried about deciding a new fee structure for Hunter  creation, destruct, etc... as someone just pointed out in our bitcointalk thread, it's prohibitively expensive, now.

We also need to decide if we're doing both the color thing and the standard names thing, or just the standard names thing. Also, let's talk about reinforcements, which was the idea that one could pay a fee to have one Hunter teleport to the same tile as another Hunter. It would alleviate many common criticisms of Huntercoin's gameplay, particularly the logout time.

Mithril Man

  • Hero Member
  • *****
  • Posts: 589
    • View Profile
    • Mithril Man Web!
Re: Gameplay change (hard fork) wish list
« Reply #24 on: September 20, 2016, 03:12:14 PM »
I am for low fees, since the project release because of distribution, this is known. Of course there is the technical problem of the number of transactions generated if players number rises up but this is pruning job to reduce the needed transactions stored on local pc to let players play

I agree then that the cost must be reduced a lot, and we should really decide the new fee structure asap because is more than a year that we are stuck on the matter and now that price rises, staying in the limbo without changing stuffs would be a big error , we have to follow the momentum.

I want to talk now about something to consider about the changes of the name/value namecoin style:

Currently, if I'm not wrong on this (please tell), the huntercoin daemon validates all incoming transactions and if some name transaction isn't valid, the offending transactions aren't included in the blockchain.
If we introduce the open name, we can't validate properly each transaction, excluding the offending one, because the standard daemon doesn't know if a name transaction is standard or custom, this lead to the problem that we could include a lot of invalid transactions, causing more troubles than pros.

As i said in the past, a real "open framework" should have a turing complete scripting system that allow to insert validation rules for each custom world so that ANY node could validate each other nodes, just by running the custom transaction ruleset.

Now, currently this is a missing huntercoin feature.

So, first thing to consider is: did we want to remove all validation, so that every name transaction is included in the blockchain?
This isn't a big problem about gamestate, because the daemon would anyway validate a transaction and consider it to change the gamestate (if valid) or skip it, but as a "game framework" this isn't enough and moreover the blockchain would include junk data.


I think that we must at least introduce some basic validation that involve the "game world" (game world could mean an alternative map or a completly new game):
every name_register/name_update should have a JSON property that remind to the ruleset it's subject to, so that every node running a custom game, could just skip it, or try to validate to compute its game_state (this would speed up validation times of course)

I would even introduce some special names registration, that allows to register a ruleset (this way we are even open to further validation automation in future), something like

NAME_NEW_RULESET (and NAME_UPDATE_RULESET using the same NAME_NEW_RULESET address)
that accepts a json like this:

simplest form (just register the ruleset name)
Code: [Select]
{ ruleset: 'MyRulesetName' }
advanced form (register the ruleset name and all the expected values in the name_update/name_register transactions)
Code: [Select]
{
   ruleset: 'MyRulesetName' ,
   name_register: {
      name: '*string:min=1;max=10',
      color: '*int:min=1:max=4',
      class: '*enum:warrior|mage|thief'
   },
   name_update: {
      characterName: 'string',
      moveTo: 'int[]',
      attack: 'bool',
      useItem: 'ulong',
      specialAction: 'string',
      logout: 'int:min=5;max=10',
      ensureExecution: 'long:min=-1'
   }
}

in the example above, i declare some simple rules (remember, we don't have turing complete language so we have lot of limits) in the form of JSON, that helps automatic validation on some transaction and act even as a manifest to show which features my custom rulesets expose

In the example, i'm stating that my custom ruleset "MyRulesetName" need, during name_register, 3 parameters: (note that * rapresents a mandatory field)
- name: a mandatory string (min 1 char, max 10) (could even add a regex expression to validate names) that rapresent the character name
- color: a mandatory int within a range (min 1 max 4)
- class: a mandatory string that rapresents the class of the character in the form of enum, so we can validate and prevent someone sending a transation with a class like "archer"

while the name_update allows:
- characterName: the character name to move, etc... (currently in huntercoin the sending address is linked to the controlled hunter, but in my custom game I could imagine that a player uses maybe name_register to register an account and then create characters using name_update (so i can implement easily the account concept)
- moveTo: an array of int (rapresents current specified waypoints format)
- attack: a bool that when true means to attack (this could be a  more complex parameter, like a string that rapresents the attack type, or even a subJSON with other parameters like

Code: [Select]
...
attack: {
   weapon: 'sword',
   ability: 'int',
   target: 'string'
}
...
where
- weapon is the name of an equipped weapon (of course custom game validation is required and standard nodes just can validate that's a string)
- ability is the id of a class ability (again, custom game validation), like 2 = "backstab", 5 = "cut throat", etc...)
- target allow you to select a target of the attack (now we don't have this feature because our hunters attack in a squared range, but in a custom game you could chose which character attack, even at some distance)


continuing on name_update allowed properties:
- useItem is the Id of an item in the character inventory (custom game validation, standard nodes can validate it's an unsigned long)
- specialAction a special (custom game validated) action to perform, maybe non character relevant.
- logout is the logout command that says to remove character from the game between 5 and max 10 (rapresents blocks)
- ensureExecution is a long that rapresent the block we need the attack to be performed. if -1 this means no restriction, otherwise the value is the block height we expect this action to be executed or, otherwise, the transaction get ignored



this is just a rude example about ruleset definition, but what is important is that I can register my ruleset (and even NAME_UPDATE_RULESET !!!) so that ANYONE using huntercoin, knows that a ruleset exists with the name of 'MyRulesetName'.

now, everytime my custom game will send a name_register or name_update, it need to specify AT LEAST the ruleset name (and all the parameters i defined in my ruleset, if advanced ruleset is defined and supported by our changes, but as first step just the NAME_NEW_RULESET is enough and open to further enhancments)

something like (even on standard huntercoin game)
name_update {
   ruleset: 'MyRulesetName',
   name: 'myHero',
   moveTo: [1003, 1055]
}

to move my hunter in my custom world rapresented by MyRulesetName, to coordinate 1003, 1055 (that aren't valid on our standard map) and every custom huntercoin daemon can just skip this transaction validation if the ruleset isn't its own!




I need to take some time to realaborate other aspects but i'm busy at work, will write later (this took me some hours to end this post lol)
(about pruning, ruleset should at least communicate which transaction can be considered pruneable at a given time, otherwise custom games couldn't be pruned by standard huntercoin core)
« Last Edit: September 20, 2016, 03:16:52 PM by Mithril Man »
Alternative GUI client for Huntercoin http://www.mithrilman.com
HUC donation: HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE
BTC donation: 1DKLf1QKAZ5njucq37pZhMRG67qXDP3vPC

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1001
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #25 on: September 20, 2016, 05:13:01 PM »
don't have time just yet to read all of it but this bit so far :

Quote
Currently, if I'm not wrong on this (please tell), the huntercoin daemon validates all incoming transactions and if some name transaction isn't valid, the offending transactions aren't included in the blockchain.
If we introduce the open name, we can't validate properly each transaction, excluding the offending one, because the standard daemon doesn't know if a name transaction is standard or custom, this lead to the problem that we could include a lot of invalid transactions, causing more troubles than pros.

every transaction is validated or it won't go in the blockchain, but if for example they do a move that is not recognised in the alternate_gamestate, or invalid move, it will just be invalid in that gamestate.

if someone does invalid tx in a specific gamestate, but it's a valud nametx it will just cost them a fee for updating their name. they won't want to do them on purpose.

we won't be able to change huntercoin massively with the next hardfork, but we can do some small changes. apologies if you explain more in th enext parts, will try to read later

wiggi

  • Global Moderator
  • Full Member
  • *****
  • Posts: 150
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #26 on: September 20, 2016, 06:43:15 PM »
Perhaps an low level rule is possible, like: If the name value (which is just a string) starts with a specific char then it's a "normal name" and ignored for the Huntercoin game, so that the tx can't be invalid because of it.
Parsing it is then the problem of whoever want to use it, and they are free to use any format they like.


Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1001
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #27 on: September 20, 2016, 07:11:37 PM »
Perhaps an low level rule is possible, like: If the name value (which is just a string) starts with a specific char then it's a "normal name" and ignored for the Huntercoin game, so that the tx can't be invalid because of it.
Parsing it is then the problem of whoever want to use it, and they are free to use any format they like.

yeh this would be the way. but i think mm is concerned about nametx being junk [not needed], but i don't think they are (see below).


Quote
As i said in the past, a real "open framework" should have a turing complete scripting system that allow to insert validation rules for each custom world so that ANY node could validate each other nodes, just by running the custom transaction ruleset.

Now, currently this is a missing huntercoin feature.

do you mean every huntercoin node validates every gamestate?

Quote
So, first thing to consider is: did we want to remove all validation, so that every name transaction is included in the blockchain?
This isn't a big problem about gamestate, because the daemon would anyway validate a transaction and consider it to change the gamestate (if valid) or skip it, but as a "game framework" this isn't enough and moreover the blockchain would include junk data.

it's not really junk, it's the same junk as moves in huntercoin, they are all there too.
If we were to not include this in the blockchain then you wouldn't be able to verify alternate gamestates (or huntercoins gamestate if we removed huc nametx from blockchain)

Like wiggi said, regarding the ruleset thing, you could just start a name with a character.. e.g. in namecoin, people have agreed than names that start with d/ are domains. id/ is id.
doesn't matter that much how the external gamestate recognises it.

regarding the "turing complete", your external gamestate can be whatever you want, all your inputs are just the name tx. With those inputs you can do what you want in your own external gamestate. with added bonus of not having to do anything to huntercoin except allow the normal names/txs

regarding the json examples, yes just like that is how you would do it.
for pruning - as long as you have a snapshot at the point of pruning (like utxo + a gamestate, + all nametxs after it) you should be ok.
for perma prune from the blockchain (i mean, not saved in the blockchain at all to begin with), you'd only be able to ignore stuff which doesn't affect the gamestate, like chat.. as you would need validate the alt gamestate somehow.

« Last Edit: September 20, 2016, 08:19:17 PM by Snailbrain »

Mithril Man

  • Hero Member
  • *****
  • Posts: 589
    • View Profile
    • Mithril Man Web!
Re: Gameplay change (hard fork) wish list
« Reply #28 on: September 20, 2016, 11:42:41 PM »
Quote
As i said in the past, a real "open framework" should have a turing complete scripting system that allow to insert validation rules for each custom world so that ANY node could validate each other nodes, just by running the custom transaction ruleset.

Now, currently this is a missing huntercoin feature.

do you mean every huntercoin node validates every gamestate?

Turing completeness (https://en.wikipedia.org/wiki/Turing_completeness) and i quote "any function whose values can be computed by an algorithm can be computed by a Turing machine, and therefore that if any real-world computer can be simulated by a Turing machine"
now, we don't really need to go that further (Ethereum has it tho) but anyway to validate every custom transaction in any node, we need some custom language to specify the validation rules, and this way ANY huntercoin node can validate ANY transaction.

Imagine my example, in a scenario where huntercoin has a powerful scripting system, basically when i want to register a new game ruleset, I register the ruleset with all specifications like
- name validation
- allowed classes
- which action can be performed by a specific class
everything that's inputable in a name_update, should have a validation rule in the ruleset definition

this way, any transaction can be, at some extent, be validated.
I don't want to push too further saying that all the gamestate could be computed by any node, because it would cause too many computation effort (even if this would be ideal), so it's fine that the gamestate itself is computed by custom nodes that just decode the transaction that are relevant to their ruleset

this is why i'm against having just a name that start with d or X to say that that player uses other rules, because it's too much limited, while having an explicit "ruleset" field sounds more appropriated (and architecturally speaking is a lot "cleaner")
if you are worried about backward compatibility, lat say that if the name_update doesn't contain the ruleset property, it refers to standard protocol

About junk transactions, i were refering to invalid transaction (in the sense that were malformed for the ruleset, or invalid in their content) and that keep space in the blockchain without having value.

Think this way (and reply, because maybe i miss a bit here) what did happen now if i send a malformed transaction that contains invalid json in name_update?
Did i spend (waste) money and tx get added to the blockchain or did i get refunded and tx ignored?
In the past i remember that sending a malformed json caused the wallet to be corrupted (doh!) but what happen on the blockchain side?

fact: a malformed/invalid tx is sent

scenario 1: to prevent ddos/spamming, those txs are saved and fee deducted
result 1: we are filling the blockchain with junk data, causing a ddos to be at least a bit expensive

scenario 2: to save blockchain space, those txs are rejected
result 2: ddos/ing is cheap, but we save blockchain space

in scenario 2, the problem is that custom ruleset cannot be validated, so there isn't a way to say a tx is malformed/invalid, so all possible junks would be stored in blockchain (hope my though is clearer now)

of course if actually what happens is scenario 1, having "junks" is already possible, but the more the games, the more the possible junks
Alternative GUI client for Huntercoin http://www.mithrilman.com
HUC donation: HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE
BTC donation: 1DKLf1QKAZ5njucq37pZhMRG67qXDP3vPC

Murch

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: Gameplay change (hard fork) wish list
« Reply #29 on: September 21, 2016, 07:41:07 AM »
Hey guys. I've been reading through this thread. I don't have a strong programming background, but with my (limited) understanding I think I've picked up the following:

1. The blockchain can be made versatile by mimicking the namecoin system by bootstrapping nametx's to hunter creation (which are essentially the same thing in the first place). This would allow alternate rule sets (on the same game world layout?) accompanied by corresponding virtual rewards (not HUC).

2. There has been some discussion of fee changes to avoid bloat but nothing certain yet.

3. An important technical challenge preventing usability by the average user is how to functionally prune the blockchain.

Because I don't properly understand the code changes being discussed, I can't really comment on that. However, I do have some thoughts regarding the economics of Huntercoin. I might be off base with a lot of the following, partly because I can't find any up-to-date rules anywhere (in which case please just let me know that I have no idea what I'm saying).

I think that even if you were to solve the pruning problem right now, adoptability won't increase that much. The barrier to entry isn't that the blockchain is too big to run a full node, imo. At least for myself, I don't like downloading wallets and keeping coins in them. I have a greater chance of mishandling those as opposed to keeping them on an exchange. Think of me as your average, inexperienced, dumb user. I'd much rather sacrifice some security for ease of use. Something that would get me jumping in immediately would be a web client for the game hosted by one of you devs. Then setup time is only however long HUC transfer and confirmation takes. I'd definitely be willing to donate a bit to help make that happen.

Next, I'm not sure if it costs 200 HUC every time you summon a hunter, or if more cost less, but right now I see that as too high. For something that you can lose in one pop to an enemy destruct, I can't justify risking that much HUC just to try to learn the game. There has to be an accessible learning curve. Having the 5 HUC creation fee isn't as much of a problem as being able to lose 20 full blocks worth of coins at once. However, if the hunter cost were to be reduced to 20, then it might be too easy to dominate the board. Could this be balanced by reducing the max number of hunters at once? I'm thinking no since running other wallets is trivially easy. I'm not sure what the solution is, but I just can't see this scaling.

For more people to play, there needs to be a reasonably good chance of 'breaking even' per play session (there's a reason dice is so popular). This doesn't necessarily mean reducing the skill cap of the game, but rather modifying distribution somehow. Unfortunately, without being an expert at this game, I can't begin to suggest how that could be done.

From a game theory perspective, if the dominant strategy is to collude rather than to defect, then the game state will always stabilize as some sort of cartel sooner or later. Controlling this comes down to how incentives are set up.

Just want to say that I think you guys are definitely on the right track. Investing in a coin based on its idea is death. But I don't mind investing based on the devs. Right now this coin seems very much worth investing in on those grounds alone. Please continue to keep your dialogue this open. You have at least one fan haha. ;D