Native Desktop Exporter for Construct 3

Nesteris

[quote:2qfwt8ns]As for the engine we currently have that is "very powerful, what we need is a new editor" I dare you to say that to the devs of Airscape and The Next Penelope, who managed to do what very little Indie developers do a make a game that companies want on their company and are fully ready to pay yet are handicapped by Construct 2 not having the exporters. MMF might be a UI nightmare, but to be fair it is more powerful than Construct 2 and has all the exporters anybody should ever need. And using MMF is still easier than writing real code.

"Look how far we've come by relying on HTML5 alone!", yes I can see, two developers got crushed by it and even more have stated, in this very forum that they're not going to use Construct 2 and someone even mentioned going to my personal nightmare, Stencyl. (Shudder).

Aurel could have developed The Next Penelope for infinite years to make it infinitely beautiful, but if every movement was going to constantly stutter and the FPS was going to constantly appear to be dropping even though it's technically at 60 then nobody is going to play it. And Node-Webkit is not going to get any of the blame, or Construct 2, it's the developer that has to deal with everyones abuse.

Honestly, it sounds like a lot of the users here are defending Sccira because they don't want to look bad because they spent money on it.

We need either Ashley to make Construct 3's own native exporters or him to get somebody to hack his engine to do so, otherwise Construct 3 is just going to be Construct 2 with a better editor, in which case paying another 130 USD for it is going to feel like theft to me no matter how good the new UI is.

Improve the engine, don't make it look prettier, improve it.

Stop stalling and do it, because you're eventually going to either have to do it or abandon calling it professional and fully featured.

Actually it's not fully, fully featured now. Every other engine I've ever encountered has native exporters and it's ilk.

+1

I think there are 3 issues why there won't be native exporters:

1) it's easier for Ashley and he doesn't want transform Scirra into big, serious company. Also it could be risky for him. So it's much easier to talk all time about bright future. Just wait for CocoonJS... just wait for Crosswalk... just wait for Cordova... Anyway: yesterday I read about some bug in Chromium that was not fixed since 2012.

2) most of the C2 users are newbies, so they will make clone of Flappy Bird, release some one screen apps for Android... So... jittering? Micro-stuttering? No problem... We can wait 10 years. So they will not push Scirra.

3) I guess that it's much more profitable for Scirra to sell C2 for schools (with monthly payments) than get 1-time payment from devs.

it's not just a new UI, its a new edittime so plugin developers and scirra themselves can integrate complex features into the editor. currently the editor is severely limiting to plugin developers, who can't do more than provide a simple interface through value properties. With the new edittime you'll hopefully have plugins to make a lot of tasks much simpler, and workflow will then be greatly improved.

Instead of the devil test make a flowchart app for people to see the difference between what they want, and what's doable.

Do you want to make games?

Are you willing to deal with some compromises to do so?

Do you know code?

ETC

Blah

Nesteris

+1

I think there are 3 issues why there won't be native exporters:

1) it's easier for Ashley and he doesn't want transform Scirra into big, serious company. Also it could be risky for him. So it's much easier to talk all time about bright future. Just wait for CocoonJS... just wait for Crosswalk... just wait for Cordova... Anyway: yesterday I read about some bug in Chromium that was not fixed since 2012.

2) most of the C2 users are newbies, so they will make clone of Flappy Bird, release some one screen apps for Android... So... jittering? Micro-stuttering? No problem... We can wait 10 years. So they will not push Scirra.

3) I guess that it's much more profitable for Scirra to sell C2 for schools (with monthly payments) than get 1-time payment from devs.

I finally got +1'ed! I feel special.

But yeah, I know how you feel. Also WOW on the 2012 bug. Not surprised though.

I think we should petition Sccira to take off their "full featured and professional" tag line from the front page

Nesteris

Sorry, I was wrong. This bug was found in 2010:

"I found out about this bug a long time ago, and it’s been raised with Google via its Chromium bug tracker for a long time. It has, for the most part, been ignored. The first report was in 2010"

and this article is from 2014:

http://www.forbes.com/sites/ianmorris/2 ... p-battery/

so I can wish us good luck with Chromium issues <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Also

"True multiplatform support." on Scirra main page could be updated by:

"* - jittering and micro-stuttering may occurs. Scirra does not guarantee that your game will be playable on any device. But you can freely report your bugs/issues to Chromium, Crosswalk, CocoonJS etc. teams."

I vote -1 here.

Improve workflow is more important than gain the run time performance. It is meaningless if the application was not completed before deadline.

