Open scoz opened 13 years ago
So I guess a question I have is.. how far did you guys plan on taking this project? If you just wanted to make it for phones of that exact screen size, I think it looks perfect; there's plenty of room and everything is clear. However, I have another phone that I had for testing programs (before I got my Charge) and the screen size is much smaller. The game loads on it perfectly. The only different is the amount of what you can see. Since the sprites and whatever else are measured in pixels, I can see less on the screen with fewer pixels (obviously, haha) Anyway, I'm wondering how/if you could implement a scaled graphical interface vs. by specific pixels.. cause then it could work fairly between different phones.
Anyway, it seems like the pixel measurements might be a rather permanent part, but I just figured I'd mention it. :)
But yeah, personally as I look at the view from my larger phone, I think the character size it perfect compared to the world tiles and such. Trees and random stuff would be sweet :)
you got yourselves a pretty exciting sweet project going on :) I'm jealous of your class haha
The artistic feel of the game needs to be decided ASAP.
The graphics system design depends heavily on artistic variables. The size of actos/object on the screen and the sprite size greatly affect memory requirements.
Right now a "world tile" is 32px x 32px, and are being drawn at a 1:1 pixel ratio to the screen. On Kyle's phone this gives 15 x 25 tiles when displaying on the entire screen. What is the scale of the hero to world tile? Is he 1/4th the size of a tile(16x16) ? This would make the hero 0.06 inches square.
With the current 1:1 pixel mapping we are also using 20MB in world-tile buffering. I could probably re-think that to eliminate one of the buffers, but thats still a large chunk of memory that cannot be eliminated. We're already encountering memory issues, the reason the game cannot be tested in the emulator now. I'm not sure how limited memory actually is. Kyle's phone is supposed to have 512m ram, but its given us Java VM heap OOM errors multiple times now, and we're only using 20-30MB.
Anyways, some important points that should get hammered out in the next week: