Did actual game code get bigger as game machines evolved? (Excluding graphics and audio)

[Lee Bee]

We all know game ROM sizes grew exponentially over time. For example:

NES Super Mario Bros = 32k
SNES Super Mario World = 512k
N64 Mario 64 = 4MB
GameCube Mario Sunshine = 1.3GB

But excluding graphics, audio, (and even text data) - has actual game code grown much, in general? Did it stop growing, and when?

What would you say is a comfortable or reasonable size for game code, including any engines?

[berarma]

Code has usually been the smallest portion of a game by far. Even if it doubled in size it would still be a very small part.

Most of the increase in size comes from graphics and audio, making the code size an even smaller percentage even when the code may have grown in size.

The size of the code can vary a lot. In the first 80s it could be a few KBs in the less complex titles to the tens of KBs in the most complex ones, but when high-level languages, libraries and frameworks started being used it could increase by a lot. When code size stopped being an issue, generic libraries and frameworks would be included without being optimised for the actual title, and sometimes even with a major part of the code not used. This could take the code to the hundreds of KBs.

[Wall_Axe]

Interesting if there's really much difference between snes and nes Mario except graphics, level data, and the snes version had lots of text .
The code governing Mario's movement and collision detection is probably very similar and all you do is run to the right.

Super Mario Sunshine is probably very simple if you strip away the three d engine and physics.

I've never played it but I saw some nice water effects, probably just a mathematical algorithm which doesn't take up much space....but would need a good programmer to accomplish.

The code for a strategy game would probably be the biggest.

It could be that game code peaked around the year 2000 when strategy games were popular. Nowadays it's probably indie strategy games that have the largest codebase.

I can imagine jagged alliance 2 being large as it has several complicated gui screens ,a.i. for skirmishes and the overall strategy on the world map. The combat engine, hospital, weapons, explosions,stealth, day & night, a fully featured laptop in the game with fictional web browser and email client...

The code for a sixty hour rpg would be mostly level data and stats which doesn't count as code.

It could be that the Sims has a large codebase as it took seven years to release the first version I think. Just thinking about the code that controls character responses,buildings,walls,jobs, sleep, cooking...the list goes on .....

Games like grand theft auto could be very simple, as the missions are just mostly travelling to a certain location or killing someone. But it would need a fair amount to control physics and behaviour of NPCs. The NPCs just seem to walk around,they don't sleep or eat like in the Sims.
If you take away the physics engine it could be hilariously simple code.

[AndyC]

Interesting if there's really much difference between snes and nes Mario except graphics, level data, and the snes version had lots of text .
The code governing Mario's movement and collision detection is probably very similar and all you do is run to the right.

Except you don't just "run to the right" in SMW. It's probably similar in complexity to SMB3, which also had multidirectional scrolling, more involved power ups, over worlds, mini games etc. There's definitely going to be a lot more logic there than in SMB1.

On the whole, it also depends on exactly how you define "code" Lots of games use a "data as code" approach, SCUMM being a very famous example, where the actual core engine is running a very simple interpreter and aspects of the game are really configured via higher level scripts.

There's also the effect of native code size. 8-bit CPUs had limited instruction sets and tried to cram the available instructions into individual bytes if possible. 16-bit CPUs were more likely to offer a wider instruction set with 16 or even 32 bit instruction sizes, since they can read larger amounts from RAM in a single cycle. The consequence being that code will naturally grow in size, even if every instruction was a 1:1 mapping. Note this also means what a "reasonable size" for code is can vary widely depending on the exact architecture of CPU you are targeting (and even more so when things like caches get involved on fancier modern CPUs).

[Wall_Axe]

I would've thought that there would be a slight reduction in code for sixteen bit games due to there being more instructions that can do more.
For example it's probably easier to use a sixteen bit number to represent a sprites X co-ordinate on a sixteen bit computer.
Due to there being a need for sub pixel accuracy a lot of the time they were used on eight bit systems .

But I can see what you're saying as every instruction takes up twice the amount of ram?
But if you see it as number of lines or number of instructions,the sixteen bit games could be smaller if implementing the same game on an eight bit system.

I was thinking that scripts don't count but I suppose they do really. I can imagine GTA scripts being very simple,travel to X,trigger cutscene, kill X, travel....

Whereas scumm are probably more complicated. Games like fallout and Knights of the old republic allow you to move during combat which makes them so much more complicated than a jrpg where you just take it in turns and stand still.

[MustardTiger]

16bit code uses two bytes per instruction (minimum) compared to one byte in 8bit, so code size would increase just for that reason. Additionally 16bit games have more complicated gameplay logic and resource & memory management compared to simpler 8bit games and all that takes more code.

[Ralf]

