Since my first blog I've been putting together the overall architecture of the game. You can see some of the initial work in the commit log on GitHub. This can...
I think that's a wilful misreading of the post. I'm not saying event sheets aren't important or can't do amazing things. There are plenty of big Construct games already made entirely from events. In this project I want to focus on a different approach.
This is exactly the way most of your users are reading this.
It doesn't matter what you write, actions speak louder than words.
I complain all the time, but even the people that usually kiss the ground you walk on are voicing their disappointment over this one.
But it's a wasted of time to argue, you already made your choice.
I'm just doing a coding side-project, and I explained all the reasons for choosing scripting in this blog post. I don't know why you have to talk about things like backstabbing. If you don't like the idea, well... you don't have to follow the project 🤷
Well that's the problem isn't it. You either can't, or don't want to see it yourself.
(Btw idk if you can see that or not, but just to be clear, I'm not down voting your messages)
I genuinely don't understand this - it was apparently not controversial when I opened our latest blog on JavaScript coding with "Construct's visual block system can produce amazing results without having to write a single line of code. However if you want to go even further... then you can also write JavaScript code in Construct." Here I am now demonstrating how you can go further. I think all this talk of backstabbing and kissing the ground is way over the top.
And I genuinely don't understand how you can't see how this is a punch in the guts for a lot of users.
- The majority of people use Construct because of the promise that it advertises, no coding required
- Everyone obviously wants to eventually make their dream game and for a lot of people that is something bigger
- Construct has a bunch of issues when it comes to making bigger games, not only in terms of performance but especially in terms of organization and structure
- We were always told that Construct is capable of these big games and that events are perfectly fine for it (and yes there are bigger games made with it, but most of them moved on to other engines after release and some jump ship even mid development because of these issues)
- People asked for Scirra to make a game with their own engine to see these issues, since they can't fit in a bug report and are hard to communicate. The suggestion page is full of a million guesses how to fix it which creates an even bigger mess
Then you announce that you make a game with your own tool and tell people it is to test the engine, to taste your own dog food.
The expectation is obviously that you will finally experience these issues yourself now and get a better understanding of them.
But then it turns out you skip over all the issues that the vast majority of users struggle with for years by using JS instead of events.
If you like it or not, the message you are sending is, for "real games" you need "real code".
Which is the polar opposite of the dream that you are selling to people for over a decade.
And that is what feels like a stab in the back.
We routinely deal with feedback from users with large event-based projects and make improvements based on that feedback. We did it just this week with improvements to search in r312, for example. And 80% of my time remains on that kind of work. This is just a side project focusing on the coding features of Construct. I've already addressed many other points in both this blog post and these comments.
This violent language like "punch in the guts" and "stab in the back" is unacceptable. Please see our Forum & Community guidelines. You can disagree but you don't have to use language like that. I am going to stop responding to such remarks and may take moderation action if it carries on in future. I'll be carrying on with this project, and nobody has to follow it if they don't like it.