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.


All sprites to same spritesheet, if it gets full, fill up next(for small size games)

Construct 3 b132 brought us even more complex spritesheeting engine, that is literaly made for  medium and  medium+ games. Which separates sprites over more sheets then it used to be. For smaller, more complex and effect thriven games this not good thing, as more sheets will drastically eat up performance.

In favor and used together with other cool thing we got at release b132 "custom defined spritesheet sizes": We should have ability to tick checkbox so all sprites fill up 1 spritesheet, if its gets full then another. This gives us possiblity to have least spritesheets with highest efficiency. So we got both sides covered. Atm spritesheeting got pushed into case, that there should always be  alot of spritesheets, even more then it used to be.

Atm if you like to test some simple cases with few sprites, they instantly are seperated, based on their size. Which is really awful in my opinion but this idea would fix it! You can't litteraly test some 10x10 sprite with 100x100 in same sheet ( ! like wow :(, in my opinion !)

One 4096x4096 spritesheet could host alot of sprites and enough for 1 smaller game. Atm sprites would be seperated over 20+ spritesheets, that you can't lower, depending how you build your project.

If you like to make small bullethell games or other kind, effect hevy, games with small amount of graphics, you must use all kinds of  batching optimizing to get better performance. Instead all sprite could easily be in one or two 2048x2048 spritesheet or one 4096 spritesheet.

Examples: In compare, cool small game KiwiStory could easily hosted in one 4096 and 2048 spritesheet, instead 22!

Demonoire could be hosted in 2-3 spritesheet, but its slow pace game and you don't get any benefits from it, but atm its in 47 spritesheets.


If somepoint your games grows you can always enable correct spritesheeting and take advantage of its methods. But if you like to build small sprite hevy games or just test some case for your bigger project then single sheet option should be nice. (TiledBG objects should still be seperated)

     If you add case, that other layout sprites gets seperate sheets to fill up, you could have medium+   game with highest efficiency. Taking into account that Construct is pretty good at small&medium games, then this feature would be rly good addition.


If someone has already built some complex sprite hevy game, maybe even on phone. Then can one test release 131 vs release 133 and how huge the impact is. I mean i can't be onlyone who sees need for this and any input would be nice.

  • SnipG
  • Jan 10 2019
  • No status
  • Attach files
  • SnipG commented
    22 Jan 13:40

    Construct tries to appeal spritesheeting to strange middle case with very complex style.

    This will removes the need to constantly change spritesheeting,  when some project run bad or don't run at all(never ending problem).


    What would be best is having 3 style.

    Simple: all sprites same spritesheet, if 1 gets full start filling next - per layout. No need for memory management.  Sprite deduplicate works per layout. 

    (works for small and simple games, testing performance, tring out some examples etc.)


    Medium/flexible - current c3 spritesheething. Default spritesheeting


    Large - Manual spritesheeting, introduce complex and manual or near manual spritesheeting. Disables automatic logic. User can customize sprites per sheet and apply memory managament for perfect results.

    Could be ineditor or outside.