Perhaps the lin / rot switch toggling could be improved (so it just changes at every key press rather than while the key is down) but yup it's great! With the increasing number of scenarios like this perhaps the "two-dimensional" bit on the gallery homepage is a bit too specific now :P

...Not to be a nay-sayer, but this really isn't that different from the Castle Storm scenario. Technically, this is only 2.5D, since there is no width to anything. From what I've done on this, true 3D is possible, but I do not think Greenfoot/Java is fast enough to do anything with it. The best looking approach though seems to be mutantleg's Terrain scenario. Still, nice way to improve on the other methods!

Thanks for the kudos. It's not exactly "Orbiter" (http://orbit.medphys.ucl.ac.uk/orbit.html it's free!), nor will it ever be for reasons I think Zerg understands. However, I think Greenfoot is about principles and education, not high-end entertainment - so 2.5-D is getting at the basics and may whet the appetite for those who want to explore Java3D, DirectX, etc.. I started out programming games and simulations (long ago ;-) because it could get me deeper into computer tech and programming than doing business apps, database stuff, etc. that I don't care for very much. So, I believe in starting students on games - the sky is not the limit ;-) I haven't spent a lot of time on the interface yet, but as an Orbiter fan, it may go that way - just to see what it can do. Go for it qnanqing - you do good work! My son has been bugging me to put shooting in it. Almost everything he write is a shooter game - or wants to be! Don't know what mouse-look is. I think I'll learn a lot in this forum. One more thing - to "depth charge" a 2.5-D to 3-D requires a 3-D object mapping, like a u-v surface. That can be done in Blender (a free 3-D CAD-like tool). However, (and I'm no expert) that's where Java3D and DirectX etc. excel. In Greenfoot, you'd have to redraw and setImage() every act() on potentially hundreds of objects. In "Feeding Frenzy", my dual-core computer slowed down considerably when more than 250 or so fish were doing somewhat less than that and stopped for periods of time loading 100 or so "pop" sounds for each explosion when the bubbles reached the surface. Maybe a Greenfoot developer could forecast what the bottlenecks might be for pushing the limits with drawing graphics. Smaller images seem to take much less time.

Mouse-look=the code that allows the mouse to change the rotation. It's something I learned making FPS games with Blender, actually. And I did actually write the code for a rendering engine in Greenfoot a while back. I'll see if I can find it, but it is extremely, painfully slow. Something to do with Greenfoot not being able to solve 8000+ simultaneous linear equations every act() very quickly :P But I will definitely look for my old code or re-write for the benefit of those who want "true 3D"

You can now right-click and point your mouse in the direction you want to go. Right-click again to turn the mouse off. I don't think this is what Zerg had in mind by Mouse-look, but it beats holding the arrow keys down to do a complete circle. = or + will accelerate forward, - decelerates, 0 stops forward motion (non-RCS motion). RCS is reaction control system - that's attitude control, not propulsion. I added simple indicators for attitude and position. Click the RCS mode indictor (Lin / Rot) to change RCS mode. Read the project ReadMe.txt file for details and new things I forgot about. My son added shooting to his copy, so that may make it into the next update. I lasers are being used for navigation now, so adding a more powerful mode to clear space debris may not be beyond resonable developments.