Individual requests may often be presented as simple, but many things that may seem simple are in fact very complicated and time-consuming to develop. Further, if you add up all the 3D feature requests across all the users making them, it amounts to developing a significant chunk of a 3D engine, and that's not a goal for us with Construct right now.

So 3D positional sound was added because it was easy, and other things aren't, so you won't add them, which doesn't matter because Construct is a 2D engine, even though you just added 3D positional sound, which would require some or all of the same ground work as, say, the very specific example of a 3D distance(x,y,z) method, that was given because users pretty much know how you'll respond to most requests with a no, but who needs that anyway, because Construct is a 2D engine? Do I have that right?

Construct remains primarily a 2D engine. Unsurprisingly when we added some extra 3D features there was a lot of excitement, but also a lot of further requests for things like animated 3D models, 3D lighting and shadows, 3D physics, 3D collisions, 3D features in the editor, etc. etc. If we did all of that, not only would it take years, but we'd essentially be building a full 3D engine. While that might be cool, it would probably amount to building a whole new product. It's important to have focus, and our goal is still to focus on building a 2D product, but with some fun extra 3D additions - for example an otherwise 2D platformer but with a few elements of 3D added in, along the lines of the 3D platforms example.

Not asking for anything complex like 3D lighting, physics, collisions, etc. Just simple (and it is simple) object rotation. I'd be remiss if I didn't point out people have already figuring out how to deal with 3D physics and collisions so it is somewhat eyebrow-raising to read the standard response when it comes to any feature requests that would make life better for every user, regardless of whether or not their game project features 2D or 3D gameplay.

As for animated 3D models, that appears to be handled quite well by the 3rd-party addon created by Mikal... which really should be an included feature, but that's a conversation for another time and leads down a rabbit hole of discussion around why C3 is doing so much on the CPU when webGL/GPU has support for handling for more on the GPU out of the box. But, again, another time.

Another extremely basic feature would be 3-axis distance, which we can do fairly easily manually, but given the addition of 3D positional sound, it seems like it would tie into the functionality that's already been created for that, as you're already checking 3-axis distance AND direction.

Generally the devs don’t give roadmaps, we just find out what they added when releases come out. Sometimes you can see what they currently working on when we see related features being added. That said we haven’t seen many 3d features added in a bit.

We can make feature requests on the suggestions platform, but features such as full 3d rotations seem to be delayed indefinitely as the dev calls it complicated.

Anyways we can do some physics on our own. We can use the distort mesh feature to make full 3d rotation, then the rest is math.

Here is a test I made for one die. I have some ideas to improve it and make it work for multiple dice but it may take a bit to implement when I get a chance.

https://www.construct.net/en/forum/construct-3/how-do-i-8/create-3d-dice-rotation-167723?kws=Dice

It's a little frustrating that they've said 3D features received more excitement than anything else in years and then... nothing. Can't even handle basic 3D rotations because, apparently, math is hard. Total nonsense. Guess that's their MO though.

One of the problems is that any changes they make has to make sense to both the CA and C3 environments, otherwise they can't keep their promise of C3 benefiting from CA's development.

That's not something to count on anyway given their track record, and C3 already uses tags for things like collision filtering. C3 could/would also benefit from the inclusion of expanded tag implementation around timelines and objects, which already exists in other gamedev software, and also animation software like Spriter that works with C2/C3, which has its own tag system.

