[Request] Not Saving the layout size

Discussion and feedback on Construct 2

Post » Sat Feb 28, 2015 1:31 pm

Hello,

I'm using the save/load feature in my game.
We can 'tag' the objetcs you don't want to save with the NoSave behavior.

But I've bump into a little issue and was wondering if there was a trick or something to avoid that.

When you 'save' the game, it seems it also keep in the save the size of the layouts. I find no way to avoid that.
Why is it an issue?
Well let's imagine a scenario :

-You realease a game using the save/load feature
-Players play it and save their game
-You want to update the game to add new stuff or fix things
-In the update, you decided to make a room bigger with more bonus because it was good for the game balancing
-Players get the update, load their game
-They get stuck with the old layout size (the camera don't go further)
-They have to restart a new game to get the changes

So is it important to save that layout size info in the save feature?
Perhaps there's a way to avoid that?
B
65
S
19
G
12
Posts: 314
Reputation: 11,736

Post » Sat Feb 28, 2015 2:04 pm

I don't use the built-in save feature so I can't help you much there...However, you're generally better off not using the layout size at all - instead use a 9-patch or something to define the size and shape of the layout, use clamp() to keep scrollx/y within its boundaries, and enable unbounded scrolling. I guess you'd have to use the no save behavior with it too.

In the future you might consider using dictionaries/arrays to manage save data instead - you have far more control with them.

edit: Maybe you can place an object in each layout with 2 variables containing the width & height of the layout, give it the no save behavior, and set the layout size to them when needed. If you adjust the layout size later in development you'd also update these object's variables. *shrug*
Image
B
231
S
27
G
13
Posts: 1,782
Reputation: 18,195

Post » Sat Feb 28, 2015 2:15 pm

I agree with @KaMiZoTo , it would be nice to have, not using features because they are not working as intended is not something people should do.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
43
S
18
G
18
Posts: 2,106
Reputation: 16,436

Post » Sat Feb 28, 2015 2:16 pm

The save feature by design saves everything. I'm sure someone has an opposite use case where it is important to save the layout size.

One workaround would be to enable unbounded scrolling and implement the scroll bounds through event logic.
Scirra Founder
B
373
S
218
G
84
Posts: 23,525
Reputation: 186,342

Post » Sat Feb 28, 2015 2:48 pm

Thanx all for your answers.

@Tokinsom Yeah I know I shouldn't use the save/load feature. It's dangerous when you want to make modifications. But my coding knowledge makes me very very unconfortable with dictionaries and arrays... I really will have to face that on day.
Until then, I will give a try with your variable trick. It should be easy to do. Thanx. :)
B
65
S
19
G
12
Posts: 314
Reputation: 11,736

Post » Sun Mar 01, 2015 9:58 pm

@Tokinsom Well, it seems we can't change the layout size in runtime. :/
B
65
S
19
G
12
Posts: 314
Reputation: 11,736

Post » Mon Mar 02, 2015 1:02 am

Ah, forgot about that. I'd request it or just start using your own "layout zones" with 9-patches as I mentioned earlier.
Image
B
231
S
27
G
13
Posts: 1,782
Reputation: 18,195


Return to Construct 2 General

Who is online

Users browsing this forum: Yahoo [Bot] and 4 guests