[ANN][HUC] Huntercoin - Worlds First Decentralized Game/World on the Blockchain

[MithrilMan]

I'm almost ready to release my client updated version, meanwhile i'm doing some experiment with Vector graphics using Inkscape, to see if I can create a custom graphics to use on Huntercoin Mithril Edition and I've to say that even if I'm not an artist at all, I'm quite happy about the result and my workflow, her a WIP screenshot just shot, I've a loooot to do, anyway the new graphics wasn't supposed to be on my upcoming version, but anyway I'll pursue my idea of a graphics revamp (this way i can keep learning, this time on the artistic side)



about the upcoming version, I've some cool things to show you maybe on video, regarding some experiment to extend the standard gameplay (and involve my server, so this will be a centralized extension of course, because doesn't reside on blockchain but will impact the game of whoever use my client)
I'll explain the idea in a post maybe tomorrow, meanwhile I'm going to end the Automatic Behaviour I've named "Scary" that when applied to a hunter will try to save him if enemy approach, or at least... will try to persuade them to not attack ( will explain later )

[MithrilMan]

just to give an idea about the work needed to revamp the graphics, this is the tileset i'm currently using (original graphics)




So the minimum effort to have the same map with a custom graphics (so without actually improving the map design, that is something i'd like to do) is re-drawing all these tiles (actually 251 tiles)

today,  in a full day i've done about 10 (+ 9 reusable contours), so wouldn't be a breeze!

[The Bitcoin Co-op]

Why'd you end the "scary" behavior? Wasn't that one good for when you suddenly can't pay attention for some IRL reason?

[MithrilMan]

Why'd you end the "scary" behavior? Wasn't that one good for when you suddenly can't pay attention for some IRL reason?

I've been misunderstood, i wanted to say that i I almost finished it, then I'll test it and then release the new client version, probably next weekend

[-zibrac-]

Where can I find the Mac download?

[snailbrain]

Where can I find the Mac download?

looks like we need to get "maxpower" to compile the last version for mac..

[snailbrain]

Where can I find the Mac download?

Try this, compiled by maxpower.

I don't have a working mac so i can't test

https://mega.nz/#!JM0WgDDR!AlMaXOvsj4qcZWPZFHlA0FmzIrVSY2T2AMr-SaToENE

[wiggi]

I've some cool things to show you maybe on video, regarding some experiment to extend the standard gameplay (and involve my server, so this will be a centralized extension of course, because doesn't reside on blockchain but will impact the game of whoever use my client)

We should band together to extend the standard gameplay, at least in the cases that can be done in a decentralized way. Huntercoin network is pretty good as "server", storing data in decentralized way (the game state) and doing almost arbitrary calculations with it (would be interesting to compare to ethereum, what use cases exist that are possible for one, but impossible for the other).

[The Bitcoin Co-op]

We need to pack more gameplay updates into the core protocol before branching off with essentially different games and rules on different clients.

[wiggi]

We need to pack more gameplay updates into the core protocol before branching off with essentially different games and rules on different clients.

Coordinating this will be a challenge. Perhaps a formal motion/voting system would help, if it gives coin holders the ability to choose
between different gameplay updates or even commission one, and of course the right to veto unwanted changes.

and it shouldn't discourage gameplay updates for different clients. Easier to pack things that exist than vapor, so...


