Arima:

You just described why the state of MMF shouldn't be used for comparison. Ashley has proven to consistently be a better developer with better design ideas. MMF has been stuck on legacy code and structure for ages and C2 was built properly without those problems. They're just too different to compare.

nd clickteam has many developers, and had many others in the past. Like it or not, they were pioneers. Sure, they could've ditched old structures long ago, but saying Ashley has better design ideas is telling only part of the story. Construct is the superior product, sure, but it wouldn't exist if it weren't for clickteam.

In addition, you're suggesting we forego the only baseline we have available to compare! Yes there are products that have successfully implemented the exporter strategy - unity comes to mind - but why are those better as comparison models?

Someone's not 'sucking money from Scirra' if they are contributing to C2 and implementing features people want, even if you personally don't want them.

wasn't very clear, sorry. I meant that a new employee is using resources regardless of what they're working on. I would rather have a new hire working on features that benefit everyone.

I don't think the editor is perfect, and I haven't gotten the impression that others arguing for native do either. I've stated repeatedly that if native exporters were to happen without hiring someone else, then they should be made later after the rest of the todo list is done.

he todo list will never be "done". What I wanted to say is that it seems like people want the exporters now, which in my mind implies - mobile issues asside - that they'd be happy if the software stayed the way it is now for a few more years

That... Doesn't make any sense. It sounds like you're calling iOS overpriced hype because we're reliant on apple, a third party, to develop iOS? We're even more reliant on microsoft for their development of windows. Not to mention...

don't like apple - maybe our cultural differences are making this feeling hard to understand - in my country, an iPhone 5s costs the equivalent to $4500 (adjusted for GDP per capita) so maybe now you can understand why I think it's overpriced hype (in the US it costs $800). I think they provide one of the worse environments for developers. Microsoft sucks as well. HTML5 at least is stable, in that there's less of a risk it will be discontinued, like both Apple and Microsoft have done time and again.

You're arguing FOR one of the main reasons to make native exporters - exporting HTML 5 only causes scirra to be much MORE reliant on third parties, and more third parties, rather than less!

disagree. With HTML5 you're reliant on a single technology stack. The responsibility for complying with the standards lie with the vendors. And that's not even counting the ease of use of the APIs, the many frameworks/OSS solutions and the community - an esoteric bug with HTML5 is more likely to have a solution or workaround than an esoteric bug with Android/iOS/WP8/etc.

I'm not saying making native exporters would be problem free, of course it wouldn't. However, as said, the jit compilers on iOS being inaccessible is one of the points that native would solve since we wouldn't have to use them at all..

nd I think it would only compound the problems. Just go to any forum for a product that offers exporters: the vast majority of posts are either complaints about lack of functionality or complaints about bugs.

That's still relying on third parties to fix them. Besides, how do you know that they'll be fixed? Because they're large companies?

The chances of something being fixed are better if you're not the only one experiencing the issue. I doubt XNA would've been abandoned if it were the primary mean of developing for the XBOX.

As you stated, apple doesn't let anyone compile JavaScript except for themselves. They've had this stance for years. What makes you think they'll change that stance? I'm very grateful to intel for making node webkit and crosswalk, as well as them making it free, but what if they change their minds? What if ludei changes course and decides to become a publisher or makes some other decision that ends their service for getting HTML 5 games on iOS? What if they desire to use an exorbitant pricing structure that most of us can't afford? What if they never manage to get their platform working properly for everyone? Guess what happens - our only option is to switch over to another third party - if there even is one - and hope they do better.

ecause if you're using a widely adopted tech, there's always someone you can run to if your current vendor doesn't work (see phonegap). If Apple wasn't considered a status symbol, I bet they would've gone the way of the blackberry.

By making native, we rely on third parties far, far less than sticking with HTML 5, where every single device C2 exports to is more dependent on third parties than if it was native.

aybe, but you'll also have less leverage if you need something changed or fixed.

It's pretty obvious which platforms are the successful ones by now. Native could be made for the major players, and HTML 5 would still exist for the rest. A native exporter would not have to be made until a platform had proven itself.

