Project file size affect runtime?

I have made a project see. A very simple one I guess, but its already around 130+mb due to uhh you know, too many objects in it, cuz I used so many sprites like monsters, people, etc. And when I test run it, it takes too long to load the preview which usually ends up not responding.

So what should be the average file size of Construct games? Oh yeah, I have a little question or just want a clarification. In a finished project, will the only thing a user will download is the .exe file? Or can there be folders included in it, which I guess is a Sound Folder or Data folder. But is there any other? Will the whole game be comprised in one .EXE file?

Under normal circumstances, yes the game will be just one .exe file. You can however load sounds and graphics at runtime from folders if you like.

Also, there is really no set file size limit. Obviously you need to keep in mind system limitations, and whether or not someone is going to be willing to download a 130MB game, etc. You may want to check into some optimization:

• Don't import large graphics if you're just going to scale them down in-game. Import everything at 1:1 ratio
• Trim any excess from around the edges of your images. Also keep in mind the power-up rule... if your image isn't sized at a power of 2 then it's going to be scaled up in VRAM. If you have a 34x36 sprite, it's going to be taking up 64x64 in VRAM... so perhaps you could find a way to just redraw that sprite at 32x32?
• Compress your sounds! A lot of people skip this one. Make sure all of your sounds have decent compression on them, and that all blank space is trimmed up. Some people think they need the best sound quality at 44100Hz sampling rate when they could easily get away with 22050Hz. Don't use WAV whenever possible
• Are you using tiles wisely? Can you break up any large images into smaller components that you can use as building blocks? And no I don't mean just cut up large images into squares. I mean is there, say, a tree in your image that repeats multiple times? If so, why not just make a single tree sprite and paste a bunch of copies?

Check out more optimization tips on the wiki:

http://sourceforge.net/apps/mediawiki/c ... ation_tips

However there may be an issue with VRAM and resources not loading properly on a layout to layout basis, but somehow loading all at once, which could be more noticeable with large projects. Kayin discovered it, and David was looking into it. I'm not sure what all the details are yet.

Since I am working on an RPG that will exceed 100 frames, I simply created a method of multiple EXE's for easier development (less lag while working on the game) so let's say, every 10 frames there's a special "portal"...

First, copy the first exe you have(excluding the start menu and stuff like that, so like, gameplay only), call it whatever you like

Then make a global variable, let's call it "areaname", and set the value of it to what you named the second EXE.

If Player overlaps portal:

Array: Set value at X 1 : portal.value('whichapp')

File object: execute file: AppPath+portal.value('whichapp')

System: close application

Now, just to make sure the player simply hasn't double clicked on the next area...

Start of frame:

Array: load from file

Array compare value at X 1: is NOT equal to global('areaname')

System : close

And if the player just clicked on "continue game":

File object: execute file: AppPath+portal.value('whichapp')

System: close application

Well... It works for me.

Lemme know if there's anything that doesn't make sense .

Edit : just remember this is extremely simplified, you will also have to save/load things like player values, which frame he is on, and things like that.

Stuff

That's... a rather extreme method of doing things. And not something that I would recommend for the average game.

Jut keep your game tidy and optimized. If you have a very large game then you may want to look into loading graphics at runtime and using a level editor to make map files that you can also load at runtime. That will keep your .exe nice and trim.

If Player overlaps portal:

Array: Set value at X 1 : portal.value('whichapp')

File object: execute file: AppPath+portal.value('whichapp')

System: close application

I... em... uh.... please don't.

please. That's hideous.

Oh haha, by frames, I meant layouts .

Wait, I can load graphics from folders? Does that include sprites I use in the game? Like people and monsters? My game is pretty much an RPG with a card game in it much like Digimon Digital Card Game. Would it had been better for Construct to like, once building the .exe is done, it would export all objects used in a I dunno Objects Folder? and then all that would remain in the .exe is the events or something which would probably cause it to be less than 1mb just like those other .exe that other games use. The .exe would just read the stuff in the Object Folder and show in at runtime. I think this kind of algorithm is seen in the RPG maker series.

Normally, games would have their .exe to be less than 1mb or so.