Construct 3 - many questions (native exporterts)

Aphrodite ahh I see, I understood it like you were talking about all "buyers" from the initial release .

In that case I see no reasons to not agree with you.

Expectations for native comes from scirra.com main page itself - "Build Once. Publish Everywhere. True multiplatform support. Build your game in Construct 2 and publish it to all these platforms." statement.

Don't know why but people these days forgot how to read and use their logic. Instead of finding out more info about the product their will go ahead and download/buy it. And only after that they realize that this is not exactly what they thought it is. Free user have a bit better situation because they can only export to the web, so all is fine here. How game will work will mostly depend only on the browsers. But people who bought it before reading/thinking will hit the wall right away. So yeah scirra should really figure it out.

Also i noticed some part of my previous post did not show so I'll put it here again.

Web export. Yes. For me It's like an Image Editor. Add it, if it work leave it, make some occasional fixes and small additions, forget about it. There's so much stuff missing I don't even know where to start...

And just like Construct was Construct 2 will never be called a finished product. Complete product have some kind of a road map that goes from A to B and either as a developer you can make and release a full product - like most people used to do in the past. Or release it as a very popular these days "early access" scheme . Which is not bad (well not in every case) because it lets you play with it while devs have time and money to finish it up. But it still means there is a point B somewhere. Unfortunately there was only point A with C2 (and CC) there is no point B and will never be. And i don't really like it cause I don't know what to expect in the future.

With some sort of a to do list we could tell what and when to expect from it, What was done, what is in development and what are the plans for next months. But not here. It's all just one big experiment. If Ashley is in good mood he may fix some issues, if he is not then he will say "it's not compatible with our UI library"

C2 will end up just like CC did. One day they will announce "This is C3. We will no longer support C2 from this day. Buy C3 or stick with old unfinished C2"

To be honest I will not fall into that trap again. I will get C3 only if I see some sort of a road map or to do list with time tables, that will let me know what and when to expect from it. I will not spend my money on something I was told I will get just to read many months later "yeah, sorry but no" again

PhoenixNightly I agree on the fact no programming knowledge is needed to an extend, however most issues with users seems to come from three facts:

-Sometimes they did not designed the part they want to implement enough and so, do not know how to implement it (if someones want to build a car or a bike without any plans, well good luck, if they did plan ahead it becomes much more easy as you just have to do it, same goes for C2, if you do not know enough what you want to do, you cannot simply translate it to the event system, some call that designing part programming or coding but I disagree, it is more designing at that level as you do not have to take any limitations in account at first, only when implementing it).

-Sometimes they did describe it fully, but just have no idea how to implement it, in which case asking the forum often solves that issue.

-sometimes they either implemented it wrong or relied on a specificity of the system they should not rely on but think it is "fine enough".

Aphrodite

Absolutely correct

Aphrodite ahh I see, I understood it like you were talking about all "buyers" from the initial release .

In that case I see no reasons to not agree with you.

Expectations for native comes from scirra.com main page itself - "Build Once. Publish Everywhere. True multiplatform support. Build your game in Construct 2 and publish it to all these platforms." statement.

Don't know why but people these days forgot how to read and use their logic. Instead of finding out more info about the product their will go ahead and download/buy it. And only after that they realize that this is not exactly what they thought it is. Free user have a bit better situation because they can only export to the web, so all is fine here. How game will work will mostly depend only on the browsers. But people who bought it before reading/thinking will hit the wall right away. So yeah scirra should really figure it out.

Also i noticed some part of my previous post did not show so I'll put it here again.

Web export. Yes. For me It's like an Image Editor. Add it, if it work leave it, make some occasional fixes and small additions, forget about it. There's so much stuff missing I don't even know where to start...

And just like Construct was Construct 2 will never be called a finished product. Complete product have some kind of a road map that goes from A to B and either as a developer you can make and release a full product - like most people used to do in the past. Or release it as a very popular these days "early access" scheme . Which is not bad (well not in every case) because it lets you play with it while devs have time and money to finish it up. But it still means there is a point B somewhere. Unfortunately there was only point A with C2 (and CC) there is no point B and will never be. And i don't really like it cause I don't know what to expect in the future.

With some sort of a to do list we could tell what and when to expect from it, What was done, what is in development and what are the plans for next months. But not here. It's all just one big experiment. If Ashley is in good mood he may fix some issues, if he is not then he will say "it's not compatible with our UI library"

