Construct 2 - Realistic State after 1 gazilion downloads

spy84 bjadams - I was actually contacted out of the blue by http://www.hoodamath.com and ended up selling a non-exclusive license for three of my games. A non-exclusive license basically means that the entity that purchases the license can use it for their own site (usually by hosting the game and generating ad traffic/money). But it is non-exclusive, so I am free to shop my game around to other places and sell it again and again. An exclusive license will sell for more money, but then you can only sell it once. Of course, there are gray areas and nothing is set in stone, and you will want all the terms spelled out in a contract so both parties know what to expect and for how long each party must abide by it.

It's impossible to write software without relying on third parties. All modern software development requires relying on additional libraries written by other people. It is actually quite a difficult challenge to write some software that does not rely on any third party code, and it would look something like a custom-written OS that boots to a DOS-like prompt and would not really do anything useful. A native exporter would just rely on different third parties. In particular I'd anticipate buggy graphics drivers as a particular weak point of native platforms; browser vendors to a lot to work around driver bugs where possible in their engines, and where not possible the GPU blacklist ensures things at least work. (While the resulting poor performance can be frustrating, the alternative often means maddeningly mysterious crashes and glitches that can totally ruin the game, so slow but working is actually the better option.) Then there's OS fragmentation (very problematic particularly on Android), compilers/development tools to rely on, more OS-level libraries that may have various issues, and so on. So I don't really agree that a native engine relies any less on third parties at all; it just relies on different technologies, and that doesn't prevent you from getting screwed by the crappy work of some other vendor, graphics drivers being the perfect example of that.

spy84 bjadams - I was actually contacted out of the blue by http://www.hoodamath.com and ended up selling a non-exclusive license for three of my games. A non-exclusive license basically means that the entity that purchases the license can use it for their own site (usually by hosting the game and generating ad traffic/money). But it is non-exclusive, so I am free to shop my game around to other places and sell it again and again. An exclusive license will sell for more money, but then you can only sell it once. Of course, there are gray areas and nothing is set in stone, and you will want all the terms spelled out in a contract so both parties know what to expect and for how long each party must abide by it.

and which are the games you sold?can u send me a link with pm if you want?

It's impossible to write software without relying on third parties. All modern software development requires relying on additional libraries written by other people. It is actually quite a difficult challenge to write some software that does not rely on any third party code, and it would look something like a custom-written OS that boots to a DOS-like prompt and would not really do anything useful. A native exporter would just rely on different third parties. In particular I'd anticipate buggy graphics drivers as a particular weak point of native platforms; browser vendors to a lot to work around driver bugs where possible in their engines, and where not possible the GPU blacklist ensures things at least work. (While the resulting poor performance can be frustrating, the alternative often means maddeningly mysterious crashes and glitches that can totally ruin the game, so slow but working is actually the better option.) Then there's OS fragmentation (very problematic particularly on Android), compilers/development tools to rely on, more OS-level libraries that may have various issues, and so on. So I don't really agree that a native engine relies any less on third parties at all; it just relies on different technologies, and that doesn't prevent you from getting screwed by the crappy work of some other vendor, graphics drivers being the perfect example of that.

This is way too true.

The major problem we have is HTML5 support across the board is still a very young endeavor and has issues. It gives another platform -one that's implemented on all the other platforms- to distribute a product. It's a standard people can go to that should work the same across all devices, as it's requirements makes it virtually a device on it's own. Once the platforms have enough support in a user agent program that supports HTML5 and implements it well, the complaints should be on par with native programs.

But since it's new it'll have issues getting things as the intent is for stability and speed, and not just optimization. The more support means more speed so going a safe and standard way gets them a significant speed increase in the end anyway.

A good thing to look at is the rise of DirectX vs OpenGL. DirectX was this MS product that was about graphical rendering and such, and like the XBOX people dismissed it at first. For a while it was worse than OpenGL as many cards were optimized for it over the new DirectX. The DX platform grew by having better documentation and worked with the hardware developers -along with having money to back it- to get it to become what has been years as the better and more optimized platform.

