Ok so now I explained as other people why we think 2 products at the same time for 2 devs could be counterproductive, I'll now propose ideas that I think could greatly benefit both products, as we all hope Scirra will succeed with their projects, and be able to grow and hire new developers on the engines as they’re planning to do.

I think the deal is fair as long as promises are kept. Which means :

- Scirra dev team will grow,

- Construct Gamedev isn’t affected in any way in its development so game-specific features continue to be added in the engine and remain the priority,

- Most of the new CA features benefit both products so are useful and relevant for us faithful gamedev customers paying our subscription.

I agree with many feature ideas proposed by other users in previous post (direct preview and edit of Ease curve in Properties View for example), I’ll just suggest additional ideas (most of them also benefits regular Construct) :

1. Add a Hierarchy View to enhance the workflow of creating hierarchies by simply dragging and dropping instances on top of each other in this dedicated view.

It would also allow users to find, order and select Instances in a convenient way without needing to lock layers on top to be able to select instances directly in the layout view.

Hierarchy is at the core of Animate so it deserves UX enhancements.

Why ? Right now the workflow that consists in selecting child then parent and then right-clicking parent to open a context menu and only then create the hierarchy is not intuitive. Also green arrows are confusing regarding which object is parent and which object is the child.

Dedicated suggestion : construct3-21h2.ideas.aha.io/ideas/C321H2-I-311

2. Add “Animation Trigger Events” to Frames in the Animation Editor.

As one of the best USPs of Animate seems to be related to the possibility to execute logic from Eventsheet during the “Movie” (in addition to the usual Timeline workflow most Animation software have), it would be nice if we could trigger events from specific Frames of any Sprite animation.

For example in the Animation Editor, we could right click any frame to open the context menu where a “Add Animation Event” button could be added. The animation Event would be a string (=Tag). We could then execute logic in Eventsheet thanks to a new “On Animation Event {Tag}” trigger condition for Sprites.

There could also be a new dedicated "tool button/icon" on the left toolbar of the animation event. It would be similar to the "Edit Image Points", it would be a list of all Animation Events ("Tags") on that specific frame.

There would be autocomplete feature both ways, in the dedicated Trigger Event in eventsheet (most important) but also in the Animation Editor. So already used Tags are suggested to avoid mistakes.

Example use case : I have a character running in my Movie (8 frame animation) and I want to add small Dust FX at each of his footsteps. The process to add this small FX manually at the right frame on the Timeline would be really tedious. I could just add a “Step” Tag on the 2 frames where the character foot touch the ground and spawn my FX on a dedicated image point thanks to a On Animation Event “Step” Trigger condition in the event sheet.

3. “On Timer {Tag} Start”, “On Tween {Tag} Start” condition events. For the same reason (one USP of Animate being Event Sheets), I can think of a lot of cases why I would use Timer and Tween behaviors on top of Timelines in my Movie, for some specific things it’s really more convenient.

For the same reason it is very useful to have “On {Tag} running”, “On {Tag} Finished” (that already exists in Construct), we need a “On {Tag} start”. Indeed the same Timer or Tween Tag can be called from multiple places and it would be handy if we could avoid duplicating the logic that needs to happen when that Tag is started thanks to those new Behavior Conditions.

4. Nomenclature (Name-based) bulk import for Spritesheets. A big amount of frame by frame Animators prefer to work with Spritesheets to export/import their work (way easier for file management to have only 1 file). Right now if i want to make a Movie with my spritesheets animation, i have to manually import each spritesheet and specify the number of columns of the number of rows. It would be handy if I could just name each of them AnimationName_XxY where X is the number of columns and Y is the number of rows, and there would be an option to bulk import sprite sheets based on their name.

5. Resize Image Canvas > Image > Align Image Point

When Resizing an Image, on the Dedicated pop-up menu (“Resize Image Canvas”), add the option to “Align Image Point” in the “Image” drop down list. As it works with “Align with Center”, but based on an Image Point. This is needed really often.

When “Align Image Point” is selected, it adds a number field to choose which image point should be considered.

6. Shortcut to Snap Polygon Points and Image Points to integer Positions

If the user press MAJ (or CTRL?) while editing the Collision Polygon Points or Image Points position, it will snap the currently selected poin to the closest integer position :

-> Image Point Edit: when the user is in Image Point edit mode, if they click anywhere on the image, it immedialty update the point position to the position they just clicked. With MAJ, it would the closest integer position instead.

-> Collision Point Edit : when the user is currently dragging a point of the polygon, if MAJ is pressed it's only moving from integer position to integer position.

Why ? 95% of the time, we want those points to be placed at integer positions. Right now the click-to-place/drag-to-move points feature always place points at non integer position so we can't really use them and we need to specify X and Y values in corresponding field each time instead. Which is really tedious and time consuming.

7. Fix the Drawing Canvas : construct3-21h2.ideas.aha.io/ideas/C321H2-I-226

8. Enhance Pixel Art capabilities for both Animate and Gamedev Construct by adding a new effect that would allow to merge “pixel-perfect with smoothness.”

It would solve a very old issue for Gamedev Construct + it would allow the use of Animate as a tool to create pixel art FX, character animations and pixel art movies, by pixelating shapes, and interpolating them. It would allow us to have clean text and smooth scrolling for pixel perfect stuff even at non integer positions.

It could be a nice USP for Animate as a lot of Animation tools don't have any pixel art friendly features (I know it because as a customer i didn’t find it in potential competitors of Animate), and there is an overlap between people interested in Pixel art animation and people interested in making indie games.

