We need a Nintendo Switch port of Construct>>>We are behind scheduled !!!

I'm curious, are you using Construct's existing support for Xbox One? If not, why not?

I think Indie games doesn't perform well on Xbox. I'm not sure, although I would like to know how a decent construct game would perform on Xbox nowadays.

As far as I know, Switch is the way to go for indie dev in matters of consoles.

Personally, I didn't really consider Xbox either. Or PS4 as a matter of fact. But my game is a puzzle game and the touchscreen of the Switch is a big plus.

Xbox One has "GamePass", which will be huge in the forthcoming future...

However, I also believe that Construct needs a second export option as an alternative to html5. For example, GDevelop is experimenting with Cocos2d-js for native builds. A smarter move for Construct would be to use cocos2d-x lite which is also what powers Cocos Creator (2d-js is getting EOL now). Cocos2d is the most mature engine in the mobile scene and exports to everything except consoles (even this may be doable with some additional tweaks).

I understand that the team has strong opinions on keeping the project on a clean bet (html5) in which it specializes. However, I (hope and) believe that Construct deserves to be bought for some millions by a big player and become popularized to the masses. The value of your product is not it's subscriptions or the user base - it's the technology concept that works wonderfully and has not yet been monetized by a big company.

It makes no sense for FSM-based visual scripting to be popular nowadays (Blueprint, Playmaker, Bolt etc), when eventsheets are so more readable and productive. But Fusion is almost abandoned and Construct/GDevelop are considered as toys due to the lack of a native exporter. I'm not saying that you should change your strategy. Just consider some auto-translation options that exist. Just my 2c...

C3 to Cocos

How would that work?

Cocos family has a lot of projects. One of them is Cocos2d-js in which you write javascript cocos calls and it's translated (binded) to c++ cocos calls via Cocos2d-x. For C3 to use this route, I guess it should map its core actions to the 2d-js actions.

However, my point is not to promote cocos, but rather to encourage the team to consider whatever technologies it takes for the end result to scale according to the needs of the crowd. Html5 is just one thing. Flutter is probably the next/better Flash. UX tools with code-autogeneration is another big thing. Mono/.net is the new gamedev lingua franca. Things evolve. Construct is not the best html5 game engine (Defold is), but it is the best event-sheet software around. For me, Construct is a shiny event-sheet that happens to lack native exporters. Eitherwise I would abandon Unity in no time for Construct! Do you know how many "professional Unity developers" actually work with shit-tools like Playmaker? It's ridiculous. Construct is miles ahead. And it is consumed for making ...mini games for kongragate, while the industry lives its most wealthy times in history with mobiles to be 1/3rd of the revenue generator and a tablet console to sell better than ps4. The paradise of the indies is not in ...kongragate! I wonder why such a wonderfull product is spared on a web-first strategy. Web what? Desktop web is dead. Web is on mobile (90%). Web IS mobile (and mobile is changing... it's not Android neither iOS anymore... it's becoming "Flutter", and it happens to have a powerful webview!).

Just connecting dots...

Chasing after the next new tech is pointless.

Games that do well, and are profitable bring users.

The things that drive users away isn't the platform, it's the ability to do what they want with the engine.

If that means having to code, then they will go to another engine. C3 has that now, but its not mature.

You have to think in terms of what 2d games need.

While the default objects and behaviors in construct offer an easy entree point, they are basically crunches, and rigid in their abilities. In case you were wondering, this is why there are so many on Kong.

Give us more objects and behaviors.

More ways to be creative.

Not more ways to populate an overrun platform.

I think that c3 is customizable enough. The reason of its existance is that it handles the project architecture for the developer and leaves just the logic to be built.

What the developer has to excell in is creativity. One of the best 2019 games, Baba is You, was built with Fusion! It could be easily built with c3. The tools are there...

Now, would baba develop his next project with c3? I doubt it. C3 is marketed and developed as web-first (and that leaves the other exports with inefficiencies). He would want to choose a tool that offers convenience but secures the target platforms first. Broader audience is now the goal. So he will probably end up to unity+playmaker/bolt even for games that are better deliverable with c3...

I'd add that while it's technically possible, for us as a small company I don't think we really have the resources to pull off official console ports. A very significant reason Construct has as many features as it does is because we truly have a single codebase that works on all platforms. There are also significant hurdles to writing native ports - this blog post on the prospect of native engines is quite old and a bit out of date now, but still covers some relevant points.

Even if we only aimed for a single console, it would probably take around 12 months, tie up basically all our development resources essentially putting everything else on hold; being web-first, many features would probably be infeasible to port (e.g. do consoles do iframes? SVG? form controls? video? networking?), making for a complex support matrix and increasing the difficulty of actually porting your games to console; and it would likely tie up significant resources even beyond completion, as console SDKs are a moving target with regular changes, and opening a whole new class of bugs where there are differences between the web and native engines. Meanwhile there are considerable risks: I'm still surprised at how few people appear to use or even talk about the Xbox One exporter, so it seems entirely possible we do all this work and hardly anyone uses it; maybe it takes so long that by the time we finish the next console generation is out and we have to start over; maybe they actually do add support for HTML5 games at some point making much of our work redundant; and due to all the risks and complexities involved it could end up being extremely expensive - if you think $99/year is expensive for Construct 3, note GameMaker charge $799 per year per console exporter, or $1500 per year for multiple console exporters - and they're a bigger company with more resources to put towards that.

Don't get me wrong, I'd love to have more console support for Construct. It would be huge and a dream for many people. However looking at all of the factors involved, it seems awfully close to an extremely risky bet-the-company gamble, and I don't think we can justify it. The de-facto setup of a couple of third-party porting companies who maintain their own engines based on compatible subsets of C3 is kind of awkward, but seems like the best compromise we have right now.

So, what is the reason of changing engines? The switch export or the engine itself?

I'd point out that as I mentioned, people can, and do, publish their Construct games to Switch and PS4 using third-party companies.

Who are those companies !?!?! and please don't mention Chowdren cause they are way busy and I ain't waiting for two years for a response. Why don't you try to get along with those companies instead and bring them to Construct in an official way.

I'd point out that as I mentioned, people can, and do, publish their Construct games to Switch and PS4 using third-party companies.