The code got bigger because the games got bigger. If a game has more content then it requires more code to deal with that content.

Another thing is a shift from games written in pure assembler to games written in higher languages or a mix of a higher language like C and assembler.

It raises an interesting problem - how should we compare a program size of a program written in assembler vs a program written in C.
Higher languages like C or even Basic are more concise. You realise with one instruction an operation which may require 50, 100, 200 or more assembler instructions. Think of something like drawsprite (spriteNr, x, y)

So if we compare length of visible code text then C is an obvious winner.
Yet C code gets finally after all compiled to assembler. And compilers may be inefficient. Or include unnecessary libraries. So a real compiled C code may be bigger than a program in assembler doing the same thing.

So yes, the code became bigger. But as the other have said, it's not the main reason behind increase of games size. Code usually makes only about 10% of game size, the rest is graphics, sound and level data.

[Vampyre]

Another thing is a shift from games written in pure assembler to games written in higher languages or a mix of a higher language like C and assembler.

It raises an interesting problem - how should we compare a program size of a program written in assembler vs a program written in C.
Higher languages like C or even Basic are more concise. You realise with one instruction an operation which may require 50, 100, 200 or more assembler instructions. Think of something like drawsprite (spriteNr, x, y)

This reminds me of an argument in the letters page of an early Edge magazine back in 1994/95 between Jon Ritman and Glenn Corpes (Bullfrog - Populous, Magic Carpet etc). It was really interesting and sums up what Ralf has posted.

Jon Ritman sent a letter in about how he'd developed Quintessential Art Of Desctruction for Cranberry Source in pure assembly, and that every games programmer of any renown/self-respect should be programming in pure assembly for the speed of code over any other language.

