Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Mithril Man

Pages: [1] 2 3 4
Development / Player account and implications
« on: March 23, 2016, 01:13:51 AM »
for clarity sake and to not lose what i've wrote, i took the posts I did on BCT and put them here in a big one post
I fixed some typos too and rewrote something in a cleaner way, so please re-read in case you already did before


that's a good idea for accounts - some incentive to having an account.

we can add accounts in the original way the game was designed (multiple hunters under one name), of course disadvantage of that method is you cannot move other hunters when 1 is pending.

I think that, as you pointed out, the old way has a bad drawback that prevent you from coordinating your hunters in the proper way, and this even helps bots because it's less error prone than having to consider in few seconds which hunter to move or not, etc..., so account implementation shouldn't be done that way but should be thought in a new way.
And I think that the new way could be pretty easy: reserving a special name (AccountID) linking it to an address, and adding to it some attributes.

Let me introduce this concepts (Address bound Account):

An account can be created using a special transaction (e.g. game_createAccount) that create a special name into the game, that is saved in gamestate or better in a new .dat like accounts.dat that will contains the full list of active accounts
game_createaccount { address: 'HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE', name: 'My Account Rulez', badge: 'myIcon', note:'Hey Ya, I Rul3!' }

this method will return an AccountID that can never change and that rapresents the real account ID, even if player then change its name or transfer to another address (so this would be the real registered name if you consider this as in namecoin and this must be unique, while the account name could have duplicates maybe, not that important)

- address is the address bound to the account. This is where you have to send the money that will be spent to play. Every move/destruct/chatmessage/whatever game action that requires a fee, will take money from this address.

- name is the Account Name, that identify in a friendly way a player (the real ID is the returned AccountID as i said) and that could be used to show the account ladder positions, on game clients, realtime chat, etc... and that will let players to brag while climbing the ladder position!

- badge, note: an example of account extensibility, showing that we can add some fancy stuff linked to accounts, like an icon, a note, maybe a hunter skin, etc...

Should be possible to transfer an account to another address, so if a player wants to be safe can change periodically his base account address and we can even create an account market where people could build up a strong one and then sold it (@snail this should sounds familiar to you that have a MMORPG experience).
game_transferaccount { accountID: 'myUniqueAccountId', newaddress: 'HMAAABBB5wo9FiniVU4pXWGUu8E8PSmoHE' }

Should be possible to update account information, to allow a name change, icon change, etc...
game_updateaccount { accountID: 'myUniqueAccountId', name: 'My New Account Name', badge:'myNewIcon' }

With such Account, we can then just add a mandatory field when you create a hunter, so that you must specify which account the new hunter belong to (and underneath this would just cause the hunter creation cost being taken from the address account)

the hunter transfer should be changed in order to use account instead of address

Just with those small changes/addition, we have a full fledged account system that we can use then to do whatever we want with

And consider even other PROs like the fact that this way a centralized system would just require to handle a single address per player, so creating a kind of centralized server would be easier!

i don't know how to do it without punishing those without much coin to create multiple hunters... e.g. i thought that maybe the more hunters you have in account the less tax you get, but then someone who only wants to play 1 character (poor person) is getting stung, and it helps those who create many.

i proposed the opposite (rise the cost of every new created hunter while you have others already active/created) because this sounds to me the best way to prevent people from acting like now, covering the map with 30+ hunters on a single client

and if we take my example as real, so starting from 25 huc then doubling its cost every new hunter, or having a fixed part plus a variable part, comparing to current cost this would mean something like this summary

costs for creating hunters:
A - current active cost: 200 huc every hunter
B - proposed alternative of cost starting from 25 huc for the first, then doubling the cost for every new hunter
C - proposed second alternative of cost starting from a fix cost of 50 per hunter, plus 15 huc for the first, then doubling the variable part for every new hunter

Example of costs with different approach

Hunters created1234567

of course values can be tweakered but this is pretty clear we can do whatever we want, even changing costs based as, i said in another post, on current population (so if map is empty, cost could be higher to prevent the feastest after a disaster to fill the map with his hunters)

I think just need to know how players will have more power by creating more character [snip]

Why should they be more powerful with more hunters?
I didn't focused on the "powerful" aspect when i explained my ideas, but I was just considering two contradictory aspects:
- having just one or very few hunters is annoying because the game is slow and you could be far from action
- having too much hunters helps too much who can control a lot because of time and who runs bots

