Alright. I've obviously got working levels and such, but now I kinda want to get into doing things such as lay out the general castle. Do the first area of the game and such. The areas seen in the video will be in there, but later.
I'm going to have it be very much in the style of the new Castlevanias in that you need to obtain items/keys to progress to new areas. It'll just be one big area you can explore and not a game based around levels.
I'm thinking of having you start in your house and you have to walk through a forest or cave or something and reach the fortress.
Does anyone have any good advice on what to do or not to do when doing all this?
Want to start some serious level design
Moderator: Moderators
-
SecretServiceDude
- Posts: 99
- Joined: Wed Oct 22, 2008 3:49 pm
- Location: Los Angeles, CA
Will your game have a map like the one in Super Metroid or Castlevania: SOTN? That might be useful depending on how big the game world is.
Lack of a map is one of the major reasons I dislike the NES version of Metroid. The rooms are so similar to each other, it's really hard to tell them apart. Getting lost is a great way to frustrate the player, so I'd recommend preventing that in any way possible.
Lack of a map is one of the major reasons I dislike the NES version of Metroid. The rooms are so similar to each other, it's really hard to tell them apart. Getting lost is a great way to frustrate the player, so I'd recommend preventing that in any way possible.
-
Celius
- Posts: 2159
- Joined: Sun Jun 05, 2005 2:04 pm
- Location: Minneapolis, Minnesota, United States
- Contact:
Ah, I have the same type of game! I'm making a game called "ChateauLeVania", which is obviously inspired by Castlevania. I'm writing a book called "The Curse of Chateau LeVeaux", and this is the game based off of the book. It plays almost just like SOTN.
Anyways, it really depends on how much ROM space you have. For example, I've given myself 512k of PRG to work with. This allows me to be really flexible. I have a bank defining metatiles, and another bank defining screens which are made of those metatiles, and finally I have a bank defining rooms which are made of screens. That bank also has other things too, as the room definitions don't take up the whole thing.
Anyways, my suggestion would be having rooms composed of screens which are composed of metatiles. My screens are composed of 16 8x8 metatiles. Those metatiles are composed of 4 4x4 tiles, and those 4x4 tiles are composed of 4 2x2 tiles. There are 256 different 2x2, 4x4, and 8x8 tiles that can be used in one room. This block compression style saves space in the long run.
As for objects(enemies, items, entities, etc.) in the room, it's just a matter of defining the placement and identity of the object. For that I just have a list with all that information on it for each room. I can keep that in the same bank as the room definitions.
EDIT: Wow, your story sounds kind of similar to mine. You start out at your house (though it's more like a resort), and you have to make your way outside and down these stairs to the lakeside on which there is a cave that leads to an underground castle.
EDIT 2: Is your game screen-at-a-time scrolling like Zelda? Is this the same game as the other video you showed recently?
Anyways, it really depends on how much ROM space you have. For example, I've given myself 512k of PRG to work with. This allows me to be really flexible. I have a bank defining metatiles, and another bank defining screens which are made of those metatiles, and finally I have a bank defining rooms which are made of screens. That bank also has other things too, as the room definitions don't take up the whole thing.
Anyways, my suggestion would be having rooms composed of screens which are composed of metatiles. My screens are composed of 16 8x8 metatiles. Those metatiles are composed of 4 4x4 tiles, and those 4x4 tiles are composed of 4 2x2 tiles. There are 256 different 2x2, 4x4, and 8x8 tiles that can be used in one room. This block compression style saves space in the long run.
As for objects(enemies, items, entities, etc.) in the room, it's just a matter of defining the placement and identity of the object. For that I just have a list with all that information on it for each room. I can keep that in the same bank as the room definitions.
EDIT: Wow, your story sounds kind of similar to mine. You start out at your house (though it's more like a resort), and you have to make your way outside and down these stairs to the lakeside on which there is a cave that leads to an underground castle.
EDIT 2: Is your game screen-at-a-time scrolling like Zelda? Is this the same game as the other video you showed recently?
Well, I have the room data down. It's not compressed like yours (yours sounds like the way Mega Man games do it), mainly to allow for more freedom of room design. Each room is around 210 bytes. 192 for tiles, and the rest for info like what palette, what tileset, what enemies, what music, etc.
I have a master array that says what rooms are where and a secondary array that has what banks the rooms are in. The only downside to this is the arrays can only be 256 bytes when using a pointer... Though I will probably make a second variable for the room indexing to expand on that.
Obviously the most space is dedicated to rooms. Music and sound might be fairly large too, but that's another issue.
Other things I'm wondering would be how much space could enemy AI possibly take up? I'm using some common routines for the movement of enemies, though others will probably need to be addressed specifically. I haven't made any attempts at real complex enemies/bosses.
128KB seems like a good chunk of space, though I can always change to UOROM for 256.
I have a master array that says what rooms are where and a secondary array that has what banks the rooms are in. The only downside to this is the arrays can only be 256 bytes when using a pointer... Though I will probably make a second variable for the room indexing to expand on that.
Obviously the most space is dedicated to rooms. Music and sound might be fairly large too, but that's another issue.
Other things I'm wondering would be how much space could enemy AI possibly take up? I'm using some common routines for the movement of enemies, though others will probably need to be addressed specifically. I haven't made any attempts at real complex enemies/bosses.
128KB seems like a good chunk of space, though I can always change to UOROM for 256.
-
Celius
- Posts: 2159
- Joined: Sun Jun 05, 2005 2:04 pm
- Location: Minneapolis, Minnesota, United States
- Contact:
Actually, the freedom of room design for me is pretty big. I'll probably only show about 1100 screens or so, and I allow for 1024 unique screens. A lot of them can be the same, too, if it's a save room or a long hallway of sorts.
I have 16k dedicated to AI. It's basically all code; that's the easiest way to code AI. Though if this isn't enough, I'll expand it. I plan to use as many universal routines for each object as possible, so I'll be able to save space.
One great thing about having 512k of PRG data is you can basically assign banks to things instead of sections of banks.
I have 16k dedicated to AI. It's basically all code; that's the easiest way to code AI. Though if this isn't enough, I'll expand it. I plan to use as many universal routines for each object as possible, so I'll be able to save space.
One great thing about having 512k of PRG data is you can basically assign banks to things instead of sections of banks.
Map of Metroid. I imagine repetition was one of the only ways to get such a large map into that sized ROM.SecretServiceDude wrote:Lack of a map is one of the major reasons I dislike the NES version of Metroid. The rooms are so similar to each other, it's really hard to tell them apart. Getting lost is a great way to frustrate the player, so I'd recommend preventing that in any way possible.
-
SecretServiceDude
- Posts: 99
- Joined: Wed Oct 22, 2008 3:49 pm
- Location: Los Angeles, CA
Ah yes, I've seen that map. It would have been really sweet if the map documented all the hidden worlds that you can access by exploiting the wall climb glitch.blargg wrote:Map of Metroid. I imagine repetition was one of the only ways to get such a large map into that sized ROM.
Regarding the map question: Believe me, I have thought about this. The only thing is how to do the implementation. I like how SOTN and similar games did their maps. You just get a general screen with explored areas in bright boxes.
The only problem with this is that something like that would probably require a fair chunk of memory. I SUPPOSE I could have it be based on bits of a number cause the boxes you explore will either be on/off. So one byte could be 8 boxes.
Another little problem will be backups of the maps for gaming sessions. I'm planning to use a password system and having a password for a map could be very tedious. Not to mention all the other variables someone's set. I may go with a save feature, though I'm not sure on that implementation either.
I considered having map items you can find so if those items are true, you can see the parts of the map. This approach would have it so the map doesn't get "mapped out" by exploring, but rather if you have the item (hope that makes sense)
The only problem with this is that something like that would probably require a fair chunk of memory. I SUPPOSE I could have it be based on bits of a number cause the boxes you explore will either be on/off. So one byte could be 8 boxes.
Another little problem will be backups of the maps for gaming sessions. I'm planning to use a password system and having a password for a map could be very tedious. Not to mention all the other variables someone's set. I may go with a save feature, though I'm not sure on that implementation either.
I considered having map items you can find so if those items are true, you can see the parts of the map. This approach would have it so the map doesn't get "mapped out" by exploring, but rather if you have the item (hope that makes sense)
-
Celius
- Posts: 2159
- Joined: Sun Jun 05, 2005 2:04 pm
- Location: Minneapolis, Minnesota, United States
- Contact:
I actually do something like what you mentioned with the boxes. I have a "bitmap" to determine whether a screen in the room is an actual screen, or empty (Screen #0). Take this room for example:
Outlined in the pink box. There are a lot of blank screens in this room (the black areas, of course). The box encompasses an 8x7 area, so you have 56 screens total in that room. Since I define every room with 2 bytes per screen, this room would usually take up 112 bytes to define. With my bitmap solution, I state with bits whether or not a screen is blank:
00000011
00000111
00001111
00011100
00111000
01110000
11100000
All the 0's indicate a blank screen. When you enter a room, the room is somewhat decompressed to RAM. I only put pointers to the screen data in RAM for the whole room. So for every 0 in the bitmap, I point to screen #0, which is blank. All in all, instead of defining 56 screens, I defined 21. Thus the size is reduced to 42 bytes of definitions.
Though one might think that this whole "bitmap" after a while wastes lots of space, for a lot of the rooms are completely square. For a solution, I decided that if the first byte of the bitmap was $FF (I think), then that indicated the room was completely square with no blank screens. Of course, I could point to a blank screen in my room definition, that just might waste space.
EDIT: This above is for the room loading, not the progress map.
My progress map will be 64x60 screens large, so it will span over 4 (2x2) name tables when viewing it (each screen is represented with one tile). In the saved game data, it will be a bitmap too, each room you've been in is represented by a 1. A 64x60 tile map will be stored somewhere in ROM, and this bitmap will put a tile on screen for each corresponding 1 it encounters.
Outlined in the pink box. There are a lot of blank screens in this room (the black areas, of course). The box encompasses an 8x7 area, so you have 56 screens total in that room. Since I define every room with 2 bytes per screen, this room would usually take up 112 bytes to define. With my bitmap solution, I state with bits whether or not a screen is blank:
00000011
00000111
00001111
00011100
00111000
01110000
11100000
All the 0's indicate a blank screen. When you enter a room, the room is somewhat decompressed to RAM. I only put pointers to the screen data in RAM for the whole room. So for every 0 in the bitmap, I point to screen #0, which is blank. All in all, instead of defining 56 screens, I defined 21. Thus the size is reduced to 42 bytes of definitions.
Though one might think that this whole "bitmap" after a while wastes lots of space, for a lot of the rooms are completely square. For a solution, I decided that if the first byte of the bitmap was $FF (I think), then that indicated the room was completely square with no blank screens. Of course, I could point to a blank screen in my room definition, that just might waste space.
EDIT: This above is for the room loading, not the progress map.
My progress map will be 64x60 screens large, so it will span over 4 (2x2) name tables when viewing it (each screen is represented with one tile). In the saved game data, it will be a bitmap too, each room you've been in is represented by a 1. A 64x60 tile map will be stored somewhere in ROM, and this bitmap will put a tile on screen for each corresponding 1 it encounters.