What a great update, a real game changer.
[edit]
When you create a custom action it should suggest the available override action names via autocomplete, that would be a nice QOL improvement.
Great update, especially with the pathfinding additions.
After playing around with the custom actions for a bit I'm pretty confused about their use case.
I can't find any difference to copy picked functions besides a different icon in the event sheets.
But I'm staying hopeful for some useful additions to this feature in the coming weeks.
Some suggestions would be the additions of something like
"Sprite.my_custom_action( param_0, param_1 )"
even better would be
"Sprite.Custom_Action( "my_custom_action", param_0, param_1 )"
Another suggestion would be, if I add a custom action to a family, that every object added to that family inherits the action, and I can perform different actions on each object
sprite_family -> do_custom_action
sprite1 on custom_action -> color.red
sprite2 on custom_action -> color.blue
"No one cares" as in "who cares" as in "it is not the point of the exercise", not what people are looking for.
But I do see how that could be read the wrong way.
While I obviously can't speak for everyone, I certainly communicate with a lot of C3 users who feel the same way, which the amount of thumbs up on my initial comment supports.
So you are a hobbyist like the majority of C3 users... that's literally what I'm saying, most C3 users are hobbyists, or small single person indie devs who use Event Sheets, not JS, to make their games.
So that is what Scirra should try to improve.
I do agree that there should be better tools for pros. But I also think that I should be allowed to ask for at least the same treatment and care for event sheets without you coming along and declaring on behalf of Ashley that that isn't feasible for some reason, and then getting agitated when I point out that you clearly missed the point I was making with my comment.
Your solution, to your made up infeasibility of my proposal, is to let the community port the game.
Which isn't the point. It's not about the finished game, it is about Ashley using his own product the way most of his users do, so he can improve Construct with that knowledge/experience.
And congrats that you never ever had any issues with C3 I guess.
You are missing the point, no one cares about the end product, it is about Ashley working with the engine, on a complex project, in the same way the majority of his customers do. With event sheets.
Optimally he would actually run into every single possible problem users have experienced, so that he can find a way to fix, or improve them.
Thank you for explicitly starting with reaffirming Scirras commitment to event sheets to address the concerns of many C3 users.
It might be a bit early for it but would you be willing to port the same game over to event sheets after you are done with the JS version (or a different game of similar complexity)?
Obviously a port to events sheets could not support as many units and such, but would still create the opportunity for even more C3 improvements, but this time more focused on the visual scripting workflow.
I also think that this scenario you are using to test is not very representative of actual gameplay if this will be a classical RTS.
With 1000 vs 1000 units I would guess that the pathfinding and especially collision avoidance between tanks, when they are actually controlled by a player, will be the much bigger performance challenge and will also cause a lot more delta updates which probably drastically reduces your current bandwidth savings.
Why do you have to update the positions so frequently at all? It's not an action game, shouldn't the units move based on pathfinding? With pathfinding you could only send the mouse click position to the server, calculated the path on the server and send it back to each player. It can then be played almost like an animation, that only gets interrupted through events like getting in range of enemy units or buildings, which could be handled like the projectiles with these network events, which, in addition, could send a full update for that unit.
Though I can see how your method is a more generalized, catch all approach and doesn't need specific planning for each new feature, though I guess we'll have to wait and see about that.
"I have to write custom collision detection code" #MadeInC3 🤡
I'm sorry if this came across as some kind of attack because that's not what I wanted.
English isn't my first language and these were meant as idiom in case that wasn't clear. What I meant with it was people feel betrayed, but that actually sounded more melodramatic to me than the idioms I used.
If you want I can edit my comments and replace the idioms with "betrayal" if that is more appropriate.
Like I said before I didn't expect you to change course, but you said you don't understand why people feel "betrayed" so I wrote it from a users point of view.
And yes these are angry comments, that is because I am angry. It is yet another thing Scirra does that I don't agree with.
I'm sorry that this comment started off with the wrong tone, but It is just very frustrating when again and again you feel like your criticism isn't taken into account at all.
Feels like if the comment isn't angry it is ignored, if it is angry it is inappropriate.
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.
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
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)
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.
Nice message from the main developer of Construct,
we made little examples with event sheets, but if you want to make a real game the event sheet system isn't enough.
That sounds veeery very different to the messaging we got for years and years from Scirra when we were the ones making games with Construct.
Feels like a total backstab.
Member since 29 Apr, 2013