- What you want in C2 for 2015 -

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.

https://github.com/waneck/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.

My notes:

1) I think guessing polygon shape right after importing a sprite is a bit frustrating, at least for me. Although it's a great feature I rarely use it, box collision shape is fine for me in most cases.

2) Search box in "Projects" tab is a necessity. I usually keep stuff highly organized but still it doesn't help me much.

3) Customizable number of undos

4) Make it possible to give an object some custom setup after spawning on preview because sometimes when you spawn a few similar objects but want them to be different size(or to have different variables) they usually end up changing together, at the same time. I try to make workarounds based on UID or IID and other stuff but it doesn't always help me.

That's all for now. Maybe I'll come up with other thoughts later.

How'bout "containers" for Families? Each time you create an instance of something in the family, it automatically contains the family container object. I could use this right now for sure.

Haxe isn't necessarily going to fix any performance problems. Like I said, most projects which run in to trouble are either exceeding hardware limitations, or grossly inefficiently designed. I rarely see projects where the C2 engine is the bottleneck, and where I can I optimise it so it's no longer the case. Rewriting the engine in another language is a colossal project and does not change that. Also modern JS engines are very good and can get close to native performance, especially with asm.js, which to me would be a far more compelling choice (but not without its own tradeoffs). I really think a runtime rewrite is off the cards for now.

Also the rate HTML5 is improving is so fast, and with the might of well-resourced companies like Google and Microsoft behind it, I reckon it will be native-equal or better before we could even finish a new runtime.

Ashley I think a few people are mistaking the latest chrome/NW issues with C2's performance...

> And isometric isn't really that hard to do in events. I don't feel like it needs its own editor.

>

Is it easy to create an isometric layout, place your graphics, player and set to 8way- walking behaviour?

Yes, kinda

[REDACTED FOR LENGTH]

All i'm looking forward to are some tools or behaviours or events or whatever to help us in the development of an isometric environment. And i'm sure i'm not the only one.

isometric... in my point of view is still one of the top notch layouts you can achieve in 2D.

I'm not really sure exactly what you're looking for (given that, y'know, you're a different human and I am not a mind reader) but within the past year I've made two isometric games, one of which includes "floors" so to speak, and the other a full dungeon crawler with abilities and collision. This isn't really the topic to discuss this in, though, so if you want, private message me or something and we can talk about it.

My comment wasn't related only to performance, but mainly about the fact that Scirra and the users don't have control over the more low level part of the engine.

Honestly I'm a really scared that an auto updating webview, more than nodewebkit, could break a perfectly working game without any action from the user (or even knowing it really). Who do you think such a user would contact when the game will crash or will start to jitter? And do you think telling them that the problem has been generated by the os auto update and that the solution and timing is up to them, will be enough or will you lose clients?

2014 was the last of any meaningful advancement of C2. At this point C2 can only improve the current set and offer a few new plugins. C2 is hitting the peak of of features. Once that peak is crested then all that's left is stagnation and then at the end of 2015 there will be a large number of complaints wonder where the meaningful changes are. If the entire Contstruct line is to continue to have effective growth, penetration and meaningful features, C3 is the way to go.

C3 is mostly an IDE overhaul not an engine overhaul. I think a lot of people are mistaking the move to C3 as CC to C2. That's not the case. C3 will still be running the C2 game engine. Will end up using the same C2 plugins. However with the new IDE, structure and so on. New meaninful features can be added. Such as way points, editable bounding boxes, custom windows for plugins, Timeline animation, prefabs, scenegraphs so on. Not saying all done by Ashley, but features can be done by others.

Who knows, maybe C3 will offer an update price as an early adoption from C2 to C3.