Some people claim that the thing holding back homebrew on Super NES is lack of pre-made generic game engines. It's more complicated than that.
Many web designers prototype their designs with "Lorem ipsum", a passage from On the Ends of Goods and Evils by M. T. Cicero, adding actual articles later. I'm guilty of this as well; I used a translation of this passage when I was building my NES VWF engine and when refining another pixel font.
But in "Lorem Ipsum is Killing Your Designs", Kyle Fiedler explains why this isn't the best approach. It ends up with a design that's optimized for a Cicero excerpt rather than for the information you wish to present. Instead, he recommends starting with a rough draft of an actual article as you begin design. Joshua Johnson agrees in "The Importance of Copywriting in Web Design", as does Jason Fried in "'Getting Real' design tip: Just say no to Lorem Ipsum".
In the case of a game engine, this means having the map of an original level and original sprite cels in place before programming begins, even if only for the purposes of designing a binary representation of level maps. To avoid the chicken-and-egg problem of making a level map without knowing the constraints on the map format, have a pixel artist produce a rough draft without technical constraints at first (other than the 8x8-pixel tile grid) by making the playfield layer and parallax layers as PNG images. Then derive appropriate technical constraints on the engine from that. This worked well for Haunted: Halloween '85, whose first deliverable was a viewer for the draft of the school level. When the draft level had more than 256 distinct tiles, I came up with a way to shuffle tiles around in CHR RAM at runtime.
Not only does this produce an engine more tailored to the intended use, but it also avoids placeholders slipping into production. This is why you need to test with original artwork from day one, so that Nintendo has no grounds to sue you into financial ruin should some artwork from Super Mario World accidentally end up in the published game.
Many web designers prototype their designs with "Lorem ipsum", a passage from On the Ends of Goods and Evils by M. T. Cicero, adding actual articles later. I'm guilty of this as well; I used a translation of this passage when I was building my NES VWF engine and when refining another pixel font.
But in "Lorem Ipsum is Killing Your Designs", Kyle Fiedler explains why this isn't the best approach. It ends up with a design that's optimized for a Cicero excerpt rather than for the information you wish to present. Instead, he recommends starting with a rough draft of an actual article as you begin design. Joshua Johnson agrees in "The Importance of Copywriting in Web Design", as does Jason Fried in "'Getting Real' design tip: Just say no to Lorem Ipsum".
In the case of a game engine, this means having the map of an original level and original sprite cels in place before programming begins, even if only for the purposes of designing a binary representation of level maps. To avoid the chicken-and-egg problem of making a level map without knowing the constraints on the map format, have a pixel artist produce a rough draft without technical constraints at first (other than the 8x8-pixel tile grid) by making the playfield layer and parallax layers as PNG images. Then derive appropriate technical constraints on the engine from that. This worked well for Haunted: Halloween '85, whose first deliverable was a viewer for the draft of the school level. When the draft level had more than 256 distinct tiles, I came up with a way to shuffle tiles around in CHR RAM at runtime.
Not only does this produce an engine more tailored to the intended use, but it also avoids placeholders slipping into production. This is why you need to test with original artwork from day one, so that Nintendo has no grounds to sue you into financial ruin should some artwork from Super Mario World accidentally end up in the published game.