Concerns from a "Serious" developer

Performance wise I can't complain at all. Just recently I started to redo all my in game graphics using the Q3D plugin. As a benchmark, to see what I could expect from 3d performance on a old midrange phone I downloaded a couple of "Made with Unity" games in 3d.. They seemed to perform fairly well. I didn't have any fps counter. It was playable but definitely not any 60fps. It felt like around 25-30 fps.

I built a quick map with mockups, characters with animations and effects some simple game at a similar complexity (geometry, animations, shaders, lights etc. of what I was seeing in the games I tested. I was quite surprised that I was getting around same performance. Around 30fps-50fps even with real time shadows on for characters and moving objects.(which some of the game i tested did not have, without realtime shadows i was getting 40-55fps) Environment shadows was baked, which is pretty common practice. The only thing my test was missing was some proper game mechanics, but there was room for optimization to many of my poly models texture sizes etc.

I did this test to verify weather I should continue down the Real time 3d path with my game or stick with isometric. My conclusion was that for a slightly lower fps than isometric i got a real time 3d game, and not having to worry that much about memory budget, advanced calculations for angles arrow arches and ricochets in isometric etc. and rendering hundreds upon hundreds of character animation frames in various directions.

I didn't try building it though but from previous tests I've always been getting about the same fps after building compared to the normal phone browser.

I can't complain at all, If I can build a 3d game at similar complexity to a Unity game with pretty similar performance. I'd choose C2 any day of the week. Unity still don't have the event sheet. I will share tutorial/capx on that later and good practices for mobile 3d games.

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.

(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...)

LOL. I have my concerns about C2 and C3 but this is definitely one of the things I've always appreciated personally so I hope you don't, tho I see why you might want to.

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

Which threads were unjustly locked that you are referring to?

lamar - you have previously ignored my replies and repeated the same question, and you're doing it again, so I don't feel like it would be constructive to reply.

Ashley, you and I and everyone that has been following this thread knows you did not respond to my question and you asked what we wanted and claimed you were listening. You brushed it off and went on to tell us all the wonderful things you plan for C3.

So I even started a new thread with that question and instead of answering you had Tom lock it.

Here is the question again Ashley and I think we all deserve the respect of a direct answer:

Ashley can I get a direct response from you please?

> Okay, wow, now a 17 page thread.

>

> I'm not sure what anyone here thinks we should actually do. We've already announced things like our own mobile app build service and new IAP/ad plugins for C3, so that is on the way. We've got Xbox One support just around the corner. Mobile support from what I've seen is pretty solid with WKWebView and Android 5.0+, all supporting JIT-compiled JS and hardware-accelerated WebGL. Maybe we could tweak the way we advertise certain things. Maybe some people have bugs, or unoptimised cases, in which case please file reports, or send me .capxs to profile for performance improvements (as ever, I always ask, and either get sent nothing, or just projects with silly performance-destroying mistakes, hence my skepticism).

>

> Do you want us to rebuild the C3 editor? I would go so far as to say that would probably ruin us, and waste a brilliant opportunity. 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.

>

> So what have I missed? What do you think we should actually do differently that isn't something we've already covered? If I can't make sense of any specific complaints or clear suggestions on what to do, then I don't see why we shouldn't just carry on as we are - I think we already have a strong plan for the future.

>

Ashley after reading the many many comments on this and my thread I believe what people are asking for is this:

1- Go ahead with C3 as it may at least be useful to people using Mac and Unix even though most C2 users have said they do not want a Chrome browser based subscription engine.

2- Make an update or addon package of exporters and features for C2 that users have been asking for and fix the bugs you have been promising to fix for years. Put that new team of programmers to work on that along with C3.

We all understand Scirra has to make money and I believe you understand that if you lose your long time C2 users by not listening to us your chances of staying in business are pretty damn small.

So this is a reasonable request and you can charge your $99 for a great package of features and exporters for C2 and I will bet you will sell many more of those packages than you will C3 browser versions.

It also would prove you actually intend to honor your license and advertising that said those exporters would be included in C2 and would probably keep your base happy and maybe they would be interested in C3 later after you get all the bugs worked out.

It seems to me you would want those long time C2 users to hang around and support Scirra but reading through the comments on many threads they are dropping out and pretty disappointed in Scirra right now.

So what do you say?

Can we get a package of features and working exporters for the existing C2 engine at a reasonable price with no subscription Ashley?

If I get banned for asking you a straight forward question then so be it and I will let the forum decide what to think about that!

Ashley Tom

Reading through the blog posts provided and just going through the most recent ones as a whole actually gave me more faith. I do see that a lot of concerns are being worked on and mostly at this point it's just seeing how things work in c3.

And if I'm not mistaken, being able to export in c2 and upload using the service should alleviate issues that I have. Especially the ad services

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.

> 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.

How would you like us to deal with bug reports that don't meet the minimum requirements to investigate? Do you have a link to some of them that concern you?

I like the reply (/replies) from Ashley.

From here on I think it is better that if there are any other concerns, to do as Ashley is suggesting and make a seperate topic and stop replying in this one developer's (interesting to read) opinion-thread.

While Tom and Ashley is active. A quick question you might have missed in this fast feed. If we are subscribing to C3, is there any technical limitation stopping us from using the C3 build service for games exported in C2? This would be great as a transition since it will take some time for plugin makers to port plugins we are depending on.

Ashley

I'm happy to manage spritesheet images myself and all of the memory issues that may arise from it if it means no seams, which I emailed you about a couple months ago, and I ended up implementing image loading myself separate from C2's spritesheeting with no issues and lower memory requirements than I had before, though I think what you're suggesting with image limits on desktop PCs is not, generally, an issue in most desktop games. The best solution (from a dev perspective) is to allow users to create their own spritesheets, even if they have some position/rotation/scale/limitations to work properly with Construct. Put simply, other software does spritesheets better, and it'd be nice to be able to update a single spritesheet that can keep collision shapes instead of having to re-import a spritesheet, have C2 split it up, and then have to redefine proper collision for each sprite. Even though C2 supposedly creates "optimized" spritesheets, I haven't found that to be the case and to shrink file size, I tend to find myself running all exported PNGs through PNGGaunlet which can reduce the size even further, with some images compressing another 90%. Yes, I know this doesn't affect memory usage, but it is a missing optimization for size on disk and it can be a bit of a pain to have to do it after every export because C2 may create differently-organized spritesheets if any images have changed due to re-import or additional spritesheet images being generated if more content is added.

As for working exports: we're not really presented with much info on export, and I've had issues where one export works and another done minutes later (for testing) fails on startup (red loading bar, for example) doesn't work, even though I may not have made a single change in either C2 or to whatever nw.js version I'm exporting to. Believe me, if I could figure out a way to more clearly report that issue, I would do so in a second.

Also, while it's good you won't defend a 4yr-old blog post that isn't accurate, it'd be even better if you walked back claims that WebGL performance is equal to that of OpenGL/DirectX, because at just the base level of that claim, the idea that a graphics functionality wrapper on top of another graphics wrapper is as fast as a single graphics wrapper is...well, it's just silly.

[quote:1ei4kesf]A page with Scirra tested benchmarks for each platform(PC/Mac/Linux with PC specs, Android/iOS with model, wrapper vs browser) with a Construct 2/3 version of the exported test file would work wonders in giving people an idea of how relative their current devices are to the test devices.

We already ship some in Construct 3, in the tech demos section.

I meant more of a page outside of the program that lists the benchmarks done on Scirra owned testing platforms along with the platform technical details to set expectation levels.

I've been playing around with it little myself and I like your recent blogpost where you can link to them directly.

Zebbi

Pretty much constant 60fps vs about 45fps. I benchmarked my old system and new system with this:

http://www.passmark.com/products/pt.htm

and found that:

95% of systems are faster than my old system and

75% are faster than my new one.

Jayjay

Windows version is only relevant for the nwjs export since they're dropping support for xp and vista as I recall. Also I'm fairly certain only one core is utilized by Construct's runtime, with maybe the exception of webworkers used for pathfinding and perhaps some other things.

Sorry I think I'm off topic from the rest of the topic.

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.

After asking for a roadmap past C3 (and not really getting an answer), I downloaded Unity and bought Playmaker. While it is different, it isn't as hard as you think and there are tons of tutorials.

In the end you have to use the tools that will get the job done. If you don't want an HTML5 workflow, choose another tool. Waiting for your favorite tool to finally do what you want (via feature requests) may take years. In that time, you can learn a tool that you know will do what you want AND deliver your product on the platforms you need.

I was a heavy discreet combustion user who was very reluctant to learn anything else. Now I use AE and I'm glad I do.

I'll keep using C2 for simple 2D HTML5 games, and probably Unity for everything else.

How would you like us to deal with bug reports that don't meet the minimum requirements to investigate? Do you have a link to some of them that concern you?

Ideally I'd like for Scirra to try recreating the described situation, work with the paying customers to reproduce what it is they assume they are trying to do, and spread knowledge about how to do that properly, rather than closing as won't fix.

For example, here's some in the past 6 months:

Graphical issues NW.js: Closed for using a third-party addon and not being "minimal" (how do you do that when you have a full sized game and might not know if it's merely a size-of-the-game issue?)

Platform jump height variation: Closed as won't fix (so no pixel perfect games allowed eh? too bad Retro is the most common 2D game people like to make)

Issue with platform behavior: Closed as won't fix (A jump command should be received that tells the platformer to only check for being on ground once the velocity Y is below 0 again)

Pin behavior position lag: Closed as can't fix (why not give the user some means of control over the order in which behaviors will be executed?)

Choppy/Jerky Frame Skips: Closed as another Google issue / "can't fix" (Great, says every customer expecting decent mobile export)

Also R0J0hound I think it's safe to say that those passmark results are comparing against other users who are into "passmarking"/benchmarking. The Steam HW survey is even slightly biased as it is probably has more gamers who play 3D games than 2D.

For a strictly-2D sense, the average hardware we're seeing does dip down into Windows XP and Vista users, and they do still get very vocal when our game doesn't work (and we told them in requirements that it wouldn't, not even marketing to them as possible or "functional" on their OS !).