SPower, there's nothing actually wrong with the material you've written (in fact it's nicely written) but: multi-threading is way, way harder than you might think. For simple examples, it's fine, but for anything more complex there are subtle issues that you need to be aware of. Although I can't see the source code for your scenario, I know it has a multi-threading bug: that is, it does something in a way that isn't thread-safe. Specifically, you shouldn't call Greenfoot API methods (particularly movement / collision checking) from another thread - because the Greenfoot API just isn't thread-safe. Now, it might [i]seem[/i] to work - but, if you run the scenario for a long time, or if you run it another computer, you might see an inexplicable failure which is due to internal data structures being corrupted, because they were accessed from two threads at the same time. Such problems are more common than you might think. In short, to save yourself from a world of pain with multi-threading, don't do it. If you want to see how complicated the code is to do correct multi-threading while using the Greenfoot API, you can have a look at one of my own scenarios: http://www.greenfoot.org/scenarios/1963

Mark, there are no bounds for the larger world - that is what makes it unbounded. The dimensions supplied to the World constructor do indeed specify the viewport size; the difference between a bounded and an unbounded world is just that the position of the actors within a bounded world is constrained to be within the viewport. To create the effect of moving the viewport around, you need to move all the actors within (and figure out some way to move the background, if you are using one. The easiest way is to draw the background with actors, rather than use a background image). There should be a few examples of that here on the greenfoot.org website, try a search or post in the forum.

Looks like you're removing the actor, and then checking for collision (which requires that the actor is still in the world). Change the order around so you check for collision first. Alternatively, search for the exception in the discussion forum - this is a common problem.

Yeah, it's really just meant as a demo, not a full game. The nice thing about is it properly calculates the angle that a ball would bounce if it hits a brick, even if it hits the corner. But, it's more here so that others can borrow the code if they want. I don't really have time to make it into a full game.

Ok, it's fixed! You may need to clear your Java file cache (http://www.java.com/en/download/help/plugin_cache.xml) before it works here on the gallery. And of course the problem will be present in exported scenarios, until the next Greenfoot release.