Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Id Software Programming Principles

blog.felipe.rs

Post reply on HN
Print view View original

71–80 of 83 posts

Re: Id Software Programming Principles

#71

Post by alkonaut »

iabacu wrote: post #69
alkonaut wrote: post #7

Earlier quoted context omitted.

It completely removes the fun though, if you only enjoy generalizing, optimizing, refactoring, designing, and take zero pleasure in delivering an actual usable product. If the product is Doom this shouldn't be a problem - but for most of us the product is form validation or calculations involving plywood. Making frameworks and generalization is the only reason I manage to keep doing what I do. (I'm exaggerating somew…

"...only enjoy generalizing, optimizing, refactoring, designing, and take zero pleasure in delivering an actual usable product" Too many projects suffer immensely because of people who don't give a shit about delivering. In that mode, anything is an excuse: we need to reactor, we need to build a better framework, we need to revisit the requirements, etc. Then real progress gets slowed down because of some ill fitting…

Of course I take some pleasure in delivering products, and I try very hard to not over engineer or over generalize. I take pleasure in it, that doesn't (necessarily) mean I overdo it.

But if the job didn't have those elements I wouldn't be in it - and our product would be suffering from that too.

Wise devs are hard to come by.

Re: Id Software Programming Principles

#72

Post by brokenmachine »

alkonaut wrote: post #18
NumberCruncher wrote: post #17

Earlier quoted context omitted.

>> Making frameworks and generalization is the only reason I manage to keep doing what I do. This could be written on the tombstone of JS.

I hate writing boilerplate and I'd rather have pineapples shoved up my behind than write code of the kind that should be in the freaking standard library . But yeah

This is what always bugged me about java. I'm only just above a beginner, but it seems to me that in 2017 you shouldn't have to write so much crap just to read from a file.

BufferedReader, FileReader, blah blah blah

http://www.mkyong.com/java/how-to-read-file-from-java-buffer...

Maybe there's a good reason to make it this difficult, if so I'm not aware of it.

Re: Id Software Programming Principles

#73

Post by alkonaut »

brokenmachine wrote: post #72
alkonaut wrote: post #18

Earlier quoted context omitted.

I hate writing boilerplate and I'd rather have pineapples shoved up my behind than write code of the kind that should be in the freaking standard library . But yeah

This is what always bugged me about java. I'm only just above a beginner, but it seems to me that in 2017 you shouldn't have to write so much crap just to read from a file. BufferedReader, FileReader, blah blah blah http://www.mkyong.com/java/how-to-read-file-from-java-buffer... Maybe there's a good reason to make it this difficult, if so I'm not aware of it.

There is - but there is no good reason to not have good naming plus also a simple wrapper to do the most common cases. That the IO framework is very general is good, but that you need tons of boilerplate for a common scenario is bad. C#

  var txt = File.ReadAllText("file.txt");
This is exactly the abstraction you want if you want to read a (whole) text file. The point of abstractions is to pick the right one. For IO it's likely best to have many layers of abstraction so you can choose the simple top level function or use a more complex one when needed.

I'm sure there is something similar in Java these days too. Would be a huge mistake to not have simple IO helpers to the std library.

Re: Id Software Programming Principles

#74

Post by charleslmunger »

alkonaut wrote: post #73
brokenmachine wrote: post #72

Earlier quoted context omitted.

This is what always bugged me about java. I'm only just above a beginner, but it seems to me that in 2017 you shouldn't have to write so much crap just to read from a file. BufferedReader, FileReader, blah blah blah http://www.mkyong.com/java/how-to-read-file-from-java-buffer... Maybe there's a good reason to make it this difficult, if so I'm not aware of it.

There is - but there is no good reason to not have good naming plus also a simple wrapper to do the most common cases. That the IO framework is very general is good, but that you need tons of boilerplate for a common scenario is bad. C# var txt = File.ReadAllText("file.txt"); This is exactly the abstraction you want if you want to read a (whole) text file. The point of abstractions is to pick the right one. For IO it…

Like this?

https://docs.oracle.com/javase/7/docs/api/java/nio/file/File...

Re: Id Software Programming Principles

#75

Post by hermitdev »

arthurjj wrote: post #42
hermitdev wrote: post #8

Earlier quoted context omitted.

