In defense of Construct 2

I think it's more like...leave behaviors alone and give us more options to make what we need when we need it, using events. What Newt said is actually how Stencyl works lol.

This!

> snip

>

I agree with all this. Got to say, reading about some problems make me feel like I live in a different universe or something. I can vibe with the sentiment that C2 feels limited because of certain assumptions about what users need and what they don't. The recent parallax discussion for instance springs to mind. But I don't see why we couldn't recreate Mario, or any kind of platformer gameplay we like, with the platform and solid behaviours and some events to supplement them.

It's actually because the way the platformer handles collision detection and response, that you can't clone mario. Iv'e been repeating myself multiple times in defense of the "you can't clone mario" argument with behaviors. You need a custom system for handling mario and his collisions. Trust me, I am not simply talking on conjecture but on actual experience. I event scripted a mario clone and I coded one via the sdk. In the future I may share this project, but I don't want to deal with people trying to figure out how to use them.

In many cases you can get away with the platform behavior. but the moment you need a low level control, you are up the creek. For example: if you need collision grouping, things are impossible with the behavior atm. If you wanted to altercate the way collision response takes place on slopes... well... now you are in the behavior itself recoding it. You can't fix the way a behavior works in events. Try adding kinematic bodies to physics using events. lol. You can add in 10 minutes though, via code, but it is impossible through events

> ....to say you couldn't create your own physics with events is not true.

>

Your earlier point about making Mario with platform behaviour was valid, and I haven't tried so it could not only be possible but relatively easy to do now I think about it.

No , no , no. You can't. It's impossible. Read the posts I wrote one or two above this one. Mario is so basic and yet it can not be made using the platform behavior, simply because of the fact that mario uses point based collision detection rather than SAT, Also, because the platformer behavior modifies the velocity of an object without the users consent, certain collision responses that occur in mario are impossible. You can make the behavior via events, but it is a terrible idea to do so without coding some of your own supplementary collision detection plugins and behaviors.

as for physics... My project using physics permanently got moved to unity.

Super Ubie Island was done with platform behavior and custom events. Seems to be fine. My only issue thus far is exporting options. Wish I could publish to consoles. That's my biggest vote

...this denies the point of the behaviors. Instead of using and setting something what is ready to go in few seconds you are reinventing the wheel by creating entire behavior in events just to be able to set one thing.

If you really want you can modify the behavior to suit your needs, but then it creates two more issues.

1. You should not modify original plug/beh because at some point someone might do some optimization or bug fixing and your changes will disappear

2. You can duplicate it, but then you need to keep track of the original plug/beh on every release just to see if nothing has changed. And you are ending up with two almost identical plugins that needlessly makes a mess in plug/beh list...

This.

We seem to be getting onto a number of different topics here :T

NotionGames I would argue that a game like Ubi actually is perfect for the platform behavior. It's incredibly simple in terms of platforming and uses a large resolution which hides or nullifies the issues and inaccuracies I mentioned earlier. Now go make perfectly accurate and bug-free Super Metroid engine and tell me the platform behavior is ideal ^^;

NotionGames

Good job! Love the game. Did you get it to wiiU? If I may, the game is fairly typical in the "platforming" sense. I mean that, your need for platforming mechanics was fully solved and contained within the behavior. Anything else you needed could be added on top. That is perfect as a use case. There is no reason why you can't get the platform behavior to work in many projects. But if you have a low level problem with something the platformer behavior does, it renders the whole behavior useless to a project. You can't correct what the behavior does with collision detection or resolution... and so on.

We seem to be getting onto a number of different topics here :T

NotionGames I would argue that a game like Ubi actually is perfect for the platform behavior. It's incredibly simple in terms of platforming and uses a large resolution which hides or nullifies the issues and inaccuracies I mentioned earlier. Now go make perfectly accurate and bug-free Super Metroid engine and tell me the platform behavior is ideal ^^;

Haha. Yes, you are definitely correct. It is a pretty simple platformer. It was mostly designed around what could be done with the platform behavior so yes, I don't know the low level problems that are going on. So I pretty much don't speak of them haha. But I do take your word for what issues you are experiencing.

NotionGames

Good job! Love the game. Did you get it to wiiU? If I may, the game is fairly typical in the "platforming" sense. I mean that, your need for platforming mechanics was fully solved and contained within the behavior. Anything else you needed could be added on top. That is perfect as a use case. There is no reason why you can't get the platform behavior to work in many projects. But if you have a low level problem with something the platformer behavior does, it renders the whole behavior useless to a project. You can't correct what the behavior does with collision detection or resolution... and so on.

Thank you! I am actually redoing a lot of things and releasing Super Ubie Island REMIX. Level design touch ups and blah blah..

Back on topic. I couldn't get the game working on the wii. Just too high resolution and stuff going on. I'm just assuming that is the issue. My other smaller games work just fine though. I should probably do like Tokinsom and start making pixel platformers to hopefully reduce the amount of resources needed to run. I went through with a programmer and did a bunch of performance tweaks but the framerate is still a bit too low to properly detection collisions, resulting in unwanted deaths. :/

NotionGames - that is a shame. I wanted to release a game on the wii but I haven't bought the dev kit yet. I was kinda hoping to release on steam and then move to wii in funds permitted. I suppose the high res stuff could be a problem.

Last I heard WiiU doesn't support WebGL so, like, 99% of C2 games are out of the question. Paired with the NDA I don't think C2/WiiU is really much of a thing.

Colludium Ahh, I didn't realise you were using physics so extensively. When I spoke about making your own physics I just meant faking it so you can cut the behaviour out altogether. I had a quick look at your game and now I can understand the frustration you are having.

Ruskul It does make sense, maybe I am out of touch. While I personally would like development to go towards expanding the multiplayer object, I cant argue that offering more avenues for fine tuning some behaviours wouldn't be in Scirra's best interest (especially considering those who don't know how to code or event will be reliant on them to start with).

Well, when I think of modularity, instead of A'la carte behaviors, I think of the plugin sdk using events.

Pretty sure you'll get all the behaviors you can dream of then.

Why are we even talking about plugins and behaviors, a more important issue is the export options!

I have several games waiting to be released. And i have optimized them all for around a half year. Still not good enough for a release... We need a Custom Scirra Exporter or Scirra could buy Cocoon.io and develop it

Nah, nevermind. - I'm dreaming

Talking about exporters is a waste of time, C2 exports HTML5, and it does it well - wrappers are the order of the day when it comes to cross platform support, and Scirra doesn't make wrappers, so it's a null point.

Asking to have more open ended behaviours, or an "unlocked" mode for non-beginners is more reasonable.

Ashley

The issue is not "cookie cutter" feature or "general-purpose", or event-base behavior.

The issue is "how to reduce programming cost":

• "cookie cutter" means users will program with pure events if they need new feature.
• "general-purpose" means users might add some or a lot of events to match their requirement.

( Some time they will never get it, so they will ask pure event-base behavior, I do not agree official plugins are "general-purpose" already, since users still could not reach their targets. )

• "pure event-base behavior" means a lots of events.

The better solution will reduce events in all cases.

A possible solution is start at pure event-base behavior-- "how does users modify it for new features?" Then breaking it into plugins(behaviors). Finally it will be a plugins-system which left some hooks for users to add new feature by events or by plugins-- It is not a single plugin or behavior, it is a reuse-able architecture.

Do not trapped by "single plugin/behavior", this kind of solution does not have enough flexible. Sprite(plugin) could have behaviors like extending slots/decorators, how about behaviors' extending slots/decorators?