Native Desktop Exporter for Construct 3

  • sqiddster

    Aurel

    Have you tried export your games to iOS via CocoonJS WebView+? Just for test issues? I know that it's still not perfect (i.e. no native AdMob) but I'm just curious if bigger games are butter-smooth as said one time.

  • • I think what defines a game engine, is not how many sprites can be rendered, or if it can run games at constant 60 FPS.

    • The ultimate test is the amount of great games made with that particular engine, and I wonder why, C2 seems to be the game engine with the smallest ratio: great games/users.("great games" means successful games)

    • C2 developers are worse than other developers? I don't think so, talent is everywhere, so I think there's is definitely a big roadblock in that final stage of the process of releasing a game.

    • I think Ashley should be aware(and he is for sure) that a game engine without successful games and major developers(like squiddster and others), is a game engine with no future.

    • I personally love C2, and is a 2nd nature for me, so I can't see me leaving C2 in the near future, but I would love to understand what would be the solution for breaking that roadblock, because a new editor will not solve that problem, and just "wait for the future" is not a solution at all.

  • I think what defines a game engine, is not how many sprites can be rendered, or if it can run games at constant 60 FPS.

    It may not define an engine, but it is plenty important - at least for action, racing, platform games. If this were positioned as a puzzle game engine or such - no biggie, but since it's basically presented as a "recreate the classic arcade hits at home" sort of thing (at least with the latest video) - you expect a steady framerate and a certain ability to supply visual spectacle.

    The ultimate test is the amount of great games made with that particular engine, and I wonder why, C2 seems to be the game engine with the smallest ratio: great games/users.("great games" means successful games).

    You mean smallest ratio of publicized games - we know of the ones on the front page. Yeah, Last Penelope looks awesome, what else does C2 have... hell, I cannot name another thing from the top of my head (sorry, naked spaceman game, cannot remember your name). I'm sure for every active forum member there are two lurkers and 8 people who never show up here. Probably same ratio of projects.

    There's plenty of people who show amazing looking stuff and then disappear - be it that they ran into C2 problems or perhaps just run out of steam... Perhaps it would help if Scirra gave them a hand - be it with extra attention to their problems or with some other support option - to get those showcase games.

    Edit: I usually have it disabled, but looked at the start page - it has a small plain link to forums - perhaps this should be a larger banner ad sort of thing, you know.

  • Somebody, I'm with you, performance is very important, I didn't said it was not

  • It would be interesting to know the percentage of C2 users who write for desktop only and have no interest in mobile.

    Yeah PC for me.

    IMO ( not that it really matters ) Mobile\Touch while ok for apps, just equals feature-less games.

  • How can that Pixi.JS be so fast? I did a version of their Lots-o-sprites demo http://www.goodboydigital.com/pixijs/examples/4 and I reckon it runs faster on my mobile device than the C2 one does on my desktop PC. I made it as close as possible to their code, and turned collisions off.

    I get 40 fps on desktop (Chrome preview) and 2 fps on my Nexus 7. (Also is there any way to know the FPS of their demo in the browser?)

    [attachment=0:2xo480ad]lots_o_sprites.capx[/attachment:2xo480ad]

    [On a side note, I started adding Groups to the code to help profile, and I noticed when I added a certain Group the FPS dropped from 40 to 25. Just an empty group! If I remove or even disable the Group, FPS goes back up. Please see the "UpdateValues" group in the capx. BTW an exported version is unaffected this way.]

  • It would be interesting to know the percentage of C2 users who write for desktop only and have no interest in mobile.

    I have little to no interest in mobile.

  • EVERYONE! EVERYONE! ATTENTION! ATTENTION!

    I just had a magical epiphany.

    Now, this idea may seem stupid since it's technically fueling Sccira's competition, but what if, and I think this is a win-win scenario for everybody so hear me out.

    What if Ashley made Construct 3 as he intended, that is a Construct 2 extension.

    And made a Unity2D asset that mimics Construct 2's event system for those of us what need/want need to export natively to PC and to export at all to consoles.

    First off, we'd still be supporting Scirra by buying it, second, it would be great income since, imagine Unity's powerhouse with Construct 2's editor. Just holy sh*t you guys. Third, we'd have an improved Construct 3 for those of us who still want pure HTML5 fun, and those of us who need it could buy the Unity asset for consoles and native PC.

    That way, Ashley doesn't need to bother with making a entire bloody engine, we don't have to nag him unrelentingly for native anything and he stills get more income! It's perfect! And he's also be getting into the entire Unity market, so that's a huge new potential customer base.

    Ashley, let me know what you think of it.

    TL;DR

    Ashley makes a Unity asset that is basically Construct 2/3's event system, thus pleasing our native and console wanting cherry pies.

    Construct 3 gets to be whatever Scirra wants without backlash from pissed off users since they have the asset for any needs like console exports and native PC.

    Aurel

    What do you two think of this?

    P.S. Also imagine if you could copy paste events between them? Not the code beneath the events, but the actual events, thus you could have insta-translation from Construct 2's HTML5 to C#, Boo and UnityScript.

    Best idea I've ever had on these forums.

  • How can that Pixi.JS be so fast? I did a version of their Lots-o-sprites demo http://www.goodboydigital.com/pixijs/examples/4 and I reckon it runs faster on my mobile device than the C2 one does on my desktop PC. I made it as close as possible to their code, and turned collisions off.

    I get 40 fps on desktop (Chrome preview) and 2 fps on my Nexus 7. (Also is there any way to know the FPS of their demo in the browser?)

    Did you try DevilMark in the previous posts? native-desktop-exporter-for-construct-3_p879965?#p879965

    Also sort-of built to be similar to their demo thing and it gets some rather good results. Notas good as pixi, but still makes C2 look good.

  • > How can that Pixi.JS be so fast? I did a version of their Lots-o-sprites demo http://www.goodboydigital.com/pixijs/examples/4 and I reckon it runs faster on my mobile device than the C2 one does on my desktop PC. I made it as close as possible to their code, and turned collisions off.

    > I get 40 fps on desktop (Chrome preview) and 2 fps on my Nexus 7. (Also is there any way to know the FPS of their demo in the browser?)

    >

    Did you try DevilMark in the previous posts? native-desktop-exporter-for-construct-3_p879965?#p879965

    Also sort-of built to be similar to their demo thing and it gets some rather good results. Notas good as pixi, but still makes C2 look good.

    Yea I did although it doesn't appear to behave just the same (although probably doesn't matter). Did you try mine? I copied their JS code as closely as possible. See if you can get that comparable in performance to theirs <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> I'm talking mobile ...

  • When talking about performance, I think it's important to keep in mind that the most effective optimisations are always performed at the high-level, i.e. game logic and resource management, that is turning "naive" things into "less naive" things, and either doing something differently in order to achieve the same result faster or compromising on the complexity to find a better balance between user experience and performance. Assuming the developer knows what the target platform perf killers are, as abusing alpha blending on a mobile chip that performs poorly in that area will never fly well ; just an example.

    Only then, when all the low hanging fruits have been collected, can the low-level optimisations become useful. Platform specific low-level optimisations, such as vectorised math libs and so on, will unlock the next ~20% of performance, but it won't auto-magically turn a struggling 10fps game into a smooth 60fps one.

    Also, these optimisations are exponentially costly, i.e. the more a software is optimised, the harder it is to optimise it further, and the more costly it becomes to save another 1ms. Plus, at this level, what is beneficial to one set of devices is usually detrimental to another, therefore multiplying by a factor ~5 all the work (desktop computer, console, high-end mobile, medium mobile, low-end mobile)

    What I'm getting at here is the "game dev time vs performance optimisation time" balance ; when working towards a deadline reducing game development time is always the most effective solution, as it gives more time to perform high-level optimisations which will give the best results in terms of performance. That's where the productivity of tools like C2 shines. We can get something working quickly ! And then if performance is an issue in my game, maybe I just spend a few days to rework some behaviours or levels and save 20ms ; where it would take months of programmer time to save 1ms on physic collisions maths. That's a complete different order of magnitude.

    Know your game, know your logic, know your devices. Don't rely on low-level engine optims and exporters for performance ; it can help, but there's no silver bullet.

    Additionally, a quick word on broken exporters. It can happen. It's always a risk. Every company or project, big or small, faces the same risk, e.g. when choosing an engine, a tool, a service provider, a manufacturer, a 3rd party contractor, etc. They can defect, and you're never left in a good position. That's part of the risk assessment process, and ideally there should be a mitigation plan for it.

    But most of all, choose an engine for what it is, not for what you want it to become.

    Anyway, all of that being said, from my point of view the future of Construct should focus on the productivity of the game development tools : more user-friendly IDE, better debugger (huge potential time savings here!), etc. ; not on trying to cater for every details of every project on every platform.

  • Yea I did although it doesn't appear to behave just the same (although probably doesn't matter). Did you try mine? I copied their JS code as closely as possible. See if you can get that comparable in performance to theirs I'm talking mobile ...

    Yeah, their performance for the same thing is just insane. And it really FEELS smooth, not just in that sometimes weird "high fps, clumsy feeling" that some C2 exports have. I wonder what they are doing differently.

  • Everyone ignoring my previous post?

    #IdeaWasted

  • Nesteris I may be wrong, but I don't think you can apply the C2 logic to a 3D engine (even to export 2D games). It's very different.

    Also, it kind of already exists. If you really want an event system for Unity, did you ever try Playmaker?

    http://www.hutonggames.com/

    It doesn't work like C2, but does a very good job for beginners wanting to jump in Unity + visual scripting : )

    ( should you need some games examples, it has been used in Hearthstone, The Forest, Dear Esther...)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Regarding pixi.js, the main performance difference is the overhead of the event engine. Bunnymark probably uses a line or two of simple JS code to move the sprites, whereas using events involves the use of the well-optimised but fairly significant general-purpose object-picking/action-running event engine. A fairer test is probably renderperfgl, which doesn't move the objects (therefore not needing the event engine), but also does handle rotation (which bunnymark doesn't and probably uses to optimise further). It's still not really a fair test since they are doing different things, but comparing those two I get approximately equal results. The C2 renderer is really pretty much as fast as it can be anyway: it basically copies numbers in to a big typed array and passes it to WebGL.

    As for doing anything involving Unity I think that is completely bonkers. Besides it seems odd that on the one hand some people complain that we depend on third parties for browser technology, and then others suggest solutions that again involve depend on third parties (be it HAXE, Unity or some other intermediary technology). No technology is perfect, and we could be equally hosed by shortcomings in those. Browsers on the other hand are written by billion-dollar companies with thousands of expert engineers, so if we are to depend on any third party, that seems like a better bet.

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