Since the resource of developers in scrirra is limited, these features (for normal size project, native exporter) could not be all done, like Fimbul said.

Here are my opinions for C2 so far (after 1 year and half)

Exporters:

I don't give a c**p about native or emulated or HTML5 exporter. Most of the players don't care about this stuff, they care about how the game looks and plays.

THIS is where the REAL issue starts. Construct 2 is dependent on 3rd party wrapper. In theory should not be too bad since Ashley can focus on C2 and the 3rd party can focus better on the wrapper. Well, in practice is not so good (see Ludei/CocoonJS and the current Chromium/nw.js)

Also another "problem" is consoles support. C2 currently supports only WiiU (and is still not fully compatible due to some Nintendo WebFramework limitations); don't know more details about the Xbox One support.

Example: Aurel and "The Next Penelope" , with no Playstation wrapper and no access to source code, he can't port his game.

Yes, I am aware that native performance is better then HTML5 (C2 performance is now closer to CC, but after many optimizations that CC does not have).

Plugins:

While some plugins can be installed separately, in my opinion plugins like Paster/Canvas, LiteTween, Mode7, Pode's HTML Pack and some other should be already integrated in C2 since they are VERY usefull.

On this point Spriter should be integrated better (1 object in editor instead of many).

3D already:

Between this and this witch one looks better ? Of course the 3D one at least for the backgrounds.

And is not impossible, nor too much resource hungry, QuaziGNRLnose already demonstrated it in his Q3D Plugin

Most user don't need advanced 3D functions, only to move, rotate, scale and animate 3D objects, something like Construct Classic.

Multiplatform:

Current: Construct editor -> HTML Games -> Wrapper

The current method... Overall works good, but the problem is usually 3rd party wrappers

Another way: Construct editor -> Game Instructions (Events + Layouts + Resources) -> Platform runner/player

The "problem" is that the "runner/player" for each platform has to be coded separately and maintained/updated when Construct updates some instructions. Also the plugins will have to be made for each platform.

Also, there is Unity's take on HTML 5 that is to convert C and C++ code to asm.js using emscripten .

To be honest, I think Unity's take could be the best compromise: The developer can export his game in C/C++ if he needs the source code and also can export to HTML5 (multiplatform).

Or to continue this way, but to pay someone (or Kickstarter) to make a wrappers for the platforms that are now not supported (like PS4 for example).

Overall Construct 2 is a great tool for making small to medium projects on a budget, but at the moment is not suited for more ambitious projects.

Maybe Ashley would like to release some way for the plugin developers to make 3rd party exporters possible.

Why is there a negotiation between the native exporters and better editor? Why can't Scirra work on both? If you need to hire more people then hire more people, get budget and take time. You are not a small scale company anymore as far as how you showcase C2 in your webpages. Why there is an option between these two?. Release with the native exporters first and then work on the better editor. It may be easy for me to just say, but hey! you're competitors are driving fast.

Before I bought the license from Scirra, I checked every other application stencyl, GM and all. I am glad that I bought this coz it is easy for a create games. But did I earn from this. NO. My aim is to publish decent games in Android and IOS and after a bit of experience, much better games. I published my first simple game using Intel XDK, either the size if way too high for my simple game(Crosswalk for Android) or the performance is too damn bad(Android). This may looks like a small problem to you, but believe me, there will be more users who might have just left C2 or crossed this part with hard feeling. I am loosing interest with C2. When I speak to other mobile developers from the community, then feel the same. And most of them soon planning to start learning a new application. You have to focus on the tiny developers too. If they create simple game, you never know, It can come out as a big hit in the Android and IOS market. They will be ready to buy more. How many of our users bought Business License? Tell me.

Just click my game in the signature section of this post and check the size. It's 24 MB, for a simple puzzle. Too damn bad. It is suppose to be 2MB.

See how many members are in members page. How many members active in this forum? A way too much difference. If you offer them that they cannot refuse, this forum could have many more members.

Don't just focus on Desktop users, you have no greats mobile games to show in the Home Page, Coz you have to give them an option. When you have a better native exporter, users could try exporting it easily. I am tired of using intel XDK or cocoonJS for export.

Most importantly you have to focus on 3d and all other 3rd party plugins to be added into C2. Coz, usually in applications 3rd party plugins will be something like add-on from the basic requirement. But see all your most used 3rd party plugins, Is that suppose to be an add-on or already embedded with C2 Itself?

I still appreciate Ashley from getting here and answering the issues. It shows he is interested to lift this company to the next level. But you got to understand C2 have two users, Mobile dev and desktop dev. You have to feed both of them.

