The Bounce - A ball physics platformer


#1

The Bounce

The Bounce is a bouncy ball physics platformer game. Simple to understand yet incredibly hard to master, what seems easy at first glance is actually pretty rage inducing when you get to the later levels. I’m not much of an artist so I focused on simple design, which allows for easily customisable levels (maybe a level editor someday) and awesome gameplay.

Controls

Use LEFT and RIGHT to move
Hold DOWN OR B to slow down (Trust me you’ll need this)
Press A to double jump
UP to pause

Main Menu: PLAY starts or resumes the game, CONF is the options menu (currently no options menu, just enables or disables sound). LEFT and RIGHT to choose, A to select.

Tips

Momentum is both your friend and your enemy! It takes the ball awhile to reach maximum horizontal speed, so make sure you always do a run up for the big jumps! Additionally it takes the ball a long time to stop moving too! Make sure you apply opposite directional movement when trying to stop on small platforms!
Apply liberal use of DOWN/B! Not only does it slow your vertical height it also stop you horizontally too, making it useful for those tight landings as well.
Use A at the TOP of your jump for maximum height! Wait until the very last frame before you start to lose height on your jump to press A for best results.

Downloads

Download Sketch: Here. Written in VS2015.

Direct Hex Download: Here

Proton Simulator Windows Version: Here. Thanks to the awesome Proton Arduboy Simulator I’ve managed to hack together a windows lauchable version of the game for those without an Arduboy or who just want to quickly try it. It’s not perfect by any means, and has some graphical glitches, but it’s perfectly playable. To use open the zip folder and run “winArduboySim.exe”. Press IGNORE on the debug error then wait a LITERAL MINUTE and the game will open. MAKE SURE TO EITHER TURN THE SOUND OFF OR TURN THE VOLUME TO 5%, THE END LEVEL PORTAL IS VERY LOUD, TRUST ME. Use Arrows keys for D-PAD, CTRL for A and Z for B.

Level Editor: Not yet. I made a level editor/viewer in Unity to help me make the levels for the game by allowing me to visualise them easily. The actual levels use a very simple format, level objects are stored using 5 variables {X,Y,W,H,Type} so editing them is very easy. Once I have this tool working well enough for public release I’ll update it here if anyone wants to be creative but isn’t confident enough to make whole games (children maybe?)

Versions

(23/12/16) I’ve added an ending to the game now, which is level 14. I was planning on getting at least 15 levels but I feel this is the correct length now. I had to do a lot of squeezing to get this much done anyway :smiley:
(10/10/16) Back again a month later (sorry)! Level 13 was pretty tricky, it’s the biggest level (in ROM size) yet, just one or two more levels + an ending and I’m done!
(13/9/16 2) Level 12 is in, it’s pretty hard so good luck! I think I have enough ROM for 2 or 3 more levels, depending on how much the ending takes up.
(13/9/16) Fixed a lot of issues, game now has more sounds and fixed position of objects on a lot of levels. Will work on new levels now.
(12/9/16) Options Menu along with Save files are in, accessed by the CONF option in the main menu. Levels that have been beaten can be chosen in the level select menu and the PLAY button will reload your previous progress while your playing through the game (If you’ve beaten the game it will just load level 1 like normal). Game is version 0.9 now.
(9/9/16 2) Added new level, bringing us up to 11 total. Updated Github links accordingly.
(9/916) I’m calling this current version 0.8 as it’s almost done. The game is perfectly playable and there are currently 10 levels (you just fall into nothingness when you run out of levels). The TODO list has milestones for future versions and I’ll update this thread accordingly.

Todo

  • More levels (At least 15 total (currently at 13) for version 1.0)
  • An ending (Not just falling into nothing when you run out of levels)
  • Release level editor/viewer (Requires a lot of usability additions)
  • Music? (I’m no musician and not sure enough ROM will be left)

Eried's Unofficial Repo :)
Eried's Unofficial Repo :)
(Holmes) #2

Wow!! Awesome game! Can’t wait to install it!


(Scott) #3

I’d be interested in knowing exactly what the issue with using the Arduboy2 library is. The upcoming version of the official Arduboy library is going to be virtually identical to Arduboy2, so if there’s a problem we’d like to address it quickly.


#4

It’s probably not your fault and the result of some optimisations between versions. I tried to find the change that produced the problem by going through the Github changes list but I couldn’t identify it.

Basically I’m using arduboy.drawRect() for most of the objects in game, and it seems that when it’s called with coordinates that result in it being drawn off-screen (EG: At >128 X, or <0 X) it seems to result in the rect being drawn stretched across the whole screen and either lagging or crashing the game (probably because too many different objects drawn at once). This behaviour is the same in the Proton Simulator too (without lagging/crashing), but I found a partial fix by checking if I’m about to call drawRect() for a level object off-screen before I call it, however this doesn’t work for more complicated objects which have multiple drawRect() calls (Like button objects) because while some of the object is on screen some of still isn’t (because it’s smaller or further off the screen).

