24

I am only talking about games developed by Nintendo itself.

I know that NES Super Mario Bros. was written in assembly. (Here is an SE answer saying the same.)

They must have switched to a higher programming language at some point because obviously today they are no longer using assembly ;-)

When did it happen?

Perhaps someone knows the first game no longer written in assembly. (Or at least assembly was not the primary language.)

I'm not asking about NES games only because the change probably happened later.

I know Nintendo had many games and platforms. But it should be possible to roughly say when they started to prefer a higher programming language for their games. Even if they didn't change everything everywhere at once.

17
  • 7
    Is there any evidence that they did 'switch', as distinct from using whichever tool was suitable for a particular case?
    – dave
    Feb 5 at 20:21
  • 9
    There's no such thing as "C or Assembly". They go very well together and there can be an "and", just depending on what's most suitable for the task at hand.
    – tofro
    Feb 5 at 21:36
  • 13
    This seems to be based on a false assumption that there was a company wide synchronized one way change ("switch") from one language to another.
    – Raffzahn
    Feb 5 at 23:44
  • 13
    I worked in a development studio that produced games on GB Color and Gameboy Advance. I know that the GB Color source was assembly, but the GBA code was in C. I'm pretty sure that Gameboy games generally were produced in assembly as the SDK provided by Nintendo didn't include C compilers, mainly because there were no decent ones available for the Z80 at the time and hardware resources (ROM and RAM) were so limited that you had to manage them manually anyway. N64 definitely had C compilers - we converted an N64 game to PS1 and I remember seeing the source code. Feb 6 at 10:51
  • 2
    @UncleBod Do you like an SE answer better?
    – zomega
    Feb 6 at 16:22

5 Answers 5

16

To give a very general, but pragmatic answer, you could say around the time of the N64. Nintendo 64 games were largely written in C. From the Ultra64 Fan website:

N64 game applications are written in the C programming language. However, an N64 game program is structured somewhat differently from a general C language program.

If you would like to read more about C and the N64, the Ultra64 website has a good bit of documentation

That is not to say N64 games never incorporated assembly code. Particularly for games that pushed the systems limits, like some of the Star Wars games, Indiana Jones, and Perfect Dark, Factor 5 and Rare respectively utilized their own microcode. Certainly some other developers did, but Factor 5 and Rare are the most talked about cases.

This old IGN interview with Factor 5 mentions custom microcode used for Rogue Squadron and Indiana Jones

For Rogue we already had done some changes, but when we started Indy, we just started from scratch, threw away Nintendo and SGI's microcode and wrote everything from the ground up. Our new microcode allows almost unlimited real-time lights and a much higher polygon count than the original.

So to give a calendar year, Pilot Wings and Super Mario 64 were the 2 release titles in early 1996. Pilot Wings development was started mid-1995, Super Mario 64 development was probably started in 1994.

The Nintendo 64 launch title’s “Period of Creation,” the document reads, started on September 7, 1994 and lasted until May 20, 1996, which was one month before the game’s June 23 release in Japan. All told? 622 days.


Okay, with that being said, why am I claiming the N64 is the big tipping point? Simply put, games for Nintendo's earlier consoles were written pretty much exclusively in assembly.

The SNES is a little bit hard to say, over the years I have read hearsay on the internet of Japanese only releases being programmed in C, people have also claimed there's evidence of C-strings in some decompiled SNES game ROMS. Various arguments can be seen in this forum thread. I'm not going to provide any quote from this one because no one in this exchange actually provides hard evidence. It might be worth a read if you want some talking points to look up further.

There's also discussions online about compilers like ORCA/C being used for the SNES back in the day... I can not find a source confirming a specific SNES game that was written using one, though. I may just be blind.

The other possible X-factor is the Virtual Boy. It was released in 1995 near the time frame of the N64, but it's hard to find info on. I think Virtual Boy games were done in assembly, and the "Virtual Boy - Sacred Tech Scroll" gives an outline of the hardware if it's of any interest. It looks like the modern day Virtual Boy homebrew community does development in C using a patched version of the GNU compiler, I can't find evidence that C was used at the time, though

Ever since the homebrew community started using patched copies of GCC, the GNU C Compiler, to compile their code, libgccvb has been the de facto standard library, used by almost every Virtual Boy homebrew project ever made. It is a leightweight collection of functions that provides some basic functionality to interact with the hardware.

