I'm guessing a good goal would be to fill up 4 megabits, or 512 kB. With that size you would have enough room to make a good game, but you wouldn't be tempted in going overboard on features. ROM could be divided up like this:
128kB for level maps (8 levels, each 16kB large)
64kB for audio
32kB for program code
128kB for BG graphics (8 sets of 16kB)
160kB for sprite graphics
You can probably cut down on sprite graphics by using a lot of software rotation and scaling tricks.
By this measure, how big is Super Mario World?
SMW uses a hell lot compression for levels. I don't think anyone would want to go through the trouble of making that many levels for a homebrew.
Levels are hard to make, but much better for time, and game size. You can make 128KB content quicker than filling up another 8KB of code for sure, if you make a good game engine, why not have lots of levels to go with it? That's pretty backwards to me. A game engine with few levels...I mean, unless it's something like Gimmick, where that is the gimmick, then it makes not a ton of sense for many reasons.
Because levels can take up a lot of time to make?
Also honestly: memory is relatively cheap these days. As long as you don't need weird hardware in the cartridge I'd say don't worry as long as it fits within the address space. You probably don't want to waste space for no reason but don't try to set up such strict space limits before hand unless there's a very specific motive limiting you (e.g. your engine needs a specific layout or you need to reserve some space for save RAM or stuff like that).
Or you might want to make your game small in order to fit it on a collaborative multicart, if we ever get around to making one of those.
tepples wrote:
Or you might want to make your game small in order to fit it on a collaborative multicart, if we ever get around to making one of those.
Something similar to this one?
https://www.pikointeractive.com/super-4-in-1.html
Sik wrote:
Because levels can take up a lot of time to make?
Also honestly: memory is relatively cheap these days. As long as you don't need weird hardware in the cartridge I'd say don't worry as long as it fits within the address space. You probably don't want to waste space for no reason but don't try to set up such strict space limits before hand unless there's a very specific motive limiting you (e.g. your engine needs a specific layout or you need to reserve some space for save RAM or stuff like that).
I agree that unless you have some specific reason to limit ROM size then you shouldn't. If you can use 16 or 32 megabits of ROM for your creation you should do so. Obviously I wouldn't advise being wasteful by keeping old or unneeded data occupying large amounts of space. But there isn't much difference in cost so you should do whatever works best for your project. If you can manage to fit your project into less space, that's great. It can be a fun challenge. If you aren't so great at getting everything to fit in less memory, don't worry about it unless you need so much memory that a standard setup won't work.
tepples wrote:
Or you might want to make your game small in order to fit it on a collaborative multicart, if we ever get around to making one of those.
You might be underestimating how cheap memory has become. Maybe I was overpaying, I seem to remember 8Mbit EPROMs being costing almost $10 in the past, but today one could use an 8M
byte NOR flash on a board for little over $2.
Yeah, but that still only gives you so much headroom before you have to start including bankswitching chips or physical selector switches.
On the other hand, I suppose it's unlikely that such a collection would have more than one or two moderately large games at most, so it probably wouldn't be a question of trying to cram half a dozen Donkey Kong Countrys and Star Oceans into one cart. Then again, that might depend on how enthusiastically the developers had embraced the "memory is cheap" design philosophy...
...
My game (if I ever get the thing off the ground) will probably end up fairly large - but then, it's a port from a more advanced platform, which kinda limits your options (see Street Fighter Alpha 2 and Super Road Blaster)...
I have a few concepts laying around on my end for SNES games. For one of them, the soundtrack alone takes up a whopping 8 megabits (and a key reason for that lies in its extremely large number of tracks, which even go farther than what Earthbound has).
I have yet to do any real programming for these games. The same goes for the vast majority of the graphics.
93143 wrote:
Then again, that might depend on how enthusiastically the developers had embraced the "memory is cheap" design philosophy...
To be fair the many-games-in-one-cart idea is the exception to the rule, most games are made on the assumption they're the only thing in the cartridge. Heck, I think the only reason the NES has one such cartridge is because mappers are so common on the NES that you may as well take advantage of that to cram multiple games (I suppose the same reasoning can be applied to the Master System).
I like to think of memory as being cheap, but personally, even if memory is cheap... that doesn't mean it's cheap for all of the other users (nor does it mean you can ship your games through the internet that much faster, as I'm still nervous about online storage... there's more than just offline factors coming into play when it comes to game distribution these days). Thus, I get nervous about shipping a .zip file that's hundreds of megabytes (due in part to how long my music can sometimes get). An 8 MB SNES game, though? Pushing it on non-banked SNES games (12 MB is probably the max if you wanted to max out LoROM and HiROM regions), but for me, that's still easily distributable, and much better than distributing a game that's hundreds of megabytes (especially when it comes to audio).
Well yeah the "memory is cheap" thing being mentioned here is explicitly about those cartridges. I know that 4MB costs about as much as 2MB for example, to the point that the savings would be negligible. Building the cartridge itself will cost a lot more of money than the electronics part.