Memory planning

dogfish

New here, working on first game. Learning about memory at moment, as it will dictate how I approach levels.
I have mined the forums, wikipedia, etc as much as possible.

Bear with me please:
My game will have 72 levels, Block-pusher (Boxed-In) genre.
So far I have one level menu page, with 6 images loaded (12 levels each). In ImageOptim each image is ~130kb.
When I "page left/right" I switch the levels actor's image to the next image.
So when I load up viewer, it starts with Images: 4.5mb, then increases by 4mb each time a new image is loaded (level page change).
BTW,
Game Engine: 1.3MB
Other: 11.5MB
Total: 17.2MB.

a) How does ~130kb translate to 4mb?
b) What does that "Images: xMB" value represent; RAM?
c) What should my ceiling on that value, (and the other 3 viewer values), be?
d) How does that relate to the 20MB 3G cap (or modern equivalent)

My concern is that I'll be bringing in 72 more background images, at 4MB a pop is 288MB.
It involves lots of ladders and tubes, etc so that is the easiest to do, but if necessary I can go these routes:
Make the ladders, wall-blocks, etc into actors, and reposition them for each level.
Rework the back-ground artwork to be PNG-8 graphics (although not sure how to do that at moment with InkScape).

Thank you for answering my questions; I promise my puzzle/game design is clever as hell and will make you all proud.
But if it doesn't fit, I must acquit! *sigh*

Dogfish

dogfish

Edit: Discovered ImageAlpha, converted a typical level background image from ~140kb to ~32kb (with acceptable result quality).
So now I'm looking at 32kb*(72 levels) = 2.3MB of some form of memory dedicated to my large images.

Until I understand questions a-d above, I have no idea if I will be in acceptable publishing ranges.

Again, thanks in advance.

dF

MotherHoose

good that you found imageAlpha, and use imageOptim!

a) How does ~130kb translate to 4mb?

a lot of the image: xMB's size is in the the project's screenshot Folder … you can delete all but one of them when you finish your build, if your project is large; or delete them all when you receive your app from GS (keep the folder : delete the images)

b) What does that "Images: xMB" value represent; RAM?

what else? the app elements when opened are stored in RAM

c) What should my ceiling on that value, (and the other 3 viewer values), be?

whatever your game requires -- provided you have optimized everything!

- unchecked Preload Art attribute in all actors (where applicable)
- unchecked/edited the Physics properties in actors (where applicable)
-- static actors do not need Density/Friction/Restitution or Moveable (Interpolate and Collision actors do need this …)

d) How does that relate to the 20MB 3G cap (or modern equivalent)

the 20MB 3G cap only applies if the 3G device is currently using a phone carrier … i.e. it is maximum data transfer size allowed by the phone company – not Apple or the device; larger-size apps purchases are valid; and, the download is a available when connection with a computer is established.

recently, some were complaining about GS Publish not accepting projects >150MB.

ah … @dogfish your GS application is smaller than the project size. Work on your game; optimize when you have the work done.

MH

dogfish

Thank you MotherHoose. So I should not worry about that massive "Image xMB" value, and just worry about project size? With six PNG-24 images my project only shows 1.1MB; If I brought in 72 additional non-compressed level images I'd be around 15MB project size, so I guess I'll be good, and definitely will be ok if I end up having to convert them to PNG-8. In other words I don't want any limitations imposed by apple, at&t, god, to restrict people from buying my game if I don't have to!

Good luck to everyone submitting games for the holiday season!
dF