Construct 3 - many questions (native exporterts)

Unfortunately remaking the game core, wont help much i think. Scirra still rely on third parties to export on mobiles and pc. And many of the issues stem from there.

Aphrodite

E.g. setting up events to pseudo-remove slope detection from the platform behaviour, so the player can fall down gaps properly.

(At least 3 large projects are using this, with a bunch of smaller scale users talking about it).

E.g. Having to use "Button is down, trigger once" conditions for the keyboard instead of "On button press" because the latter bugs games (My bullet spawning at offset bug report covers it).

There's tons of examples in the forums, you just gotta look.

Unfortunately remaking the game core, wont help much i think. Scirra still rely on third parties to export on mobiles and pc. And many of the issues stem from there.

That's because Ashley's too lazy to fix present features, instead he's overdosing on bleeding edge features that break a lot of everything.

nimos100

"- That so many things requires workarounds to function is at least on my very top when it comes to C3, spending close to 70-85% of the time when using C2 creating weird workarounds are really not something that makes C2 shine."

Exemples? (not asking for a bug report, just what you had to work around so we understand the issue so someone could correct that, as workarounds are the opposite of good design)

There are so many, so ill just name a few.

• Video not loading correctly if you set the source during runtime it requires a workaround to make them appear. (Only works sometimes, so have to make another workaround for that again)
• Images not loading correctly, meaning they overwrite each other. Scirra say its on purpose, but personally I would consider this a bug, as the functionality that you expect doesn't work as intended. Now this gets even better when using animations, as you then have to add animations rather than just frames to avoid them being overwritten. Making the whole load from url completely static, which is a bit weird as you would assume that one of the reasons why you would load something is because you need it to be dynamic and not static.
• File handling (Nwjs, file chooser) getting required/expected information.
• Audio can't be loaded in runtime. So a workaround having to use a video object works, however it removes all the benefits of using audio.
• Pinning several objects to each other causes problems, due to objects pinned are updated to slow. Meaning if you have obj1 and you pin obj2 to that and obj3 to obj2. Obj3 will lag behind looking like there is a performance problem, due to it not updating fast enough, dragging around object already is rather slow so using pin with it makes it really slow. So fixing that, you have to pin everything to 1 object. And in cases where you are making something more dynamic you would have to use a control object to fix it and reduce the slow effect.
• Path finding....simply to buggy to even start on that, but just needs to be mentioned.
• Video playtime, is not updated correctly if a video is paused and you tell it to change playtime it will not update until you reactivate it.
• Video playtime is not correctly paused, if you play a video and then pause it during play, it will pause the video, but if you reactivate it, it will jump forward a bit of time. This is stated in the manual as a problem if I recall, but with the amount of video players and graphic tools I use I doubt that this is something cant be solved. At least the other programs doesn't seem to have a problem with this. Haven't gotten around to making a workaround for this yet. But guess it will be something with trying to subtract the amount it jumps from the playtime, but doubt that it will work.

Anyway this are just some of them, smaller ones constantly pops up, so its hard to keep track of them all. But a lot of the issues I have added to another post about updates to objects in general, which in a lot of cases are a result of workarounds or general things I have spotted while working with them, trying to do something that C2 can't do, but should be able to in my opinion.

It's quite interesting to see people complain about plugs, and say they are migrating to platforms that require coding.

It's quite interesting to see people complain about plugs, and say they are migrating to platforms that require coding.

Im complaining raising awareness of different problems, because I want C2/C3 to be better, and in general I love it, but as with any program you use you notice things that you ought should be fixed or better. So even though people are complaining, its good information for Scirra to get if they react on it.

But you can't really argue against people looking for other programs, even if that requires them to learn something new. I mean you would do the same with Word, Open office etc. if they didn't work as you wanted them to. So at least for me I fully understand people that want to give some of the others kits a try.

nimos100 thanks.

Nesteris I was asking because just looking is not enough as in a lot of cases it seems to be a misunderstood of the feature, not it not working correctly, the platform behavior slope by itself is not a bug, just something not wanted , the not being able to fall however is one (if it could be redone however I would not mind, I remember it breaks the point of having a platform you can fall from with the jumpthru behavior, as you can climb back on it too, being able to keep slopes while correcting that would be far better), the on key pressed is a trigger and so is meant to happen before anything else (it happens at the exact time you pressed it, where key is down waits the next check), however being able to choose when to refresh behaviors would prevent that issue I agree (That would also fix the pin issue).

That's because Ashley's too lazy to fix present features, instead he's overdosing on bleeding edge features that break a lot of everything.

I don't think "Lazy" is the right term here. With the amount of updates that come out for C2 I don't think you can call anyone working on Construct lazy. That being said, as a (Mostly silent) observer throughout all the threads talking about all the exporter issues/bugs, I think this comes down to a rather large divide in the direction the developers are going and where customers want the product to go. The developers seem to want to focus on HTML5 and providing constant updates. People want to be able to release their games in several different formats and having it work correctly, not just on browsers.

Some are saying this is just because those complaining are not good enough at coding. But to those people, I ask you: Wasn't the whole point of using Construct to make the process of programming simplified? What's the point if you have to jump through hoops anyway? I think that having to use wrappers complicates things a lot as well. It causes the size of your game to balloon and a lot of bugs pop up that wouldn't normally be there. Is that really a regular part of programming? I am no programmer so this is a serious question.

