I often think about how crazy it must have been to be a game developer around this period. Almost every bit of design, math, coding knowledge was flipped on its head. Overnight developers who were managing relatively simple XY coordinates suddenly had to discover the complexities of 3D rotations, perspective math, and probably more linear algebra than they ever really expected to know.
It’s even crazier we got masterpieces like Mario 64 so early into the first 3D console generation.
I was confused why you mentioned haptics, as the Rumble Pak did not exist when the N64 launched. But Wikipedia cites EGM as saying later versions of the game had Rumble Pak support: https://en.wikipedia.org/wiki/Rumble_Pak
There wasn't much knowledge out there in the early days (80s), either. You couldn't look stuff up on the Internet. I tried to independently discover the formulas for 3D perspective by sitting with graph paper and trying to reverse engineer them. I had to look up books on 3D graphics theory and wait weeks for my local library to get them on an inter-library loan.
I personally feel very lucky that I experienced the days were we had to wait for the updated MSDN DVDs to arrive so we can check out the new docs/code samples and make changes to our drivers and docs! Good times.
Doom had been a few years before but what Mario 64 really bought to the table was a super intuitive analogue control stick rather than tank controls and tons and tons of polish
Mario 64 was two years ahead of its time, at a time when two years was like 10+ years now. Hardware acceleration, colored lighting, skeletal animation, free camera*.
Quake (World) was a huge achievement graphically but I feel like its real contributions to history ended up being internet play and WASD
Both games were mind-blowing then and are still fun now.
* It's nuts to me that we had to wait until 2004 with San Andreas to get a modern "left stick moves, right stick looks" in third person games. The N64 was 90% of the way there, but didn't stick the landing for whatever reason.
Of course this depends on your definition of "equaled", but GTA5 is the single highest grossing entertainment product of all time. I'd say it dwarfs all other games ever made to date by a long shot.
First of all, DOOM isn’t raycasted. Second of all it’s 3D in the sense that all objects have xyz coordinates and can move in that space. You can miss the monsters by having a rocket go over their heads. The main limitation is that the levels couldn’t have more than one ‘room’ per vertical space.
The rendering can still be implemented as polygons (making it true 3D rendering) whilst still maintaining the same level-based limitations, as we can see with DOOM 64.
Yes, Doom renders walls in a way that is broadly similar to to how contemporary GPUs work. Doom sorts the walls in view space via the BSP tree, transforms them to screen space, breaks them into non-overlapping spans of screen columns, and then fills each column’s pixels with the wall’s textures. The floor and the sky are not geometry.
Doom is definitely raycasted. John Carmack was on the Lex Fridman podcast a few years back and talked about the Doom implementation coming off of Wolfenstein 3D:
https://www.youtube.com/watch?v=I845O57ZSy4
Most people would call DOOM a 3D game. Its popularity spelt the end of 2D games which is why people bring it up.
It doesn't matter that it's raycast with billboard sprites, it was first-person-perspective with pixel-perfect lit texture-mapped wall and floor rendering with lifts and stairs. 3D enough.
I just went down a quick rabbit hole and discovered the vector-based gamed machine Vectrex which in 1983, well before the 1995 Virtual Boy, had a "3-D Imager" head-mounted stereoscopic display. I wonder if that gets the claim for the first "real 3d" video game.
If you could perceive real 3D, you would be able to "see" completely everything in a scene, including the back of objects, or objects behind other opaque objects.
As a Marathon fanatic, it killed me that the game didn’t get more love. I recall watching a Doom game and someone shot a rocket at a player above them. The path of the rocket was bizarre and being baffled that this was ‘good’.
It was a fun era to live through as the progress was so quick.
I only really got into Marathon several years ago and played Doom/Doom 2 not too long afterwards. IMHO there is a serious case to be made that Marathon is superior on every axis (music/sound excepted) but I absolutely understand why Doom had greater mass appeal. They're both a lot of fun but for me Marathon 2 is tops (and there are a LOT of homages to the series in later Bungie games - the 343 Guilty Spark escort level in Halo: CE is basically a redux of the alien ship crawl waiting-for-doors bullet hell level from Durandal).
I still have yet to finish Duke 3D. Next time I'm in between jobs I'll hit it up.
> the alien ship crawl waiting-for-doors bullet hell level from Durandal)
"If I Had A Rocket Launcher, I'd Make Someone Pay" [1]?
But yes - my impression was always that the Doom games mostly focused on having cool levels, with plot as an afterthought. Marathon gave more of a sense of the levels having been designed around a plot.
> But yes - my impression was always that the Doom games mostly focused on having cool levels, with plot as an afterthought.
My understanding is that yes, and that was part of Tom Hall parting ways; based on the alpha versions and the 'Doom Bible' it was intended to be a more story driven experience, closer to Marathon.
That said, The engine could support such at least with some enhancements. Strife is still one of my favorite games if that era thanks to the 'living world' feel, even if it has some nasty ways to get in a hostile overall world state or dead end.
doom's rendering is 2.5d (but is still fully accurate to 3d rendering, if the pitch of the camera is fixed to 0), but doom's _logic_ is fully 3d (the only reason enemies were infinitely tall was to save on cpu speed (and different to enemies, projectiles always had full 3d collision), it was just a few lines of code change to make them have real height for player-enemy collisions, which was done in heretic, another game using the same engine as doom)
Yeah I meant less that 3D games were invented out of nowhere when the PS1 or N64 released. It's more that a large majority of developers, especially ones on console, were thrust from 2D to 3D development.
When we started Abomination[0] it was born from X-Com which was totally 2D. It was assumed this was going to be 2D. Then we tried to create all the characters and monsters we wanted and ran out of RAM instantly with all the rendered angles.
Slapping my own 3D engine on wasn't too hard, but there was no tooling in those days. How do I get the meshes and textures out of 3D Studio Max into the engine? Who can I call? Nobody. You had to work all this stuff out from first principles. It was a grind.
Doom controls are horrible, you dont really walk or run, its just a horrible slide or move in that direction. Not saying Mario is perfect but it does feel more realistic in comparison and its a very good first attempt considering there was nothing like it before.
3D had been in arcades earlier (e.g. Virtua Racing in 1992, four years before) but having to figure out how platforming works in 3D was the true genius. They really knocked it out of the park.
Imagine their dismay when they realized they actually need 4x4 matrices and weird math invented in the 19th century.
Just getting 3d triangles working is a mess (winding order, normal direction, etc). Clipping them correctly as they intersect the view frustum is a next level nightmare if you don't have a known-good implementation or reference text available.
> Starting from 2022, Emanuar would begin uploading videos discussing Nintendo 64 technical details and optimization techniques,[15] along with outlining Super Mario 64's bugs, technical shortcomings and poorly optimized features, fixing them in the process.[16][17][18][19] He would heavily rework the game's source code in 2024 and use it as a base for his collaborative ROM hack Return to Yoshi's Island, which resulted in increased frame rate and improved graphical fidelity compared to the original game, even when running on the original Nintendo 64.
He has worked with folks and repos under the HackerN64 collection, which has some generic forms of these optimizations. As for the actual code for each specific game I think he only releases it when he's ready to release the games.
> I think that is fine-tuning. Many, many, many hours and days spent actually sitting down and playing the game.
Turns out quality takes time. Who would have thought. Very few games reach this level of fine-tuning, because it takes dedication (and budget).
Funnily, it's almost conflicting with this answer:
> Was much changed during development?
> Apart from the number of polygons use, the characters were first-off – once they were designed, they went straight into the game. There wasn’t really a lot of changing, artists just kept supplying stuff that just got put in the game, conveyor-belt style. That was more or less because of a very, very tight deadline – it had to be out right when the N64 came out.
So it's more nuanced. You fine-tune the fundamentals, but not necessarily everything.
Yes, fine tune the fundamentals of "is this thing fun to control". Content is a separate thing which I personally think is where a lot of modern games have gone wrong.
Nintendo are known for developing prototypes to figure out what is fun. Unlike modern "implement the design doc" process. There's a YouTube interview with someone from retro studios who explains this, Nintendo weren't interested in their design docs for metroid. I am hopeful remembering this correctly.
I haven't read this Goddard interview yet, but he was responsible for one of the best games of all time, 1080 snowboarding! What is completely bananas is that him and his mate ended up working at Nintendo and showing them how to do 3d graphics when they were teenagers.
The invested time consistently into the things that were important to improve. If the art was good as-is (and it was), they didn’t waste time “perfecting” it further.
But as long as the gameplay itself still felt fuzzy or like there was friction, they spent time improving it up until their deadline. This was not a lack of project management, this was project management actually done well, for once.
In fact they accidentally optimized Super Mario 64 around its debug-mode performance, and shipped the game in that state, with debug symbols and everything. But they could get away with that because the game they shipped still landed in the performance budget they needed for the gameplay they were after.
Fine tuning is a huge deal. I made some simple games and spent a lot of time on fine tuning little details about the movement trying to nail the right "feeling". The feeling of Mario's movement in Mario 64 is excellent. That feeling immediately makes the game fun even when just jumping around aimlessly.
It's very difficult to get right. Even with the exact same programming logic, tiny tweaks to certain numbers around velocity, acceleration, friction, impulse, etc all can have a huge impact on feel. So even without changing anything besides a single static value here or there you can make the game feel very different. (and then of course you can also add more logic and tweak things endlessly, like adding coyote time, jumping higher when you hold the button, nudging the player slightly into place instead of stopping flat if they are grazing an object... and then other things like sounds and animations can themselves completely change the feel without changing the systems at all)
Feel is also something that is very subjective. Some people might like something that feels very tight and responsive, some people might like something that feels more floaty or forgiving. I tweaked one simple game I made to be a bit quicker and tighter, which caused more casual players to feel it was too hard and quickly stop playing, but more competitive players got highly engaged and played over and over to climb the leaderboard.
The thing I'm always struck by with these kinds of interviews is just how mundane it really was. We tend to ascribe this sort of legendary status in retrospect to projects like this that makes it seem like it was an elite group of techno wizards in Valhalla who spent their life's effort on it. But very very rarely is anyone thinking "this is the most groundbreaking revolutionary work ever achieved that will be adored by millions for generations" at the time, it's just regular joes showing up to the office and saying "yeah this was a thing I worked on for a year back in the 90s".
>Giles Goddard (born 30 March 1971) is an English video game programmer. He was one of the first Western employees at Nintendo
>[Argonaut Games, Giles's first job] produced a 3D graphics demo for the Nintendo Entertainment System and collaborated with Nintendo [0]
To my uninformed self, this sounds extremely impressive to get a 3D graphics demo on the NES. Oh I would love to see how that looked. All I could find is that it was based on Argonaut's Starglider title from the Amiga [1]
Based on that, I believe Giles is mistaken in the Eurogamer interview cited by Wikipedia. The demo was on Gameboy, not NES. The also-linked NintendoLife article also mentions the demo was on the Gameboy. But I guess maybe that's actually more impressive!
There was a NES and later SNES prototype (By Pete Warnes and Carl Graham) that was IIRC the focus of the 3D chip discussions. X was cool, and a good selling point (and predated the NES work), but there was (again IIRC) no interest on going further with 3D on GB.
Seeing custom hardware on carts (Pilot wings, Mario Kart?) and having dealt with the custom hardware on the Konix, gave Jez a good avenue to explore with Nintendo.
The 6502 can do wireframe and pseudo-3D. 3D has a lot of different types and levels, but prior to this there already wireframe and pseudo-3D products out there.
NESGlider was a wireframe demo. Of course very impressive technically but just a tech demo. The 6502 chip spent almost 100% of its processing power just calculating the 3D lines, leaving very little room for smooth gameplay or filled-in polygons.
Hadn't heard about that before. Argonaut and Nintendo also co-developed a 3D game called "X" on the Game Boy, that might give us an idea of how it could've looked.
> How many people were on the Super Mario 64 team?
> Probably about 15 people in the end.
Whoa, a much smaller team than I imagined! It must have been fun working in this group!! The rest of the interview is also cool but was impressed with this small number!!
One thing I find really interesting is how the move from industrial society to information society involved such small teams for new products. Look at the huge teams needed to make a new ship design or airplane or even things like washers and dryers and such. Its a lot of different roles. Some of these projects had hundreds if not thousands of people involved.
Meanwhile, some of our most amazing software came from groups under 150 people. The original Macintosh was just 125 people. The NES was a core team of 4 to 5 engineers. The original iPhone team was 200 people. The original Amiga team was 30 people. Windows 1.0 started with 13 people. Windows NT started with 12 people. Microsoft Excel was originally 5-7 people. Google launched with six people and its 1999 staffing level was around 40 people. Some classic video games from the 80s were made by 2 or 3 people, often just 1 person. A lot of 90s games had teams of 5-30 people.
You could drive past a sleepy office park with a tiny office and inside would be 50 people who would change our software world significantly. I find that really interesting and romanticized a bit.
It's incredible how small the teams were on some of Nintendo's best games.
Ocarina of Time & Majora's Mask were 40-50 people. If you look at the credits for modern games, they scroll for minutes at light speed. The entire credits are ~100 people on those games.
Some of that inflation is because localizing games takes more people now. Back in the day it might have been one person per language for 2-10 languages translating text only. Now you might also need a full cast of voice actors for each language + writers and directors for each language, over a wider number of languages.
Some of that is the standard for bugs has changed. Games do still ship with bugs but back in the day the standard was just "be playable to the end and don't crash" Now there's a complex certification process to validate the game's behavior against the system's host OS, and if the game has online features you have to test against cheating and exploits. Check out some of the bugs that speedrunners exploit in older games that let them manipulate the contents of memory, that would be considered insane today. So you need a lot more QA staff than back in the day.
Compared to today's big-budget productions, I'm also impressed by this era's typical development team size. Banjo Kazooie, another iconic N64 platformer, was another 15 member dev team, the bulk being 4(!) programmers and 4 artists.
I appreciated the detail about the silent work environment, as opposed to today (in the US at least), where if you want silence to concentrate, the burden is on you to defend against noise rather than the other way around
Proponents of in-office working and open plan talk about the benefits of spontaneous conversations. For me I find I just can’t get anything done in these environments and I prefer much more deliberate communication. I wonder what the situation is like in tech companies in Japan today?
> Proponents of in-office working and open plan talk about the benefits of spontaneous conversations. For me I find I just can’t get anything done in these environments
Kind of depends on what you work on. As a programmer, getting a task of designing and implementing something, obviously needs a lot of quiet time. But for creative projects like video games where you're basically creating art together in team, it's really hard to do "deliberate communication" for longer stretches of time and not end up blocking everyone left and right, especially in non-AAA teams, where you basically have to collaborate non-stop so everything can move forward.
99% of the game is concerned with [Mario's movement]. most of Miyamoto’s time is spent on that, and the movement of the camera.
I had to put down too many early 3D action games because of clunky controls and not being able to see what was going on. Maybe horror games (like resident evil) could get away with awkward cameras in the service of jump scares, but it's frustrating when you have to make a jump and the camera, and thus the controls, don't cooperate with you.
Miyamoto's talent has always been in his relentless technical execution and polish. Particularly with the move to 3D, every modern platformer and adventure game owes its basic camera and control to Mario 64. Every modern action game owes its lock-on system (the ability to target individual enemies and move/strafe in relation to the target) to the Z-targeting system from Zelda: OoT.
Late Mark Haigh-Hutchinson wrote a great book about real time game cameras "Real Time Cameras: A Guide for Game Designers and Developers". Anyone interested in the topic ought to check it out.
In hindsight, the movement in the early Tomb Raider games was really awkward. It didn't feel very human... it felt like an endless loop of rotating a circular tray then putting your foot on the gas.
The level design helped a lot with the camera. Subsequent games (doing 3d) tried to make more realistically sized spaces where there wasn’t a 6ft area clear behind the character at all times and tied themselves in knots trying to make it work (rather than re-designing levels).
One thing he doesn't mention explicitly is that someone working on Mario 64 invented modern third-person controls for games with free camera. Games which started development before Mario 64 came out, had "tank controls" where the movement was relative to the direction the player character was facing.
In Super Mario 64 this was different: pressing "up" on the controller didn't let Mario walk forward from his own perspective; rather, it made him walk in the direction the camera was currently facing. Basically every third-person game today now uses the Mario 64 control scheme.
It is interesting that another game which had a similarly huge influence on character controls was also a Mario game: Super Mario Bros for the NES. It introduced character acceleration, dynamic jump length based on character speed, dynamic jump-height based on how long the jump button is held, and character steering in the air. Basically every 2D platformer uses this control scheme to this day. Games before that had fixed jump arcs and fixed running speed.
Super Mario Bros did not "introduce" those features. Major Havoc (from 1983) had all of those features 2 years earlier. And various games throughout the early 80s had various aspects of all of them. SMB certainly popularized and universalized them though.
The same could be said for SM64, albeit less so as SM64 definitely revolutionized the third-person control scheme to a greater degree.
Interesting. The English Wikipedia page of Major Havoc says
> Although Major Havoc was not a major commercial success in the West, it had a significant impact on the development of the Japanese computer game industry.
The Japanese Wikipedia page mentions four games which are influenced by Major Havoc, though they don't say anything about Super Mario Bros. The earliest listed game is Theseus (1984) for the MSX, which basically copied the Major Havoc platforming physics. It's also possible that this one influenced Super Mario Bros (1985) rather than Major Havoc directly.
Though it is worth mentioning that these games apparently had unlimited upward acceleration from holding the jump button (kind of like a jet pack) and they had a head bumping mechanic which would let the player drop down stunned. SMB didn't have that.
At the time, I owned and ran a video game store, and Super Mario 64 was a real watershed moment. Seeing Mario's face deform in real time made a lot of jaws drop.
N64 and the Wii follow ups actually are one of the few consoles linage, that after the move to C/C++ SDKs, that actually has a quite visible OpenGL influence, including the shaders.
I’m not quite sure what your point is here? N64 (and wii) was fixed function, no shaders at all … unless you count rsp programming for vertex ‘shaders’ but that was relatively uncommon and certainly wasn’t done in earlier n64 titles.
The api borrowed a lot from opengl and the opengl red book was required reading! I dont understand your C++ comment; only directX is C++. Vulkan and the playstation sdks are all C, and the programming language used to call into the graphics api has nothing to do with the look of a game.
"N64 and the Wii follow ups" => GX 2 on the Wii U has shader support based on GLSL.
C and C++ SDK relates to what languages are used to write the games, and what compilers are available on the devkit, as console game development started to move away from Assembly, not graphics APIs.
The 5th generation consoles was the last one where C++ compilers were still to be made part of the SDK, or available via third parties like CodePlay, all 6th generation consoles introduced C++ compilers in their devkits, including Nintendo.
I have not a made a single remark on how that influences the look of the game.
It’s even crazier we got masterpieces like Mario 64 so early into the first 3D console generation.