4
  • 2
    The last comment in the needed forum thread name drops SimCity 2000. I threw it in a disassembler and it definitely looks like generated code. The function prologues don't look like any 65816 compiler I'm aware of (zardoz c, orca anything, apw c, mpw pascal IIgs, etc). Thanks to the wayback machine I was able to find a demo of the avocet 65816 c compiler and there are some intriguing resemblances (all functions start with a REP) but enough differences that it doesn't look like avocet either. Perhaps with the right directives.... Feb 7 at 3:46
  • 6
    "I used Zardoz C to make the original FIFA soccer on the Super Nintendo. Of course there was a lot of hand rolled assembly but a lot of the UI and some parts of the game were written using Zardoz. The ability to use the DP as the base for local variables meant the code generation wasn't too terrible." -- news.ycombinator.com/item?id=31916359 Feb 7 at 4:08
  • Pretty cool info Kelvin, thank you for finding that source
    – zippy
    Feb 7 at 11:50
  • 3
    Super Mario 64 was infamously compiled in debug mode (optimizations disabled) since it was one of Nintendo's first C projects and they didn't want to break the first version that was already working.
    – user253751
    Feb 8 at 23:58
34

The question seems to been written under an assumption that there must have been

  • a company wide
  • one way change ("switch") from one language to another
  • that change being company wide synchronized
  • across all platforms and
  • across all projects and
  • no parallel usage and
  • not going back and forth

This seems like a rather outlandish expectation. Whats good for one game may not work for any other, more so what does on one platform may rarely work on others. In 2001 Nintendo for example supported 5 (6) different consoles in parallel:

  • Famicom 1983-2003
  • NES 1985-1995
  • SNES 1990-2005
  • N64 1996-2002
  • GameCube 2001-2007
  • Game Boy 1989-2003

Dates are for the consoles, new games were usually introduced by Nintendo over the whole time span.

Those platforms span from 1.77 MHz 8 Bit 6502 all the way to 100 MHz 64 Bit MIPS. All in parallel. But not only platforms, but also games differed greatly. In the end it comes down to each platform and project seperatly.

Last, but not least, it's known that Nintendo used HP 64000 development system. First for their arcade machines and later of course for consoles. The HP system was quite beloved as it wasn't tied to a certain CPU family, like systems offered by chip makers, but used the same tools and workflow (mostly) independent of target CPU and system. It offered Assembler as well as Pascal and C compilers. Nintendo used its Pascal compiler for some arcade games predating the NES, so I would expect them to do the same with the NES and later systems.

Especially for the ORCA* suit offering Assembler, Pascal, C, Modula-2 was well received with professional 6502/65816 developers. Not at least due it's seamless integration of mixed language programming (HLL for the logic, Assembler for critical parts). In fact, at the time maybe more often PASCAL than C.

A major problem here is that Nintendo was always quite secretive with information about their development environment. The use of HP 64000 is only known due some photos. Other known HP 64000 users were Konami and Coleco. A definitive answer might need some serious code archaeology.

In the end, HLL based game development was there from the very beginning, and it's interleaved with Assembly still today.

8
  • 4
    Even if the change wasn't made company wide and on all consoles there must be a game where Assembler wasn't the primary language for the first time.
    – zomega
    Feb 6 at 16:34
  • 23
    The OP may have assumed those things, but the question is perfectly meaningful and answerable without them. The only core assumption is that assembly was once a major part of their toolchain, and is now much less so, compared to high-level languages. It’s like asking “When did farmers switch from oxen to tractors?”, which has all the same subtleties — the change was/is gradual, halting, complicated, unevenly distributed, and incomplete — but there has obviously been a real change, and one can describe its timeline. The subtleties are part of the answer; they don’t disqualify the question. Feb 6 at 19:12
  • 4
    I'm upvoting since this is a good start to a complete answer, but the final paragraph is a reach, because at some point Nintendo did start using semi-managed runtimes for first-party games. I recall seeing a C++ stack trace from Wind Waker once during a crash, for example.
    – Corbin
    Feb 6 at 20:26
  • 1
    @zomega Point is, as mentioned, that HLL as primary language was used by Nintendo on (8 bit) arcade games already before the very first console game, so the implied change never happened.
    – Raffzahn
    Feb 6 at 20:45
  • @Corbin 'Managed runtime' ?? Not sure what that is supposed to mean in this context, as it's not intrinsic to using a HLL. There were HLL systems way before C++.
    – Raffzahn
    Feb 6 at 20:48
