digitalsoapbox

Agreed, based on the way Scirra operates full native doesn't work for their timeframe.

For our game we ended up with a 500mb project at export (lots of graphics and music and sound, lots of levels, lots of other layouts, and lots of things going on in-game, and about 3 to 4 hours of gameplay), and after finally releasing the game we found that the performance was very hit-and-miss across machines with almost the exact same (great) specs and that screen-recording software like FRAPS or even a Skype window share would cause glitches like characters jumping higher than they should ever be able to. For some customers even having Chrome open at the same time caused noticeable issues.

Right now we are only able to use Node Webkit 10.5. We figured updating to NW.js 12.0 would be better, but performance has not been near what we get in 10.5 (and upgrading C2 also drops performance for some reason, we've tried each new release since r196 with no luck).

This isn't a small game admittedly, but it's also not the largest I've seen for 2D games made in middleware like Construct 2. We invested a large amount of time into optimizing performance and still see things happening from customers that have never happened in our testing. Things like this are almost impossible to "produce a blank cap demonstrating the bug" for and are also why we had to make some tough decisions on which platforms to release on based on how many people will likely be unable to run the game at all (not an unnoticeable amount based on Steam's hardware surveys).

So yes, it's partially humour to say C2 is still early access, but when it comes to stability in larger games and selling to a fairly large customer base, it's definitely the rough and early stages for us, bugs that would be tolerable in freeware or unnoticeable in smaller games matter and the ones we don't have control over are what hurt the most.

digitalsoapbox Awesome, can't wait to hear how Xbox One is looking! I agree that Unity has its flaws and that's actually why I really want for C2 export formats to be able to get into a position of having more stability and performance, I just feel that it's not yet the time for the website to say "We're stable and you can make whatever 2D game you want and it'll run amazing!" all over its product pages and then turn around and say "Well, it's kinda early access so just wait for the next update/technology" when people are having issues.

TiAm definitely agree it'd be nice to have either more forces working together on node-webkit or competition to let the best ones survive/rise to the top.

Schoening again attacking people who are having legitimate issues that are within the bounds of what they were promised the engine would do is not fair. I agree with you that full re-write is insane for just one programmer, but now with C3 in development it's worthwhile to have people voicing their concerns of what they want in the future (and doesn't that mean that C2 is going to someday too be retired like CC?)

I don't get extra slack from any customers or reviewers when my 2D 80's inspired arcade game doesn't run properly on decent machines just because we are a "2 man team building an HTML5 game". It's great to be a fan of Construct, I have been since almost the earliest betas of Construct Classic

It really sucks that people would ever need to "f*** off", and it doesn't look good on the community or development tool as a whole if they do. It's not the people trying to make a 3D MMORPG leaving, it's people making simple arcade platformers and top-down racing games who just can't get their professional games working the way they need them to. I think I'm just saying that it isn't "you're with us or you're against us", it's a community of people who all have very different goals and aspirations under the same promise, the same things we see in the advertising material and feature lists of Construct 2.

volkiller730 Very true too!

Ashley hmm, my point was that the same bug being someone else's problem (while still technically being our problem as paying customers and therefore also a problem for you) doesn't make it any better. Google release updates that try to be one-update-fixes-all, and so when they introduce bugs for us it's not really their problem and it takes more effort to get the whole community to report the bug so that they realize it's important.

Sure, they have connections and contacts that you don't, but they also have way more projects and people to support in their day job. Perhaps hiring an expert in low-level driver/OpenGL issues who can experiment and debug and fix while you can focus on the next features would make native extremely viable, and everyone would benefit even if the cost of C2/C3 was increased for it.

Ashley Well I wouldn't mind the customer needing to install proper DirectX files, even now we are finding that customers need to install DirectX updates or the latest versions of their graphics drivers in order to avoid the game having the strangest glitches/bad reviews, so it's not really that much of a difference in our case.

There probably are nasty bugs hiding somewhere in each layer that you are working on top of for sure, but the ability to fix it or do a work-around at one of the lower levels rather than relying on a slow giant corporation to contact another slow giant corporation seems better for consistent stability (as a driver or DirectX/OpenGL issue will still exist in our games but be further out of reach as it may require a driver update, and also modifications to Node Webkit, or even Chrome itself). I know well that it's tough enough getting anything to run properly across a variety of machines, so it definitely is nice that the runtime is able to slowly expand its compatibility and stability every day, but it also feels like it's taking a lot longer for fixes to trickle down the chain than even making an in-house webkit style runtime would take to fix some of the most pressing bugs right now.

Yeah, it is pretty cool that Google is putting some help into fixing their own product, but that's also a situation where you are just as helpless as your customers, as the problem is further up the chain. At least with the AMD bug you were able to fix it and then release it as soon as you had the solution. Google could tell us the secrets to all of our Node Webkit issues but if we aren't compiling the source code ourselves we can't fix them.

And that's great, I really love C2 and all the hard work you've done since your Tigerworks days. I do see the future of HTML5 and WebGL, but my customers aren't buying the future they just want to play my 2D game on a PC that is more than fit to play Half Life 2, and any bugs that I created/I am able to fix myself in my capx, or that you can fix in a future update, are A-Okay

