-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Game.compute_rating #496
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yapf can be helpful, but I'd always double check what it did because sometimes it just isn't worth it. I've been reading about black
and it seems pretty good. The thing I'm not convinced by though is how it formats imports and will each imported item on its own line.
Note to self for testing:
We should test to see what happens in the scenario where one player ctrl-k's in order to destroy the other player's ACU. IIRC there was an issue with this a while back where the player who ctrl-k'd would always be awared a win instead of a draw.
For rebasing you should just need to:
Then resolve conflicts and do |
If I rebase onto |
No it wont affect develop directly. It just means if you ever go back and look at the PR there will be a bunch of extra commits in it. And IDK how it would affect a revert, but that's unlikely. If there aren't any conflicts, or not many conflicts then I tend to rebase out of OCD at this point. If you want to cherry pick only a few commits I think you can use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the logic is pretty solid; you got lots of tests which is great! If you are available to run a few test games at some point let me know.
Yapf has worked nicely in many places, but also not so nicely in others. Would be nice to tidy up the rough spots a bit.
Ok so I tested a game where two acus kill eachother with the ACU explosion. Here is what happened: First scores getting reported, army 1 reports an acu kill (score of 1):
Then when rating happens
In this situation it should be counted as a draw. So maybe we need to add that as an edge case. If both armies reported defeat then consider the game a draw. EDIT: |
…reported UNKNOWN.
Co-Authored-By: Askaholic <askaholic907@gmail.com>
use == for int identity, remove duplicate test reformat using yapf clean up yapf formatting hiccups
084f5b7
to
80bda30
Compare
Thank you for testing that! I changed the convention to treat games where both parties report defeat as draws. |
Looking at it now I guess I just interpreted it wrong. It even logged what the outcomes were and they were simply defeat for both teams. |
Looks correct now:
|
* failing test for issue 485 bug * First refactor of compute_rating. Does not handle games with results reported UNKNOWN. * compute_rating moved to GameRater class * Apply suggestions from code review Co-Authored-By: Askaholic <askaholic907@gmail.com> * Add double victory test, make FFA_TEAM constant use == for int identity, remove duplicate test reformat using yapf clean up yapf formatting hiccups * Treat game as draw if both parties report defeat * yapf cleanup and a few naming refactors * suggested use of player_factory * review suggestions Co-authored-by: Askaholic <askaholic@protonmail.com>
Mostly sparked by issue #485.
Based on PR #495 so includes a lot of commits from there.
I'll rebase once that's merged, so it will only include the last two commits.