apk problem

[Pfaber11]

Just launched my latest game for android on itch.io and although it downloads when I try and install it it gets to about 80 % then says install failed . was thinking it may be due to the size of the file 114 mb  . https://pfaber11.itch.io/the-awesome-maze-game-2-android-edition
If that is the case what can I do about it . Thanks

It's ok fixed it and it was user error . I was trying to use a png file for the app icon .

[iWasAdam]

out of interest 114mb seems like a lot of very large data. I would have thought you should have a max of around 20mb for something like this?

[Pfaber11]

yes so would I for some reason the mazes took up 12 mb for the new ones an only half a meg or something for the recycled ones . Been working on this all day and eventually got it all working right . A little bigger than really needed I suppose . I'm done with mazes for now gonna try something else next .
By the way you do need a png file for the icon on the phone but I was using too big of one , settled for 256X256 in the end . I am now charging for all my games to see if I can earn a buck and if I do I'll let you know how I get on . Not expecting anything great but who knows . Maybe my next game will be a cash cow , I doubt it but you never know.

[Pfaber11]

Another problem I encountered was that I kept going through the walls of the maze on android but when the exact same program was run on the pc it was faultless . I tried every thing I could think of for more than a day to fix this . It was happening when I went into a wall then moved rapidly from left to right and forward at the same time . very annoying . I eventually got round this by making it so if left or right was pressed at the same time as move forward the object would not move at all. This worked fine and once you get used to it it was pretty much ok . Gonna start a new project after a small break .
   Happy coding . May the force be with you.

[Derron]

This sounds as if:
- your logic is faulty
- or you trust in collision detection and the android device runs less often so you have a check before the wall and the next is already on a valid coordinate again (the famous "bullet + thin wall" problem)

I think in a maze game you can skip collision checks and use simple tile based checks - so a faulty logic for now

also 100mb for (such) a maze game is too much in my opinion ... except you have a lot of big textures (for whatever reason). If I see such a game and it requires 100mb (btw: google play allowed 50mb once... as maximum) then I would ask the question what else is hidden in the application.
Instead of going on with the next game I would try to find out why the game became so big (music? gfx? duplicate data? debug builds?). a 12MB 3D model might mean you include the textures in the file - maybe some unused textures? If it was only a 12 MB "data" model (so only the vertices etc) then you might be way too high poly. Also such model stuff should compress well (an APK is compressed already).


bye
Ron

[iWasAdam]

ok, if we take the base maze as a grid - what grid size are you using?
assuming 1 byte for each grid and 32x32 for a level you would get 1k per level
64x64 = 4k
and 128x128 = 16k

generally 32x32 for a maze based level is a good size - more than that and the level just becomes a lot of corridors with no differences.

texturing could be a single texture or multiple textures - lets give (say) 128k-256k per texture

3d models (which should be lowish vertex resolution) should not be too high - lets give a max of 32k per model, with most around 2-4k

lets have 32 different 3d models.

So in total you should have a data size (without audio/music) of:
32 3d models x 32k = 1mb
12 levels at 32x32 = 1k x 12 = 12k
textures 12 x 128k = 1.5mb

which sort of gives (lets round up): 3mb
add 1mb for general graphics data - UI, etc
add 10mb for audio/music

Grand total is.... TADA: 24MB


So there you have it. if your install size is larger than 24mb - you need to look at where and what is eating the data and possibly rethink things.

Just because we have multi-gig machines, that is no reason for being sloppy - it wont make you a better programmer, just learn poor ways of doing things.

[Derron]

Regarding grids: Maybe the mazes are pregenerated 3D models ... so not constructed "live" but reusing existing blocks or even complete maps. This would explain a bigger asset size than really needed.

In "Maze Raider" (biggest is the runtime there I think) I used individual 3d models for "sides", "corners", "T-shapes", "+shapes" ... and then generate the level grid cell by grid cell. Afterwards according to what kind of wall is needed there I place the according 3d model at the position in the 3d level corresponding to the 2d labyrinth/maze I generated (in my case it was a pac-man-"maze").


@24MB
you are talking about _uncompressed 24MB. 3D models could compress a bit here and there. So even more space for more textures/models.


