iOS Will massive rooms cause performance issues?

[starblinky]

Im making a runner game. Its not an endless runner but the rooms will end up being pretty huge.


Id like to have the player object move forwards and have the camera follow him, as apposed to the player object remain in one spot and the entire level move past him... so I’d have to make the rooms really large.


If I had a room thats say 9999999 in width, is this going to cause memory or performance issues?


Should I just have the player object stay still and move the entire level past him?


The player will need to eventually back track back to the very beginning.

 

[Dog Slobber]

Typically a massive room does not cause performance issues.

However the larger the room, often the larger the room, the more objects, tiles and background graphics. And a lot of those, especially object instances with code and collision testing will cause terrible performance.

 

[devonhg]

I remember years ago I was working on a game with large rooms, and I found this worked particularly well.

Basically, all objects, except for controllers and the player, were deactivated by default. As soon as the player got within range however the objects would re-activate, and then deactivate themselves once the player was back out of range of them.

This allowed me to make a huge room with very little hits to my performance.

More specifically, the "instance deactivate region" was the function that made this possible, but you can read more about it in the docs.

 

[starblinky]

I remember years ago I was working on a game with large rooms, and I found this worked particularly well.

Basically, all objects, except for controllers and the player, were deactivated by default. As soon as the player got within range however the objects would re-activate, and then deactivate themselves once the player was back out of range of them.

This allowed me to make a huge room with very little hits to my performance.

More specifically, the "instance deactivate region" was the function that made this possible, but you can read more about it in the docs.

Hey dude, thanks for the info. This really helps a lot.


Been really frustrating trying to figure out how the camera would work. Im really grateful for the help

 

[Nocturne]

You should note that in general, the idea of a room size is simply a convention used to help design the rooms in the editor. At run time, it's really just an abstract value that has no bearing on the actual game, since you can still move the view outside the room and draw and have instances too.

 

[AdamJ]

If I had a room thats say 9999999 in width, is this going to cause memory or performance issues?

Should I just have the player object stay still and move the entire level past him?

The game I'm working on at the moment has a single enormously long room to give a similar effect of continuity. Any performance issues I hit - and they are few - are due to the number of objects that are active rather than the room size, so I do something similar to what devonhq describes and deactivate any objects that are outside of the camera. I attach the camera to the player and move the player through the room, rather than the complexities of moving the level.

It is working very well - I get the continuity I need (much like what you would want for an endless runner), with good performance.

 

[FrostyCat]

While large room sizes like this aren't directly indicative of poor performance, it is often indicative of inexperience in visual sleight-of-hands used in game development. That can lead to naive designs causing poor performance or infeasible situations later.

The classic example of this is the endless runner. Rookies get fooled by the glitz and insist on rooms with infinite or exceedingly large size for the character to move through. Experienced developers know that the room remains screen-sized and the background plays on a treadmill the whole time.