As far as the coding user experience that I have personally observed, game programming peaked with the team developing NBA Inside Drive 2004 for the Xbox.

Their workflow was:

1) Arrive at work. Get coffee. Fetch latest code from Visual Source Safe.

2) Turn on Xbox. Hit F5 to build, deploy and start debugging on target.

3) Edit and Continue C++ in debugger IDE all day on target without ever bothering to stop the game. (Yes, this took some coding discipline to maintain.)

4) Turn off Xbox and go home.

Between the Visual Studio debugger and the Whole Tomato coding assistance, it was easy to understand the code and the runtime behavior. For anything GPU-related, Microsoft Pix for Xbox gave you a scrubbable timeline of every action, every pixel, every register change in the GPU while drawing a frame.

The hardware capabilities, available libraries, and artist tools have increased tremendously since then. But, the coding experience has not. 20 years later, I'm outside of gaming and I find most people using re-run-and-printf debugging for professional development. Even locally. I don't know how anyone gets anything done.

The only significant improvements I've seen in 20 years (besides the occasional memory tracker or profiler tool) has been AI agents and reversible debuggers. Otherwise, it's all been downhill since 2004.

it drives me insane that good tracing profiler tools are basically confined to certain niche domains and/or are insanely expensive (or some weird cloud based shit). instrumenting programs (printf or otherwise) is dumb as hell when all desktop usermode (and even most embedded chips worth coding for) have the capability of instruction level trace. tools have sweet graphical timelines and stuff and it's killer.

basically, all programming should be writing requirements as a custom level for Shenzhen I/O

I haven’t used it personally, but I always heard that VSS was a complete train wreck.

Gamedev programming probably hit a low point for me when XBox One and WiiU came around. Those were some truly awful experiences.

> Whole Tomato coding assistance

This was far before Copilot and it was the superbest extension for VC++6 & up.

I like REPL, but you can be quite fast with a Edit-Compile-Run cycle. But that require settings a test harness and have the run phase be a test run. It's not as fast and experimental as an REPL, but can be quite nice if you know the test cases for your code.

> 3) Edit and Continue C++ in debugger IDE all day on target without ever bothering to stop the game. (Yes, this took some coding discipline to maintain.)

Similar experiences but with Java and Eclipse: editing code while it's running is amazing. And yet, far too often, since moving on from Java to Swift, even with the "proper" Instruments, the actual best I've had has been debug-by-print in much slower cycles... and sometimes not even that, when things went wrong in SwiftUI I might as well have been an ancient Roman haruspex reading entrails for all the good it did.

And at the time, everyone was complaining about Eclipse.

That was pretty much my experience developing a PS2/Dreamcast game in the 2000-2001 timeframe when working on the PC build, the _REASON_ I did so was because the PC port ran on 3dfx and that crashed the OS every 2nd-4th start so restarting was painful, being able to edit-continue was a godsend.

That said, still using debugger driven development and edit-continue to this day and marvel at the lack of experience of people touting Lisp or Erlang or whatever as the only places in the world with some kind of hot-code replacement.

Live coding is making a comeback. I predict it for 2027. LLMs can and have made hot code loaders for any existing language, and make trivial the nasty bugs that used to plague JIT developers (like broken stack frames).