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.

  • I won't be releasing on XBox, no. I don't have any reason to think there's particularly a market for my quirky cartoon platformer on there, and it'd cost me a lot of money (MS say it's "free", but iirc they require you to have insurance and a bunch of other hidden costs). Don' t get me wrong, I'm prepared to invest in a platform where I think I have a chance at recouping my money. I just don't really see the XBox as a key target platform for my game.

    I appreciate the response, but that just sort of underlines what I thought: I'm going to have to use another engine going forward.

    I think Construct is a great beginners engine and a good way to get into game development. But I don't think it's quite there as an engine for big commercial projects. I think a lot of game developers will hit a point where Construct is starting to hold them back and they can't really grow with it as they'd like. I'd love to be proven wrong though.

    You say you can't invest too much energy into chasing a particular platform, and I do understand where you're coming from. But then, you did put all your eggs in the Html5/JS basket. What are you going to do if none of the future consoles support it, either? You guys need to think real hard about this. Is this a platform developers can do real work with, or not?

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

  • Same Thinking HERE !!!!!! You read my mind !!! it ain't worth it, I think for sure and you'll see that this engine of Construct has no future at all for us Indie Developers, with Html5/JS basket we won't see a future with our games, it is almost time lose Because we Cannot Export our game to the real Indi Platforms like Nintendo Switch ect, ect,,, We are gonna be stuck on this ilusion dream forever if we don't find an exit soon >>> Why don't you people from Construct creators get along with Chowdren and create and exporter dedicate for the Nintendo Switch with C++ !?!?! We need one asaaaap !!!!

    Construct2/3 enginers why don't you people get along with Chowdren to work together as a one team and create an exporter dedicate for Nintendo Switch with C++ using Construct !?!?!?!

    Don't you think its a Great Idea !!!! We need that if we really want to see Construct2/3 around some more in a couple of years to come.

    Everything its possible in this life.

    C'mon put a hand into all this to make Construct great again !!!

    I won't be releasing on XBox, no. I don't have any reason to think there's particularly a market for my quirky cartoon platformer on there, and it'd cost me a lot of money (MS say it's "free", but iirc they require you to have insurance and a bunch of other hidden costs). Don' t get me wrong, I'm prepared to invest in a platform where I think I have a chance at recouping my money. I just don't really see the XBox as a key target platform for my game.

    I appreciate the response, but that just sort of underlines what I thought: I'm going to have to use another engine going forward.

    I think Construct is a great beginners engine and a good way to get into game development. But I don't think it's quite there as an engine for big commercial projects. I think a lot of game developers will hit a point where Construct is starting to hold them back and they can't really grow with it as they'd like. I'd love to be proven wrong though.

    You say you can't invest too much energy into chasing a particular platform, and I do understand where you're coming from. But then, you did put all your eggs in the Html5/JS basket. What are you going to do if none of the future consoles support it, either? You guys need to think real hard about this. Is this a platform developers can do real work with, or not?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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.

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

    It's not as easy as "getting along" with the Chowdren Team or any company that's willing to port your projects to a native environment. Business is complicated and cooperating on such a level would require a great amount of legal and set up work. Native ports of games often, if not always require specific changes to be made to the build process, assuming an automatic builder/compiler is used at all. This alone would require tons of work since most games use 3rd party addons and similar.

    (As a side note. Good luck getting Chowdren or other 3rd parties on board with sharing their profits with Scirra. Why should they, if they can just independently provide the service and get 100% for it?)

    I know it's frustrating but that's just how things are. Piracy prevention aside, Nintendo probably saw that there weren't a lot of HTML5 games on the WII U and decided to drop support for it. Unless there are thousands of developers requesting it, I don't see this happening anytime soon.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)