Jayjay's Forum Posts

    Which threads were unjustly locked that you are referring to?

    Good point, I unfairly lumped locked and closed together in one there.

    I am more so concerned about closed bugs (which I mistakenly believed were locked) which were closed simply for not fitting within the tight guidelines on bug submissions.

    I'm not going to defend a 4 year old blog post. Yes, it's probably wrong. It was just an interesting benchmark result. I haven't spent the past 4 years claiming HTML5 games are faster than native. Just that they're fast enough. It is basically fair and correct to say WebGL has identical GPU rendering performance to native code.

    Hehe, I don't think you need to say it's faster, but for your target audience that last sentence is going to sound the same to them and they'll be upset when they find out what that actually means.

    Again, I do think it's a pretty unique thing that you actually can talk directly to the founder, but I'm starting to see the appeal in disappearing behind a corporate team page...

    We talk to our customers too, it's part of our charm as a small indie team. The same applies for Scirra, not participating in the discussions just proves everyone who says Scirra doesn't listen is right, although I guess ignoring their concerns and locking their threads / bug reports does the same too

    tunepunk Q3D is awesome, built on ThreeJS, so you're only seeing the C2 event system and 2D collisions/physics and audio subsystems at work there. Shows more WebGL's strength than Construct's performance.

    Also, Unity does have different eventing types: plyGame is quite a bit like event sheets, but there's also PlayMaker and a few other visual scripting tools available for it. It's probably just a matter of time before "I stay with C2 for the event sheet" becomes "I switched to Unity for the event sheet" and it'd be a massive shame if that wasn't an event sheet plugin made by Scirra.

    To be fair, since my post that jayjay quoted me with I have since got a replacement for my 10 year old computer so the graphics are no longer a bottleneck on my system. Also the few times I tried mobile export the performance was much better than my old system.

    Great point R0J0, although the Steam hardware survey says that's not the norm with only half the systems running Win 10+ (almost 30% still running Win7 systems) and only half are quad-cores on all of Steam.

    From a commercial perspective, a 2D game that requires a quad-core CPU and latest line of NVIDIA or AMD or *maybe* Intel isn't very acceptable to the developers or their customers, and it reflects in Steam reviews and comments across other forums.

    Events can be abused way easier than code, and even the templates that come with C2 aren't designed for performance necessarily.

    There's dozens of different ways to do things, and many of those are just terrible for performance.

    I'm telling you there needs to be some exposition into the proper use of them.

    You make a "for each object" that runs every tick, then the exporter should give a warning, etc.

    Have to agree with that being a useful feature, plus it means that instead of users finding work-arounds to issues like families (eg: often needing a for each object to actually let each object in a family do what it's supposed to individually) then the users would be forced to submit bug reports to issues and improve Construct for all.

    Although I also agree with jayrp1 because the users here are probably seasoned in the tool and have done whatever it takes to save performance already.

    1) What exporters are missing from C2? They all work. Some work better than others; none of them are broken.

    Have you any games with paid customers / mass publishing ? A lot of the users bringing their complaints here do, or have tried to reach platforms that C2 promised them and failed (WiiU in particular)

    "Some work better than others; none of them are broken" is not valid for this audience, and the phrasing suggests that merely being able to export is the end goal of the Construct workflow.

    However, I propose a radical opposition to this: The games should work.

    Customers can't tell when an exporter has worked properly or not, they can tell when a game is unplayable.

    Producing unplayable games is not the interest of commercial developers.

    Scirra needs to come out and say "This isn't meant for you" to commercial developers if they aren't going to be expected to have 100% export and functionality to the platforms they list on their advertising.

    Or, they need to at least list the side-effects of export to each platform like a medical commercial.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    ...

    so when I see this claim pushed over and over despite gallons of real-world evidence otherwise - and sorry, but your internal tests with tiny little games or demos mean nothing when compared to thousands of copies of commercial games out in the real world that show the opposite, and PLEASE don't try to blame the game's developers for this as you've done in the past - it's very hard to swallow after the 100th time when all evidence points to the opposite being true.

    +1000

    Do you want us to build native engines? I've covered that in this blog with our rationale around that, which nobody ever really directly argues against, there's just vague accusations of how HTML5 is "poorly optimised" or something, which really is not the case given the potency of modern JIT compilers and the native-equivalent performance of WebGL.

    Actually I and others do have a problem with the arguments in that article, as well as the article on "HTML5 games faster than native"

    Let's see:

    WebGL is close enough to OpenGL to be considered the same performance-wise. In other words, Construct 2 games render in practically the same manner a native engine would.

    ...

    We already cover Xbox One and Wii U - so that only leaves PS4. Currently we're blocked by Sony not providing an easy way to publish HTML5 games to the PS4. Given how well our Xbox One support worked - requiring no significant changes to our engine to work on a console - we are keen to see Sony supporting HTML5 on their console too.

    There's a few arguments against those lines of thought:

    Listing GPU fillrate as the main cause of a games slowdown... and then stating that the WiiU is a viable export platform is quite funny. WiiU doesn't support WebGL, meaning not only regular GPU "fillrate issues", but no special FX and low performance.

    5FPS after losing WebGL and FX is still not playable for a platformer. We didn't even make an HD title, just a retro 16bit platformer with 32x32 to 64x64 pixel sprites on average.

    As for fillrate being "the main culprit", there are many instances where CPU should be considered too (eg: most enemies and players using the platformer behavior) and, no matter the optimizations, aren't going to be able to combat the issues of JavaScript without emscripten. But, if you make a tool that exports to HTML5 through emscripten it might as well also export the actual C/Cpp (to port to the JS, best of both worlds).

    Even the mobile games developed with Unity and Unreal put C2 at the ground... How you can even compare?

    - Native games is WAY better in lower and mid hardwares, and this is AMAZING because more people will play your games.

    ->>Scirra depending on thirdy-partys for realese our game. Remember when you guys drop support to Cocoon as exporter? That's why I droped C2.

    ...

    By the way, The Next Penelope is being ported to C ...

    To me the main issue I had with html5 games is that on low-end devices (iPad 2) they perform not really well at all. The same simple app on iOS, even with the super accelerated safari, tends to have small hickups and feels not smooth compared to the same done in a native engine (love2d in this case).

    The situation seems a bit better on newer devices (iPhone6), but still showing those small jerks every now and then (are they GC related?).

    All of this scares me away from trying to do something serious with html5 engine.

    While it's true most devices support webgl it doesn't mean we get the same performance as native in that respect. In my experience it varies per device, and it's just not about the hardware capabilities. Case in point, for me in CC rendering is way faster than in C2. This goes against your benchmarks so that leads me to believe webgl gives native performance on only certain devices. The argument that the hardware is the limit doesn't fly when changing software and doing the same thing performs a lot better.

    The browser's hardware support is primarily about having everything work instead of having everything have good performance imo. Even things like the vsync jank is still there on some hardware. This is probably what causes the disparity between the issues users see and what is tested.

    I don't know if native support would fix this, and I realize doing so would cause a load of different issues and multiple code bases, but there seem to be core issues with how browsers do things that are not performant.

    Now, in regards to "HTML5 faster than Native?":

    Construct 2's WebGL renderer is faster than our previous native C++ DirectX 9 based engine - the one we developed for Construct Classic.

    This is a completely wrong comparison, because C2 is largely an improvement and optimization on CC, you already learned from past mistakes and found new ways to optimize. It's the software form of a "straw man" argument against native.

    If you back-ported those optimizations back to C++ you'd find that the results suddenly return to native being the fastest and smoothest. We can tell this ourselves from simply our experience of porting to Unity in C# with our current game and seeing it run much faster and with more lighting, special effects, and enemies on-screen than our C2 prototype.

    Then there's also the people who didn't see the results that are promised in that article with C2 vs CC:

    97151 - WebGL

    128458 - Native

    i3 - 3220 / GeForce GTX 550ti with small factory overclock / Win 7 64 / nvidia driver 306.97 / 8Gb RAM

    Intel E2180 2Ghz, 4GB RAM, Win7 64 bit, SP1, Geforce 210, Nvidia 306.97 driver

    Native/DX 25613

    WebGL:

    Chrome 22: 3801

    Chrome 23: 4482

    Chrome 24: 3901 (dev)

    Chrome 25: 3503 (chanary)

    FF16: 3254

    i7 9203.6ghz, 48gb, win7 64bit , amd7970 3gb, catalyst 12.11(beta)

    Native/dx: 118040

    WebGL:

    Firefox 16.0.2: 58712

    Chrome 22: 103761

    WebGL Performance (Google Chrome 23): about 10400 objects

    Native Performance: about 24000 objects

    My notebook: Processor Intel Core i5-2410M 2.3 Ghz, 8 GB Ram, Graphic card Intel HD Graphics 3000, OS Windows 7 Ultimate 64-Bits

    I'd like to point out two things from all of this:

    1.) Like the data above, some of the "still-Steam-average" hardware still sees native far out-performing WebGL, and desktop is currently the best supported platform for HTML5 + WebGL. The results may be 4 years old, but the average 2D gamer (based on customer support issues on Steam) hasn't updated their PC/laptop/even just the graphics card in a long time.

    Even with an Intel i7 6700k and GTX 1070 which has much better WebGL support than most of my customers I get:

    Sprites/objects >= 60fps with no drops below

    "Native"/dx/CC: 86k

    WebGL/Chrome/C2: 95k

    This may not be the number of sprites that will appear in a game, but it still reflects an underlying performance gap between Construct Classic (which could be argued to be almost as un-optimized as C2 is optimized) and WebGL. HTML5 is not faster than native. It can get close with WebGL + Emscripten, but it inherently is just not capable of being as fast as native, and I wish that Scirra would stop trying to compare the two this way.

    2.) You can't just ignore comments/evidence/arguments against your company/public statements about your engine and then claim "nobody ever really directly argues against" them!

    Bonus: That multiplayer plugin would probably have been used a lot more if people were able to export their games and "publish everywhere". It's also possible the users are waiting for more helper functions/plugins/behaviours that make tracking objects much easier (Eg: a behaviour for syncing objects). I know multiplayer is generally a hard feature, but it's a great one to have even if it doesn't get used as often as other plugins.

    Like others are saying, yes, export matters 100% more, but I still am glad Construct got multiplayer.

    Although, it seems some other users had a better time using their own multiplayer solutions:

    Using Electron instead of nw.js made my games smaller and better working, using my own networking solution with central socket.io based server destroyed weird, random connection problems that disallowed me from even testing my game. And made multiplayer a lot smoother. Being able to write my own rendering code allowed me for much more control over how stuff is shown on screen what makes performance better.

    Well where do you spend money? For the one time you purchased C2?

    Well I guess I'm another type of user anyway. Since I'm only doing this as a hobby and do not need income from this. I can relate to all of the problems people have, but it doesn't affect me as much so I can be a little more calm.

    C3 is like the No Mans Sky of game engines. Technologicaly a huge step, but the end result is disappointing as of now. No question.

    I used C2 for mobile games and that worked quite well, but for anything other it's Construct for prototyping since forever because it's the fastest tool to try ideas and then taking these to others, but I never had the dream of one tool being the almighty.

    In a few months C3 will be better than it is now and maybe they will even get me to subscribe then for the very reason of prototyping so quickly. And it will be worth that small sub. fee.

    P.S.

    We need to keep in mind that these 10-15 users that are complaining at every thread are not the majority.

    Like you said yourself there will always be people defending the product, and that is because it does not affect them in the same way it does to you.

    Scirra chose the price and how to market their tool / what features to advertise it was capable of. And when discussing the potential for commercial success it should be safe to assume these are users who purchased Construct 2 for the maximum (business) priced license.

    Construct 3 isn't really like No Man's Sky, because GDevelop and many other tools have allowed people to make "hobby games" and given access to "educational coding / learning to program" in the browser before C3. If anything, it's like C3 is the clone of No Man's Sky that does a better job of it (Astroneer? )

    However, you do raise a good point. The few people complaining on the Scirra forums are just some of the biggest games made in C2 / the games Scirra uses in their Showcase.

    They might not represent a majority of the Construct 2 userbase, but they are being used to try and sell Construct 2 as a professional tool / to act as bait for other unsuspecting developers looking to bring their 2D games to desktop + mobile + console "faster" than coding-based engines like UE4 and Unity.

    If Scirra came out and said "Construct is intended for hobbyists, students, web games, and educators" then these kinds of big commercial games would still be made from time to time (as there are some people who are happy with desktop/Windows only), but there would be less upset developers as they know in advance that serious WiiU / Xbox One / Mobile development is not going to happen here.

    The problem is that means the amount of people looking to make commercial products in Construct also decreases, so there's less customers buying the more expensive business license. It also means that Construct then becomes more directly competing with "Scratch" and "Kodu" than the other game making software that is commercially available. Very different marketing tactics would be needed too.

    So with the current marketing, it's almost like Scirra is thinking "Who cares if customers of our users eat them up alive on Steam reviews and forums?" (eg: when we can't make the game work on average-level Steam PC hardware or bring our game to Wii U), and that's what makes the developers here / in past threads upset.

    An idea that came around earlier was for Scirra to try making their own commercial large game (I'd even suggest specifically make it a platformer, to experience the joys of jank, which still occurs even in C3), and I'd rather put money towards that than a C3 license right now, just so that they understand these frustrations.

    Anyway, it's been said a lot and jayrp1 is right, I'll save my breath on this now because, as I had mentioned earlier, we've had to move on at our small studio and C# isn't so bad after all.

    I don't understand why are you guys still talking about the Wii U since :

    1- It didn't sell pretty well.

    2- Everybody is talking about the Nintendo Switch.

    So It won't be any surprise if Nintendo decides to drop support of the Wii U next year.

    Scirra should be focusing on the Switch since most engines are preparing exporters for it.

    Switch has no browser yet (available to the public at least) so we don't know how well it will/wont run.

    However WiiU is still a valid audience, theres a lot of people with WiiU who won't upgrade to Switch any time soon. It's an audience starving for good games

    NotionGames No offence but my opinion but I think you are in this for the money mostly only

    and I find that a really poor way to make games ... just because call of duty and I know you've talked about this with your friends

    but even though call of duty makes millions selling a game that plays with human natural instincts to cash in doesn't mean you need to do that

    with stylized casual games that have been ripped off for years even before mobile was around .

    You may take offence but Id be interested to hear your reply in a respectable manner.

    Construct Engine too me is an engine about allowing you to take your ideas an turn them into reality

    in as simple as a way possible and have the ability to let others play it what platform that is

    personally to me is irrelevant aslong as the platforms it export to are ones people are into

    like the internet that's more then enough for me and people don't directly have to download anything

    to play it win win who cares about console unless your game design requires console support are you a big company

    trying to make 10k a month to fund your team I think you need to build a fan base who are into your games

    and that number can be reached eventually but if you need it really quick then you better hope your game is super meat boy level

    or has same technique of impact that tetris had on silly game addicts, I don't know big companies was never a very interesting idea to me

    Id prefer to be as small as possible?.

    — there was really no call for that level of name calling. Full-time Indies need food and that means money. Even part-time Indies sometimes need resources that cost money. If your opinion had any factual/legitmate basis behind it Construct would still be free and open source for those same reasons!

    Assuming you can doing anything you want on Wii

    We're here for making 2D games, its been done before as we see with games like Freedom Planet and Shovel Knight and many more that seem to run fine on WiiU (some even some made in Clickteam products), that's not "assuming you can do anything you want", it's assuming 2D games will actually run on the console.

    When Construct 2/3 can't compete with arcade + NES level games, I think it's safe to say they shouldn't advertise it as a 2D game maker with the same emphasis on it being professional as tools like GameMaker and Clickteam do. Even the open source engine Godot is used for real desktop and console games, and it doesn't market itself as "professional" as Construct does.

    tunepunk Agreed, but Scirra does get to decide their final price and I think commercial developers would be fine if in-app ad plugins were a business license-only feature or an otherwise optional, paid asset on the asset store.

    Although I think yet another way to solve that whole issue regarding IAP though is premium/paid support, which would be one of the few things to actually make sense as a yearly subscription.

    That way Scirra's customers can directly have some influence over the direction of the software so it meets their needs, and Scirra can be have a recurring revenue stream to stay in full time operation while still allowing a one-time purchase available to hobbyist developers (with cloud build also being a feature worth keeping behind the subscription pay-wall).

    Yes they got that. Hopefully C3 has better mobile export options. That was pretty much a given one. They never really marketed C2 as a mobile game engine, more of a desktop html5 engine, but it's nice they are taking notice since html5 games run fairly smooth on mobiles nowadays.

    I have to disagree, WiiU, iOS and Android are three of the top four platforms they are advertising as "Build Once. Publish Everywhere." on the Scirra homepage ( https://www.scirra.com/ )

    Looking at Construct 3, it's the same, they list "HTML5, Steam, iOS, Android" and thankfully took off the WiiU export ( https://www.construct.net/ ).

    Also, desktop export has been a nightmare, our game still doesn't work on Linux and Mac OSX because it's larger than 500MB. The "GPU drivers are bad so native is bad" argument also falls apart when the same hardware that gave CC issues is giving C2 issues anyway (net difference is zero) and the slew of other JavaScript/NW.js specific issues that our customers have on Steam has been awful (and our only defense after we have done every work-around and optimization we can is "Sorry, it's the engine!").

    Once again "Serious" developers are getting surprise gotcha's that you may not have encountered personally/yet, but they basically are show-stoppers. We spent the past year porting our prototype to C# in Unity and have made immense gains that would be seen as "impossible" to people who haven't yet encountered the dark side of C2 and started looking around at what other engines have been up to since CC died.

    I wouldn't call anyone "serious" who can't even invest in their own business, blaming everyone else for not providing a smörgosbord of everything that you "might need".

    A functioning export is a pretty fair request of a game engine you're paying for. I bought my C2 business license for the same price as Visual Studio 2010 Professional which came with a whole lot more content than Construct 2, but it's not designed specifically for making 2D games so of course I didn't expect it to do the things I expect C2 to do out of the box (and similarly I don't expect C2 to do programming specific things VS 2010 does).

    As for in-app advertising, if that's *the* way that devs are making money on mobile, then not supporting it means you can't really make a viable commercial game for mobile no?

    There's people trying to make games full-time with tools like Construct 2, they're "serious" and they are investing in their own business.

    It's not about "Well C2 works for my one specific game", or arguing about "how serious" someone is. They purchased a tool that suggested it was ready for real commercial development in its marketing, and it falls short of the mark. They're paying customers, we're all paying customers, and if the advertising is wrong it should be changed.

    Time is valuable, even "spare time", it has a monetary value, part of why we pay for Construct 2 is because it was supposed to save us time on the basic parts of an engine and let us focus on the core elements of games: Art, SFX, and logic

    Well if they were to try to take the console route, how would they go about it?

    Would they develop for all of them?

    If not all, who would decide which one to develop for?

    Where would the funds needed to hire someone with experience in each specific console come from? Im pretty sure they don't have someone already.

    Would their current income method pay for all that?

    Edit:

    Also, what do they do when the next version of this or that console comes out?

    Pray that the old codebase isn't abandoned?

    ....

    Sorry, but Im just being realistic.

    Those questions are rhetorical. I expect most people to already know what the likely answers are.

    A least Im pretty sure what they are, and that's why I look for alternatives to what the answer has been for the past 8 years.

    Nothings changed, with the exception that perhaps subscriptions might allow some of the issues of funding, and manpower to be overcome.

    You're right, those questions are probably rhetorical, as the only sensible answer (aka the answer to: "With such a small team, why is Scirra bothering with any runtimes at all when they seem to only care about the editor?") is that they should really just make Construct as a plugin for another game engine. One with hundreds of team members and a very open free edition, perhaps Unity or Unreal Engine 4?

    If Scirra went that route (and it might be even easier to do now that they can just make the Construct editor a browser tab within Unity) then they have a legitimate reason to off-load the complaints about runtime to the engine they used, as they only handle the editing. It'd be a win-win, and it means Scirra gets the jump on making a complete editing environment in the other engines before they eventually do it (Blueprints is probably just the first stage of visual coding in UE4, and PlayMaker is indeed very powerful but just doesn't work/feel quite the same as event sheets).

    But, all of this is written with me assuming that Scirra wants to compete with GameMaker:Studio, Unity, Clickteam (exports to console via Chowdren), and more.

    Because if they don't, then I and every other serious commercial game developer here (who are exporting for desktop + console + mobile) is in the wrong place, and I would be happy to accept that!

    Yet, when they advertise their tool as being for a "professional game developer" (Construct 2 features page), "fast as native" (Construct 2 blog post), and "publish everywhere" (as we can see they still say on Construct3.com ) that is not the message they are sending out to the world.

    It's hopeful future optimism at best and full-on misinformation at worst, and it leads to more developers like us arriving, investing our time and money (and if we run a Kickstarter, our fanbase's money) into a dead-end solution that later leads to cancelled ports and frustration all around.