Quazi has always been making amazing things in CC since he first started with it (eg: Mega Thumb: Dream Match http://gamejolt.com/games/mega-thumb-dream-match/3161 ), but TowerClimb was always amazing even before it made it onto Steam! Really glad that it's getting some recognition <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

Lots of games on Steam and other platforms. For Steam you can track the (rough) stats of how many people own a game with sites like SteamSpy:

The Next Penelope: http://steamspy.com/app/332250

Cosmochoria: http://steamspy.com/app/293240

Insanity's Blade: http://steamspy.com/app/334190

Some middle-man companies also use Construct 2 to develop HTML5 templates or games on behalf of other clients, including web games and mobile games.

"Big blockbuster" is not what I would really describe any of the desktop C2 games as though, as we found even with Insanity's Blade that there are major issues with Node Webkit export of larger games, causing issues in Linux and MacOSX exports, and also issues with updating past r192 and NW 10.5.

Is it still a good tool to use for making your indie titles? Yep! <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Here's damainman's playthrough of the C2 prototype for our next title Battle Princess Madelyn

More info on the game in official thread: https://www.scirra.com/forum/battle-princess-madelyn-from-the-makers-of-insanity-s-blade_t165299

Thanks for the support and glad you like the prototype so far — ! We don't have a release date yet sorry, but you can check out our blog for the latest news! http://www.causalbitgames.com/

Do you remember the last voting?

All the kids voted "multiplayer", not having any idea what they were doing..

Despite its relatively light usage, this was still an important feature or option for C2 to be a much better tool for future professionals, and provides a great selling point even with the complications of writing your own Node server (which could be a simple echo, then handle logic in C2).

Letting the community vote is important because we're not voting on features in a specific game (eg: the ones we are making now) but the possibilities we want in the future. Having options is what Construct 2 is all about.

So I would say that I completely agree with letting people vote, but Scirra can then fine tune the order of implementation based on difficulty of the tasks. Voting just makes sure they know what their customers want.

jamiek here's a handy guide to using the Interwebs!

https://youtu.be/mfMrVKnGzwg

Also your question doesn't quite make sense ,but you're better putting it on the How Do I...? section!

No problem! I used to be a huge fan of Fusion (1 and 2) before switching to Construct Classic and later Construct 2.

Fusion's best part is that (at least the previous ones did?) it exports to native DirectX and has a lot of commercial titles to showcase, but I personally prefer the work-flow of Construct even since the beta days of Construct Classic. Either way, that is definitely a good price!

3: can I output native windows code in a single .exe file?

I'd break this down into two answers:

Native? no, it's HTML5 so your content/game runs within a native EXE based on the Google Chromium engine. This in theory should work "almost natively" on Windows, Linux, and Mac OSX.

Single EXE? To share yes, if you make it an installer/uninstaller as someone above has mentioned, but technically no you can't bundle the whole content of the game into an EXE from Construct 2.

Hope that helps

Similar to other creative or art-type jobs, it's equally possible to become incredibly well off from your works, or to become a "starving artist". It depends on factors like economy (the amount people are willing to spend on your art/game), target audience of your product (and how well you cater to them), word-of-mouth and publicity of your works, and many other things that all have varying effects on your income.

The easiest way *not* to make a living off of games is not trying to make them.

Here's hoping these bugs are sorted out within a month.

Eisenhans

A lot is riding on this game (quit work, gamedev full-time), I knew it when I set out to build it. The deadline was this December.

This is why I truly hope C3 would eventually have a native export. We rely too much on the whims of 3rd party wrappers. I just want the normal reliance on Drivers & Engine to cooperate. Here we got the middle-man Chromium that just tries to Seppuku everyone all the time.

Ouch! Really hoping it works out for you but I don't expect Scirra to be able to do too much themselves.

Node-Webkit (and Chrome) is constantly holding Construct 2 users hostage every other update so far. We were lucky to get something that (barely) works and stick with it (R192 and NW 10.5) for Windows at the cost of losing console and other OS export functionality, but it's also why our future commercial titles will be using another engine.

Construct 3 would be really amazing as a plugin (level editor, object editor, code editor) that can be used by other engines that develop their own exporters/native export with much greater numbers of staff to deal with the nitty-gritty issues.

— good point, although the average Steam user is running an Intel integrated GPU/weak GPU, so advanced games (which could still be targeted for a casual/fairly wide-reaching game) are unable to reach that large chunk of audience. (source: http://store.steampowered.com/hwsurvey?platform=pc scroll down to see the most common GPU per DirectX version running)

As for AMD, be careful there too as we have found that even computers that, based on their specs you would think they should run the game better than an Intel HD4000 laptop, have had some issues where the older cards (2010-2013 and older, basically stuff before WebGL) despite having way more "power" than an Intel CPU were having equal or more lag playing our game. Haven't seen this happen with NVIDIA yet.

Running in windowed mode at native or generally very small resolutions overall makes our game run much much better on entry to mid-level/average desktops and laptops, but with fullscreen resolution (even though the base resolution is less than 320x240) there is still major slow-down which is apparently caused by the upscaling/fill rate based on the past conversations regarding the performance issues of Node.JS/Node-WebKit.

An option to force monitor resolution would be really nice, and probably the only hope of improving performance for real (and before someone swoops in to say "optimize your events before blaming the engine!" yes, we have, we have done everything we could to ensure this).