Yes, but then again you had to create the whole thing from scratch. Nowadays there are libraries that will do basically anything you can dream of. There's middleware. Whole game engines.
That era? Want to blit on the screen? Do it yourself. Want to load an asset? Not many pixmap formats to choose from. You may have to write the code to load it yourself. Want to play some beeps? Better control the PC speaker frequencies by turning it on and off (without spending too many cycles on it). Sound cards didn't make the problem any simpler.
You can't even code on one window and watch the results on another window. Unless you had loads of cash like Carmack at some point and could buy a NeXT. It's code, run the compiler, run the game. If it crashes it might take the entire machine with it. Reboot and try to figure out what went wrong. You _might_ be able to get a debugger but they were extremely primitive - and no memory protection so the debugger (which would likely modify the code and add side effects) could crash too.
Yeah, simpler games. But glacially slow to code anything. And very little publicly available information.
You try figuring out a highly performant ray casting engine without the internet. Or implement smooth scrolling after entire companies had tried and failed.
> You try figuring out a highly performant ray casting engine without the internet.
Not that it detracts from what he accomplished in any way, Carmack's alternative to the internet seems to have been books and research papers.
From GEBB DOOM:
"John started searching around for 3D research papers. He had several
VHS tapes of math conferences, and compendiums of graphics papers from
conferences because game books were a rare thing back then, and there was
nothing printed that could help us create the engine we were building – he had
to figure out where to get information that was not directly applicable to games
and figure out how to adapt it to his problem.
Bruce Naylor’s May 1993 AT&T Bell Labs paper was titled "Constructing Good
Partitioning Trees" and was published in the proceedings of Graphics Interface
’93. John had this book in his collection. Bruce’s explanation of BSPs was
mostly to cull backfaces from 3D models, but the algorithm seemed like the
right direction, so John adapted it for Wolfenstein 3D.
— John Romero"
This is still the way things work now. A lot of techniques new to games come from earlier academic research there’s even cross-pollination back from industry as well.
DooM uses BSP trees for the levels and Quake uses them as well but in 3D. The main difference was that DooM could make the BSPs on the fly (2D) while Quake needed the BSPs to be compiled ahead of time. The executable had to be run, along with a visualization optimizer and a lighting program, in order to get the compiled map file for Quake.
Smooth scrolling on the PC was a particularly difficult problem because of design decisions made when creating PC expansion card type video systems.
Smooth scrolling, in general, was known on other hardware. That was either having enough CPU throughput and a display resolution combination that would allow the CPU to drive the display fast enough to make it happen, and or with the assistance of video display chips forming video subsystems capable of smooth scrolling by offering the kind of control needed for success, all while also leaving enough of the system resources available for a game to be made featuring the effect.
I’ve been making games since I was a kid in the 80s and whilst what you say is kind of true hardware and interfaces to it were spectacularly more simple as well. There was also more public info than you might suspect as making games was a popular thing to do then as well.
> You can't even code on one window and watch the results on another window. Unless you had loads of cash like Carmack at some point and could buy a NeXT.
Yes, you could. PCs from the beginning could support dual monitor setups with MDA plus any of the graphics cards, and this wasn't an uncommon setup for a long time because MDA had sharper text than any of the IBM color graphics standards until VGA, which had a text mode with slightly better resolution.
> And very little publicly available information.
There was lots of publicly available information. Less of it was free, but it was in books; for the less esoteric stuff they were in decently sized sections of computer books in general bookstores and computer hardware/software stores, magazines you would subscribe to, and for the more esoteric stuff there was stuff that was hard to find outside of (especially university) libraries. It was more work to find some information, but the signal to noise ratio was better.
Back in the 80s on Apple ][ (Both Johns started on Apple ][), whoever wants to develop competent games would switch to assembly ASAP. Whoever could not figure it out would drop out eventually. Eventually, whoever managed to join professional gamedev (be it Origin or Softdisk) HAS to know a lot of low-level stuffs and be fluent to assembly, Pascal and perhaps C. Example: Carmack had to code the rendering engine and network engine for DOOM, probably singlehandedly.
Today's world is a lot easier so more percentage are retained. It's a lot easier to write C#, use Unity and get out a demo in say a few days/weeks. No low level programming skills are needed, at all.
This creates a bias when we compare "classic professional programmers" versus "modern professional programmers". They simply don't need the same set of knowledge.
I find constraints are good. Limitations inspire creativity. It might be easier because the problem is obvious, difficult but obvious. Modern day programming with 1k nodejs module dependencies is a nightmare.
Yes, but then again you had to create the whole thing from scratch. Nowadays there are libraries that will do basically anything you can dream of. There's middleware. Whole game engines.
That era? Want to blit on the screen? Do it yourself. Want to load an asset? Not many pixmap formats to choose from. You may have to write the code to load it yourself. Want to play some beeps? Better control the PC speaker frequencies by turning it on and off (without spending too many cycles on it). Sound cards didn't make the problem any simpler.
You can't even code on one window and watch the results on another window. Unless you had loads of cash like Carmack at some point and could buy a NeXT. It's code, run the compiler, run the game. If it crashes it might take the entire machine with it. Reboot and try to figure out what went wrong. You _might_ be able to get a debugger but they were extremely primitive - and no memory protection so the debugger (which would likely modify the code and add side effects) could crash too.
Yeah, simpler games. But glacially slow to code anything. And very little publicly available information.
You try figuring out a highly performant ray casting engine without the internet. Or implement smooth scrolling after entire companies had tried and failed.