This seems like a pretty GPU intensive way of getting the effect of just some animated squares. With some ingenuity I think you could do away with the Pixellate effect entirely and take a different approach.

What about using a simple looping, repeatable animated sprite of changing squares. You could do various programmatic things to make it seem more 'random' (picking random frames every so often, or periodically flipping / rotating the sprites...)

Or a tiled background that (while it can't be animated as such) could be given the illusion of 'animation' with some event based methods similar to that which I mentioned above.

This would make it much easier to have the flowing lava follow the screen properly and also make your game much more performant on slower machines.

Do they have the same origin point settings?

Makes sense! Glad you got it working :)

I would just use the sprites themselves. It's fewer objects for you to keep track of and means using fewer objects at runtime. I'd recommend deciding for yourself which part you will treat as the 'main' part and making all of the other parts follow its lead. Otherwise you might get confused later if you're mixing and matching which things you're comparing to which other things.

Eg. you might do it so the head controls everything. Hits on the body affect the health stored in the head, the head stores the current behaviour state for all parts, the body always inherits scaling from what the head is doing, etc.

Family instance variables mean that each object in the Family has its own version of that instance variable.

Like, the Family has a Health variable. But if you shoot the head, only the head loses Health - not every object in the family. The body has a different Health value that isn't affected.

You could use containers for this. If you put the objects into a container together, you could have it so that their health values always match. Or that a hit on the body always takes Health off the head, and then you can scale them both based on the head's value.

I agree that that hiding important buttons behind an extra click may be a bit of a UX downgrade, but honestly, it's not that hard to find.

There are multiple ways to access it, anyway:

You can open the dropdown arrow next to the Play icon and choose "Debug layout".

Or you can press Menu > Project > Debug.

Shift+f4 launches Debug for the first layout.

Shift+f5 launches Debug for the current layout.

It kind of sounds a little like you want Scirra to redesign their interface just because you don't want to learn where the new button is?

Thanks for the thoughts guys. Really appreciate it. I'll definitely look into this more. nyuszi008 I think you are right that I really only need to update package.nw / app.nw for my purposes.

Also I wonder if I could make the game app so that it is basically a nw.js wrapper that loads the game via an online upload? Like if I just hosted it at mysite.com and the .exe really just runs a window that visits mysite.com. (There are a couple of reasons why I wouldn't want to do that I guess - for one it would be slow, for two it would presumably be accessible to anyone who just visited mysite.com... hmmm. Just kicking ideas around)

There's a few ways I could approach this so I will need to have a think about balancing my ease of publishing each update on the dev end, and the ease of receiving updates on the player end 🤔

Thanks again everyone.

The same guy has given a couple of really good GDC talks about how to make effective trailers, too:

https://www.youtube.com/watch?v=nVeihUFtEkg&ab_channel=GDC

https://www.youtube.com/watch?v=QWd7F0z1W_Y&ab_channel=GDC

🙂

Yeah, it sounds simple, but when you start picking at the idea...

First of all, won't the game have to essentially delete itself to replace its own files with the updates? Will that affect the user experience (eg. the app suddenly just auto-closes and must be rebooted ??).

I figured for a nw.js thing you might be able to just download some pieces of it (eg. just the new JS files and some new PNG assets, etc). But that might be tricky on Mac, where all of the project bits are "inside" the application itself. So I don't know if that would work.

Maybe it would be better to make a launcher program that checks for updates and then runs the game?

Or maybe the simplest thing is (despite saying I didn't want to be on Steam or whatever) to find a distribution platform after all that would handle updates for me. I hate using Steam's publishing interface but I guess from the user's point of view that might be the most seamless way to receive app updates. 🤔

Anyway, the game in question won't be done for a while yet so I have some time to mull it over. Still very much open to ideas and suggestions!