Construct 2 - Realistic State after 1 gazilion downloads

Discussion and feedback on Construct 2

Post » Sun Mar 23, 2014 7:18 pm

I always wondered why Scirra didn't use haxeNME. From what i understand it's what Stencyl uses, along with many others.
B
43
S
22
G
20
Posts: 735
Reputation: 11,977

Post » Sun Mar 23, 2014 7:24 pm

I just want to add that I would easily throw down $100 for good working native code exporters...or just something that worked directly from inside C2...easily $100! So get someone working on it! :mrgreen:
B
19
S
7
G
7
Posts: 88
Reputation: 4,102

Post » Mon Mar 24, 2014 2:06 am

Some great posts by Arima that I totally agree with! I can't help but think that Scirra would be best to hire an extra guy, get him to recode C2 with Haxe or asm.js output in mind, while Ashley continues to work on C2. Then by the time it is finished, release it as C3. Scirra makes a ton more money as people upgrade/buy...the community is happy and Construct is then future proof. I know that Haxe html5 output is still not finished, but eventually it will be and there are some impressive commercial games that have come out recently using this framework.

Funnily enough I was reading the Unreal4 megathread over on the Unity forums, where people where arguing about the merits of visual programming and Blueprints. One user posted an interesting reply , praising the merits of C2 and how viable it was as a visual programming solution. But in the same breath he vowed to never use C2 again because the performance was so terrible. Like it or not, there is a lot of this sort of talk going around the web. C2 has this very love/hate vibe amongst users. Of course if your only intended output is HTML5 for the web then it is near perfect!
B
11
S
2
G
1
Posts: 108
Reputation: 1,899

Post » Mon Mar 24, 2014 2:59 am

HTML5 tech is new, so it's going to have performance issues depending on the machine and browser used.
With compatible browsers, if C2 exported ASM.JS functioning code it should increase the logic speed so the only issue would be drivers optimizing the calls.

If there was plans for an ASM.JS option for plugins/export, I'd be all for that.
B
21
S
8
G
6
Posts: 346
Reputation: 4,891

Post » Mon Mar 24, 2014 8:57 am

I think you are underestimating the amount of time and effort to create (i.e. rewrite the entire engine) with a native exporter. As Ashley has previously stated, by the time the new engine is finished, mobile processors will be running javascript quick enough for more advanced games.

I think a BIG advantage in writing plugins/behaviours with javascript is that functionality can be developed alot quicker than a compatible exporter could be.

Perhaps a middle ground might be to include more asm.js code (we already have box 2d with asm.js). But writing and maintain both versions would slow development down to a snails pace.

Unity and other options exist to create native apps. C2 is easier to use, but thats the trade off for mobile develop (at the moment).
B
12
S
3
G
4
Posts: 57
Reputation: 3,186

Post » Mon Mar 24, 2014 1:13 pm

@Arima - by "compatible" I'm not just talking about the same feature list, I also mean that the features that are supported function identically. If they don't, then ported games will be broken and it will often be extremely difficult to figure out why. For example some part of a platformer might collide differently and break the game, due to a round-down instead of round-to-nearest somewhere deep in the engine. Getting exact compatibility so games actually port with good success rates is months and months of painstaking work by itself. (This would also be complicated by some "interesting" features of Javascript, such as all numbers are doubles - simply choosing an int or single-precision float anywhere in the engine could cause incompatibilities. The list would go on.) Then not having the same supported feature list is the other half of the problem, and if some unsupported feature is critical to your game, tough luck.

I don't think many people in this thread appreciate the work that goes in to maintaining a large engine which thousands of games depend upon. Maintaining backwards compatibility with updates to the same engine is hard enough. I consider it a pretty significant technical accomplishment that we have so far made well over 100 updates and kept the rate of breaking changes very low. This is an "invisible" success which users quite rightly take for granted and don't think much about, but involves careful planning and good engineering. Lots of other tools out there frequently break things. Many games come to depend on very subtle aspects of the engine - the "quirks" - and they very much have to be left in or re-written compatibly otherwise you break whole categories of games. The idea of rewriting even a compatible subset of the engine in a different technology is a monumental technical challenge far beyond that of even just backwards compatibility with the same engine.

asm.js only covers the JS logic and would still have lots of dependencies on browser-platform features, such as: the WebGL shader compiler, asynchronous image and audio format decoding and streaming, the Web Audio API, user inputs (touch, mouse, keyboard, orientation, accelerometer, gamepads, user media, etc), WebRTC, AJAX, WebSockets, v-sync, web workers, XML parsing, form controls, platform-specific integrations (Facebook, file I/O, Windows Store, consoles e.g. NWF, etc), other unsupportable features like third party plugins and the Browser object's javascript execution, and probably more I can't think of. All of that needs to be rewritten in native code in a compatible manner, which is still a monumental job. This is why I compare it to writing a new browser engine, and so far nobody does that well apart from the major players in the industry.

However if we stick with the web platform, we can have it all: a compatible, fully-featured and high-performance engine on all platforms. Mobile needs to catch up a little, but we can already see that happening, such as with the performance results on a Nexus 5 and the fast-improving Crosswalk.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240

Post » Mon Mar 24, 2014 6:44 pm

The one thing that puts C2 head and shoulders above everything else is the commited involvement by Scirra in the community. Where else can you speak directly to the head man/men and get meaningful, constructive answers. They may not always be what we want to hear but thats life.
B
47
S
16
G
9
Posts: 1,097
Reputation: 11,180

Post » Mon Mar 24, 2014 6:58 pm

