Thanks - good FAQ.

There are no plans to port the editor.

Given how big a project is, there's plenty to do. I have lots of experience with Windows programming and UI, mostly from 0.x. The editor is the largest and most complex part of Construct 2, and it's a massive, massive timesaver to stick to one platform, and not have to learn a new framework, UI library or anything else - I can just use my existing experience. I don't have to keep stopping to learn the framework or getting stuck on problems I've never solved before, I can just work straightforwardly.

I keep saying this but I'm only working part-time on this, and the fact is, because of that, every single piece of work absolutely must be looked at in terms of time it will take against the benefit of having the work done. A multiplatform editor would mean maybe double the workload, and only bring the user coverage up from 90% to 100%. Basically, I can't justify that. Sucks for Mac/Linux users but unfortunately I just have to optimise everything I do for the greatest return.

C2 is still open source, so if it becomes popular, it's perfectly possible a parallel project could start to port the editor.

I'm not expecting everyone to be happy, but thanks for putting forwards your views everyone.

In short, the open letter addresses the Construct 1.0 issue. To put it very briefly, it can largely be put down to technical issues: we could release "1.0", and due to its poor architecture, it would still be unstable, so we decided the term "1.0" would be misleading. With our greater experience C2 is much better designed, so the same reason should not prevent the "1.0 of C2". And 0.x is such a mess, improving it from where it is would be more effort than starting from scratch.

Also, the 'desktop runtime' would be OpenGL powered, and can probably hit Mac and Windows in one go if it's coded right. Anyone can make an exporter through the open exporter SDK, so there's a valid risk somebody might make a free one, but it takes a lot of in-depth knowledge of Construct and the event system algorithms to make a successful exporter. That puts the Scirra team at a big advantage over everyone else.

OpenGL can do everything the old 0.x runtime did - shaders and all. When a desktop runtime is in the works, there's no reason to believe it'll be any less powerful than the 0.x runtime. In fact, if we're making money from it, we can spend even more time on it and make it even more powerful! That also depends on the pay-what-you-want system and other factors, though.

I'd just make a forum post if you get stuck - there probably won't be SDK docs for a while.

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!

A quick question: is it possible to set it up so that when you choose Run Layout, it opens the layout in Firefox or Chrome, as opposed to IE?

Obviously would be a useful feature but it's just one of those not-a-showstopper things that's been postponed. For now, you can just cut and paste the temp URL when previewing in to other browsers.

[quote:2tygi6pw]I do like how the sprite editor is now MSPaint

That's actually an intermediate measure until Davo comes up with a new picture editor

Haha, I can't believe Pong, Asteroids and Mario have already been (sort of) done with such limited features! Good going

What browser are you using? Chrome and IE9 are very fast, the others are still playing catch up (but I think they've all announced plans to hardware-accelerate their canvases).

Internet Explorer 9 beta v-syncs the canvas so it's as smooth as the 0.x runtime - maybe give that a shot to avoid tearing?

Download Construct 2 public preview 26

Why is it release 26?

We're using an incrementing version scheme, and the previous releases were private.

More information

Please read Welcome to the Construct 2 public preview!

Known issues in Construct 2

There are some problems and incomplete features we know about already; please don't report these as bugs!

• [s:39nthbwz]I can't seem to persuade Windows XP to group the list items in the event wizard, like 0.x does. It works on Vista and up though.[/s:39nthbwz]
• Collisions are only bounding box.
• [s:39nthbwz]Collision events (Is Overlapping/On Collision) don't pick the second object properly in all cases.[/s:39nthbwz]
• [s:39nthbwz]The initial event algorithms are inefficiently coded, so a functioning prototype could be developed quickly. This can be sped up significantly. If you find the loops or other events slow, consider this a work in progress. (It's not because Javascript is slow.)[/s:39nthbwz]
• You can't create an instance of an object at runtime if there isn't at least one instance in a layout somewhere in the project. (This will be supported eventually, it's a new feature over 0.x though.)
• [s:39nthbwz]Copy-pasting objects between projects isn't done yet.[/s:39nthbwz]
• [s:39nthbwz]Opening two projects appears to remove all icons from the project bar. (Cosmetic only, rest of functionality with two projects open should work.)[/s:39nthbwz]
• [s:39nthbwz]In some cases, switching between layouts at runtime leaves the scroll position in the wrong place.[/s:39nthbwz]
• [s:39nthbwz]Nested looping conditions don't work, and triggers as subevents to loops don't work either. However, ordinary looping conditions by themselves should work OK.[/s:39nthbwz]
• Missing features should not be considered bugs!

Since there's not currently any UI to pick expressions, here's a list of all expressions currently supported in C2.

General expression features

Javascript does not actually support an integer datatype, but support is emulated by the runtime by rounding floats. However, any operator involving a float returns a float (so e.g. 5 + 0.5 returns 5.5 like you expect) so this probably isn't going to be an issue for anyone. Also, division always returns a float, so 5 / 2 = 2.5 (as with 0.x), if you want integer rounded division, explicitly specify it with int(5 / 2).

There are no expression shortcuts like in 0.x: you can't type .X as a substitute for Self.X. However, the Self keyword works.

You can specify specific instances in object expressions: Sprite(0).X gets the first picked Sprite's X co-ordinate, Sprite(1).X the second, and so on. Sprite(N) when there are N sprites will wrap-around and return the first Sprite's X again, Sprite(N+1) the second, and so on. Sprite(-1).X will return the last picked Sprite's X co-ordinate, Sprite(-2).X the second last, and so on. You can use any expression for the instance to pick, you don't have to just enter a number.

The usual arithmetic operators are supported: + - * / % ^

There's a new unary minus operator, so you can write -Sprite.X instead of 0 - Sprite.X.

The conditional a ? b : c operator was a bit buggy in 0.x - it should be working correctly in C2. Example: Sprite.X < 100 ? -1 : 1

The & operator is string concatenation as in 0.x, or logical AND when both operands are numbers. The | operator is logical OR (and has no special behavior with strings).

System

int(x) - convert x to integer

float(x) - convert x to float

str(x) - convert x to string

len(x) - return length of the string x

random(x) - return a random float from 0 (inclusive) to x (exclusive) - note this differs from Construct 0.x where random would return an integer if you passed it an integer. Use int(random(x)) to reproduce this behavior.

random(a, b) - return a random float from a (inclusive) to b (exclusive).

sqrt(x) - compute square root of x.

abs(x) - absolute (positive) value of x.

round(x) - round x to the nearest whole number.

floor(x) - round x to the lowest next whole number.

ceil(x) - round x to the highest next whole number.

sin(x), cos(x), tan(x), asin(x), acos(x), atan(x) - trigonometric functions, which work in degrees

exp(x) - e raised to the power x

ln(x) - log to base e of x

log10(x) - log to base 10 of x

lerp(a, b, x) - linearly interpolate a to b by x

distance(x1, y1, x2, y2) - distance between two points

angle(x1, y1, x2, y2) - angle between two points (degrees)

loopindex - current (top-level) loop index

loopindex(name) - loop index of 'for' loop of given name

max(x, y [, z...]), min(x, y [, z...]) - returns maximum/minimum of any number passed - like 0.x you can pass any number of parameters here.

newline - text string containing a line break character.

dt - new name for 'timedelta' which is the standard used in games programming (it's actually usually referred to as 'delta time', so 0.x got this the wrong way round!). Currently always returns a fixed value (1/60th of a second) because Javascript does not have a high-resolution timer. You should still use it so you're future-proofed in case dt is ever modified to actually be a time measurement, and when implemented, timescale will modify this value.

timescale - always 1.0 at this time.

time - time in seconds since the game started.

tickcount - number of ticks elapsed since the game started.

objectcount - total number of object instances in the game.

fps - current framerate in frames per second.

scrollx, scrolly - current scroll position

Common object expressions

Currently, Sprite and Text implement these.

X, Y, Width, Height - as with 0.x

Angle - (Sprite only) Angle in degrees

Count - number of instances

Other object expressions

There are no longer MouseX or MouseY system expressions - insert the Mouse object and use Mouse.X and Mouse.Y for the mouse position in the layout, or Mouse.AbsoluteX and Mouse.AbsoluteY for the position on the canvas.

The text object also has a 'Text' expression (surprise!).

Instance variables

Access these by their name like this:

MyObject.MyInstanceVariable

You can't name an instance variable the same as an object expression.