The Making Of Super Mario 64 – full Giles Goddard interview (2001)
pixelatron.com
pixelatron.com
It’s even crazier we got masterpieces like Mario 64 so early into the first 3D console generation.
It was a fun era to live through as the progress was so quick.
I still have yet to finish Duke 3D. Next time I'm in between jobs I'll hit it up.
"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.
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.
IMO It depends on how you view it. You can render the game stereoscopically and see a different view in each eye... then I would call that "real 3d".
That’s exactly what the Virtual Boy does.
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.
Those 48 hours were likely the peak of video gaming. Certainly they have yet to be equaled.
More Money == Better Than https://www.youtube.com/watch?v=gbU4VRs2rro
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.
I think PoP: Sands of Time has that kind of camera control, and apparently that was 2003.
I always assumed it was even older than that. If it wasn’t GTA or PoP, who did pioneer that camera control style?
I’d say it’s just about the only (arguable) flaw in the Mario 64 controls, everything else is absolutely spot on.
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.
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.
Please dont redefine what 3D means to a forum of smart developers
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.
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.
We're living again in this period of time were it must have been crazy to be a developer ;)
https://youtube.com/channel/UCuvSqzfO_LV_QzHdmEj84SQ
From Wikipedia:
> 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.
> 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.
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.
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.
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.
In video work and VFX you sometimes hear people say "The real plugin is effort".
>[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]
0 - https://en.wikipedia.org/wiki/Giles_Goddard_(video_game_prog...
1 - https://web.archive.org/web/20080613053018/http://blametheco...
https://gamehistory.org/eclipse-the-demo-that-sold-3d-to-nin...
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!
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.
> 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!!
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 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.
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.
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.
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.
Mario64’s camera was a wonderful piece of design.
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.
The same could be said for SM64, albeit less so as SM64 definitely revolutionized the third-person control scheme to a greater degree.
> 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.
Due to its SGI influence.
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.
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.
I'm tempted to create a website curating video game stories like this one.