It's a known fact the size of ROM is not a very reliable way to measure how big is a game, because some games use memory with more efficiency than others.
For example Kirby's Adventure is 512kb PRG + 256kb CHR so you'd expect a very huge game, but no it's for example smaller than SMB3 which is "only" 256kb PRG + 128kb CHR.
I think it'd be cool to build up some algorithm which could measure the ROM efficiency of a game, taking in consideration the amount of levels, size of levels, amount of tileset, amount of musical tracks etc...
Any ideas ?
That's ultimately subjective, but a good start would be to map the ROM using FCEUX's ROM Mapper utility. You have to play through the whole game pretty much, but it will tell you which bytes are code, which are data and which are not used.
This would be a very difficult thing to automate, since each game has its own architecture. There's no easy way to tell how much of the ROM is dedicated to levels, or even how many levels there are.
Also, I doubt anyone would spend a lot of time working on this, because it doesn't really bring any sort of advantage. Game A uses ROM more efficiently than game B, so what? There's nothing useful you can do with that information. I'm pretty sure people would rather spend their time working on things that actually contribute to the development of new games.
Learning how other games made use of their data is helpful to designing new software.
I have learned a lot by looking at the data formats for SMB1, Zelda 1 and Metroid. Mainly I learned that those sorts of extreme application-specific data compression just isn't worth it for my projects. I am not trying to squeeze onto a 32 KB ROM chip or an FDS disk. I still use compression, but it's not as insane as Zelda 1's.
Sure, I'm all for studying the solutions used in existing games, I just don't see the need for a tool that analyzes ROMs automatically, mainly because it would be overly complicated and probably not very accurate.
If you've played a game (meaning you know how long it is) and you've looked at the sizes of its ROMs, it should be obvious whether it's using the space efficiently or not, enough for one to decide if a game is worth studying or not. I fail to see any significant advantages a tool that analyzes games could provide.
I agree on the tool part, however you can't just look at the size of the ROM image either. For instance, Zelda 1 is a 128 KB ROM, but much of that space is unused. This blew me away when I read it. I thought surely a game with a compression scheme as painful as Zelda 1 needed every last byte in the ROM, otherwise why would they compress the data like that?
SMB1 on the other hand uses every byte of it's ROM, and even stores some data (such as the title screen layout) in CHR-ROM and reads it via the PPU.
What tool are you talking about ? I never talked about a tool !
I was speaking about some formula that would involve one person analyzing a NES game, the number of levels it have and the size of the levels, the amount of graphics it uses, and the amount of different songs, and produce some "magical number" out of those number.
Then this number divided by the ROM size would become the efficiency factor. Of course this involve exploring the game completely and it time consuming so I'd never have plans to do this alorithm for all games, just some well known games.
Maybe if entiere PRG banks in the game are unused this should be taken in account but otherwise this would just be an indication of how efficient the game is, nothing more. (so if the game don't use all it's ROM it will just loose some points of efficiency which is perfectly logical because the developers could have added levels to fit all the ROM).
About Zelda this is a bad exemple as the original was a FDS game. I suspect that FDS ports don't use efficiently their ROM. This "test" could confirm or reject this hypothesis...
The test would really be something simple like :
N = a*#of levels*size of level + b*#of tunes + c*#of graphics
efficiency = N / Rom size
Of course the constants and units to measure actually the amount of levels/graphics would be complicated
Bregalad wrote:
For example Kirby's Adventure is 512kb PRG + 256kb CHR so you'd expect a very huge game, but no it's for example smaller than SMB3 which is "only" 256kb PRG + 128kb CHR.
Kirby also has a lot more unique graphics than SMB3, and possibly less scrolling constraints (e.g. no 2-screen-tall level limit) that impact how it can compress levels. SMB1 is efficient, but it's also very repetitive and constrained.
qbradq wrote:
I agree on the tool part, however you can't just look at the size of the ROM image either. For instance, Zelda 1 is a 128 KB ROM, but much of that space is unused. This blew me away when I read it. I thought surely a game with a compression scheme as painful as Zelda 1 needed every last byte in the ROM, otherwise why would they compress the data like that?
Because they probably compressed the data in the same way that the FDS version did. An FDS game doesn't have access to all its data at once; it has to spin up the tape[1] every time it wants to load a different set of files, and sometimes it even has to prompt the user to switch banks ("SET SIDE B"). And there weren't any ROM chips between 512 Kbit and 1 Mbit.
And lack of ROM efficiency alone isn't enough to call its developers incompetent. Failing to fill the space to an even power of two with extra levels could just mean the level designers didn't have enough time to implement and properly balance a longer game. (See
Ending Fatigue and
Xen Syndrome.)
[1]FDS uses a Mitsumi Quick Disk mechanism. Quick Disk is a tape that rewinds quickly.
Compressing the file is often an easy way to tell how efficient the game data is stored.
In my tests (running APACK on NES games for my GBA flash cartridge), Codemasters's games are the biggest 256k games, especially Cosmic Spacehead.
I'm sure everyone's seen it before, but at the end of the
Programming M.C. Kids article, there are data statistics for size and compression.
I think programming efficiency should be measured as a ratio between rom size and fun. This would need to be expressed as the equation:
Code:
rom size
--------
fun
Any of the standard measurements for fun (smiles per minute, satisfaction per achievement per minute, etc) would be acceptable.
If the game has 0 fun (just for the sake of argument; this is not actually possible), then the ratio will be infinity, which means the chances of you caring about the game are 0, so the rom size won't matter.
If the game has a measure of 907.18 smiles per runthrough (commonly referred to as a ton of fun), then the ratio will usually be very low (almost 0), and chances are, you'll play it no matter what the rom size is.
Dwedit wrote:
Compressing the file is often an easy way to tell how efficient the game data is stored.
Cool. Then I can encrypt in-game text and CHR data with a stream cipher, and I can look all efficient while tracing prototype leakers.
Quote:
In my tests (running APACK on NES games for my GBA flash cartridge), Codemasters's games are the biggest 256k games, especially Cosmic Spacehead.
That's because Codemasters were
also Codecmasters.