Um...the walls kind of have to move for the concept of the game to work.
Unless...
I don't plan on making the actual walls to move, it would kind of be overkill.
Just the holes.
Making the balls collide with each other would probably seriously slow down the gameplay, think about the amount of times it would have to draw each frame to pxl-Test them all...especially when the person starts getting to 10-something balls.

The way axe always rounds down is killing me with the bar on top now...time for me to learn the floating-point or whatever it is

I've kind of made a sort of universal menu in a subroutine so I don't have to code the same menu 5-10 times
It's in the Axe parser thread.
I'm working on options, which will have to involve an appvar or SMC.  And that kind of stuff can get complicated really fast if you don't plan ahead of time and know exactly what you want to add before you add it...

this looks really cool so far, dude!  keep up the great work on this!

I'll probably make it slower, and the player can select the speed to go at through the Options menu.  Normal speed="fast"
Full isn't ruled out yet either...

Unfortunately, I may end up having to take out the bar altogether because as of yet I can't think of a good way (read: easy) to implement them in the ideas (mockups above)

Most of the time, I prefer to do small updates so if people want something in particular the development can kind of swerve from one thing to another, but it looks like I won't be able to do much of that on this, so, big updates

On a different note, what would people like to see in the options menu?  So far I have speed, initial # of balls, # balls added each game, and amount of types of balls (2-4 planned)...maybe "difficulties" which set all the options to different levels...
Anything else?

Ball collision between each others migth be kinda hard to implement for the ones that are not black. I worry about the amount of pxl-test detection that would be needed for white balls.

Anyway keep up the good work!