Construct 3 workflow suggestions?

Questions & Problems
#1

Wondering if anyone here is a user of the Construct 3 game engine, and if so, for large projects with many sprites, what kind of workflow have you designed? It is easy enough to export from Pro Motion to a sprite strip, then import to Construct 3 with the UI. But then, once I have edited each sprite in Construct including breaking the frames into differently labeled animations, frame durations/animation speed, and collision polygons, it’s not so convenient to make further graphic edits to the sprite in Pro Motion.

For example, exporting a new sprite strip and importing in Construct 3 will destroy the collision polygon and frame durations. Fortunately, if I export each frame to separate images, Construct 3 lets me drag and drop a replacement image frame by frame without ruining the other sprite frame metadata in the engine. But it is a little tedious especially if I made changes across a large number of sprites.

I don’t know if it’s possible or even a good idea to directly edit the sprite PNGs stored in Construct 3’s .c3p file with Pro Motion. The next best thing I could think of would be writing a custom script to take exports from Pro Motion and replace the corresponding images within the .c3p file. Anyway just curious what others have done if you have worked through this.

#2

Up to now I have no better idea than changing c3p contents.
I’m not familiar with constructs sprite handling. Do they offer some import export that contain all the extra settings?

A friend said:
You could also suggest to them that they consider pairing separate simple shaped (like rectangles for example) single frame sprites to each enemy to use for the collisions, because someone mentioned that using single framed collision sprites for each enemy as opposed to using collision shapes per frame of animated enemies drastically improves performance of the game, and, of course, if the collisions were handled by separate invisible sprites, you could swap out the enemy animations with no concern for the collision shapes per frame being ruined, as those collision shapes are never used.

#3

I used to be a Construct 2 user, and developed one iOS released game with that a year or 7 ago. Construct 2 had serious issues with (re)importing and control over sprite assets. Construct 3 offers even less control over project files and (re)import.

You’ve experienced these issues yourself already, and unless the C3 developers tackle a number of much-needed import, export, and asset handling improvements you will be out of luck.

The reason why I respond to this topic is to warn you about Construct’s bitmap handling: Pro Motion generates indexed PNG files, and when these are imported into Construct it will convert those to 32bit (24+alpha) ones, increasing the file size footprint. The user has no control over this whatsoever. Then when the game is exported, even with recompression enabled, the final asset is much less optimized file size-wise than the original asset that was fed into Construct.

I’ve tested this in C3, and the result remains the same. For example, a 256x256 256 colour indexed PNG file of 12.2kb resulted in a 31kb(!) 24bit version in Construct. After export the same image with recompression resulted still in a 17.2kb image.

This may sound like nitpicking, but if your game consists of tens of megabytes of images, it means a substantial larger final file size footprint, less room for levels, and so on, and so forth. And aside from this, I use a dedicated utility (Color Quantizer) to optimize the PNG files to the max, and Construct completely disregards this.
Construct is unnecessarily reprocessing and reoptimizing graphics, and this costs extra development time as well as causes larger graphics file sizes.

The total lack of control over the asset workflow in Construct 2 and 3 is worrying, and is one major reason why I left the engine behind. A game engine should leave your heavily optimized indexed graphics alone.

#4

Very interesting. Which engine did you move to?

#5

Before Construct I had worked with Clickteam products, BlitzBasic, and Flash. Aside from the poor asset workflow in Construct, I also very much missed the animation controls which Flash offered, and I had to resort to the rather clumsy Construct<->Spriter combo.

The final nail in Construct’s coffin was when I actually published the iOS game with it. It wasn’t exactly a solid experience (being a browser-based engine and relying on Cordova for an action game). Fine for browser games, not so fine for compiling actual executables. NW.js includes a full browser engine, which results in a 140mb empty game size for a Windows executable.

In short, I wanted something that would have:

  1. great built-in animation tools, including a timeline “animate anything, even code”;

  2. full control over my asset pipeline, and;

  3. native quick export. No fuzz.

Requirement (1) pretty much limited my choices to only a small set of possibilities, and I settled on testing Unity and Godot. I tried Unity for a month, and then Godot. Since I am mainly work in 2d game development, Unity felt like overkill, and Godot was surprisingly… nice to work with. And an incredible light footprint, and the asset control is excellent!

One of my pet peeves with Construct (aside from the already mentioned ones) was that my carefully prepared spritesheets would just be re-processed AGAIN into new spritesheets. Can you imagine your 16 colour sprite with distinct colour palettes being partly combined with totally unrelated sprites and background graphics in new sprite sheets? Ugh…

Anyway, Godot 2.1 had a pretty good import pipeline, but since version 3 it is perfect for me: Assets are left alone, and can easily be updated with new versions (Godot keeps the original and processed one side by side), yet I have full control over the processing side - even to the extent of deciding to use texture memory compression. Or just leave them alone. Absolutely perfect. Spritesheets are left alone. Problems with alpha/transparency are solved with a click.

And when an asset is updated, Godot automatically detects this, and re-imports with the settings set by YOU. Quick and effective.

My intention is not to heckle on Construct. As a web game engine it is probably the best choice out there (and easiest to develop these with), but my requirements just outgrew the engine.

This turned into a long story again. :smile:

#6

PS I’ve been a user of PM for 8 years now, or something. PM NG is lovely to work with. I combine PhotoLine, Krita, and Pro Motion for most of my graphics work. PM Reminds me of Deluxe Paint on the Amiga (which I know it is a spiritual successor of).

#7

Thank you very much for all the detailed insights! Very interesting! Although you seem to be happy with the asset i/o provided by Godot, please don’t hesitate to tell about things that could be improved within PM so that there is better interaction with Godot or other software packages you use. Yet, I don’t have any experience with any of the game engines, but I try to play around with Construct and Godot soon to create some tutorial videos, mainly for creating tile sets and importing them into the engine, but of course I will also need to add a character animation etc. . Maybe some possible improvements will come to my mind, but I guess I’ll only be scratching the surface of a very simple game project and won’t experience fiddling with assets that more complex projects would have, not to speak about true game development involving multiple iterations.
I created my last game on the C64, long time ago and I never finished a game for the PC, although I started a project in 1996 (where PM was initially planned to be my own sprite editor). At that time there haven’t been any game engines (I think Clickteam started to create one at that time) and all the game code, asset handling etc. was handmade :slight_smile:

Happy to hear that you are a long term user of PM. Please also don’t hesitate to tell me about features you miss or things that can be improved, extended or rounded off.