s time goes on, it becomes harder and harder to make money on app stores. If you catch the early boom, money comes much more easily, which means you'd have to figure out whose phone/os is going to be the next big thing. You also have to factor in the time it takes for you to create a working exporter, as well as a feature-complete exporter. Also the time it takes for a developer to create their game on said exporter. And that's not even counting the fact that versions change and SDKs break. By the time you're finished, what guarantee do you have that the platform will still be financially viable? It's a risk you have to take. It's a risk clickteam took, and they've been bitten in the ass for it many many times.

... and besides, what would be the point then if you had to bring it back from the web to desktop to export?...

'm not talking about turning C2 into a web app. I'm talking about rebuilding the IDE in javascript while retaining it's status as a desktop software, downloads and all. See the brackets editor for an example.

Juryiel:

If he doesn't have the team size to support those things maybe it would behoove Scirra to stop implying those things are supported. C2 and mobile is not ready, and the fact that there isn't a huge 'Beta' or even 'Alpha' tag when they advertise that means that Scirra is misleading us.

I wouldn't use the word misleading, as that implies malice, but yes, I agree. Maybe Scirra should clarify that exporting to mobile is quite finicky, especially on anything older than a top-of-the-line smartphone.

You're thinking about this only from Scirra's perspective and your own perspective, but not from the perspective of small design teams with small budgets

...

nor do you get special preference because C2 originally started with desktop support.

hoah, it's not like that! If I really cared only about myself, I would be pressuring Scirra to add more application-making features, since that's my primary source of income.

What I'm advocating are features that help EVERYONE, not just mobile users:

• Better/more integrated tilemap object
• more/better modularity features such as widgets and nested objects
• ability to run construct apps without draw calls - for server-side programming in multiplayer, so you won't have to code your server in a different language - this would make small MMOs possible within construct, for instance.
• better ajax support
• collaborative design capabilities (two people working simultaneously on the same game)
• an IDE SDK
• converting the editor to open web tech and opening it's source code (for the IDE only, again I'm not talking about the game engine or the exporter)
• who knows, maybe even an exporter SDK, so people like

  tomsstudio can try making their own native exporters

—:

If you believe that 17.5% of the market is Russian, then maybe you should learn to speak the language.

ou want to convince me that localizing games to Russian is a good idea? I'm convinced. Hey, maybe learning Russian isn't so bad either.

As a user with a 5 button mouse, I agree.

Because "unlimited bandwidth" is a lie. All contracts have something like "reasonable limits apply" in the small print. If you use an "unlimited bandwidth" host, as soon as your game becomes popular, you'll receive a message from your host telling you to "migrate" to a (vastly) more expensive package.

You'll refuse to migrate, and they'll shut down your game, just when it was getting popular.

Bandwidth is very expensive, there's no way a host would just give tons of it away for a few bucks.

Much better to go with a limited bandwidth host - at least you know the limits clearly!

rainmaker, I once programmed a solution like this, using text objects as well!

What you do is, instead of creating 10000000 text objects for a big table, create only as many as the user can see at once, then add a scrollbar to the side.

When the user scrolls, instead of scrolling the layout as you would do normally, just make the source text for each line advance by one.

Say your source data is a list of fruits:

[1] - Banana

[2] - Apple

[3] - Orange

[4] - Watermelon

[5] - Pineapple

[6] - Grape

[7] - Blueberry

And the user can see 3 lines at most

Line 1 -> fruits[1]

Line 2 -> fruits[2]

Line 3 -> fruits[3]

Now say the user scrolls 1 item down. Instead of seeing "Line 4", the lines themselves don't change, just the references:

Line 1 -> fruits[2]

Line 2 -> fruits[3]

Line 3 -> fruits[4]

This way, the objects remain fixed, nothing new is created, just their text is changed! The only downside is the scrolling appears less smooth, since you can't scroll down, say, "10 pixels. You must scroll in whole lines.

It's probably not going to work on mobile for a long time. However, you should consider that mobile networks are VERY unreliable, almost useless for real time gaming, so you should probably use websockets instead!

If you decide to use your own signalling server, don't use hosts with "unlimited bandwidth", or you're gonna have a bad time.

Does this even work with node-webkit? I'm interested to see if it would work with it, since it's a natural candidate for a host in a client-host architecture.

- I understand that youve got a lot experience. im shocking that these thoughts are from an experienced developer like you.Because experience means years and you are not a child to speak this way. What it means we pressure for mobile and you with your rights will pressure Ashley to NOT focus on mobile. Ashley is not a dog or a cat...He has his plan for what he will do. And for the moment he gave us many alternatives desktop,mobile,consoles and we are talking about our problems/our worries to find out where things will go.

