[Request] Not Saving the layout size

0 favourites
  • 7 posts
From the Asset Store
220 Food Sprites in 16x16 pixel size. Perfect for items for a retro style game.
  • 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?

  • 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*

  • 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.

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.

  • Tokinsom Well, it seems we can't change the layout size in runtime. :/

  • Ah, forgot about that. I'd request it or just start using your own "layout zones" with 9-patches as I mentioned earlier.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)