@Ashley - I do understand and appreciate that it would be a big challenge, but Its true that I don't understand all the intricacies involved of what I'm arguing for and the amount of work it would be. I see things like haxeNME or monkeycoder which advertise being able to compile to multiple platforms, and I guess it makes it seem easier than it is.

Regardless, I still think it would be a good move long term, but I also acknowledge that I might be wrong, and respect the decision to stick with HTML 5 for now. I do hope it will get as better as you think it will, but I can't say I'm entirely confident about it. Maybe even if you're unwilling to go native, perhaps at some point a rewrite to entirely asm.js could be considered instead.

Either way, thank you for being receptive to the discussion!
Moderator
B
94
S
33
G
33
Posts: 3,006
Reputation: 27,744

Post » Fri Mar 28, 2014 4:01 pm

Watching this thread from page 1 to 30 I concluded that Scirra should make an official "tutorial + capx + Android PlayStore published-proof-game showing the "best way" to export and publish a game that platform. (The rest of the many other platforms for another day).

For example using their "Space Blaster" game as the game to export. But optimized for moviles, giving info about important optimizations to target that platform (Android).
Then you have the same game, one made for desktop and one modified with any optimization needed for you to compare and learn.
This example should be able to be downloaded from the PlayStore so we can see that "It can be done" right there in our moviles.
We can then test performance and reliability knowing that every step in the process, from making the game, to the exporting was made as it should.
If all this is made by Scirra it will give confidence to viewers and customers, much more if the same is made by any other user (I know there's already exporting tutorials made by users).

I'm not discouraging user-made tutorials about exports, just saying that and official tutorial will do a lot to proof that it can be done and at the same time mitigate any "you made it wrong" criticisms. Then if you try and fail for whatever reason, you have a reliable source to check the process. And you know that the export isn't just plain broken.

This should be done with all wrappers/exporters to all supported platforms but, at least, one platform should be tackle.

I read the entire post, found valid points for detractors and defenders of Scirra course. While both sides can be right at the same time I saw that there's already games made with Construct 2 published at Steam, Android PlayStore and Windows phone.

So I can't believe that exports can't be done. At lest to Android phones and desktop with good enough quality and performance. At the same time some rough edges are undenaiable but, at least to me and seeing games released, are not a brick wall or a reason to say: "It can't be done".

Testing games released on Android (made with C2) i found that they not only worked fine but also worked fast.
I tried games made by @Silverforce like "Firewall: Puzzle Shooter" and "Ninja Legacy Lite" in a Samsung S3, a Samsumg Galaxy Y Young and an Android tablet "MD7096" wich is so patetic that can only be released in Argentina (cof.. cof..). Anyway, in those devices, witch only one can be considered fast, all games worked well and fast.
I showed those to my girlfriend who found nothing to complaint, about speed or suspicious behaviour. She knows nothing about Construct or what the hell i'm doing throwing boxes against circles in a strage program.

I didn't test the Steam games yet but shouldn't be any major problems on this platform.


Conclusion:
A good tutorial about the process of exporting and publishing to Android (at least) made by Scirra itself, using a well made, no-complaints-sensitive example like Space Blaster as the test subject and this test game downloadable from the Playstore should proof enough, should mitigate fears and will serve as an example to follow and compare.

Firewall: Puzzle Shooter performed too well in all mentioned crappy hardware mentioned (poor S3) to just say: "We cannot export and publish to Android" and grin about it.

There's some nasty problems yes. But there's more than just an elusive future that doesn't deliver. I belive that with a good example many fears will dissipate, many known problems will be obvious enough to be carefull until are solved and also many games will find their way to the PlayStore too. Some people made it. You can too.

Any other not mentioned platform/brand/store will be discused another day.
Hopefully this can help both sides or at least ease fears... and hopes.
B
31
S
4
G
4
Posts: 110
Reputation: 4,593

Post » Fri Mar 28, 2014 9:49 pm

@Hillstrom Great post, it summarizes how I feel about C2 and mobiles.

Because C2 is so easy to use but still requires someone with experience to optimize, it is very easy to quickly make a very poorly optimized game that even struggles to run on powerful hardware.

I cringe a lot when I view other people's CAPX, they do a lot of calculations per tick when its not required, or do complex maths to perform a function that can be achieved with simple variables.

A very common example is this: Enemy healthbars.
They typically have every tick, set Bar Width to X. Completely unnecessary because that's every frame. Does the enemy ever get damaged again and again every frame? Hardly. Therefore it's a waste. Just throw it under Every 0.2 seconds instead. The visual difference is barely noticeable but as enemies add up, the calculations are a lot less work. There's also something that should be added to ensure it only updates the bars when needed, ie. when enemies have been injured only, otherwise it will update for all enemies when its not required. So it is placed under a trigger/event to check, If Enemy.Health < Enemy.HealthMax, then set Bar width. It's just a simple thing to do to minimize CPU cycles being wasted.

Currently a few things really hurt performance that you should avoid, WebGL effects, don't touch it. I see ppl use it to change color or tints on sprites, no. What a waste of resources.

But certainly there should be an official list of what to avoid doing to get good performance on mobiles. I don't think there's been much focus on mobiles by Scirra TBH, I learnt a lot from "Remember not to waste your memory" tutorial, but there's actually a lot of other pitfalls, some of it linked to C2 features, such as WebGL and some behaviours, or the way you go about making your events.

I am still a noob when it comes to programming or C2, others here who frequently help on the How Do I?... forum are vastly more experienced. But its because I started with a focus on mobiles, everytime I add something, I always make sure its done the most efficiently as possible.
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,614

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Brendan2007 and 6 guests