Dedicated suggestion, explaining in details the issue and implementations ideas for this new effect : construct3-21h2.ideas.aha.io/ideas/C321H2-I-317

(Recently some successful apps with pixel animation features started popping, and it could be an inspiration for some features by the way : Aseprite, Pixelover deakcor.itch.io/pixelover, Pixel FX Designer codemanu.itch.io/particle-fx-designer, )

(it's weird but i've never had access to the "Edit Post" feature for Forum posts, no matter what device (PC/Mac/Phone) and what browser (Chrome/Edge/Firefox) I use, no matter if I'm in incognito mode, if I disable all chrome extensions or not. So pardon me if there are a lot of typos as I can't edit and preview my forum posts)

EDIT : Nice, i can now edit my post

The amount of work required to make Animate a decent animation software is at least 20 times bigger than the amount of work required to make C3 the best engine to create commercial 2D games. (it’s already the best for prototyping, but there is a reason why there aren’t a lot of indie hits made with C3 on steam comparing to most other game engines so far)

We know there must be some kind of organization behind the scenes where Ashley would focus on gamedev Construct, while Diego would focus on Animate Features and especially fixing (again and again) bugs and UX of Timelines. They were big investments in developing this feature, great progress were made and it looks smart to kill two birds with one stone and monetize this. Also “every new feature would benefit both Animate and Regular Construct users”, right ?

Well, maybe not. It could mean the priority will go towards features that benefit both products, so most likely Timeline enhancements or audio-visual related stuff, while the biggest priority should go toward game-specific features that are currently lacking in the Construct engine :

For example right now games with a lot of Data are a nightmare to make.

UI, Dialogue System, Reassignable inputs are incredibly difficult to implement while they are needed in almost any serious project.

We don't have any Inheritance features which is quite unbelievable for a game engine. (most requested feature ever on old suggestion platform IIRC)

A lot of built-in plugins aren't unusable in production yet (Drawing Canvas self-erasing as soon as the player rescale their game windows, just to name one)

Here is a non-exhaustive list of important things that i think really need to be enhanced or added in Construct, trying to prioritize what seems to be the most important construct3-21h2.ideas.aha.io/ideas/C321H2-I-318

Sure Timeline improvements are nice to have for gamedev but it feels like it's not the priority at all, it’s only “nice to have”. I can think of dozens of full-indie games that don't require a single use of Timeline. And even if we're only talking about audio-visual enhancements, i would prefer things such as better particle system, better audio features and better pixel art support, more 3D features : each of those would be useful for at the very least a quarter of all games made in Construct. Also Timeline right now is a pretty bad UX, but I'm not even sure I would use it a lot even if all nice suggestions from the dedicated forum thread would be implemented. Maybe just for polishing some menu intro/transition but that's it. It won't help me at all to develop the games I'm struggling to make right now.

However those 3 years spent on developing Timeline aren't wasted : it also helped developing Hierarchies which is the best thing that happened since C3 started, it's already possible to achieve some useful stuff with Timeline if we really need it right now (sure with the pain of a bad ux) but why keep spending more devtime on this especially, instead of other high-potential and promising features that were pushed once and then dropped forever for example ? I would love it if such a talented dev as Diego, who is also responsible for those amazing Hierarchy features, QOL and animation editors improvement to name a few, could also work on high-priority and game-changer features as you’re such a “small team”.

As other people, I agree there is no sense to split the features in 2 products. None of us would pay 2 subscriptions, so the best would be to include everything in main Construct and have the second Animate-only cheaper option for those potential new users you’re targeting. (+ you always advertised the subscription model as a way to be able to grow, and update our beloved engine. So it would makes sense if we - early subscribers - can use the things where the money went)

But even then, I would be worried. It could be very confusing, maybe even repellent for new users who would try this new cheaper option first, and find out the showcased feature is actually bad UX and worse than any other Timeline they tried so far. And above all, there is just 2 dev working on the actual engine right now (Ashley and Diego), you’re always explaining us (with good reasons) why every single small-looking feature can actually be a huge amount of work, telling us you need to prioritize on most requested (and if possible easy-to-add features), that you’re a small team and so on…. It makes no sense.

Most of the time, I defend Construct’s point of view when there is debate as to how Construct is evolving. I admire Scirra’s amazing delivery rate, most of the time I appreciate the explanations you’re providing to the community and I found last months really exciting in terms of updates and new features. You seemed to take care of some users' suggestions lately. But here I just wish you would limit the damage of this decision as soon as possible and focus on making your engine viable for commercial/bigger projects instead. There is so much game-changer, absolutely essential things to add/fix in this engine while fixing the Timeline is just “nice-to-have” at best (as Tweens are already nice to work with for most common cases), or even useless for a lot of projects. Almost nobody is using it. It’s harsh but it’s the truth.

We all wish Construct could grow, multiplying its revenue and so on. But why not just spend 1-2 months to create a nice and fair Affiliate Program to let the network effect, content creators and community market Construct itself ? construct3-21h2.ideas.aha.io/ideas/C321H2-I-310 It would be a better match to the SAAS business model rather than splitting the product into 2 different solutions. It’s less risky and less expensive rather than committing to this and targeting a maybe non-existing customer base, trying to reach brand new users while the current community was built slowly during 10 years. The potential of gamedev Construct is still far from being reached and it looks like it's safer to build upon its strength.

In any case, thanks to all the team for all the love and the work put into the engine for so many years, for all the updates those past months and I wish you good luck for the upcoming months whatever your roadmap will be ! Much love.