C2 will end up just like CC did. One day they will announce "This is C3. We will no longer support C2 from this day. Buy C3 or stick with old unfinished C2"

To be honest I will not fall into that trap again. I will get C3 only if I see some sort of a road map or to do list with time tables, that will let me know what and when to expect from it. I will not spend my money on something I was told I will get just to read many months later "yeah, sorry but no" again

Spot on!

*signed

I think this topic should be on top before we get official answers.

"Our goal is to make Construct 3 the best game making editor ever" more like the best prototyping tool ever

"Our goal is to make Construct 3 the best game making editor ever" more like the best prototyping tool ever

Construct 2 has the potential of making small, and big games, if people tends to do prototypes, just because its using cross platform exporters that doesn't mean you cant create actually great games with it. and 90% of the time in a game all that matters is the graphics. so.. c2 is the tool of freedom for game artists, ... and enhances the abilities of a advanced programmer, you can create ur own plugins that can do anything, even a serious game engine function that will save u a lot of events and make it run very smooth, but then u need to know JavaScript and to work with the SDK that scirra offers, the quote u said its just a poor opinion i say no offense intended.

you can make from 2d to even fast 3d games with c2 in the current stage, i can only imagine the performance enhancements that C3 will bring, im guessing no more cross platform exporters that will be the most useful thing in my opinion and a 3d viewer for 3d games, maybe default implement the q3d functionalities and make it more simplistic to use, but the rest is just perfect as it is.

the quote u said its just a poor opinion i say no offense intended.

To be honest I was just joking, I really like C2 it's one of the best and easiest tools that I ever used... but now that you mentioned it, C2 doesn't perform as advertised.

So I need to know javascript to get good performance? I might as well just program the whole thing in javascript then.

It doesn't matter how you guys try to hide it, it's impossible as of now to get good performance on a complex game, I tried for weeks.

But what about those successful games that Scirra advertise? Yes, I admit that some of them have good performance but if you think about it, those are not very complex games, those are just pretty games.

If you use physics your frame rate drops a lot, the same applies if you use many animations or have multiple AIs, etc etc

I did many test with other engines like unity, game maker, clickteam fusion, stencyl and the performance is huge compared to what I get with C2, even without optimizing the assets or the code for better performance.

Please don't send me to a performance tips tutorial, because I tried every single tip and C2 it's just not build for it. To be fair whats not build for it, it's the technology... I'm pretty sure that in a few(many) years every device it's going to run html5 at 60 FPS without any issues.(or maybe not)

Some users say that it's not scirra's fault, because all of the exporters are third-party and many issues come from there... well, perhaps they should work on their own exporters as they advertise? "True multiplatform support. Build your game in Construct 2 and publish it to all these platforms." a third party wrapper is not true multiplatform support.

In conclusion, I'm not trying to make C2 look bad or anything, I just want to tell the truth because I found out about all these issues after I purchased C2 and I don't want this to happen to other users, they need to know the truth before spending their hard earned money. C2 it's a great tool, very easy to use, you can program pretty much anything that you can imagine(even if you are just a beginner) but you have to know it's limitations and be really careful about the performance, try not to make very complex games, and if you are planning to make a very complex game, you should look somewhere else because C2 it's not the right tool for it.

If you're getting better performance out of Stencyl, you're doing something wrong with C2.

Share your work, everyone has blind spots.

You are saying that stencyl performance is worse than C2?

I have to say, that stencyl was one of the top performers on my tests.

They are currently running under OpenFL and the performance is awesome!

And just to be clear, I don't use stencyl to make games or anything, I don't even own it. (I just did some heavy testing on it)

You can find a couple stencyl games here and you can see that they have great performance, I'm not even sure if C2 can handle something like ghost song... (i don't think so)

http://community.stencyl.com/index.php/ ... 809.0.html

http://community.stencyl.com/index.php?topic=36539.0

droxon

Are you focusing on HTML5 performance on mobile or PC?

I'm making what I like to believe is a complex game (at least CPU-wise) and I have hit so many performance issues that cause the fps to dip below 60fps, but almost always discover it was my own fault and end up resolving them. I'm maintaining well above 60fps on NW.JS on a game that has a lot of collision stuff to deal with. Also, I do not write my own plugins or know how to javascript.

Also, it'd be realllllllll cool if you could send those tests from all the different software to Ashley or something, maybe a build as well as the source files. Assuming your tests are right, that would surely encourage Ashley to focus a lot on performance, but as I stated above, I'm personally not having performance issues from C2 itself. It's usually my fault.

