Ashley's Forum Posts

  • You do not have permission to view this post

  • No, it does, the program offers to take you here where you can pay what you want for Construct 2 - this is live and working. I guess the answer makes it sound uncertain, but we are definitely going with pay-what-you-want initially, and you can make payments now if you wish.

    Perhaps a better answer for the last question would be:

    Q: I hear a payment system mentioned. How is this going to work?

    A: Scirra developers would like to make some money while developing C2. This in turn is supposed to help motivate them to complete C2 faster and/or better. As an experiment, Construct 2 has been released as "pay-what-you-want" software. You can choose how much you pay for it, or use it for free. A possible future idea is to sell additional exporters, but pay-what-you-want is all there is right now.

  • 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

  • Try Construct 3

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

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

  • <img src="http://www.scirra.com/images/html5.png" border="0">

    HTML5 exporter

    Construct 2's primary exporter generates HTML5 games using a Canvas element. We feel this is much more relevant in today's world than a Windows desktop EXE exporter. For those who haven't heard the term before, HTML5 is the next major revision of HTML and web technologies which modern browsers are already starting to implement. There's a nice overview I found here, and you could also check out the more in-depth HTML5 Wikipedia article.

    While HTML5 doesn't have a widespread adoption just yet, we're building C2 for the future, and when it does, you'll be able to share your games on the internet across almost all devices and operating systems, with a single format. HTML5 is essentially the main features of Adobe's Flash incorporated in to pure HTML and Javascript - and it'll run on iPhone, iPad, Android, Windows, Mac, Linux, or any device at all with a modern browser. The latest version of Firefox, Safari, Chrome and IE9 all currently have good support for HTML5. Support will improve, but older browsers (IE8 and below) don't support HTML5. IE9 is due for release imminently (the beta is available here), and although it'll probably take a couple of years for HTML5 to gain the same support as Flash, we'll be ready and waiting when it happens.

    Modern browsers are also in an arms race to hardware-accelerate the HTML5 canvas (using either OpenGL or DirectX depending on the browser), as well as to get the fastest javascript engine (several browsers compile javascript to machine code). HTML5 canvas is headed towards being a very high performance platform.

    Plugins are written entirely in Javascript (both edittime and runtime, thanks to integrating Google's V8 javascript engine in to the exporter). Plugin developers who want to get involved in extending C2 no longer need Microsoft Visual C++ - just some everyday Javascript know-how and Notepad. Hopefully this will open the floodgates for developers - the barrier to entry is very low, and there are tonnes of opportunities for implementing cool new web technologies via plugins (WebSockets anyone?). Users win too, with more plugins to choose from, as well as being able to very easily custom-code specific plugins for their own purposes.

    Multiplatform architecture

    C2 is designed around external 'exporters', which are written separately as add-ons (like plugins) and should make it significantly easier to port to new platforms further down the line. This also means there'll be an Exporter Development Kit (EDK). Ambitious third party developers can write their own exporters and enable Construct 2 to export to new platforms and devices entirely independently. Since the exporters are separate to the editor, these exporters can also be sold commercially by independent developers.

    Hopefully this will encourage third party ports to new platforms. This could include an official Windows desktop EXE runtime in future, a third party Android native exporter, or whatever anyone thinks up.

    Checked builds

    Most releases (unstable ones) will be 'checked' builds. These contain loads of internal checking that can spot problems in the code. All these checks might slow down performance a little bit, but they mean if you encounter a bug, chances are you'll trigger one of these checks, and you'll get a messagebox with a dump of useful diagnostic information. This should make it much easier and quicker to fix bugs - instead of just "it crashes", with a copy-and-pasted report from the user, we can immediately know the exact source code line and even a rough idea what went wrong. This should also help us make a lot of changes quickly and still be confident everything's working, if there are no 'check failures', and vastly improve the overall stability of Construct 2. (This, and our improved coding experience, should mean we do much, much better than Construct 0.x's stability.)

    Unicode

    Construct 0.x has no unicode support which makes it nearly impossible to translate, and hard for people to use non-English text in their games and events. Construct 2 is fully unicode enabled - you can't translate it yet, but you can use unicode strings in your project content, object names, and so on.

    XML data format

    Projects, layouts, everything non-binary is saved in a human-readable XML file format.

    Project folder structure

    C2 can now store projects in a folder, with separate files for the project settings, layouts, and UI persistance information, and so on. This makes saves much faster (only changed files are saved back to disk, rather than regenerating 100mb of data every save if you have a 100mb .cap). Collaboration becomes much easier as well, since you can either send changed files between team members, or place a C2 project under source control like SVN, and have full versioning, merging etc. Given that the file formats are XML this is much nicer for collaboration too.

    For small demos and examples single files are still more convenient. For this, you can still create .capx files which are just a zipped project folders (you can actually rename them .zip and open them). These open and edit transparently just like old .cap files, but for large projects they'll be a little slow, so they're mainly a convenience feature (eg. for posting to forum).

    Improved UI

    The Windows 7 ribbon looks much nicer than the old ribbon, and it's a free part of Visual Studio - no dependencies on the proprietary Prof-UIS library that we had to pay for! Much of the UI has been redesigned and thought out from scratch, and hopefully it's a lot simpler, easier and faster to use.

    OpenGL

    Construct 0.x uses DirectX for both the editor and runtime. Construct 2 renders with OpenGL for the editor (since the primary exporter is HTML5, there's no hardware acceleration API built in - browsers can provide acceleration themselves). OpenGL 1.1 ships with Windows XP, and there's no need for D3DX installation for the editor. There's also no Visual C++ library installer required, so the installation is simpler and quicker.

    Other notable changes

    The entire program has been redesigned taking on board the most popular suggestions and gripes from Construct 0.x. Here's a few other smaller improvements:

    • Everything in the project is organisable in to a folder heirarchy (layouts, objects, etc), which should help organise large projects.<div>- There is both a 32-bit and 64-bit native version of the IDE, so 64-bit users can enjoy improved performance.</div><div>- The install should be portable, so you can install to e.g. a thumb drive and run it on other computers without going through the installer. This also means it can be run in places where account limitations prevent you running installer, e.g. in schools, universities, workplaces. (Remember the 64-bit editor won't run on 32-bit Windows, so if in doubt, install the 32-bit one.)</div><div>- Expressions are statically evaluated. If a parameter can be worked out in the editor (e.g. it's constant) it's evaluated and can be checked by its plugin. For example, the Array object can reject -1 for an X index - in the editor, before you run.</div><div>- Specific instances can be used in expressions, e.g. Sprite(2).X</div><div>- All indexing in the event system is 0-based. 1-based just doesn't make sense mathematically, and it's totally consistent this way (the random() expression has always been 0-based, for example).</div><div>- There's a new "configurations" system. You can edit multiple configurations (ie. tweaked arrangements) of your project, for example, to create a demo of just the first three levels - within the same project as the main game.</div><div>- The x.xx.xx version number system has been dropped. "1.0" is an arbitrary milestone - not only was it a bit of a fiasco with the previous version, but software rarely reaches 1.0 and stays there, so "1.0" hardly means "done". To reflect this, releases will simply be numbered (1, 2, 3, 4...).

    No backwards compatibility

    It's important to note there is no backwards compatibility to 0.x in Construct 2. That is, you won't be able to import your old .cap files in to Construct 2.

    We realise this is going to be a gripe with many users, but the whole reason we've been able to make so many of the above changes is by forgetting backwards compatibility - and just for starters, the HTML5 platform is a completely different technology to a Windows desktop runtime, so there are lots of features that aren't transferable anyway (everything from pixel shaders to the venerable but archaic INI object), not to mention the web is a whole other paradigm to the desktop.

    It may be possible a third party developer creates some tool that can do some kind of partial conversion from 0.x to C2, but it won't do everything. Also, considering the many and far-reaching changes in C2, we'd recommend projects are rebuilt from scratch in C2 anyway - so you don't get stuck using old patterns and ideas, and take full advantage of new features.

    Unfortunately we don't have time to write a converter tool ourselves - we're still effectively laptop-in-our-bedroom programmers, with other commitments outside of Scirra, and C2 itself is a never-ending project. We would love to have easy import from C0.x, but there's just no time, and we're excited about the future. However, we hope you'll agree the new improvements are promising and exciting. Your feedback is welcome.

    <img src="http://www.scirra.com/images/c2cog.png" border="0">

    </div>