Paint order doesn't work for isometrics: you want to have some objects in front of a wall, and some behind, and then you want to have the objects switch layers later. Right now, the only way to do this is by re-adding EVERY object in the world over again in a different order. I am still looking into the world's code for class layering in hopes of maybe finding out how it works.

I had a thought regarding isometrics: I believe that a small re-write of the Greenfoot world code, or possibly just an extra addObject method with a layer parameter could work. Dunno, but maybe I'll look into it next week, when I have a little free time.

Nice! I was waiting for someone to finally get this idea working. My only complaint: off-screen objects do not receive input. I would suggest that this could be fixed by having a separate method that you use for the "act" method, and call this from the world, regardless of if the object is on the screen or not.

Right. The first thing you should know if you are going to make an Isometric game is that is is "impossible". Greenfoot does not support manual layering (mostly). The only way Greenfoot does it's layering right now is based on what order the units were added. What this means is that if you want your isometric terrain to hide stuff behind it, you will need to re-add your objects ~every act sequence. Now, the downside to this is that if the Greenfoot code changes the way it orders objects, your game would need _serious_ changes. However, I don't see this happening that soon, so I would say go ahead with it. The exact way to do all that is a bit complicated, but I could try and post an example sometime soon. There is a plus side though: Isometrics mean re-writing the code to the extent that a scrolling map is almost easier than a static one.

Hmm... Nice to see someone else follow up on the RTS genre. I like the resource collection design, and the construction too. I would suggest improving the pathing by either forcing the units to move directly to the target point, or by making the movement smoother in general. I haven't looked at the code, but my guess is that you are using a four way movement system. Bumping this up to eight way would smooth out a lot of the wrinkles. A piece of advice: If you aren't very artistic, get a friend to make images. Almost all mine were done by friends. I am interested to see how this turns out. Are you planning on doing isometrics? If you are, I could give you some tips based on another Greenfoot isometric I am doing. Also, are you going to try for a scrolling world? I have thought some about it for my own RTS, and was forced to give it up for time and speed constraints, but I could give you some tips on that too.

Ah, Z-buffer! This works something along the lines I thought it would. The only way that you can get the Z-buffer to work in all cases though is to force the render engine to go pixel by pixel. Greenfoot (and maybe Java) is just too slow to do that kind of math. Too busy to make the next move, lol. Right now I am working on the networked version of Realm of Battle and a "sequel" to it, a Blender based RTS, in addition to schoolwork. Too much work! Maybe once I have some free time I will get my shaders up and working. And cool new models.

Real render and Quick render are toggled between by pressing "p" and "r" The keyboard controls are only for real render mode. The preset is quick render. Even when you do go to the real render though, the keyboard controls will be laggy. Unfortunately, there really isn't anything I can do about this. The plan is to position the camera in quick mode and then render for real, with lighting & shading + textures(maybe). I also plan to make an editor with an exporter/importer that could work alongside Blender (I already have an import-export script that uses the data that this simulation works off)