new binary release for betterQt client
(a bit ahead of github concerning the Windows stability bug (I give it 20% chance of being killed for good)
https://mega.nz/#!OdthBC7S!8pptEB7jxdmCp_DVN-Jo6ezq9hKE5J-gDECmrY9gxjE

The inventory/alternative outfits seem to work as intended, and this is of course a fine example of having the network host data and data processing.




If an items is aquired it is stored with the reward address (or, if none exists, the player address),
and items are "equiped" as long as both addresses are the same, and otherwise stored away (if the hunter already owns a storage or the item can create one) or lost forever if not.

This should be done less complicated and more ergonomic, and here is a problem: sending data to the Huntercoin network is too limited.
The waypoints are designed only for walking around (they're integers, but limited to 0-501, no "escape" value that would allow the hunter to *not* start walking).
Then the chat message, good, but will spam the chat window, and finally the reward address. It would be cool if we had something that is not just a hack but future proof and designed with the purpose of inputting general information.

[The Bitcoin Co-op]

I agree that you should work on gameplay features, but it's hard for you to do when you're required not to mess up the shared gamestate. You can't interfere with other clients. I think HUC-based voting is the best way to decide gameplay changes.

First we need the game to be more robust, though, like with the Huntercore update. Then it'll be able to handle more information without hiccups. We need more miners and nodes, too

[MithrilMan]

I've some cool things to show you maybe on video, regarding some experiment to extend the standard gameplay (and involve my server, so this will be a centralized extension of course, because doesn't reside on blockchain but will impact the game of whoever use my client)

We should band together to extend the standard gameplay, at least in the cases that can be done in a decentralized way. Huntercoin network is pretty good as "server", storing data in decentralized way (the game state) and doing almost arbitrary calculations with it (would be interesting to compare to ethereum, what use cases exist that are possible for one, but impossible for the other).

The feature i was talking about is centralized because relay on my server to exchange information (think it as a game server) so i find hard to share someway
At the same time i find hard to share the same implementation you have done about graphics improvement, or worse, your auction gem system because it relays on custom implementations.
Ok, we can share implementation details and whatever, but if people running my client use a different daemon (i built my client upon huntercoind.exe RPCs) then i can't have a custom game.data like you

this is why when you say

Coordinating this will be a challenge. Perhaps a formal motion/voting system would help, if it gives coin holders the ability to choose
between different gameplay updates or even commission one, and of course the right to veto unwanted changes.

I agree with you, but the problem is not a voting system (well, not totally true because in the past this problem arises when me and snailbrain had different views, so ok, a voting system is fine), that's not the main problem, because the problem is anyway the manpower on the core side of the development

So ok, a voting system would be useful, but it isn't the solution to the problem, we need to find motivated devs to help domob and then we need a way, beside voting system, to chose the implementation method maybe.

About your gem system/inventory, without a way to have a full consensus it would be not so useful because its usage is limited to your client (e.g. if on your client a user has a sword but my client doen't have such information into the game.data, even if we share both same graphics assets, it would lose appeal)

Like my idea of having ingame contests, even if in that case i could handle it on multiple servers because it just need for hunters to subscribe (pay a sum at a specific address), but the game node should have an auto-payout feature rather than relay on my closed server side payout

We need to enhance how extended game data can be included in blockchain and think about how to extend the game without having to hard fork... and i think that having a touring complete scripting engine into the cryptocoin would be the perfect choice (ethereum like?)

but huntercoin forked namecoin that forked bitcoin, so we are limited actually on that side, and I don't know how much would cost implementing that on current codebase, would be cool...

[wiggi]

cool. is that 3D ?

It's 2D tiles even if it looks 3D and visually several things on top of each other are often optimized to only 1 tile. When Qt is upped to an open-gl supporting version it should be possible to have mountains on a much larger map and zoom out to a realistic looking satellite view, just so with no tricks no LOD and no popping.

how soon we can use the better Qt, i mean the light one. 800M wallet.

As long as it will just trust the data of your wallet and doesn't force full blockchain dl (not just the 800M) on rescan, it's ok to use.

[wiggi]

The feature i was talking about is centralized because relay on my server to exchange information (think it as a game server) so i find hard to share someway
At the same time i find hard to share the same implementation you have done about graphics improvement, or worse, your auction gem system because it relays on custom implementations.
Ok, we can share implementation details and whatever, but if people running my client use a different daemon (i built my client upon huntercoind.exe RPCs) then i can't have a custom game.data like you

A small step that is useful right away, could go like this:
- use the same list of "player sprites", if mithril edition gets a new monster, betterQt would load this too, and vice versa
- a daemon (with 2 patches applied) determines a list of important things to display (just "indicative, client side" like the gem spawnpoint in betterQt safemode),
  this can be polled using RPCs or compiled into Qt and displayed in both clients

Any new game element would be designed with this in mind, e.g. 1 of the 2 patches must be able to determine the coordinates of a NPC that will then do complicated things in one client but visually (sprite index, coor, dir, and what it has to say like "5 gems for the ugly head of this annoying hunter") would appear in both.

In this example, players can also do the "quest" with any client, and the reward is kept safe for them. This happens implicitly, without any additional programming, if all input is normal Huntercoin moves and gamestate does all data processing.


Would you need a closed server only for payout?

[MithrilMan]

The feature i was talking about is centralized because relay on my server to exchange information (think it as a game server) so i find hard to share someway
At the same time i find hard to share the same implementation you have done about graphics improvement, or worse, your auction gem system because it relays on custom implementations.
Ok, we can share implementation details and whatever, but if people running my client use a different daemon (i built my client upon huntercoind.exe RPCs) then i can't have a custom game.data like you

A small step that is useful right away, could go like this:
- use the same list of "player sprites", if mithril edition gets a new monster, betterQt would load this too, and vice versa
- a daemon (with 2 patches applied) determines a list of important things to display (just "indicative, client side" like the gem spawnpoint in betterQt safemode),
  this can be polled using RPCs or compiled into Qt and displayed in both clients

Any new game element would be designed with this in mind, e.g. 1 of the 2 patches must be able to determine the coordinates of a NPC that will then do complicated things in one client but visually (sprite index, coor, dir, and what it has to say like "5 gems for the ugly head of this annoying hunter") would appear in both.

In this example, players can also do the "quest" with any client, and the reward is kept safe for them. This happens implicitly, without any additional programming, if all input is normal Huntercoin moves and gamestate does all data processing.

Would you need a closed server only for payout?

we could set the rules we want, and if we follow the same implementation it would work but only if we both are running the same "patched daemon", this is the problem
not having consesus rules processing data, you can't be sure that things will work

e.g (may be inaccurate because i don't know exactly how your gem implementation works):
if you spawn a gem on your patched daemon/client, and someone that have not a patched daemon walk over, your daemon would assign it to that hunter while the daemon that the player is running, that isn't patched, don't know about gems and ignore it

so you have an inconsistence here

Even if your implementation depend on transaction generated by the patched, and when one of the managed hunters (hunters in the wallet of the running daemon) step over the gem you generate it to communicate to every patched daemon that you own it, what happens if 2 or more different hunters step on that cell at the same time?

The point is that if you don't have consensus rule that sculpt actions result on stone (blockchain) you can run in problems where different "patched clients" aren't compatible each other, thus generating inconsistency and gameplay bugs

This is why a turing complete scripting engine would fit well


My ideal solution
My ideal solution would be to have scripting implemented in daemon and validated each block, where every script processes hunters positions/actions and affect game.data in a dynamic but predictable way (so provably fair results) and in order to "approve" those game script, a voting system would allow a script to be running

e.g.
Imagine i want to create a script that every block it spawn a random gem with a random value like you do:
1 - I'd create a script that every block uses a random number (like the one used by disaster) to chose the dropping tile, and set that info into the gamestate, and every time a hunter steps over the cell, the gem is assigned to his address (or if more hunters are there, with the same random number you chose the winner). The script creator set the Activation Delay parameter that will be used once the script is approved (see below)

2 - I send this script to the blockchain with a special transaction (Script transaction)

3 - This script now is open to be voted, and the vote could be expressed sending some amount of money to the script address (could be a nice way to incentivate game improvement in a decentralized way) or maybe thre should be some form of control that need that some invested "game masters" approve it

4 - Once the feature is approved, it will be active, starting from current approvation block, after the Activation Delay amount of blocks to be decided (so clients developer could have time to implement the needed addiction to the game)

This way, WITHOUT requiring hard forks, we could have an expandable game. It sounds cool to me

[Vaccomondus]

how many coins can be done per day on average?

[The Bitcoin Co-op]

how many coins can be done per day on average?

Done how? You mean earned by playing the game? ("Human mining")

[The Bitcoin Co-op]

My ideal solution would be to have scripting implemented in daemon and validated each block, where every script processes hunters positions/actions and affect game.data in a dynamic but predictable way (so provably fair results) and in order to "approve" those game script, a voting system would allow a script to be running

e.g.
Imagine i want to create a script that every block it spawn a random gem with a random value like you do:
1 - I'd create a script that every block uses a random number (like the one used by disaster) to chose the dropping tile, and set that info into the gamestate, and every time a hunter steps over the cell, the gem is assigned to his address (or if more hunters are there, with the same random number you chose the winner). The script creator set the Activation Delay parameter that will be used once the script is approved (see below)

2 - I send this script to the blockchain with a special transaction (Script transaction)

3 - This script now is open to be voted, and the vote could be expressed sending some amount of money to the script address (could be a nice way to incentivate game improvement in a decentralized way) or maybe thre should be some form of control that need that some invested "game masters" approve it

4 - Once the feature is approved, it will be active, starting from current approvation block, after the Activation Delay amount of blocks to be decided (so clients developer could have time to implement the needed addiction to the game)

This way, WITHOUT requiring hard forks, we could have an expandable game. It sounds cool to me

That sounds like a great solution! I think voting should be done vis micro transactions, though, so people don't have to pay to vote. We could weight votes by the amount of HUC held by the sending address for longer than XYZ days.

[snailbrain]

It's been so long since this question has been asked,  i've almost forgotten...

as far as i remember:

10 coins are generated per block.

1 by hardware mining
9 put onto the map (actually 8.75, 0.25 coins go to whomever has the crown of fortune, but sometimes it may be on the ground - in which case it goes to the gamefund afair)

1440 mins in a day

14400 coins generated a day (until halving)

from the game you could get about 13k if you dominated and had full control.

That's not including PvP (of which you might win or lose some).
I generally log in and create 10 hunters and hope to catch people by surprise.. i can normally make 1 or 2k coins from a few of hours of play (while working) (sometimes more).
That being said, the combat mechanics need fixing as it's too predictable - although, humans do tend to find ways of making what seems simple stalemate combat into almost complex chess when using multiple hunters (with more or against more).

edit:

regarding las tpost by mm and bitcoin co-op

i may have misunderstood some -but you could jsut do this now, that's what wiggi has shown?

and without any script stuff or changing anything. as long as you get people to use your own calculated gamestate (like wiggis gem client) you could have all the information you need.

every player has an address, and each player in time can have their address shown using name_history (in case someone else creates a toon with the same name)

maybe i'm not understanding completely though ..

[snailbrain]

there is 731k coins in the gamefund atm..

(this is an inaccessible sum of coins which is to be used in future updates, such as NPC loot or crown of fortune)