The sad truth of Construct 2

Konidias

I really get where you are coming from (you expect a but here), but isn't that a common thing in game design anyways? THAT being to keep different plattforms, hardware, software, drivers in mind?

You will ALWAYS have to work around to make sure that every desired plattform will have the exact same experience. Heck you can't even say "iPhone" anymore, because it'll depend on the version how powerful this certain iPhone is.

In PC development you have to keep in mind that not everybody has an up to date graphics card which may or may not use a certain thing (I'm not very deep into this topic, but I'll just name Physx). As a developer, you WILL have to use certain fallbacks, no matter the plattform. May it be textures, filesize (I remember the DL-titles for the Wii could only be a certain size), shaders, RAM-usage etc.

With Construct 2 it is the HTML5 thing. And with this limitation you have to work around certain things if you plan on catering to a certain plattform.

I know there are limitations with everything. I'm just ranting a little about how I wish this wasn't the limitation that Construct 2 had. I'd trade some other limitations for the ability to natively export.

Like just reading the latest release notes there is talk about doing tilemaps and such... This time couldn't be spent doing native exporters? I feel like Construct 2 is already "there" in terms of being able to create games. Now I just want it to be more versatile in terms of exporting (which in turn, would open up some features that aren't available because of HTML5 exporting). I don't *need* tilemaps or layout alignment tools as much as I need native exporting. I understand the team is small but it's just disappointing to hear Ashley being so against creating different exporters.

To me it just never seems good to totally shut out something like that and put all your eggs in one basket. I guess my problem is a two parter... 1. that construct 2 can't export natively and 2. that scirra has made it pretty clear it will never do that.

It's just disappointing.

There's a pretty big difference between needing to keep texture filesizes small, and not being able to even add some features to a game because it will bring performance to a crawl.

With the last game I worked on, I was already doing everything I could to keep within mobile limitations... Crushing down images, reducing frames, optimizing code as much as I could, just flat out removing some effects I wanted to do because workarounds would have still created performance hits, etc. I fully understand working within limitations. That doesn't mean I can't still be disappointed with the one track direction Scirra has taken with exporting.

They treat HTML5 like the "golden boy" and I just don't feel the same way about it.

thats terrible :s...and i have buy my licence today :s and everyone need a native exporter, html5 is fine, but why not in swf, exe and other formats??

Well even if x native exporter were to magically show up tomorrow, you would still be sol as far as plugins go.

All of them would have to be rewritten in that native code.

I'd call that a sad truth.

