Construct 2 - Realistic State after 1 gazilion downloads

  • Just my opininon.

    I think it is better to focus at the positive and not the negative as we are taugt by the media.

    There are problems but there are also strenghts that our HTML5 C2 carries. I think it is a quite transparent engine with honest goals and vision towards the future!

    Let me pitch another idea. A lot of talk on performance was focused on final exporting/publishing stage. What about first steps? Ashley; I think a direct scripting access would offer a completely new dimension to C2? What are your thoughts on the subject? (imagine construct editor with additional underlying scripting editor - gamemakers valhalla maybe? )

  • moxBorealis there's a difference between focusing on the negative and discussing ways to address something's weak points and how to make it better, which I think most, if not all of of us are doing.

  • Let me pitch another idea. A lot of talk on performance was focused on final exporting/publishing stage. What about first steps? Ashley; I think a direct scripting access would offer a completely new dimension to C2? What are your thoughts on the subject? (imagine construct editor with additional underlying scripting editor - gamemakers valhalla maybe? )

    The main purpose of C2's IDE is to use as little direct scripting as possible.

    There also is a way to do direct scripting in the software, which is the Browser's run JS function. I have used it to execute actions of JZIP that I made an include plugin for one of my projects. It doesn't work with code minifcation, but it works as intended. However with the IDE you're still stuck with the event system for 99% of what is needed.

    Even with the event system you're not stuck doing nothing with scripting as you can script plugins, in which the plugins work as they should every action you call on them. This is basically how functions work in JS as well as in C2. The event environment eliminates typos from commands (but not from entries), and provides a set amount of actions that each plugin can do. Since you can make your own plugin if you need to, you still have access to scripting at any level you choose.

    Quite frankly if you really want direct access to pure JS code you're better off not using C2 or making your own plugins that do what you need them to do.

  • A lot of people, i'd even say the majority, use tools like construct/gamemaker/multimedia-fusion etc. because they want to make their "dream" game, not because they want to make their game as marketable and cross platform as possible. It's a hobby, and i think enabling people to make their game as big and complicated as they want within the scope of current hardware, rather than force them into cutting back so many features modern hardware would allow, makes C2 a lot less appealing to a lot of users.

    am very, very confused with your post. You said "enabling people to make their game as big and complicated as they want [...] makes C2 a lot less appealing to a lot of users", which makes no sense.

    Then you said

    A lot of people didn't leave because we got tired and stopped using the software

    ait, what? You're saying people got tired and stopped using the software, and for that reason, they didn't leave?

    I think I agree with what you said, or maybe I agree with the opposite of what you said? I can't be certain.

  • Come now, it's not fair to take a half sentence and twist their meanings people.

  • I don't really post around here anymore, but i have been using construct continually since all those years back when classic was starting out.

    As it stands i don't see myself using C2 very often compared to CC, even though its a way superior tool to classic in terms of stability. C2 has definitely improved a TON since it started out, things with more complexity than a few events and some behaviors actually end up working quite well on desktop, yet it falls short in so many areas because it's held back by trying to achieve what classic did in a webpage. The whole advantage of doing everything in html5 for C2 was to make the games work on as wide a range of platforms as possible, and yet in trying to use html5 as a catchall C2 games end up working from my experience okay-to-well on desktop and shoddily everywhere else. I feel like in choosing html5 C2 has become a jack of all trades and master of none. Its a bit frustrating coming from an experienced background using Classic that the successor to it still hasn't surpassed it at making games that run natively. In fact it's honestly nowhere close as long as its using html5, with all the overhead that comes with using html5 vs the performance a native game using opengl/directX would have.

    I'm not trying to hate on C2, its a fantastic program and i do end up using it because having a game that runs everywhere is a beautiful thing. But its disappointing that html5, and not C2 is whats limiting me. With CC i could literally look at ANY 2D game, and even simple 3D ones and understand that it would be plausible to make a large portion of them exactly as they were using CC alone. With C2 i see a game and though building it is possible getting the performance you'd expect on modern hardware isn't.

    I don't really know the details of how C2 is designed, but i just wish it could export native games that used SDL with opengl, or something similar, so that games that take advantage of modern hardware could finally be made using it, rather than what a lot of people see as a novelty in making their games run in browsers.

    A lot of people, i'd even say the majority, use tools like construct/gamemaker/multimedia-fusion etc. because they want to make their "dream" game, not because they want to make their game as marketable and cross platform as possible. It's a hobby, and i think enabling people to make their game as big and complicated as they want within the scope of current hardware, rather than force them into cutting back so many features modern hardware would allow, makes C2 a lot less appealing to a lot of users. I think this is pretty evident in the way the old user-base was essentially alienated with the new goals scirra had in making C2 from its inception to when CC was retired. A lot of people didn't leave because we got tired and stopped using the software, its just C2 didn't fill our needs and still hasn't.

    Good post. This is one of the engine biggest weakness. The HTML 5 nonsense. The engine workflow and creation process its the advantage, the rest is the disadvantage. Imagine (i repeat myself) a CC, Gamemaker with this production flow, export open gl, exe desktop, and then in time develop other exporters. Scirra put all their money in html 5 non sense and that's why we are here.

    I never picked up the engine for the Html 5 nonsense, i only saw it as a plus that you can put a demo online, but that was it. It didnt even had a exe wrapper back in those days lol.

    In theory you can make a html 5 game and work on all platforms, on practice, no, unless you make a very static and simple game. For example i made a small game for Desktop, works well, unless (blacklisted gfxs), to make it work on canvas2d browsers it almost impossible, most of the time. Half is because how the engine is made, and half because of this shitty HTML 5 technology(that in 1 gazillion years will be cool ...). JS Frameworks like Phaser have very high performance, and while they are simple to use them, i dont have time for it since i am not a professional programmer and it was never my intention to be.

    Made a small game:

    • Works on desktop
    • After optimization(so bassicly another version) it barely works on web mobile
    • After another optimization and basically another version, works good with wrapper on iphone 4s and samsung galaxy s2 and up. A fracking flappy clone! Epic multiplatform!

    So overall this non sense of HTML 5 multiplatform is not real at the moment, it might be in a few years, but i guess many of us wont be here.

    I am still working with c2 now, but every day i think about moving on to another engine, probably Unity as soon as i have more time for developing or just develop for desktop, and pray for the best lol...

  • lwgames

    You are seriously doing something wrong if you cannot get a flappy clone to work great on mobiles.

    Took me 4 hrs to do a flappy clone with my own art: https://play.google.com/store/search?q= ... apps&hl=en

    Another of my simple game, but with heaps of moving objects, bullets and sine behaviour, runs flawless even on very old phones:

    Fast fighting game also works great on mobiles: Street Kungfu (https://play.google.com/store/apps/deta ... ngfu&hl=en)

    Fast platformer: Poise (https://play.google.com/store/apps/deta ... oise&hl=en)

    Some of the criticisms here are very valid, but this is not a fair criticism. Simple games do work great on mobiles with C2 and HTML5. Even bigger complex games work well. Just because the engine is easy to use, does not mean its easy to optimize and plan your game around the limitations of mobiles.

  • It´s just like Photoshop...your pictures won´t look good, because PS can possibly do it.... it´s in how to use the software and ressources!!

    Of course there are some weak points.... but other tools do have them as well, it´s all to you to make your game look, feel and work great!

  • lwgames

    You are seriously doing something wrong if you cannot get a flappy clone to work great on mobiles.

    Took me 4 hrs to do a flappy clone with my own art: https://play.google.com/store/search?q= ... apps&hl=en

    These games are all using CocoonJS, which is currently the only way to get good performance on mobile devices in many cases. But of course CocoonJS is coming with its own bag of problems. That's probably why Scirra is promoting the use of Crosswalk, which doesn't do anything to speed up HTML5 games compared to just using the mobile Chrome browser. Which may be relatively fast, but can in no way rival the real thing. So I think it's fair to say that there is indeed still a general performance problem with HTML5.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • > lwgames

    >

    > You are seriously doing something wrong if you cannot get a flappy clone to work great on mobiles.

    >

    > Took me 4 hrs to do a flappy clone with my own art: https://play.google.com/store/search?q= ... apps&hl=en

    >

    >

    These games are all using CocoonJS, which is currently the only way to get good performance on mobile devices in many cases. But of course CocoonJS is coming with its own bag of problems. That's probably why Scirra is promoting the use of Crosswalk, which doesn't do anything to speed up HTML5 games compared to just using the mobile Chrome browser. Which may be relatively fast, but can in no way rival the real thing. So I think it's fair to say that there is indeed still a general performance problem with HTML5.

    Actually, my most complex game is done with Crosswalk via Intel XDK, because CocoonJS falls on its face with big games with lots of assets (450MB loaded into memory!!)

    <== flawless on older phones with a 1ghz dual-core and 512mb ram.

    Crosswalk actually runs smoother/faster than CJS as it is, the only downside is its lack of Ad/IAP support, but its a temporary downside from what is saying.

    Yes, we have lots of room for improvements but as it is, you can create great games with the functional parts. Will you be able to make whatever you want run great on mobiles? Heck no. Figure out what works and what doesn't and optimize.

  • i was talking about web mobile, not wrapper cocoon/sdk mobile....

  • i was talking about web mobile, not wrapper cocoon/sdk mobile....

    Was your flappy clone running on mobile Chrome browser or the default browser??

  • QuaziGNRLnose - I just want to point out a few disadvantages of Classic and advantages of HTML5 that you didn't mention.

    CC created desktop executables. It's interesting to point out that from a security standpoint, the user is putting a great deal of trust in running an executable they downloaded from the internet. For this reason the latest versions of Windows' default settings use "SmartScreen filter", that basically warns you not to download EXEs if they are not "commonly downloaded", and you have to click through "more info" -> "run anyway". Then CC used optional DirectX components, which often required a separate download and execution of an installer that could take several minutes to run. Both of these serve as pretty big hurdles to getting real players to play your game, especially casual non-technical users (which I think still applies even as a hobbyist). On the other hand HTML5 is secure by design, and can be immediately run in the browser without any security prompts or installers. I think this is a much more significant advantage than most people give it credit for.

    We spent a great deal of time optimising CC, but we still didn't get as fast as Chrome. I don't think the reasoning in the blog post is right any more: I think the main reason is Chrome has a sophisticated multi-threaded/multi-process engine, and can run rendering commands in parallel to the next frame execution on the main thread. We never made CC's renderer multithreaded, partly because parallelism is difficult to get right. So Chrome (and subsequently node-webkit & Crosswalk) have a big performance advantage over CC there.

    We have also done more optimisation work in C2, including collision cells, parallel pathfinding calculations in a Web Worker, and more recently optimisations to skip redundantly evaluating expressions in the event system. I think this means in some cases C2 will provide a better experience when scaling up to large games.

    CC was also at the mercy of the quality of the graphics card driver and in some cases glitched or crashed depending on the state of system updates. Software rendering is slow but can be the difference between working and not working.

    Especially given the security and installer hurdles of node-webkit, I'm surprised by the level of demand that remains for it. Still, it should serve well as a "native app" if that's what you're after.

  • >

    > > lwgames

    > >

    > > You are seriously doing something wrong if you cannot get a flappy clone to work great on mobiles.

    > >

    > > Took me 4 hrs to do a flappy clone with my own art: https://play.google.com/store/search?q= ... apps&hl=en

    > >

    > >

    >

    > These games are all using CocoonJS, which is currently the only way to get good performance on mobile devices in many cases. But of course CocoonJS is coming with its own bag of problems. That's probably why Scirra is promoting the use of Crosswalk, which doesn't do anything to speed up HTML5 games compared to just using the mobile Chrome browser. Which may be relatively fast, but can in no way rival the real thing. So I think it's fair to say that there is indeed still a general performance problem with HTML5.

    >

    Actually, my most complex game is done with Crosswalk via Intel XDK, because CocoonJS falls on its face with big games with lots of assets (450MB loaded into memory!!)

    <== flawless on older phones with a 1ghz dual-core and 512mb ram.

    Crosswalk actually runs smoother/faster than CJS as it is, the only downside is its lack of Ad/IAP support, but its a temporary downside from what is saying.

    Yes, we have lots of room for improvements but as it is, you can create great games with the functional parts. Will you be able to make whatever you want run great on mobiles? Heck no. Figure out what works and what doesn't and optimize.

    Sorry, but in my experience it's simply not true that Crosswalk runs faster than CocoonJS. Crosswalk does simply perform like the mobile Chrome browser would, while CJS is accelerated and can actually reach native-like performance in otherwise hopeless cases.

    Your game may work good with Crosswalk, but it's also not crucial for that type of game to have smooth 60 fps or anything close to that. Don't get me wrong, I do like Crosswalk, but I also like to stay realistic about the way it performs currently.

  • Ashley

    I think it's moot to argue that running an executable is trusting the user to put faith into your executable. This has always been the case for any game, any program, anything downloaded off the internet. Windows' poor choice of default setting to prevent the lowest common denominator of user from being tricked, which will happen anyway for those people who blindly download and run software shouldn't detract from genuine applications using a system to its fullest by accessing as much privilege as they can. It'd be pretty sad if we were headed to a future where only "registered" developers get the privilege to have their applications actually use your computer to its fullest, and everyone else is forced to run through a non-essential protection layer or use a workaround/loophole like html5 that's supposed to make running the code seem "safe" because its the trusted browser running the code instead of a standalone application. Anyway, this isn't about Microsoft's bad choices, something i think everyone who'd understand agrees on.

    If an exporter using SDL were made, the games would be cross platform, and genuinely perform well since the whole goal of SDL is to make things run everywhere. The license of SDL would completely allow this as well, and SDL would make things work 'everywhere', using the systems to their fullest, but of course i understand the work involved in making any kind of new exporter, i'm merely suggesting this as something that seems to mesh with your goals and provide the best of both worlds so to speak.

    As for installing directX etc. This is something that's also to be expected when installing any kind of game. It's never been jarring to any PC user to see a directX prompt while installing a game, its been expected for years.

    In anycase, im aware of that performance test, but rendering a ton of sprites faster isn't really impressive or incredibly important (of course it is a good thing). You admitted yourself that there aren't many optimizations to these aspects in classic, and they were never really necessary because the calculation of sprite vertices has never been a significant factor in affecting performance, games with 30 sprites on screen can have performance issues if you're doing enough with them. It's lovely that C2 makes many optimizations in order to squeeze as much performance out of html5 as it can, i'm fully aware of this and it is impressive that you get as much out of it as you do, but the fact remains that when i make a significant number of expressions run for enough objects, C2 seems to fall behind at least in my experience, but perhaps this has changed since i did my tests. You're fully aware that if you made the same optimizations in a native C++ engine like CC that you did in C2, the results of that tests would be completely different.

    As long as everything's running in javascript, the performance is never going to be as good as it could be, javascript is simply much slower than any native C++ code and theres nothing that can change that. Theres benchmarks (http://www.i-programmer.info/news/86-browsers/3492-javascript-is-slow.html) you can find on the internet and floating point calculations will just always be significantly slower (http://stackoverflow.com/questions/17036059/javascript-is-4-times-faster-than-c, see comments), no matter how optimistic you are about it's future gains, and you've acknowledged this yourself.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)