removing objects when off-screen

So I’m making a little side-scrolling platformer in Java right now as some practice. I generate my levels from text files with different numbers signifying different types of blocks and objects in the game world, as I often see people do on the internet. My problem is that when I start the game, all individual walls and other objects are all created at the same time in an arraylist. If my levels were to get much larger than they currently are, I can see having thousands of instances of the same object existing off-screen would be very inefficient. It would be preferable if I could only create blocks and enemies at a certain distance away from the player as it approaches them, and when they exceed that distance, they would be removed from the arraylist. I’ve been able to remove the objects when they go off screen so far, but not re-draw them again. So this leads me to my question: How would I go about creating only the objects that I need on the fly rather than creating them all at once when the game starts up like I’m currently doing. If anyone needs to see any code, that’s cool, I can show, or if you wanna just give me a short explanation, that’s fine too. Any help would be greatly appreciated!

Also if any of my Java jargon is incorrect above, please correct me! I’m still quite a novice! ;D

Perhaps you could break your level up into segments, instead of one large file? Then you only have to load the segment that the player is in, and perhaps immediately in front & behind of the player. As the player moves, reload the required segments. Theoretically you could have limitless level size with this method (notwithstanding hardware limitations!).

nerb.

Wow that’s a pretty great idea! Much simpler than anything I was thinking of. I could see the amount of files getting out of hand if the game’s size (in terms of content) were to increase dramatically, but I definitely will consider this! Thanks!

Add this code to every object which can go left the screen in their update code.


public void update()
{
    if (x <= -tileWidth)
        destroy();
}

That is when each object moves out of screen from left, we destroy them.

Yeah, I’ve actually got this figured out. What I need to know is how to recreate those objects if the player were to go backwards without re-drawing every single object that is already on the screen. :-\

What I’ve understood is you are trying to draw the objects that are only visible. If so, make a rectangle that fit’s the screen. When rendering objects, test whether the object intersects with the screen rectangle and render the objects that lie on the visible part of screen. This way, you can only render objects that are on the screen.

Load the entire level all at once. It will fit in memory unless your game is much, much bigger than I imagine it is. 1000 blocks should be around the order of several kilobytes. A megabyte is 1000 times larger than that and a gigabyte of RAM is 1000 megabytes of RAM. Collision detection and drawing will be the problem if you try to do it all at once. (Especially since collision detection could be O(n^2).) To narrow down the number of items to visible and nearby items, test if each items AABB overlaps a rectangle slightly larger than the visible area of the level. Items won’t need to be discarded until the end of the level. You can leave them wherever they are when they go outside the rectangle or reset their position to where they started. You could sort items by their x position or divide the level into grids/chunks, but it might not matter. (Awesome name btw.)

Alright thanks, I really wasn’t sure if this was a bad practice or not, but my game probably will not ever get very large.

I’m sorry, but I’m not familiar with the term AABB. Could I get a quick explanation or something?

Thanks!

AABB = Axis Aligned Bounding Box

Easy system to implement, because each box just has a x/y and width/height and you just check those things
x and x+width, y and y+height to the others and make sure they aren’t overlapping/intersecting.

Basically rectangles that can’t be rotated. ;D

Ah! Seems simple enough! This is what I was planning on doing anyway, just didn’t know it was named that. Thanks!