Construct 2 - Realistic State after 1 gazilion downloads

Discussion and feedback on Construct 2

Post » Wed Mar 05, 2014 8:15 pm

shinkan wrote:"Export your game to desktop PC, Mac and Linux apps by using the Node-Webkit wrapper... You can also reach the popular iOS and Android app stores using wrappers like CocoonJS, appMobi and PhoneGap — all three with built-in support."
This is pasted from https://www.scirra.com/construct2

Every information needed about C2 is provided. You only need to spend few minutes to read what exactly you are buying.


The part that's missing is that Scirra is helpless against CocoonJS and Crosswalk bugs, that these products don't actually produce satisfactory results for many users, and that these products don't have C2 exports as a main priority so fixes may come slow or never. Don't kid yourself, if this was not a problem you would not be seeing threads about this stuff 'every week'.

E.g. quoting from that same page

With extensive platform support you can rest assured that players will have access to your game no matter where they are*.


*but probably will have sound, performance, and ad issues in an overwhelmingly large number of cases and games so even though they can access your game they may not be able to actually play it.
B
11
S
2
G
3
Posts: 283
Reputation: 1,968

Post » Wed Mar 05, 2014 8:21 pm

To be honest, I'm starting to get a bit disillusioned with html5 myself. I wasn't happy with the idea of html5 only initially, but was eventually convinced that it was a good idea since the whole industry was moving to support it, but after years of waiting I'm still frustrated and disappointed by several things.

- Html5 has no manual memory management. You cannot dump anything from ram, you have to wait for the browser to do it for you, and you have no idea when it will do so, and garbage collection can cause stutters. Layout by layout loading only handles what textures are sent to the video card, so does not help with this. This problem makes large mobile games pointless to bother with because since they don't free up memory they just crash. I wanted to put loot pursuit on mobile, but it's just not an option, and I only found that out after months of work, which was quite upsetting. I've been using construct for about 7 years and consider myself pretty knowledgeable about it, so it's quite likely less experienced users won't realize this limitation without first putting in wasted work too. C2 loading everything at the start also causes long loading times, but hopefully something can be done about that while still using html5.

- Javascript's poor performance. On desktop it's not as much of an issue, but on mobile it's obvious, and is made worse by the fact that iOS doesn't allow compiling JavaScript in apps, making things like cocoonjs like 2/5ths of the speed of safari in my tests, and safari was already behind native. It's also disappointing that on all platforms, C2 will always be steps behind native exporters in speed (this segment is again about the speed of the code, not the rendering - C2's rendering is written in webgl, which as I understand, IS basically running natively and in one of my older tests was faster than CC's rendering). That said, on desktop I very rarely encounter speed problems on an amd 4400+, which is old enough that it can't even decode 1080p video smoothly, so that says good things about the speed there, but we're still always behind what we could have, and what the competition has.

- Reliance on third parties for export, which despite all their efforts, which are appreciated, have proven to be still not ready for prime time, years later. Relying on third parties means scirra cannot control the quality of their own product, which is disappointing as scirra has a terrific editor.

This also means we're beholden to their whims, like chrome, and therefore node webkit, disabling hardware acceleration on all XP and vista systems. I mean, seriously, wtf.

The truth of the matter is C2's competition - almost all the competition - has native exporters, and what we're experiencing is why. Clickteam has it. Game maker has it. Unity has it. The list goes on and on.

