It’s even crazier we got masterpieces like Mario 64 so early into the first 3D console generation.

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.

Those 48 hours were likely the peak of video gaming. Certainly they have yet to be equaled.

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.

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.

[1]: https://marathon.bungie.org/spoiler/m2/14.shtml

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".

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.

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 was wondering how he has adapted to using LLMs. If they might have significantly advanced his work.

It can be an acceleration when wielded by someone who can keep the model focused.

> 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.

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.

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.

>[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.

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.

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.

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.