Idle Weekend February 20, 2017: When Live Gives You a BFG

[Chris]

Idle Weekend February 20, 2017:

When Live Gives You a BFG
This weekend, we talk about our fatal flaws in gaming: sometimes, we need to learn to just use our goddamn BFGs. In other media, we're both digging Legion, and the violent stylings of one John Wick.

Discussed: Hearts of Iron IV, Doom, Dark Souls III, Alien: Isolation, Prey, terrible childhood fables, fitness, agile development, Batman: Arkham Origins, Batman '66, Batman (1989), Batman Returns, Batman v. Superman, Legion, John Wick Chapter 2

 

• Listen on the Episode Page
• Listen on Soundcloud
• Listen in iTunes

[SL128]

I also have the hoarding problem in games, to the point where I finished Fallout 4 with over 400 stimpacks (generally sticking to cooked food, which was also hoarded). 

 

One interesting solution to this problem is the cypher system from the Numenera table-top game, wherein there's no hard cap on these consumables, but holding too many can harm the player. From here:

Quote

 They’re one-use cool powers that can heal, make attacks, or produce effects like nullify gravity or make something invisible. The sky’s the limit. But they’re always consumed when used. And they cannot be hoarded. Collecting cyphers together in one place, or carrying many on your person can potentially have a detrimental effect–from the long term (illness) to the short (explosion!).

 

I haven't played the tabletop game or Torment and so don't know how it is in practice, but it's always sounded cool.

 

Edit: The cypher system works effectively in Torment

[lizzyinthesky]

Legion is extremely fascinating to watch unfold. Completely unsure how it will all pan out but I'm excited to see. I've liked how they've skirted around David's father although I feel like the Logo treatment gives that away somewhat

 

Professor Charles Xavier

[Lork]

There's actually a very specific reason for Rob's traumatic, formative encounter with the cyberdemon, and it's dumber than you might think.  You see, despite the fact that iD obviously wanted you to use the rocket launcher for that fight, as evidenced by all the rockets they give you for it, boss enemies are uniquely resistant to it.  They're immune to splash damage, which accounts for at least half of a rocket's killing power normally.  

 

If I had to guess I'd say they probably did this to prevent the cyberdemon from killing itself with its own rockets, but regardless of the reason it's absolutely piss poor game design.  How are you supposed to figure out what's going on?  Without extensive research or just looking at the code, you wouldn't.  With the information the game gives you, all you can do is come to the reasonable but incorrect conclusion that either the cyberdemon has twice as much health as it really does, or that the rocket launcher is much worse than it actually is.

[tilde]

I know this was a throw away line by Rob, but Epicurean fables do exist. While they are not written in modern language, they are still pretty accessible:

http://www.la-fontaine-ch-thierry.net/fablanglalphab.htm

[murdocj]

I have the hoarding problem too in games... always saving potions, ammo, bandages, whatever.  Like Rob I'm afraid I'll get to some point and be utterly stuck.

 

And here's some long comments on the software dev discussion because I've been thru a couple of different flavors of Agile at several companies, including Scrum and Kanban.  As R&D said Agile is a reaction to the rigid form of Waterfall, where you had to complete each step (specification, design, implementation, testing) before starting the next step.  The goal with Waterfall is to make sure you are delivering what the customer wants to avoid rework, but because each step is so huge, it can be years before the customer sees the result, and the requirements may have changed by then. 

 

In Scrum teams operate in fixed chunks of time, called sprints.  A sprint is always the same length, generally 2, 3 or 4 weeks.  At the start of each sprint, the team picks off the work it can accomplish in that sprint, and by the end of the sprint, the work is done and tested.  The customer sees what has been accomplished and can react to it.  The idea is that you can do a course correction fairly rapidly if the requirements change. 

 

Kanban is similar, but is structured around the individual features rather than fixed lengths of time.

 

The problem you run into with Agile is that people focus on very short term goals and lose track of the bigger picture.  Items that are necessary but bigger get deferred because they don't really fit into the neat little Agile timeboxes.  I recently worked on a system where a bunch of features had been added over time, each one of which made sense on its own, but together the result was literally incoprehensible.  Even the manager who was supposedly managing the project had no idea how it worked.  I ended up writing a summary for the product manager to try to boil it down to the essentials, and it was still hard to figure out.  That's what happens when you don't have an overall picture of where you are going.

 

As Rob said it comes down to the people more than the methodology. 

 

Danielle's comment about "no silver bullet" reminded me of a paper by that name written by Fred Brooks, who managed the first really large software development project.  His book "Mythical Man Month" is a dated but very readable collection of essays on software dev.  Lots of great quotes, e.g. "It takes 9 months to have a baby, no matter how many women you assign to the job".