The sad truth of Construct 2

Discussion and feedback on Construct 2

Post » Fri Feb 08, 2013 11:36 am

@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.
B
18
S
5
Posts: 22
Reputation: 2,346

Post » Fri Feb 08, 2013 6:25 pm

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.
B
7
S
2
G
3
Posts: 28
Reputation: 2,260

Post » Fri Feb 08, 2013 6:47 pm

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??imothep852013-02-08 18:47:38
B
32
S
9
G
6
Posts: 1,467
Reputation: 7,951

Post » Fri Feb 08, 2013 6:56 pm

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.
Image Image
B
161
S
48
G
90
Posts: 7,356
Reputation: 66,767

Post » Fri Feb 08, 2013 7:54 pm

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.BluePhaze2013-02-08 20:15:41
B
49
S
11
G
10
Posts: 1,833
Reputation: 14,428

Post » Fri Feb 08, 2013 9:46 pm

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.
B
26
S
8
G
3
Posts: 210
Reputation: 5,973

Post » Fri Feb 08, 2013 11:50 pm

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 :)

[QUOTE=BluePhaze] 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....

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 :)



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...

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.



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.

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.


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.

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.


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...

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.



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.

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.



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.[/QUOTE] 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.

[QUOTE=theubie]
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.
[/QUOTE]
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 :(
B
87
S
18
G
9
Posts: 2,455
Reputation: 14,834

Post » Sat Feb 09, 2013 12:03 am

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.
B
24
S
4
G
1
Posts: 244
Reputation: 3,462

Post » Sat Feb 09, 2013 11:07 am

@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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Sat Feb 09, 2013 11:56 am

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.
Moderator
B
72
S
13
G
11
Posts: 900
Reputation: 11,783

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Artpunk and 12 guests