You can try the Greenworks Redraw plugin. To use the plugin, you just have to call a function at the project start. I know you're not using Greenworks, but it solves a similar-sounding graphical glitch caused by the Steam overlay.

I assume you added some Chromium arguments to your package json file (if not, see "The Big NW.js roundup thread" - some of these are important for Steam releases). If the redraw plugin above doesn't work, try reordering your arguments - for older versions of NW especially, arguments later down the list aren't reliably enforced.

The C2 business license is only required after you break $5000 in sales, so depending on the success of your game, you might not need it.

But if you do need it... you would be in a difficult position. You could contact one of the Scirra team - maybe they'll let you pay for an appropriate C3 business license as a substitute, or maybe they'll waive the C2 business license just for your case. They'll probably just suggest upgrading, though.

If you have to upgrade, then for an average-sized game without third-party plugins or add-ons, the transition is usually fairly smooth. There are a couple of guides like this one that give indications of things you'll need to watch out for.

This is doubtful, the engine/editor is identical.

Scirra have made the C2-C3 transition very smooth, but every engine has its own unique quirks and surprises. The runtime is different. The texture packing is different. The handling of dynamically created objects is different. I'm not familiar with any of this, so of course I'm going to encounter bugs that will take me a while to solve.

Also just knowing that they won't be supporting it is scary as hell. Like what if Windows adds something that breaks it? or an exporter breaks? I would not take that chance. It's already scary using 3rd party plugins on a supported engine!

That's a valid fear, but realistically Windows is pretty stable. Still, if such a thing does happen... then I'll just port the project to C3. After all, that's still an option after July.

I started my current project back when C3 still had some teething issues. Now, several years on, my project is nearly finished and C3 looks quite robust. It's been super tempting to jump ship recently, mostly for the improved runtime, but also for little features and that could have saved me development time. It's like, oh, NOW there's pseudo-3D support, lol.

But ultimately, I think I prefer working with an older engine I'm very familiar with than a newer one I'm not. If I encounter a weird bug in C2, I immediately know what caused it and how to fix it. If I encounter a weird bug in C3, I'll probably have to spend days trying to diagnose it.

Not to get sentimental, but there's also a certain grace to using old, familiar tools. It's like having a favourite pair of socks... you know you should throw them out because they're starting to get full of holes, but you're attached, you're comfortable, and you almost feel empowered by them. I wonder if that's how the Iconoclasts developers felt with using Construct Classic in 2018.

Maybe I'll jump ship next year.

I don't know if I'd say obsolete, but it does seem like HTML5-to-mobile wrappers are a dying scene. It would be a lot less effort to use C3's mobile export options. If you prefer working with C2, then one option is to keep working in C2 but just use C3 for exporting.

Exported sprites and textures are grouped together in larger spritesheets to save memory. They're packed in power-of-two square image sizes (i.e. 128x128, 256x256 etc.) because that's how many systems store and process images. This means that a spritesheet could have a large empty space, which might appear inefficient, but in actuality it would be more memory efficient than keeping the sprites separate.

Unless you're using a lot of ENORMOUS sprites or particular custom GL effects, it shouldn't cause any issues.

So far, I haven't experienced a crash since updating.

Also, the lack of object refreshing after closing an animations window is a god-send for larger projects - I always assumed it was just a quirk of Construct that I had to live with.

It could be memory related. For me, my project with 107MB memory usage seemingly doesn't crash, but my project with 167MB memory usage does.

Just to throw in my lot:

I have been experiencing this problem, usually after I close the sprite editor or soon after saving. I am using r268, 64 bit build. I do not have autosave turned on.

However, I think the problem went away since I put all of my objects into folders (i.e. so they are not loose on the projects sidebar). I'll keep an eye out in case I'm way off base, but my wild guess is that this problem is being caused by too many objects on-screen in the projects sidebar, maybe due to a bug in the new version of the 3rd party UI library Ashley referenced.

For other people experiencing the crash, it might be helpful to know if you also have a cluttered projects sidebar.

Thanks all! Looks like I'll be developing this for the next couple of years!

ᕕ( ᐛ )ᕗ

Thanks, all.

My only critique would be to add more animation frames for Verm and other characters. Your art is so good, that it was marred by too little # of frames, making the walking animations not smooth and too fast/slow for their movements. (but maybe this was because of the itch.io limitations?)

My other minor critique would be to have the movement obstacles (or walls) more smooth. It didn't feel good moving Verm around corners, sometimes he would get stuck.. it didn't feel like good movement. Getting 'caught' on an edge is what I am talking about. Since it's not a platformer it should be really smooth movement.

Good points. I had to stop polishing the demo (otherwise I would have been working on it forever), but I will go back and improve these things once I've produced some more content.

Also seems like a very ambitious project if you are to end up delivering a full game. The amount you will have to implement seems really intimidating! you probably need to put in up to 8-10 hours of gameplay?? or more?

Actually, 8-10 hours is exactly what I'm aiming for. It is an intimidating amount of work, especially since I've committed to not padding it out with random battles, but I've got a good grasp on my work speed. Another 2 years of development should be about right to see the game through to completion.

Here's a demo to an RPG that I've been working on for the last year or so:

sketchylogic.itch.io/small-saga

The final game will eventually be a downloadable exe, but I wanted the demo to be playable online to maximise the number of people who would be willing to play it. Here were some unique challenges I had with making an online demo version:

1. Streamed music files wouldn't play consistently, so I had to make all of the game's music pre-loaded sounds. Not ideal, but it worked.

2. Itch.io has a 500 file limit for online games, although apparently this can be increased if you ask nicely. My demo was pushing this limit, which meant I had to get rid of a lot of superfluous assets. Anyone hoping to make an enormous online game for itch.io should be wary of this limit.

3. Some players turn off hardware acceleration in Chrome for screencapturing purposes, but this effectively disables WebGL. So I had to put in an "if effects enabled" check to give those people an error message that instructed them to try another browser, turn on WebGL, or download an exe version.

4. My dialog system works with text files loaded with AJAX, but I switched to just using giant global strings to remove the possibility of the dialog breaking for someone with a bad Internet connection.