ENIGMA Forums

Outsourcing saves money => Issues Help Desk => Topic started by: Wendigo on June 04, 2018, 02:30:52 am

Title: Keeping assets outside of executable
Post by: Wendigo on June 04, 2018, 02:30:52 am
Hi community,
When I compile a game it seams that all the assets get compiled into the executable file as well. Since Enigma is GPL software I'm a little concerned about the use of third party assets under proprietary license within the Enigma game engine.
The Blender Game Engine (which is also GPL software) also packages all the assets into the executable by default but you are able to prevent assets from becoming GPL licensed this way by putting them into a separate folder and telling the game engine to read the images, sounds etc. from there.
Is it possible to do something similar with Enigma?
Title: Re: Keeping assets outside of executable
Post by: time-killer-games on June 05, 2018, 12:05:51 am
You can load sprite and background images externally, as well as audio sound resources. Make sure you free them from memory when no longer used, like described in the GameMaker Studio docs for each function.

sprite_add: https://docs.yoyogames.com/source/dadiospice/002_reference/game%20assets/sprites/sprite_add.html

sprite_replace: https://docs.yoyogames.com/source/dadiospice/002_reference/game%20assets/sprites/sprite_replace.html

background_add: https://docs.yoyogames.com/source/dadiospice/002_reference/game%20assets/backgrounds/background_add.html

background_replace: https://docs.yoyogames.com/source/dadiospice/002_reference/game%20assets/backgrounds/background_replace.html

sound_add: https://docs.yoyogames.com/source/dadiospice/002_reference/game%20assets/sounds/legacy%20sound/sound_add.html

sound_replace: https://docs.yoyogames.com/source/dadiospice/002_reference/game%20assets/sounds/legacy%20sound/sound_replace.html

audio_create_stream: https://docs.yoyogames.com/source/dadiospice/002_reference/game%20assets/sounds/audio_create_stream.html
Title: Re: Keeping assets outside of executable
Post by: Wendigo on June 05, 2018, 01:20:46 am
Thank you for the links TKG.
The descriptions of the "*_replace" functions state that "You can not use one from the resource tree as you cannot replace built-in assets.". So in other words when using those functions I wouldn't be able to use the object and room editor and to do everything via code since the assets created within the IDE are forbidden then.
I wonder if Enigma works the same way as GM here.