This is basically the Mythical Man Month in a few lines. You once wrote something specific, and it was great. Then you had to write a second thing, and you remember things from the first, so why not make it more general for the inevitable 3rd, 4th, 5th to come? And, then, you fail to deliver the 2nd.

I don't have my copy handy, but I believe that's actually the second system effect

You're correct, but it is also described in the book, "Mythical Man Month".

Re: Id Software Programming Principles

#76

Post by alkonaut »

charleslmunger wrote: post #74
alkonaut wrote: post #73

Earlier quoted context omitted.

There is - but there is no good reason to not have good naming plus also a simple wrapper to do the most common cases. That the IO framework is very general is good, but that you need tons of boilerplate for a common scenario is bad. C# var txt = File.ReadAllText("file.txt"); This is exactly the abstraction you want if you want to read a (whole) text file. The point of abstractions is to pick the right one. For IO it…

Like this? https://docs.oracle.com/javase/7/docs/api/java/nio/file/File...

Something like that, though the method to read a whole file into a single string seems absent for some strange reason.

Re: Id Software Programming Principles

#77

Post by dualogy »

hyperpallium wrote: post #62

This is first class post-hoc bullshit. They weren't making prototypes or reusing code, they sure as hell weren't composing high-sounding principles. They just got on with it because they were talented experienced and motivated. For that reason, the rest of the talk is very inspiring - so listen to the hour-long video (half talk, half questions), and not the article which only has the post-hoc bits. https://youtu.be/E…

> they were talented experienced and motivated

Agreed and that's the whole secret sauce right there, combined with: no distractions (social media or indeed even "coding forums" with constant flame-wars on this and that language/stack/paradigm) and crucially also no distracting "stack" or APIs to speak of (bare metal coding literally "on top of the BIOS" in these days, no OS/GUI/multithread/GPU APIs).

The initial core team spent their entire youths 24/7 getting insanely good at ASM and C and numerous gfx tricks and then "they just played the piano" to the best of their accumulated abilities. Observe how much longer the Dooms took compared to Wolfenstein and priors, and how much longer the Quakes took them compared to the Dooms.. as they were slowly entering the age of Windows native & Internet multiplayer even they too got slowed down a bit (were shocked how for Quake "just waiting for 'ze engine' took a year"!) compared to the earlier works --- of course still managed to ship high-quality products, but still

Re: Id Software Programming Principles

#78

Post by EliRivers »

a3n wrote: post #2

> Write your code for this game only - not for a future game. You’re going to be writing new code later because you’ll be smarter. This really stood out for me. I'm always tempted, while writing something specific, to generalize it. I try to resist that, when I recognize it. Writing a ThingThatImWritingFramework risks ThingThatImWriting never seeing the light of day, or never being used.

Factories. I've got a codebase to work with using factories everywhere. Static arrays of them. Classes are given hardcoded enums and there's macro magic all over the palce to join classes to the factories that make them, and to generate all the factories in these static arrays of factories.

Sometimes the static array of factories contains a single factory. Creating a single item. No variation, no types, just one kind of one item.

The item is needed once. In one place.

Re: Id Software Programming Principles

#79

Post by devopsproject »

h1d wrote: post #44
zmb_ wrote: post #16

Earlier quoted context omitted.

They were four people shipping multiple games a year. They couldn't afford to prototype or build proofs of concept. They had to ship.

Doesn't sound like a generally useful tip.

"Make something you can sell" seems like a pretty straightforward strategy.

Re: Id Software Programming Principles

#80

Post by hyperpallium »

dualogy wrote: post #77
hyperpallium wrote: post #62

This is first class post-hoc bullshit. They weren't making prototypes or reusing code, they sure as hell weren't composing high-sounding principles. They just got on with it because they were talented experienced and motivated. For that reason, the rest of the talk is very inspiring - so listen to the hour-long video (half talk, half questions), and not the article which only has the post-hoc bits. https://youtu.be/E…

> they were talented experienced and motivated Agreed and that's the whole secret sauce right there, combined with: no distractions (social media or indeed even "coding forums" with constant flame-wars on this and that language/stack/paradigm) and crucially also no distracting "stack" or APIs to speak of (bare metal coding literally "on top of the BIOS" in these days, no OS/GUI/multithread/GPU APIs). The initial core…

Another eg of distraction-free programming: http://www.atariarchives.org/deli/cottage_computer_programmi...
Post reply on HN