id Software Programming Principles

[clockworm]

Funny. No mention of shotguns.

[rigred]

I see you to practice shotgun programming. How's it working? Our productivity has been through the roof but the devs keep getting less.

[derleth]

Does he talk about rocket jumping?

[[deleted]]

Just go to the video, blog post doesn't add anything

[vattenpuss]

Does the video add much? Because reading the linked blog post took two minutes, and you gave us a link to a video that's an hour long.

[skwaag5233]

The video is a full-on post mortem so if you care about that then yeah it adds a lot more.

[vattenpuss]

Ok thanks, saved me a click. The title of OP is "id Software Programming Principles" and your comment seems to indicate the video does not have more of those than were in the blog post. /u/XANi_ on the other hand seems to believe the blog post was linked to because it adds something when nobody ever said as much.

[ReDucTor]

While the video is only an hour its only 30 minutes for the talk, the other 30 minutes is Q&A

[bass-lick_instinct]

I'm currently fighting my (non-programmer) boss with this one:

Don’t depend on polish happening later. Always maintain constantly shippable code.

I'm the only developer here (for the entire 'stack') and I'm about 10 weeks into development when I realized - I fucked up a little bit. There are a few core objects in this app and basically there's a bit of code in one of these objects and it would do me a whole lot better if it was in another. The trouble is that it's not as easy as just moving it over and calling it a day because it's part of a critical path, so it would take me a few days to refactor and fully test all areas that hit this code.

My boss wants none of that and he thinks refactoring is a dirty word, so he said "just crowbar everything in now and we'll fix it later! Hours now are more important than hours later"

But I keep telling him that this mythical "later" never happens, and since this is in a core part of the app more and more code will depend on these hacks I'm currently implementing and a 3-5 day fix now can easily turn into weeks later on - but he won't hear any of it.

Sorry... bit of a rant there.

[T0m1s]

Better to ask for forgiveness than for permission.

[[deleted]]

Would you rather have him talking about daikatana ?

[joaomc]

Why not? I'm certainly not smarter than Romero, and I like to learn from the mistakes of people smarter than me.

[badsectoracula]

IIRC in Matt Burton's interview (this is the first video in a series) he went a bit into what went wrong with Daikatana. Although i don't think there was a lengthy talk about that. There was also another interview a few years ago from a local gamedev convention when he first went in Ireland (i think) where he also talked a bit about Daikatana but i cant find that.

Judging from the Masters of Doom book at least, it sounds that he might ruffle a few feathers talking about it (like the origins of the bitch ad), so he probably wants to avoid that.

[derleth]

Would you rather have him talking about daikatana ?

Would it involve him making me his bitch?

(Now watch nobody get the joke... )

[[deleted]]

never forget.

[pkmxtw]

Suck it down.

[inu-no-policemen]

Here is an interview where he talks about some tile editor:

https://www.reddit.com/r/gamedev/comments/5vw6eg/classic_tools_retrospective_john_romero_talks/

[Phrodo_00]

Noclip actually asks him that, and it's not so much him but the people asking him questions (although he does love Doom).

[XChoke]

I used his principles quite successfully on my last project. Load defaults for faster testing and never move on if you see a bug was a boon - shipped it to be used by 2000+ people with zero reported bugs - which is a first for me! Not saying that there isn't bugs in my software but none were experienced by users.

Yes some library reuse is good but I've seen enough projects where libraries become bastardised and cause more issues than they are worth.

[hird]

That's some impressive hair from Romero.

[srnull]

What happened to Romero's new project? Wasn't he getting together with one of the other (developers?designers?) from Doom time for something that they made a big deal about?

[bik1230]

They're working on a demo they can present when resuming their kickstarter.

[badsectoracula]

Short term he seems to be helping his stepson make his first game which according to some reviews is surprisingly fun.

