"In the last six months of 1991, we started and shipped five games,"
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!
First all developers are extremely talent and some bagged years of production experience under belt before they formed ID.
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.
> 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.
Agreed, although I'd say it's a different type of ownership they had, a better type. Not only did they own the company legally, they also got to make the games they dreamed for. Today, one might be able to lure some technical person with stocks and options, but he or she wouldn't be that devote if he or she does not love the products (that much)
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.
Yes and no.. assets were simpler, games were simpler.
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.
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.
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.
Perhaps that is another differentiator contributing to the ID team moving as quickly as they did. SGI NUMA systems were not cheap! How many teams had that kind of best in class hardware in house?
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.
To add on to the other comments of games being more simple back then, most of the games released in 1991 by them were sequels and/or shared codebases and tooling with other games.
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.
If anything else this makes the achievement that much more impressive. They built tools instead of just hammering out assembly. The five games in six months was just collecting on that previous effort. But knowing what tools to build and how is the real achievement.
It's not just about knowing what tools to build ahead of time. That might well be impossible.
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.
Right. That's what's impressive. They built the right tools, presumably during previous projects. The tools they built were useful enough to enable future work.
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.
While you are technically correct and I agree completely, I think your emphasis on abstraction might lead to higher (or at least more variable) cycle times rather than lower.
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.
It should not be understated though how good the toolset was for the time. The original idea for Keen came after they (Carmack and Tom Hall) recreated the first level of Super Mario Bro's 3 in one night. They had to break from Softdisk under Romero's suggestion, because Softdisk would claim proprietorship over the engine. They actually "borrowed" their work computers from Softdisk over a weekend to work on Keen and created the first level in 72 hours. After the success of the first Keen it was a no-brainer to keep making more and milking it for all they could.
Have you ever been bit by the bug of absolutely needing to get something done and finished just so you can keep riding the high of finishing something? You chase that feeling into the next thing, and the next thing, and so on.
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.
One thing i've found as an avid gamer is the lack of "humanity" in modern games. Modern high budget games are streamlined, risk averse, and predictable.
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.
Maybe in aggregate modern gaming exhibits less humanity, but the best games today are on an entirely different level of story telling and emotional investment than 1991.
You could still produce a AAA title with a small team (e.g 10) in the early to mid-90s. By 2000 an average team was about 100 people. There are exceptions to this in both directions but that was the overall trend.
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.
id Software went independent after working for a company named Softdisk making a monthly floppy disk called "Gamer's Edge":
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.
Having a monthly deadline making MS-DOS games on floppy is why they were so prolific at that point. None of the Cmdr Keen games are much different from each other, and there were 6 of them.
The original 'trilogy' is a bit more distinct from the rest IMO; Yes the basic platforming concepts are the same, but I'd say Keen 3 and Keen 4 is a pretty substantial jump in style/features like swimming. (Also setting aside the odd duck of Keen Dreams).
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..
I've listened to a bunch of John Romero's apple time warp podcasts about apple2 development. It was very small companies (sometimes single developers). This was in the 80s... A little bit before.
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.
You can do that today, you could ship five Chess or Candy Crush games in six months if you wanted to. It's just a matter of where you set the bar for complexity and effort.
Assets were much simpler. The screen was ~320x240 pixel so your 2D images were a handful of pixels from a couple hundred limited colors. An artist could bang out tons of images and sprites in the amount of time it takes someone to meticulously craft, model, paint, animate, etc. a full 3D monster today. Same thing for sound and music--it was much simpler and more manageable by one or small number of people.
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.
On the other hand, 2d animation requires A LOT of these hand-drawn sprites, to the point where I suspect the cost benefits of 2D become questionable. For example, Heroes of Might & Magic 3 moved to their sprites being pre-rendered 3d models (possibly also painted over in every frame), which look worse that the pixel-art sprites in 2D. I suspect they did it because it was just less work to do it in 3D.
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 ;)
Games had to be smaller projects. The console and home computer hardware at that time put a tight limit on how much code and data you could ship. Filling that up wasn't hard. It was mostly a matter using these resources well.
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.
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!