I admit, when I try for hours to get a few extra FPS when it is dropping, I start to blame C2, I start thinking "Goddamn the collision engine must be so crap, howcome MMF2 does it so much better!!" or "Damn what's the point of WebGL if it just lags after like 4 effects!" or something, but then I remember I did have performance issues with MMF2 at points (even with collisions), and then I eventually discover where my problems lie (usually something like trying to do collision detection with like 200 objects every tick or something that didn't seem obvious at the start, or just understanding the concept of how shaders work and some shaders need more processing than others) and then I take a different approach or rework it and volia! problem solved.

Not gonna lie though, I had a nightmare with mobile, but that was about a year ago, must be better now.

.... usually something like trying to do collision detection with like 200 objects every tick or something that didn't seem obvious at the start....

Same here.

In most of the performance issues, I found that selecting the right objects, and not all of them, and not every tick, generally solves most performance issues for me. (like: Profiling group speeds going from ~10% to ~0.5%)

Picking's, on layers, on screens, comparisons, booleans states, can all greatly enhance your performance if applied correctly in situations with lots of objects.

I believe the amount of objects handled at one time is the main culprit when it comes to the processing bottleneck clogging up.

After that lots of big images ...

droxon You can make the same games in construct 2, perhaps some different approaches to get the same results.

But don't you notice that your frame rate drops every few seconds? even when your game it's running at 60 FPS it still drops a few frames and it's very noticeable, it looks awful.

I've been that road, you said it your self... you are getting a lot of performance issues. I just hope that you don't hit a brick wall just like I did, I ended up wasting my time.(currently porting my game to another engine)

I tried contacting the scirra team, but according to them C2 performance it's perfect. (it's always the user's fault) with other engines you don't have to worry about that as much.

I mean, with every engine you will get performance issues... its inevitable, but with C2 you just get to a point where even some simple things start to cause performance issues. You have to focus more on performance, rather than the game creating.

An html5 wrapper doesn't perform as well as a native .exe, it just does not.

I encourage you to test your game in multiple computers, at least on my case the game didn't perform as well on other devices.

lennaert

Yeah, very similar experience to me. This sort of thing is still vital even in something like MMF2 which runs natively, I managed to ruin my framerate due to bad programming and too many collisions per tick (which at the time, I thought I was doing just fine and blamed MMF2). Ironically, that's one of the reasons I ended up finding Construct 2, because I got fed up with MMF2, even though it wasn't MMF2's fault (except for the annoying workarounds in MMF2 of getting more Alterable Values, spreading a number so you can pick them, etc., C2 is a lot more straight forward and removes limitations which is awesome).

droxon

I know what you mean, the jolty look when a frame is dropped is very noticeable and unacceptable, I seem to get it with Chrome but not NW.JS. Not exactly sure why, considering NW.JS practically is Chrome...hmm...

Yes, I get performance issues, but I mean it's not C2's fault, it was my own fault because I was an idiot and made some dumb choices in the way I chose to program that I seriously believed wouldn't impact performance. It's important to remember that if you are making a large game or a complicated game, then, in order to have this large complicated game stay smooth, you have to accept that you need to keep a close eye on performance and be very cautious, no matter what engine or software you use. (Personally, I find it fun to program and try and squeeze performance out of things, it's satisfying when you discover what causes the problem and then fix it. It's part of the whole "Game Creating" experience.)

Perhaps, one engine might handle collisions much better whilst being worse at having more sprites on-screen, whereas another engine might handle object picking very well but struggle with collisions in comparison. Things can always be improved on by the software developers, though.

Honestly, a handful of months back, I had tested on weaker systems, like an old laptop with an intergrated chip thingy, and a weak dualcore. It performed TERRIBLY, until I discovered that shrinking the window so it is tiny, made the FPS reach 60. Then realising you can shrink the canvas in events and then zoom into the layout to get the same performance boost. THEN eventually Ashley added that "Low quality" mode in the project properties, THAT was exactly what was needed. The dualcore wasn't the bottleneck even though there was a lot of CPU stuff to do, like iterating through tonnes of sprites and positioning + angling each of them, but it was the GPU that caused problems (mainly because it didn't exactly have a GPU lol)

... Performance issues

never mind... someone else answered u.. and for the game u showed,

it is possible in c2 yes it is and runs even better, check for Penumbra Alpha v2 its similar....