I have a galaxy note 10.1 , however wont be using c3 due to the licensing type

Good question

A performance comparison is in order - sooner or later.

XDK/nodejs VS construct3 exporter

> The problem is the payment model and the investment it asks for- doesn't justify a html5 only game engine. Even stencyl - which is very similar in pricing and target audience (perhaps inspiring scirra) can compile to native games and can still export in the free version to one of the targets

>

Construct 2 has so many more features than a lot of these other tools, that I'd actually struggle to make a comprehensive list of them all. This is made possible by the fact we use HTML5. It makes cross-platform support a breeze and lots of sophisticated features like networking, audio and video support are provided by the browser. Some tools don't even have form controls out of the box! When comparing to other tools with different technologies, I think it's important to take in to account the actual feature sets supported. Sure, you can pick a tool which has native export for example, but how many features will you lose or gain?

I think you will have quite a lot of trouble making a list that justifies that extraordinary claim of it having much more features

Just looking at the number of games made by construct2 on the market - or any other pure html5 game engine alone should be proof enough to anyone that it is certainly not a popular choice of serious game developers. Most games on the market are native code. Even the mobile stuff.

the only reason you make the engine purely html5 is so that you don't have to do as much work creating exporters and supporting them. less work for the game engine dev, but not for the game dev using the engine.

Most of the community on this forum has been unhappy by how poor the export to apk/exe is - how inconsistent the game plays after you package it with a web browser in the apk, how much more extra space it takes being bundled with a browser

Meanwhile other game engines - some of which free - offer much more features than construct2 + native exporters +html5 export.

Godot for example is excellent and has you beat on features and architecture for free - but you gotta learn its scripting language/api. Let's not even mention Unity3d and Unreal. Whats the point even.

The only advantage of construct is the event sheet that makes it look like no programming skills are required. This is the honeypot that attracts new users as it lowers the entry point bar to non programmers.

I think you know that very well, as your focus with construct3 was the editor- wasn't it? make it more userfriendly, forget about new API functionality or improvements in the actual runtime. Perhaps some of the weekly updates will prove me wrong - but so far scirra has made it's focus clear - user friendly editor

With that subscription fee model, you are essentially raising that bar back up there on the hobbyists

Please share with us why people should rent construct3 for a year, instead of downloading the unlimited events+flash export free editor of stencyl- developing a game in that instead, and finally buying a sub from stencyl when they are very invested not only in the engine there, but also in the game they have been developing in it.

A free editor with no event sheet limitation and at least one export option for testing is something that will get hobbyists invested in the engine, the more developed their project - the more invested. That will then get them to pay for a subscription/exporters.

The sub fee announcement prior to demonstrating value was like proposing an engagement ring on a first date. Hey, they are plenty of other fish in the sea - also being so pushy is not attractive on a first date

And if my aim is to make money with games, then 99/year is downright laughably cheap!

That's my two cents.

Has anyone on here actually made money from games they created in it? I would love to have a look at some statistics of users who use it as a hobby vs users who make money by selling a game they made in it.

You say it's cheap, but most people, even those who can stomach going rental are pleading for a lower price for first year, more free features or a one time payment offer combined with rent. In the end we can be cynical and say - well yeah- of course they will.

I dare to say that I can afford paying a rent for it, but still think that it ain't worth it. I just don't use it often enough to justify paying yearly and I guess I will use it even less now.

The problem is not the price. The problem is the payment model and the investment it asks for- doesn't justify a html5 only game engine. Even stencyl - which is very similar in pricing and target audience (perhaps inspiring scirra) can compile to native games and can still export in the free version to one of the targets- without silly event sheet limitations or network limitations

The exporters are not built in though, they are on a server

That is actually the very opposite of what this petition thread is requesting.

I guess when people say "built in", they dont care about where the feature is (the cloud), what they really mean to desire is an exporter that was made specifically for construct - even if it was made with the same technology that they have been already using on their construct2's built-in exporters - only NOT built-in c3

