Skip to content
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

468 show captured pieces instead of material imbalance #1142

Open
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

Jimima
Copy link

@Jimima Jimima commented Nov 8, 2024

Had a go at this, draft at this stage as there is a bit to do but wanted feedback on the overall idea, if possible

Relates #468

@veloce
Copy link
Contributor

veloce commented Nov 11, 2024

UI looks fine!

@Jimima
Copy link
Author

Jimima commented Nov 11, 2024

I added a secondary option to the settings for this. I wonder if this is the best approach, it was simple to add it this way but maybe a single choice with 3 options would be better

Was also a bit unclear on why the theme preference implementation did something custom for the choice picker on ios, this seems to work but can take the other approach if there is a reason to do so

@ijm8710
Copy link

ijm8710 commented Nov 11, 2024

I think it makes more sense to have one setting with 3 options. Rather than 2 separate toggle due to the fact that the settings screen keeps getting more options and to limit it best we can.

Obv Veloce/toms opinion will carry more weight but I think it's best to keep that contained best they can

@Jimima
Copy link
Author

Jimima commented Nov 12, 2024

Alternate option

@Jimima
Copy link
Author

Jimima commented Nov 14, 2024

In-game option

Simulator.Screen.Recording.-.iPhone.16.Pro.-.2024-11-14.at.08.55.42.mp4

@Jimima Jimima marked this pull request as ready for review November 14, 2024 09:14
@Jimima
Copy link
Author

Jimima commented Nov 14, 2024

Would appreciate a review @veloce @tom-anders

@veloce
Copy link
Contributor

veloce commented Nov 14, 2024

It is better with a single setting yes. Thanks!

black: MaterialDiffSide(
pieces: black.toIMap(),
score: -score,
capturedPieces: blackCapturedPieces,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you extend test/model/game/material_diff_test.dart with a check for capturedPieces?

IMap<Role, int> startingCount,
IMap<Role, int> subtractCount,
) {
IMap<Role, int> capturedPieces = IMap();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be written in a pure functional way:

return startingCount.map(
    (role, count) => MapEntry(role, count - (subtractCount.get(role) ?? 0)),
);

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I thought this should be possible but I couldn't figure out the right way to do it

Board.standard.materialCount(Side.black);
final IMap<Role, int> whiteStartingCount =
Board.standard.materialCount(Side.white);
// TODO: parameterise starting position maybe so it can be passed in
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I think this is needed before merging - It's already possible to view (but not play) variants that have a different starting position (e.h. Horde). With this PR, capturedPieces will display incorrect values currently.

However, I noticed that the web UI does not display material difference at all for Horde, maybe we should do the same? @veloce wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's some commented-out code here that probably needs to be removed


const MaterialDifference({
required this.label,
required this.visible,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the visible field really needed? A property bool get hidden => this != MaterialDifference.hidden would also work (and probably same some memory)

required this.visible,
});

final String label;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The label will be translated at some point, so it's maybe better to already make this a method along the lines of String l10n(BuildContext context) => switch (this) { ... } instead (and add a //TODO l10n)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I am not 100% sure what you mean here (though I understand the broader point). Is there an example somewhere else I could look at?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I meant something like this:

String l10n(AppLocalizations l10n) => switch (this) {

But actually it's more common in the codebase to do it via a free function, like this:

String shapeColorL10n(

@@ -110,7 +119,9 @@ class BoardPrefs with _$BoardPrefs implements Serializable {
required bool boardHighlights,
required bool coordinates,
required bool pieceAnimation,
required bool showMaterialDifference,
// required bool showMaterialDifference,
required MaterialDifference materialDifference,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Calling this MaterialDifferenceFormat (like in the commented line below) would be more readable I think. Currently, there's both MaterialDiff and MaterialDifference which is confusing

size: 13,
color: Colors.grey,
),
if (materialDifference == MaterialDifference.capturedPieces)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it would be more readable to factor out this whole Row into a class MaterialDifferenceDisplay extends StatelessWidget. (Then you could also precompute the pieces to loop over in a helper variable and use that in the loop, instead of needing to write the loop twice)

@Jimima
Copy link
Author

Jimima commented Nov 15, 2024

@tom-anders I pushed up a bunch of changes, would appreciate you taking another look when you have the time 🙂

: '',
),
],
else if (materialDiff != null &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if both these conditions should be moved into the new MaterialDifferenceDisplay's build() method as well (returning SizedBox.shrink() if either of them is false) . This way we'd have all the logic in one place. (it would also make the ternary in lib/src/view/game/game_body.dart l. 131 redundant)

@tom-anders
Copy link
Contributor

very nice, no more comments from me :)

@Jimima
Copy link
Author

Jimima commented Nov 15, 2024

Oh should have said, I still don't really know the best label to use for the setting. I just changed it to simply "Material" just now but I've changed it a few times and still can't decide what is best. Happy to be told here!

@Jimima
Copy link
Author

Jimima commented Nov 15, 2024

very nice, no more comments from me :)

Thanks, will take a look at the l10n stuff tomorrow

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants