What you want in C3?

If its possible - Native iOS and Android exporters? That would make Construct the ultimate game design tool regardless of what version ...

+1

"Native exporters" (? it's native, or it's exported, but exporting/building native from abstracted...) keeps coming back, yet we know it means multiple underlying engines, which is not practical.

That completely defeats the point of targeting a cross-platform technology like HTML5 and would be the end of Construct. There are other engines that do it ; so the real question is, should C3 try to compete with these at the risk of becoming a poor-quality clone, or continue to become THE solution for cross-platform HTML5 ? The later seems more unique and more interesting to me.

On the subject (remove white spaces, 'can't post URLs...) : https:// forum/what-you-want-in-c2-for-2015_p870156? #p870156

by Ashley

Refeuh

I think the issue is that most of the other engines also export to html5. On top of that, they also do native code for each platform. That is a HUGE advantage over construct.

What construct has going for it is the layout/level editor and event system. The html5 export is honestly nothing special or unique in my opinion.

We need easy advertiser integration with major ad providers and native exporters/compiler integration if construct 3 wants to compete in my honest opinion.

To be honest I'm probably done with construct when the next iteration of gamemaker and the likes come out. Unless of course the issues I addressed get implemented.

Tylermon

Fair point ! Though I think it's important to pick one target/platform and get it to work as best as possible in order to maximise the productivity of the game creators while remaining realistic with what Scirra developers can do.

Having to support multiple underlying native engines certainly wouldn't help with that, it's an order of magnitude higher in terms of workload just to maintain a small collection of platforms and it makes the abstraction of certain features much more complicated, if possible at all. Therefore in my opinion continuing to focus on HTML5 would be the smart thing to do, letting big companies with much more resources and man-power ensure HTML5 gets better and better over time.

As end-users of these engines and game creators, "we" don't really care about the practicality of the engine development, in the end, we just pick the best solution for our requirements that fits in our budget when the time comes. But I see in C2/3 a great tool to quickly author decent applications, using a reasonably cross-platform-ish technology ; if I'd want anything else personally I'd just go back to traditional programming because there already are development frameworks and tools that expose more. I also know it would take more time to create simple things. 'Just my point of view !

megatronx - agreed. What I want in C3 is for C2 to keep being improved and supported. What would anyone on these threads have to gain by C2 being abandoned and having to fork out more money for the next version? Think about it.

I would like to see more developers hired so that C2 does not die out with the release of C3.

Tekniko

You write tutorials. I have some problems with isometric projection. I wrote these problems here: (General/about isometric)

Can you please check it out and make tutorials?

One problem of pathfinding is that i can't reduce the time.

more templates and examples and finally few templates of highscores/ leaderboards

Hmm, another license fee? O well, I guess that means I better rush My games to market so I can make sure to have enough cash

About the original Topic...

Although by the time C3 comes out, I'll have finished mine... but would be nice for new users to have some things like...

Inventory (RPG and otherwise)

announcements board (to import from a feed somewhere on the internet if app has connection... would be nice for new users)

on the other side of things...

the more we can do with C3 the better... with things that pros could use like...

Videos that are easier to import

More things to make Apps... vs all on games... (not saying much, but I'm already making apps with this as well as games...)

~Ant

I'd like to see a way to prevent characters from overlapping when using pathfinding in isometric games. The recent update with regenerating a small portion of the map was nice. I'd like to see more like this.

I think a unity2D plugin would be the best option. It would make exporting much less of a hassle.

I was/am proud to have contributed financially to the development of C2. Even though I feel the direction from C1 to C2 wasn't what I personally was hoping for, the overall product is a success and speaks volumes of Scirra.

*HOWEVER*

To be able to justify spending again on a new license for a new product I would have to see some things done differently. These are OPINIONS, and are not designated as ATTACKS on Ashley, Scirra, C2, or anyone else. These are my personal thoughts and these things impact my decision on moving forward with C3.

1) Built in language support of some kind. The Event system is a slow and tedious experience as the game gets more and more complex.

2) Exporting options really need to be addressed. This is the number one turn off for many that otherwise found C2 appealing. While the website boasts a wide range of export options -- really there only needs to be the main exporting options: Desktop(win max linux), HTML5, android, and iOS. Other technologies can be addressed later.. and honestly even linux or mac is not a huge thing (even though I would much prefer having a linux export) as long as these export options are reliable.

3) More expandable. Not sure how to summarize this one. Community development of addons and plugins but to a much greater extent. Being able to add true 3D support via a community developed addon sounds wonderful. Or a community created sprite editor? Community supported language addons/wrappers for C3? A Modular C3 would be amazing and lessen the burden on the small team -- while giving the community an opportunity to expand and customize C3 as needed.

I want to continue supporting Scirra, but if the product remains the same and is unable to really grow up in to a full pledged game creation studio, there are just far better options. Nothing personal -- I truly adore the Scirra guys, but money can be tight and there are a lot of options out there, including free.

Whilst it goes against the drag and drop USP, being able to type out an event, with auto-complete, would be amazing.

No C3 yet. Fix C2 first.

No more features this year - just work on fixing bugs.

For example Audio needs some attention. Music in particular. Some times looping music will just stop playing, but this cannot be reliably produced in order to file a bug report.

The shadow feature needs work, and I'm sure others can list problems that they have encountered specifically that could do with some TLC.

And then we have the many reported exporting issues.

Ashley should make a game - that way he can experience some of the issues that only surface in complex projects, and can't be reproduced in simple capx files. And it will also provided some valuable insight for C2 developers into how this engine can best be utilised to get the best results.

C2 is a great product with more than enough features to create great games. Why not stop adding features - and fix where broken and improve where needed - and make what is already there solid.

Twinsonian

The lack of growth ability is why I have been overly nudging Scirra staff and other devs that C3 should be on the horizon. As it is C2 really can't meet or offer enough access for better development tools. Everytime I need a plugin because of C2 ES limits I bang my head against the wall. So I agree strongly with this sentiment

"I want to continue supporting Scirra, but if the product remains the same and is unable to really grow up in to a full pledged game creation studio, there are just far better options. Nothing personal -- I truly adore the Scirra guys, but money can be tight and there are a lot of options out there, including free."

And as for easier programming access. I already did this. I wrote a simple behavior that would load js file into the HTML dom and execute it. Works great. However it's pretty early and I suspect I won't ever flesh it out enough.