The irony of what is requested, how the request is met and the community's reaction just amazes me

I guess in the end the whole point is to make the export process a one click effort

The subscription fee payment model seems to be the single biggest major issue that people have with Construct3.

Scirra will not know if it will have a positive or negative impact on it's revenue until the first year after release. In the end it is really up to the users to make or break the jump by voting with their wallets.

We have done our best to voice our concerns in a civilized way. Best of luck to Scirra. They are damn talented, but so controversial some times

If construct3 has one big advantage, that would be backward compatibility. Being able to use construct2 plugins and effects in construct3 is a big selling point to me

[quote:19rrtkp4]Because the project filetype is binary

That's terrible for team work and subversioning....................

So Construct 3 saves binary blobs that can not be edited externally and are difficult for tracking changes.

Fusion 3 will save project files as simple editable json text files that can be edited externally and that makes it better suited for team projects and github version control.

http://www.clickteam.com/fusion-3-devel ... ?f3id=8769

Will Scirra consider moving to that approach when they release desktop versions of construct3 ?

That would be a feature request that would be beneficial to the users more than the developers of the game engine. <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz">

> Most other game engines support spitting out a native APK that is not bundled with a web browser

>

Construct 2 already supports this as well. Just target Android 5.0+, and it won't bundle Crosswalk, which is what increases the file size. It's only there for Android 4.x support, which is steadily shrinking.

That is worth adding to the FAQ, as some users on this forum see it as a disadvantage of the current exporter

So you have your exporter then.

Yes, the exporter is on their server. This requires a number of things from you and them to work:

• To have paid your yearly subscription
• An internet connection to upload the project to scirra's server and download the resulting apk file (looks like xdk doesn't it) - depending on the size of your project this may have impact on compilation time
• To be on a network that has not blocked access to their domain or appropriate ports
• For their server to be online and not be overloaded by users or brought down by malicious parties such as the ones who have been attacking this forum with spambots

With these new factors, it could be less reliable, but in return you could get a single click export to apk

The problem is that the apk packaged game has a different performance from the game when you playtest it on localhost through the editor.

Tom will construct3 also be able to use construct2's current offline exporters for construct3 projects? All of them?

Construct 3 is backwards compatible and can open Construct 2 projects, Construct 2 will not be able to open Construct 3 projects.

[quote:11zq1mom]Because the project filetype is binary, users will not be able to comment out lines of code that prevent the project of being loaded either.

Construct 3 projects are a mix of binary files and JSON.

Thank you for clarifying this point. I think that it is important to make that clear to construct3 users who think they can just buy construct2 and use that on a project they spent a year on developing in construct3 - only to realize that they are in fact locked to construct3 for that and must instead buy another year of subscription.

That should be made clear prior to them investing in creating their project in construct3. Right now many users are misled to believe they can easily go back to construct2 if they don't like the subscription - without any consequence to their work.

Please add it to the FAQ

This is wrong, the free edition will have limits. You can work and edit games in the free edition up to those limits. If you open a project that exceeds those limits, it will be in read only mode.

You cant do much with 100 events, so it is really not viable as an editor for old projects. The scenario of losing access to working on your own projects in construct3 after the yearly sub period has ended still stands.

As a backup people would be able to open their projects in construct2, if they have it. That way scirra has two competing products on offer.

I am assuming that construct3 made projects will not be compatible with construct2, only the other way around?

Tom does scirra plan to keep compatibility of projects between the two editors?

Will construct2 editor be able to open construct3 made projects and will that compatibility be kept for long?

Because the project filetype is binary, users will not be able to comment out lines of code that prevent the project of being loaded either.

That is one of the advantages of Fusion 3, which will allow users to also track github changes and collaborate on a project. The files that their editor uses is storing information in simple json text files - easy to edit outside of the engine editor.

Meanwhile construct's are binary blobs- not accessible for any changes or tracking outside of the editor. Your editor is probably storing information of the version that saved that file and when opening it is checking if the file is from a newer version of construct. Please correct me if I am wrong on that point.