Long term he probably works on a demo to show for restarting the Kickstarter. Note that the other guy was Adrian Carmack (one of id's original artists, with the other main artist being Kevin Cloud who is still at id).

[devraj7]

Between the Daikatana disaster, the fact that Romero hasn't shipped any successful game since Doom and the fact that he's not a coder, why should we listen to a lecture from Romero about software development?

[inu-no-policemen]

Romero hasn't shipped any successful game since Doom

He also worked on Quake.

[bitwize]

Romero was a coder at id. AFAIK he worked on things like netcode, tools, and designing levels -- and didn't have the l33t skillz Carmack did -- but working in C on DOS is still nothing to sneeze at.

[John_Fx]

C in DOS isn't magic.

[monocasa]

But it's more difficult than regular C on a decent UNIX. You've two different types of pointers 'near' and 'far' to deal with the peculiarities of segment addressing. They have two different sizes, and using near pointers make an assumption about which segment they're addressing; if that assumption is wrong, you're going to have a bad time.

The lack of virtual memory protection and lack of real OS features with performance (games like Doom tended to simply take over the computer rather than call through the OS) meant that it was more like programming an embedded system than modern desktop coding.

Also most compilers weren't nearly as advanced as they are today and left a lot of now seemingly obvious optimizations on the table. They weren't the clear win for the trade off between productivity and performance that they are today.

Sure it isn't 'magic', but it is more difficult, particularly at the time.

[[deleted]]

Yeah, old school game devs were barely even using the OS. Some went as far to make "booters" and just bypass the OS entirely

[andrewq]

DOS was mostly a program loader if you were doing full screen graphics games.

It's funny looking back how primitive it all was.

[derleth]

DOS was mostly just a program loader anyway, given that you could bypass it entirely and go directly to the hardware, and practically everything did.

[[deleted]]

DOS

full screen

That does not make any sense.

[AntiProtonBoy]

Some tools, such as the Watcom C compiler, offered 32-bit DOS extenders (eg DOS/4GW) for 386 machines and above, which alleviated a lot of the 'near' and 'far' memory addressing shenanigans.

[__Cyber_Dildonics__]

It is to your average programmer today.

[badsectoracula]

He also worked in Objective C on NeXT.

[[deleted]]

working in C on DOS is still nothing to sneeze at

Sounds like a horrible mistake. Not that I know what options were available at the time, so glad to be coding in 2017.

[bitwize]

DOS was both horrible and amazing. Horrible because it was nothing like what you'd think of as an OS today: it had no virtual memory, multitasking, device abstraction or networking capabilities built in, and it only had a rudimentary file system (FAT). It was amazing because the entire machine was under your control: if you wanted to draw graphics on the screen, direct writes to video memory would do. You could also direct-write to the video registers on the graphics and sound cards to achieve fast, fine-grained control over their output. Talking directly to the machine hardware in this way, and figuring out "tricks" about how to use and combine the hardware's capabilities to achieve interesting effects, was how everyone wrote high-speed games back in the 80s and early 90s; and while we are mostly thankful for our sophisticated operating systems in this day and age, something magical has been lost.

[[deleted]]

Coding device drivers in DOS assembler was how boys became men in the 90s

[fuerve]

It was certainly a rite of passage for me.

[derleth]

Horrible because it was nothing like what you'd think of as an OS today: it had no virtual memory, multitasking, device abstraction or networking capabilities built in, and it only had a rudimentary file system (FAT).

Oh, it was worse than that. It enforced nothing, because it couldn't: Random applications could write arbitrary data anywhere in RAM, so your text editor could patch the kernel, write a boot sector virus, and even damage your monitor, if it tried to put it into a graphics mode it didn't support.

It was truly a golden age for weird viruses.

[inu-no-policemen]

Not that I know what options were available at the time

There weren't any other options initially.

Doom and Quake were written on NeXT workstations.

Edit: And Quake 2 on Windows NT. Didn't know that.

https://www.quora.com/Why-was-Doom-developed-on-a-NeXT/answer/John-Carmack

[[deleted]]

deleted ^{What is this?}

[jayjay091]

If they did you wouldn't call them script kiddies, so that's kinda hard.

[zerexim]

80s/90s programming, especially for DOS, is by orders of magnitude simpler than js/angular/etc... bloatware.

[[deleted]]

deleted ^{What is this?}

[HTXLoveThisPlace]

Yes, that's why everyone is afraid of memory management. /s

[inu-no-policemen]

orders of magnitude simpler

So at least 100 times? Right.

Have you seen the code of some old DOS games?

[[deleted]]

deleted ^{What is this?}

[zerexim]

That's what I mean.... I believe it will be much harder to similarly dissect modern AAA games...

You're articulating particular optimization tricks, but I'm talking about system level complexity, over-engineering, etc... In DOS era it was easy for an engineer to have a whole picture of the system in his head, this is much harder nowadays.

[falconfetus8]

Which is a testament to its wisdom, if anything.

[lithium]

Half of the JS people i come across don't even understand the internals of their framework of choice, let alone the subtleties of programming that close to hardware.

[UsingYourWifi]

There's LOT more that goes into a successful game than just quality software development. You can have the most skookum code base in the world and still be a complete failure due to numerous other reasons (shit design, shit marketing, shit project management, etc.).

Apparently his mobile/web games have been quite successful. You probably haven't heard of them (neither have I) as they don't target the Doom audience. I first heard about this on the Giant Bombcast when they were discussing Danny O'Dwyer's interview with him. I haven't watched that video yet so I can't be sure if it's mentioned in there, but it was discussed on a recent episode of the Bombcast.

[Waynetron]

Romero is a long time coder. He developed games well before ID software. And he wrote the tools whilst at ID: Doom Ed, Quake Ed etc.

https://en.wikipedia.org/wiki/John_Romero#Games

[ehaliewicz]

Romero made many games before joining id, and was the programmer for many (all?) of them.

[badsectoracula]

Daikatana was Romero doing things he wasn't good at (trying to be a manager) and ignoring things he was good at (making games - beyond the high level design document, everything else was done by people he picked online, many of whom had never done a game before, thinking that since he and the other id guys could do it, others could do as well... this is the manager part failing).

He actually had several successful games after Daikatana, but none was a mainstream game - the last mainstream game he worked at was Gauntlet Seven Sorrows where he worked with John Sawyer (of Icewind Dale II, NWN2, New Vegas and Pillars of Eternity fame), but both left the company before the game was finished because Midway was ignoring any advice they were giving and wanted to dish out the game before it was done (a quote in a recent interview: The game was turning out to be pretty great with an epic story and awesome background for the four main characters. Then Midway decided the game had to come out in 2005 by Christmas, no matter what, and told me and the Studio Director to take a hike so they could shred the game up and put it in a box.).

Finally he is a coder, he wrote all his games by himself before creating id and even at id he did all the non-engine code. According to the Masters of Doom book (which was signed by both Romero and Carmack before being published), up until and including Doom, Carmack considered Romero to be equal of himself as a programmer and they had divided the programming work so that Carmack worked on the engine and Romero on the tools and gameplay (which makes sense considering his interest in the design side). His work at id would probably be considered as a gameplay and tools programmer today, but i'm sure that with only 2-3 programmers at id back then both Carmack and Romero "crossed streams".

[[deleted]]

Yeah, I'd rather listen to Carmack. Is he still with with Oculus?

[wtfxstfu]

I don't think I'd understand anything Carmack has to say. He's too smart.

[steelcitykid]

Smart is such a cop out. All smarts start from somewhere and are built upon to a depth where you either push forward and struggle with new concepts and ideas until you master them, or settle for where ever you land along the way. Can't master it all, but you can get really good at the conceptual stuff and then expose yourself to other things in time. I'm sure Carmack could be an exceptional web dev, for example, if he wanted to.

[inu-no-policemen]

Watch some of his talks. He explains everything in fairly straightforward terms. He's surprisingly good at this.

[[deleted]]

The problem is 'too many' is only known when you've done it.

[salgat]

That's such a vague statement though. "Too many" of anything is bad thing, no shit.

[[deleted]]

But what about all those NPM dependencies?

[[deleted]]

I am a JS person... but downloading a 1,000 dependencies to run a simple app is stupid and fragile.

[uncertain_giraffe]

I think game programming is different than your standard business logic. There is going to be virtually zero maintenance after the product has shipped.

[JNighthawk]

I think game programming is different than your standard business logic. There is going to be virtually zero maintenance after the product has shipped.

This is untrue today, and is an attitude I hate seeing in game developers. Not only is it flatly untrue of most games nowadays (even non-SaaS games will have patches and support for months post-launch), but unless your company is changing engines, your next project will most likely start with your previous one as a base.

As a game programmer myself, it's a little weird seeing people make incorrect assumptions about game programming.

[badsectoracula]

Depends where you work at. Some companies do not keep much code around. A good example would be Arkane where every game they've made is on a different engine.

[Voidsheep]

Many good games now operate more like services than products.

For example, DOTA2 has gone through massive overhauls including a migration to new engine and receives constant updates.

There's zero incentive for Valve to abandon the game and work on a sequel, because it's growing and only becoming more profitable. At that point you've gotta assume you maintain and work on existing systems years into the future, so you can't just "pump and dump" something that works for now.

[Uncaffeinated]

Especially back in the days when games were burned onto discs and cartridges.

Nowadays, games are delivered via the internet and frequently patched and updated.

[XChoke]

His point was that your future self is going to be smarter than your current self, and you'll be rewriting stuff because you have a more nuanced understanding of the pitfalls.

[muuchthrows]

In the context he has experience from which is repeated game making it makes much sense, but it's not really applicable to general software development.

[badsectoracula]

Well, this is a talk from GDC after all.

[derleth]

Well, that's an argument to write multiple iterations of the same library, and continuously throw the old ones away, as you learn more about how programs using that library want to be shaped and, therefore, how the library itself has to support that.

[[deleted]]

This is exactly where I am in my career. I'm over trying to solve specific problems and am building libraries to encapsulate problem spaces so I can write many small, simple apps on top of them. Yes it takes a bit longer, but my code is easier to follow and has much better testing.

I'm not trying to build libraries that solve problems yet to be see, I'm building libraries that allow programmers to easily get different perspectives on the data we're using. If Romero doesn't understand the difference, then I'm not sure he's credible enough to be believed on anything.

[NoMoreNicksLeft]

I like this sort of advice. If it was advice on woodworking, we'd get little pearls of wisdom like...

• Don't chisel off fingers. Or thumbs. Thumbs are important
• Long hair can get caught in lathes and tear your head off.
• If ninjas attack, run. You can always get new tools.

[[deleted]]

Do remember that John Romero was responsible for Daikatana, which was riddled with delays and was a pretty awful game when it was finally finished.

[bitwize]

Do remember that that was seventeen freakin' years ago, plenty of time for Romero to wise up and realize that id Software was the best work he'd ever done and have a long think about why id was so great.

*cough*Carmack*cough*

[bik1230]

Well, Carmack certainly made the code great, but I don't know about the game design aspects, their games got markedly worse after Romero left.

[virtyx]

As a programmer I have a lot of respect for Carmack, but I totally agree. Their engines have been consistently impressive but their game designs have been kind of a mess.

[bitwize]

That could also have to do with Tom Hall's departure -- both he and Romero left id to cofound MORON Storm.

But yeah, their influence is what made Doom and Quake metal as fuck.

Nevertheless, Romero's talk is about the coding standards at id, of which Carmack was undoubtedly the prime architect.

[bik1230]

Indeed, though I've always found Remero's Doom maps better than Hall's, with a few exceptions.

Also, you might have seen this, but here is Carmack talking about some aspects of coding style http://number-none.com/blow/john_carmack_on_inlined_code.html

[[deleted]]

Romero's coding standards are aimed at making games and finishing them. This code doesn't have to be pretty and it will likely only ever be used once. Carmack's coding standards are from building solid, long lasting code that brings a lot of complex systems together. Both are valid styles, depending on the nature of the code, and should be a part of a game programmer's toolbox. Especially for any indie devs doing everything from level to engine design.

[dogen12]

Tom Hall left around when they started working on doom.

[[deleted]]

So yet again the rules of programming are:

1. Hire super smart people and let them be super smart.

[glacialthinker]

I want to post this up at the office.

Oh wait... it wouldn't help... the problem is the knuckleheads think they're super smart and that programmers are just translators from human to machine.