Question - Code Using Zip / UnZip to Overwrite Rooms / Objects / Sprites

[Aaron Stez]

Basically i created 3 games, with the same object code and names.

Now I want to package it into one app which will access all 3.

Eg. Game A, Game B and Game C

Game A is loaded by default, Game B and Game C are zipped.

If the user selects Game B, I want it to unzip and overwrite Game A files. All rooms, objects, sounds etc have the same name.

Is this possible?

 

[Homunculus]

What do you mean by "overwrite game A files"? Included files? Or you want essentially the same game but with different assets?

Either way, that's not possible. Rooms for example don't really exist as a file when the game is compiled, and even if that wasn't the case since games are sandboxed, they can't access files outside of their own sandbox.

If you tell us what your goal is maybe we can give you a better solution

 

[Aaron Stez]

I want the same game but with different assets. I would need it to replace Rooms / Sprites / Sounds

What do you mean by "overwrite game A files"? Included files? Or you want essentially the same game but with different assets?

Either way, that's not possible. Rooms for example don't really exist as a file when the game is compiled, and even if that wasn't the case since games are sandboxed, they can't access files outside of their own sandbox.

If you tell us what your goal is maybe we can give you a better solution

 

[Homunculus]

As said, you can't replace game assets like that in a compiled game. You have a few options though to achieve the same result:

1. Load the assets externally
With the exception of rooms, you can have all your sprites as included files and load the right ones at game start using sprite_add etc... depending on the player choice. This does have an impact on performance, a big one I suspect, due to assets being on different texture pages. Can't really say if it's viable, probably depends on the scale of the game. Also, rooms can't be loaded this way, so you'll probably need your own room loading from file

2. Just have all of your assets directly into a single game, and only use the appropriate ones depending on the player selection at runtime. This seems to be the best option to me, since you can reuse all the common assets and code, and using parenting and a few conditions you can avoid having three completely different codebases to maintain. It's probably not that big of a deal to have a lot of unused stuff in your game.

I can't see ANY advantage of having three executables, but you didn't really give us any details, so...

 

[Aaron Stez]

My Games are Hidden Object Games, with 100 Levels - So performance is not an issue, but file size is...

The base code is same.

What Changes in the 3 Games -

1. Sprites,
2. BG,
3. 3 Sounds,
4. Object Position in Room (Objects are already placed in the room and they get their X,Y from there)

I have managed to load Sprites and BG from Included files.


I am having trouble with Rooms, since all the objects are placed in the room and that is where they get their position from.

I am trying to avoid re-writing code where i define X and Y in a saved file as that would be extremely time consuming for 12,000 objects.

As said, you can't replace game assets like that in a compiled game. You have a few options though to achieve the same result:

1. Load the assets externally
With the exception of rooms, you can have all your sprites as included files and load the right ones at game start using sprite_add etc... depending on the player choice. This does have an impact on performance, a big one I suspect, due to assets being on different texture pages. Can't really say if it's viable, probably depends on the scale of the game. Also, rooms can't be loaded this way, so you'll probably need your own room loading from file

2. Just have all of your assets directly into a single game, and only use the appropriate ones depending on the player selection at runtime. This seems to be the best option to me, since you can reuse all the common assets and code, and using parenting and a few conditions you can avoid having three completely different codebases to maintain. It's probably not that big of a deal to have a lot of unused stuff in your game.

I can't see ANY advantage of having three executables, but you didn't really give us any details, so...

 

[Homunculus]

I can't see the size being a problem if your plan was to ship all three versions of the game anyways. You can split the assets all you want but the total size is the same.

For the rooms, if using GMS2 you could take advantage of room inheritance, where you setup a parent room with all the common properties and define child rooms with just the differences for each version of your game. At runtime, you just select the correct room versions out of the three child rooms.