So I'm back and every now and then when I have some free time I'd like to exercise my brain in a productive way and do some stuff with the NES! Preferably a game project. And no matter what, there are two things that scare me when it comes to planning development.
1. Which are the best and most common mappers to use? I'd probably go for one of the easiest to reproduce/find mappers in order to make the buliding of a cart easier, but not something that remains unused. So naturally I wouldn't want to waste a good MMC5 on a small game or something.
So hopefully the answers won't be more advanced stuff than the MMC3. I'd either pick that, or for even more simplicity, UNROM with CHR RAM or MMC1.
2. If I want a game that revolves around more than images and text, I have to have collision detection, but how exactly do you go about that? I understand having a map of the current screen in RAM (I'd have a single screen for the playfield and fade transitions in-between, drawing the next room while it's dark and then fading in for simplicity. The other nametable would be the pause menu with items and whatever which is scrolled to. I want a Zelda-like overhead view.) but that's about it. Also, does it help to keep track of which 16x16 block the player is in to make the collision check easier?
Thanks for everything!
Mapper choice and collision
Moderator: Moderators
Re: Mapper choice and collision
For your first game, I'd recommend NROM because it's simplest.za909 wrote:So I'm back and every now and then when I have some free time I'd like to exercise my brain in a productive way and do some stuff with the NES! Preferably a game project. And no matter what, there are two things that scare me when it comes to planning development.
1. Which are the best and most common mappers to use?
You can calculate that at any time from the player's current (x, y) position by shifting the X and Y coordinates four bits to the right.Also, does it help to keep track of which 16x16 block the player is in to make the collision check easier?
Re: Mapper choice and collision
Don't design the game around the mapper. Think about what features your game will need and then we can discuss mappers. Most beginners just go with NROM (i.e. no mapper at all), to avoid unnecessary complexity on their first projects.za909 wrote:Which are the best and most common mappers to use?
Collision detection is all about moving the objects, checking if they went into something solid, and pushing them back if they did. It gets a little more complicated if you have slopes, but working exclusively with blocks is almost straightforward.I have to have collision detection, but how exactly do you go about that?
Collisions are indeed a big aspect of action games, but don't forget about physics, AI, and other concepts that aren't exactly trivial either.
I don't think so. This will change so frequently that you can just sample the blocks around the objects every frame. Also, objects often make contact with multiple blocks at a time depending on their position.Also, does it help to keep track of which 16x16 block the player is in to make the collision check easier?
Here's a quick rundown of how collision could work:
1- Move the object horizontally (by the amount of pixels calculated in your physics code);
2- Get the coordinates of object's top right and bottom right (displacement to the right) or top left and bottom left (displacement to the left) corners;
3- Convert the coordinates from pixel space to level map space (i.e. divide by 16 if the blocks are 16x16 pixels);
4- Check the solidity of all blocks from the top coordinate to the bottom coordinate;
5- If any of them are solid, push the object back by the amount of pixels it's into the wall (need to look at the pixel coordinate again, to see how much past the left or right edges of the block it is);
6- Do the same for vertical motion, always compensating for the direction of the movement (top vs. bottom);