Compiling into diferent files

New releases and general discussions.

Post » Mon Jun 29, 2009 11:28 pm

When compiling Construct builds a unique EXE. I twould be great to be able to create diferent kind os datastoring files... for example:

Graphics.data (would contain all the pictures and graphics)
Audio.data (sounds and music)
Game.data (all the rest)

the exe file would be only a linking file... for instance.

... this would turn the exe file smaller and the project would also be more organized. Maybe it is nothing important... but load times would be shorter because... only the needed graphics would be loaded from file, and RAM would be spared (or so I think) :)
(this was also anonther way to protect the game data... I'm seeing game where the sounds stay in a folder... and can be easly obtained)
B
2
G
4
Posts: 17
Reputation: 1,084

Post » Mon Jun 29, 2009 11:50 pm

You can already load graphic, and sound resources externally, and have access to store in .ini for game data.
Image Image
B
161
S
48
G
90
Posts: 7,356
Reputation: 66,767

Post » Tue Jun 30, 2009 12:09 am

Currently all the data is just embedded to the EXE. Using external data files would not make the total amount of data you need to send out smaller, it wouldn't be faster, either, and I doubt it would save memory. So I don't see much reason to do this I'm afraid :P
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Tue Jun 30, 2009 2:26 am

With external data sources it allows modification of game data without the need to recompile the entire EXE... super useful for pipeline development with umm... everbody else in the world. From a data-protection and project perspective its useful to have a out-of-the-box storage option like this that artists can use asynchronously from coders to add data like big background images, music, videos, other misc stuff to a project without the need to make a 400mb project file that takes 30 minutes to save/recompile.

Yes - I understand its possible to store that data in its individual files and use INI's in a folder but it is "Cleaner" to have it in a protect-able archive with easy access via Construct. My suggestion is to modify the ZIP object to be able to extract/import files from a password protected ZIP - solves everybody's woes on this one.
B
2
G
3
Posts: 43
Reputation: 936

Post » Tue Jun 30, 2009 7:13 am

I think this is good idea though I already store levels,music and sounds externally. But those who aren't familiar with INI's it would be easier to add new levels without having to compile everything well it would be easier to patch games and add new stuff.
B
11
S
3
G
4
Posts: 622
Reputation: 3,186

Post » Thu Jul 02, 2009 7:54 am

zip password support would be nice :)
at least for decompression
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

Post » Sat Oct 17, 2009 11:34 am

I just wanted to add my support for this kind of system.

As Construct doesnt seem to have any kind of patch system for bug-patching finished projects (correct me if Im wrong) it would be smart to keep the .exe file size as low as possible to reduce download-time for users. At the same time, I would rather not have all graphics spread out in folders, I want them to feel safe in a file somewhere.

Also, it would be great if you could have "families" for your graphics, so that at a layout start up you could tell the game to load a certain family file, and all its graphics gets loaded, like, you know, "load snowy landscape tileset" and such.

Basically, you import you graphics, give it a family name, a file is created which stores every graphics of that family in that file, and then you would load the family at layout start up. Wouldnt that be handy? 8)
B
2
G
3
Posts: 15
Reputation: 880

Post » Sat Oct 17, 2009 3:58 pm

This would be ideal. A group could work on a project much more easily. Say for example your Music/Sound guy gave you placeholder sounds that are not final in anyway. Now lets say the person maintaining the project goes away and the sound guy wants to update these sounds and he does not have the *.cap. How will he test these new sounds without recompiling? In short, he can't.

If we had archives of files, INSTEAD of in folder (the folder method I really don't like due to scum stealing art/music/sounds) it would not only allow people to work on the game much more easily (if there was some type of encryption). But also prevent some what I call "script kiddies" from using your hard work elsewhere.


The *.exe should be as small as possible in my opinion.

Jeff
B
3
G
3
Posts: 42
Reputation: 959


Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 5 guests