- What you want in C2 for 2015 -

0 favourites
From the Asset Store
A cool way for kids to write and practice English Alphabets
  • I'd love for Scirra to take more controls on the exported game. With all the recent problems on node webkit and the other wrappers, that side of the whole game is too prone to go bad.

    Though the idea of auto updating webviews is nice, the risk that a broken update, without the ability to roll back, is too big. I don't want to have to deal with the mistakes of a third party when my game wasn't in need of an update.

    This could be achieved by bundling (or providing a correct link and information) a well tested and working version of nodewebkit for desktop and update only after extensive testing. For mobile the situation is more troublesome for now.

    As for the future, I think they should start thinking into taking real control of the rendering/input/networking part of the engine.

    Haxe is a real candidate as it provides ways to have different native targets. One of the haxe frameworks, snowkit ( http://snowkit.org/ ) is heavily based on webgl standards and deploys to windows, mac, linux, ios, android in native and to webgl too.

    please have a look as it has 3 layers to it:

    • flow, for building and deploying projects
    • snow, the low level part of the engine providing what scirra looks for in a render browser
    • luxe, the high level framework

    This is the killer combo I think we're all looking for.

    My 2c


  • ...Haxe is a real candidate as it provides ways to have different native targets. One of the haxe frameworks, snowkit ( http://snowkit.org/ ) is heavily based on webgl standards and deploys to windows, mac, linux, ios, android in native and to webgl too.

    I'm not sure how Scirra could do anything with Haxe, but if they can, please do so. Haxe is good framework and could solve a lot of the export problems.

  • I think productivity of the existing tools should be an obvious priority, if not the priority, for future developments ; time saved by developers creating games can be spent on project-specific needs, e.g. advanced optimisations, integration of 3rd party plugins, getting obscure platform exporters to work, etc. This would be easier for game developers with a technical background, but would benefit the entire community, as it already does.

    If we focus only on some of these modules, only a subset of the C2 projects will benefit from the improvements, while at the moment that are still certain aspects of the IDE that are a bit clunky and that are clear "time-wasters"

  • i would like to see some small things that make my life easier like

    -setting the initial moving angle of bullets in the editor

    -families for basic things where you can put in different objects like sprites and tiled backgrounds

    -scaling for tiled backgrounds


    and i would love to have an easy mysql implementation, like mentioned here before, for storing and receiving data

  • I would like to see:

    An option to export without comments and free lines. Now I have to delete every comment and enter in index.html ... I know it doesn't take much space, but every bit counts

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • [quote:1c9jr5k7]

    > megatronx

    > That screencap I showed you is a sub-event of a "At start of layout" event condition. So it is at the start of the layout.


    > [attachment=0:1c9jr5k7][/attachment:1c9jr5k7]


    > Thus my problem.


    ok, try positioning the objects "on layout loaded" , then set wait:0.1 and then fade in.

    Tried that, that just breaks the game.

  • Ho yes an others requests for Santa Ashley :

    -> If a global timeline isn't possible (plzzzz make it append !!!!!) maybe a movement editor could be cool too

    i use a lote move_to behavior for all animation (setup manually coord + enable the behavior for the move)

    a more friendly editor with the same system could be great

    -> advanced particule, the actualle particule system is great but lack some features

    ex :

    color change/blend

    the abilitie to edit/visual the particule, actually only showed on the runtime


    -> Animated Tile map or Tile animation


  • Just to throw my view on some of the topics cropping up here:

    Exporters - "depending on third parties" is unavoidable with pretty much any software development. Native engines depend on the OS and drivers instead of the browser, and those are rarely perfect either. Driver bugs can mean games glitch up or crash, and there is almost no reasonable way of investigating it other than buying the affected hardware, setting up a system to use it, installing a particular version of the driver, debugging it, then coming up with a (sometimes convoluted) workaround - if the problem even makes sense. This applies to both mobile devices and desktop components like graphics cards. Our old native engine in Construct Classic also depended on DirectX which needed a separate installer which was a big pain in the ass for everyone.

    Further, portability becomes extremely difficult with native engines. Several competing tools with native exporters have really patchy support for features across the different exporters. Some features may simply not transfer to other platforms because they are not supported, or they work differently, or the developers never got round to porting it there. It also massively slows down development since a lot of new features need to be written N times for N platforms, with N times as many bug reports, and the extra challenge of maintaining compatibility between N implementations; with C2 we only ever need write it once. Third party plugins in particular rarely support even half the supported exporters, only covering whatever platforms the plugin developer happened to have the SDKs set up for. HTML5 is really good at getting stuff to just work across platforms. Browser support does mean there are occasional gaps, but it's all based on standards and browsers are improving really fast, so gaps get filled in.

    I truly believe that native exporters would mean we end up doing nothing other than maintaining a bunch of parallel codebases with no time to do anything else, with games that cannot be ported between platforms, and no fewer dependency issues than we already have. I think it's another case of the multiplayer engine feature, where people suggesting it imagine it working out far better than it will in practice.

    Related to that is wrapper support - we've already dropped support for all non-browser wrappers. The remaining "wrappers" are actually true browser engines that are pretty much completely compatible with the existing engine, so it's more or less a finished job. I'd also note that most browsers manage regular updates without breaking the entire internet, so I'm sure apps will be fine too.

    Also related to that is performance - I'm willing to profile any .capxs that people send to me which have performance issues, and see if there are any bottlenecks in our engine. Most of the examples I see though are simply extreme cases of ignoring the performance guidelines and designing an incredibly inefficient project, or they otherwise exceed the hardware capabilities of the advice. Rarely is the C2 engine the bottleneck. In particular WebGL allows native-grade use of the GPU, so if your game is GPU bottlenecked, a native engine will not perform better. Modern mobile devices are also approximately as powerful as a cheap laptop - or more powerful - so if your game doesn't run on mobile, it probably won't run on low-end desktop systems either, and both types of system have plenty of power to deal with a well-designed game.

    3D - I've said it before and I'll say it again! It's a whole different product idea IMO, and we're going to stick to a 2D tool for now.

    As for our plans for 2015, there are a lot of good ideas in this thread, but they're not really possible until C3, which we plan to start addressing this year.

  • I would say that the current route Scirra is taking is fine.

    My wish is: 10 or 20% more time time spend on ways to improve the C2-performance. (I am not saying it is bad right now)

    For example: use of memory, or anything that can make the fps go up or memory usage go down. (and again, I am not saying it is bad right now ^_^)

  • Ashley: I agree completely about the idea of maintaining several different native engine. It is really a waste of resources.

    That is why I was sugesting haxe, which is a language that compiles down to native. You only write in one language.

    Now on the framework side I also agree there are differences, but that really depends on how well such framework is designed.

    snowkit/luxe engine for example is really well thought and modern in design. Everything I have tried works across all the targets, from mobile to desktop and webgl.

    You can also refer to Kha (https://github.com/KTXSoftware/Kha), still based on Haxe, that has full support even for consoles!

  • Ashley I have no idea if this post could be interesting to you or not, but the Haxe creator is a lovely chap and a friend of mine, if you want me to do the introduction.

    Bonus: we were on stage to talk about engines last month during a festival, and he has a very good idea / opinion of C2.

  • My only request for 2015 from C2 is for C2 to keep being C2. You guys are awesome and this software continues to improve at an astounding rate. With HTML5 finally reaching towards its potential, and with smartphone and tablet technology having moved forward so far already, it won't be long before the full power of C2 can be realized across the market.

    Really great stuff here; please keep it going in 2015!

  • We look forward to seeing the new updates to C2 in this new year 2015!

    Ashley thanks for C2

  • Others ideas for Santa Ashley :

    Priority -1 : (more critical than 0 <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz">)

    30 FPS MODE (or the ability to fix the framerate/frameskip) :

    I really prefer an fixed smooth 30 fps mode than a flickering 60 fps mode (47-58-43-60, .....)

    This will help a lot for less performance wrapper.

    (last HD game console use this, why not use ?)

    Exporter using other technologie

    Haxe is a great sample for new cross technologie.

    But i understand that you can't waste all that you have done allready with C2.

    But why can you try to mix the two solution ?

    Their not allways oposed or uncompatible.

    And we don't need to keep a true HTML5.

    I'm thinking of Croxit.


    An webview implantation using Haxe that have really fast performance.

    You use it simply like a exporter for HTML5 and if you write/use more your could acces advanced feature with the NME integration done in it.

    NO CONSTRUCT 3 !!!!!!

    for me if you're allready thinking in C3, it's that your actually choice (technologie) are good for a long time production cycle.

    And you can't shame us about the poor perf of html5 gaming.

    C2 is mainly a Game Engine so performance and trully export is the key.

    You make allready a impressive work for a none coder engine.

    It's fast easy and to use.

    But personnatly if you allready switch to C3, i'll think that i waste money on C2 and prefer to definitly switch my self on an other engine that i'm allready using like Unity3D or Godotengine (i need to really make some test to gamemaker for 2D project).

    Keep going on C2.

    Maybe you need to keep more calm on beta release.

    Make use only 1 beta/month but with more deep change <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

    you make great work on C2 don't waste it <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

  • Others ideas for Santa Ashley :

    Priority -1 : (more critical than 0 )

    30 FPS MODE (or the ability to fix the framerate/frameskip) :

    The last time this was tried the engine effectively collapsed on itself, C2 is fantastic, but the more I read about other users experiences (my work is on mobile, where FPS isn't a massive deal) "50+ FPS or go home" seems really apparent.

    Just throwing my 2 cents in, looked at Stencyl after reading about Haxe, they've got a great UI where things like sprite windows are displayed as tabs - I'd actually quite like that for C3. If only to get rid of having to resize and drag around the frame window/image canvas because they stack on top each other...

    In regards to C3, I welcome it, though the inevitable 6 month drought makes me sad. In an ideal world C2 would have modurality so the community could "take over" C2 development as Ashley worked on C3, but as modularity itself would require an architecture change it's logical that this will be a feature that will fall into C3s USPs.

    Which'll be great, because it has a real shot of turning what could be a slow start (as any new version of software would have) into a community supported one.

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