#7414 - spankmonkey1987 - Tue Jun 17, 2003 2:15 pm
now as i am still learning how to program in c i probaly dont know the correct terminology.i have questions about mapping for the creation of games like age of empires, AOE uses grids to map out were characters are the question i had was what is the most likley maxinum grid size that i could have with "actve characters possibly in semi large numbers moving round the map or is it even possible
#7415 - niltsair - Tue Jun 17, 2003 2:22 pm
Any size. You just dynamicly load your map (load the map as it is being shown) As for how many characters, it'll all depends on their AI algo (How much time it take for each to take action) and then again, you coudl go around by having them takes 'group action' I suppose.
#7465 - spankmonkey1987 - Wed Jun 18, 2003 10:53 am
ye i may try that it would definatly take up less time if they were grouped up ok i will try that
#8048 - sgeos - Tue Jul 01, 2003 6:27 am
| niltsair wrote: |
| Any size. You just dynamicly load your map... |
To an extent this is true. You might want to figure out roughly how much space each map takes up. This is to make sure your map is not too too big. The GBA (or any system for that matter) only has so much RAM.
-Brendan
#8050 - Quirky - Tue Jul 01, 2003 7:35 am
| sgeos wrote: |
| niltsair wrote: | | Any size. You just dynamicly load your map... |
To an extent this is true. You might want to figure out roughly how much space each map takes up. This is to make sure your map is not too too big. The GBA (or any system for that matter) only has so much RAM. |
But if the map is in ROM you get more space - that's the "dynamic" bit, you only have a small part of the map in RAM at any one time.
#8054 - sgeos - Tue Jul 01, 2003 8:29 am
| Quirky wrote: |
| But if the map is in ROM you get more space - that's the "dynamic" bit, you only have a small part of the map in RAM at any one time. |
My bad.
-Brendan
#8070 - Cyberman - Tue Jul 01, 2003 4:14 pm
Even though ROM is more plentiful I would be hesitant to say it's boundless ;)
There are some games that have completely random levels as well (I would love to port those but save state is too big.)
Well back to what I am getting too. If your map is REALLY big (and that's quite possible). Tiling the map itself (not just having tiles on the map) is a good idea. IE break it up into compressed sections you load dynamically into WRAM which you load dynamically into VRAM as it comes into view.
I doubt any map should be greater than 2048 x 2048 pixels but.. you never know.
Cyb
#8077 - sgeos - Tue Jul 01, 2003 5:47 pm
| Cyberman wrote: |
Even though ROM is more plentiful I would be hesitant to say it's boundless ;)
|
One could always make a stupidly large map that doesn't fit in ROM. Massively inefficient data structures... too much time on the part of the maker...
| Cyberman wrote: |
| There are some games that have completely random levels as well (I would love to port those but save state is too big.) |
What do you mean by 'the save state is too big'? Are not randomly generated maps created by an algorithm? I you want to use a map generated by your favorite game, you could always convert it to something of a reasonable size/structure on your PC and then include it in your project. You'd have to know or figure out your favorite game's map structure though.
| Cyberman wrote: |
| Tiling the map itself (not just having tiles on the map) is a good idea. IE break it up into compressed sections you load dynamically into WRAM which you load dynamically into VRAM as it comes into view. |
I've thought about this as well. If you are in Sector J, you'll probably want to have the sectors above, below, and to the sides decompressed in RAM. (Mayhaps the corners as well.) When you move into another area you'll load in the border areas.
| Cyberman wrote: |
| I doubt any map should be greater than 2048 x 2048 pixels but.. you never know. |
Let's see, 16 pixel by 16 pixel meta-tiles... that is 128 by 128 tiles. I've found that it is fairly difficult to make maps that large. Of course, an auto-generated map can be any size.
-Brendan
#8078 - Archeious - Tue Jul 01, 2003 5:47 pm
| Cyberman wrote: |
Even though ROM is more plentiful I would be hesitant to say it's boundless ;)
There are some games that have completely random levels as well (I would love to port those but save state is too big.)
Well back to what I am getting too. If your map is REALLY big (and that's quite possible). Tiling the map itself (not just having tiles on the map) is a good idea. IE break it up into compressed sections you load dynamically into WRAM which you load dynamically into VRAM as it comes into view.
I doubt any map should be greater than 2048 x 2048 pixels but.. you never know.
Cyb |
Just wondering how you arrived at the numbers 2048x2048. Wouldn't it depend of the game design. An example of how the focus of the game can change map size. Compare Mario vs Sonic. Both are platformers but sonic travels much faster requiring much larger maps.
Compressing the maps is an excellent idea. Most maps are repeats of the same tiles anyways. Just have to watch out for the decompression time.
#8079 - sgeos - Tue Jul 01, 2003 5:49 pm
| Archeious wrote: |
| Most maps are repeats of the same tiles anyways. |
The original Metroid (and many RPGs) have repeats of the same rooms.
-Brendan
#8087 - tepples - Tue Jul 01, 2003 8:35 pm
| Cyberman wrote: |
| There are some games that have completely random levels as well (I would love to port those but save state is too big.) |
Unless you save only the seed used to generate the map.
| Quote: |
| I doubt any map should be greater than 2048 x 2048 pixels but.. you never know. |
The map in the overworld of The Legend of Zelda is already 4096 pixels wide (16 screens by 256 pixels). The map in the overworld of Jurassic Park for Super NES is about 4096x4096 pixels.
Try decompressing the map a screen at a time, decompressing new areas when the camera pans to them.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#8125 - Cyberman - Wed Jul 02, 2003 3:25 pm
| tepples wrote: |
The map in the overworld of The Legend of Zelda is already 4096 pixels wide (16 screens by 256 pixels). The map in the overworld of Jurassic Park for Super NES is about 4096x4096 pixels.
Try decompressing the map a screen at a time, decompressing new areas when the camera pans to them. |
Ok.. SNES is not the GBA but it did have smaller amounts of memory. I suppose what I was really getting at is, try something and see if it's rediculous or not ;) And the later was my suggestion as well. deal with only what you need no more and no less.
| tepples wrote: |
| Unless you save only the seed used to generate the map. |
Hmmm well I know in a certain game I've been trying to port this won't work. Each level is randomly generated, that's cool right? However during game play the level changes. For example you leave a pile of food on level 33, and leave your dog there. Coming back up, you won't find your dog and you won't have your pile of food. Or all the holes in the walls from a tunneling monster or the 100000 gold pieces you left there. Just the same thing you saw when you entered the level the last time.
Now finding a way to compress the levels well enough so it fits in 64K would be handy, as is to port this I need about 1 meg of save memory (gah huge huh?) to save the entire game state. There are 150 + levels in it. 30 static the rest random. Even the static levels once 'used' in the game have to be saved because you and monsters can alter the level.
Cyb
#8132 - DekuTree64 - Wed Jul 02, 2003 4:56 pm
Maybe you could save a list of 'events' that happened to a level, so you can generate it from a seed, and then redo all the things that happened while you were there. You may end up running out of memory for the event lists eventually, but it would surely be smaller than storing whole levels.
Just have like one byte to tell the type of event, like hole in wall, thing on floor, thing picked up. And for a little optimization, if you need more types than that, make less than 256 type 'classes', so you can store a secondary type for ones that have a lot of variations in the next byte, but don't use that second byte unless you need it.
Then have a number of bytes following depending on the type, or for variable sized events maybe have the second byte tell how long it is. You could even try compressing those lists with LZW or something. Might not do much good, but experiment around with anything you can think of.
#8135 - Quirky - Wed Jul 02, 2003 5:47 pm
| Cyberman wrote: |
| tepples wrote: | | Unless you save only the seed used to generate the map. |
Hmmm well I know in a certain game I've been trying to port this won't work. Each level is randomly generated, that's cool right? However during game play the level changes. For example you leave a pile of food on level 33, and leave your dog there. Coming back up, you won't find your dog and you won't have your pile of food. |
You aren't trying to port .... Nethack?! :-o Or at least a similar rogue-like. That would be awesome, I've often though that the gameplay would really suite the GBA. I think that the memory issues mean a GBA specific version (i.e. designd for the GBA from the ground up, rather than "ported") would be required though. Start small and build on that, if you see what I mean.
Anyway... Perhaps you could just remember which level the dog's on, for example, rather than its precise location. Randomise its start location when you return to a level - that would be your punishment for abandoning the faithful mutt! And as for the food and gold, well a monster could have eaten it or stolen it, right? And those tunnels were underneath a supporting wall, I'm not surprised they collapsed when you went down a level ;)
As for the save state - I think perhaps you are trying to save too much? Your stats will be randomly generated at the start, so by saving just the seed and your current experience/level you might be able to squish it down. And gold, etc, you'll have to handle in bytes - perhaps lose the least significant bytes when saving? I dunno, jsut some ideas. There are probably lots of little things that you could do that would fit in the game without compromising playability too much and when added up would save you loads of space.
OK then, when will it be finished? :-)