14

There's evidence of the existence of source code projects and compilers in at least Nintendo 64 launch titles.

Doom was a C project so presumably that port was probably also in a high-level language.

Given how C and C++ work, that does not preclude the use of assembly for critical sections of code even now.

4
  • 7
    The Nintendo Doom port wasn't developed by Nintendo. Ooh, it looks like the Doom/FX source code is available and it's all assembly. There were at least 2 C compilers used for SNES development -- Zardos C and Byte Works ORCA/C (in particular the Macintosh Programmer's Workshop cross compiler version). Those were used by 3rd party developers, not necessarily Nintendo. Feb 6 at 0:10
  • 1
    @KelvinSherlock The ORCA/* toolchain (Assembler, Pascal, C, Modula2, BASIC) was quite popular with 6502/65816 developers during the 80s and way into the 90s. Not at least due it's seamless integration of mixed language programming (Pascal/Modula/C for the logic, Assembler for critical parts). In fact, at the time maybe more often PASCAL than C.
    – Raffzahn
    Feb 6 at 0:48
  • 3
    Since OP seems interested in "When", your answer could be improved by adding dates. Feb 6 at 14:24
  • 2
    Super Mario 64 was an N64 launch title, written in C by Nintendo.
    – user253751
    Feb 8 at 23:59
5

An aspect of development which hasn't yet been mentioned is that many games are developed using what are called "domain specific languages", which are often tailored around the particular needs of a game. Rather than writing machine code to explicitly accommodate each and every possible interaction between objects in a game, a game's author may use an external program to translate something like:

    CPNZ WIZ.ROOM,CURRENTROOM,NOWIZ
    CPNZ FBLIVE,0,WNOATK
    SIGHT WIZ.LOC,PLAYER.LOC,WNOATK
    SOUND FBLAUNCH

into a bunch of data which the game program can process to:

  1. Check whether the data at a certain location (which happens to have been assigned to the WIZ data structure, at an offset assigned to ROOM) differs from the data at a different location (which happens to have been assigned to CURRENTROOM), and if they differ start processing table entries at the address assigned to NOWIZ.

  2. If the above test reported the room was equal, test whether FBLIVE equals zero, and if not start processing table entries at WNOATK.

  3. Check whether the XY coordinate structure starting at the address assigned to WIZ.LOC and the structure starting at the address assigned to PLAYER.LOC identify positions that are line-of-sight to each other; if not, start processing table entries at WNOATK.

  4. Play the sound whose index is given by FBLAUNCH

I don't know what kind of DSL was used for games like Zelda and Pokemon, but domain-specific languages can tremendously assist in their development. In many cases, it's hard to rigidly categorize domain specific languages as being high-level or low-level, since they often combine low-level semantics (e.g. identifying objects by address) with high-level operations (e.g. performing line-of-sight checks), and I don't know any specifics about what DSLs were used in Nintendo development, but use of domain-specific languages greatly facilitates development of games like Zelda which have a wide range of possible interactions between objects, but only need to consider a few of them at any particular time.

4
  • 2
    I'm upvoting, but more concrete citations would be valuable. One possible research path is into the development of Super Mario 64, which used emulation of high-level APIs along with a high-level managed SDK to develop large portions of the game's logic, and SGI workstations to produce art assets.
    – Corbin
    Feb 6 at 20:29
  • The techniques I'm describing would have been employed during the "8-bit era" for games like the Infocom text adventures as well as for King's Quest, but I don't know of any examples targeting any Nintendo systems in particular. I wouldn't be at all surprised if MULE was such a game, but I know nothing about its internal design.
    – supercat
    Feb 6 at 21:24
  • @Corbin: Certainly large parts of Super Mario 64 were written in C, using a particular identifiable version of gcc, but domain-specific languages had been used in game programming long before that.
    – supercat
    Feb 6 at 21:55
  • Tomorrow Corporation has some blog posts about PunchOut DSLs at tomorrowcorporation.com/posts/category/retro-game-internals
    – ninjalj
    Feb 10 at 9:16
0

The Gameboy Advance was roughly SNES level graphics hardware with a 32 bit CPU. This allowed devs to write a late-SNES level game in straightforward C without the need to drop down to assembly to squeeze every last cycle out of the CPU. From the outside it seems like that was the whole point of putting the ARM core in there. I have no insight into what Nintendo were doing internally though. My GBA experience is writing homebrew for it in C around 2002.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .