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

51–60 of 83 posts

Re: Id Software Programming Principles

#51

Post by [deleted] »

NumberCruncher wrote: post #15
Hansi wrote: post #12

> "No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code." I disagree with this so much, prototypes and proof of concepts teach you so much but usually they are crap you will always write it better a second time. Throw away the prototype and re-write it as a much better implementation.

For every prototype / POC thrown away there are 9 other prototypes ending up in production or getting sold as business software. If you feel the urge to write a prototype to learn something new please do not show it to your manager/sales rep!

[deleted]

Re: Id Software Programming Principles

#52

Post by Ace17 »

msangi wrote: post #25
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.

That's indeed a very good advice. All abstractions have a cost and no abstraction is better than the wrong abstraction. I found this talk on the topic very interesting https://youtu.be/4anAwXYqLG8

In the same vein:

prefer duplication over the wrong abstraction ( https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti... )

Re: Id Software Programming Principles

#53

Post by zerr »

alkonaut wrote: post #7
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.

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…

Exactly. e.g. it might be much easier (for some) to come up with a finished product/Game with Unity, with mouse clicking here and there... But it takes away all the fun of game development. On the other hand, I'm pretty sure it is hell a lot of fun working on Unity itself... So all the sweet is for their in-house devs :) (Same goes for Rails, Node, .NET, etc...)

Re: Id Software Programming Principles

#54

Post by mikekchar »

alkonaut wrote: post #7
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.

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…

Generalisation is always needed in a code base. However, only generalise pieces that you actually use in your code. YAGNI (You Aren't Gonna Need It) is a great principal. You should follow it -- until you need it. Then, of course, do what you need to do.

People often think that projects get slower as code is added. However, the systems we work with are dramatically more complex and based on more pre-existing code than ever before. Because that pre-existing code has been generalised out, we can write new code easily and quickly.

There are two situations that you need to think about wrt to this issue (IMHO). If someone needs to do something that you have already done in your project, it should be simple and obvious how to do it. The more often something needs to be done, the more simple and obvious it needs to be. However, if someone needs to do something that hasn't been done before (even if it is is very much related to what already exists), then all doors should be open. The code should not imply how new work should be done. It definitely shouldn't try to guess what you want to do and do it before you get there.

Re: Id Software Programming Principles

#55

Post by hyperpallium »

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.

If you know you're going to have to experiment a lot on some aspect of the game/product, it seems to make sense to isolate that part, removing the commonalities into some kind of framework (perhaps informal, jury-rigged, so you can iterate on just that aspect.

A bit like the Wright brothers building a wind tunnel, so they could experiment quickly with control systems.

But Id wrote some great games, so maybe I'm missing how they handled this aspect...

Re: Id Software Programming Principles

#56

Post by pjmlp »

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.

There is a saying in game circles, either one writes a game engine or a game, as most studios tend to die spending the publisher's money build the next great engine.

Re: Id Software Programming Principles

#57

Post by douche »

pandaman wrote: post #35
NumberCruncher wrote: post #15

Earlier quoted context omitted.

For every prototype / POC thrown away there are 9 other prototypes ending up in production or getting sold as business software. If you feel the urge to write a prototype to learn something new please do not show it to your manager/sales rep!

In games industry nobody ships prototypes. If you manage to put one on Steam it's not going to sell much either. And yes, writing prototypes is normal, read on "Cerny method" if you are curious.

The existence of so many half-baked and abandoned early-access games on Steam would seem to belie this claim. It's not uncommon to see a few hundred reviews for games where the developers have ghosted without finishing.

Re: Id Software Programming Principles

#58

Post by NumberCruncher »

pasquinelli wrote: post #50
NumberCruncher wrote: post #15

Earlier quoted context omitted.

For every prototype / POC thrown away there are 9 other prototypes ending up in production or getting sold as business software. If you feel the urge to write a prototype to learn something new please do not show it to your manager/sales rep!

What if you prototype a game mechanic and it's shit?

The article talks about similarities between common agile practices and John Romero's programming principles. There is a world beyond the gaming industry where you can sign big contracts and ship broken software and no one dares to complain.

Re: Id Software Programming Principles

#60

Post by crdoconnor »

Hansi wrote: post #12

> "No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code." I disagree with this so much, prototypes and proof of concepts teach you so much but usually they are crap you will always write it better a second time. Throw away the prototype and re-write it as a much better implementation.

>you will always write it better a second time.

No. You won't:

https://en.wikipedia.org/wiki/Second-system_effect

Post reply on HN