- What you want in C2 for 2015 -

Discussion and feedback on Construct 2

Post » Sun Jan 04, 2015 8:10 pm

megatronx wrote:
Nesteris wrote:@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.

Events.png


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.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Sun Jan 04, 2015 8:15 pm

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
ect...
-> Animated Tile map or Tile animation ;)
-
B
85
S
14
G
6
Posts: 72
Reputation: 7,237

Post » Sun Jan 04, 2015 8:42 pm

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.
Scirra Founder
B
395
S
233
G
88
Posts: 24,376
Reputation: 193,842

Post » Sun Jan 04, 2015 8:52 pm

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 ^_^)
B
27
S
6
G
7
Posts: 678
Reputation: 5,651

Post » Sun Jan 04, 2015 11:18 pm

@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!
B
32
S
4
Posts: 57
Reputation: 1,550

Post » Mon Jan 05, 2015 12:53 am

@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.
Image | @AurelRegard on twitter
B
19
S
6
G
1
Posts: 307
Reputation: 2,500

Post » Mon Jan 05, 2015 3:44 am

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!
B
30
S
6
G
5
Posts: 249
Reputation: 5,608

Post » Mon Jan 05, 2015 9:26 am

We look forward to seeing the new updates to C2 in this new year 2015!
@ashley thanks for C2
B
157
S
27
G
17
Posts: 910
Reputation: 32,588

Post » Mon Jan 05, 2015 11:07 am

Others ideas for Santa Ashley :

Priority -1 : (more critical than 0 :P)
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 ;)
you make great work on C2 don't waste it ;)
B
85
S
14
G
6
Posts: 72
Reputation: 7,237

Post » Mon Jan 05, 2015 11:29 am

ThunderZ wrote:Others ideas for Santa Ashley :

Priority -1 : (more critical than 0 :P)
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.
B
59
S
21
G
9
Posts: 641
Reputation: 9,787

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 13 guests