In the end you bought c2 for a specific thing, others (like me) also bought it for html but mainly for mobiles. All have opinion there is no need to push someone.

Well everyone has opinions, sure. I'm not saying mobile users deserve nothing. You and I want different things, and it's ok.

I can understand if Ashley spends time creating a facebook/twitter plugin or looks for solutions to mobile-exclusive issues, even if I never use any of that. I understand. But it has to be done within reason.

If everyone starts chanting "mobile mobile mobile" and no one disagrees, Scirra might get the impression that everyone wants mobile stuff, and that is not the case, so I speak - this is what I mean by "pressuring" Ashley.

I want scirra to see that people like me, people who don't care about mobile, exist. And people like me would prefer if the desktop got a bit more attention.

Heck, the decision to support an open source solution like ejecta might even be a good choice! I can stand a few months of Ashley working on that, even though it won't benefit me. But spending the next few years working on native exporters? No way.

I was one of the backers for the original pack, and I can vouch for this guy. Most of the assets he produced were great, and I have no doubts the new content will be good as well. I'd definitely jump in before the $89 tier runs out.

Except, XP is on almost 30% of all computers which use the internet daily. 30% is a massive factor, regardless of how old the system is. And I suspect it'll continue to be a massive factor until either Microsoft replaces its village idiot, or Chromebooks is upgraded to become truly PC (instead of PC lite).