Egyptoon

Yeah I agree <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

but also I would acknowledge that there have been quite a few professional games made in C2 of varying genre and size, here's a list of Construct 2 (and some Construct Classic from the looks of it) games on Steam Greenlight (some of which have been Greenlit/are already on Steam): http://steamcommunity.com/sharedfiles/f ... =103535227

digitalsoapbox as someone who has made both 2D and 3D games from scratch I can confirm that it actually is better in some cases than being completely held hostage by a third-third party (as it's not just Construct 2 and driver vendors we are waiting on, it's also Chrome, Node-Webkit, and the HTML5 standard in general).

The main reason we don't re-invent the wheel is because we want to actually finish the games we make instead of producing tonnes of unfinished abandonware before we finally settle on choice of programming language, memory usage/allocation, design pattern(s), and other low-level things. Prototyping is a great time to switch engines around, and being half-way finished or further is not.

Middleware that works roughly the same way every time can be accounted for with work-arounds, while random engine-breaking updates can stall or kill a project entirely.

The reason why I personally want native desktop is because I know that Scirra can and has done an AMAZING native DirectX 9 runtime before with Construct Classic: http://www.scirra.com/construct-classic

Literally the C2 editor exporting to CC would be all I'd ever need ( as CC had a buggy editor but pretty solid runtime...except on Vista <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz"> ).

Point is though, we want to use Construct 2, as a game dev tool it is literally the best we've ever seen, especially for 2D games. However, when you want to release commercial titles and pay say $500 for a copy of a "professional business edition of a game development tool" for each member of your indie studio to do so, you really want said game engine to actually perform the tasks it promises, especially after you've just raised all your funds in a Kickstarter and now have to release a product on the budget you initially planned (and other, less specific, cases).

Unity is where a lot of serious C2 developers seem to be going, and each one I've seen hasn't blamed the editor in Construct 2, just the lack of control that Scirra has over runtime/export.

Also as a side note I've been following Sombrero for some time and it's looking really good, reminds me of the Friendly Strike series I played in my Clickteam TGF/MMF days <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

szymek

Hehe, funny you should say that, because that's almost exactly what we had to do with our game and it did cause quite a few people to lose interest

I don't mean this as a slight to C2. It's without a doubt one of the best 2D engines out there for hobbyist/learning developers. But in my opinion it's not ready for commercial scale development due to reliance on third parties. [AGAIN, I'M TALKING PC/CONSOLES HERE] Not that it can't be done, but it can turn into a nightmare very fast when you want to release your game but for some unknown reason it janks on supercomputers, or runs horribly bad on all intel processors, or doesn't run at all on current-gen consoles.

tl;dr: HTML5 is the best choice for C2 but it means commercial PC developers will have a bad time.

Completely agree with this, it makes sense to stick with HTML5 for C2, but for now it's a real shame we don't get that kind of editing/development power it offers when we also need native export for desktop (at least Windows, the largest user base for gaming on PC right now) in order to reach the full user base of PC (not just people running quad core desktops and a nice GPU).

There are just too many people who see a simple retro 2D game and freak out that it doesn't run on their old Windows XP/Vista/even sometimes Windows 7 computers, because it "seems just like a Neo Geo/NES/SNES game", and then that looks bad on the game devs and in the end hurts their sales and image. In fact, we recently found that even certain applications running at the same time can screw our game up entirely (Chrome, FRAPS, other screen streaming stuff including Skype sharing, etc...).

On the other hand, it's almost a self fulfilling prophecy too if the cycle is "No big (by PC standards) games made in C2 = no evidence of C2 as a 'pro' tool = nobody buying and learning C2 to make big PC games" and so on...

Nice find!

I think the biggest thing worth mentioning about HTML5 performance in general (both for Desktop and Console), is that the scope of the game is currently the performance killer. Small Atari-2600-style games (with updated graphics) will run pretty well, especially if they run fine in Canvas2D, but anything 80's arcade and newer can really start chugging, especially if it needs WebGL just to get a 30+ framerate.

For anyone interested, Insanity's Blade is on sale on Steam this week with a 25% off discount! Check it out at http://store.steampowered.com/app/334190/ <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

Or, watch the trailer here: http://youtu.be/XzmLmNBH7D4

Maybe it's better to describe it as scripting, as you aren't doing the core engine code, but are working with a form of "pseudocode" to manage the game logic/mechanics. So in a way, it's part of programming, but not quite the same as programming in a literal "programming language" or at the engine level.

Game developer works too to say that in a shorter way (they design how the game should play/feel, and often in a team will get an engine programmer who enables them to do that, although programs like UDK, Unity, Source, CryEngine, etc are enabling much more game development without an engine programmer now)

Nice job!

I get 36 to 48fps (usually around 40fps) on Chrome, but performance was pretty bad on both IE and Firefox.

My specs:

Windows 8.1 Pro 64-bit

AMD Athlon II X4 645 (quad 3.1GHz)

8GB DDR3 RAM

NVIDIA GeForce 210 1GB DDR3 (running both a 1360x768 VGA and a 1600x900 DVI display)