If you look at HTML5 we're in the beginning stages still and an optimized user agent that renders HTML5 would have performance similar to native in the end. DirectX did that to the "user agents" (Video Cards), but they had enough money. The web isn't a singular thing, so once more people start adopting, more people will have a demand and in the end that demand is worth more than money.

It's impossible to write software without relying on third parties. All modern software development requires relying on additional libraries written by other people. It is actually quite a difficult challenge to write some software that does not rely on any third party code, and it would look something like a custom-written OS that boots to a DOS-like prompt and would not really do anything useful. A native exporter would just rely on different third parties. In particular I'd anticipate buggy graphics drivers as a particular weak point of native platforms; browser vendors to a lot to work around driver bugs where possible in their engines, and where not possible the GPU blacklist ensures things at least work. (While the resulting poor performance can be frustrating, the alternative often means maddeningly mysterious crashes and glitches that can totally ruin the game, so slow but working is actually the better option.) Then there's OS fragmentation (very problematic particularly on Android), compilers/development tools to rely on, more OS-level libraries that may have various issues, and so on. So I don't really agree that a native engine relies any less on third parties at all; it just relies on different technologies, and that doesn't prevent you from getting screwed by the crappy work of some other vendor, graphics drivers being the perfect example of that.

It's clearly a matter of degree. The more pieces out of your control the more problems especially at the level of exporters where controlling them would give a lot more power in even implementing workarounds for other peoples' bugs including some driver bugs etc. Obviously you will never have 100% of the control, but you can have quite a bit more by controlling export. But even so, the main problem with third parties is, as I said, that they don't make us a priority since we are not their customers. If NVidia gives bad drivers for cards users paid them for, those users will go there to complain and NVidia will respond in some way. Going to Ludei does not seem to have this same effect, especially since I didn't give them any money. I'm sure there's other intermediates that don't respond to users but may respond to developers etc. So maybe that's what you guys should do instead, work with these third parties more closely. I do think that in the very very very long term there will likely be some tool that is robust enough. But that is just so uncertain that putting effort in C2 right now doesn't seem worthwhile, since there is no idea of when it will come. In the end, I don't know, you have a lot of theoretical arguments and reasoning but in practice things don't seem to be working out anywhere near at the level of C2's competition and I think that's really what people care about. Maybe this will change.

Anyway the new game I'm playing now is to see whether I finish my larger unity project before C2 export is in a state where I would feel proud to put out my games

On my on powerful desktop Construct is fantastic, it's performance on lower end hardware where my issues are. My laptop gets 15-25 fps on my game Orbit. We have recently ported it to Unity and identical scenes with the same physics engine with even more complex features such as volumetric lighting gives me 400fps on the laptop and 3000+ on desktop.

For this reason I treat construct as a prototype tool and for that it works exceptionally well. The speed with which I can get ideas down is super valuable for me when game designing. But for publishing, in my experience the performance just isn't there for larger projects.

CrudeMik - that is far too big a performance difference to be attributable to Javascript execution speed. It sounds like you're getting software rendering due to buggy drivers.

Ashley - yeah maybe, I don't really know enough about it. Tested on multiple low-end pc's and laptops and the performance just isn't there, We actually did a live stream with the Area5 / Outlands guys and the game ran really bad on their machine, this is what made us switch engines. So far in Unity it's screaming fast.

There could be many reasons as to why, but we've extended Unity so that we have similar 9-patch functionality and for whatever reason putting the textures onto polys and scripting in c# makes for crazy speeds in scenes with identical complexity between engines.

As i say though, C2 is still my go-to 2D engine, just that for whatever reason Orbit wasn't right for it, could have been bad scripting in events on my end, or it could have been trying to render too much or something like that.

