Disappointed over bad communications!!!

[quote:17azthjc]We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform.

I disagree with that statement completely. Reliance on third parties is only bad if you suffer from vendor lock-in (which we don't, by the way, the closest we get is over-reliance on chromium, which isn't even that bad since chromium is FOSS). What you're calling "third parties" actually means "abstraction layers" in this context, and those are the holy grail of computing, and has been that way since its inception.

It is obvious that the more layers of abstraction you have between you and the metal, the slower things are, but the more layers you remove, the more you start finding that writing software borders on the impossible, culminating in "real programmers use a magnetized needle and a steady hand". For example, buggy and bloated as graphics drivers may be, no one would dream of ditching them and pushing raw instructions directly to the GPU, even if those ended up being a thousand times faster than going through the drivers.

Same goes for the myriad of third-party-reliant technologies used by Scirra to provide fast turnaround, easy gamemaking capabilities and seamless portability. To implement those by hand would require titanic efforts that a solo programmer just can't cope with, regardless of his "rockstar" status. Ashley has stated multiple times: bringing feature parity to a native exporter amounts to writing a browser engine from scratch; and lest anyone thinks this is easy, remember that Opera is basically a wrapper nowadays, even their multi-man team and 2~3% market penetration (which is huge when you consider the numbers we're talking about here) wasn't enough to convince them to stay (nevermind "switching to") in-house.

If we go by what the market is showing us with regards to other game-making tools, as soon as you start writing native exporters, your product is frozen. Feature development slows to a glacial pace and all efforts are shifted to attempts to bring feature parity and bug fixes.

Fimbul

Construct Classic, Craft Studio, Game Develop, GameMaker 6, Clickteam products (MMF, TGF, etc), Godot, and many other small-team-engines perform very well and generally use less layers of abstraction than Construct 2.

I'm just pointing out that the less layers involved above DirectX/OpenGL, the better the performance and control over his own program that Ashley will have.

Of course going down anywhere below C++ and a graphics API is entering into layers that I would never expect a lone developer to code for, but pretending that HTML5 works how it was supposed to at the export side of things has to stop.

Maybe if there was one console that could actually run REAL games (made in HTML5/WebGL from C2) well then we'd all be happy, but as long as everyone is using a million different devices and platforms, the ability to have my game work badly across all of them is no good compared to just one export platform running perfectly across the majority of my customer/userbase (eg: after they have been determined to have met a minimum of specs and updated their graphics drivers to the latest version and updated their DirectX and Windows Updates, after that point I should rarely ever see a complaint about bad performance)

If we go by what the market is showing us with regards to other game-making tools, as soon as you start writing native exporters, your product is frozen. Feature development slows to a glacial pace and all efforts are shifted to attempts to bring feature parity and bug fixes.

I can do enough in Construct 2 to make my games, the bug fixing and runtime performance is all I need to be happy. Editor-side C2 works way better than any engine as-is for 2D games. I see no reason to update the editor aside from making it easier for plugins like Quazi's Q3D to control more of the GUI.

In fact, C2 was supposed to support multiple exporters during its early plannings, rather than just HTML5 (...)

Admittedly, I missed the early adopter phase and have no CC background, so I have no idea what C2 was supposed to be in the beginning. When I bought in Sept. 2012 I was looking explicitly for a HTML5 engine and it was relatively clear that native directx was off the table.

But if as you say this evolved from another announcement entirely, I can partially understand the frustration that some people seem to experience.

I'm just pointing out that the less layers involved above DirectX/OpenGL, the better the performance and control over his own program that Ashley will have.

Yes, but at the cost of development speed. Also I think "control over his own program" is a bit of a dubious statement. By giving up on code provided by browser vendors to work around limitations, bugs and incompatibilities between different configurations/hardware setups, you're absorbing responsibility for overcoming those problems yourself, polluting your codebase with patches. The way I see it, you lose even more control over your own codebase, since you keep having to put dirty hacks to make it work with another set of "third parties".