@Ashley - if you read this, when you respond to the idea of native exporters (I could be wrong about this, I apologize if so but it's the impression I get), it seems like you think we're talking about you making your own complete browser engine, because you talk about how you couldn't compete with google or such's team of engineers. We're not. What we want is just native games, no web tech that games don't need. Yes it would make a lot of third party plugins obsolete, but I just don't care as I don't use them that often. i really think html5 is holding C2 back.

I don't believe that it's impossible to create native exporters that work better than chrome. There's thousands, possibly hundreds of thousands of games out there that do exactly that. Chrome is trying to support everything a web browser can do. Games need only a fraction of that. We don't need CSS or whatever web tech. Trying to support them all is not an achievable task for a small team, but supporting all of the functions needed just for games has been achieved by many, many small teams out there, including you guys with the native exporter in construct classic.

Yes, it might take a while to code. I understand that C2 is solidly on the html5 train, and it's not good to try to get off a train while it's in motion. However, if someone could be hired to work on it concurrently, then work on the current to do list would be able to continue at the same time and no delay in updates to c2 would occur.

However, even if you can't find someone to help, then even working by yourself I think when most or all of the stuff on the to do list is done, then a switch to native should happen. I don't know if 3d could be considered at that point as well, but I also think it should be incorporated, and that might be a good place to do so, or to at least lay the framework for it to be implemented later on.

C2 has the best editor out there that I've tried, hands down. It shouldn't be held back by its exporters. Exporting to native would make it a powerhouse would dominate the competition. As it is, and this is really painful to say considering how much I love this program - I'm finding it harder and harder to recommend c2 to people unless they fall into very specific categories and don't mind the caveats.


newt wrote:Well, nobody is making you use C2, perhaps you should try some other software.

newt wrote:Here we go with the weekly native thread disguised as something else.

That's really not the right position to take. Scirra's event editor isn't available anywhere else, and without it I wouldn't be making games at all as I am terrible at traditional code. Also, it just drives away people who would otherwise become paying customers.

Scirra's got a great product, but it is not without its flaws, and we shouldn't discourage discussion of them, as discussing them constructively can result in a better product. If a lot of people are complaining about something, then it's likely a real problem.
Moderator
B
94
S
33
G
33
Posts: 3,006
Reputation: 27,749

Post » Wed Mar 05, 2014 8:24 pm

Juryiel wrote:E.g. quoting from that same page

With extensive platform support you can rest assured that players will have access to your game no matter where they are*.


*but probably will have sound, performance, and ad issues in an overwhelmingly large number of cases and games so even though they can access your game they may not be able to actually play it.



What can scirra do about that? Exported games from C2 are perfectly ready to be used with third-party wrappers. If one of this wrappers is not working correctly then it's up to developers of that wrappers to deal with issues. Ashley can only send them email explaining what's wrong, but he can't tell them what to do.
ImageImageImageImage
B
157
S
66
G
41
Posts: 2,599
Reputation: 34,825

Post » Wed Mar 05, 2014 8:32 pm

Arima wrote:@Ashley - if you read this, when you respond to the idea of native exporters (I could be wrong about this, I apologize if so but it's the impression I get), it seems like you think we're talking about you making your own complete browser engine, because you talk about how you couldn't compete with google or such's team of engineers. We're not. What we want is just native games, no web tech that games don't need. Yes it would make a lot of third party plugins obsolete, but I just don't care as I don't use them that often. i really think html5 is holding C2 back.

I don't believe that it's impossible to create native exporters that work better than chrome. There's thousands, possibly hundreds of thousands of games out there that do exactly that. Chrome is trying to support everything a web browser can do. Games need only a fraction of that. We don't need CSS or PHP or SQL or whatever web tech. Trying to support them all is not an achievable task for a small team, but supporting all of the functions needed just for games has been achieved by many, many small teams out there, including you guys with the native exporter in construct classic.

Yes, it might take a while to code. I understand that C2 is solidly on the html5 train, and it's not good to try to get off a train while it's in motion. However, if someone could be hired to work on it concurrently, then work on the current to do list would be able to continue at the same time and no delay in updates to c2 would occur.

However, even if you can't find someone to help, then even working by yourself I think when most or all of the stuff on the to do list is done, then a switch to native should happen. I don't know if 3d could be considered at that point as well, but I also think it should be incorporated, and that might be a good place to do so, or to at least lay the framework for it to be implemented later on.


This could be nicely done same way like official SpriteFont plugin was made.
ImageImageImageImage
B
157
S
66
G
41
Posts: 2,599
Reputation: 34,825

Post » Wed Mar 05, 2014 8:35 pm

shinkan wrote:
Juryiel wrote:E.g. quoting from that same page

With extensive platform support you can rest assured that players will have access to your game no matter where they are*.


*but probably will have sound, performance, and ad issues in an overwhelmingly large number of cases and games so even though they can access your game they may not be able to actually play it.



What can scirra do about that? Exported games from C2 are perfectly ready to be used with third-party wrappers. If one of this wrappers is not working correctly then it's up to developers of that wrappers to deal with issues. Ashley can only send them email explaining what's wrong, but he can't tell them what to do.



I'm not sure what they can do, I can't run their company for them since I don't have their operational details. From my perspective as a customer, I would be far less disappointed if the addition I put there with the asterisk to their marketing was present when I bought the product. That way I would know that these issues come up all the time, would set my sights lower, and probably still decide I want to buy C2 (it's cheap enough to be worth it for its ability to make JUST simple games). But obviously if they did that they would lose a lot of customers. If this were my company I would portray my product's capabilities more accurately if I could not improve them, and take the hit on customers. I would not lead anyone to believe that they can actually reliably make mobile games of any complexity given the state of wrappers and in fact would make it clear that they can't. I said it before but mobile export is very much a beta or even alpha product right now. I would label it as such.

I actually find that Ashely does oversell a lot of stuff. I jsut recently read his article on how C2 solves the 'view source' issue with obfuscation. It doesn't. That's barely a measure for anyone who would bother to steal the source, especially getting information to manipulate gameplay rather than just trying to reproduce your game. Yet, Ashley confidently says some (correct) things about how the obfuscation helps, then follows it up with the definitive and misleading statement of "View-Source Issue is solved!" I guess he's better at marketing products than I :)
B
11
S
2
G
3
Posts: 283
Reputation: 1,968

Post » Wed Mar 05, 2014 8:48 pm

newt wrote:Why should they refund it? Its not like you can't try it out before you buy it.
Just saying he should compare the other options, which coincidentally usually must be purchased before use.

You cannot try out before you buy it.

Only with a license you have the option to export for mobile inside c2.
B
51
S
9
G
2
Posts: 153
Reputation: 3,488

Post » Wed Mar 05, 2014 8:51 pm

I am at the same disappointing level as many of you here and maybe more.
@Ashley
A game engine what needs GOOD,polished, published games to relay on advertise and grow. (there are some? 2-3)
Polished games need a way to be made (done and great),
a way to be exported ( mmm not so much)
and finally the people to make them (you start loosing them, eventually everyone will cross the hobbyist line and jump over to another engine)
so why scirra doesn't listen to us ?
i feel helpless here ( I am a visual disigner and I have 2 finished games in a Really great quality, not published a screenshot yet due to the lack of the tool i chose (or the export options don't eat me it was my choice either way))
B
35
S
11
G
3
Posts: 97
Reputation: 3,478

Post » Wed Mar 05, 2014 9:07 pm

@Arima which quote?
Yeah the second is a bit calloused, I admit that, but I stand by the first.
You should be out there trying other products, finding what works for you.
Or at least finding things you would like to see in C2.

@mrnannings
That's not a very good argument as most of the mobiles that can play the game have browsers that play the game, and offer even more features.
Image ImageImage
B
169
S
50
G
169
Posts: 8,286
Reputation: 108,216

Post » Wed Mar 05, 2014 9:13 pm

Maybe Ashley could look into something like Ejecta (since it's open source):
http://impactjs.com/ejecta

Code: Select all
Ejecta is like a Browser without the Browser. It's specially crafted for Games and Animations. It has no DIVs, no Tables, no Forms – only Canvas and Audio elements. This focus makes it fast.

JavaScript code is executed directly by a JavaScript VM (JavaScriptCore), the HTML5 Canvas 2D and WebGL API is implemented in native code with OpenGL, Audio is implemented with OpenAL. Several other APIs (touch, accelerometer, localStorage) behave like those in a real browser.
Many HTML5 Games run out of the box, or with minimal modifications – with better performance, better sound support, Game Center integration and more.


and incorporate it to Construct 2, so we don't need to rely on 3rd party exporter anymore ?
B
34
S
13
G
8
Posts: 134
Reputation: 8,118

Post » Wed Mar 05, 2014 9:15 pm

newt wrote:@Arima which quote?
Yeah the second is a bit calloused, I admit that, but I stand by the first.
You should be out there trying other products, finding what works for you.
Or at least finding things you would like to see in C2.

@mrnannings
That's not a very good argument as most of the mobiles that can play the game have browsers that play the game, and offer even more features.



Great, I already own gamemaker but I will go ahead and purchase the game maker exporter to android to try it out. You cover the $100+ I spent on C2, and I'll cover the other $100. Let me know your preferred method of payment so that I can implement your extremely useful suggestion.

The browsers over WIFI don't work the same as exporters. My game right now doesn't work at all on Crosswalk, runs ok but slow in Chrome mobile. Look if you're not having problems that's great, but telling people who are having problems that they are in fact not having problems, and that they should throw money which they gather from local trees to try other engines' exporters is just not productive.
B
11
S
2
G
3
Posts: 283
Reputation: 1,968

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Artpunk and 8 guests