The proposed ICRC-14 Game General Stats standard is important because it establishes a common format for games to expose their main game stats and player stats. This format can be used by various ICP games, tools, and gamers to query gaming data in a standardized way, thereby improving interoperability between games and enabling collaboration between multiple projects.
Minimal set of types and methods for games to expose their main game stats and players stats to boost collaboration and side tooling.
Introduction
This proposal describes the minimal set of types and methods that will help games to have standard stats for their main stats and player stats. We hope that this will boost ICP games interoperability and thrive the collaborations between multiple projects.
Goals
Allow games, tools and gamers to query main gaming stats for any game.
Allow gamers to query their gaming data.
Allow authorized third-parties to query their gaming data (Should be on another standard).
Provide an authorization mechanism for gamers to approve who manages their data (Should be on another standard).
type Identity = variant {
Principal : principal;
};
Is the intention here to allow for additional identity types to be added in the future? If so you might have to rethink this part a bit; check the feedback Andreas left here.
Applying his his advice above to the Results type…
type GamerStatsResults = variant {
Ok : GamerStats;
Err : opt GamerStatsError;
};
Next, regarding:
type GamerStats = record {
hours_played : Nat;
session_time_average : Nat;
extras : Value;
};
What are your thoughts about potentially typing extras as a vec Property? Essentially, making it easily interpreted as a map by consumers.
I think this would also make it easier to quickly find some agreement on, and implement, genre specific stats as you allude to. e.g. fps games implementing ICRC-14 MUST include accuracy : Float in extras.
In fact, no one can predict the variety of upcoming games and determine the entire list of stats for the future. We use our NFT (EXT standard) as an account access key. The player’s account contains all stats. In different games, players can have different types of stats. Therefore, it would be reasonable to get stats from players’ game accounts, and not from tokens. This does not require any standard of token. Any programming language can easily parse the JSON format.
You can see how we get stats for dwarves from our game accounts on the website: https://ictokens.app/
Optional to support backwards compatibility in older clients
I have done some tests and I think Andrea’s feedback applies for GamerStatsError (Already updated) but my tests allows me to add identity variants without breaking frontends/otherCanis.
In both of them, you can remove commented Text variant and check what I mean. Maybe I’m missing something, please let me know.
vec Property
Agreed and already updated!! Love to use a vec record and not a vec tuple that is usually a pain on frontends imo. DAB uses vec tuple for details, maybe we could talk/suggest Funded to change this to vec record, do you see any advantage on vec tuple approach?
I’m going to write this answer on ICRC-14 Github issue also and will tag you. Please answer there.
Thanks a lot for taking the time to collab on this @iBardak
I want to clarify, this is not a token standard, these are just types and methods to be added on the main game canister if the game supports the standard.
The idea is to have an standard as simple as possible here (These are Game Stats). In Stats record you can see stats that every game normally have (I think):
and for Players is the same, I think these stats applies for every game:
type GamerStats = record {
hours_played : Nat;
session_time_average : Nat;
extras : vec {Property};
};
I would love if you can give us your thoughts on this stats, if you consider that they are important enough to be on the basic standard and what other do you think that applies for all games.
Of course there are a lot of stats that varies between projects and this isn’t by any means a restriction to use whatever stats a game wants to manage.
If we agree and use this standard, all the games on the IC can interoperate -with stats- easily based on that, and it will be super easy for additional tools (Internal and external to the IC) to map games and stats on the IC Game Ecosystem and give additional benefits to everyone.
After this basic standard we can work in by genre specific stats standard to complement this one (this will not be a restriction for games to use others than the ones on the standard though).
I’m going to write this answer on ICRC-14 Github issue also and will tag you. Please answer there.
I’d propose we use CandyShared as the “Value” type for this library so devs get prebuilt libraries to have fast access to handle the data types inside their canisters.
Great work! Personally, I do not. However, I’m a bit biased. I did a lot of backend development as a result I prefer to have my Request / Responses wrapped in records (its JSON all the way down).
I have a question about NFTs and metadata. Is there a way to give permission to an authorized canister to upgrade or update the metadata associated with an NFT? ex. Level 1, Level 2 with different properties
and I’m wondering if it’s possible to merge different NFTs into one. For example, if I have two NFTs that represent same parts, can I combine them into a single NFT that represents and upgraded version?
Yes, Eimolad uses this for in-game crafting. You can burn several NFTs and tokens and the mint of a new NFT. The sequence of these actions can be linked by a smart contract. This way you won’t have to change registry entries.
