03-28-2011, 10:40 PM
Okay guys, long post coming up!
A chunk is a whole screen's worth of level, so that's 9 blocks high by 10 blocks wide, a total of 90 blocks on the screen.
However, we'd be storing half-chunks (I call them parts or portions, since that's a bit shorter), so that'd be 45 blocks per half-chunk.
I suppose, a portion file (.prt or something? extension doesn't really matter...) could be a text based file storing:
--- Portion type (a number the game would use to determine what kind of portion this is, such as platform, big gap, wall, etc.)
--- Difficulty level (another number the game would use to determine when to use this portion)
--- The portion data itself (this would be a 2d array/table of numbers listing the block arrangements, as well as any enemy or item hooks)
Of course, when I say number, I actually mean character, but those are just represented by a byte-sized number anyway.
Here's a sample portion file.
So yeah, a portion file that has only the bare minimum could get away with being about 58 bytes; one with comments would be longer, but even then, a typical portion file with comments discussing only the type of the portion (and credits, if the person making these is a credits-whore) would still be likely under 150 bytes.
I could reduce the filesize of every portion to a standard of around 47 bytes if we don't want text-based portion files, but then I'd have to make a level-editor for people to use to make these things, or everyone would have to use a hex-editor to make the binary files directly.
EDIT: Though, I'm thinking I might need to store the left and right side open spaces in these portions as well, so that the game can better place the portions within a chunk. That is, if one portion has its rightside space higher than the next portion's leftside space, it will move that next portion to be higher.
From there, the game would load all of these as it opens, and the game would then generate chunks by choosing two of these portions for each half of each chunk. The portions it chooses would be determined by the current type portion type we're on (this changes gradually, so that we can slowly go between different level construction types) and the difficulty level we're currently at (the difficulty gradually increases as the game continues).
BTW, the difficulty level works like this: when the game makes a chunk, it adds the difficulty levels of the two portions it has picked together; if the total exceeds the game's current difficulty, we have the game pick another pair of portions until we come up with a pair of portions with a low enough difficulty. In order to keep this from slowing the game down too much, the game won't be able to pick any portions that already have a difficulty equal to or higher than the current difficulty level, though this might still be a bit slow. Another possibility is for the game to pick one portion first, then pick only a portion with a low enough difficulty level for their total to be less than the current difficulty level (did that make any sense?) for the second half.
Difficulty will also affect the likelihood of items and enemies spawning in their respective hooks.
@ Guy, if I remember correctly, I did actually try to shift the sprite around so it wouldn't sink like that, but then I occasionally got instances where he would float a pixel above the ground. Precise collisions hate me.
As for how bosses would work, I figured that a special boss room would occasionally spawn with the boss in it. Once you enter the room, the battle would begin and the game would stop scrolling (I'm thinking it might be nice for the game to slowly stop, instead of jerking to a stop). Then, once you beat the boss and shit, the game starts scrolling again.
I was also thinking that, when you fall down a gap, you'd lose a point of health and respawn next to the pit you fell in.
@ Gors, I suppose there could be special tunnel-type chunks that would use the tunnel generator.
Whew! Long post is LONG.
A chunk is a whole screen's worth of level, so that's 9 blocks high by 10 blocks wide, a total of 90 blocks on the screen.
However, we'd be storing half-chunks (I call them parts or portions, since that's a bit shorter), so that'd be 45 blocks per half-chunk.
I suppose, a portion file (.prt or something? extension doesn't really matter...) could be a text based file storing:
--- Portion type (a number the game would use to determine what kind of portion this is, such as platform, big gap, wall, etc.)
--- Difficulty level (another number the game would use to determine when to use this portion)
--- The portion data itself (this would be a 2d array/table of numbers listing the block arrangements, as well as any enemy or item hooks)
Of course, when I say number, I actually mean character, but those are just represented by a byte-sized number anyway.
Here's a sample portion file.
So yeah, a portion file that has only the bare minimum could get away with being about 58 bytes; one with comments would be longer, but even then, a typical portion file with comments discussing only the type of the portion (and credits, if the person making these is a credits-whore) would still be likely under 150 bytes.
I could reduce the filesize of every portion to a standard of around 47 bytes if we don't want text-based portion files, but then I'd have to make a level-editor for people to use to make these things, or everyone would have to use a hex-editor to make the binary files directly.
EDIT: Though, I'm thinking I might need to store the left and right side open spaces in these portions as well, so that the game can better place the portions within a chunk. That is, if one portion has its rightside space higher than the next portion's leftside space, it will move that next portion to be higher.
From there, the game would load all of these as it opens, and the game would then generate chunks by choosing two of these portions for each half of each chunk. The portions it chooses would be determined by the current type portion type we're on (this changes gradually, so that we can slowly go between different level construction types) and the difficulty level we're currently at (the difficulty gradually increases as the game continues).
BTW, the difficulty level works like this: when the game makes a chunk, it adds the difficulty levels of the two portions it has picked together; if the total exceeds the game's current difficulty, we have the game pick another pair of portions until we come up with a pair of portions with a low enough difficulty. In order to keep this from slowing the game down too much, the game won't be able to pick any portions that already have a difficulty equal to or higher than the current difficulty level, though this might still be a bit slow. Another possibility is for the game to pick one portion first, then pick only a portion with a low enough difficulty level for their total to be less than the current difficulty level (did that make any sense?) for the second half.
Difficulty will also affect the likelihood of items and enemies spawning in their respective hooks.
@ Guy, if I remember correctly, I did actually try to shift the sprite around so it wouldn't sink like that, but then I occasionally got instances where he would float a pixel above the ground. Precise collisions hate me.
As for how bosses would work, I figured that a special boss room would occasionally spawn with the boss in it. Once you enter the room, the battle would begin and the game would stop scrolling (I'm thinking it might be nice for the game to slowly stop, instead of jerking to a stop). Then, once you beat the boss and shit, the game starts scrolling again.
I was also thinking that, when you fall down a gap, you'd lose a point of health and respawn next to the pit you fell in.
@ Gors, I suppose there could be special tunnel-type chunks that would use the tunnel generator.
Whew! Long post is LONG.