The other thread that I opened was about the hard facts of NES programming, especially with the CC65. Like "What is a cfg file for?" etc.
In this thread here I'd like to discuss some questions about the programming style. I.e. common ways to achieve something, best practice etc. Things that aren't objective facts, but more certain styles that established themselves.
My first question is: How is the level structure for the game logic usually saved?
Possibility 1:
There are some general variables that define how the level looks like and where the player can walk. From these variables, the background in the nametable is created. But during the algorithm that decides if the player can walk a certain way, only these general variables are used.
Imagine a simple maze game where there are blocks/walls of 16 x 16 pixels that the player can't pass and the rest is the floor that the player can walk along.
Since the screen is 256 x 240 pixels and every block is 16 x 16 pixels, we have a playfield of 16 x 15 = 240 squares.
That means, the whole level structure (from a purely logical point of view, I'm not talking about the actual graphic tiles in the PPU yet) can be put into standard variables (or constants) of the size of 240 bits = 30 bytes. Each bit stands either for "there is a wall in the way" (1) or "the way is free to walk" (0).
In the beginning, the nametable is built up from these values: You loop through the bits and bytes of the variables and if there's a 1, you put the 2 x 2 wall tiles in the corresponding place and if there's a 0, you put the 2 x 2 floor tiles there.
Later, when the game runs, you don't look at the nametable anymore. All you do is take the x and y coordinate of the sprite, and through calculation, you extract the correct bits from your 30 bytes generic variables to see if the way that the character is about to go is free.
Possibility 2:
You somehow create the background in the nametable (for example through some compressed ROM data that is extracted for this one action and then discarded again). And during gameplay, you actually literally read the values from the PPU itself. If the player wants to go up, you check the nametable at the corresponding location. If there is one of the wall tiles set, movement isn't possible, if one of the floor tiles is set, movement is possible.
In the first version, the level structure is abstracted away. Both, the nametable and the game logic use generic variables. To define if a character can walk somewhere, the PPU is never read, only the customly-defined variables that are either stored in the ROM or in the CPU's RAM.
In the second version, the level structure is directly defined by what is written in the nametable. The nametable, and therefore the PPU's RAM, is constantly read to see if the player is in a position to move.
How do real NES games do it?
For example in "Donkey Kong", can Mario climb a ladder because some variable tells the game that in this and that location there is supposed to be a ladder? Or does the game literally read the nametable at that location and recognizes that there is the ladder tile?
So, if I manipulate the nametable in the PPU during a running game on an emulator, but I don't change anything in the regular CPU or the ROM data, could I change the gameplay, i.e. create working walls and ladders etc.? Or would the change only be visual while the movements of the player wouldn't be influenced, i.e. there would be a discrepancy between the gameplay's level structure and the visual representation on the screen?
What's the common practice for NES games here? In a normal PC game, I would of course put the level structure into a two-dimensional integer or byte or boolean array and only work from that array. I would never actually read the background graphics to decide what's to do in the game logic. Is this the same on the NES? Or are game logic conditions directly linked to the nametable contents?
In this thread here I'd like to discuss some questions about the programming style. I.e. common ways to achieve something, best practice etc. Things that aren't objective facts, but more certain styles that established themselves.
My first question is: How is the level structure for the game logic usually saved?
Possibility 1:
There are some general variables that define how the level looks like and where the player can walk. From these variables, the background in the nametable is created. But during the algorithm that decides if the player can walk a certain way, only these general variables are used.
Imagine a simple maze game where there are blocks/walls of 16 x 16 pixels that the player can't pass and the rest is the floor that the player can walk along.
Since the screen is 256 x 240 pixels and every block is 16 x 16 pixels, we have a playfield of 16 x 15 = 240 squares.
That means, the whole level structure (from a purely logical point of view, I'm not talking about the actual graphic tiles in the PPU yet) can be put into standard variables (or constants) of the size of 240 bits = 30 bytes. Each bit stands either for "there is a wall in the way" (1) or "the way is free to walk" (0).
In the beginning, the nametable is built up from these values: You loop through the bits and bytes of the variables and if there's a 1, you put the 2 x 2 wall tiles in the corresponding place and if there's a 0, you put the 2 x 2 floor tiles there.
Later, when the game runs, you don't look at the nametable anymore. All you do is take the x and y coordinate of the sprite, and through calculation, you extract the correct bits from your 30 bytes generic variables to see if the way that the character is about to go is free.
Possibility 2:
You somehow create the background in the nametable (for example through some compressed ROM data that is extracted for this one action and then discarded again). And during gameplay, you actually literally read the values from the PPU itself. If the player wants to go up, you check the nametable at the corresponding location. If there is one of the wall tiles set, movement isn't possible, if one of the floor tiles is set, movement is possible.
In the first version, the level structure is abstracted away. Both, the nametable and the game logic use generic variables. To define if a character can walk somewhere, the PPU is never read, only the customly-defined variables that are either stored in the ROM or in the CPU's RAM.
In the second version, the level structure is directly defined by what is written in the nametable. The nametable, and therefore the PPU's RAM, is constantly read to see if the player is in a position to move.
How do real NES games do it?
For example in "Donkey Kong", can Mario climb a ladder because some variable tells the game that in this and that location there is supposed to be a ladder? Or does the game literally read the nametable at that location and recognizes that there is the ladder tile?
So, if I manipulate the nametable in the PPU during a running game on an emulator, but I don't change anything in the regular CPU or the ROM data, could I change the gameplay, i.e. create working walls and ladders etc.? Or would the change only be visual while the movements of the player wouldn't be influenced, i.e. there would be a discrepancy between the gameplay's level structure and the visual representation on the screen?
What's the common practice for NES games here? In a normal PC game, I would of course put the level structure into a two-dimensional integer or byte or boolean array and only work from that array. I would never actually read the background graphics to decide what's to do in the game logic. Is this the same on the NES? Or are game logic conditions directly linked to the nametable contents?