To be honest I just shouldn’t be lazy and call drawRect() for every object all the time even if it’s off-screen, but it’s still an issue for more complicated objects. I didn’t report anything because I thought it was just me doing something wrong as no one else has said anything.

Edit: On looking again my guess would be https://github.com/MLXXXp/Arduboy2/commit/6d13d7cb43649959075c2e00591648d3185b8b29 but I can’t see what would be wrong with it


(Scott) #5

Thanks for taking the time for your detailed description.

That change was made in the Arduboy library long before I forked it to create Arduboy2, so it’s slated to go into the next Arduboy library release. If I can find the time, I’ll look into it.

If anyone else wishes to look at the changes and identify the problem (if there is one) you’re welcome to have a go.

EDIT: I have a feeling the problem is with this block in drawFastHLine():

  // if our width is now negative, punt
  if (w <= 0) {
    return;
  }

It’s checking if w is negative but w is defined as a uint8_t, which is unsigned, so can never go negative! I think w has to be copied, or maybe just cast, to a signed int for manipulation and/or comparison. I may have a chance to sort this out later today.


#6

I just copied the changes made in that commit and applied them to my current Arduboy library and I got the bug, so I can confirm that’s the cause.

Makes sense I guess, instead of making it negative and then not rendering it, it just loops it to maximum-ish uint8 size and draws a massive line across the screen… No idea why it makes it crash though

EDIT: Changing it to int16_t w fixed the issue, not sure if there’s a better way but your right that’s definitely the cause.


(Scott) #7

The easy proper fix is to copy w to a local int16_t variable and then use that in place of w for the remainder. I’d like to see if it can be kept as an 8 bit variable, though.

If a line is drawn near the end of the screen and ends up writing pixels in RAM past the end of the screen buffer, it would clobber other variables in RAM which could result in a crash.


#8

I first tried a signed 8 bit but it still happened, I guess it’s over/underflowing, so then I tried 16 bit.

Ahh, explains why I got somewhat different crashes each time I messed with the level I was loading/the w variable.


(Scott) #9

I’m hoping it can be cast or copied as a signed 16 bit where necessary but then left as an 8 bit in the drawing loop.


#10

I’ve made a Pull Request with what I think is the changes you meant, if I understand what you mean by the drawing loop. I tested it and it worked fine.

Options Menu along with Save files are in, accessed by the CONF option in the main menu. Levels that have been beaten can be chosen in the level select menu and the PLAY button will reload your previous progress while your playing through the game (If you’ve beaten the game it will just load level 1 like normal). Game is version 0.9 now.


(Scott) #11

Yes, I’ve looked at it. Thanks.

I’ve written my own fix using a different method and need to determine if yours is better than mine to decide which to use.

Note that you’re using tab indenting and will need to change the tabs to spaces in order for the pull request to be accepted, if we decide to apply it.


(Andrew Dent) #12

Tabs versus Spaces? https://youtu.be/SsoOG6ZeyUI


(Scott) #13

(Scott) #14

@Joshimuz,
I’ve done a fair amount of testing, including looking at the code size produced with various sketches, and timings using an oscilloscope. I’ve found that my way of fixing the problem results in smaller code size and runs faster than yours. It’s actually smaller and faster than the code with the bug.

I’ve applied the fix to my Arduboy2 library and the develop branch of the Arduboy library.

Although it wasn’t used, the time you spent working on a fix and pull request is appreciated, as well as your help in determining the cause of the problem. :smile:


#15

Awesome, I’m glad the issue is fixed over anything else so it’s fine. Thanks a lot :smiley:


#16

Just as an update (sorry for the double post, I can’t find the edit button on my original post?) I’ve added an ending to the game now, which is level 14. I was planning on getting at least 15 levels but I feel this is the correct length now. I had to do a lot of squeezing to get this much done anyway :smiley:
The game now runs on the Arduboy2 Library, so I’ve removed the custom library included with the Sketch, I’ve also updated the Hex file to the finished version.
I might add one or two extra levels, but I’ll probably move on to my next project now that I have free time again.

Thanks, and hope you guys enjoy :smiley:


(Scott) #17

I added an update in the Versions section of your original post.


(Scott) #18

I don’t see any use of Arduboy2 in the code in the GitHub repository.


#19

It sure would help if I updated the GitHub repository with the current code then!

Also thanks for editing my post, I realise now that the post is just too old for me to edit.


(Scott) #20

The code for this sketch on GitHub, as of Dec 25 2016, will not compile when using Arduboy2 library V4.0.0 or higher, due SPI changes in the library.

I’ve opened and issue on GitHub with details on how to fix this.