Construct 3 any news?

For a bit of perspective, Unity has 1000+ employees.

https://en.wikipedia.org/wiki/Unity_Technologies

For a bit of perspective, Unity has 1000+ employees.

https://en.wikipedia.org/wiki/Unity_Technologies

I just used that comparison to make it easier to understand the message I was trying to deliver with that post.

glerikud got it and pretty much summed it up for everybody.

Also, there could be a lot of area for improvement in ways of organizing your eventsheets/events to be more readable, like color-coding groups. Also tracking where undo/redos are made would be useful. A way to see where functions are being called- basically ways to help see the flow better so you can jump between eventsheets and not get lost.

Also, families could be improved- It is often annoying if you have a variable in one family and need it in another, and have to rename the first one and then add it in the other, then go into the eventsheet and change which events use the old variable to the new one.

Sprite animation system could be improved- spritesheets for example, tiled sprites, etc.

Also, would like to see more support for in-game menu systems, as that is a very important aspect of games that engines overlook.

These are excellent suggestions, co-signed!

no, they take the information they got and report it there for you. This is the behaviour I'd like to see from Scirra

I routinely do this already, sometimes several times a week. However users can get their bugs reported quicker if they cut me out of the process and report it directly, especially if they have a good report (in the best case you can more-or-less cut and paste the report to a different project). That's why I suggest that - if you want issues fixed quickly, going direct is the fastest way. If users don't want to do that, I can and regularly do report issues on their behalf.

That's why I suggest that - if you want issues fixed quickly, going direct is the fastest way.

I understand your point, but there are the cases where those companies wouldn't take our reports as serious as yours.

> That's why I suggest that - if you want issues fixed quickly, going direct is the fastest way.

>

I understand your point, but there are the cases where those companies wouldn't take our reports as serious as yours.

Good developers respect a good bug report regardless of where it comes from. The important thing is the report is clear and identifies a real problem.

>

> > That's why I suggest that - if you want issues fixed quickly, going direct is the fastest way.

> >

> I understand your point, but there are the cases where those companies wouldn't take our reports as serious as yours.

>

Good developers respect a good bug report regardless of where it comes from. The important thing is the report is clear and identifies a real problem.

That's true. But not every company consists of good developers. Also not everyone has the resources to respond to every bug report users file. But if a report came from another company (representing more users at once) it could weight more.

Html5 wrapped export will never run as efficiently as a 'native' export, in the same way that a windows / virtual machine OSX will never run as quickly or smoothly on an i5 laptop as an installed version would. Anyone who believes otherwise is simply mistaken. This is why none (I say again - none) of the major game development software suites offer just one export option that you have to wrap using third party / uncontrolled software. There be dragons if you develop that way, and it could pose a risk to the stability of your development pipeline.

I understand scirra's reasoning for choosing html5 and I respect that choice, but the consequences are clear if you wish to develop a game for something other than google chrome. If those consequences do not bother you then clearly there is no problem. If they do then you have to either accept them and work around them, or simply move on. I think c2 is excellent for developing browser based games, but the list of wrapper-induced bugs is forever being populated by new and unexpected problems - so wrapped export will always be challenging.

