What was so different about development back then that they were able to do that? That's unheard of today despite better hardware and a lot more tools. And they didn't have stackoverflow.com!
Second as other mentioned these are relatively simply games, not the ones like Ultima and Golden box that usually takes years to develop.
Third I think there is a unique culture in teams such as early ID: No bullshit, devs willing to devote 80, 100 hours per week, no management overhead as they KNOW what they are going to do.
Yes, I think nowadays there is rightly a reluctance to do this sort of thing without either an ownership stake or very high compensation - neither of which are common in the gaming industry.
If we're talking about the Gold Box series; were those long development times?
7-ish games in 4ish years doesn't seem too bad, and the the engine evolved with each game.
Like, Commander Keen and the other of those games are the same amount of effort that might go in to a particularly well staffed month-long game jam today, just in terms of assets and total needed code. CV-11s video on Quake has a section covering that transition from mostly 2D to mostly 3D. It caught a lot folks off guard.
But they had to write a lot their tools to create the assets. They had no middleware, no engine to license. They had to write stuff in assembly. The computers they used were super slow and you could crash them so easily. At some points in iD's early history they were smuggling computers from Softdisk out of their offices and working over the weekend and then taking the computers back Monday morning. The tools were terrible. Documentation was a lot harder to come by. A lot of the people in iD at the beginning were also juggling a day job, they were moonlighting making those earliest games. IIRC Wolfenstein was the first one they worked full time on.
Neither the tooling were terrible, in fact, arguably the opposite. Some of the best dev tools ever made come from that era (Borland stuff)
People still write a lot of asset creation tools today. That's standard in games industry.
Doom was developed on NeXT workstations, under the NeXTSTEP operating system. The final game engine was programmed in C, and the editing tools were written in Objective-C. The engine was first compiled with Intel's C compiler for DOS, but later Watcom's compiler was used.
https://www.quora.com/Why-was-Doom-developed-on-a-NeXT/answe... adds:
Over the entire course of Doom and Quake 1’s development we probably spent $100,000 on NeXT computers, which isn’t much at all in the larger scheme of development. We later spent more than that on Unix SMP server systems (first a quad Alpha, then an eventually 16-way SGI system) to run the time consuming lighting and visibility calculations for the Quake series. I remember one year looking at the Top 500 supercomputer list and thinking that if we had expanded our SGI to 32 processors, we would have just snuck in at the bottom.
https://www.youtube.com/watch?v=RDAzJLBB6pE is a visit to id Software in November 1993
16 MIPS CPU processors housed in metal heat sinks that can look and feel like small bricks! Real steel amd aluminum all over the place!
IRIX delivered NUMA style multiprocessing running on a single OS image they scaled up to 2K CPUs! I believe NASA had a 2K CPU system for quite a while.
Running one of those beasties was an excellent overall computing experience. At that time, perhaps unexpectedly, one of the most impressive features was the documentation. The early version of that system was called, "Online Books" in the software manager, which itself was what we know as a package manager today, and featured a Windows Help type application designed to render the docs and many high quality illustrations in a compact and searchable, selectable form. Selecting text meant being able to work through advanced system examples copy paste into terminal style, among other things.
For people who enjoy command line, in the terminal style coding, the SGI terminal font and white on blue was, and in my view remains, one of the top easy on the eyes, fast and low fatigue text interfaces ever done.
I will often grab one of the modern, similar to the fast bitmap fonts SGI used, and use white on blue today. My first home computer was an 8 bit Atari, also setup to display white on blue, similar to the C64, which can be set that way quick and easy.
Anyhoo, I was using and setting up those systems for a time,from workstation up through 8 CPU Origin and Onyx class NUMA hardware, and absolutely loved it. Exemplary computing experiences.
A comment can be found in the SGI freeware Doom package, "SGI graphics run Doom real sweet." (Or something to that effect.)
Newbies would be surprised to find even their "slow" SGI Indy could run multiple copies of Doom at the same time, rendering into a window with full sound effects and no dropped frames. I would play one while a few others were running in attract, or "demo" mode, all smooth, display frame locked looking crisp and responsive.
https://www.reddit.com/r/itrunsdoom/comments/j5943h/im_over_...
One day, I would live to take the time to explore that computing experience. Like SGI, everything about those machines looks super sweet!
Three of those releases were Commander Keen games; Shadow Knights and Danger Dave shared engines; as did Catacomb 3D and Hovertank; Rescue Rover I/II were simple puzzle games built on an old demo code base. I'm not trying to take away from their accomplishments, merely pointing out that they didn't start from scratch every time.
I think id was trying to get out of come contractual obligations from Softdisk.
It's about finding the intersection in the design space between "the game I want to make" and "the capabilities of the tools I have" that allow you to adapt your tools to make something 90 % of the way there with 10 % of the effort.
This goes for any fast product development! Lockheeds' Skunk Works were amazing at repurposing tools and parts to invent completely new planes with few components that were actually new.
You may not know what tools you will need in the future but when you need a new tool you can build it in a way that it is reusable.
In other words a good tool solves an abstract problem. I don't need an Ikea-Bergmund-chair-leg-attacher. I need a screwdriver.
Once you have a toolbox full of these basic tools you are better prepared to tackle those future projects.
It sounds like you're suggesting that one spends, say, 80 % of one's creativity coming up with general, abstract problems to tool for, and then 20 % of the creativity on finding ways to apply general tools. That absolutely works, I think, if you're fine with high variability in the time you spend between each release.
What I tried to suggest is that instead you spend 40 % of your creativity on finding abstract problems to tool for, and the other 60 % of your creativity in finding ways to apply your distinctly less general tools to new situations, despite their lack of generality.
What concerns me about the high-abstraction route is that people, in my experience, have a tendency to over-abstract. To try to predict every future use case ahead of time, instead of accepting their ignorance and building for ease of change.
That is why I want to emphasise modding non-general tools rather than future-proofing tools at the design stage. Because you can't know at the design stage in which direction future innovation will go.
They were doing that. Finishing and shipping anything feels really really good. If you're a small team and you feel a deep personal investment in the product then shipping becomes addictive.
Brandon Sanderson and writing is a similar example. Is the quality always there? No. But, the guy is very very good at finishing and clearly rides to wherever his passion takes him. His output is, in comparison to other authors writing in similar genres, incredible.
Also, games were much simpler and players had much simpler expectations.
If you look at older games you'll often find the creator's / developer's quirks and mannerisms have seeped through showing mild biases, prejudice, stereotypes, etc (humanity). The freedom to express yourself in your work, resulted in people becoming emotionally invested in the product. This investment likely meant they spend many additional hours if not directly working on the product, than thinking about it resulting in a faster shipping date or a higher quality product in the same timespan.
In that period, you moved from mostly 2D to mostly 3D games so more complex code generally, plus the need for artists to do 3D modelling, texturing, rendering, optimisation, etc etc. Sound designers, composers, etc etc. AAA Games just got bigger, plus multiplayer. Hardware got more powerful (sound and graphics cards) so there was a desire/demand to make more use of that hardware. Generally, it all became a lot more "Hollywood".
There are still great games made by small teams of people in a short period of time. But to hit the AAA mark you need to be with a big studio and have the marketing budget behind you. Again, Hollywood.
Softdisk is most famous for being the former workplace of several of the founders of id Software, who worked on a short-lived game subscription product, Gamer's Edge. Gamer's Edge was a monthly[3] PC game disk started in 1990 by John Romero.
Did anyone ever actually successfully buy just one episode? I mean, 10 year old me did from a different publisher (Epic Megagames), but they just sent the whole trilogy anyway.
But overall yes, a lot of those folks got good at churning out games, and part of that was understanding the value of good tooling.
The level editor used for Keen, called TEd (Tile Editor) was actually used for something like 30 different titles, both 2d and 2.5D, prettymuch up to the original Rise of the Triad..
They're kind of fun when they get into old stories about long gone companies. They don't come out very often however: They're 10% annoying and 90% really fun.
Look at game jams today, like the 48 hour game creation contests. A lot of stuff that comes out of those are little 2D things reminiscent of games of that early 90s era. It's because it's still pretty fast and easy to make assets for that style of game.
I think it's possible to have that same output in mid age. The difference is enthusiasm. It's still novel.
Further one of the games in the Spring Future Games show mentioned they were developed by a small team, using UE5 and AWS Gamelift, in about 9-12 mo.
I think a game in six months is doable with the proper talent. It's not gonna be Elden Ring in scope. But NES Legend of Zelda in 180 days seems possible now.
Tools like Github Copilot & NVidia GauGAN can also assist. But may be a steep research curve before resulting in actual workflow compression ;)
This changed a few years later when CDs came along. Many game devs originally didn't quite know what to do with so much storage space. Then processors also got much faster still and 3D acceleration became a thing. Game dev project scopes exploded accordingly to give you the game industry we have today.
1. Less distractions (no Youtube, social media, etc..)
2. Games were simpler
3. The games produced probably weren't that good
They were gamers, they could've been playing games instead of working their asses off internet and social media here are not to blame.
They were _really_ driven and passionate