Construct 3 suggestions & ideas

Suggest and vote on ideas for Construct 3! Please note this is only one aspect of planning. We do not guarantee any features here will be implemented, even if they are top-voted ideas. The aim is just to collect feedback. Remember to search for existing submissions before adding an idea, describe your ideas as comprehensively as possible, and vote for plausible ideas that are well thought out. Please see our full guidelines on suggesting features.

5 VOTE

Spritesheets for sprite objects / decoupling a sprite from its' frames

https://www.scirra.com/forum/c3-spritesheet-feature-isn-t-true-spritesheeting_t188976

Perhaps someone else can explain it better than me, if so, please leave a comment..
Here's just some general thoughts: 

Basically, by decoupling the spriteart from the frame data, we can import/export one image, work on one image without having to flip between frames/animations. 

The frame data would remain regardless of whether you add or remove parts of the spritesheet, so you can setup the frame/animation data independently.

It allows management of art assets to be simpler and less exhaustive. You could perhaps have different spritesheets and a sprite can select which to use, or even integrate it with current sprite system and mix them so when you create an animation, you can specify if it uses a spritesheet or not. Then you can simply update/edit the spritesheet and setup the frame data for that animation. You would then be able to edit either of those without affecting the other.

It could allow for modable games, since assets could remain on spritesheets and not be autogenerated into random sheets that mix sprites.

 

As it is now, the frame data are tied to individual images, so if you remove one it also removes the frame data(imagepoints,collisionpoly), so if you insert another image these are reset. Also you have to flip through them to edit the sprite instead of just remaining on one image and editing it as a whole- so you are required to click and interact with the ui exhaustively. This process becomes a problem if you have many animations with many frames. Games often have many of these, and spritesheets allow say an artist to make many changes to a spritesheet without ever effecting the frame/animation data. 

It might also allow for sprites to swap out spritesheets during gameplay. So you can have animation/frame data that can be used with multiple spritesheets, allowing for a character to change its appearance during the game without having to manage extra animation events

  • Alex HW
  • Apr 5 2017
  • Need more detail
  • Apr 18, 2017

    Admin Response

    This idea seems to mix up the internal representation and the UI representation. They don't have to be the same. For example, the editor could display what looks like a spritesheet, but internally represent frames as individual images; or the other way round, it could display individual images, but internally maintain a single spritesheet image. It doesn't seem clear which you want: the UI improvements, the internal representation, or both? These probably need to be considered separately with a rationale for each approach.

  • Attach files
  • Alex HW commented
    April 18, 2017 16:02

    In response to the admin; Many developers create and work with their art assets that are organized as spritesheets. This is because it allows them to encapsulate and contain everything in one file, making it easier to modify/change the artwork.

    The goal with this suggestion/request is to keep this part of the asset development workflow consistent. The way construct currently handles it is by forcing the developer to use single image files for each frame or animation. So what is needed foremost is to remove that requirement in construct, so that it allows the developer to continue maintaining just one file that contains all frames/animations. This should be the priority.

    What should be considered next, and which would depend on how the first part is implemented, is the issue of collision polygons and image points- how those will be retained when the spritesheet is edited (when frames are repositioned/added/removed and then reimported).

    What can be considered third, is what benefits of editing a spritesheet in an image editor- and if these could be integrated into construct's editor. Having one image allows you the ability to draw anywhere without having to click through a bunch of frames, change tools, etcetera.

    Other things that might be worth thinking about are whether objects can have multiple spritesheets; ie, have the ability to switch between them, or allowing animations to specify from which spritesheet their frames correspond to.

    I think this is the order I would prioritize it.