More notes on the subject:
-
Dragons accounts will need to receive mosaics which is why there should be a Parent Account that will be the Mosaics Issuer and Distributor account.
-
If you derive dragon accounts from the Parent Account, you don’t need to store the private key of the dragon accounts. This would make sure that only 1 account must be kept safe. (the Parent Account)
- This parent account, out of security, can be hold as a x-of-x multisig but implications must be noted. Whenever a new mosaic would need to be issued, all cosignators would need to confirm, etc.
- As a side note on this, in PacNEM I use NodeJS bots which validate PacNEM transactions and some bots also automatically cosign transactions. So automating the cosigning process is nothing impossible.
-
Dragons can be represented as NEM Accounts [as noted above, mark the implication of storing 1 more private key].
-
Dragon Attributes can be represented as NEM Mosaics
- Some non-transferrable, define base properties of the dragon (Strength 25, Health Points 15, Fire Points 35, etc.)
- dragons: namespace bought by @aenima, he was fast at it!
- Some are transferrable, customize dragons or make them stronger (NEM::Red Hat Mosaic 1, Fire+++, etc…)
- this would need more details because how can you customize a dragon?, would this add weapons to the game or what do you people think is needed?
- Some non-transferrable, define base properties of the dragon (Strength 25, Health Points 15, Fire Points 35, etc.)
-
Dragon Attributes can be represented as NEM Mosaics
My opinion is this will need to be multiple apps:
-
Backend keeping ownership state, transferring ownership, deriving (creating) dragons, keep track of the parent account. (NEMDragons state machine…)
-
Frontend would read state data from a API developped on the backend. Data needed here includes displaying informations about Dragons, their location on the blockchain (include geo-location features to make it hit Real Life?)
It is not a 10 minutes project that someone will finish very easily but it is very similar in features scope as was PacNEM which is why I thought my words can help a little and I also think this can help new developers because it would use a lot of what NEM has to offer.
I do not have lots of time to dedicate to this project currently but I can tell you that Xarcade would also welcome such ideas!
Cheers NEM!
PS :
^ ^
/ \ //\
|\___/| / \// .\
/O O \__ / // | \ \
/ / \/_/ // | \ \
@___@' \/_ // | \ \
| \/_ // | \ \
| \/// | \ \
_|_ / ) // | \ _\
'/,_ _ _/ ( ; -. | _ _\.-~ .-~~~^-.
,-{ _ `-.|.-~-. .~ `.
'/\ / ~-. _ .-~ .-~^-. \
`. { } / \ \
.----~-.\ \-' .~ \ `. \^-.
///.----..> c \ _ -~ `. ^-` ^-_
///-._ _ _ _ _ _ _}^ - - - - ~ ~--, .-~
/.-'