Mathew wrote:Very interesting, but could you please post this image with higher resolution? Because I can hardly see anything even with big enlargement, thanks.
I scaled the image to hide an important part of my generic agent routine
. Is this quick example of a sub-routine good enough?
This example isn't very practical, but I think it gets the point across. It starts at "Is Player near?".
Mathew wrote:I had many ideas about how to do it so far, for example limit every level to have only one monster of each type and simply moving those monsters to next positions (and disabling player to go back [left direction])
I think you're on the right track... It really depends on how much time and work you're willing to put into it. I'd suggest using a dynamic level unloader/loader that utilizes object pools. Objects that are far off-screen can be recycled for use in the about-to-be-shown parts of the level. As for physics, the level loader can do something similar. This approach would allow the player to go backward through the level without having too much of a performance loss. I'm unsure about how much processor would be encountered by attaching/detaching several objects each frame, but I'm betting that it would be negligible.
On top of the level loader, and even if you don't use a level loader, make sure to cull off-screen objects. It's as simple as running a for-loop to check every sprite in the scene, but it makes gigantic levels possible. I had an unreleased project called SpyTower that experienced a lot of lag when it came to large levels. The previous game engines that I've used culled automatically so I didn't even think about it being a problem. The fps maxed out after I implemented simple culling.
Don't limit the monsters. If you use a pool, then it should really only matter during initial level loading, but I think the benefit of having multiple monsters in a level makes even an initial load-time worth it.
Take my advice lightly - it's far from perfect and I often overlook obvious solutions. Having said that, here's how I'd set up your game...
Have a sprite manager that creates pools of textures. The textures should be assigned an ID number.
Have filler-entities that just hold the position of where you want sprites. They would be nothing more than 4 floats (x,y,rotation,scale) and an integer (texture ID number). You can always add more variables if needed for some reason.
Use an extended-scene class that contains an update thread to handle the placement/visibility of sprites to the filler-entities.
Do something for the physics similar to the sprites. You can even use the placement/visibility portion of the scene to apply the physics bodies.
I'm sure that I missed something, but I hope you get the idea that I'm trying to convey. There's no sense in limiting the number of on-screen physics objects if that's what you need. I guess my solution is just about making the graphics perform well to make up for the physics.
If I confused you, let me know. I think I confused myself.