Well, that's why going frame-by-frame also works well - it's unambiguous when you insert a new frame, you know exactly where it will go, or you can copy another frame including all its metadata like collision polys. If you work with spritesheets and add a new frame somewhere, it's not easily possible to tell what changed with the newly imported spritesheet

That's not true though- you must be seeing this in a way that makes you believe that the spritesheet format would be ambiguous. It doesn't have to be.

You could still create frame and animations in the same procedure as it is done currently, however it would simply place the frame over the spritesheet. You'd still have the frames displayed in the animation panel, and could reposition them(to determine the play order), select them, etc. When you select them, a box on the spritesheet would display to indicate where that frame is located on the spritesheet. If you select the animation in the animation list panel, all the boxes could display in the spritesheet, allowing you to easily see the correspondence.

The great thing about this method is you can make changes to the spritesheet with lesser impact on the corresponding frame data, because that data would remain in tact and can be adjusted independently. There would be no need to rebuild all the data because it would be already developed- you would simply shift the frames or animations, and all the data shifted(if the artist decides to reorganize the sheet, etc, which wouldn't happen often because the organization is usually planned). Or you could remove or add the frame data, even duplicate it. This would all be done independant of the actual spritesheet, so you can work with the spritesheet without effecting the frame/animation data.

At the moment the sprite image is tied to the data too closely- the spritesheet method allows more flexible workflow that is simpler and less of a hassle with working with many frames/animations. Most sprites have lots of frames and animations, so the spritesheet method I describe makes more sense.

Yeah, I meant we could add that - so you can export and reimport as a spritesheet.

Yeah, but what happens if you add or remove frames, or whole animations? How does Construct interpret those changes?

If I export all the animations to one sheet. How do I import all the animations from a sheet.

How do I import a whole sprite sheet with multiple animations(not just frames), into the editor without any prior animation data existing?.. How do I tell construct which frames correspond to which animations in the spritesheet?

If I'm forced to split the sheet into multiple sheets per animation, it doesn't solve the issue.

You're saying all this can be done and still have imagepoints/polygons stay intact? frame speeds? loops settings?

What's the benefit of that if you can import and export whole animations as spritesheets?

Construct doesn't have exporting of spritesheets from the sprite editor. It only exports per frame, so you have to reassemble them in an external paint editor before doing further work to them, especially if you want to animate them in the external editor. So it becomes redundant work that takes away time.

Then you have to reassemble them into a form that can be reimported back into construct- more time taken away. And what happens if you add or remove frames in the process- there becomes inconsistencies.

That seems to solve the problem of managing art resources as spritesheets, but what's the purpose in showing a whole sheet? If you're going to modify the collision polygon for example, you can do that easily enough frame-by-frame, right?

Showing the whole spritesheet has many benefits:

+You can paint anywhere on it without flipping through frames/animations. This lowers the amount of times you must click and reposition the mouse- allowing work to be done more fluidly without pauses. You can apply changes to pixels/details across multiple frames this way more fluidly without swapping between tools/panels.

+If you show the whole sheet, you can rely on one image. So you can export that one image instead of clicking through each frame/animation exporting each one having to reassemble them all into something workable in an external editor.

+You can then reimport just one image, and still have all the frames/polygons/imagepoints still positioned on the sheet where you have assigned them previously. If you have added another frame somewhere in the sheet, or inserted a frame, you can include tools to drag/position those frames to their new locations(you can reposition the frame and it would reposition the corresponding imagepoints/poly relatively). You could just click a frame and drag it across the spritesheet to the new location- duplicate if necessary for new frames.

The frames would have a relative position to the spritesheet, and the imagepoints/poly would be relative to the frame.

Basically this way would lower the amount of redundancy involved, improving the workflow. It would also open up other possibilities, like applying effects across the entire sheet- like changing the color palette.

Also, it might open the possibility of exporting/importing to certain formats that spritesheet editors use.

As for importing updated spritesheets to better use them in C3, I'm sure we can make some simple changes to make that easier. It sounds like an "import spritesheet over existing frames" option which keeps all collision polys, image points etc. and just updates image content from a new spritesheet would do a lot to help. Does that sound like what you need?

It would certainly be a step in the right direction, and help improve the process in my opinion.

Like Eisenhans mentions, it would be great to offer something more substantial, as the current method construct provides can be slow and cumbersome to work with if you have sprites with many animations and frames.

What I would envision is basically importing a spritesheet, and viewing the entire image in the editor, with tools to select frames from the sheet.. You could have the same UI, but instead of showing a single frame in the editor, it shows the whole sheet. If you add an animation, you can add frames in the same way, but adding frames draws a rectangle in the spritesheet that you can move around and adjust size. If you add an image point, it shows that as well depending on which frame you have selected.

The main thing here is that the whole sheet is shown in the editor, and the frames simply show a rectangle drawn over that sheet- and the collision poly and image points can show as well depending on the selected frame.

This wouldn't be that big of a change to implement in my opinion, because it would use the same UI essentially. The benefit here is that you can import/export one image, and work with one image in the editor or in an external paint editor- making the process more efficient.

What do you think about this Ashley ?

I think it would be very simple for you to implement as it uses the same UI, you might even be able to include a way to switch between modes. I suggest a way to switch as it would offer more flexibility, but If not, I suppose you could create a new object and call if Spritesheet, similar to how you have the 9patch.

I don't see the problem. People can't fork out $129 (or is it $99) a year to have the ability to make an UNLIMITED amount of games every year.

Just curious, but how many games have you made with construct since you began using it a year ago? I mean games that have been completed.

Supposedly C3 was to give us a way to implement things like this via an editor sdk.

Its one of the main features imo, but it's only been six weeks of blogs, and 2 years of silently waiting for updates.

An editor sdk that allows such feature to be implemented would be C3's saving grace for me. I don't know why they wouldn't announce that sooner rather than later.

You can currently import an animation from a spritestrip, but this doesn't solve all the issues. This effectively forces you to reset all the imagepoints as well as collision polygons (because they import as new frames), and it only imports for one animation. You still have to manage multiple images this way instead of just one.

The spritesheeting feature isn't for animation. It's used to pack sprites together to increase performance at runtime. Other engines refer to it as a texture atlas.

I want to USE spritesheets. I don't want construct to generate them and not allow me to handle them in any way.

I need better ways to WORK WITH my art/graphics so I can develop more efficiently. This is my point here.

Im mostly interested in looking at the use of an external editor.

Unlike tilemaps where there is a ubiquitous editor like Tiled, there are dozens of spritesheet editors.

As long as it improved the process, I'd be supportive of c3 importing from one of those.

The big issue I have with current way construct handles sprites is that you have to work on each frame separately, and are forced to click through each frame/animation and struggle with the UI. It is very cumbersome for setting up sprites/animations and maintaining them if you make changes to graphics.

There are so many ways it can be improved, and it's frustrating to see no progress made in this area.

It seems like they are complacent with the actual editor stuff.. we haven't really seen any big changes to the way we use the editor.

Don't those have to include a file with placement information?

That would mean someone would have make a way to parse that file, as well as create ways to manipulate images in editor.

Then, would people have to be able to import a file type, meaning pick an existing editor, and use its format?

Well, I thought C3 would be handling all that when they promised Spritesheeting. But it looks like they haven't implemented any spritesheeting tools to allow importing spritesheets and editing them, choosing the frames on them, etc.

They just chose the easy way out in my opinion- and it doesn't help the process of creating sprites.

I feel like I've been lied to.

So C3 auto-generates the spritesheets, but that doesn't help people that want to CREATE and USE spritesheets in their projects.

I wanted to be able to create my spritesheets in a paint program and import that sheet, because then I could just edit the sheet in the program more easily to redraw parts if necessary, etc. That way I can just work on one image file instead of have to split it up into different images and import each one.

So this auto-generating spritesheet doesn't help in the PROCESS, because the process in C3 is still the same (you haven't shown otherwise), and the way it sounds is it just generates it in editor so that you can see the final output and also save on image quantity when exported (again, this doesn't change or improve the process of creating a project).

Can we at least gain the ability to USE spritesheets in the editor???

I can't remember if this is possible, but I'd like to reference an instance variable without picking it. Such as sprite["variable"] where I provide a string.

also, would there be a way to assign to the variable in the same way?