Of course going down anywhere below C++ and a graphics API is entering into layers that I would never expect a lone developer to code for, but pretending that HTML5 works how it was supposed to at the export side of things has to stop.

The future (for now) is javascript, that much is pretty clear - the discussion is whether things are moving at an acceptable pace (you say they're not, I say they are). Unless something changed and I didn't notice it, tech such as NaCl and PNaCl aren't moving forward. Even if you think HTML is a bad choice, what other option do we have? Haxe is a pile of garbage documentation-wise, just look at their tutorials and try to follow along - it looks like a graveyard of broken changes - nothing ever works like the docs say they should, and even the standard library is unstable, not to mention the libraries/packages (which are third parties, btw). So what about a native exporter for Android? Well there's no such thing: android apps run on top of a virtual machine, and even before that mobile games used to run on j2me which is now extinct. I pity the ones who developed an exporter for it. Oh wait...

Maybe if there was one console that could actually run REAL games (made in HTML5/WebGL from C2) well then we'd all be happy, but as long as everyone is using a million different devices and platforms, the ability to have my game work badly across all of them is no good compared to just one export platform running perfectly across the majority of my customer/userbase

That's the whole point. Everyone wants that. Your choices are:

• Haxe - broken spec, outdated/wrong docs, small community, not production-ready
• Java - they haven't delivered on their promise of "write once - run everywhere" yet, why should they start?
• Air/Silverlight/whatever - so, like, wrappers? Also, as you can see, they're all dead by now
• HTML5 - big performance leaps every year, growing capabilities, multi-billion dollar investments, humongous community, and we already have dedicated HTML5 devices

I can do enough in Construct 2 to make my games, the bug fixing and runtime performance is all I need to be happy. Editor-side C2 works way better than any engine as-is for 2D games. I see no reason to update the editor aside from making it easier for plugins like Quazi's Q3D to control more of the GUI.

The runtime already does nearly everything I want it to do, it's the editor that gets in the way. Developer time is much more valuable than machine time! When I making/use external tools to simplify development I feel like it's a huge waste of time, that I'm fighting the IDE more than being aided by it, especially considering there's no easy way to integrate tools to the IDE (without going through ashley, a la spriter) so you're forced to close the editor before using them (since they modify the XML directly). The interface is the biggest hindrance for gamemaking for the kinds of games I like to make.

Performance on the desktop, at least for me, is great. Mobile games have good performance as well, even on my comparatively ancient Galaxy Note 2, provided you keep in mind that mobile devices are basically toys

Pictured: a modern mobile device compared to a modern desktop computer

Most mobile games are a joke, the top selling games rarely have more than 50 sprites on-screen at a time, and yet you see people here wanting to create mobile games with 1000 sprites, all with physics enabled and two/three effects, and hand-painted full-hd rotating backgrounds. Native isn't going to get you there, and even if you were a programmer god and could create and engine entirely in handwritten ASM, I doubt it would do it either.

If only people would publish their games for others like me (or Ashley) to pick apart, we could point out the problem and optimize them. Heck, I might even sell that as a service.

Don't forget that C2's engine isn't just Javascript being interpreted by a browser, its events being interpreted into Javascript, that is being interpreted into machine code that uses all kinds of third party code, png, wavs, etc.

What's amazing is that it works as well as it does.

To me the only question is what can you do with it?

Fimbul

If only people would publish their games for others like me (or Ashley) to pick apart, we could point out the problem and optimize them. Heck, I might even sell that as a service.

What is the point of using C2 then, if we need professionals to make our games work well on mobile devices?

Only to create games that work well on desktop pc's but not on mobile without professional help is not what you expect from an engine that tells us:

You can now make advanced games without writing a line of code. Construct 2 does the hard work so you don't have to... ...True multiplatform support. Build your game in Construct 2 and publish it to all these platforms...

.

I really think that Ashley did a great job making it possible to create games that easily, but if we cannot make "big" games with a lot of sprites, that would mean that C2 just focuses on the most simplistic and smallest game mechanics in order to work well with great performance on mobile devices.

Performance on the desktop, at least for me, is great. Mobile games have good performance as well, even on my comparatively ancient Galaxy Note 2

Most mobile games are a joke, the top selling games rarely have more than 50 sprites on-screen at a time, and yet you see people here wanting to create mobile games with 1000 sprites, all with physics enabled and two/three effects

How do you export your mobile games?

Cant confirm this. My sample with 2 sprites, 1 has bullet behavior is jerking on PC using chrome and on galaxy s4 exported with intel xdk crosswalk <- prefered method by scirra

So for me it has nothing to do with 1000 sprites.

There are 100 of posts where people are wailing about the performace on android....

At the risk of sounding like a stupid ********

In my honest opinion, Ashley needs to stop dreaming about new features to add, editor improvements and stop developing Construct 3

...

That is exacly what was in my mind, thank you for posting this!

Now it would be nice if we get a response.

>

> > At the risk of sounding like a stupid ********

> >

> > In my honest opinion, Ashley needs to stop dreaming about new features to add, editor improvements and stop developing Construct 3

> > ...

> >

>

> That is exactly what was in my mind, thank you for posting this!

>

The part about me being a stupid ******* or the second part?

Second part of course

I never wanted to sound like I'm angry about C2 at itself.

I just wanted to say that if we pay 100€ (in my case), get a 1st class game editor and tons of possibilties to make games, we expect the game to at least run stable and bugfree on every plattform that is mentioned and promised, not only the PC.

I think what is happening to Construct 2 is basically what happened to Construct Classic. It's buggy, unfinished but Ashley has moved on to Construct 3, leaving behind an unfinished product with which only a handful of developers, if even that, made a succeeded game with.

CC - Iconocaust (or whichever the name was, didn't remember it properly) and Minitroid (non-commercial, apparently was a nightmare to make).

C2 - The Next Penelope, Cosmochoria, Airscape

Correct me if I'm wrong, but in both iterations of those Construct programs, haven't the developers of their games left Construct while Ashley moved onto the next iteration?

At least with the transition from Classic to 2 we were getting a new engine and language. From 2 to 3 we're getting a new editor.

When the transition from 3 to 4 comes what are we going to get then? An improved toolbar?

I don't know C1 that well, but I heard it had a lots of crashes and a bad exporters and that was why the development stopped (correct me if I'm wrong).

And I'm afraid of C2 happening the same...

You should not blame beta releases, because that's what they are "beta releases". It's quite normal for them to have bugs.

As of the rest... I really do not care anymore, after all posts I made and read

I'm just glad I'm working on a project that don't need high or steady fps to work, but current wrappers situation (that lasts 3 or 4 months already!) is just a big lol.

Q3D is nice and all, but it's just too damn confusing. I bought it, tried to understand it for whole week and then I gave up. Now if I need some 3d for desktops I'm happily using UE4, where things do work like I want them to work and always at 60 steady frames per second for me and others. So yeah C2 is currently my tool for making small, stupid and slow mobile and web games.

I think what is happening to Construct 2 is basically what happened to Construct Classic. It's buggy, unfinished but Ashley has moved on to Construct 3, leaving behind an unfinished product with which only a handful of developers, if even that, made a succeeded game with.

There's a lovely thread but kind find it now, about Node Webkit working "fine". There's a lot of nice posts in there about C2, exporters, and almost very same thing like in this thread. As far as I can remember, the ultimate answer to everything was something like "it's just a bug, they will fix it (chromium team) eventually". And guess what? They did. They fixed it. Everything was perfect.... for two or maybe three months

To be fair, construct 2 works really well in browsers. The major complaints i see are with people using construct 2 for mobile games, a place they will not excel because of hardware constraints that make even java-script itself perform poorly. If you want to make a game for mobile with javascript you absolutely have to scale back and be very frugal with the resources you use.

Mobile games aren't complicated, and that's because you really need to develop them from the ground up to get any kind of good performance. Making a complicated mobile game in C2 is easy, however it wont work because it's too complicated. The more difficult an engine is to work with, usually the better the performance you can squeeze out of it but the slower your development will be, ESPECIALLY if you are inexperienced.

You could very easily code a fast HTML5 game for mobile, however you wont have the wonderful abilities like picking which construct allows you to use, you'd have to build the game in an optimized manner. If your game is GPU bottlenecked, then that's going to be a problem no matter what. There's a lot of inexperienced developers using C2 (which is understandable) and they end up complaining that their game is working poorly because it works on desktop "just fine" but dies on a mobile platform. The only answer that can be given is that their game is trying to do too much, regardless of if it's doing "a lot less" than other games they've seen on the platform.

As an example, anyone familiar with demoscenes will understand that some people can squeeze a ton out of very little. Take for example classic c64 games and their graphics, and compare them to some of the more impressive demos for c64:

demos:

vs.

games:

A lot of low level optimizations that have to do with using smart memory structures and reusing data in an intelligent way mean you can get "way more" out of something. This is what mobile developers manage, even if they're using html5+javascript from the ground up, vs construct. Construct 2 will allow you to very easily trim down recursively through lists of objects with picking conditions / actions, however the fact this is used everywhere to make events "easy to use" means the performance suffers, ESPECIALLY on weaker platforms where performance is constrained. Things like "creating" and "destroying" in construct are very high level and generally expensive even with the recycling systems in place. They're general so that when something is gone it's gone and everything knows it's gone, however this is expensive compared to just pretending something is gone and controlling at a low level. In most cases a game with limited actors could much more efficiently be constructed by having a short array of references and never having to really pick anything.

To top things off, most people abuse the hell out of collision detection in construct since they have a poor understanding of the costs associated with it and the mechanisms behind it's operation. It's very easy to blindly apply collision detection throughout code for repeated conditions, but really most engines have a SINGLE collision detection run per frame because it's so expensive, when in construct you can end up with many many many collision detections per frame, which make things "tighter" at tremendous cost. Behaviors are also a big issue because of how general they are, the expense they incur quickly adds up.

If you want great performance, you need a powerful platform, or you need to fine tune your game from the ground up, there's no magic bullet and complaints are misdirected for the most part.

shinkan

Q3D is confusing because of the limited editor SDK of C2, so if people want powerful plugins with good editor integration, im afraid supporting C3 development is the only way they can do it... Regardless Q3D is constantly improving, and hopefully i'll have time to get some documentation out after the next update which finalizes a lot. I can guarantee using Q3D is way easier than trying to make a 3D WebGL game directly, and it works quite well at achieving that goal. In any case UE4 and Q3D have entirely different purposes, UE4 doesn't really work in browsers, regardless of what their poor HTML5 emscripten demos that barely work try to prove, they really aren't trying to make an engine for WebGL.

Q3D is confusing because of the limited editor SDK of C2, so if people want powerful plugins with good editor integration, im afraid supporting C3 development is the only way they can do it... Regardless Q3D is constantly improving, and hopefully i'll have time to get some documentation out after the next update which finalizes a lot. I can guarantee using Q3D is way easier than trying to make a 3D WebGL game directly, and it works quite well at achieving that goal.

I'm all aware of that my friend. You have put tremendous amount of work to make this plugin happen and it is really great and powerful . But unfortunately, currently C2 is not making it any easier to use. I never found your plugin hard to use - speaking about event logic. But rather what confuses me a lot is C2 editor itself, placing 3d object in 2d inverted space is not fun for me at all. That's why I stopped using it, not because it's bad but because it takes too much time from me to set things right. That's why for time being I choose UE4 to do 3d stuff only cause i can do what I want faster and in full 3d space. I know I could build myself a nice 3d editor in C2 and use it to for my needs, but that's not the point here. I really hope I could use Q3D in a nice environment

"Mobile games aren't complicated, and that's because you really need to develop them from the ground up to get any kind of good performance."

And that is true as well, people tends to forget about that. But again current crosswalk do not help making even that easier, while having problems with almost empty projects