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

Buffer new random tiles with direction information #12

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

milaq
Copy link
Contributor

@milaq milaq commented Sep 4, 2018

First off, thanks for providing a FOSS, ad-free alternative of 2048. Much appreciated 👍

This PR mitigates an exploit where the player reverts the last move step to generate a new random tile for the chosen direction.
This may not happen. The undo function should only be available to correct accidental errors, not to improve the chances of success.

Mitigates an exploit where the player reverts the last move step to generate a new random tile for the chosen direction.
This may not happen. The undo function should only be available to correct accidental errors, not to improve the chances of success.
@tpcstld
Copy link
Owner

tpcstld commented Sep 4, 2018

Hey! Glad you're enjoying it. :) Thanks for the PRs.

I wanted to fix this for so long, and I just never had time or motivation lol; and this is a nice and comprehensive fix for the problem. 👏 That being said, I'm not sure if I want to merge this. In the few years this app has been out, I've gotten a bit of feedback about how this "feature" has prevented RNG screw and let them win.

Yeah, it's cheating, and should've never been a thing in the first place. But cheating in a single player game isn't so bad, and I've grown quite attached to this exploit because of the feedback. And from a game design perspective, I've heard it kinda feels nice to think you're breaking the rules. :P

How do you feel about this: If there's something already in the buffer, we clear it before returning. That way a new tile is generated once every other undo, in case someone actually wants to trigger the exploit. XD

Thoughts? If you feel strongly that this shouldn't be in the game, I can merge it as-is. I just think the alternative might be a bit more... fun.

@milaq
Copy link
Contributor Author

milaq commented Sep 4, 2018

Thanks for your fast response.

I also thought about this the way you did.

The original game was implemented in two ways:

  1. The original game had no undo functionality whatsoever
  2. The Android port of the author later included an undo functionality, which also has this exploit (as of today)

So I asked myself whether it would be a good idea to "fix" this issue. Personally, I don't overuse the undo functionality; I've seen people literally doing trial-and-error runs. I think this diminishes the success of actually winning by quite a large margin, because it makes the game much easier.
This is of course just a personal feeling.
On the other hand, having an undo button comes in handy if one accidentially swiped across the screen in a slightly wrong angle. The original JS version used the arrow keys which are less input error prone than a touchscreen.

Maybe we could integrate an option to enable the the one or the other undo functionality; namely with and without tile buffering. We could call it "remeber spawned tiles on undo" or something similar.
This way, everyone should be pleased with the results and it doesn't scare off your user base.
This would of course need a bit more work as it needs a dedicated option screen. But then, we could also integrate an option to remove the undo button completely.
We could call it "relentless mode" or the likes (JK).
In turn, this could maybe also be a foundation for additional options if more ideas pop up.

Personally, I think the undo function should be "buffered" by default. Just like in chess for example, where the AI will most definitely make the same turn if the player decides to move the chessman to the position it was before undoing the turn.

Maybe this needs some input from other users. You can, for example, leave this PR open for a while and tag it with "waiting for opinions" or something like that.
In the meantime, this gives us the opportunity to think about all this calmly. It is not a time critical or game-breaking issue after all.

But in the end, you of course decide what's best for the project. I don't want to put pressure on you at all. If you think we should leave it as is, then I am perfectly fine with that :)

@AndyRead
Copy link

AndyRead commented Sep 5, 2018

I agree with everything that's been said:

  • Great game, thanks!
  • Great fix for an obvious way of cheating
  • But, I got used to using this cheat as a final escape route if necessary!

I like the idea of making it an option. The one thing I might add though is that the option cannot be changed in the current game. So once you've started a game with the option set one way you have to finish the game that way. You can't change the option for that game as an escape!

@tpcstld
Copy link
Owner

tpcstld commented Sep 5, 2018

Thanks for chiming in @AndyRead! Glad to know there's many dirty cheaters out there ;) (including me btw)

Honestly speaking, I want to avoid an options menu in this project. I'm not against options overall, but I wanted this app to be a "one size fits all" thing, if you understand. If we ever add options, I want to hide the UI somehow so only people who really look for it will find it. :P

Aside from philosophy, the main issue with adding an options menu is the non-trivial localization (i.e. translation) work that comes with adding new strings. I like relying on the community to translate this app (partly because I'm lazy and cheap, but partly because it feels more open source XD), but that means translations are not guaranteed to come at a reasonable time. I think it feels really really bad to have only partially translated strings, which is why I have avoided adding or changing text.

Lemme know if you two (or anyone else! hi!) have any further opinions about this. Currently, I don't think I'm going to merge this, but I'll keep this PR open in case I change my mind. Is that ok?

@milaq
Copy link
Contributor Author

milaq commented Sep 5, 2018

I understand your reasoning. It's all fine with me :)

@AndyRead
Copy link

AndyRead commented Sep 5, 2018

I agree. Your thinking is very sound Jerry. I love Micha's patch and think it's right in many ways, but the extra work to create a settings menu and language translations makes it hard to justify, unless a lot of users are screaming! Users can carry their guilt on their own shoulders if they continue to cheat ;-)

There's also the issue of whether it's better to diverge from the original 2048 - again pros and cons.

Andy

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.

3 participants