What I personally do is store either the JSON string of an object, or an identifier (usually IID or custom value), or both, to a dictionary for later reference. Then, at the start of the layout I loop through the dictionary and if the object(s) ID matches the key name, it will load by JSON string, be destroyed, or do whatever else I want depending on the value.

Erm...here's an example

Let's say I'm in Level 2 and I pushed a crate that I want to save the position of for later.

> +At End of Layout
-Add key to dictionary: LevelName &","& Crate.IID with value Crate.AsJSON

+At start of layout
	+for each dictionary element
	+for each crate
	+LevelName = tokenat(dictionary.currentvalue, 0, ",")
	+Crate.IID = int(tokenat(dictionary.currentvalue, 1, ","))
	-Load crate from JSON

(I'm paraphrasing here but you get the idea)

It can be a lot of work, and a royal pain in the ass, but you get complete control over your object states. Also, families help.

Good Lord that is an epic amount of work... Im not sure I want to go down that path, it could end up taking more time than is warranted for what I want to do.

I may be able to achieve what I had in mind using some work around with the Save/Load function. I need to keep playing with it.

Perhaps a plugin can make it a little easier.

Were you thinking of making a plugin for this Tokinsom ? It seems like the Persist behaviour does half the job. It just needs the ability to be disabled / enabled. So if it's disabled: when player returns to layout objects are in default positions. When enabled, objects are in whatever state they were left in when player left layout previously. Maybe I should put a feature request or something.

Thanks for the detail, I might end up using that method you describe.

it's no good

What settings would you suggest —

Hi!

I see this discussed a lot, and I've seen it done, but I still haven't understood how it should be accomplished: getting a nice full-screen pixel art on different screen sizes.

I'm making a retro style pixel art game which is especially intended for smartphones and tablets. I've started out with a 320 x 180 viewport, which works nicely if I make my graphics in true pixel size (32x32px tiles). I know letterbox integer scaling will keep my pixels nice, but I end up having nasty margins on my iPhone SE which has a 1136x640px resolution. Scale inner or outer gives a nice result full screen on both the iPhone and my iPad, but especially on the phone the pixels aren't so perfect any more.

Basically the scale inner or outer -approach would be fine and I think I could deal with arranging stuff so that nothing gets cut away, but the pixel distortion is a problem.

I've seen games made with Construct that I've played on both my phone and my pad which seem to accomplish this - for example "Cluckles". The phone view is more widescreen while the ipad view has a little more information on top and bottom (in landscape orientation). It seems like the pixel size is about the same as on my 320 x 180 project - but no pixel distortion!

I made a pixel art game lately using a different software and achieved a nice look by making the graphics 4 times bigger, so a 32x32 pixel tile would actually be a 128x128 pixel graphic. This kind of higher resolution solution would probably end the pixel distortion problem here too, but it also makes the graphics much heavier.

How do you do this? Any input would be much appreciated before I make the decision and start building more of the game. Is there a satisfactory way of doing it with small graphics or should I upscale them?

jtraskelin Cluckles Adventure uses Scale Outer. You need to make the background graphic for all layouts larger than the window size. Thats true for game level layouts, menu screens etc. In Cluckles the window size is 240x160, and the background graphic for each layout is 368x256. The larger bg graphic means you wont see black bars or the edges of your artwork on different device screen sizes. The tiles in Cluckles are 16x16.

Im not sure what's causing the distortion you refer to. But you'll get different results if you play with the settings in Project Properties. What settings do you have for Full Screen Quality and Pixel Rounding? Are you using C2 or C3?

If you want total control over your save data and save files, you would use a combination of Dictionaries and/or Arrays, and Local Storage. My current project has 3 save slots I am in total control of, can get or write to any part of them at any time, with copy/delete functionality as well. If this is what you're looking for, I suggest not using Construct's built-in save functionality. Far as I'm concerned that's just for debugging.

Tokinsom Can I ask, are you saving information about the position / state of objects in a layout? Say there are elements in a layout the player can interact with: coins to be collected, enemies to be killed, smashable crates. Say you want to save the state of the layout after the player has played through collecting some items, killing some enemies, smashing some crates. If the player leaves the layout then returns later, how can I load the previous state of the layout, rather than loading the default state.

What would you consider best practice in this situation to save the layout's state, including the position of objects within the layout, allowing to load that state at a later time?

The Persist behaviour works up to a point. It saves the state of objects within the layout, but I don't think its possible to revert back to the object's default state, if for example the player wanted to restart the level to play through from the beginning again. The Persist behaviour would work well if you could disable / enable it under different conditions.

The Save/Load function isn't ideal because it will load the old state and wont reflect points / coins the player has accumulated after leaving the layout.

Any tips?

Cool! I'm following this. Love the sci-fi, space scavenger theme.

Ashley in the video you show how the Z scaling feature could be used to manage parallax layers in the Kiwi Story demo. Im wondering if there would be a performance improvement in that situation? Like, if all the game is doing is scrolling say three layers at different rates to get a parallax background effect, will there be an advantage to performance by using the Z scaling feature instead? Just curious.

I'm currently looking for a dev to port rex's Light Behavior to C3 (C3 runtime). I posted in the jobs subforum. It would be a paid commission if anyone is interested.