Construct creates HTML 5 games, the wrappers and exporters export HTML 5, not true native apps. If you want to create native apps for a platform then most likely you will need to use the SDK or buy the Development tools that are built for that platform. Get an objective C development tool for iOS (and learn objective C). Get Visual Studio for Windows 8 and Windows Phone (And learn C#), etc....

HTML 5 is not a native or even a compiled low level language. HTML is not going to perform at the same level as driver level code on any platform. HTML 5 and Javascript are interpreted, procedural languages. Ranting about that fact won't change a thing. Construct is created by a two man team. The tool has specific goals and targets like writing HTML 5 apps. If HTML 5 doesn't meet your requirements, there is nothing Construct 2 can do about that. I wish McDonald's served the worlds best Lasagna which is also Zero callories and gluten free... but they don't. So that's not what I try to order when I go there...

Part of game design is looking at your target platform, evaluating your game design, and using the right tools to create what you want. There truly is no one size fits all solution.

If you are going to use any tool to create HTML 5 games, then you will have to get used to the limitations. Third party wrappers are not easy to create, that is why there are dedicated companies just for making them. That is what they are good at. They aren't making game design tools, they are making wrappers. Ashely and Co. aren't making wrappers, they are making game design tools. Since the wrapper developers are benefited most by having their wrappers and exporters used in as many scenarios and in across as many sets of tools as possible, they work to make their wrappers work with the various tools out there. But it takes them time, even though they know their wrappers and tools better than anyone.

Why not spend time whining about why the browser vendors or marketplace vendors don't make native wrappers for HTML 5 apps since they want your html 5 apps on their market place. Or why the browser developers don't make the browsers all support the same accerlation features to allow for performance across all of them without the need for all these third party wrappers...

Traditional game development meant creating versions of your game for each platform and working with multiple tools to target each one correctly. That story hasn't fully changed. While tools like Construct 2 make things easier to develop the game itself, unless Ashley and crew want to spend their full time making wrappers for all these platforms and ignore the core function of their tools which is game creation in HTML 5, then the best bet is to look at what wrappers that are out there and use them.

Notice that even the teams that are fully dedicated to writing these wrappers and accelerators take months or even years to get them into a state that works well for their platforms of choice, and they have much larger teams that the one working on Construct.

These are just the facts... They may be sad, but that doesn't change them.

To the point you made about the recent release notes: I'd much rather the developers of the game design software stick to adding functionality to help in creating games and let the people who write exporters and wrappers focus on exporting and wrapping html5 games more efficiently.

Scirra's a small team, and they only have so many manhours to devote to various bug fixes, expansion of current capabilities and development of new capabilities for their IDE. Not all C2 developers develop for mobile platforms, however almost all C2 developers use the IDE for developing games. Yes, everyone would like to have their specific development need addressed right now. There is a list of things I'd love to see C2 able to do, but I know that 85% of them only would be beneficial to a handful of developers.

In the end, your frustration is valid, but the way development in general and game development in specific works is that you use the tools that make your life easier until they've done all they can for you, then you get to work finding a solution for the challenges you face until you either get past those challenges, someone else comes up with a solution for you, or you give up.

I hate to sound heartless, but that's the life of a developer.

i wish Scirra's forums were better :(. I only reply to not correct but to enlighten about C2 and other revelations. So these are not corrections :)

Construct creates HTML 5 games, the wrappers and exporters export HTML 5, not true native apps. If you want to create native apps for a platform then most likely you will need to use the SDK or buy the Development tools that are built for that platform. Get an objective C development tool for iOS (and learn objective C). Get Visual Studio for Windows 8 and Windows Phone (And learn C#), etc....

<font color=red>reply: Good point, however C2 project objects are platform and export agnostic. Early design of C2 had in mind to export to different native platforms. Inherently C2 still is built around this at it's core. It's just the focus has changed and become more focused and limited in scope.

http://www.scirra.com/forum/what-is-c2-structure_topic62806.html

https://www.scirra.com/blog/53/construct-2s-architecture

For now it's either

A. Go native coding for the platform

B. Accept the current state(which i'm doing, with a little grumble)

C. Go to the competition who in fact is supporting full native cross platform.

Choose the right tool for you and budget. Maybe C2 isn't that tool. :( thought I love how it works :)

</font>

HTML 5 is not a native or even a compiled low level language. HTML is not going to perform at the same level as driver level code on any platform. HTML 5 and Javascript are interpreted, procedural languages. Ranting about that fact won't change a thing. Construct is created by a two man team. The tool has specific goals and targets like writing HTML 5 apps. If HTML 5 doesn't meet your requirements, there is nothing Construct 2 can do about that. I wish McDonald's served the worlds best Lasagna which is also Zero callories and gluten free... but they don't. So that's not what I try to order when I go there...

<font color=red>reply: The sad part is the SNES can do better than C2 + CocoonJS :( Also the important part of the entire discussion isn't logic performance which is running at acceptable levels. it's the fact that performance is running closer to software rendering rather than GPU accelerated draw routines. What's worse is that CSS3 transforms(which are full GPU) have better performance than C2 due to it's use of Canvas2D.

There isn't a request for the impossible. Just a request for the old model of direction Scirra was going to take in creating the Exporter Development Kit to allow others.

I'm a firm believer that Scirra should do a kickstarter aimed at 50k to hire a developer to create native exporters. </font>

Part of game design is looking at your target platform, evaluating your game design, and using the right tools to create what you want. There truly is no one size fits all solution.

<font color=red>reply: Very true, which brings Kondisus original point

https://www.scirra.com/blog/86/gamemaker-has-no-competition-we-beg-to-differ-html5s-scalability

Scirra makes it very clear that there product is more worth it in the long run. However, it's reliance to wait on others is the biggest weakness. While YoYo Games seems to move at a snails pace they are taking responsibility to do it all. Not only that there extension system does allow developers to work in other languages for target platforms. As HTML5 has no access to native calls unless given a wrapper option.

I also want to point out that the immanent performance of Android, WebGL, IOS and all of that. Has been going since 2010. It's been 3 years waiting for WebGL to hit Android and IOS. In the mean time Apple and Google show no signs of implementing it at the embeded browser level.

</font>

If you are going to use any tool to create HTML 5 games, then you will have to get used to the limitations. Third party wrappers are not easy to create, that is why there are dedicated companies just for making them. That is what they are good at. They aren't making game design tools, they are making wrappers. Ashely and Co. aren't making wrappers, they are making game design tools. Since the wrapper developers are benefited most by having their wrappers and exporters used in as many scenarios and in across as many sets of tools as possible, they work to make their wrappers work with the various tools out there. But it takes them time, even though they know their wrappers and tools better than anyone.

<font color=red>reply: very true. so this is related to a prior responce

this is why I think just a pure game wrapper(gfx, audio, control, storage) that Scirra could do, but allow the community to handle the rest as needed. I plan to tinker with the opengl es wrapper once my current game is done.

</font>

Why not spend time whining about why the browser vendors or marketplace vendors don't make native wrappers for HTML 5 apps since they want your html 5 apps on their market place. Or why the browser developers don't make the browsers all support the same accerlation features to allow for performance across all of them without the need for all these third party wrappers...

<font color=red>reply: Well you can call it whining, but after 15 years married it's more important to express concerns in a discussion. Whining is usually terse and Konidius has not been terse what so ever. He has been rather verbose, exploring and discussing the different factors that everyone has brought up :) as you are :)

The discussion is really about Scirra choice to reduce it's options. Understandably it's a staffing issue. But the overly focus that HTML mobile is acceptable, will be acceptable imminently or leaving out crucial details. HTML mobile really can't access vital long term requirements(ie no native IAP by js). Also yes it's about Google and Apple inexplicable reluctance to open the WebGL doors and the same for groups like Ludie not already having done so. </font>

Traditional game development meant creating versions of your game for each platform and working with multiple tools to target each one correctly. That story hasn't fully changed. While tools like Construct 2 make things easier to develop the game itself, unless Ashley and crew want to spend their full time making wrappers for all these platforms and ignore the core function of their tools which is game creation in HTML 5, then the best bet is to look at what wrappers that are out there and use them.

<font color=red>reply: This solution could be done by either creating the EDK or releasing the export_html.dll source code for third party development. I'm sure an agreeable license of use of source could be arranged. But i'm not asking for it specifically because I would prefer to avoid coding these days as much as possible. At most snippets here and there.

The hardest part is JS to other language. It could be done with some difficulty as JS is such a crappy language :( no that's not the real reason. it's due to it's flexibility which takes more effort to create a converter.

</font>

Notice that even the teams that are fully dedicated to writing these wrappers and accelerators take months or even years to get them into a state that works well for their platforms of choice, and they have much larger teams that the one working on Construct.

These are just the facts... They may be sad, but that doesn't change them.<font color=red>reply: Yep and that's ultimately why it's sad and painful. Phonegap is waiting on Google/Apple, CocoonJS has other priorities and Scirra is just letting everyone else handle mobile. </font>

In the end, your frustration is valid, but the way development in general and game development in specific works is that you use the tools that make your life easier until they've done all they can for you, then you get to work finding a solution for the challenges you face until you either get past those challenges, someone else comes up with a solution for you, or you give up.

yep, you are very right. So for now my current Ouya project is in C2. Minimal graphics I can get away with. If the game pans out a few hundred dollars. I will likely use a different toolset until HTML5 mobile get it's act together. When it does I will be jumping right back with gleeful abondon. but my game is well invested in C2 now so I will just get it working as best I can.... it would be nice if CocoonJS could at least support controllers and not crash on the Ouya :(

C2 is the best 2D game development IDE, hands down. But, at the end of the day HTML5 is HTML5 - bugs appear in some browsers that do not appear in others, browser audio is terrible (causing many posters to complain to Ashley about C2 audio support not realizing it's the browsers themselves), graphics drivers seem to cause all sorts of weird issues with WebGL, HTML5 works brilliantly on deskptop but grinds mobiles phones to dust if you want anything involving physics or complex effects (vs native apps). The canvas tag still has weird limitations like no z-indexing...

HTML5 is painful, but it's going to get better I'm 100% sure. With all the browsers fighting over standards it's a bit of a wild west right now. I myself keep flip-flopping from throwing my hands in the air and screaming "I'm done with HTML5!", then realizing what a pain getting 2D to work in something like Unity is and then a few days later coming back to C2.

Konidias - not many other tools even support shaders... I know WebGL isn't everywhere yet, but at least the feature is there!

BluePhaze - modern javascript engines are true machine-code compilers, not interpreters.

I would reiterate that an inefficient game will be slow with a native exporter as well, because the hardware can only do so much. So native exporters may not even fix the problem. As I said most native mobile developers are very smart and spend a long time working out performance tricks. I'm not sure this point has sunk in.

I'm not calling everyone's games badly designed, I'm just saying you need to put in a lot of effort for optimisation on mobile, and I definitely have seen people blaming Construct 2 for being slow with badly designed games before as well. So I think you need to make sure you've done absolutely everything you possibly can to optimise before worrying about the performance of the tool itself. If anyone wants to send me .capxs which are apparently slow, I'd be happy to comment and offer tips and profile it to see where C2 is slowest and possibly even optimise C2 itself. But it might also be you've just thrown more at the device than even a native engine could handle.

I agree with Ashley here. We have run into the same framerate issues with XNA/C# on mobile, and that was simply down to inexperience. The more we've come to understand the limitations of hardware, and to structure logic efficiently, the faster our games have run.

Construct 2 has over-delivered in regards to our expectations of performance on mobile devices.

for me construct2 its a very good, start, before i was user of MMF2 during years from 1995 to 2012.

Its IMPOSSIBLE to make a simple text reader in MMF2 who read an external file from a ftp, its no scrollbar at all in swf mode :D... and we are in 2013...

Yesterday; i made a text reader with construct2 with AJAX, and a video player who can also read an external video from ftp...thoses kind of stuffs are impossible with his concurrent.

I was asking to the clikteam what he are going to do, because every time i asked for a solution, it take MONTHS and YEARS to move a little finger...

and now im sure i got the solution to my problems, construct2.

Its fast, without bugs in collisions, and a lot of stuff impossible to do with MMF2, i took a little tie to do my first test, and its working.

so one thing to say, thanks to Ashley and is team for construct2.

here its my test done with construc2 http://mattepainting.be/test/index.html

try to do the same with mmf2 :D

I'm sorry but I agree with Konidias 100%. I've been saying the same things for the past year.

I've been the first to publish a "game" for iOS made in construct and again the first to support the native Game Center (on PhoneGap). I say this not to boast my achievements, but to prove that I'm speaking from experience.

First of all the argument that optimization fixes the issue is complete bullsh*t, I optimized my game in unimaginable ways, rewriting even part of the engine to use the latest hacks, I got to 40fps, but on iPhone4 it lags a lot and I won't risk my company name releasing a half-assed job. Not only that, but to achieve those abysmal fps I had to strip down the graphics to the bare, resulting in a project that look less nice than what I wanted. And let's be frank, my game is very very simple, I did a quick test with another game maker (that exports native apps) and I was getting 60fps constant with a layer of particles that I added on top of it to test speed.

The other argument I see often made is that you can get good fps with mobile Safari, true that, but nobody gives a crap about web games on iOS, plus they are extremely hard to monetize, it's either the AppStore or time wasted (unless is just an hobby).

Meanwhile the WebView (the one that PhoneGap uses) yield horrible framerates (certainly not the fault of Scirra, it's just not in the interest of Apple to make it work).

So we have to rely on external services (like CocoonJS) that are an expense on their own and are clearly not updated regularly (who follows the development of cocoon knows perfectly this). In the end you have: One level of abstraction in the form of Construct, and another level of abstraction which is CocoonJS. If any of these companies fails or decide to stop updating you are done as they are both (partially) closed source. I am personally waiting for the past 3 weeks for ludei to add the promised Game Center support which I'm not seeing coming.

I write this because I believe that construct 2 is the best game maker ever made and a very very good engine, even comparable to some big boys like Corona as far as game development possibilities: you could write something as big as Diablo II with c2, no doubt about it. And on Chrome you'll alse get amazing fps.

Still and I know I'll get bashed for this, HTML5 gaming is a failure, and that's it, there is no point to be made, no redeeming qualities, it's just that: a failure. Let's be honest about it.

HTML5 is the future of Web Applications, and at that is big, beatifull and perfect, but gaming no, and never will be sorry.

Why? Simply, because any game engine there is can be ported to multiple platform, every game engine, every game maker on the market (except C2) has native exporters to every possible platform, and the few that don't are taking steps to do it.

Any argument can simply be countered with this: let's say you develop a game, you get big, you get on Steam, you want to support steam features (achievements, cloud, workshop) good luck doing that with HTML5, it's certainly possible, but whatever your game will be it would be less time consuming to just port it to another engine, even controller support is still sketchy in HTML5!

I finished my game in 2 weeks with construct, then spent 6 month optimizing and waiting for people to finish their libraries and now I'm still sitting on it and I lost any drive to finish the job, it will be certainly the last game I develop with construct 2 (unless a real miracle happens here) because the time I lost optimizing I could' ve wrote it native and be done with it already.

I'll certainly use it for prototyping, but it's such a shame, such a horrible shame, like having a Ferrari in your garage but you can't drive it because you don't have the right fuel.

I believe that if Scirra decides to finally drops HTML5 and start thinking about a cross platform language (like Haxe or lua) they could dominate the market, as things stands right now I see it as a very unlikely eventuality...

This is not Construct 2 fault, sorry but i just buy C2 for what it's aimed for, HTML5 GAME MAKER.

this how C2 is good at, mobile is just need time, in fact I trust Ashley words, he is right, the HTML5 is improving day by day, just try to compare html5 from dec 2011 and after dec 2012 ? their a huge improvements and that took just one year, i remember how html5 was so buggy and i remembered how tigsource filled with users saying this worst option for web game, and flash shouldn't die etc..

for mobile games, i use gamemaker studio, i hate to be like advertising another tool, but i just want to say, C2 is best for html5 game making tool who is fast forward and with easy physics support & webgl shaders.

yes it would be cool to have native export, but you should all understand this just one man effort, and the only support from you to him is to buy and spread the words about C2, it's possible one day native export will happen, or in fact the html5 might do the trick someday but not yet, hopefully soon.

in fact i believe this blame should goes to browsers and mobile manufactures, the issue might be more political than to be technical i believe..

sorry for my bad english.

I will add my 2 pence here.

I am a new (and free) user, with a small background in programming from my teenage years (mostly BASIC and Pascal). I am still to decide if I should go forward with buying Construct.

I see this tool, at least at this time, as a great tool for making prototypes and learning how to make games. But I have to say, html5 somehow scares me away from buying. If, construct would work based on Haxe, I would gladly pay for it, even more than it costs now.

I would love to see perhaps Construct2H, that works on Haxe instead of HTML5, I would gladly pledge to a kickstarter to rise funds so Tom and Ashley could hire people to port C2's great interface and usability to Haxe.

Saying that, something might change my mind in the near future. HTML5 can do a great leap (like Java did before) - we will see...

Also, I think that it would be a good idea to post a tutorial for mobile optimization on scirra's website, so less-experienced users could optimize their games for mobiles easier.

The biggest part of game design is making something entertaining with the tools you are provided.

If you can not make HTML5 games now with it, then you need to learn it more, or choose a different platform.

DO NOT sit down and plan out a huge game for your first projects with ANY game engine.

Make a few stupid little games, and see how far you can push them until you break it. Then you will understand the limitations.

If you do not know your limmits, then you will design poorly, every single time. No exceptions.

Dont start out making an advanced game for phones, or any other specialty device. Learn the game engine first making desktop based games.

Once you master desktop games, then try to streamline them.

So many new people to game development think they can just start out as a master with out any training or practice.

It is like signing up for a Karate class, and on the first day insisting that you should be able to defeat a 200th degree black-belt.

Or it is like buying an top quality guitar, and insisting that you should be able to play SLAYER or Van Halen on your first try.

This is like any other art-form, you need to learn it before you can master it, or judge it.