[WIP] HyperPong

WIP HyperPong is a clone of Pong with a twist :stuck_out_tongue_closed_eyes:
I actually just submitted a DDR clone called DDRBOY. I’ve been working on both these games so make sure to look at that thread if you are a fan of quick reflex games!

ANYWAY, back to HyperPong
Here’s how you play. Instead of trying to score against the CPU, you score points by simply touching the ball.
In fact, you can’t even beat the bot. That’s not the objective!
Here’s the twist: every time you hit the ball against a paddle, the speed of the game begins to increase rapidly. The goal is to see how long you can keep up with the ball! It gets super intense too (or maybe its just me :joy:)

My high score is 51 so try and beat me.

Here is a demo of it in action:
https://photos.google.com/photo/AF1QipNOKJQTKu4aKww0g3711xULfFD2Zjc4hll4ljY2
my sigh of release is justified; thats my highest score :joy:

I have the github here so you can compile it for yourself:

TODO:

  • add sound (could get annoying)
  • add menu screen
  • add game over screen
  • add mode with super powers or random occurrences (enlarged/shrunken paddle, larger ball size, screen inverts, etc)

Please give me some suggestions, I think this will be really fun to release :smiley:

1 Like

Pretty simple at the moment but has potential.

It’s good to see the code isn’t writing directly to the start of EEPROM and is shifted down a bit.

A few stylistic issues here and there but generally the code is quite good.

A few small issues/suggestions:

  1. The .ino file doesn’t match the name of the repo (though if there’s onlyever going to be one .ino file then that’s not too much of an issue).
  2. EEPROM is being read unnecessarily quite a bit. In particular, write_highscore doesn’t need to read_highscore first, and if you assign score to highscore then you only need to write highscore to EEPROM and you don’t need to read it back afterwards.
  3. The check for the special ‘sentry’ value in EEPROM only needs to be done once in setup. After that you know it’s true because only your program has had access to EEPROM and you aren’t changing it anywhere.
  4. The ball shouldn’t be moving in the draw_ball function. A function for drawing should only draw, it shouldn’t affect the game state.
  5. Using the framerate as a timing mechanism isn’t ideal because it causes the screen to be drawn more often, which could increase power consumption. There’s several alternative options available but in your case I’d suggest splitting the drawing and the logic from each other and then to increase speed you increase the number of times you do a logic step (this has the side effect of solving an issue called the ‘bullet through paper problem’).