How do I do a game in a Sandbox way

Is it possible, in construct 2, to make everything in 1 layout and turn the game a sandbox game?Cause I really don't like to see a loading screen in a survival game. Doesn't fit at all, in my opinion.

Also, making the map design based on sprites to make them more beautiful would be too heavy when I reach hundreds of maps putted side by side?cause 64x64 tiles just don't let you be creative to create maps. Perhaps, creating a big sprite of a map and then cutting in pieces?

Also I think there's a bug with tiles BG, because, by just walking, a line on top appears and disappears like if it had a pixel in the image, but there is not.

Where do you got the 64x64 limit from?

Where do you got the 64x64 limit from?

I didn't say it's a limit, but recommended for a better performance, you know?

If you could provide some .capx with the problems in notes. But I think you could do some 2 layout game, I'll try to simplify for you.

For not having "Lags" or Loading Screens, you could put a Layout as a repository, then, load only the first layout, leaving all the future Objects in the other, then, when the objects are going to spawn, put the browser to download them (or entire families) then create them.

You also could put some "Demo Introductory" layout when the other is downloading background, after downloaded, the guy could play.

I think the number 2 is better, since it requires no heavy and brute code.

If you could provide some .capx with the problems in notes. But I think you could do some 2 layout game, I'll try to simplify for you.

For not having "Lags" or Loading Screens, you could put a Layout as a repository, then, load only the first layout, leaving all the future Objects in the other, then, when the objects are going to spawn, put the browser to download them (or entire families) then create them.

You also could put some "Demo Introductory" layout when the other is downloading background, after downloaded, the guy could play.

I think the number 2 is better, since it requires no heavy and brute code.

I don't think it's gonna work, since i'm not repeating small tiles to fill the layout. Just imagine a bunch of images that fills a 50000 width, or probably larger, of the the entire game. I think that's insane and that's why my idea of a sandbox using more sprites maps than small tiles wouldn't work very well. In my opinion, even setting everything that is outside of the layout as invisible would run properly, since I can't destroy.

PS. I'm doing a game for desktop, which will have an EXE file to install the game, like the other games.

PS2. I'm planning to make a game with a enormous map... A complete game, not just a quick browser game.

— anyway, the computer doesn't understand that something is on screen or not, it just render everything and move the screen.

I've experienced a problem with Multimedia Fusion 2, the game was 30000 x 30000, after the 12000 it got completely laggy, and I'd to do something like rendering.

I don't know if you are going to experience that, but, if you do, do like I said.

GTA V is a great example, the render in that game is fantastic, you can see far away and the detail/distance is perfect. Rockstar is a great developer.

About the Map

I recommend not making one massive png map. Splitting them into separate png files might work. Then just create the png object when the player becomes within a range that implies that they'll likely interact with that area. This means, not actually loading the image in until they become within a reasonable range.

This is because the engine will constantly be trying to understanding where objects are, what the object is, what the object has, and what the object is doing. This can be taxing on the cpu. This is especially the case if the object is doing events. For example, if you have NPC's walking around and talking while and you have 50 of them- that alone can take cpu even when they're nowhere near the player.

About Culling

Think about culling methods. If you measure distance to a blank sprite off in the distance you could trigger a function that creates more of the map at a certain location.

Unity does a good job explaining two types of culling in the first paragraph here (quoted below)

"Occlusion Culling is a feature that disables rendering of objects when they are not currently seen by the camera because they are obscured by other objects. This does not happen automatically in 3D computer graphics since most of the time objects farthest away from the camera are drawn first and closer objects are drawn over the top of them (this is called "overdraw"). Occlusion Culling is different from Frustum Culling. Frustum Culling only disables the renderers for objects that are outside the camera's viewing area but does not disable anything hidden from view by overdraw. Note that when you use Occlusion Culling you will still benefit from Frustum Culling."

Occlusion Culling stops rendering objects that are blocked from view.

-> Think of objects inside a building

Frustum Culling stops rendering objects that are outside (too distant from) the camera's view.

-> Think of objects thousands of pixels away

Culling in this case would be destroying objects, closing related groups and so on. You want objects and events only bother the cpu when they absolutely need to. Even if you want NPC's moving dynamically you can have NPC's walk around for a little while when they're too far away from the player. Then when the player returns just have the NPC resume movement or randomly created in select set location that are not too close to the player. This way it looks like the NPC was moving while the player was gone. Illusions =]

Start Small; Build Inside; Build Outwards

Creating a big map straight away will make it hard to impossible to apply logical methods. It will become very difficult to debug. You wont be able to pinpoint the direct cause of issues and finding a solution will become too time consuming. Create a few things you want in your sandbox and test them. Try putting in some culling methods, even when the culling is only 100 pixels away. This way you know that it works.

Populate your small map with the things you have in-mind. This way you get a handle on everything on a small scale. You'll be able to visualize and understand what you're working with. Then, branch outwards. Take what you've created and learned from the small map and replicate it. Use what you've already perfected and understood to branch out from the small playground area to a larger- and larger sandbox map.

I hope that answered your question a least a little bit.

~ Good Luck, Kossglobal

About the Map