Just my 2 cents, though it may not be worth much. It's just frustrating how there's always a catch. Construct Classic made it so that I could actually create games without programming knowledge, but it had too many fundamental issues to release a full game on it (eg. Can't do full screen without sacrificing paralax. Ouch!). Construct 2's event sheet system is unparalleled, in my opinion. It destroys GMS and Stencyl as far as I'm concerned. However, the lack of native export will end up hurting my game if I try to release it as a download or mobile. So I am limited to browser for now. And I think that a lot of people feel the same way, hence all the complaints lately.

It's quite interesting to see people complain about plugs, and say they are migrating to platforms that require coding.

Especially when it's GMS, because I don't think people realize that you can't do anything remotely complex in that program without learning their language, which once again, completely defeats the purpose anyway. Might as well get Unity at that point.

Megabeard

That's a fairly good post.

I wouldn't mind sticking with NW.js as a wrapper, I do mind C2 bugs. As it stands I can't use Preview for Previewing as it's bugged (mostly audio related and it's been going on since r184). Instead of fixing existing features C2 is being bloated with new ones and Ashley is making C3 the saviour, which is apparently going to be Bug-free C2 with a better editor.

By simplifying one part of "programming" games, it needlessly complicated a bunch of others. Sure, you can make a game ridiculously fast in C2, but good bloody luck getting it to work properly on any of the wrappers. Speaking of, when I run my game on desktop (with NW.js, because no alternative), there are three processes of NW.js running, each with at least 50mb. And the game itself is bloated by a minimum of 56MB. GMS on the other hand, I've made a game the size of 1MB total, when I run it there's only one instance and there's never any jank or anything.

I've said it before and I'm saying it again, what happened to CC with C2 is happening to C2 with C3, expect that C3 isn't really a new engine.

Construct Classic made it so that I could actually create games without programming knowledge, but it had too many fundamental issues to release a full game on it (eg. Can't do full screen without sacrificing paralax. Ouch!).

If I just changed..

engine.

Construct 2 made it so that I could actually create games without programming knowledge, but it had too many fundamental/wrapper issues to release a full game on it (eg. Can't do PC export without jank. Can't do Android via Crosswalk 7 because it's banned yet it's the only wrapper with semi-good performance. Ouch!).

a while ago there was a voting for most wanted features, multiplayer and Modularity where toprequests, i still think multiplayer came to soon, or rather modularity should been done before multiplayer, thing was, multiplayer could be done in current engine/editor and modularity not, then multiplayer was done, the only choice left was starting on a updated version of the engine, that can bring improvements to modularity, better search, , and pretty much everything that current editor was limiting, and also, c2 c3 its just a number... its just a bigger update than anything before, lots of software do it.

Regardless of what will happen, i'm still having my fingers crossed that something drastic will happen/change with C3.

I haven't lost complete faith in Scirra! I know you guys can do it, but it requires taking some risks. And most companies will have to take risks to get to the next level!

"Our goal is to make Construct 3 the best game making editor ever" - it's cool, but what about the best game making engine ever?

I think, best game making editor + best game making engine = best game making kit.

If constuct 3 has native exportes, it will become the most popular kit ever, and Scirra will become the most rich devkit making company ever.

Will it have texture distortion and visual editors for it, as well for other plugins/behaviours that need it?

Sometimes you have to think....

Be glad you do not have to buy machine embroidery digitizing software! Embird is a good example.

They update once a year, and every other year they call it a major upgrade that we have to pay for. The changelog is like 5 to max 10 items per update and mostly bug fixes. So basically what Ashley cover in a minor update is same amount as for Embird in their paid upgrade!

The software itself looks like it is firmly stuck in the mid of 90's too with useability in similar level. But I have to use because I paid thousands of SEK for that software + plugins (that should be part of software itself like importers and true type font) and that there's not too many to choose between...

This put things in perspective.

But with that said, of course we want the best.

For even more perspective.

Originally there was to be an sdk for third parties to create their own exporters.

Instead we have third party wrappers that barely work.

People asked for monetisation features, and they got them, for the wrappers that don't really work.

None for html5, the only thing that actually works.

Moral of the story:

You can piss off some of the people some of the time, or

You can piss off all off the people all of the time when you try to make all of the people happy all of the time.

Sometimes you have to think....

Be glad you do not have to buy machine embroidery digitizing software! Embird is a good example.

They update once a year, and every other year they call it a major upgrade that we have to pay for. The changelog is like 5 to max 10 items per update and mostly bug fixes. So basically what Ashley cover in a minor update is same amount as for Embird in their paid upgrade!

The software itself looks like it is firmly stuck in the mid of 90's too with useability in similar level. But I have to use because I paid thousands of SEK for that software + plugins (that should be part of software itself like importers and true type font) and that there's not too many to choose between...

This put things in perspective.

But with that said, of course we want the best.

With respect, i'm pretty sure there are more game making software then embroidery digitizing software. If Scirra were to do this people would simply use something else. The software development market has become very competitive. Not that i don't appreciate Scirras update policy.