As said: use the "done game" to improve it regarding on how you organize your assets, improve on how to store your stuff more efficiently. Of course you should not overcomplicate (create models and textures procedurally or so) but at least try to improve your coding / project management skills.


bye
Ron

[Steve Elliott]

114Mb for an Android app is very large, you need to address this problem to stand any chance of being successful.  A quick search for average app size on on Android gives this article and a figure of 15Mb.

https://sweetpricing.com/blog/2017/02/average-app-file-size/

[Pfaber11]

The reason it's so huge is down to the mazes . For some reason they are taking up 12 mb  . I have redone a blank maze just to try and see what the result is and the new ones are using 4mb still high but heading in the right direction. I might try and redo them . on my original maze game they were averaging about 256k . the mazes are 2048x2048 in size so quite large . I think I should redo one maze a day until the job is done as my punishment for sloppy programming . I started off when I was 15 with a zx81 when 1k was 1k . In those days efficient programming was very important . Today we are spoilt rotten with mounds of memory to play with but yes no excuse for the sloppy programming.
Anyway if I go with the 4mb mazes it will shave 48mb off the total . so nearly half what it was . Might be something to do with mtpaint but I like the simplicity of the program. Thanks for the input.

Bonjour

[Derron]

What is a "blank maze" ... what does it contain, which format is it? If it is blank vertices it won't be 4MB except it contains some very verbose extra data.


bye
Ron

[Pfaber11]

I will try and show you what I call a blank maze .
This is a blank maze and the other one is a maze completed. As you can see the bottom one is the same size but uses much less memory . not sure why. Anyway I just draw on the blank whatever I like then tramsform it into a height map and there's my maze . I put  a texture on the maze also to enhance it .

[Pfaber11]

Never seen any mazes done like this but I should imagine it's been done many times before. I set the height of the height map to 2000 or so and the height of the camera to 500 . And there it is very simple but effective . I  set my computer to show x and z coordinates so I can place the orbs and food in the maze . My latest maze game has 12 levels of play opposed to the original game with only 6  plus added food and ghosts . I have plans to make it even better but I'll do that in the near future . was thinking when a ghost touches you everything goes into slow motion for 10 seconds . At the moment the ghosts are passive and just look good . When I create the height map from the 2d png file I make it 20480 x 2000 x 20480 so they are quite large . Takes a few seconds to load in fact about 15 on my phone and 40 seconds on my laptop .  It's a slow laptop.

[iWasAdam]

OK. In essence you map is a 17x17 grid:


which at 1byte per grid position (array of bytes) would be 289bytes. you would have an array so that you can do proper clip/collision checking, movement etc.

Probably the best suggestion I could give you is to dump the 3d, and focus on a very simple 2d topdown maze using a simple array ( array[x,y] ) with 0 being the floor and 1 being a wall.
your man starts at a random position where the array[x,y] = 0

Build a small program to enable you to move the man around on the floor and not bumping into the walls.

Next step would be to add an exit and a time to get to the exit.

After that use the code you wrote for moving the man and adapt it so that it uses randoms to move your man - you now have the basics of an enemy

Start simple. then work your way up. 

[Pfaber11]

That's interesting Adam but not giving up on 3d I'm hooked on it . If you played my maze game 2 with ghosts and food I think you might think the result is quite good . If any members of SyntaxBomb  ever want to see any of my games just let me know and I'll get you a key to get a free download . The 17 x 17 grid is a good idea though never thought of that. The 3d thing is awesome to use and really is no more difficult than 2d . just different . This is a screen shot of my game to give you an idea of what I'm doing and they are getting better all the time .

[Derron]

So you have drawn bitmaps (with jerky lines) in 2048x2048 and use that as heightmap to alter the position of vertices??
Does that mean you have thousand of vertices (so you have one "next to your lines")??

As told: create ground tiles, create wall tiles - and position according to the maze layout. This allows for multiple things:
- themes (other tiles for a theme) for the same maze layout
- animated mazes without much effort (sliding doors)
- dynamically create mazes
- mazes which occupy way way less disk space


as said I took that route with Maze Raider.


So if I misunderstood how you create a maze: what is the data format of a "map level/layout"?


bye
Ron