Construct Animate feedback thread

I'm only saying I trust Scirra, I wasn't trying to insult anyone. I'll be an unhappy customer if C3's development noticeably slows down due to attention to C3 Animate.

If I could choose, I'd wish Scirra could focus full time on C3. I do hope Scirra expand as a company and get more staff on board sooner rather than later.

I wasn't trying to insult anyone

I wasn't referring to your comment, I didn't see any insult in there though, I guess I should have provided an example to make it more clear)) I thought that was clear enough but I was referring to things like:

angry kneejerk reactions

We can disagree but with respect.

I think things like that were unnecessary as the users are hungry for a very good reason, a lot of us don't live with our parents and have bills to pay and families to support so if you focus on game dev full time you take everything more serious if you are using C3 as your main Game engine, that's why if you see them concentrating in something else where they could improve C3 and add New features to open new doors for new opportunities and income that's something that is for the best interest of everyone unless you doing it for a hobby.

The years are flying and we are getting old so we cannot wait for an eternity to add features and keep improving the engine, we need it now while we are still alive))

Construct Animate is not a huge addition to our workload. If it actually did double our workload, it would be totally infeasible, and we would not be doing it. Any time we make a big change lots of people like to predict the doom of our company, as has happened several times in the past, but here we still are.

As I pointed out previously Construct Animate has been in research/development since last summer. Over the past year we have continued to add loads of updates to Construct 3, and I don't believe anybody over that period noticed that updates were any slower than usual.

Please keep your posts in this thread civil, on-topic and within the Forum & Community guidelines , otherwise I will close this thread and ask that feedback be posted in individual separate threads.

Timeline suggestions:

When I click to 'Set keyframe(s)' button, but not at the 'Editing mode', automatically enter the editing mode and set keyframe

- You still have to add a timeline controller and create an event to properly export an animation.

It's simpler to set the 'Start on layout' property of the timeline.

- When exporting your animation, the default settings for Duration and Framerate don't match with the settings you create for the project.

I'm not sure Construct can easily guess the default duration if you have multiple timelines of different durations, and they can also start at different time offsets, which is why this is still a manual field.

- The transparency tip is nice, but a checkbox to automatically make all layer backgrounds transparent would be better.

That will break some cases, like using a non-transparent layer with opacity for a fade transition. Forcing all layer backgrounds transparent will remove the transition and break the animation. It's better to make the bottom layer transparent.

Maybe as a quick work around, have the first timeline set to Start on Layout 1 by default?

The problem is timelines aren't actually associated with a layout - they are essentially global and can be used on any layout, and so there also isn't really a good "default layout" to play them on, according to the current design. The default for the first timeline could be changed, but then the first timeline works differently to any timelines you add next. In my experience that just moves the stumbling block for beginners - the question just moves from "why doesn't my first timeline play?" to "why doesn't my second timeline play?". Even if you have to figure out how to play the first timeline, at least you've learned the principle and can apply that to any timeline, instead of relying on defaults you haven't found out about yet.

I agree that it would be nice to have a smoother experience for first-time visitors, but I'm not sure how to best solve this without introducing a new inconsistency.

Maybe have it use the framerate from the first timeline?

We don't yet have a property named 'framerate' for timelines... do you mean what we currently call 'Steps per second'?

Maybe an export option for making the bottom layer background transparent then?

Well, what is the bottom layer? That is a surprisingly difficult question. What if the bottom layer has sub-layers? Maybe it's the last sub-layer? But that is drawn after the root bottom layer, and could well be transparent anyway. What about the root bottom layer? That could actually be transparent and only used for a compositing effect, and in fact a sub-layer has the opaque background. There could be multiple sub-layers with opaque backgrounds, some used for fade effects, and only one truly being the background.

I don't think there is actually a good way to automatically identify "the background layer", so I don't think we can make a reliable setting for it, hence the advice in the dialog instead - presumably the project author knows!

I wonder if drawing tools are on the cards at all. Like not "going into a sprite, draw, then place on layout", but drawing directly onto the layout, kinda like flash? Draw directly into layers or something, even if behind-the-scenes this gets converted into a sprite.

I ask, as this is the one thing preventing a friend from trying Construct Animate, as they want to draw a background, then draw a character on top of the background so they get the scaling and perspective correct. But right now, you have to go into the sprite editor, which means you have to guess how it will look once placed onto the layout. Sure we can resize sprites, but they're raster images, so they won't look smooth if suddenly resized.

Imo a big issue that has plagued timeline from the beginning and sadly still plagues it is:

It's still fairly unstable, leading to crashes from time to time.

While I see that the timeline crashes get fixed when reported as a bug, it sadly seems that new crashes crop-up almost every update and it also seems to to get harder and harder to reproduce them.

I understand that the timeline is a fairly complex features and I love all the new updates and qol changed, but it is a really bad sign that it still is this unstable after being out for a few years by now.

This leads to the case where a lot of community members are actively avoiding using the timeline.

Because of that reputation it's even more important that the timeline is 100% stable. To overcome the fear of crashes and reinsate trust in the stability, the timelines robustness needs to be proven double.

The timelines stability needs to be looked at thoroughly, tested and refactored to bring it to a robust, stable state imho.

I think what you (fairly) identified was that the problem of building a product for multiple audiences. Is Animate being designed for animators, or game designers? Some may say both. But the real issue with this is the question of choice.

Every product asks to be chosen instead of the other options available to each audience. And when those audiences want and expect different things, with different (even competing) workflows, priorities, and language, the product either has to focus on one audience, or what they all have in common (which is usually very difficult).

If clarity of purpose is the first step, the second step is superiority — offering something the other options don't, or don't offer well enough. We've seen that here: so much of the feedback has been to get Animate up to the basic standards of other animation software. Useful, but that only makes Animate just like all those other options. It doesn't give it anything above those expectations - a reason to choose it instead of what already exists. And there are some incredible options out there.

It's not clear yet, to me, who Animate is designed for and what it has over their other options. But figuring out those two points is the first thing that should be sorted, before technical research and engineering begin. That vision is what defines the biggest features (are effects included or not?) and the smallest details (is it frames or steps?). I hope it's sorted, and just not been communicated.

Personally, I don't think you need to be more patient - I think you're exactly the kind of user that would benefit from those points being answered. You've had given lots of amazing feedback, and more clarity would make that feedback even more useful.