Construct 3 - many questions (native exporterts)

Discussion and feedback on Construct 2

Post » Wed Sep 30, 2015 8:48 am

C3 is more than likely a very long way off.

The following site - Construct 3 - was setup to keep us updated, although updates have not as yet been forthcoming. Hopefully @Ashley will update the site sooner rather than later.
#gentlenudge
If your vision so exceeds your ability, then look to something closer.
Moderator
B
134
S
30
G
84
Posts: 5,391
Reputation: 58,464

Post » Wed Sep 30, 2015 10:04 am

I am a broken record on this subject, but it keeps coming up, so I'll keep asking the same questions back at those asking for native exporters: what is it you really want? Rather than focus on the technology choices, what is the end result you are after?

If it's better performance: maybe WebAssembly can do that, while keeping the broad cross-platform compatibility of HTML5. And as ever, I struggle to find examples where our JS engine is not fast enough - almost everything anyone provides as examples are either GPU hardware limits (so a native engine would not be faster!) or just insanely inefficient game design (such as using 1000 sprites instead of a single tiled background).
If it's more access to native features: I don't know what you're after precisely, but it can most likely be plugged in with Cordova or NW.js.

Some people seem to think native exporters are a magic bullet that will solve all problems and make us incredibly rich. Here are some counter-points to consider:
- it would make the product a lot more expensive. As others have mentioned, many appreciate the fact C2 is one of the cheapest product on the market for publishing to every platform.
- it would make the product a lot slower to develop. If we support 10 platforms with 10 different codebases, every change must be written and tested 10 times, making development 10 times slower. We could use frameworks or libraries to help mitigate this, but some people seem to think it's a really bad thing to rely on third parties too much, so it seems like an odd direction to take, especially given browser developers have far more development resources than most cross-platform frameworks out there.
- if you use any third party plugins at all, you can probably guarantee they are not going to be supported on more than one or two platforms. Even official features may not be supported on all platforms as porting issues crop up. This makes feature support a really complicated checkerboard across platforms, making porting a huge headache. Other products on the market suffer this exact problem.
- there actually exist other products on the market that take the approach of writing native exporters, and they are struggling with all the above issues and appear to be behind us, which to me disproves the idea that "native exporters = commercial success".

There are no magic perfect solutions in technology - don't think that native exporters would be flawless, or guarantee commercial success. In particular, I think the success of Construct 2 so far is significantly due to the portability and ease of development of HTML5, to the extent that I do not think we would have gotten anywhere near where we are today if we had gone with any other technology.
Scirra Founder
B
395
S
233
G
88
Posts: 24,376
Reputation: 193,842

Post » Wed Sep 30, 2015 10:24 am

Ashley wrote:such as using 1000 sprites instead of a single tiled background

There are scenarios where "1000" sprites is needed, like in rts games, and probably many more, so I don't think it is good example against exporters. But personally, thought I wish performance would be better, having native exporters is not my own priority.
My professional Royalty Free Music at Scirra Assets Store
--------------------------------
Specs: i5 2500, 16gb of ram, gtx 770, win 7, Focusrite Scarlett 8i6, Mackie mr8mk2, Alesis 320, browsing the net on chrome.
B
89
S
30
G
22
Posts: 1,985
Reputation: 20,099

Post » Wed Sep 30, 2015 11:05 am

by the time of c3
most people have android 5 devices
ios and windows dont have problem with html5 now
and with android 5 : problem solved
but i wish we hade at least a direct and offline export to each platform (mostly android)
B
16
S
6
Posts: 243
Reputation: 1,755

Post » Wed Sep 30, 2015 11:43 am

megatronx wrote:
Ashley wrote:such as using 1000 sprites instead of a single tiled background

There are scenarios where "1000" sprites is needed, like in rts games

Of course, but I meant this in the sense that the user could have trivially replaced all 1000 sprites with a single tiled background, their game would look and work identically, and the performance would be radically improved - but before they figure that out, they complain about poor performance and ask for native exporters.
Scirra Founder
B
395
S
233
G
88
Posts: 24,376
Reputation: 193,842

Post » Wed Sep 30, 2015 11:51 am

