Platformer? - NESdev BBS

Platformer?
by radonballoon on 2007-05-29 (#24520)

Can anyone point me in the direction of or explain how I would go about creating a scrollable level, like a platformer?

by Bregalad on 2007-05-29 (#24522)

Basically, you have to store your level in memory, and when scrolling, update from memory to the screen.
Now it depends but typically you have your map stored in a compact format (or even compressed) such as RLE, and decode it into a RAM array. Then you have another routine that allow you to place parts of this map from RAM to the screen, in metatiles and/or block of the size you want. When scrolling, you want to place metatiles of the section that is just going to enter in the field on the Name Table/Attribute table during VBlank.
That is for the map, for sprites, there is plenty of ways to do that, and since I never did it with sprites I don't know if I can tell you much about it. An idea is to store the position of the sprite in the map and treat it regardless if it's in the screen or not, but this typically takes too much memory/time to be a workable solution, so many people prefer just doing stuff to load and unload sprites as they go in/out of the screen.

by tokumaru on 2007-05-29 (#24524)

There is just no simple answer to that question. I guess I'll try anyway... =)

Every game is basically a bunch of objects working together, controlled by your game engine. In addition to the obvious objects such as the enemies and items, there are other very important objects such as the player and the camera. The camera is very important for a platformer!

You have to keep track of the positions of all these objects, to know when they collide, and to be able to render them to the screen.

The position of the camera inside the level tells your engine what part of your map to render to the screen. The format of the level format is up to you, but you have to be able to render part of it (a screen) based on the coordinates of the camera.

As the level is played, and you have to scroll the screen, the engine has to detect when it's time to render a new column (in the case of a side-scroller) of tiles, based on how much the screen scrolls every frame. You have to keep updating the name tables as the camera moves.

The other objects (player, enemies, etc) must be processed individually every frame. To find out the position of the sprites that represent them, you have to subtract the coordinates of the camera from their coordinates, in order to find how far into the screen they are.

A platformer is kinda complex to be explained in a single post. How much do you know about game coding in general? It's really hard to know where to start this explanantion...!

by radonballoon on 2007-05-29 (#24525)

Alright, I get the basics of the platformer, and to answer your question I've already programmed a pong game for the nes (although this is probably far from a platformer), so I at least understand the basics of the nametable/attribute table,palette, sprites, input. I guess my first question is what foreground objects versus background objects are. I'm guessing that the foreground like blocks, ground, etc. are sprites, and the background is a nametable that scrolls. Which raises another question, how would you scroll a repeating background? Would you load two nametables, and switch them out? And my final question is what is the normal way to go about creating levels? And how would this be stored?

Thanks!

by tokumaru on 2007-05-29 (#24526)

radonballoon wrote:
I've already programmed a pong game for the nes

So I'm sure you get the basics of how a game works. One of the hardest parts is understanding that, the concept of how to update things as the time passes.

Quote:
I at least understand the basics of the nametable/attribute table,palette, sprites, input.

IMO, this is much less important than understanding the concept of a game engine.

Quote:
I guess my first question is what foreground objects versus background objects are. I'm guessing that the foreground like blocks, ground, etc. are sprites, and the background is a nametable that scrolls.

This is your call, really. Of course it would be easier to make everything that interacts with the player as sprites, but the NES is not very strong in the sprite department (too few of them to use and the small ammount of them that can be displayed on the same scanline), so, depending on the complexity of the game (ammount of objects and how detailed they are), you may find yourself using the background for objects and items.

Quote:
how would you scroll a repeating background? Would you load two nametables, and switch them out?

Well, typically, in platform games, the background does not repeat, but if you really wish to do that, the NES has 2 name tables avaliable, so if you fill them both before starting the game, you get a 512-pixel scrollable are without having to update them again. There is no need to switch them. If you have vertical mirroring, and we call the name tables "A" and "B", let's say you start displaying name table A. As you scroll right, name table B will start to show up, until it fills the whole screen. If you keep scrolling right, the NES will automatically show name table A again.

Quote:
And my final question is what is the normal way to go about creating levels? And how would this be stored?

How you create the depends on the format they are stored, and the format is all up to you.

For actual games, you obviously can not store all the level as uncompressed name table and attribute table data. First, because that uses a lot of space (1KB per screen), and second, because even using that much space it does not include any collision information.

Games tipically use what is called metatiles. Metatiles are groups of tiles (usually arranged as blocks of 2x2 or 4x4 tiles) that you use to actually build the level. You have to define these metatiles somewhere in the ROM, defining what tiles each one uses, what palette, and their type (empty, solid, slippery, water, etc).

For a side-scroller, it'd be easier to arrange those metatiles in the form of columns, because as you scroll you have to draw columns with the new metatiles that show up in consequence of having scrolled.

But even that is not enough compression if you plan on having really big levels. That means that you have basically 2 options: use the same trick used with the metatiles, that is, instead of placing metatiles directly into the level, define entities that are groups of metatiles and place that directly into the level. The Sonic games for the Megadrive/Genesis do that. The other option is to use a compression algorithm (RLE, LZ, etc) to compress the level map data, and decompress it to RAM (you'll probably need large ammounts of it) as the level is played. I'm a big fan of the first option, because I find it faster and simpler, but it can result in levels that look repetitive if used in the wrong type of game.

Thing is there is no rule at all for this kind of stuff.

by albailey on 2007-05-30 (#24536)

tokumaru wrote:
There is no need to switch them. If you have vertical mirroring, and we call the name tables "A" and "B", let's say you start displaying name table A. As you scroll right, name table B will start to show up, until it fills the whole screen. If you keep scrolling right, the NES will automatically show name table A again.

I'm also interested in doing a scroller, and you just saved me a whole lot of pain with that one statement.

Al