Many games are held together by duct tape • Hacker News Board

Re: Many games are held together by duct tape

#111

Post by winrid » Wed, Jan 15, 2020, 6:00 PM UTC

CoolGuySteve wrote: post #101

As a counterpoint, the Quake -> Quake 2 -> Quake 3 original open source releases are remarkably clean. Quake 2 in particular is very minimalist and the game was developed in something like 10 months. Granted, it's not really fair to compare anyone to the id software team of the time. But the requirements of the Quake series, basically a BSP renderer that is easy to modify and extend, probably forces it to be extensib…

Also, Carmack had a philosophy of rewriting things instead of just adding code.

Re: Many games are held together by duct tape

#112

Post by soup10 » Wed, Jan 15, 2020, 6:02 PM UTC

kelvin0 wrote: post #67

Ex-Game dev here: shipped many titles on console (AAA and some zzz titles). When comes time to shipping a game, the crunches, pressure and overall stress is through the roof. Most everything goes at that point: duct tape, hot glue, bobby pins and toad spit. And if you disagree with management over these 'not so best practices' (in order to ship faster...) they will find someone to do it and you could be out of a job.…

it usually makes sense to start hacking and slashing towards shipping anyway since 95% games have a shelf life and aren't maintained and extended much beyond the original release. By the time the next game starts production there's probably major engine and platform upgrades to contend with and a different non-overlapping set of features to support so why bother with excessively clean well architected code that won't be re-used. (Of course this is somewhat of a self-fulfilling prophecy the state of the code-base influences business decisions with regards to what will be re-used and what the next game will be)

Re: Many games are held together by duct tape

#113

Post by hawski » Wed, Jan 15, 2020, 6:06 PM UTC

If AIs of today make a heap of code (if you say it's data, I say data is code is data) that is really a spaghetti of a code that happens to seemingly achieve a goal, maybe game developers are already a bit like that ;)

Re: Many games are held together by duct tape

#114

Post by AstralStorm » Wed, Jan 15, 2020, 6:12 PM UTC

tluyben2 wrote: post #108

CoolGuySteve wrote: post #101

As a counterpoint, the Quake -> Quake 2 -> Quake 3 original open source releases are remarkably clean. Quake 2 in particular is very minimalist and the game was developed in something like 10 months. Granted, it's not really fair to compare anyone to the id software team of the time. But the requirements of the Quake series, basically a BSP renderer that is easy to modify and extend, probably forces it to be extensib…

Engines (Doom, Quake) need to be much cleaner and more consistent than (one-off) games.

Mind you both reused many ideas from previous ones. Doom reused Wolfenstein 3D, Quake reused pieces from Doom. (WAD format for example.)

The engines made for the games were indeed intended to be one offs.

Reuse of design and formats does not imply reuse of code.

This is very different from new "universal" engines like Unity, Unreal Engine, Ogre, Frostbite, Dawn Engine or Unigine. Those were designed to be separate from games.

Re: Many games are held together by duct tape

#115

Post by AstralStorm » Wed, Jan 15, 2020, 6:18 PM UTC

desc wrote: post #95

zentiggr wrote: post #82

Earlier quoted context omitted.

> and that if you wanted to increase the FPS you could plug in more mice I am having trouble imagining what sort of event handling bs this might be taking advantage of... I am too vanilla a coder at this point in my life.

I'm not a game dev, but rough guess: the framerate is artificially limited to some 'sane' range by the equivalent of a short sleep() which is cancelled by an input event. More devices, more events, more chance to prompt the next frame early?

Yes, a typical artifact of not resuming the remaining sleep after the event handling.

Does not work with pushing random keys only because those are buffered separately.

Re: Many games are held together by duct tape

#116

Post by tluyben2 » Wed, Jan 15, 2020, 6:18 PM UTC

So is almost every other piece of software. I would like to see an analysis of commercial closed source software on how many of then use good practices, have clean code etc. Not the ones that filled in the [] we y use TDD in the CIO monthly questionnaire. Maybe I meet the wrong companies I have to work or integrate with, but in my experience it is not very far from 0% (but it is >0 luckily). I met one company last week who do everything right, but only for projects over 500k where over 10% goes into those practices, otherwise there is simply no money for the overhead...

Re: Many games are held together by duct tape

#117

Post by AstralStorm » Wed, Jan 15, 2020, 6:20 PM UTC

seren wrote: post #32

friendlybus wrote: post #23

Earlier quoted context omitted.

Could you take pride in rewriting the code? Maybe as an open source adventure with others? Going through the shame of showing it off is more valuable on its own merits than leaving it as is, regardless of the code quality or social outcomes.

I believe that as code "writers", we tend to have a bias that code should well-written. And I don't think it is that important. If you are working in a global company with a distributed workforce, well-written code is mandatory because it is a way to communicate and to maintain the code in the long term. Even more so if this is a critical code that could kill. But if you started as a lone developer for a game hobby p…

Well, there should be a bit of shame in writing code that's buggy or not working at all...

Of course if you avoid that while still writing a mess, it's mostly fine.

Re: Many games are held together by duct tape

#118

Post by tluyben2 » Wed, Jan 15, 2020, 6:21 PM UTC

AstralStorm wrote: post #114

tluyben2 wrote: post #108

Earlier quoted context omitted.

Engines (Doom, Quake) need to be much cleaner and more consistent than (one-off) games.

Mind you both reused many ideas from previous ones. Doom reused Wolfenstein 3D, Quake reused pieces from Doom. (WAD format for example.) The engines made for the games were indeed intended to be one offs. Reuse of design and formats does not imply reuse of code. This is very different from new "universal" engines like Unity, Unreal Engine, Ogre, Frostbite, Dawn Engine or Unigine. Those were designed to be separate fr…

True; I guess ID had this internal engine strategy or it grew out of the culture there naturally? I read the Doom book but don’t remember if that was explained. I have the Doom black book but did not read it yet.

Re: Many games are held together by duct tape

#119

Post by ken » Wed, Jan 15, 2020, 6:21 PM UTC

> “Games aren’t just an ordinary piece of software, they are a complex beast that require many different disciplines to successfully ship, and often on timelines that require sacrifices to be made,” said game developer ...

Is this any different from any other type of software? What is this "ordinary" software that doesn't require different disciplines, or have timelines?

Re: Many games are held together by duct tape

#120

Post by AstralStorm » Wed, Jan 15, 2020, 6:23 PM UTC

seanalltogether wrote: post #70

Wow a 3440 line switch statement for processing game state! https://github.com/TerryCavanagh/VVVVVV/blob/master/desktop_...

Explicit state machine is better than an implicit one. And every program is one of these.

4 KLOC for big chunk of game logic is rather frugal.

The main problems that are plain is not enough names (for states, flags and triggers) and not having split off text to some central repository. (Making translation easier.)

Orthodox version of the state machine would have code execute while you're changing states rather than in any given state.

The big switch statement is a good design with mediocre implementation. (Compare with Sierra's AGI LOGIC code: https://wiki.scummvm.org/index.php?title=AGI/Specifications/... )