The line where things crash is on the resource load, which kind of makes sense since the gif didn't arrive with the download, afaik.

There's lots of unused methods as well. Maybe you are withholding parts of the code, and this is a simplification?

++++++++++++++++++++++++++

The main thing that jumps out at me is that it is unusual to see so much work done within a paint() method. Most folks separate the game logic from the drawing. Thus new positions and sizes would all be worked out prior to the draw call.

There are also what seem to be a few redundant calculations here and there. For example, in the calculation of new positions, I assume screen.height & .width don't vary during the course of the game, yet you are adding constants to them within a loop. Since you get the same result every time, why not just do it once?

There is a lot of discussion here about "the best" way to time game loops, and whether to use passive or active rendering. I will leave that to the more experienced!

Getting a working version up as an Applet will go a long way towards eliciting more feedback, as well.

Also, we are not here/don't have the time to look through all your code and point out every error and bad coding you might have done. If you have specific questions, we will answer them to the best of our knowledge.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org