As a mobile dev, I would like to see these features in C3

• Definitely Native Exporter - with better performance and optimized size.
• Good performance in the game itself.
• Definitely embed the most used 3rd party plugins in to C2 itself.
• Clean way to create share and leaderboard options

To all the advanced C2 users out there, If you think these are silly things to ask and if you think it wont help in the future, believe me, you haven't met all the users who had left this C2 for not having this.

Here are my opinions for C2 so far (after 1 year and half)

Exporters:

I don't give a c**p about native or emulated or HTML5 exporter. Most of the players don't care about this stuff, they care about how the game looks and plays.

I take issue with that, because a game needs to be supported the the platform the player wants to play it on. Otherwise they can't look or play the game. And I think they care a very great deal about that.

I've read every post in this thread and I'm glad some of the murk is clearing. However I would like to add my say again

Native export is not the solution for buttery smooth performance.

C2 Engine is you could say the culprit. CC was a group project by students. C2 is all Ashley. The Runtime engine is likely very different. What most of you see as being vastly slower is just lack of performance optimizations in the main engine. My suggestion. Do what somebody did. Create test cases in both CC and C2. Then give them to Ashley.

I'm glad someone noticed that the different between bunnimark and deviltest. bunnimark is pure minimal js. Where as deviltest looks to being using a more advanced bullet. Bloat the same bunni's with the same game features and you will see a slow down.

I'm looking forward to C3 and what people should be invested in is the C3 architecture. Not in a way of what C3 should have, but to make sure that C3 will allow for other developers.

As some one who does Game Programming for a living; I agree that C2 is not a tool for professional game development. There are so many fantastic work flow tools, and overall IDE architect that makes other tools so much more nicer to work with. C2 has the ES wich makes near error less code and the API is fantastic. however C3 needs to either have these work flow tools, or the main engine needs to grant access for better work flow tools to be made. I've made request for work flow tools, but often either get blocked do to C2 limits, or Scirra see's no value. My only complaint. Is that Since Ashley doesn't make games, I'm not sure his value of what game developers want or need should the final decision. Such as file journaling updates, scene graphs, IDE store....

Yeah. it's been said before, but that's where I stand on the situation.

A developer created an importer for Spriter to Unity

(

)

(https://github.com/bonus2113/Spriter2Unity)

(http://brashmonkey.com/forum/index.php?/topic/3365-spriter-for-unity-43-updated-integrated/)

and the same thing could be done for C2 projects if a developer was really interested. That would greatly expand the available platforms to export for.

No offense to Spriter (it's awesome), but some movement info is much different than a whole creation system with plug ins, shaders and so on.

> Here are my opinions for C2 so far (after 1 year and half)

>

> Exporters:

> I don't give a c**p about native or emulated or HTML5 exporter. Most of the players don't care about this stuff, they care about how the game looks and plays.

>

I take issue with that, because a game needs to be supported the the platform the player wants to play it on. Otherwise they can't look or play the game. And I think they care a very great deal about that.

Poor choice of words from my side What I meant to say is that I don't care what's under the hood, how the game is programmed, what technologies it uses ... etc. What I do care is what players see when they play my game.

About multiplatform I've said my opinion in the downside of my post ... Except consoles, I don't think there is any other popular platform that doesn't support HTML5 games (trough wrappers) ... But yes, at the moment the 3rd party "just" do the job (some better, some worse)

In the meantime I've downloaded Unity + a visual script engine and when I got more time I will start to do some tutorials and see how I handle it.

Improve workflow is more important than gain the run time performance. It is meaningless if the application was not completed before deadline.

I don't feel that the workflow of C2 holds me back, but being able to get to the Node-Webkit exporter any faster doesn't really help me when my problem is performance with said exporter.

I agree with the others that it's Scirra's choice whether they try to go for more control over export (which could prove very costly and take up a lot of time), or they instead tone-down the advertising to match the medium/hobby projects instead of competing with the biggest ones (which would make me a little sad, because Construct has the best editor I've ever used).

Staying small and going big are both options that could turn out great or not so great for both them and the community, but right now both sides equally feel like they're not getting what they wanted and thought they would when they read the adverts.

jayderyu

I agree, but sometimes things that run fast in one build are broken in the next build (and they're both Stable builds). The problem is that things are not just running slower in C2, but unpredictably.

One moment you've got 60FPS, the next it's jumping between 25FPS and 45FPS for rendering the exact same scene with no changes. Consistency is probably the root of the issue, and I think it's something to do with Javascript and the garbage clean-up, so hopefully that can be fixed with asm.js