Arena GQL Simulator - Win % calculator#2084
Arena GQL Simulator - Win % calculator#2084FioX0 wants to merge 8 commits intoplanetarium:developmentfrom
Conversation
Added Exception if index too high/small
Co-authored-by: Yang Chun Ung <qooraven@gmail.com>
Co-authored-by: Yang Chun Ung <qooraven@gmail.com>
| } | ||
| ); | ||
| Field<NonNullGraphType<DecimalGraphType>>( | ||
| name: "arenaPercentageCalculator", |
There was a problem hiding this comment.
I guess stateQuery might not be the best place for this sort of query because it seems very domain specific(i.e., PVP system) logic instead of simple state lookups. (but on the other hand, it isn't strong due to a lack of alternatives 😅 ) cc @planetarium/nine-chronicles
There was a problem hiding this comment.
May I suggest a new category called "simulatorQuery"? I also got a Stage/PVE one that is almost done. So both queries could be set under this new category.
| int win = 0; | ||
| int loss = 0; | ||
|
|
||
| for (var i = 0; i < 1000; i++) |
There was a problem hiding this comment.
it would be nice if we have an option for this iteration count as configurable.
There was a problem hiding this comment.
Will add this right away, I'm thinking of making a hard cap of 5000? It gets quite resource intensive.
There was a problem hiding this comment.
introducing a hard cap would be nice! I don't have an appropriate number for that, but both 1k and 5k are looks good to me.
| loss++; | ||
| } | ||
| } | ||
| return Math.Round(((decimal)win / 1000) * 100m, 2); |
There was a problem hiding this comment.
Returning aggregated summary makes sense but I also think that more detailed information might be more helpful.
e.g.,
{
"blockIndex": 1,
"result": [
{
"seed": 1234,
"win": true
},
{
"seed": 5678,
"win": false
},
]
}There was a problem hiding this comment.
Thanks Swen.
So BlockIndex,
Percentage and then a
Results List per seed/win state?
Then user can decide if they want the result list?
There was a problem hiding this comment.
blockIndexmay be needed to determine what sheet states we have referred.seedcan be used for local validation as you said. 😄
There was a problem hiding this comment.
@longfin
Like so?
{
"data": {
"simulationQuery": {
"arenaPercentageCalculator": {
"blockIndex": 7133512,
"result": [
{
"seed": 1893608300,
"win": true
},
{
"seed": 2073532131,
"win": true
},
{
"seed": 1826085108,
"win": false
},
{
"seed": 1985649038,
"win": false
},
{
"seed": 614892139,
"win": true
},
{
"seed": 2060699251,
"win": false
},
{
"seed": 784343549,
"win": true
},
{
"seed": 2109394172,
"win": true
},
{
"seed": 1339463095,
"win": true
},
{
"seed": 1834517228,
"win": false
}
],
"winPercentage": 60
}
}
},
"extensions": {}
}
GQL Query as per below:
query{
simulationQuery{
arenaPercentageCalculator(avatarAddress:"0x63b6fef274118719790f63865e63a2cd26ff14dc", enemyAvatarAddress:"0x63b6fef274118719790f63865e63a2cd26ff14dc", simulationCount:10){
blockIndex,result{seed,win},winPercentage
}
}
}
|
This PR has Quantification details
Why proper sizing of changes matters
Optimal pull request sizes drive a better predictable PR flow as they strike a
What can I do to optimize my changes
How to interpret the change counts in git diff output
Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email) |
2 participants
Please note that this might be a bit of a resource intensive query. It performs quite well on my Dev PC, but on my VPS I do see a bit of a slowdown but the VPS isn't really strong to begin with.
I have optimized this as much as I could. Might not be suitable for production, but letting planetarium to make that decision.
This allows you to provide 2 AvatarAddresses and it will simulate 1000 fights and return a decimal which would be the % of avatar1 winning against Avatar2.
query{ stateQuery{ arenaPercentageCalculator(avatarAddress:"0x3b7a47daaece48807fc00a310b05bd9f5d26736e", enemyAvatarAddress:"0xab44635462880666daa7f2be5a21c71c1590ff2b") } }{ "data": { "stateQuery": { "arenaPercentageCalculator": 3 } }, "extensions": {} }