EDIT:
I made a small test project and it looks like Enigma indeed supports replacing sprites created within the IDE (haven't tested other assets jet). When I call sprite_replace from within the create event of the object the sprite gets replaced by the one from the given path.
Now I would need to find a way to get rid of all the sprites and sound files at once right before the game is getting compiled.
(or to be more precise - replace them with a dummy image since a sprite without an image causes a compilation error)
Title: Re: Keeping assets outside of executable
Post by: time-killer-games on June 05, 2018, 03:40:47 am
Or, you could use the dummy images within the project and replace those at runtime with your external assets. Just an idea.
Title: Re: Keeping assets outside of executable
Post by: rcobra on June 05, 2018, 05:20:33 am
look at this https://youtu.be/nx0BsnjO1rA
Title: Re: Keeping assets outside of executable
Post by: Wendigo on June 06, 2018, 01:54:19 am
Thank you for the video, rcobra.
Unfortunately that approach degrades the game engine to a mere game framework since you can't really use the the room editor anymore and need to keep track of the assets by hand without a visual representation of them inside the IDE.

The sprite_replace function seams to be more user friendly since you can just create some dummy assets in the shape of the collision mask and build your level with these. The dummies get replaced on compile time and you can test play the game in all it's glory. The only problem with that is the double file size of the game since the assets exist twice.
(I have added my test project to this post)

The ideal solution would be an option in the project settings that enables automatically copying the assets in separate folders and pointing the paths to that location when the game compiles.
So let's call it a feature request maybe.  ;) 
Title: Re: Keeping assets outside of executable
Post by: Goombert on June 06, 2018, 04:01:03 am
These guys are right on the money with their advice Wendigo. ENIGMA does support replacing resources that are from the IDE, just like old GM. We will continue to support this for the foreseeable future, even with RadialGM, as there is no reason not to and I'm not really sure why they don't. We also have a secret feature we would like to do that's related to this but are not saying anything yet.

I am not exactly sure I understand the issue here though. You really do not need to concern yourself with the licensing of the engine, because we will work out an exception, the only reason we haven't yet is out of fear of what happened to the WINE project basically. I believe this discussion is actually about GPL-licensed assets, as in, just the sound/image data. I am not too familiar with the restrictions of this myself, but I find it surprising that you would need to externalize the assets just as you would code.

Quote from: Wendigo
Unfortunately that approach degrades the game engine to a mere game framework since you can't really use the the room editor anymore and need to keep track of the assets by hand without a visual representation of them inside the IDE.
Yeah, some of the secret stuff we have may address exactly this, if we can pull it off.

Quote from: Wendigo
The ideal solution would be an option in the project settings that enables automatically copying the assets in separate folders and pointing the paths to that location when the game compiles.
I see, thanks for raising these concerns, because they are relatively new to me and it helps to know what Blender does as well. We are changing a lot of stuff with emake/protos/RadialGM and are also planning to look at decoupling the asset compilation from code compilation, as GM itself does. With this accomplished, a checkbox to do exactly this would be extremely easy, but it's also related to our other secret feature.

One of ENIGMA's oldest open issues: https://github.com/enigma-dev/enigma-dev/issues/24
Is also related to this, because some people would like their resources not to be zlib compressed when attached to the executable.

I'll keep this in mind and also update everybody if we do get these features out.
Title: Re: Keeping assets outside of executable
Post by: Wendigo on June 07, 2018, 02:47:10 am
Now I'm getting even more excited about RadialGM and the new "Secret Feature".
What you wrote sounds really interesting.  ;D
I am not exactly sure I understand the issue here though. You really do not need to concern yourself with the licensing of the engine, because we will work out an exception, the only reason we haven't yet is out of fear of what happened to the WINE project basically.
I'm not concerned about the license of the engine. In a different thread it has already been made clear that none of the Enigma developers intends to sue Enigma users for not publishing the source.
What I'm talking about is the license of proprietary assets that can be bought in stores like from Scierra.com. Those licenses usually forbid to sub license the assets or distribute altered copies of the assets under a different license.
I am not a lawyer but as I see it the customers of my game that uses 3rd party assets might claim that bundling these together with a GPL engine runtime inside the same executable file puts them under GPL too. So if they ask for the sound and image files I couldn't give them away without breaking the license from the asset creator.
When the assets are not bundled within the executable one would be able to put the corresponding license file into the same folder as the images, sounds etc.
Furthermore If someone really could force me to release the source of the game I could simply exclude the assets as they have a different license. The source of a game without the images, sounds, music and videos is pretty useless so one could prevent others to just publish your game elsewhere for free since recreating the assets is a lot of work.
But with your exception to the GPL license in the pipe this will hopefully not be an issue anymore.

BTW: What happened to the WINE project?
Title: Re: Keeping assets outside of executable
Post by: time-killer-games on June 07, 2018, 04:25:27 am
Quote
BTW: What happened to the WINE project?

Crossover happened. A software which was created from WINE's source code, but being sold commercially and actually converts your Windows application into a Linux one.
Title: Re: Keeping assets outside of executable
Post by: Goombert on June 07, 2018, 01:36:58 pm
Yeah TKG is right again, and the WINE developers probably saw very little of that profit/growth/gain. This is actually Josh's concern, not originally mine, but it does concern me too. Basically, just imagine if a company like YoYoGames were to grow out of ENIGMA as opposed to having grown out of Mark Overmar's original project. I think a lot of people would probably hate that.

Quote from: Wendigo
Furthermore If someone really could force me to release the source of the game I could simply exclude the assets as they have a different license. The source of a game without the images, sounds, music and videos is pretty useless so one could prevent others to just publish your game elsewhere for free since recreating the assets is a lot of work.
Right, I think this is the source of my confusion. Because when you release your game your license should just state the license of the assets separate from the license of the code. I'm going to ask Josh, since he knows a little more, just how big of a concern this is.

Also, the secret feature is related to one of ENIGMA's oldest features that people have asked a lot about. So there's technically 3 features here, the one is basically the same as the zlib request except for everything, and the other is a much much more powerful feature.
Title: Re: Keeping assets outside of executable
Post by: Wendigo on June 08, 2018, 01:52:54 am
Yeah TKG is right again, and the WINE developers probably saw very little of that profit/growth/gain.
This may get a little off topic but I'm actually quite surprised that Crossover is seen as a negative example of what could happen to an open source project if it gets used by a company.
As far as i know CodeWeavers is one of the biggest contributors to WINE and even employs developers to work on WINE and push features upstream.
In the Linux gaming community this relationship is seen as a success story of how open source development can get funded. I guess WINE even has a way larger user base than Crossover.
Or maybe there was a conflict at the beginning that I'm not aware of.
Title: Re: Keeping assets outside of executable
Post by: Goombert on June 13, 2018, 01:18:04 am
Yeah, I totally get your point of view Wendigo, I don't have strong opinions on this. I think the ENIGMA case is unique though, just considering the history of YoYoGames, I can understand some of the concerns. I was just trying to provide context by sharing some views and perspectives I've heard on the matter.
Title: Re: Keeping assets outside of executable
Post by: Darkstar2 on July 18, 2018, 12:33:59 pm
I honestly cannot understand the whole concept of cramming all resources into the EXE.  I would never use such approach and I think it is good practice to use external resources.  If I have some time I will be working on my own personal project to build my own resource engine which will handle loading external resources from packed files, encrypted files, etc....similar to what is used in commercial games - and it is easier this way when you want to release updates to your games without having to distribute the whole bloody executable.

Of course if you want to use the room editor that comes with the IDE, that can be an issue of course, which is why I would be inclined to build my own room editor engine, and have code to generate the room :)