Mods are difficult for Construct Games (SOLVED!)

Heyo! I submitted a suggestion and i would appreciate if y'all could have a look and perhaps upvote it. If the suggestion gets implemented, it would be an incredible step forward for modding construct games.

construct23.ideas.aha.io/ideas/C23-I-465

If y'all want to discuss the merits of this or suggest existing solutions, I'm all ears!

When exporting your project using Construct 3, the engine automatically merges art assets into shared sheets for memory considerations. That is nice except when you want to encourage modding in your game.

Modders will want to replace Shared-Sheet2.png with their art. That's all fine and good. But what happens if the developer releases an update that adds a single image into the project? It will likely break all the mods for the game.

This is because the engine will re-combine the art assets in the project into sheets without honouring the previous sheets. This causes a cascade of changes where nearly every sheet is a different art asset and mods that reference Shared-Sheet2.png are no longer referencing the same part of the game's art.

Currently, the only way to have users swap out the same sprite art across multiple versions is to give them access to the construct file and have them compile the game themselves. This isn't ideal. A simple boolean that disables the Shared-Sheet generation would be a saviour in this respect.

You can load sprite images from a URL which might work better. That bypasses the whole spritesheeting system.

You can load sprite images from a URL which might work better. That bypasses the whole spritesheeting system.

Not every object that has art in a construct project has the capacity to load from URL

It's also considerably more messy to have essentially two copies of every image in the project. One in a local folder (for modding) and the original in the image folder. Which also includes the annoyance of teaching the players to mod the modding folder images instead of the other images. And, not to mention, a ton of refactoring to a project that has hundreds of sprites and tiled bgs, and so on

On the topic of mod support, I think C3 is excellent for this as it stands, but I do wonder if there could be just a few bits extra (I say "just a few bits", but probably enormous work behind adding such things), probably need to add a suggestion.

Exposing extra bits to allow things such as, adding/removing animation frames, adding animations, adding/removing/setting/getting the collision polygon, setting origin point x and y, adding image points.

Also keeping consistency with all objects, so SpriteFont could use Load from URL and allow more exposure to other parts of SpriteFont via events so we can essentially have fully-customised fonts. Particle object could benefit from Load from URL too, whilst we do have sprite option for particles, we lose the performance gains by doing this.

One extremely important addition would be having the option to load unique images for a sprite, perhaps a good method could be having a new action like "use image set" and then pass a name, so then we could have hundreds of externally-loaded objects into the game without having to workaround everything or have 100 empty sprites to load images into. I don't see this as straightforward, as, if you had more frames for a mod, then how to determine this with a "use image set" action... Maybe a "Mimic image data from other sprite" action... Who knows, there's probably a good idea here somewhere.

This can all be technically worked around but it's an enormous amount of work that doesn't utilise C3's excellent tools such as the animation system and image points and such (e.g. You can make your own origin point system via events and such even with rotation around the image point, can use collision polygon from a mesh although very tricky since you can't have a mesh with just an "outline" of points).

I agree that those things would be a huge benefit, but I would be enormously grateful for merely disabling the automatic atlas creation when exporting. That would at least allow the users to change all that stuff manually and for it to not get lost across tiny version differences in the game.

I don't think it's a simple thing to just turn off spritesheets. Spritesheets are always power-of-two sized, and while WebGL 2+ supports non-power-of-two texture sizes, WebGL 1 does not. There's still enough WebGL 1 systems out there that I think if it just exported a bunch of non-power-of-two individal images then your game will be broken on a small percentage of systems, but enough that you'll get a lot of "game doesn't work" reports.

Then there's other issues like larger games losing the benefits of spritesheets could become significantly larger to download and significantly slower to load, and have a runtime performance hit too. It could be a massive deoptimisation for your game that slows things down even for players who don't want to mod anything and just play the stock game, which I think is an unfortunate trade-off.

Perhaps some of that can be mitigated in various ways, but it's complicated. Modding is a very large area if you want to go further to adding new kinds of objects, changing game logic, adding new kinds of level themes, etc. as well. I fear this may be one of these areas people say "just add A!" then "just add B!" then "just add C!" and then on for another 20 things over months/years.

Fair enough! I'll admit it's already possible for me to offer a set of in-game tools to the player to inject their own custom art and music and have those changes propagate through the game. I consider it a big hassle, but i guess turning off spritesheeting is equally or moreso a big hassle for Scirra.

Oh btw, to address your concerns with larger projects being slowed down by disabling spritesheeting; my suggestion was to have a bool in the export options to enable or disable based on the preferences of the developer. With enabled being the default option of course :)

my suggestion was to have a bool in the export options to enable or disable based on the preferences of the developer.

My point still applies. If the developer chooses to turn it off, then players of that game who aren't interested in modding still get a potentially big performance hit, which seems a shame for them.

Very very interesting!

So, assuming someone plays with webgl1, if you have a game with a LOT of load image from url, is there a likely performance impact? I prob need to force webgl1 and measure.

I'm curious what load image from url does under the hood - I presume it kinda tells the C3 runtime "hey, this specific frame of this specific animation must display this single image file". I assume this means the image that we get from load image from url is not somehow injected into a power of 2 image (or maybe it does?).

Does it matter if you change 10,100,1000, or 10000 images like this? I'm very interested in making projects that rely on EVERYTHING being loaded via url externally (making it easy for me to expand the project with extra content, as well as modders), so good to plan ahead accordingly!

Definitely need to measure but still just curious overall.

Thanks as always for the very descriptive explanation, Ashley!

As per the latest change to the beta cycle: the spritesheets have an option to be disabled! This is amazing. Thanks a ton for Ashley's hard work and ear to the community.

Now all thats left is to showcase this fantastic functionality to our players! I'll post if anything cool becomes of it