In a subsequent letter Glenn Corpes ripped this argument to pieces. Glenn maintained that other than a handful of assembly the entirety of Magic Carpet had been written in C. His argument was, due to the optimisations of the C compiler (which don't exist in assembly), that if he'd written the engine code in pure assembly there would be at most a 5% increase in speed - and it would have taken ten times longer and twenty times the amount of code. The payoff of assembly wasn't worth the end result.

[Vampyre]

Just re-read LB's original post:

NES Super Mario Bros = 32k

32K!! Which is the entire thing - code base, graphics, sound etc. That's some supremely efficient coding. My poster child for code efficiency has always been Ultimate fitting Jetpac into 16K. But this is another level.

Edit: Been doing some digging and found "SMB is 40KB of data, 8KB being graphics (just the tiles themselves), and the other 32KB being program code, music and sound effects, and level data."

But still... 40K - astonishing.

[AndyC]

This reminds me of an argument in the letters page of an early Edge magazine back in 1994/95 between Jon Ritman and Glenn Corpes (Bullfrog - Populous, Magic Carpet etc). It was really interesting and sums up what Ralf has posted.

Jon Ritman sent a letter in about how he'd developed Quintessential Art Of Desctruction for Cranberry Source in pure assembly, and that every games programmer of any renown/self-respect should be programming in pure assembly for the speed of code over any other language.

In a subsequent letter Glenn Corpes ripped this argument to pieces. Glenn maintained that other than a handful of assembly the entirety of Magic Carpet had been written in C. His argument was, due to the optimisations of the C compiler (which don't exist in assembly), that if he'd written the engine code in pure assembly there would be at most a 5% increase in speed - and it would have taken ten times longer and twenty times the amount of code. The payoff of assembly wasn't worth the end result.

This is one of those rare cases where I'd say Ritman was wrong. He's only wrong because more modern architectures, like the PC, are designed around C compilers in a way older ones weren't though. The Z80 instruction set really does not lend itself to C, register usage isn't very orthogonal, parameter passing via the stack is very suboptimal and there aren't nearly as many opportunities for optimization. It's a very different world in x86, where C compilers can thrive (especially over the years where the architecture has moved more towards supporting compilers rather than hand coding).

[Timmy]

This is one of those rare cases where I'd say Ritman was wrong. He's only wrong because more modern architectures, like the PC, are designed around C compilers in a way older ones weren't though. The Z80 instruction set really does not lend itself to C, register usage isn't very orthogonal, parameter passing via the stack is very suboptimal and there aren't nearly as many opportunities for optimization. It's a very different world in x86, where C compilers can thrive (especially over the years where the architecture has moved more towards supporting compilers rather than hand coding).

Well, if you have seen my game tutorials for several Z80 based machines, you'd see that I use assembly when it's needed, and c when I want to write the faster version of the code that I'd otherwise use Basic code. Of course that might require me being adequate (i.e. not very good) in both languages.

Fortunately I'm not a renowned/self respect coder then.

Also, on a 48k machine, everything is a compromise. You can use C, but it will cost you more memory. You can use an existing sprite engine, that will costs you even more memory. Or you could write your own and it will costs you more time. And I'm a really lazy person, so...

[Lee Bee]

As a non-coder, I'm still trying to get some idea of how much code is "enough" for most games? What is a comfortable amount to work with?

Speccy games are mostly all under 48k. Maybe we could double or quadruple this for SNES or N64 games to give the code more "breathing room"? But what about a game on a 4GB DVD - is the actual game code likely to use more than a few hundred k? Surely there has to be a cutoff of how large game code needs to be?

[AndyC]

Surely there has to be a cutoff of how large game code needs to be?

No. The more code you can have, the richer your game world can be. The more nuance you can implement, deeper and richer your AI can be.

There's never really "enough" space, things get trimmed to fit in the memory and processing time available. Almost every game ever written probably had "dropped" features that could have been included if there was more time to develop them, more free RAM in the target system or just a bit more CPU grunt that would've allowed it without slowdown.

[Lee Bee]

No. The more code you can have, the richer your game world can be. The more nuance you can implement, deeper and richer your AI can be.

That is fascinating, and something I hadn't considered before.

But while having too little space to code can no doubt be frustrating, I'm guessing that having too much space could lead to a daunting or stressful experience for a lone programmer where he's just overwhelmed with too much possibility and not enough time? This is certainly true of graphics, which is what I love about the Speccy.

I wonder if there's a "sweet spot" of code size that provides the most fun experience for a lone programmer?

[equinox]

No. The more code you can have, the richer your game world can be. The more nuance you can implement, deeper and richer your AI can be.

There's never really "enough" space, things get trimmed to fit in the memory and processing time available. Almost every game ever written probably had "dropped" features that could have been included if there was more time to develop them, more free RAM in the target system or just a bit more CPU grunt that would've allowed it without slowdown.

In other words the cut-off is the imagination of the overworked programmer dork.
AI would fix everything, if only we hadn't cut off AI's knees so that it can only say "you seem to be suggesting something creative, that is unacceptable..."

[AndyC]

That is fascinating, and something I hadn't considered before.

But while having too little space to code can no doubt be frustrating, I'm guessing that having too much space could lead to a daunting or stressful experience for a lone programmer where he's just overwhelmed with too much possibility and not enough time? This is certainly true of graphics, which is what I love about the Speccy.

I wonder if there's a "sweet spot" of code size that provides the most fun experience for a lone programmer?

It's a double edged sword. Certainly there is some truth that limits can help creativity, but for every "there were features I wanted to add but I ran out of memory" you'll find someone re-writing code for the thousandth time in order to make it smaller so they can fit that one last feature in. Once you get to the 16-bit and above sort of size both the practicality of having and need for a team of coders is more likely anyway.

The other thing to remember is that it's ultimately the programmer who has to juggle all the memory in the system, not just for their code but all the run time data structures and assets etc. if I found myself on a project where I was told I could only have 6K of code because "we need the rest for graphics and sound" the absolute first routines I'd drop would be support for any kind of graphics/sound compression and said artists would find themselves working in a much more restricted space than they otherwise would have....

[equinox]

The other thing to remember is that it's ultimately the programmer who has to juggle all the memory in the system, not just for their code but all the run time data structures and assets etc. if I found myself on a project where I was told I could only have 6K of code

yes mate we know you can't draw

[AndyC]

yes mate we know you can't draw

I'll have you know my programmer art is some of the finest abstract art ever conceived. Sure, everyone things it looks like garbage and their children could do better, but all true great artists are underappreciated in there time...

[equinox]

I'll have you know my programmer art is some of the finest abstract art ever conceived. Sure, everyone things it looks like garbage and their children could do better, but all true great artists are underappreciated in there time...

shut up Jeff Minter
WAIT, I take it all back, that is an amazingly regular hexagon

[Ralf]

As a non-coder, I'm still trying to get some idea of how much code is "enough" for most games? What is a comfortable amount to work with?

Let me give you some estimate, how much space is needed for different things in a game:

graphics: 5 - 20kB
level data: 5 - 20 kB
music: 5 kB
screen buffer: 5 kB
code: 5 kB

It depends a lot on the kind of your game. Some games don't have music. Some games use screen buffer and some don't. Some have a lot of text while others have barely any text. Some have a lot of graphics while other ones have simplistic graphics etc.

But in most cases the actual code is the smallest part, taking only 10-20% of memory.

And being "comfortable" with big code is a subjective thing. If your code is well structured, bug free and well documented then you can manage and expand it practically without limits, the only limit is computer memory.

On the other hand, if your code is hacky and messy then you'll soon get lost in it and won't be able to add new things unless you rewrite it.