Construct 3 - many questions (native exporterts)

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.

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.

I have to agree with that. I stopped developing my ambitious projects exactly for those reasons.

Jayjay : there's a conflict of requirements between designing desktop/console games that "need [the] extra content and CPU" and targeting the "dual-core CPU with HD4000". By essence applications made to run on low-spec hardware should be stripped to the bare minimum, without the extra content and cpu-intensive stuff, to ensure it runs well.

Btw, have you profiled your game to see why it performs badly on some hardware ? Maybe it's just a bottleneck that can be avoided or worked around

Some very good showcases are progressively appearing ; I'm thinking The Next Peneloppe by Aurel, CopyGirl and the Metroidvania Gamekit by Tokinsom & 7Soul, etc. This proves moderately complex games can be made to perform well.

Native and platform specific optimisations are always done last on a game project, and they don't account for that much in terms of performance boost. Optimising the content and reworking the algorithms usually do most of the job.

Additionally, depending on the hardware, well designed content, good logic and native tech sometimes aren't even enough. For example a specific generation of mobile devices was absolutely terrible at processing certain types of graphics things (few and poor pixel processing units, abysmal texture read operations, appalling blending performance, etc.) ; to work on these devices, entire sets of art assets needed to be reworked to avoid this hardware limitation ; basically spreading the cpu/gpu/ram/vram load differently. Just an example, but typically this is an extreme case of something a tool cannot do.

It's impossible to create complex games easily ; the complexity of the underlying technology always reflects the complexity of the games. Which also means a stronger constraint on the user to understand the technology in order to use it efficiently.

Ease of use, functionalities, efficiency, portability, cost, etc. One single solution cannot do it all, because these are conflicting requirements.

There are already lots of other solutions to create games - native programming frameworks, portable engines, visual tools, complex modular editors, etc. C2 fits nicely between all these and provides a good answer to a collection of problems.

Ashley just can make c3 as a plugin for unity !

as a visual scripting plugin and work on that = " only c2 advantage "

just see how much playmaker sold out !

why you don't want more money?!!

It's impossible to create complex games easily ; the complexity of the underlying technology always reflects the complexity of the games. Which also means a stronger constraint on the user to understand the technology in order to use it efficiently.

Ease of use, functionalities, efficiency, portability, cost, etc. One single solution cannot do it all, because these are conflicting requirements.

There are already lots of other solutions to create games - native programming frameworks, portable engines, visual tools, complex modular editors, etc. C2 fits nicely between all these and provides a good answer to a collection of problems.