if the wrapper of choice is software rendering because of buggy drivers on graphic cards from 2 years ago, then the developer has no control over that and our games will be unplayable and slow on a number of users that download them. lot of hard work, goes down the drain. html5 is great but it fits best in its' own world... browser games

for $120 i'm happy with C2. If you look at the success of C2 made games like Super Ubie Land, and Our Darker Purpose that's on Steam for $14.99, then u can see the potential of C2 if you are patient and you keep learning and improving your skills.

But I do agree with the need for native exporters for android, ios, etc.. Although from personal experience I do have to say that a good export with Ludei or whatever can depend on the settings you use, so fiddle around with the settings like pixel rounding ON, Canvas2D instead of WebGL, try different Physics engines, etc.. and also 1/2 or 1/4 your texture sizes for mobile, it will be alot less processing work for it's little CPU and GPU (if it has one).

If u read tutorials and fiddle with the settings and keep exporting, then you'll understand what works and what doesn't, then you should get fast frame-rates on mobile.

Arima, so how's C2 performing now with the recent updates, is it working on Vista? (I hadn't seen this discussed anywhere since the update has come out.)

— - I'm afraid it's not working any better on vista - I'm still getting software rendering with both node WebKit's preview and export.

For some reason it seems to be ignoring the --ignore-gpu-blacklist flag in the package.json and package-preview.json files (the flag was actually missing in the package.json file, adding it didn't help). If I create a shortcut to the NW.exe in the construct 2/exporters/html5/node-webkit/win32 directory and add --ignore-gpu-blacklist to the target, run it, then put in the preview address into the address bar, then the framerate is smooth.

Running from a modified shortcut is the only way I've found to get it to work, but that's not a reliable method if the user decides to launch the exe directly. Maybe it's a bug in node webkit itself.

Arima - huh, that's odd. Can you post that info to the bugs forum so I don't forget?

Yep, will do.

I don't really post around here anymore, but i have been using construct continually since all those years back when classic was starting out.

As it stands i don't see myself using C2 very often compared to CC, even though its a way superior tool to classic in terms of stability. C2 has definitely improved a TON since it started out, things with more complexity than a few events and some behaviors actually end up working quite well on desktop, yet it falls short in so many areas because it's held back by trying to achieve what classic did in a webpage. The whole advantage of doing everything in html5 for C2 was to make the games work on as wide a range of platforms as possible, and yet in trying to use html5 as a catchall C2 games end up working from my experience okay-to-well on desktop and shoddily everywhere else. I feel like in choosing html5 C2 has become a jack of all trades and master of none. Its a bit frustrating coming from an experienced background using Classic that the successor to it still hasn't surpassed it at making games that run natively. In fact it's honestly nowhere close as long as its using html5, with all the overhead that comes with using html5 vs the performance a native game using opengl/directX would have.

I'm not trying to hate on C2, its a fantastic program and i do end up using it because having a game that runs everywhere is a beautiful thing. But its disappointing that html5, and not C2 is whats limiting me. With CC i could literally look at ANY 2D game, and even simple 3D ones and understand that it would be plausible to make a large portion of them exactly as they were using CC alone. With C2 i see a game and though building it is possible getting the performance you'd expect on modern hardware isn't.

I don't really know the details of how C2 is designed, but i just wish it could export native games that used SDL with opengl, or something similar, so that games that take advantage of modern hardware could finally be made using it, rather than what a lot of people see as a novelty in making their games run in browsers.

A lot of people, i'd even say the majority, use tools like construct/gamemaker/multimedia-fusion etc. because they want to make their "dream" game, not because they want to make their game as marketable and cross platform as possible. It's a hobby, and i think enabling people to make their game as big and complicated as they want within the scope of current hardware, rather than force them into cutting back so many features modern hardware would allow, makes C2 a lot less appealing to a lot of users. I think this is pretty evident in the way the old user-base was essentially alienated with the new goals scirra had in making C2 from its inception to when CC was retired. A lot of people didn't leave because we got tired and stopped using the software, its just C2 didn't fill our needs and still hasn't.