I recommend not making one massive png map. Splitting them into separate png files might work. Then just create the png object when the player becomes within a range that implies that they'll likely interact with that area. This means, not actually loading the image in until they become within a reasonable range.

This is because the engine will constantly be trying to understanding where objects are, what the object is, what the object has, and what the object is doing. This can be taxing on the cpu. This is especially the case if the object is doing events. For example, if you have NPC's walking around and talking while and you have 50 of them- that alone can take cpu even when they're nowhere near the player.

About Culling

Think about culling methods. If you measure distance to a blank sprite off in the distance you could trigger a function that creates more of the map at a certain location.

Unity does a good job explaining two types of culling in the first paragraph (quoted below)

"Occlusion Culling is a feature that disables rendering of objects when they are not currently seen by the camera because they are obscured by other objects. This does not happen automatically in 3D computer graphics since most of the time objects farthest away from the camera are drawn first and closer objects are drawn over the top of them (this is called "overdraw"). Occlusion Culling is different from Frustum Culling. Frustum Culling only disables the renderers for objects that are outside the camera's viewing area but does not disable anything hidden from view by overdraw. Note that when you use Occlusion Culling you will still benefit from Frustum Culling."

Occlusion Culling stops rendering objects that are blocked from view.

-> Think of objects inside a building

Frustum Culling stops rendering objects that are outside (too distant from) the camera's view.

-> Think of objects thousands of pixels away

Culling in this case would be destroying objects, closing related groups and so on. You want objects and events only bother the cpu when they absolutely need to. Even if you want NPC's moving dynamically you can have NPC's walk around for a little while when they're too far away from the player. Then when the player returns just have the NPC resume movement or randomly created in select set location that are not too close to the player. This way it looks like the NPC was moving while the player was gone. Illusions =]

Start Small; Build Inside; Build Outwards

Creating a big map straight away will make it hard to impossible to apply logical methods. It will become very difficult to debug. You wont be able to pinpoint the direct cause of issues and finding a solution will become too time consuming. Create a few things you want in your sandbox and test them. Try putting in some culling methods, even when the culling is only 100 pixels away. This way you know that it works.

Populate your small map with the things you have in-mind. This way you get a handle on everything on a small scale. You'll be able to visualize and understand what you're working with. Then, branch outwards. Take what you've created and learned from the small map and replicate it. Use what you've already perfected and understood to branch out from the small playground area to a larger- and larger sandbox map.

I hope that answered your question a least a little bit.

~ Good Luck, Kossglobal

Wow!Thank you!

It helped a lot. Obviously, as a new C2 user, I don't have in mind everything you've said, but conceptually it helped so much to visualize what I should do to reach a really serious sandbox game.

Here are what I've understood:

So, basically, I can do an 1 layout game with the right events. Which means that I should destroy or set invisible everything that is outside of my range of view, right?So it doesn't consume too much from Pc performance?In other words, I must say to C2 that everything that is outside of the screen must be invisible?

Another idea that I've had is: Shouldn't I build the game in different layouts and spawn the objects in the left or in the right to continue the map as the player walk?

—

When it comes to invisibility it stops the need for draw calls. Plus an object outside the screen might automatically become invisible but, I'm not sure. A single draw call consists of something being drawn to the screen. (Note: A single object can require multiple draw calls). Just know that something being invisible stops its draw calls but doesn't stop it from existing.

This is important because you can turn an entire game invisible but everything still exists in the layout. Everything is still being calculated and is still utilizing the Construct 2 event sheet where applicable. Destroying an object stops it from existing in the layout. Thus, the CPU doesn't need to spend time dealing with that object (the object is just held in memory allowing you to create it again).

When it comes to different layouts I found myself preferring multiple layouts. The problem with one single layout is it can get stressful to stay organized as time progresses. You can end up having too many layers and tons of event sheets that become confusing.

You are creating a sandbox game. The definition of Sandbox Game surely can differ from person to person. However, Sandbox =/= (doesn't equal) Seamless World. A seamless world is a world the gives the illusion of no loading. You can still put loading screens into your sandbox game.

Let's say you do want to keep the seamless world though. Well, having multiple layouts "next to each other" and making it seem seamless can be difficult. Since the layouts are not literally next to each other. I can foresee some development headaches with trying to make it look seamless. Imagine NPC's and other objects in the camera when you cross over layouts. Making it smooth and without bugs, potentially more trouble than it's worth (worth to you, and the players)

I wont attempt to hinder any creative vision of another. I will suggest that you consider staying with the Sandbox Game idea if that's truly what you want. Just further consider removing the seamless world idea. Instead of that try to implement short (~1-3 second loading screens). The player can still get the idea of a large living world without the game being seamless. That's the enjoyment of game design. You don't have to stick with a method because it works (seamless worlds) especially if it's overly complicated. Just find a way that's less likely to cause problems and make that work for you.

Index

You were a big help for me. I really appreciate.

I am leaving the idea of 1 layout game. I'll try build the ilusion of a seamless world, though. Perhaps creating a map that continue the idea of an ambient, but not exactly a continuity of the map. Regarding to the loading screen, I'll think about a less perceptible way as possible to make these transitions.