Topic: [ANN][HUC] Huntercoin - Worlds First Decentralized Game/World on the Blockchain - page 77. (Read 879724 times)

I was thinking we could have multiple gamestates on the Huntercoin blockchain. If we allowed different clients to mark transactions as theirs, the protocol could prevent them from interacting and allow them to occupy the same map tiles. The protocol would only apply logic such as combat to hunters with the same client header; it would just require nodes to store this extra data and miners to process the new transactions. Those who don't upgrade would be unaffected.

edit
just read some more and i think i understand.

i think your ideal solution was just an example (gems)..
if talking about gems or anything calculated by gamestate then you can just use modified client like wiggi. you can have a complete new currency in the gamestate if you want. as long as people are using your modified daemon you can add diamonds to the map and it doesnt matter if i dont have the client. same as wiģgis gems. as long as it's not affecting the mechanics of the original game.
if you mean game mechanics changes...maybe you are then will need consensus by all nodes
voting is difficult to do as the rich will always get what they want due to how most cryptos work. maybe if voting is expensive and the coins become part of the fund?

apologies for typos (in bed remotely)

no, you can't without node consensus and non-patched daemon would not have had features that patched daemon would have.
And the worst thing is that you can't even change game rules by script without hard forking. Scripts allow you to do anythink because nodes already have all they need to validate scripts and execute them.
I don't know if i explained me bad or what, but you can't even get close to what i mean actually

Well, we can't have people playing by conflicting rules in the same game world... otherwise I'd make a new ability for my (hypothetical) client that makes the rest of you super easy to kill.

UNLESS we have different clients create transactions with unique headers!!! Then they could ignore conflicting ones completely so they don't even appear to each other on the map

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)

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 ..

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.

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

how many coins can be done per day on average?

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

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?

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.



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.

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

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...

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

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.

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

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).

Try this, compiled by maxpower.

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

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

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

Where can I find the Mac download?