Currently in C2/C3, for something like a UI (just using UI as an example as it's easier to explain), users already have to use a variable as a tag, or use something like ProUI in C3, to implement basic functionality that, again, already exists elsewhere.

So, there's benefits all around, including for C3.

> 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!

All of these issues were solved a decade ago in existing animation software. Instead of working in a bubble, do some legwork and look at what's been done previously and adapt the same or similar methodologies instead of wasting time explaining how hard it is to reinvent the wheel.

The most straightforward way to do it that animators are used to would be to allow tags to be assigned to layouts, layers, objects, and groups/hierarchies. That solves most of the issues as described above, as a layout could be tagged as default for playback, layers (with associated sublayers) could be tagged as backgrounds, etc.

I hate to be THAT guy and again, i've been advocating for and defending Construct against criticism in the past but as someone who animates for a living this is just very close to heart...

As a background, I produce animation for corporate training and educational purposes, lead a team of two people as a creative director for a fortune 500 company where we produce a lot of animation and freelance for more "fun" projects next to all that like i.e. a credited brief stint as an animator on an adult swim show.

I've worked with After Effects, Flash (now Animate), Moho Pro and, my favorite, Toon Boom Harmony Premium.

There is absolutely NO WAY that i would use Construct for animation over any of the above mentioned software packages, which have literally decades of development behind them and were very carefully catered for animators and suits all their needs.

When it comes to producing HTML5 animation for the web, i'd either go with Animate CC, which i rarely use these days but it comes with our company wide CC subscription OR, would look into Rive.App, which was recommended to me by my colleagues and seems to be a really robust piece of software that is very similar to tools found in the above mentioned packages.

I maybe used the Construct timeline once or twice in my projects since i found it to be extremely confusing and non-intuitive. If i have to think longer than 30 seconds about how a timeline works, there's really something wrong, sorry, but by now after using so many timelines, this is just something so standardized, that it should work in a more standardized way. Beside that, in my experience the timeline used to crash a lot. I don't know how it is these days, it might be better.

In any case, the claim that Construct is the "BEST and EASIEST" animation tool to me is just either delusional or simply a very bold claim that can be debunked and backfire very easily.

Construct's animation features are just very clearly developed with neither a clear understanding of animation workflows nor any sort of input from professional animators and it shows. The interactivity might be nice but it's probably already a total overkill for most animators, who definitely won't spend the time learning the ins and outs of the event sheets. As intuitive as they are, they still need time to learn. Compared to something like Rive or all your usual prototyping tools like Figma or Invision, which can export HTML 5 and offer easy(er) to use interactivity features as well, it's really not all that intuitive as you might think.

Again, i don't mean to be nasty or criticising just for the sake of it but it seems to me, that Scirra tries to enter a market that they neither really understand the customer base nor the competition. They saw an opportunity to kill two flies with one blow with the timeline and went for it, which is commendable, but for Construct Animate to be in any way a consideration for animators it would need a HUGE and i mean HUGE, probably months to years, amount of research, programming, testing and marketing.

I just hope they didn't bite off more than they can chew and hope they really go in and look at whats out there and what the people they want to sell this to actually need. Which also brings me to this: WHO is this for exactly? WHAT animators? Motion Graphics people who work for video? Definitely won't use it, and one video export option with a file format that is highly compressed won't change that either (usually you animate either directly in the compositing software or export image sequences and then go to compositing or some ProRes or other video format with less noticable compression).

Character animators, game animators, UI designers, etc. etc. there is really no clear indication, who they want to develop this for...

I've never been this critical of any of Scirra's decision and i've been with them since the early C2 days and was a day one adopter of C3. But this project, to me, doesn't seem to be under a good star, unless they are willing to put enormous resources into it and i can't see how that will NOT affect C3.

But just my 2 cents, rant over :D

This. It doesn't seem anyone who animates for a living was actually spoken to, and the way timeline animation works here and in C3 is the very definition of counterintuitive compared to every other piece of animation software I can think of.

As soon as we get some workflow polish, this can be a great After Effects competitor (there is no decent one in the market atm, btw). I've been animating in AE for 10 years and the best thing it has is fluidity of use in the UI. If you ever need it, I'd love to test dev builds, do live testing and give feedback along the way.

I could get very particular about this if you guys would find it useful, but I'll leave these simple but ESSENTIAL points; I believe no animator would take a keyframe-based program seriously without them:

-The MOST important thing is you should be able to drag the cursor to make a selection area, this is vital for keyframe management.

-Dragging a keyframe should select it and move with the cursor. Right now it makes a duplicate when you drop it with values that have no apparent correlation, and undoing does not erase them.

-Shortcuts for adding properties when an object is selected (pressing A adds Angle property, T for Transparency as it's closer to the left hand than O for Opacity, S for both Scales [X and Y], W/H for Width and Height...)

-Autokeyframing (toggleable) ON by default (when you drag an object and are in a moment in time that has no position data, add new keyframes and position data automatically. Same applies for angle and size)

-Buttons for going to the first/last frame, keyframe skipping only is not enough.

-"." and "," or left/right arrow keys should move frame by frame.

-Ctrl+D for duplicating any currently selected keyframes one frame forward, overwriting the former if there is any. Essential for timing and pre-posing.

Complex to implement but ESSENTIAL on the long run:

-Scrubbing the cursor should update the view dynamically so you can instantly see how it's looking. If this is implemented, clicking on a keyframe should not bring the time cursor to that point, it should only select that keyframe and update the properties panel.

-Double clicking on a keyframe should bring up a easing editor, same as editing it on the layout directly but on a linear timeline with precise scales/rules (see After Effect's implementation). I can't express how important this is for any animator.

More like an Adobe Animate competitor - the ecosystem surrounding AE after 20+ years is robust, and it's an industry standard that's not going away, especially given its comparatively low cost in Adobe CC subscriptions. There isn't any real comparison with AE to be had.

On a related note, I can't imagine the name of this new product is not going to receive a positive response from Adobe given the similarity with Adobe Animate... doesn't seem that was thought through at all.

digitalsoapbox The first error (this. OnLayoutChange) was totally fixed. But not yet for the second (Zlib undefined). This is a problem with a third-party library that I'm not sure I'll be able to fix very soon.

GameSoul

Alright, I'll see if there's something in my project conflicting with the TMX importer addon. However, at least one of the parser addons are needed for the TMX importer addon to function at all.

For anyone reading this now, I'm putting a bounty on this to get it done in the next week or so. Reach out to me (PixelMetal) in the CC Discord if you can get it done!

EDIT: A dev has fixed the issues and will be posting updated addons shortly. Bounty closed.

> Cool, thanks! Still getting an error though:

Try use updated version: drive.google.com/file/d/1LqYqIhbBa2U9WenA9H0Yoi0O28ZO36Mq/view

> The XML & JSON modules that go with it are tossing errors as well:

I've tried to fix this error, with no success so far. I'm still thinking about a solution.

New version doesn't toss the error in a new project, but does in an existing project, so there appears to be a conflict going on somewhere. It's showing the same errors (below) but I can click a few times and get the layout to show up, so it now goes past a black screen. This happens at the beginning of every layout. This is in non-worker mode.

Looking forward to the modules! If you have a non-messageboard way to chat lmk and I can put together/provide a test project to sort the issues out.

digitalsoapbox Rex_TMX_Importer_V2: drive.google.com/file/d/1LHOW3RxZSGazDHlx84Hh0Yh2OcbRrqsO/view

GameSoul

Cool, thanks! Still getting an error though:

The XML & JSON modules that go with it are tossing errors as well: