— Games - ...I see you like to have opinions. Me too... but I like to be able to discuss why I hold those opinions. What's my point? please refer to the above posts. My point(s) have already been stated. You have failed to address any of them except to basically disagree without evidence as to why.
"I only just wonder what is your point? If you prefer writing code, then you are free to use a framework, where you can code. I mean, the point about C2 IS the event system." - — Games
My point: "construct 2 is faster to create objects add behaviors, and get a project up and running. Those benefits outweigh the downsides in a simple project, but as the size and complexity of the project increases, the cons outweigh the pros."
My Preference: " I would prefer to use visual scripting, like c2, because I have a much easier time simply glancing and knowing whats going on"... However... refer to above quote.
"Sure, there are things to improve and that could be made better in future releases, but if you put too much in it then all the philosophy of C2 is getting lost...why should C2 turn into some Unity 2?" - — Games
Obviously there are always things that can be improved, but the likelihood of something improving without some good discussions about it... well, that's why I made this post. I don't see how improving the workflow and efficiency of construct will destroy the philosophy of construct. I also don't see how this will turn it into unity. Nice slippery slope.
"Because Unity we already have and it's ready to use. C2 is meant for easy, rapid & uncomplicated game making and you can make big projects with it, but sure it must be in a relation to the engine." - — Games
Above, you state that, "the point about C2 IS the event system." However, you also say c2 is meant to allow "easy, rapid & uncomplicated game making". I think they are both part of the c2 "philosophy", but that the event system currently gets in the way of "easy, rapid & uncomplicated game making" when a games size exceeds basic arcade style games. The actual engine behind construct can support way more than the event sheet can support. In respect to " easy, rapid & uncomplicated game making" I am suggesting these things be discussed.
"I like what people trying to do and to achieve, but a complex RTS or MMO is maybe not in the scope of C2, but a great arcade adventure like Metroid or a Zelda like adventure game is possible for sure & games like this are really huge projects for the most people here. " - — Games
I agree, I have the utmost respect for the c2 community and what they are achieving. However, the original mario is simpler than metroid or zelda... and it is "possible" to make it... but please refer to the above post. There is no way on God's green earth you can make either metroid or zelda or mario without either 1.) using the sdk and CODING... or 2.) using event sheets way beyond the practicle point (you know, where you are trying to do collision detection and resolution )... At this point there still isn't a good way (fast, easy, uncomplicated) to handle dialogues in Construct without using the sdk, which is super important in a game like zelda. Programing it is... easy.
1.) coding is currently faster (objectively speaking) than using the event sheet to do the same thing (assuming you know how). The event sheet also has a performance loss.
2.) because you will need to rely on the sdk, for reasons stated in earlier posts, especially as a game gets more unique or complex or large (not just bigger levels), you will end up coding in coding in c2. But c2 is supposed to be about the event sheet!!!
3.) The sdk sucks.
1 & 2 & 3
Therefore:
C2 needs a better event sheet environment that can address problems raised in earlier posts...
and / or
C2 needs a better environment for coding...
But because it has neither, c2 is not suitable for large projects... as it is no longer easy, fast, and uncomplicated...