Hello there! This concerns: Platformers, Maps, and the Pocket PC. I have an idea that I'd like to run by anyone interested in reading it. I'm not sure if this is feasable or not, as I've never programmed on the PPC, and right now it's just a theory. I'm currently in the middle of building the core game engine, as the GUI is already completed. Since I've started with the core engine, I've had ideas floating around, and this is one I'd like to get some input on. The idea I have concerns the Map itself. I've been thinking about detailed Maps, and I mean absolutely detailed. I began to think about previous games, and if I remember correctly, Baldur's Gate used a single image as the entire background/map. It was hand painted, and boy did it look good. I was thinking of applying this to my game. The first game I have in mind is a Platformer. Now having a single image as the Map could prove to be a great idea, but only if it works. It could benefit the overall quality of the graphics (as the artist will be able to work freely instead of piecing tiles together), and the performance of the game. The platformer will work off of what are called Rooms. Each Room is a section of the current level. The player will not move from Room to Room (area to area) unless he or she goes beyond the current Room (that is, the "camera" does not move with the player, it holds still focusing on one Room/area at a time). This would allow me to draw the entire Room in a single frame, and only redraw the Room where needed (ie; where the monsters or player move). This would drastically cut down on the drawing needed per frame. A concern come to mind with this approach: I will not load a Room until the player enters it. By doing this, it would allow levels to be endless, but only if the player doesn't notice the loading! You know what this also means? The game could "feel" seemless to the player if it's pulled off correctly. How this works is, when a player leaves a Room and enters a new one (remember, Rooms are basically areas of a level), an image the size of the entire screen will need to be loaded, along with the Room Data (ie; areas that are walkable, monster spawn points, etc.). The Room Data will actually be small in size, only a single DWORD per 32x32 area. 7.5 x 10 = 75 DWORDs. 32 bits x 75 data = 2400 bits = 300 bytes to load upon entering a new Room. This of course doesn't include the image. My main concern here is the size of the single 240x320 image. Loading Room Data should be quick and painless (unless file access on the PPC is painfully slow). Will the image load fast enough to not require a load time? Will the artist enjoy the freedom of building a level in this manner or prefer making tiles and puzzling them together using a map editor? I just don't know, and I'd like some input. Thanks for your time.

Short answer: nope.

Long answer: you shoudl consider making a compromise. You can use tiles, and still have very lush artwork. Just create a tile ripper. The artist creates a very simple mock level anyway he wishs attempting not to be too detailed. You then run teh image through tile ripper which will find matching tiles within the image. With this tileset you can then create your levels and have the freedom of not creating tiles seperatly. Sure they wont be as detailed as just using static images, but it will be enough to fool the average gamer if your artist is good enough. Plus constant "disk" access on a pocket pc is likly to drain the battery quite fast. The tileset should be small enough to allow it to be in memory along with the map data for a level.

Personaly, I think unless you make teh characters small enough, and the rooms complex enough for the player to take some time to complete them (think games like outworld, pitfall, etc), the load time wont outweigh the better graphics. Smooth gameplay is ussually more important then graphics. Plus the player is not going to enjoy moving for 1-2 seconds across teh room to be shot across the screen again. It will be confusing to constantly being placed on teh left side of the screen. The camera should scroll with player so the game is not confusing to play.

Quote:
Plus the player is not going to enjoy moving for 1-2 seconds across teh room to be shot across the screen again. It will be confusing to constantly being placed on teh left side of the screen. The camera should scroll with player so the game is not confusing to play.

I've played a Flashback port on the PPC, and I didn't find the "Room" method confusing at all (in fact it's where I got the idea). I think it just has to do with the style of gameplay the platformer provides. In Flashback, each area is a puzzle to be solved. While they are fairly simplistic, it prevents the player from zooming across areas, and makes them stop and think for a few seconds before proceeding.

thats what i meant. if your platformer is like flashback (which is the sequal to outworld), then its no problem have the screen not moving. The player will need to take a few seconds (probably averaging about 6-7 seconds) compared to the avergae mario style platformer which would take you more along the lines of 1-2 seconds. I thought you were thinking about a rayman or mario style game where it was faster paced.

i guess i was not too clear about that. If you plan on flashback style gameplay, then you should not have too much problems even if the disk access is a second (which is about what i think, you sohuld really test it to see real world speed), you should have no problem doing what you want. However just remember battery life may be a concern. if possible you may want to try to keep a the room before the current room in memory. for the case when the player goes back and forth between rooms for some reason. Since if the player goes towards a dead end they wont like waiting for the previous room to load.

Since i have never actually coded on a pocket pc i can only make a guess based on what they can do. any pcketpc that can play mp3s would require at least ~15K per second (abit more if they plan on buffering the data). assuming an 8bit image you need about 77K to load the room, which is about 5-6 seconds. If the pocket pc buffers can actually mp3 data without much delay you might be looking at better odds at about 3 seconds. I suggest benchmarking the pocketpc you plan on supporting. Its possible that the disk acess will be faster then that, but that shoudl be worst case times assuming the pocketpc can at least play mp3s. Not usre if you plan on having background music that would need to be streamed as well. You may want to premeptivly load the next room using another thread, this coudl cut down precieved load times but could hurt performence or even case problems if the room has too many exits (do I load the room above, below or to the right)

in short, which is should have mentioned in my previous post. test it on a pcoketpc (a real one not a simulator), for a better idea of disk access speed.