> Unfortunately, much of the way contruct operates makes assumptions about what the game dev needs. I find those assumptions to be uninspiring and somewhat limiting.
>
Can you elaborate on what those things are? We've always designed C2 to be a general-purpose game engine and avoided any "cookie cutter game" type features where you're forced in to one style of gameplay. The built-in behaviors are all designed to be customisable and flexible for different purposes, at least to some extent, and if they don't work for you there's always the option of custom logic via events.
Tokinsom already got to most of what I would say.
The prebuilt behaviors are great for speed and prototyping. But they really aren't that general purpose though. You can't make a mario game with the platformer and solid behavior. It is impossible... unless the platformer behavior is only for the goomba . You can make an approximation, but specifically you have made a construct 2 platformer game, not mario. At any level of analysis this is painfully obvious. This is rooted in the way the behavior handles and resolves collisions. If you want a custom movement option, the custom movement behavior still only lends itself so far before the limits of the system become obvious. You can only make specific kinds of custom behaviors with it.
Those behaviors are non flexible and only as general purpose as the creator could envision them being used for (And I would never expect you to be able to envision every use case). But at a core level, I can't edit the way they work because they have been tied to the c2 black box. The assumption made in the behaviors is that they are good enough. You don't need to do any low level work, and anything can be achieved as is. But that's wrong. Using the behaviors... You can't create parallel worlds like that one game where you can jump to the background. You can't create n+ because you can't get surface normals and projections. You can't create mario because it uses an entirely different way of detecting and resolving collisions. you can't create sonic for much the same reason as mario. You can't create dustforce because you need raycasting and collision normals. The list goes on. You could make these games using events but that would be a royal pain in the ass in the event sheet (I know, I recreated tile based collision detection with 4 resolution types and 12 different slope angles as well as halftiles.... just for fun and tied it to behaviors that ran point based collision resolution). But since I can't save the events as a more abstract behavior, it really is a waste of time, and the lack of true OOP makes event scripting something like that even harder. And it's less efficient. So, the end result is that I create behaviors, and plugins... that need to talk to each other. You never designed behaviors and plugins to have to talk to each other and told us not to make them like that, but even the way you use solid and platform and platformer is breaking your own rules... you just are able to do it better because you can integrate it with the engine, which the rest of us can't. There are no solid groups for collision filtering, push out nearest doesn't work as well as it should, there are no projections or contact points provided, there is no end collision and so on. Solid collision resolutions also have some built in constants (why aren't those exposed as properties?)...
Does this all make sense? And Ive only touched on platformer stuffs... There are many of the other behaviors yet to talk about. I have never outright said it but, physics sucks in construct. It isn't even adequate. Not only that, there are not but a few people using construct capable of changing what physics can offer. Unless you are making a very basic physics game, physics is worthless. But that's my whole point! You can't make anything beyond simple basic things with the behaviors reasonably.
So, in the end I code... usually in an environment tailored to it, because that makes the most sense. The end path of construct as I see it is coding, but it isn't as easy to get into coding for construct as say, unity. Which means ultimately, Unity actually is easier
Don't get me wrong, I like construct. I would still buy it again. But it is a prototyping tool for me and an instrument to teach/introduce kids to programing. I stick with it because I am visual and it is easy to see and interprete events for me. Once I got my own library of plugins and behaviors made, things can be swell in construct.
(btw) every time I write a long post like this construct logs me out and doesn't save it... super annoying. I have to copy my response every so often to ovoid losing my work.