Considering those 2 aspect, I think that we should find a compromise and this is why i displayed an example of hunter costs, just to explain that with a well thought dynamic formula we can be near an optimal solution:
1) incentivating players to have more than a single hunter without investing too much, helping this way the newcomers and poor players, that may start trying to run a single or two hunters with lower risk, but even lower gain

2) "punishing" who runs too much hunters, by incrementing exponentially the cost of hunters in a way that running too much hunters will cause you to risk too much respect the possible gain, so lowering the ROI and thus limiting the "one player that rule the world" problem

(see below for a full explaination of the idea)

[..snip] and how that will outweigh just creating more "accounts"

ok now your question is about how to achieve what i want, here it is:

In order to prevent people from using multiple accounts to create, and so control, lot of hunters on the map, we need a way to reward more, in term of potential gain, the "high level" player than the "low level" one.
This is why i talked about Bounty Points (BP), that are points that you gain whenever you kill an enemy and you lose whenever someone kill one of your hunters.

The way you gain or lose BP, depends on your level and the level of the player who lost the fight, something similar to common PVP MMORPG that have a rank system.
If some low level player kill/hit you, you lose "a lot" in term of BP, while you gain a little if you kill/hit them, but you gain a lot if you kill/hit someone with an higher level than you, or similar, etc...
But why should one care about BP? Well, because there will be a permanent contest that daily/weekly/monthly etc... pay out a prize based on the ranking and that will be paid out from game funds coin pool (and that pool will have new ways to be refilled as you'll see).
We could even use the rank to give more powers (abilities) to hunters in future, but for the moment i'll keep it out to not put too many irons in the fire.

Another thing that could be useful to encourage the single account play style, is putting caps (limits) to the amount a hunter that belongs to a low level player could obtain from killing an enemy (and here i'm not talking about BT but about HUCs) and taxes in general (the lower you are, the more fees you pay when you cash out, more below)
This requires of course a rework about how pvp works, but this was already planned, and this is the core idea (and i link this even to the dynamic hunter cost but the rationale could apply even without that change):

The cost method is B (25 per huc, doubled for every new hunter you create)

Player A is an high level hunter and create 5 hunters to move them at the same time on the map.
1st hunter costs 25 (named A1)
2nd hunter costs 50 (named A2)
3nd hunter costs 100 (named A3)
4th hunter costs 200 (named A4)
5th hunter costs 400 (named A5)

Player B is a low level hunter and create 2 hunters to move them at the same time on the map.
1st hunter costs 25 (named B1)
2nd hunter costs 50 (named B2)

B2 reach out A3 and managed to hit him, what happens?
In terms of BP, Player B (note, not hunter B2 but Player B, so the Account) gain lot of BP because he managed to hit an high level player, while at the same time Player A lose the same amount.

What about Hunter value, so HUCs?
One of my ideas is considering the hunter value (so his initial value or the collected value if the hunter is a veteran) as Carry Capacity
Whenever a hunter kill another, the winner get, from the enemy, the amount he had during the attack, so in my example, since B2 is a 25HUC hunter, he would get 25 from A3

so fight result would be
- B2 became a 50HUC hunter
- A3 became a ... well here there are at least 2 options, A3 could become a 75HUC hunter (100-25) or just die and send the exceeded amount (75 huc) to gamefunds
this depend about how we manage to change the PVP, if we implement the armor/ammo system, then when someone is without armor and get hit, then he die and we can use hunter starting cost, to apply bonuses on equip (a 25HUC hunter has 1 armor, a 50HUC 2 armor, etc...)

Two things more to note:
- 1 - when Player B decide to bank the sum won by B", destructing him on a bank spot, giving the fact that he's low level, he won't get the full 50HUC gained but 50 - a fee that goes to game funds, as a "malus" for being low level. This is a nice way to encourage the single player account too.
- 2 -after player B killed his B2, if he create another hunter this will be again considered the 2nd (because there is still B1 on the map) and so it would cost again 50HUC

If you think deeply about the impact those changes have on gameplay, you should see (if i didn't missed something) that it's quite balanced.
- Account boost is discouraged because of Taxes impact on banked amount and BP penalities (and powers linked to the player level if we implement that in future)
- If someone wants to maximize BP gain and want to have a big army, he would risk losing a lot both in terms of BP (difficult to follow too much hunters) and HUC (the more you have, the more they cost and you risk that someone kill your 6400HUC hunter, maybe with a low level 25 hunter that would make him gain just 25 and gamefunds the remains)

Anyway i don't want to write a full game play now (even if i get close lol), but I think that there is already lot of stuff to think about and that can really give a huge boost to gameplay and fun!
Since i spent so much writing this posts, i think I'll implement those stuffs anyway in my client somehow in a standalone fork lol

Development / 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?

Technical / Support / crown holder question
« on: August 11, 2015, 09:53:25 AM »
I played a bit yesterday and i picked up the crown, then i faced some enemies and tried to kill them, but i lost the fight (luckily i was big, 800huc, so lost just 1 "life" and successfully banked the crown later)

I encountered some afk during the way, and tried to kill them, but my destruct was a failure, this is what rised a bell ring in my head and i went to check the source on github to find out that (correct me if i'm wrong) crownholder can't attack, his attack is completly skipped (i even thought about some bugs or some nasty thing happening before guessing the cause)

now: this may have been my fault not knowing it (i don't remember having read it anywhere, but maybe it's always been that way since the begin, but if it confuses me, then i can't imagine new players) but what i find wrong is that the game allowed me to spend (several times, doh!) the 20 huc fee to perform destruct and i consider this a bug or at least a big trap (along with not informing players about game rules)

To inform players about the fact that crownholders can't destruct, the game should prevent destructing at first place, informing the player and preserving his coins too

so to summarize:
- daemon should rise error if crownholder perform a move that have a destruct into it, preserving to accept the transaction (of course i can implement a check on my client but this is a "business rule" that should be handled by the daemon)
- players need to know about this rule (i didn't found it wrote anywhere, link me to the right place in case i missed it, anyway for a new player this isn't something he know. while not knowing about the fact that the crown has not a carry capacity cap (because it's not a constraint), not knowing that he can attack is very nasty

Probably with the next fork we would remove the fee problem, hopefully, implementing timers, but about the "crown holder can't attack" rule i'm wondering, why prevent crownholder to attack? what's the rationale behind? a crownholder can't then defend himself and has just to run away? Shouldn't we allow him to attack?

this is the code part (at the end) where i see crown holder can't harm anyone:

Code: [Select]
CharactersOnTiles::ApplyAttacks (const GameState& state,
                                 const std::vector<Move>& moves)
  BOOST_FOREACH(const Move& m, moves)
      if (m.destruct.empty ())

      const PlayerStateMap::const_iterator miPl = state.players.find (m.player);
      assert (miPl != state.players.end ());
      const PlayerState& pl = miPl->second;
      BOOST_FOREACH(int i, m.destruct)
          const std::map<int, CharacterState>::const_iterator miCh
            = pl.characters.find (i);
          if (miCh == pl.characters.end ())
          const CharacterID chid(m.player, i);
          if (state.crownHolder == chid)

that           if (state.crownHolder == chid)

Development / a possible use of gamefunds
« on: August 04, 2015, 10:48:55 PM »
was thinking that now that we have random spawn + random banks and during disaster, coins carried when dying by poison are sent to gamefund, can't we distribuite them randomly on the map?

actually we have big areas (like the big 4 areas near center) that are big and with no value, if we drop coins randomly on the map, those "abandoned" areas could be more important

a way to know how much coin to distribute is just having a counter that consider the coins that goes to gamefund between two disaster, and take a % of it (50%?) so that we can distribute randomly some coin on the map, during the safe disaster period (we can extend the safe period too, to 3 days)
this way, having random coins on the map, would cause hunters to go there collecting, creating more pvp chances

regarding the idea of skills, etc i was talking in other posts, i was thinking about implementing a mechanism to change parameters that are used in the game

of course for skills/stats it is easy to understand the benefit, but even for other parameters like hunter cost and fees, can't we think something about changing them without requiring a fork?

I've an idea and here it is:
- a special (valid) address is used to send the modified parameters with a special method just for that (e.g. game_changeparams) where you pass the list of updated parametrized values
when that transaction is included in a block, then the daemon wait (1440?) blocks or more before applying it, so we have time, in case someone hack the address private key (or in case of error) to stop miners

this way we can easily change game parameters that need to be tweaked very easily without impact

this would add the problem of trust, but if we change just gameplay parameters (and enforce changes between constraints) and not other things, it would be fine
what do you think?

Development / Recap about latest discussions
« on: August 04, 2015, 12:22:41 PM »
ok, snailbrain asked to post here last idea posted on bitcointalk and here it is a detailed draft of the whole gamplay, including something unchanged respect current running version:

This "poem" could be scay to read, but actually it's just a list of features and some numbers, but it's needed to understand the implication.
But I think that the most important thing is to agree about the features to add, because numbers should be chosen after the changes are implemented and so tweaked on the field (testnet) before applying fork

I'm pretty sure those changes, that except (maybe) traps doesn't require big changes, could be implemented in few time and so we can use that forked version of the daemon to test things on testnet ourself and with players who want to help, anyway here the details!! (please say what you think about the idea, details can change, i'm more interested in the core idea)


- when a player spawn, he spawn randomly like now
- banks spawn randomly, maybe with a finished alghoritm to prevent having banks too close (don't spawn a bank closer to a 10x10 cell respect another maybe?)

- there are no more colors, or anyway colors are just cosmetic, everyone can hit everyone else (we could use color to bind them to build templates but we would be limited by 4 templates then, so i think would be better to just consider color as cosmetic, or add as more new "colors" (better talk about sprites) as the available templates

- when a player create a hunter, he can chose his starting equip/skills [*1 for details about templates and skills]

- decrease the hunter cost to 50 + 5.
People argue about the general cost of the game so it should be taken into consideration and 50 sounds fair to me, even because without the attack fee, a fight winner will still earn more than what he earn with current fork (in an even match of course).
Cost was set so high even to limit population i know, but since population has sunk to 0 I think we should learn that high cost is self-defeating, moreover with the added complexity, controlling many hunters would be proibitive and ineffective, even because of FFA.
If in the next fork we create zones for pvp and zones for collectors, the collectours would cost e.g. 1500 just to lock coins, like someone suggested on bitcointalkforum (those coins are always refunded, is just a way to limit player creation without affecting the final player balance).

- Locking coins (but refund them on death) could even be a way to prevent too much players on the map, so we could even say that a hunter costs you 50 (your actual life, like current 200) + 5 (creation fee, lost) + 1000 (locked coins, refunded upon player dead).
Of course someone with a big wallet could still create 50 hunters, but he have to invest 1055 for each hunter and anyway not easy to command that amount of hunter and not effective as stated above

- implementing the ammo/armor concept, during player creation, the build a player chose impact on the available stats of the hunter and the starting equip [*1 again to read about details]
- ammo and armor regenerate over time, depending on the point spents on their respective skills [*1]
- remove lifesteal concept
- when a player has no armor and get hit, he lose everything he have (if he won 4 fights and have 200 on him, if he die he doesn't lose just 50 per hit but whole 200)

- add different kind of attacks, that have different cooldown and require different amount of ammo per attack [*2]

- add a generic attack cooldown, so everytime you attack (any kind of attack), you have to wait a specific number of block before being able to attack again.
This prevent spamming destruct, mitigate good connection vs poor connection problems and add the needed complexity, along with armor/ammo, to plan well your actions

- every attack type has another exclusive cooldown, that's exclusive to the type of attack. Consider each attack as an ability, like in normal RPG/Action game, you can't repeat the same action without waiting its cooldown to end. This way we can add even powerful attacks that have a bigger cooldown respect other attacks [*2]

- i suggested an ability called "evade" that act as Neo in matrix, for X blocks (5?) after activation you dodge every attack, but this have a very big cooldown, like 120 (1 hour) or more and during evade you can't attack (it could be useful to just escape all attacks if you are on a bank and wait destruct, or if you want to go through lot of enemies)
It could work well with the snailbrain idea of traps, see below, so you can evade and bring players on a trap (does trap have a radius?) because even if an evading player can't attack, he could activate other abilities and "trigger trap" could be an ability available.

- add what snailbrain suggested, traps. this need maybe more thinking and would require more development effort that other proposal, but the idea is that a player can use a hunter to deploy a trap on its current cell, in a encrypted transaction (but it shouldn't impact game interface, it should be automatically handled) and this way you have a new object, called "Trap", that's listed in your GUI (i'd say it shouldn't be bounded to a specific hunter rather than being available at a Wallet level, so you can trigger it whenever you want and even if the hunter you used to deploy it died)
Traps last for a fixed amount of blocks (let say 60, 30 minutes approx) and then they are removed from the map. To trigger an explosion then, a player has to activate it using a special transaction that shows it to all and prove you had placed the trap there, at this point whoever is in a range of 2x2 (?) take lot of damage (we need to test and see, i'd say to start from 5, so a hunter with less than 5 armor die and money are sent to the address of the hunter who deployed the trap).
- Traps can be deployed only if, when you create a hunter, you spend build points on the trap skill (and i'd say that a trap is so powerfull that such hunter shouldn't have armor/ammo or just 1/1)
- a hunter can carry max 1 trap and it have no cooldown but it's unique, this way we prevent the map being filled by traps, that would break the gameplay at all

- we process move before than destruct, it would allow to close the gap and attack at the same time, now it's not possible and if you want to attack someone that's 2 blocks from you, you can't just close the gap, then wait, then attack because he would attack you before, looking at pending tx (now you'd have to take a larger route and attack later). even with the inverted pending the enemy could of course try to evade, but with increased range of new kind of attacks, it would still be possible to hit him. (btw this point is the less important maybe, but worth trying, it costs nothing to invert the computation and see how game behave, we could even change it again before the fork if we notice some problem during testing on testnet)

I tried to detail a lot, now let me clarify some aspects

when you create your hunter, you can chose how to equip him and which abilities he have
the important work would be to balance the cost of each skill so that you can't create a god hunter.

An example of a build system could be this:

you have 20 points to spend, and you can chose between:

- defense skill
1 armor costs 1
2 armor costs 3 (1 + 2)
3 armor costs 6 (1 + 2 + 3)
4 armor costs 10 (1 + 2 + 3 + 4)

same for attack but every attack level means 3 available ammo
- attack skill
1 attack costs 1 and give you 3 ammo
2 attack costs 3 and give you 6 ammo
3 attack costs 6 and give you 9 ammo
4 attack costs 10 and give you 12 ammo

you can pick your regeneration rate, spending point on them too

- armor regen (how fast your armor regenerate over time)
armor regeneration lvl 1 costs 1 and regenerate an armor every 30 blocks
armor regeneration lvl 2 costs 3 and regenerate an armor every 20 blocks
armor regeneration lvl 3 costs 6 and regenerate an armor every 15 blocks
armor regeneration lvl 4 costs 10 and regenerate an armor every 12 blocks

- ammo regen (how fast your ammo regenerate over time)
ammo regeneration lvl 1 costs 1 and regenerate an attack every 20 blocks
ammo regeneration lvl 2 costs 3 and regenerate an attack every 15 blocks
ammo regeneration lvl 3 costs 6 and regenerate an attack every 10 blocks
ammo regeneration lvl 4 costs 10 and regenerate an attack every 5 blocks

you can chose the trap skill
- trap skill (allow you to deploy 1 trap on the map)
trap lvl 1 costs 16

having a trap still allow you to set 1 point on other skills, so that you can have 1 attack/defense and 1 regeneration on both or you could be more defensive and buy 2 armor and 1 armor regen, etc...
it's up to you, you could use a hunter with trap to taunt others and bring them over the trap zone, etc... could be funny

Note: to keep this simple for players, the GUI should allow the selection of a preconfigured template that already assigned this levels, so a player can just pickup a builtin template (maybe bound to a specific color/sprite) or create his own and save for later reuse, anyway this is a GUI problem, not a daemon problem, at daemon side it has just to validate that the total cost of skills is <= 20 (or anyway the maximum spendible points)

now about the different kind of attacks, this is how the proposed system works:
every hunter can chose between different kind of attacks, that costs different amount of ammo and have different specific cooldowns, here some examples:


name: normal attack
cost: 1 ammo
cooldown: 3 blocks


name: plus attack
cost: 2 ammo
cooldown: 5 blocks

X       X
  X  X
  X  X
X       X

name: cross attack
cost: 2 ammo
cooldown: 5 blocks

  X X
  X X

name: right cone attack (and left/top/bottom variant)
cost: 3 ammo
cooldown: 7 blocks

you can't use the same attack if its cooldown aren't over, but you can use another attack as soon as the "generic attack cooldown" of 2 blocks has passed
to use attacks of course you must have the needed ammo (so if you have just 2 ammo left, you can't use the "cone attack"

of course cost/cooldown numbers are example and need to be tested on testnet to chose balanced values

when you are facing an enemy, things get then complicated because everyone can chose its own strategy to attack.
Watching enemy equip, you should know that he can either use 2 of the 3 different attacks, because he doesn't have ammo for the cone attack, but you can't be sure about which attack he would use and then you have even to take into consideration his armor/ammo regeneration... this could be interesting and not so easy to fights again, so not so predictable...

example of what happen after an attack:
case 1: you attack with a normal attack:
   - it costs you 1 ammo
   - you must wait at least 2 block before being able to use any attack other attack except the normal attack
   - you must wait at least 3 blocks before being able to use normal attack again

case 2: you attack with a X attack:
   - it costs you 2 ammo
   - you must wait at least 2 block before being able to use any attack other attack except the X attack
   - you must wait at least 5 blocks before being able to use X attack again

case 3: you attack with a Cone attack:
   - it costs you 3 ammo
   - you must wait at least 2 block before being able to use any attack other attack except the Cone attack
   - you must wait at least 7 blocks before being able to use X attack again

fight case:
you attack with a Cone attack
   - it costs you 3 ammo
   - after you wait 2 blocks, you then use normal attack (cone attack is still in cooldown for 5 blocks (7-2 passed block)
   - it costs you 1 ammo
   - after you wait 2 blocks, you then use + attack (cone attack is still in cooldown for 3 blocks (7-4 passed block)
   - it costs you 2 ammo

as you can see, fight are more challenging and i haven't put into the examples the regen rate and maximum available ammo!

this way a fight would be interesting and not so easily predictable, but we have to balance attack powers with cooldowns, etc...

anyway i again say in bold: focus first on players having fun than on bot problem, bot could be considered at the end like a good player, with those variables ins't easy to code a god bot and anyway with ammo/armor hunters aren't equal powered at a specific block, so even a bot can lose

repetita iuvant:
I'm pretty sure those changes, that except (maybe) traps doesn't require big changes, could be implemented in few time and so we can use that forked version of the daemon to test things on testnet ourself and with players who want to help

Development / Gameplay Change: ammo/armor concept and pickable items
« on: July 23, 2015, 06:32:01 PM »
I just had a skype session with snailbrain where i exposed some ideas/concept that would improve the game, trying to balance out fun with huc value and complexity
This will be a fair long post but should be read to understand current gameplay and discuss about the next step(s)

Let me repeat briefly the pros and cons of current gameplay to have a common starting vision of the game:

- random spawn + random banks (with variable life) let casual players join a relative small session without worrying about leaving their player on the outskirt, they just need to stand for 3 blocks over a spawn area to be removed from the bank. plus random placements remove the blockade problem, because a bot master or a dominator would have problem grouping his hunters and anyway random banks allow people to bank everywhere

- lifesteal and fight mechanics potentially allow people to fight in a balanced way, preventing blockades or suffering about being outnumbered (but could be improved a lot, see below)

- removing disaster penality prevent people loosing hucs too easily, discouraging them to create hunters after the safe period (now disaster just remove hunters refunding cost)

- pvp coins "lifestealed" doesn't suffer from miners fee

- spending 20 hucs to trigger destruct, cause pvp being too costly because in an even fight, many times both hunters will trigger destruct causing null action, but spending both 20 hucs, so if during a fight those actions repeat for too many times, the final winner (if any) risk to be anyway with a negative balance.

Doing some math, without considering the standard transaction fee but just the "destruct fee", you break the even after 10 destruct (if you win a 1vs1 you get 200, but if you had done 10 destruct you paid 200 too)

For the fight loser it would be even worse because he'd have lost the destruct fees + the hunter cost, so in a 10 destruct scenario, he would end up losing 400 hucs...
of course thing could even be worse if you fight for more than 10 destruct

moreover, someone could even harass you even spending more than what you are worthing, just to try to run you out of money on the wallet, that way you couldn't trigger destruct to defend and so every hunter you have on the map is exposed to others

- now destruct, despite the cost, can be spammed (high cost was added to prevent that), but this way, even connection issue could cause someone to lose because his transaction has been sent too later respect someone that maybe have direct access to the miner, and custom daemons could even try to send a new destruct earlier than the official daemon can (it has a check that prevent to send a transaction if you have another pending transaction on the same hunter, but if the modified daemon knows that a pending transaction is going to be included in the next block, it could already try to send a new destruct).
Spamming destruction make even the pvp too flat, you can't actually dodge and counter attack, but adding a "destruct cooldown" instead could add more tactical decision to the game.

- unluckily, current implementation process destruct before the move action, this prevent even a possible counterattack action with current implementation, because you can't create a move that close the gap and destruct right after, but instead it first destruct than close the gap, this way is impossible to make a feint or stay at safe distance then suddenly close the gap and attack

- as stated before, if you run out of HUCS in the wallet you can't defend/attack, so your hunter can just try to move (if you have at least money to send transactions) and hope to reach a bank to recycle

there are other things i pointed out but now i don't remember, eventually I'll add them to the pros/cons list, anyway let's now talk about the new proposed concept

TLTR, start from here:
To prevent all stated problems, i've tought about implementing a "Ammo/Armor concept" for the attack gameplay aspect, here how it works

- a) - i think we could allow friendly fire attacks at this point, because random spawns removed the fixed, color based, spawn locations, and now everyone should be able to attack anyone, we could use colours to change some statistical/equip aspects
- b) - Destruct word should be replaced (the conecpt already has changed) by Attack
- c) - Destruct=>Move processing order should be inverted, first the moves should be computed, then the destruct, this way you can stay at a safe distance then prepare an action to move closer and trigger attack, this would cause first the hunter to be moved, then computing the attack action, allowing for feint and evade actions that now aren't possible

ok now the concept details:
- hunter cost is 200 + 20 (200 goes as life as now, and 20 is increased, instead of actual 5, because now destruction doesn't cost and we need a way to prevent generation of too many hunters)
-When a hunter spawns, it has:
  • a fixed amount of ammo that he can use to attack other hunters: 1 ammo = 1 available attack action
  • a fixed amount of armor that will be used when the hunter suffer from an attack (this prevent losing "life", as long as you have armor)
- here we can use different colors to vary how many armor and ammo a hunter has (e.g. yellow start with 10 ammo/5 armor, blue with 5 ammo/ 10 armor, etc...)

- randomly, will be dropped on the map random items (armor/ammo) with random quantities, so you can pick up a +5 ammo item, or +2 armor, etc... (this is the previous heart concept, except that now it adds an amount of armor or ammo). To add some spicy, we may even compute how much ammo or armor value the item has, the very next block after a hunter picked up it, so you don't know yet how many weapon/armor you'll have next (or we could implement both: specified random items and "jolly" items

- a hunter will have a new action, called EVADE, that would be mutually exclusive with DESTRUCT, o you can choose whether to attack or evade an attack.
- both ATTACK and EVADE will have a cooldown timer, so you can't attack every block, you have to wait 3 blocks to attack again and you can use EVADE once every 25 blocks (we can use hunter's colors here even to differentiate the cooldown)

- when you run out of ammo, you can't attack anymore, so you have to find a ammo item or run away using armor to defend yourself using ammo (like now, if both attackwhile you reach a bank
- when you run out of armor, you can try to evade or use ammo to defend, like now (ammo vs ammo cause a null action, or we can choose to apply an hit so without ammo you die, need to think about this)

I'd say that we can implement this fairly fast, there is nothing technical different from current daemon implementation, GUIs must be updated to reflect new items and stats, but core developemt should be straight forward.
Domob, thoughts about implementation details?
If we agree I'd say we can implement changes (domob on core, me on my client and Unity3D developer on unity client) and than using domob work to create an open/closed testnet session to test changes and fights there

this way I think that the game would be really fun and more balanced, not based on how many coins one holds in its wallet and more skill and tactical based
feel free to express your thoughts

Development / what are the changes in game objects/RPC/whatever?
« on: June 15, 2015, 06:30:04 PM »
In order to update my client with latest changes, what have been changed in terms of game objects returned by RPC calls like game_getstate?
and what about rules?

I've seen the bank array with x,y,life , anything else?

about rules, i've read somewhere about the "3 blocks on bank to recycle", is it still valid?

and about banks/spawn area: banks always have been color agnostic, so it doesn't matter what's your hunter color, you can bank anywhere, i suppose it's still valid but now that banks are random placed, a hunter have a chance to spawn anywhere?

other rules to take into account?
I think those info are useful to players too

Technical / Support / Bounty feature
« on: March 12, 2015, 03:14:45 PM »
hey ya,
I want to implement a bounty feature, where a player within my client can set a bounty that mean "kill player XXX"
then whenever the target die, i wait some confirmation than i decode the transaction to get who killed him
once i get the killer, i send the bounty to his address

this way anyone can get the bounty, my client would be needed just to set bounties (but any client that allow people to type OP_RETURN value can send bounty money to my specific address, specifying in OP_RETURN who's the target (based on my specs, could be just something like WANTED:hunterName.0

now, i've some questions about this:
what's the best way to get a "killed by" transaction? should i parse last block everytime a new block has been added?

there is then the REORG problem, to handle that i think i could just, every block, get the block generated MIN_CONFIRMATION blocks before
e.g. with MIN_CONFIRMATION =100, if block 683140 arrive, i can parse block 683040, looking in every transaction if it cointains some "killed by" information

does it sounds right? anything i miss about that?
If yes i just need to know who to get the "killed by" information

Development / Fight changes
« on: March 09, 2015, 12:18:53 PM »
i think that fight should be changed a bit, to make it more skill based and fun

actually only attack is a 1x range attack radius
with droppable power ups we can increase it, ok, but would still be a plain range attack

what if we implement a directional shot?
- a hunter can just shot to a cell next to him (or maybe even 2x range) and if an enemy is hit, he die (but not the attacker)
- a hunter can attack only once every x blocks (5 or 10, to prevent spam and make it so that if one miss the kill, risk to be killed)
- range explosion will keep being available, it will sacrifice the attacker but it will affect any color around (except at spawn area maybe) but the range explosion will just wound the enemy, so it set a random value to actual "poison" property (or a new "wounded" property"), so the wounded enemy has still a chance to kill the aggressor but will have a short life expectancy. same colors hit by a range explosion could just have malus like being dazed, so they can't move for xx rounds
- a wounded enemy hit again by a range explosion will instantly die

i think this would add a lot of fun to fights!

- skilled players may survive to attacks because a skill shot doesn't kill the attacker (you'll have just the "recharge time" to take into account to not being killed) and insta kill the enemy
- wounded hunters can still kill one or more enemy before die, so it doesn't matter if a player has more hunters than another
- diversified kind of tactics and gameplay in PVP

we need just to think about mechanics, since the attack isn't applied the next round, a target cell may become invalid, so the hunter will have a recharge time but i think it's ok, a player have to time the attack right! Of course this problem apply only on a moving hunter

I've already an half idea about how to apply it on my client graphically tho

a first step could be even just adding the "wound on range explosion" thing, would be very easy and will allow people to fight more vs high number of enemies

Development / How to handle ideas/brainstorming
« on: March 08, 2015, 06:02:18 PM »
I think we are talking throwing out ideas without having a clear design about where we want to go...

Without having a way to organize and "vote" ideas, considering pros and cons, i think we need organization first of all

I suggest to create a list of current foreseen/unforeseen problems and possible future pitfalls that need to be handled some way, something like

- prevent players leave the game because they lost too much easily money
- prevent single player being able to control zones just with numbers
- prevent the map being too much crowded
- improve game speed


then, everytime we have an idea, we can pass it throw the list above, marking which point it handle successfull and witch fail to handle, or mark it as unapplicable for ideas that doesn't reguard some of the points (e.g. if an idea is about preserving money, this can't handle the game speed issue, so game speed problem is inapplicable

who have an idea, can do himself the check, explaining why/how he think a problem would be addressed by his idea

once an idea sounds good (it handle properly problems and don't make worse current gameplay) then can be voted/approved and put on the official list of things we want

We can use then this list to create a roadmap where development time has to be taken into account, and so think about which feature add to take current implementation to final implementation, without screwing up the gameplay in the process (so avoiding problems like rising costs to the moon meanwhile disaster is still on after a day, etc...)

sounds fine?

Technical / Support / old blockexplorer redirect
« on: March 05, 2015, 09:38:54 AM »
i see on many places that as huntercoin blockexplorer, the old is still the link used, i think that who can put his hands over that server, should redirect that url to the BGB block explorer, would be easier than asking to very place to change their address

example of broken link here

Development / Crown change
« on: March 05, 2015, 01:29:57 AM »
I was thinking about changes to the crown:
actually it's aready camped at base, so my idea is this:

what if crown spawn at one of the 4 spawn areas, and you have to bank it in the middle?
i would be nice because every hunter, even a noob, as a chance to step over it and hold it for a glorious block (remember that incentivate players with things like this is what make players happy) while at the same time prevent someone camp at spawn area, that are too difficult to attack

this way, the crown older can't camp in the middle because of teleports (and maybe we could trigger disaster at very center location) and the fight will be really worthy

Technical / Support / question about OP_RETURN
« on: February 27, 2015, 09:24:25 AM »
the way i wanted to use OP_RETURN was to add an identification to a transaction in order to prove that user XX payed to address 123 or that hunter213.12 subscribed to a context, etc...

now i was looking at bitcoin docs (where OP_RETURN comes from) and i've just read a scary thing: OP_RETURN transactions can be pruned and its output value is unspendable


now my question is: how is OP_RETURN handled here on huntercoin? i think we should consider every tx with OP_RETURN a standard transaction (and maybe it is already), because otherwise it has lost all its attractive to me

domob, can you confirm that bitcoin works as i've read and understood (could be wrong) and that in huntercoin we don't have that problem?

Pages: [1] 2 3 4