Pong clone: Extra features and refinements to enhance the game and user experience

[Danimations]

Verification

• I searched for similar feature request and found none was relevant.

Pitch us your idea!

Five enhancements to the Pong-clone game and user experience

Description

I have several ideas which would enhance the Pong-clone game experience.

1. Vibrate on "Game Over"
2. Show past and high scores after game is lost
3. Bat should not travel beyond the screen boundary at top and bottom of screen
4. Start game again with a press on the score display screen
5. Ball velocity should increase gradually as the game progresses, ideally with every bat hit

Adding any or all of these features would make the game feel more complete and appealing to play.

Great job so far, BTW!

[Danimations]

@NeroBurner ... here are my ideas for Pong/Paddle game enhancements :)

[NeroBurner]

My thoughts on implementing your ideas:

1. should be easy, just add a reference to MotorController and use it to vibrate on death
2. more involved, where should we store the score? We'd need something like the Settings-Controller, but storing it there doesn't feel right. We'd need to create a paddle_highscores.dat or something similar.
3. yes good point, should be easy to implement, I think
4. should be possible, a little more involved. Connected with point 2., should probably be implemented together. A little more involved by creating an extra screen or programmatically creating the score screen. The imagination can run free :)
5. could be straightforward. The dx variable is a int8_t initialized with 2. So we can increase the value only by whole numbers. Increasing the dx each time hitting the wall (or the paddle) is easy. Then a game of pong was over at most at score 10. Afterwards the ball is blazingly fast. We'd need a bit of balancing.

Happy to review incoming PRs which implement those features

[Danimations]

Ha! Thanks for replying @NeroBurner , glad you're open to making some enhancements. It's a shame we can't use fractions to gradually ratchet up the speed. Given we're stuck with whole numbers, here's an idea for handling ball speed incrementally.. counter-based ball speed increases:

dx = 1 for first 1 bat hit
dx = 2 for next 2 bat hits
dx = 3 for next 4 bat hits
dx = 4 for next 8 bat hits
dx = 5 for next 16 bat hits
dx = 6 for next 32 bat hits
dx = 7 for next 64 bat hits
dx = 8 for next 128 bat hits
dx = 9 for remaining bat hits

Those numbers should provide a difficulty ramp that's appealing for the player.
I figured the score and end/start game screen would be trickier to implement.

[Danimations]

Here are some more suggested amendments that will improve the game. Three are design tweaks, one is a bug to fix.

6. Make the ball smaller (by say, 20-30%)
7. Make the bat thicker (by 50%)
8. Reduce the font size of the score to 75% of its current size, but keep the same baseline y-axis position for it
9. Fix the "ball runs along the outer walls" bug I described in issue Paddle/Pong - ball should not run along upper/lower wall boundaries #1084
10. Game should close and return to watchface display if no input is received for some period of time.. ie. 30 seconds.

@NeroBurner , these might be things you could assist with... I imagine the top three at least should be straightforward?

[Riksu9000]

Start game again with a press on the score display screen

Tapping on the screen should be enough and more intuitive.

The speed of the ball could use fractions if it was programmed that way. There's an issue with increasing speed a constant one unit. In reality the first increase would be +100%. The next is +50%, then +33%, and so on. In practice the first few speed increases would feel very large, and the later ones would be hard to notice I think.

Make the ball smaller (by say, 20-30%)
Make the bat thicker (by 50%)
Reduce the font size of the score to 75% of its current size, but keep the same baseline y-axis position for it

How would these changes improve the game? 75% of 40px font would be 30px, which we unfortunately don't have. The next font size is 20px.

Game should close and return to watchface display if no input is received for some period of time.. ie. 30 seconds.

I don't think any app should have app specific handling. The watch will stay on whatever app is left open.

Other than that I think the suggestions in the original post are fine. I'm just wondering how much effort is worth putting into this game. We wouldn't want this app hogging up too much memory. If/When InfiniTime can load external apps, I would expect this app to be removed from the default installation.

[Danimations]

Thanks for your thoughts and comments, @Riksu9000 . I'm pleased to hear that a fraction-based ball speed ramping may be possible.

I'm an (occasional) game designer, dedicated to making new games with authentic vintage feel, so this is my domain. I believe some of these adjustments will improve the aesthetic of the game and therefore its appeal. A thicker paddle will differentiate it further from the wall (which is thin), and bring it closer to typical vintage "bat and ball" game proportions. Similarly, the ball is much larger in this game than it is in other "bat and ball" games, so reducing it will make the game feel like a more authentic PONG clone.

Reducing the score's font size and creating a gap above the score (between the score and the wall) will improve the overall layout design, and when the ball hits against the upper wall near the score, it will be clearer for the player to see. I expect that for most players, the real-time score would be secondary to the gameplay itself, so should, in my opinion, not compete for screen real estate.

If there is a "game over/play again?" screen after playing, the score could be displayed there at 40 px size. That would leave a smaller, 20 px font suitable for in-game score display.

I understand your reservations about making the game overly complex given the Pinetime's limitations and other greater ambitions for Infinitime. I am not typical of the Pinetime early adopter base, and can confidently say that improving this game will be appreciated by less technical "lifestyle" users in the future. In my opinion, the game should aim for "release candidate" quality as soon as possible... while at present it feels Alpha/Beta.

[Eloitor]

What about controlling the paddle using the accelerometer?