0% is the same share IE6 had of the browser's market until march 2008. Steam stats say XP usage is around 10%, and steam's demographic is the same as the one you're probably aiming for. XP usage stats are also massively inflated due to china, so unless you're targeting chinese casual gamers during their working hours (if so, that's dumb), XP is as good as gone.

Coincidentally, construct 2 was launched officially in june 2011, and back then IE6+IE7 had a combined 9.5% share.

And as far as your 'opinion' carrying 'weight', if you've so keen to belittle such as large demographic, then no, your opinion doesn't carry any weight when it comes to commerciality.

ince when am I belittling anyone? I'm dissenting - two totally different things. Unlike some of the people in the forum, I couldn't care less about mobile. I get that people make money with mobile games, and I get that mobile is what's "hot" right now, so I don't mind, however:

If you guys want to pressure Ashley to focus on mobile exporters, then I am within my rights as a buyer to pressure Ashley to NOT focus on mobile and keep his current strategy of a pure-HTML5 product. When this product started (and when I purchased my license) it was all about the desktop, so when business decisions start impacting the quality for me (and make no mistake, if Ashley were to focus on native exporters, the desktop side would suffer), I have to speak.

Because Internet explorer 6 doesn't have the features necessary to run HTML5 games. XP does, and until recently, chrome supported hardware acceleration on it by default. That's more users that can purchase your game. It's that simple. Besides, Ashley already said he's going to make node webkit have hardware acceleration all the time.

agree, this discussion on XP is basically a moot point due to node webkit. Still, I would expect HTML5 developers, by definition on the bleeding edge of tech, to not care about outdated/unsupported platforms.

Again, I disagree. The state of MMF should not be used to assume what the state of C2 would be if they made native exporters. C2 already is vastly better than MMF, is updated way, way faster, works better and has most features that games need, and scirra working on native exporters would not send C2 back to MMF levels of problems, nor would it entirely stop progress on the IDE if they hired someone to work on them concurrently.

Why shouldn't the state of MMF be used as a baseline for comparison? You're well aware Ashley, or as he was known back then, Tigerworks, made construct due to dissatisfaction with clickteam's solutions. This is in part due to Ashley being a better developer, but the vast majority of it is due to learning from clickteam's mistakes! Let's explore some of those:

• Hardware acceleration support from the get go. While the infrastructure (read:webGL) wasn't there yet, the scaffolding was present long before.
• Open formats and technologies.
• Event sheet organization is a priority - even official plugins should adhere to standards and not be deeply dependant on engine internals (this is an area where I think c2 has been failing a bit, recently, with the new crop of official plugins requiring architectural changes).
• Open discussion of competitors in the forums.
• Short release cycle.

And now, most recently, we can say add "not wasting time developing native exporters" to that list. It's obvious that native exporters would not send C2 back to MMF levels of problems, but it would definitely slow things down. Ashley said it himself: the work involved in maintaining separate codebases grows exponentially!

Hiring someone new doesn't change anything: that is one person that is sucking money from Scirra. That same person could be developing something else instead. It's as if you all think the editor is perfect already when it's far from it! We need more modularity, we need a way to code server-side in construct (especially now with multiplayer), the tilemap needs way more features (where's isometric support? why can't tiles have attributes? why do we need a separate tilemap for a collision layer? how do we make multi-tile entities without resorting to third party tilemap plugins?), we still don't have full layout-by-layout loading, the list goes on and on...

You can't just call a platform with over 700 million devices sold overpriced hype. Even if not all of them are currently in use, a quick google search implies more than half still are. Even if you personally don't like it, lots of other people do and it has been a huge moneymaker for some.

ctually I can, and I just did. My personal grievances with Apple aside, the point is that you're always reliant on third parties: I could go reductio-ad-absurdum (as I did with my IE6 example) and suggest that Scirra becomes a mobile device manufacturer and OS vendor as well to minimize reliance on external factors. That would obviously be outlandish - my argument is that making native exporters might not be totally inviable, but it's still unreasonable. This phenomenon even has a name: Not invented here. Why do you think Ashley's solutions would be better than existing solutions?

but apple doesn't want to for some reason that they apparently don't want to disclose (or at least in my search for answers I don't recall finding an official reason)

And there's that "third parties are unreliable" issue again. Back when clickteam was developing the android exporter, they ran into some bug in the official Android SDK that prevented them from continuing. Chrome for windows 8 ARM still has many of it's capabilities artificially limited. JIT compilers for iOS are inaccessible, third parties cannot compile. Apple's software can, though, so it's not an engineering or technological problem.

This goes to show that even when making native compilers, the list of possible problems with third parties is huge! Sticking to HTML5 has its cons, but at least there you know the issues will eventually be fixed, since you have giant players throwing their weight behind HTML5's success.

Which company was that? Regardless, one company's failure does not mean another company will not succeed. There are quite a few frameworks that export native just fine.

..? The company is clickteam. But we can also talk gameSalad, gamemaker, and many others in the scene. The reason I chose C2 over them is because I think C2 is a better product. And that is due to not wasting time on exporters. Ashley keeps mentioning "what a waste it would be to develop native exporters and by then HTML5 is good enough", but can you imagine the waste it would be if we had a native blackberry exporter? Symbian? Tizen? XNA? Ouya? Windows Mobile? Ubuntu touch? Palm OS? Bada? Hindsight is always 20/20 but who could've predicted the huge success of the wii? Or the huge failure of the WiiU? Or the sudden appearance of the iPhone? Blackberry was once a huge company, so it's not like you're safe by sticking with what's established today.

It's really not. It's the result of years of work and quite a lot of code.

eep in mind I'm talking about the IDE only, not the engine powering the games or the exporter. The most complicated parts are the event editor, the image editor, and the saving/loading of it all into XML. Sounds like, at most, a few months work to convert, though only Ashley can say with any certainty.

Aphrodite: yes, I'm suggesting scirra sticks to their currently business plan - which means to stick to HTML5. The entire tech industry has been moving the way of the web for quite some time now, and with HTML5 this has just accelerated.

Most people working with computers either use the browser as their only software or could do so if desired - the exceptions are people like 3D modelers, VFX artists, graphic designers and other specialized functions like database admins and the sort. Even programmers are switching to javascript based IDEs like brackets. We already have quasi-html5 based OSs (chromeOS), html5 smartphones (Firefox OS) and most of the software industry is investing almost exclusively on web tech for new apps.

In my opinion, the only thing Ashley needs to change is:

• Develop a command-line exporter
• Create a new editor using web tech - this is not a website or a "cloud editor", but a normal software just like the one we use except instead of C++ it's made on javascript. The current editor is quite simple so it's not like it would be difficult to port. It even makes development faster, since you can share code between the runtime and the IDE.
• Open it up for developers to create IDE plugins (say, and IDE SDK) - stuff like dialogue tree editors, AI editors, finite state machine creators all would suddenly become possible with ease. Currently those kinds of tools can exist, but they'd rely on modifying the XML, which could cause corruptions. Examples of the kinds of things possible are the spriter and tilemap plugins, which only exist because scirra supports them officially.

Ugh... I'm sorry guys, I was lurking around watching this discussion but I have to chime in - Ashley is a veteran of the industry, he was already a veteran back when I started, and I have 14 years of experience with this sort of dev tool, so I like to think my opinion carries some weight.

Windows XP is too old to even be considered! Why don't you go ahead and ash Ashley to support internet explorer 6 as well?

Windows XP is 13 years old! When XP was launched, not even windows 3.1 was that old! That would be equivalent to you booting up your XP machine for the first time and hearing someone extol the virtues of windows 2.0! I'm sorry, windows XP isn't even a factor anymore. And that's not even counting the woes of it's 64 bit version, since the 32 bit one can only address up to 2 Gb RAM.

... we don't need an entire browser engine - we just need what games need...

gutted version of node-webkit would be great - there are tons of things we don't care about that could be removed in order to reduce the overhead.

As for the issue about third party plugins - as much as I appreciate all the work put into them, even with C2 as it is now, the vast majority of games could be made without them. If C2 was feature complete, then even more so.

think that the fact that third party plugins aren't necessary for the vast majority of projects says more about the lack of power in the SDK than it does about the power of construct. Many of the advanced plugins, such as spriter, tilemap or the upcoming multiplayer have advanced hooks to the IDE that we normal developers just can't access, which means plugins that require advanced or intensive configuration are right out, unless you're willing to edit XML files (thank Ashley for having the foresight of having c2 use an open format, or even that would be impossible).

By hiring someone to work on native exporters concurrently, it would reduce the impact the extra work would have on C2 itself. Tomsstudio is showing that it's possible.

omsstudio is showing nothing. I don't say this because I hate him or anything - if he manages to pull it off, power to him! However, making an exporter is a gigantic overtaking even WITH support from developers and a proper exporter SDK - just ask the creator of the anaconda exporter at clickteam (and that exporter is based off a much less feature-complete product).

Working on native exporters is a trap, just look at the state of multimedia fusion 2.5 - practically a joke, after all those years they release a meager update with either nothing new (support for skinning), features it should have had from the start (utf-8) or, at best, features the competition had for nearly a decade (zooming/rotating the layout).

The point of asking for native exporters wasn't just about solving performance problems, though that was a big part of it - it was also about other things like the issue of no memory management on iOS and about you being able to directly control the quality of C2's own exports.

OS is, as well as everything else apple makes, overpriced hype. They should be the ones fixing their memory management and enabling webGL/javascript compiling for third parties - we moan at ludei for not fixing cocoonJS but who's knocking on apple's door telling them to get their act together?

What it really boils down to is too much is based on hope. I'm just tired of relying on hope for the quality of exporters to improve, and worse, once we get them, having to hope that a quality exporter isn't later screwed up in some way.

[...]

I'm afraid I'm still in the native bandwagon.

[...]

I think it is more important for your long term benefit to make native exporters

nd what's the alternative? Making native exporters? Well let me tell you a story about a similar company that went this route, and that's an established game-making company with many employees:

• First, they release a java/j2me runtime. It is broken and many features are missing or are inconsistent. They continue working on said exporter, but nearly no one uses it. The java/j2me forum section stands nearly empty. A few years later, smartphones arrive on the scene and j2me quietly dies. The java runtime is useless for windows because the traditional exporter is way better, and it's also useless for mac/linux because it supports so few features, and the JVM is so bloated that the speed is minimal. No hardware acceleration either. The SDK for making third party plugins arrives so late it's not even worth considering.
• Then, they begin work on a XNA exporter. A few months after the launch, Microsoft announces XNA is being discontinued. Almost no games are made for the XBOX using this exporter, though some prototypes are attempted. The SDK for making third party plugins for this exporter is never released.
• So they work on a flash exporter. Well this one actually works, except flash is dying as we all know. Also, it has poor support and all third party plugins have to be remade.
• iOS is here, so better make an iPhone exporter, right? Cue years going by, and the final exporter performs poorly and offers little support. SDK arrives late as usual.
• What's this Android thing? You would think that since a java exporter was already available, an Android exporter would be a piece of cake, and you would be wrong. The Android version arrives many many many years after the big Android boom. As usual, poor compatibility and no SDK.
• Now they're working on an HTML5 exporter. Want to bet where that will take them?