Ashley but when someone use isometric block to create level, imagine how many sprites will be needed
B
109
S
26
G
46
Posts: 1,887
Reputation: 35,170

Post » Wed Sep 30, 2015 11:59 am

same amount? you just have to render them in 30° manner <.< and set your collision blocks differently a bit.
Sea Monsters template - Isometric
Also includes 40 pages PDF of optimizations and "how-to" for your games, and how the "sea monsters" template was built. Follow link for details :)

sea-monsters-templates-and-assets_t162705
B
42
S
14
G
12
Posts: 624
Reputation: 9,421

Post » Wed Sep 30, 2015 12:18 pm

@Ashley
I guess, you don't understand one very-very important thing.
If not-native exporter will be even perfect they could only give us just HTML5 performance...
But desktop games should have much better performance than HTML5 tecknology.

And, I guess, non-native exporters will not ever be perfect that's why the only thing we will have is 20%-80% of HTML5 performance.

You say that 1000 2D-images is too much. But how about games with 5000 3D-objects? How do they work if it is impossible?

I have already posted native and not-native "game" in this topic. It proves that difference in performance is great.

May be you can create voting on the main page of Scirra.com like
"Will you pay for native exporters in C3?
1. I don't need native exporters
2. I want native exporters but would not pay any cent for them
3. I would pay 50-100 $ for each exporter
4. I would pay 50-100 $ for all the exporters
5. Native exporters? Just take my money!"
B
47
S
20
G
34
Posts: 115
Reputation: 20,716

Post » Wed Sep 30, 2015 12:58 pm

yep, make a 3D game with 2D game makin' software. GL with that one bro. (without q3d)
Sea Monsters template - Isometric
Also includes 40 pages PDF of optimizations and "how-to" for your games, and how the "sea monsters" template was built. Follow link for details :)

sea-monsters-templates-and-assets_t162705
B
42
S
14
G
12
Posts: 624
Reputation: 9,421

Post » Wed Sep 30, 2015 1:47 pm

@saiyadjin can you tag the people you're responding to?

@Ashley As for where and why native would be preferred, mainly desktop and console! The systems where big "advanced" games actually mean games newer and more complex than the 1980's arcade machines or SNES titles with newer graphic effects.

Construct 2 games fail hard on Mac OSX and Linux with games over 500MB, and most of that size is soundtracks. We can't update to newer NW.JS so we're using NW 10.5 (which is great because it seems that's one of the only ones that supports Greenworks now!).

Mobile and web set lower demands for game complexity and detail, but desktop and console is an area where games get larger and sometimes need that extra content and CPU power that JavaScript loves to consume (almost all graphics in our game are less than 128x128, but there are lots of items and enemies) and WiiU doesn't even support WebGL.

The Steam hardware survey is a great way to know what systems to aim for on average ( http://store.steampowered.com/hwsurvey ), and it's roughly a 2.4GHz dual-core Intel CPU with Intel HD Graphics 4000 GPU. Do you use a device with these specs when you test the examples people send?

If making a game that's meant to reach a wide audience, such as a more casual experience, I would say we even have to aim for lower specs than that. Since lag, jank, and other issues that happen at low FPS (falling through floors, etc) look bad on us!

We get the negative reviews, not Scirra and Construct 2, yet it's generally an engine issue that does not happen on far-above-average machines.

In 10 years, when everyone has a huge gaming computer for the price of today's average laptop, I won't care about native support since the devices will actually be designed for HTML5+ and WebGL or whatever other standards appear.

But our team bought business licenses roughly two years ago, to make a game we released roughly last year, to explain to our customers that they just need to upgrade their hardware to play an 1980's-inspired arcade game? They don't buy it, and it makes me wish I didn't buy into the HTML5 dream that keeps being pushed here.
Last edited by Jayjay on Wed Sep 30, 2015 2:00 pm, edited 2 times in total.
"Construct 4 lets YOU make advanced games! (but not play them)" Construct Classic - Examples Kit Dropbox is a pile of trash and if you need my old files PM me! :)
B
116
S
41
G
17
Posts: 2,204
Reputation: 19,545

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 6 guests