Perhaps webassembly will be the way to go (like Unity's html5 export webassembly demo) as long as your target wrapper and target hardware can run it, of course.

>

> > That's why I suggest that - if you want issues fixed quickly, going direct is the fastest way.

> >

> I understand your point, but there are the cases where those companies wouldn't take our reports as serious as yours.

>

Good developers respect a good bug report regardless of where it comes from. The important thing is the report is clear and identifies a real problem.

Ashley with all respect I understand what you are trying to explain to us but this case against native engines, is not just about minor bugs and performance issues.

I like to go with examples, so I'd like to get back to this quite old report also known as the "30fps cap", some people will surely remember it. *

A fair amount of users have participated in it and have actively tried to convince the chromium team to add this feature but this is already more than 12 months old!

Do you personally see any progress being made, any real attempt of getting this implemented from their side?

It's things like these, things that are standard in native engines were the web is still lacking and I don't see a solution in waiting 1+ years until something has been done about it.

I know that going native will effectively make it impossible for 5-10% of the user base to execute and play our games but that is a risk I'm willing to take. And if you take into account that NWjs doesn't have WinXP support and Native does, things should be even again.

I'm not saying all of this because I hate you or your product, it's just so frustrating sometimes to wait months over months to get a fix or feature that natives already have for ages. I guess this is how things go with the web, I can't tell you more than the other C2 users around here already did.

It just feels like you actively try to avoid things like these and try to compensate the damage that these things already have done or still do to some serious devs around here. It's your business and you handle your business but seeing the latest progress of the competitors make C2 and possibly C3, look really old and something you don't want to work with. It might not be nice to read that but it is what it is and I cannot always keep on supporting something that is causing high amounts of frustration to it's user base.

* FPS cap reports: #1 and #2

I hope I could deliver the message well, if there is something that doesn't make sense or if someone would like to add something go ahead below.

"Windows, Mac and Linux Support

Construct 3 will run beautifully on whatever operating system you want to use."

This is what they promised.

So... native exporter has been denied... I wonder how this is possible.

I took a look at the construct3 website, and then I noticed something, the pictures match the coloring format that Microsoft uses for Visual Studio 2013 and above: BLUE - PURPLE - WHITE :

So my guess would be that Construct 3 will be based on Typescript, and here are the reasons why:

• Typescript was developed by Microsoft, which means that their Visual Studio IDE is meant to developp Typescript apps, and since Typescript is an Object Oriented language, we can include header files and such things like SDK's for autocompletion features. Scirra promised an SDK for plugin developpement, which means that we will be able to make plugins using Visual Studio with auto-completion features (Clue #1)
• Typescript is a superset of Javascript, this means that any Javascript code is a Typescript code but not the other way around, this proves the fact that C3 will be backward compatible with C2 (Clue #2).

Html5 wrapped export will never run as efficiently as a 'native' export, in the same way that a windows / virtual machine OSX will never run as quickly or smoothly on an i5 laptop as an installed version would.

You could probably say the same about hand-writing assembly vs. compiling code. Beyond a certain point, the difference doesn't matter any more.

I like to go with examples, so I'd like to get back to this quite old report also known as the "30fps cap"

No platform has all features. If we went with native engines, you'd probably lose support for browser-provided features like WebRTC, probably anything based on Web Workers (since they make multithreading so much easier to use), some service-backed features like speech recognition, probably user media features since they require a lot of cross-platform media support, you'd open the graphics driver bugs can of worms (browsers do a lot to sanitise WebGL), and so on.

Judging by the fact the 30 FPS cap feature only has ~30 stars despite the fact I always link to it, I think it's fair to say it's a niche feature. Everyone will always have their favourite feature they want which is difficult to do, regardless of the platform. For example users of native engines still want things like networking, including things like loading web-hosted images, which browsers do really well.

I'm sure someone will now say "but you could use libraries/frameworks to help", without realising the paradox that creates given others criticise us for depending on third-party code!

Judging by the fact the 30 FPS cap feature only has ~30 stars despite the fact I always link to it, I think it's fair to say it's a niche feature. Everyone will always have their favourite feature they want which is difficult to do, regardless of the platform. For example users of native engines still want things like networking, including things like loading web-hosted images, which browsers do really well.

We didn't really spread the word about it, I bet that a lot of the people that read my post about it saw it for the first time.

Regardless it was just one out of many examples were the web is lacking features.

I'm sure someone will now say "but you could use libraries/frameworks to help", without realising the paradox that creates given others criticise us for depending on third-party code!

You cannot fully not rely on 3rd parties, I think we all hopefully got that by now but you've got to admit tough that despite the features that we won't get using a native base, we'd still have more options if we'd roll with native engines. More options also mean more workarounds or even better methods compared to those than the web currently offers.

Either way I get it, you want to keep on with the web and I can just hope that one day, I will be able to release my project without the fear that something could be messed up thanks to Google's latest chromium engine or NWjs.

You could probably say the same about hand-writing assembly vs. compiling code. Beyond a certain point, the difference doesn't matter any more.

No. Otherwise Unity and UE4 devs would think native export is overrated then....?

we'd still have more options if we'd roll with native engines.

No, I think in many ways it would be likely fewer. For every feature you'd have to find libraries that are compatible and work across all platforms (from iOS to Xbox One). For example, can you find a native WebSocket library that runs over all those platforms? Even if you can, should we depend on the possibly buggy third-party code and face the same criticism when something doesn't work? Or do you expect us to do the laborious work of writing cross-platform libraries which we maintain ourselves, when we get this for free with a browser? The key point is as a small company, we don't have the resources to maintain all those libraries ourselves - and I believe we got to where we are today specifically because we didn't get dragged down in to all that extra work. I'd point out there are several similar-sized, or even larger and better-funded, competitors who appeared over the years and maintained multiple codebases, who are more or less irrelevant now because they couldn't keep up. That could've been us.

No. Otherwise Unity and UE4 devs would think native export is overrated then....?

Well, I could change the comparison: most Unity devs write in C#, a garbage collected managed language. C++ may well be faster, closer to the metal, and smoother since there is no GC. Generally though, the difference doesn't matter, the higher-level managed language is good enough and the increased productivity is more important.