Just to respond to some comments made recently...
Question for Ash: will exported games be obfuscated, or will there be an option for it?
This is pretty important to prevent reverse engineering of games, so we'll come up with something eventually. However, it's another one of those lower-priority features right now.
I also noticed on the feature thread that apparently pixel shaders can't be used-- is there going to be some way to get equivalent effects?
It's unlikely there will be shaders in the HTML5 canvas. However, further down the road, WebGL may become part of HTML5 - it's essentially OpenGL running in a browser - and that could support shaders. However, WebGL needs to be supported by Microsoft's Internet Explorer to be a viable platform, and it's not clear Microsoft will ever support it. So while a WebGL exporter would be a really interesting project, it's not worth the risk of spending time on it until Microsoft come up with an implementation - and even if they did, it wouldn't be surprising if it was some incompatible "WebDirectX" system, which would complicate the exporter! Anyways, Canvas is the one with universal upcoming support at the moment, which is why the HTML5 exports to that.
[quote:2jkcvlxc]I'm concerned that this whole HTML5 switchover is going to make Construct more appropriate to "toy" games (like Flash)
As you know, Construct isn't limited in power to only "toy" games. Perhaps an enterprising developer will find a way to make "serious" HTML5 games popular?
Also, there have actually been very few "serious" indie games developed in 0.x - probably due to stability issues though. Still, "toy" games would be a good place to start for a new game creator, I think.
Comparing 2000+ sprites with C1 and 120 in C2 I feel this being a step back and not forward
Firefox 4 has a hardware accelerated canvas and matches Chrome in performance. In my own test I could create about 5000 sprites (unrotated) before it dropped to 30fps. I'm of the understanding the next version of all major browsers implement hardware acceleration or will do in the near future, so if a browser is slow, it's probably going to speed up a lot soon. It's a side effect of HTML5 not quite being a mature platform yet - we're getting involved early.
As others have already mentioned, HTML5 is nice, but it's not going to attract many serious Indie devs.
I disagree - Flash attracts a lot more indie devs than Construct 0.x ever did!
I would have thought an .exe would have been as standard
I expected this sentiment, so perhaps I should expand on this.
Since 0.x is a Windows-desktop game creator, it's expected that it attracts people who like the perks: pixel shaders, fullscreen, and so on. The HTML5 exporter is a change in direction from this, so I'm not surprised some existing users are upset. However, still I think this is the best thing to do, for everyone. The modular exporter system was designed specifically so something like an EXE runtime could be added to C2 easily! It's totally future-proof and it can, in theory, be written entirely separately from the editor. However, we've decided to go with HTML5 first. I'll expand on this rationale.
A lot of users request multiplatform support. Many users who don't use Construct see Windows-desktop-only as a showstopper. I've lost count the times I've read around the internet things like "I would use Construct but <other tool> has Mac/Linux/iOS/Android/Flash/Web support!". HTML5 kills lots of birds with one stone - we only have to develop one runtime to have basic coverage of all of them. In order to gain more users - and make Construct more useful to the world - this is the way to go. As I said, having attracted an existing Windows-desktop-loving userbase, this will be disappointing for some, but the fact is the Windows desktop crowd are a minority. When you write software, you have to give people what they want. Perhaps this sounds a little selfish, but we also can't ruin ourselves following a niche when there are bigger markets! And this especially makes sense when it's still planned to make an EXE exporter later. It's just a tough interval for the EXE runtime followers. Also, 0.x is still there to fill that role - you don't have to stop using it! And, when the EXE runtime comes, I'm hoping we have a much larger user base who can take advantage of it - sort of like marketing in advance of an EXE runtime.
Also, another big consideration was revenue. The Construct project is a lot of work for me, and several other people are involved. We've always given it away for free. With this new version, I don't think it's unfair to try to find some way the hard-working team can make some financial gain from it.
Before the 'pay-what-you-want' system was devised, the idea was to sell the exporters. Since they're compiled externally, they can be sold commercially like traditional software. I was trying to decide between another Windows desktop runtime and a HTML5 runtime. Then the question came up: which can we sell?
I don't think we could sell a HTML5 runtime. There are some issues around reverse-engineering and the project images being hosted on the internet, which can probably be partly solved. However, the main question is: can you sell a HTML5 game? It is very difficult to see that being done - it's so easy to reverse engineer Javascript that cracks would be trivial - not to mention hosting a game on the internet means a public URL exists that can access the game. These problems probably cannot be adequately overcome.
EXE games, on the other hand, can be sold traditionally. Users also probably expect features like fullscreen and possibly effects for a game they paid for. So if you wanted to sell a game, you'd sell it as a desktop game.
I think users are much more likely to purchase a Windows exporter when they can sell their game, than purchase a HTML5 exporter when they basically can't realistically sell their game.
Also, if the EXE exporter was free, we'd be interesting to a minority of desktop-gaming indie devs. If the HTML5 exporter was free, we'd be interesting to a whole lot more people. At this point I have to say the plan was to sell a desktop runtime eventually, when it was made - so you'd be looking at having to purchase it if you wanted it in C2. That's no longer certain. Since 'pay-what-you-want', this is all questionable, since nobody knows what kind of effect it'll have. Maybe it'll prove successful and we can also release an EXE runtime under pay-what-you-want - or, otherwise, we'll go back to selling it traditionally. It also means the HTML5 exporter isn't really "free", it's "pay-what-you-want", so the argument isn't quite the same. To be honest, it's largely momentum from the original rationale that made it HTML5 - 'pay-what-you-want' was decided very late in the private preview stage.
So in short, the fact is, long term, Construct would probably peter out and stop if we don't make some kind of money from it. That's life. The plan was to sell a Windows exporter. Maybe that plan will change. I can't say right now.
But rest assured: we want to make a desktop runtime! Then everyone wins, but for the above reasons, HTML5 came first. I hope that helps explain it to those of you who are disappointed!