Maximum Size of Scene?
dustingriffie
Member Posts: 57
I am wanting to make a quite large 'open' world type game, limiting the time in between going to new areas. My question is, at what point is performance altered because of the size of the scene?
Comments
I just set a scene to 568000 x 320000 and it doesn't seem to affect performance.
My guess is that it's not the size of scene that will affect performance but it'll depend on how many actors you have going on that will affect performance.
I had a static scene, no scrolling and in my actors (bugs) I had them loop through a table of coordinates that specified a polygon drawn by the user. and i can see the game slow down as more actors (bugs) entered the scene. So i think it's all depends on number of actors and the number of rules inside each actor that will affect performance.
Okay, I think I will base how they spawn based on the players location. So if the player is near, spawn the buildings or whatever.
That's always a good route to take - only have the actors that are in-camera active, so rather than having a massive scene with lots of things spinning and animating and spawning and flashing on and off (etc etc), only allow those things within range to do their thing, with everything else out of range switched off.
Also like @tintran says, you can pretty much make the scene as large as you like, a 50 billion by 50 billion pixel scene (seriously, 50,000,000,000 !!!) is no problem for GameSalad.
That's good to know, not that i could ever fill a world that big..but any game that can fill that much detail deserves attention or trying out.
Is there a simple way to do this? I know if they are visible by camera, spawn actor at location, but what is the logic behind being visible by the camera?
Yeah, it's a little bit big !
A game like would have to play to its strengths, for example spawn a golden egg somewhere in the 50bn x 50bn scene - and have the player search for it !
that would just be a mean game, with no compass? even with a compass, you'd have to spend quite some time to get to the egg i wonder if i could do it in one sitting ..might need save points along the long journey.
which made me wonder if agar.io was built like that and then put players in close to each other, because from what i remember when i tried the game, i was unable to reach the edge, if there was ever one.
that number is even bigger than i thought, if your hero traveled at 1000pps it'd take you like just under 2 years to travel from one side to the other. Man, that game would be a real adventure if it's ever filled in with details.
Player = the moving player.
Obstacle = the piece of scene furniture that is asleep until in range.
You can do this in lots of different ways . . . magnitude is one obvious one, the magnitude between the obstacle and the player is measured with the magnitude function - and if less than X (you decide) then it comes to life.
Example, you have a spinning windmill, and rather than having it spinning throughout the whole game, even when it cannot be seen (along with dozens of other actors using up processor cycles when they also cannot be seen, you would say (in the obstacle actor's rules) . . .
When [numeric expression] magnitude (player x - obstacle x, player y - obstacle y) is less than 600
--then play spinning windmill animation.
So when the player gets within 600 pixels of the windmill it starts animating, otherwise it's dormant.
Another way would be to constrain a large (invisible) rectangle (let's call it RangeDetector) to the player (who I assume is controlling the camera) . . . then in the windmill actor . .
When this actor collides with RangeDetector
----then play spinning windmill animation.
You would probably want to make the rectangle slightly bigger than the camera size, as you want actors to come to life just before they are within sight of the camera, otherwise you will get things popping into life at the edges of the camera.
There are edges to agar.io. It is a large area but it is confined to a certain area.
Thank you very much! I thought of the second route but wasn't sure how efficient that would be. You are very helpful, just reading your comments around have helped me significantly
Of course !
No compass, just silence and a black screen 
That of course is another option, it's fairly easy to make a limitless game, with no edges, a game that just goes on forever.
It'd make a great arcade game, put £1$1€1 in the slot and sped 5 minutes travelling through a black landscape.
A game sure to revolutionize the gaming industry haha
I tried to make this, and GS happily accepted a 50b x 50b scene. However, I can't spawn the egg in a range greater than 19b x 19b. I don't know if the scene isn't as big as it says it is, or if the spawning of the egg just tops out (the latter I think). Either way, what's the point if it's only 19b. @tintran will find that way too quickly.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
ahaha you actually tried? that's great...I wonder if 19billion is an number limit in Lua. seems small.
Was curious about how large this area is ...if 30pixels is a cm, 50b x 50b pixels would have an area of just over 50% of the area of planet earth.
I think the second route would be more efficient.
Let's imagine we have 120 actors in our big scene - with the magnitude function, then on every cycle of the code each actor has to make the magnitude calculation (is magnitude (player x - me x, player y - me y) less than 600 ?) - so that's 120 mag calculations every 60th of second . . . . of course if the rules (which are switched off until in range) were more taxing (let's imagine a whole bunch of complex rules and timers and animations and so on) then you are still making a saving in processor drain - as the mag function is less taxing than the actual rules.
So one thing you wouldn't want to do would be to use the magnitude function to switch on and off a rule that is less taxing that the magnitude function - for example you might have a simple rotate rule or a colour change in a timer that changes colour every 2 seconds, you would be better off leaving this running (even when out of sight) rather than having the same actor run a magnitude function on every code cycle (assuming the mag function is more taxing than whatever rules it is preventing from running). But of course complex rules (an actor being constrained to a number of values while flashing and spinning and displaying a custom score with a glow effect whilst bouncing up and down !!) would benefit from being - temporarily - replaced with a single magnitude check.
But, having said all that, why have 120 mag rules, all being calculated every single cycle, when you could have 1 rule (placed in a large, camera sized, rectangle - stuck to the front of the camera) . . . and in addition the magnitude function will detect in a circle, whereas a rectangle glued to the camera can be the same shape as your visible scene (rectangle).
So, each method probably has its uses, they both have their advantages / disadvantages.
Okay now I want to finish making this again.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Agreed, 19bn x 19bn is much too small, not enough room for all the ads I had planned to plaster all over it.
Hmmmm, too small, probably just separate the whole game into levels, make each level 10bn px wide, when you reach the edge you go up to level 2 (of 1bn levels).
If the game is not just black screen, it would required probably hundreds of thousands of level designers or maybe more just dividing it and managing would be headache. and whoever finishs the game will get a prize... a real 100% golden egg.
You could generate the levels procedurally, a few simple rules could populate the entire space.
Yeah generating levels procedurally is a little over my head.
This is good news though, when i make my endless runner i am not limited by width of scene. I can make it really long.