Need help with the programming / theory of 2D stage development

Not sure if this is better suited for this forum or the scripting one, but here goes...

I'm brand new to game dev / Unity as of 4.3. I've been working on a 2D platformer / runner using a grid system and so far all of my pieces are working very nicely. However, I can only make stages that are about 30 seconds long before I run into some framerate issues.

Now, my laptop I'm developing on is a bit old and not a gaming laptop, so I'm sure that is a big factor in the framerate. However, it generally can run 2D sprite-based platformers without issues, and I'm not doing anything particularly intensive with my game (I don't think...) So obviously something is wrong with the way I'm doing things if I'm getting framerate issues already.

On the scripting side there is probably a bit I could do to get some of the processing of some of my more intensive pieces down. I may have overused the Update function a wee bit. That's what I'm going to be looking into over the next few days.

However, what I'm looking for advice in here is more along the lines of how people handle dealing with entire stages in 2D games? I know there is no one answer, but I'm looking for some kind of consensus.

The way I see it there are probably a variety of approaches:

A. Build an entire stage in the editor, have everything in it running the entire time (what I'm doing right now.) This has to be a terrible idea, right?

B. Build an entire stage in the editor, "turn off" the scripts on a bunch of your pieces and only turn them on when you need them, then turn them off again when you don't need them

C. Something similar to B, except don't even place the pieces in the editor, just spawn them in when you need them and kill them off when you no longer need them

D. Some combination of the above

I got this idea to maybe create a sort of "core" stage in the editor with "simple" pieces (plain ground, etc.) that are always on, place other more intensive environmental pieces (quicksand, moving platforms, etc.) but keep their scripting off until they're close, and then for enemies and other stuff like that where I'm not as concerned about pixel-precision placement just spawn them on the fly maybe? All of this would be calculated based off of I dunno... some distance from the player that would active this stuff right before the camera hits it. Or maybe I can just use some distance from what is currently displayed on-screen based off of the camera or something?

I read somewhere that this is how Unity handles graphics rendering? Only rendering the stuff that will appear on screen at any given moment? So basically I'm trying to apply that theory to scripting and such as well?

Am I along the right track here or way off?

Thanks in advance for all of the help! Game development is so exciting! But sometimes confusing!

 

You're definitely on the right track. The general idea you're referring to is called "culling" (aka deactivating things that are off screen in order to improve performance). The most important question is... Are you using physics in your game? Physics is a performance hit, and therefore needs special care. For a small game with very few gameobjects (or rigidbodies) present, you can actually get away with your approach in A. For larger games you need to definitely start thinking about some of the other approaches you mentioned. Note in a physics based game it is a good idea to have a given level in your game limit the number of active rigid bodies to be less than 100 active rigid bodies.