I think this hits the hammer on the head for the most part. Something that has complex natures should be at least somewhat complex to create. Every program has a weakness, but the question is, are these necessary weaknesses? I'm not even going to pretend I understand the amount of work and/or money it would entail to create native export options for several platforms. But at the same time, I have a very hard time believing that a lot of these issues don't go away with the use of native exports. Using HTML5 wrappers bloats the size of the project (Regardless of optimization, there's no denying this) and causes bugs that wouldn't appear in an HTML5 game normally for unexplained reasons. There are workarounds, sure, but the way I see it, if you're going to spend hours trying to find a workaround to bugs and optimization issues that wouldn't normally apply to your game if it was released as intended (HTML5 release), doesn't that defeat the purpose? Might as well suck it up and learn a program that's not as good as C2 in that case, right?

Using HTML5 wrappers bloats the size of the project

It does - but no more than, say, deploying a software made in Java (requires JRE), C# (requires .NET), Flash (requires Adobe player), Unity web (requires Unity webplayer), etc. Even pure C++ has some dependencies (requires CRT libs, typically the msvcrt.dll variants people get when installing games on Windows). People install all these without complaining.

I don't see this as a very significant point when choosing a technology.

[quote:1b1z6li2]bugs that wouldn't appear in an HTML5 game normally for unexplained reasons

Pretty much all the bugs are down to standard compatibility and device specificities. Because platform "blah" doesn't implement all things defined by the webgl standards properly, the "exported" app doesn't behave perfectly. Because device "thingy" takes some "shortcuts" or doesn't have some hardware, the exported app doesn't behave perfectly.

These don't go away with native solutions. Actually it is worse, which is why cross-platform engines usually end-up with one engine to maintain per platform they want to support, while trying to abstract all the common features as best as possible.

In both situations, using wrapped portable or native specific, the only way to ensure the end result behaves as expected is to design the game knowing from the beginning which platform(s) to target ; because the tools / engines / frameworks / whatever is used, will need to be used differently.

For example one shouldn't create a game and THEN decide to target the WiiU and the iPad2. These have so strong (and conflicting !) requirements they need to be factored in from the beginning (especially regarding art assets and use of alpha blending). Using native solutions doesn't remove this constraint. Just an example.

Refeuh I can assure you that after multiple delays to do re-designs, re-codes and profiling of each of the mechanics in our game, we did not find much else that could boost the performance.

Work-arounds are something that we have specialized in since Construct Classic, so although your points are true that sometimes it is the games fault, it is also true that sometimes it's a fault in the engine.

As for changing the scope of the game to something smaller, I would, if our game wasn't something that basically could have been on 1980's arcade machines (https://en.wikipedia.org/wiki/Black_Tiger_%28video_game%29). The Next Penelope is an awesome game, but it could also be described as a top-down FZERO, which the SNES could handle if it wasn't in HD (Black Tiger ran a 4MHz Z80 CPU, while SNES had a 3.58MHz Ricoh 5A22 CPU, I know that direct CPU comparison doesn't count, but it's not entirely a "high expectation" that my game should run as well as these systems).

Ultimately the arguments of "think/dream/try smaller" and "are you sure/double sure/triple sure that you coded it right?" are not actually good methods of shutting down this conversation. Maybe native isn't the solution to the real concern which is poor performance on desktops and consoles, which we can see is not happening in Construct Classic, Unity, Godot, and many other tools that export to native/rely on existing OpenGL and DirectX runtimes.

As mahdi71 jokes, I actually would buy a Construct-style interface for 2D game dev that runs on the Unity runtime, even though I know how to program (in C#, Java, etc). I like the speed that C2 has editor-side for putting things together. That is why I'm moving on with future retail titles to use Unity instead of Construct, but still care so much about the future of Construct.

> Using HTML5 wrappers bloats the size of the project

>

It does - but no more than, say, deploying a software made in Java (requires JRE), C# (requires .NET), Flash (requires Adobe player), Unity web (requires Unity webplayer), etc. Even pure C++ has some dependencies (requires CRT libs, typically the msvcrt.dll variants people get when installing games on Windows). People install all these without complaining.

I don't see this as a very significant point when choosing a technology.

The real issue is that these wrappers don't just add a bit of bloat, but they are middleware unlike the Unity Web Player (which Unity can control), Flash (which Adobe can control), Java (which Oracle can control), and .NET/DirectX (which Microsoft can control).

Instead we're using NW which is based on Chromium, so it's Scirra having no control over NW.js, and who themselves have very little to no control over Chromium. So we're stuck when it comes to a Scirra-specific fix to hope that NW pays attention, and if they can't fix that (jank) that Google pays attention.

For example one shouldn't create a game and THEN decide to target the WiiU and the iPad2. These have so strong (and conflicting !) requirements they need to be factored in from the beginning (especially regarding art assets and use of alpha blending). Using native solutions doesn't remove this constraint. Just an example.

True, but Construct 2 should live up to its advertisements or have some small print like "WiiU as long as you don't use WebGL, complex coding, or expect real-time gameplay". Native does fix the issue of needing GPU support over Canvas2D as well.

funny... people go into ambitious projects expecting miracles to happen, and when they get dissapointed they give up.

a normal story in game dev. unity, unreal, or anything else.

you guys gotta think smaller and focus more on quality - > road to victory (or at least some money

funny... people go into ambitious projects expecting miracles to happen, and when they get dissapointed they give up.

a normal story in game dev. unity, unreal, or anything else.

you guys gotta think smaller and focus more on quality - > road to victory (or at least some money

It'snot that. We've been doing this for a very long time, and we're getting frustrated by now with the time that it is all taking. Even in simple games performance drops at random intervals.

In many ways construct classic was better, and the follow up is disappointing, even thought its logic is better. There was just misunderstanding when decisions about c2 were happening: it seamed that people where not releasing bigger games, where in fact no one finished their big projects due to the amount of bugs that the software had.

Jayjay Thanks for the detailed reply I wasn't trying to shut down the conversation, only trying to understand and propose some elements of answers to other previous posts as well.

Though going back to performance issues, there are examples of moderately complex games performing reasonably well ; so I guess you'll agree with me that if something doesn't perform well, there has to be a difference of either scope, platform or use.

Also I think we can agree we have 3 major layers regarding performance : the hardware (low level), the engine (abstraction, mid level), the application (gameplay logic, top level). Ignoring all possible preconceptions about blaming the game or the engine, were you able to identify the bottlenecks in your case ? Maybe it is the engine, e.g. not doing well with resource management and hammering the memory inefficiently ; maybe it is the hardware, e.g. dealing very badly with some scenarios, etc.

So really I'm not pointing fingers specifically at the game logic, all I'm saying is that it'd be interesting (for us) to know what caused the problems. Maybe it would possible to make these more visible to the users through the tools.

[quote:3la4fhto]wrappers don't just add a bit of bloat, but they are middleware unlike...

Fair point ! Though we don't necessarily have to use Adobe, Oracle or Microsoft tools to create content for their platforms. I guess one of the issues is that nobody really "owns" HTML5, and big companies are stiring things in multiple directions (google v8, ms typescript, etc.) and it's not yet a fully mature technology

[quote:3la4fhto]Construct 2 should live up to its advertisements...

Isn't that true for all tools and platforms ? Maybe what C2 would need would be "platform presets" ; e.g. targetting iPad2 ? fine, let's disable all fancy stuff that we know won't run well. And so on.

Thanks for the detailed reply I wasn't trying to shut down the conversation, only trying to understand and propose some elements of answers to other previous posts as well.

Refeuh I really appreciate that, and I agree that it's important to look at the different layers. There are so many variables that can form together to make the game not run on one computer and run fine on another that it is unfair to blame entirely one part of the chain.

Often there are people who are very unlike you though, and reply to threads/comments like this with a simple statement that the developer has simply not tried "hard enough", or has "dreamt to big without putting the effort", or that they should reveal their entire source code or try re-coding the whole thing in another engine to prove it's C2/NW/HTML5/WebGL causing the majority of issues instead of the game itself.

These don't apply to every developer though, especially in our case given that our title actually was finished and released on Steam, with every possible effort put into improving it.

Most importantly to me is that I think there is a big difference between giving up, and migrating tools. Migration is a warning sign that something isn't quite working as Scirra customers expect, especially if the game does end up working better in the new engine.

Fair point ! Though we don't necessarily have to use Adobe, Oracle or Microsoft tools to create content for their platforms. I guess one of the issues is that nobody really "owns" HTML5, and big companies are stiring things in multiple directions (google v8, ms typescript, etc.) and it's not yet a fully mature technology

Definitely agree, Chrome has made some major pushes that seem to establish dominance for now, but it's more chaotic than even OpenGL was.

Isn't that true for all tools and platforms ? Maybe what C2 would need would be "platform presets" ; e.g. targetting iPad2 ? fine, let's disable all fancy stuff that we know won't run well. And so on.

In general yes, I would say so, and that I like that idea as well. The only extra parts I would add is that the NW export does not run the same on Windows, Mac OSX, and Linux even if the machines running those OS's have the exact same specs otherwise.

This is again an issue with NW and maybe not C2, but it should have a warning for the developers before they get a beta working fine on all platforms, and then promise Win/Mac/Linux (because the engine they use promised them the same thing) for the final game after getting some crowdfunding or Steam Early Access sales. It's a great way to annoy customers when you start cancelling ports.

Jayjay In our case it's all middleware fault. Doesn't matter if your game is fast paced or not, sooner or later performance wobbles.

megatronx - i'm pretty sure it's not me / engine that is wrongdoing this.

i'm using nw 12, and people whine how bad it is, blah blah, but when i export my game with it, and play it, i notice 0 jerkiness (that people whatsoever reported all the time). also performance is on the highest lvl.

and trust me, my game is for PC, and uses loads of wrongly done stuff, but still works good. i'm doing an improved version atm, but i can host my game if you want to try the old version. it uses almost everything (except ads and shit) that c2 can offer. bump mapping, effects, particles, scrolling background, families, combinations of this and that, and much more. works like a charm.

megatronx - i'm pretty sure it's not me / engine that is wrongdoing this.

i'm using nw 12, and people whine how bad it is, blah blah, but when i export my game with it, and play it, i notice 0 jerkiness (that people whatsoever reported all the time). also performance is on the highest lvl.

and trust me, my game is for PC, and uses loads of wrongly done stuff, but still works good. i'm doing an improved version atm, but i can host my game if you want to try the old version. it uses almost everything (except ads and shit) that c2 can offer. bump mapping, effects, particles, scrolling background, families, combinations of this and that, and much more. works like a charm.

What specs your pc is ?

Even in simple games performance drops at random intervals.

Interesting conversation, guys. I really like the way it's being conducted.

But I would like to see just one simple game that doesn't perform well which:

-> is coded really well,

-> doesn't put every event on the "every tick" condition,

-> doesn't add large images which are not power of two sized

-> doesn't overuse effects and particles

-> many other stuff I forgot.

Many AAA games developers needed and still need some sort of workaround and time consuming

optimization (maybe less today) with the amount of polygons being shown, line of sight simplification

for distant objects, the way to deal with off-screen assets, hardware limitations when porting to other platforms,

some even have to deal with graphic drivers and boards issues.

If a very simple game has bad performance maybe an example CAPX file will be worth a thousand words

so we can see if it's well coded, well designed from the ground up and suited for the platform it's built.

Then I can blame the engine. I've seen so many horrible demos giving its engine a bad name that I

became suspicious to say the least.