- Joined
- May 29, 2010
- Messages
- 35,839
Hilarious.
They should just declare Fallout 1, 2, and New Vegas Legacy Canon. Chris Avellone said as much years ago https://chrisavellone.medium.com/fallout-apocrypha-77c75954641a
-
Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.
"This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
Cain on Games - Tim Cain's new YouTube channel
- Thread starter Goral
- Start date
They should just declare Fallout 1, 2, and New Vegas Legacy Canon. Chris Avellone said as much years ago https://chrisavellone.medium.com/fallout-apocrypha-77c75954641a
Gandalf
Arbiter
- Joined
- Sep 1, 2020
- Messages
- 395
Every release, wether game or tv or anything else should be considered it's own canon. It's the sanest approach, I think.
NecroLord
Dumbfuck!
I just loathe "adaptations" of any kind...
Very few examples of adaptations actually working while staying relatively faithful to the source material.
Very few examples of adaptations actually working while staying relatively faithful to the source material.
Mister Vespertine
Literate
- Joined
- Apr 15, 2024
- Messages
- 9
The show doesn't make any sense at all... corporations nuke the entire world for profit margins? What? Don't remember that being a part of the original Fallout experience. Could be wrong, but doubt it.
__scribbles__
Educated
NecroLord
Dumbfuck!
Do it for your career...
NotSweeper
Educated
- Joined
- Dec 26, 2023
- Messages
- 280
Quit taking it personally, unless two women become weirded out by having a literal man use the female bathroom. Then take it personally.
- Joined
- Aug 1, 2015
- Messages
- 503
Huge Mythbusters fan, has been watching Adam Savage's Tested, recommends it. Making this video after watching a video titled Quit Taking It Personally about career advice Savage gave to people who were sending in questions. As Cain watched it, he was noticing things from his own career.
First tip is called Q-Tip, Quit Taking It Personally, don't take work events personally, particularly the bad ones. You can learn from them. Cain's example is the guy working under him who did something behind his back after being told by his boss that he has mentioned before. Cain hopes that guy, and the audience, took it as a bad situation created by Cain's boss. What Cain took from that was he couldn't control his boss, he had done this before, and had done it to other game directors so Cain couldn't consider it a personal matter, if he wanted something in the game he didn't care if the directors didn't want it, he found ways of getting it in. Cain had seen this boss do it for years on other people's projects, and then he did it on him. Can't control him, literally above him, but Cain realized he can't control his employee either. He can tell them what to do, look at what they do, and then say it isn't what he asked them to do. They can have their reasons and excuses, but they can't say they can be excused. They did something Cain didn't want, it isn't personal. Cain isn't angry at you, but as your boss you did something wrong and you have to admit it. What was Cain supposed to do if his boss kept going to this employee and telling him to change stuff? Can't stop the boss, can maybe stop the employee. As the game director, Cain would be held responsible for the content in the game the boss demanded once it shipped. He can tell the employee he will monitor all of his work and if it keeps happening he is going to HR about it. People will say that isn't fair, and that is right. Cain's boss is creating an unfair situation, but don't take it personally. This is a business problem in hierarchy and communication. If Cain had brought it to HR, the boss would probably have tossed it out. But maybe if he hadn't, someone would have taken it as a lesson.
Second tip is late career luxuries. These are things Adam Savage did later on in his career now that he had financial stability and a good reputation. One example is dropping bad clients, something you really cannot do when you start out because you need everyone. Cain has talked about stepping down from lead roles and walking away from companies. Cain has told all of those stories, you can learn from them, but those are not things Cain expects you to do in two or three years. Sees people making a lot of mistakes, like demanding a lead role or being a director after being in the industry only 2/5 years. You can't just walk away from a role when you are new. Have to prove yourself first before you take drastic steps.
Last one is Mistakes Happen. Savage talked about all the mistakes on film sets, you're paying people to be there and you have to keep going. Stay flexible, keep your options open, pick an option and just keep going. Also, you don't have to blame the person that caused the mistake right then and there. Pick a moment later on to talk to them privately, figure out what went wrong and how it can be avoided, or if it's repeat problem, figure out how to deal with them. In the moment, you just have to fix everything. These are why Cain has fallbacks in his design documents, if things aren't working out, Cain things he knows can be done already prepared, with good estimates for how long they take. If you're two weeks out and have a two week fallback when your current feature isn't working, time to use it. Have a part of your design document dedicated to Fallbacks, they don't have to be super detailed because they are things you are familiar with. Had an entire Confluence page called Design Fallbacks for Outer Worlds. Cain has taken a lot of notes, and this is where he gets to the other thing. You can forgive people for mistakes, mistakes are often made because people are trying to be ambitious or challenging themselves, which is good. Other times mistakes are something anyone could make, like the Fallout issue of the less than equal instead less than that caused a two week crash bug, completely forgivable. But don't forget them. You don't want to that mistake again, you don't want that person to make a mistake again, you want to learn from it. Don't hold a Sword of Damocles over them, but don't forget those mistakes for your own sake as well as theirs. As a lead, you are going to be doing reviews of people, this is when you look at your notes at notice patterns. Maybe some programmers are producing more bugs, maybe they keep being slower than the other programmers. You talk to them about it, see their response, maybe it's a good one like the estimates for those tasks were badly done, or a parent passed away. But if they just shrug and disagree, then you have a pattern. Understand that mistakes happen, stay flexible, go with options, and then look at it latter and search for patterns that need to be corrected or can't be corrected. Do not do that in the heat of the moment.
TL;DR : Adam Savage Good, don't take work personally, can do some good things in your career later, mistakes happen, have options and deal with it.
First tip is called Q-Tip, Quit Taking It Personally, don't take work events personally, particularly the bad ones. You can learn from them. Cain's example is the guy working under him who did something behind his back after being told by his boss that he has mentioned before. Cain hopes that guy, and the audience, took it as a bad situation created by Cain's boss. What Cain took from that was he couldn't control his boss, he had done this before, and had done it to other game directors so Cain couldn't consider it a personal matter, if he wanted something in the game he didn't care if the directors didn't want it, he found ways of getting it in. Cain had seen this boss do it for years on other people's projects, and then he did it on him. Can't control him, literally above him, but Cain realized he can't control his employee either. He can tell them what to do, look at what they do, and then say it isn't what he asked them to do. They can have their reasons and excuses, but they can't say they can be excused. They did something Cain didn't want, it isn't personal. Cain isn't angry at you, but as your boss you did something wrong and you have to admit it. What was Cain supposed to do if his boss kept going to this employee and telling him to change stuff? Can't stop the boss, can maybe stop the employee. As the game director, Cain would be held responsible for the content in the game the boss demanded once it shipped. He can tell the employee he will monitor all of his work and if it keeps happening he is going to HR about it. People will say that isn't fair, and that is right. Cain's boss is creating an unfair situation, but don't take it personally. This is a business problem in hierarchy and communication. If Cain had brought it to HR, the boss would probably have tossed it out. But maybe if he hadn't, someone would have taken it as a lesson.
Second tip is late career luxuries. These are things Adam Savage did later on in his career now that he had financial stability and a good reputation. One example is dropping bad clients, something you really cannot do when you start out because you need everyone. Cain has talked about stepping down from lead roles and walking away from companies. Cain has told all of those stories, you can learn from them, but those are not things Cain expects you to do in two or three years. Sees people making a lot of mistakes, like demanding a lead role or being a director after being in the industry only 2/5 years. You can't just walk away from a role when you are new. Have to prove yourself first before you take drastic steps.
Last one is Mistakes Happen. Savage talked about all the mistakes on film sets, you're paying people to be there and you have to keep going. Stay flexible, keep your options open, pick an option and just keep going. Also, you don't have to blame the person that caused the mistake right then and there. Pick a moment later on to talk to them privately, figure out what went wrong and how it can be avoided, or if it's repeat problem, figure out how to deal with them. In the moment, you just have to fix everything. These are why Cain has fallbacks in his design documents, if things aren't working out, Cain things he knows can be done already prepared, with good estimates for how long they take. If you're two weeks out and have a two week fallback when your current feature isn't working, time to use it. Have a part of your design document dedicated to Fallbacks, they don't have to be super detailed because they are things you are familiar with. Had an entire Confluence page called Design Fallbacks for Outer Worlds. Cain has taken a lot of notes, and this is where he gets to the other thing. You can forgive people for mistakes, mistakes are often made because people are trying to be ambitious or challenging themselves, which is good. Other times mistakes are something anyone could make, like the Fallout issue of the less than equal instead less than that caused a two week crash bug, completely forgivable. But don't forget them. You don't want to that mistake again, you don't want that person to make a mistake again, you want to learn from it. Don't hold a Sword of Damocles over them, but don't forget those mistakes for your own sake as well as theirs. As a lead, you are going to be doing reviews of people, this is when you look at your notes at notice patterns. Maybe some programmers are producing more bugs, maybe they keep being slower than the other programmers. You talk to them about it, see their response, maybe it's a good one like the estimates for those tasks were badly done, or a parent passed away. But if they just shrug and disagree, then you have a pattern. Understand that mistakes happen, stay flexible, go with options, and then look at it latter and search for patterns that need to be corrected or can't be corrected. Do not do that in the heat of the moment.
TL;DR : Adam Savage Good, don't take work personally, can do some good things in your career later, mistakes happen, have options and deal with it.
You know, that whole genocide thing is a pretty BIG difference. About the worst thing you can say about the Brotherhood of Steel is that they withhold tech from the emerging civilization in the Wasteland because they have concerns about a repeat of the whole nuclear armageddon thing. Sure, tech can be used for good, but you can't argue their concern considering they're the hold outs from the military who had some high level clearance on what was going on.
That Shady Sands thing is a pretty damned big one. I haven't seen the show, but I was made aware that they nuked Shady Sands in order to reset the NCR so this show could happen basically. The really retarded thing is that they nuke Shady Sands four years before New Vegas takes place. I understand that Bethesda has a hate boner for New Vegas, but that's just being an ass.
In fairness to Tim Cain, he only saw the first two episodes and they reveal the Shady Sands thing later on.
The left doesn't understand capitalism. There's a reason why they get on Twitter or have interviews and tell people not politically aligned with them not to buy their product. They have no idea that their product's sales are what pays their salaries, therefore customers are important. Then they write sad posts on social media about how they're no longer employed because their company went bust or fell on hard times.
Axioms
Arcane
- Joined
- Jul 11, 2019
- Messages
- 1,519
Tim comes off kinda badly in the latest video. His boss is the problem. The guy knows Tim plays the game every morning and will see what he did. So I think that's a smart way to proceed. Low level employee doesn't have to go against the top boss. Tim finds the issue basically immediately. Sure go to your guy and say please just tell me next time and I'll pretend I found out some other way, totally fair. But don't threaten him.
I actually don't think there's a good way to proceed for the employee in that situation. The problem is management and he can't do anything. Both people are his boss and could potentially fire him.
I actually don't think there's a good way to proceed for the employee in that situation. The problem is management and he can't do anything. Both people are his boss and could potentially fire him.
NecroLord
Dumbfuck!
Best show EVAAAAAAR!!
No, seriously now, Tim really has a history of not speaking his mind and just trying way too hard to be the nice guy who doesn't want to stand up and offend anyone's ultraliberal sensibilities.
Fallout franchise has been RUN into the fucking ground and defiled from the day Bethesda got their sleazy money grubbing corporate hands on it.
This is the truth.
The tragic truth.
Every franchise that is left in the hands of Corporate Clown World is destined for a tragic fate.
Really, has Tim ever criticized any aspect of Bethesda's Fallouts? Like in this channel in any episode?
StrongBelwas?
- Joined
- Aug 1, 2015
- Messages
- 503
The only thing I can say with confidence without going through the archives is that he thought the humanlike Synth plot in Fallout 4 went over the line of what is acceptable in the setting and it's depiction of robotics, and an overuse of 1950s props that gives the impression of the world ending in the 1950s instead of the future the 1950s envisioned.
Example:
__scribbles__
Educated
roguefrog
Liturgist
This comes up a lot in previews for Fallout games. There's a lot of people who think that out there, and gaming sites have writers who think this and the editors don't seem to know enough to correct them.
- Joined
- May 29, 2010
- Messages
- 35,839
Good ol' Tim saying that crunch isn't always on management and in many cases a result of employees who spend too much time goofing off or cutting out early. 
He and some probably-autistic woman utterly destroyed a class by being the only people to pass an assignment that required them to start working on it at the start of the semester, great story.
He and some probably-autistic woman utterly destroyed a class by being the only people to pass an assignment that required them to start working on it at the start of the semester, great story.
- Joined
- Aug 1, 2015
- Messages
- 503
Previous crunch video generated a lot of commentary, people are still commentating it, which reminds Cain of a Crunch related story in college.
This story is Cain's first serious experience with crunch. Engineering school, fourth year, Software Engineering class that all the Computer Science engineering students had to take. It was all fourth year CS students with three years of classes behind them and a lot of prerequisites, they all had roughly similar schedules. Two years in, you declared your major, afterwards your classes were pretty well defined. Cain is going to talk about a software engineering class that had a project portion. Entirely solo project, told on day one of the class, 50% of your grade. Cannot pass without it. Very large project, first thing the professor warned people to do is not to wait to get started. He said he would give very little homework, and was honest about that. Only other test was the final exam. You had two grades for that class, half your final, half of your project, both of them at the end of the semester. About 15 week long semester.
The project required you to simulate the job queue of a mainframe computer, requests would come into your simulation and they need resources. An executable needs a CPU and this much memory with an estimated runtime. A print job might need a printer to be grabbed to print out 20 pages. There may be a request to write something out to a floppy or hard drive.
Those jobs can be interrupted externally or internally. External interruption is whoever submitting the job stopping it, quitting the program. They did part of it, don't want it anymore. Internal interruptions are the CPU running out of memory, the printer running out of paper, the program crashing midway through. All of those are interruptions of the job that have to tell whoever requested the job a portion was done but they can't complete it. Some jobs have to be done continuously, if you get a print request, you need to print out the whole file before moving onto the next request. If you get five different print jobs, you can't just do page 1 of each file. Others, like CPU executables, can be swapped between. You can be running part of an executable and take that CPU use for use on another executable.
You had to get that simulation working, and it was to test different scheduling techniques for those jobs. Various scheduling techniques, such as shortest job first, which schedules the shortest total duration jobs first. Shortest remaining time is an alternative, which takes the total duration and subtracts what is already done, prioritizing what has the most progress done. Longest job first, others look for what job would take the fewest amount of resources. The professor provided all the scheduling techniques he wanted you to code and submit. When you submitted your simulation, you gave him the executable, he would run it on input data that simulated various jobs. Part of this input data would be the particular scheduling technique he wanted it to use on this run and then you would have to output it into a particular format and he would compare how well it was handled.
Cain started it in the that very week. Only worked a few hours when he started, had a few break periods between classes. Would go to the computer lab and spend two hours between classes working on the project. For the first few weeks, he saw nobody from the class there. After a few weeks, a girl Cain didn't know started showing up there (Possible she also started week one and their schedules didn't line up until then.) He asked her if she saw anyone from the class there, and she hadn't even on the nights it was just her in the lab and not Cain. About a month in, they started seeing other people from the class come in, and as the semester continued they steadily began seeing an increase in people from the class until the entire class was there in the last few weeks. Cain finished up a few weeks early, ran as many tests as he could. Spent the last few weeks to study for the final exams of his other classes, had all results printed out.
Heard later on from the woman that a lot of people there who were working late and fighting over access for the limited terminals and printers the lab had. Lot of raised voices, lots of fights.
They had the final exam, you turned in your program at that point. Gave the professor permission to run the executable in your account. Professor said that over half the class turned in a completely non functional simulation, it would just not start up. Most of the remaining half gave in simulators that ran but gave wrong answers. Almost every scheduling system caused that, which meant the underlying simulations were off.
The only simulations that did not have these issues and worked correctly were Cain and the woman who started early. The class moved into an uproar when they realized 2 out of 30 were going to get a decent grade. They said the project wasn't possible, they didn't have enough time. Professor pointed out enough of the class put in simulators and enough good ones that it was clearly at least possible.
Professor pointed out how important it was to your grade, and that a big chunk of the project was time management, just like in real life.
Some students went and complained to a dean, and that dean pulled in Cain and the woman and asked them about the project. Cain mentioned that the professor warned them to start early. The Dean had access to their accounts and could see when they started, and could see they weren't starting early. After confirming with Cain that the professor warned them, gave minimal homework, the Dean thanked him and Cain doesn't know what happened beyond most of those students not passing. They retook it in the second semester, Cain can guarantee they started early.
Looking back, whenever Cain saw people at work complaining about work, they were the ones that goofed off a lot. Leaving early, coming in late, spending two hours talking about a movie that they watched, take really long lunches, etc. These people would then complain when crunch inevitably happened. This wasn't everyone, but it wasn't a few people either, it was a pretty decent number in team sizes of 75-100.
Crunch is bad, but not 100% management's faults. People who entirely blame management for crunch are usually inexperienced, used to small and dedicated teams, or are coming from indie backgrounds where they have no money and have to get something out.
Yes, it usually management's fault, do not mishear Cain, and sometimes it is the publisher's fault, but it also sometimes the people on the team. Those people who cause the problem are also the same ones who avoid responsibility when the time comes. They give their excuses, Cain thinks back to that class. Everyone got the same schedule and time, some people just didn't bother.
TL;DR :Crunch usually management fault, but if someone says it always is, ask them to prove it. Some people goofed off and thought crunch could save their semester, it didn't.
(Probably no summary next two days, out again.)
This story is Cain's first serious experience with crunch. Engineering school, fourth year, Software Engineering class that all the Computer Science engineering students had to take. It was all fourth year CS students with three years of classes behind them and a lot of prerequisites, they all had roughly similar schedules. Two years in, you declared your major, afterwards your classes were pretty well defined. Cain is going to talk about a software engineering class that had a project portion. Entirely solo project, told on day one of the class, 50% of your grade. Cannot pass without it. Very large project, first thing the professor warned people to do is not to wait to get started. He said he would give very little homework, and was honest about that. Only other test was the final exam. You had two grades for that class, half your final, half of your project, both of them at the end of the semester. About 15 week long semester.
The project required you to simulate the job queue of a mainframe computer, requests would come into your simulation and they need resources. An executable needs a CPU and this much memory with an estimated runtime. A print job might need a printer to be grabbed to print out 20 pages. There may be a request to write something out to a floppy or hard drive.
Those jobs can be interrupted externally or internally. External interruption is whoever submitting the job stopping it, quitting the program. They did part of it, don't want it anymore. Internal interruptions are the CPU running out of memory, the printer running out of paper, the program crashing midway through. All of those are interruptions of the job that have to tell whoever requested the job a portion was done but they can't complete it. Some jobs have to be done continuously, if you get a print request, you need to print out the whole file before moving onto the next request. If you get five different print jobs, you can't just do page 1 of each file. Others, like CPU executables, can be swapped between. You can be running part of an executable and take that CPU use for use on another executable.
You had to get that simulation working, and it was to test different scheduling techniques for those jobs. Various scheduling techniques, such as shortest job first, which schedules the shortest total duration jobs first. Shortest remaining time is an alternative, which takes the total duration and subtracts what is already done, prioritizing what has the most progress done. Longest job first, others look for what job would take the fewest amount of resources. The professor provided all the scheduling techniques he wanted you to code and submit. When you submitted your simulation, you gave him the executable, he would run it on input data that simulated various jobs. Part of this input data would be the particular scheduling technique he wanted it to use on this run and then you would have to output it into a particular format and he would compare how well it was handled.
Cain started it in the that very week. Only worked a few hours when he started, had a few break periods between classes. Would go to the computer lab and spend two hours between classes working on the project. For the first few weeks, he saw nobody from the class there. After a few weeks, a girl Cain didn't know started showing up there (Possible she also started week one and their schedules didn't line up until then.) He asked her if she saw anyone from the class there, and she hadn't even on the nights it was just her in the lab and not Cain. About a month in, they started seeing other people from the class come in, and as the semester continued they steadily began seeing an increase in people from the class until the entire class was there in the last few weeks. Cain finished up a few weeks early, ran as many tests as he could. Spent the last few weeks to study for the final exams of his other classes, had all results printed out.
Heard later on from the woman that a lot of people there who were working late and fighting over access for the limited terminals and printers the lab had. Lot of raised voices, lots of fights.
They had the final exam, you turned in your program at that point. Gave the professor permission to run the executable in your account. Professor said that over half the class turned in a completely non functional simulation, it would just not start up. Most of the remaining half gave in simulators that ran but gave wrong answers. Almost every scheduling system caused that, which meant the underlying simulations were off.
The only simulations that did not have these issues and worked correctly were Cain and the woman who started early. The class moved into an uproar when they realized 2 out of 30 were going to get a decent grade. They said the project wasn't possible, they didn't have enough time. Professor pointed out enough of the class put in simulators and enough good ones that it was clearly at least possible.
Professor pointed out how important it was to your grade, and that a big chunk of the project was time management, just like in real life.
Some students went and complained to a dean, and that dean pulled in Cain and the woman and asked them about the project. Cain mentioned that the professor warned them to start early. The Dean had access to their accounts and could see when they started, and could see they weren't starting early. After confirming with Cain that the professor warned them, gave minimal homework, the Dean thanked him and Cain doesn't know what happened beyond most of those students not passing. They retook it in the second semester, Cain can guarantee they started early.
Looking back, whenever Cain saw people at work complaining about work, they were the ones that goofed off a lot. Leaving early, coming in late, spending two hours talking about a movie that they watched, take really long lunches, etc. These people would then complain when crunch inevitably happened. This wasn't everyone, but it wasn't a few people either, it was a pretty decent number in team sizes of 75-100.
Crunch is bad, but not 100% management's faults. People who entirely blame management for crunch are usually inexperienced, used to small and dedicated teams, or are coming from indie backgrounds where they have no money and have to get something out.
Yes, it usually management's fault, do not mishear Cain, and sometimes it is the publisher's fault, but it also sometimes the people on the team. Those people who cause the problem are also the same ones who avoid responsibility when the time comes. They give their excuses, Cain thinks back to that class. Everyone got the same schedule and time, some people just didn't bother.
TL;DR :Crunch usually management fault, but if someone says it always is, ask them to prove it. Some people goofed off and thought crunch could save their semester, it didn't.
(Probably no summary next two days, out again.)
Last edited:
Naraya
Arcane
Man, Tim will get a LOT of flak for this one. Snowflakes just won't have any of it.
- Joined
- Jul 14, 2023
- Messages
- 432
I enjoyed that story, it reminds me of one of my MSc modules except in my case I was one of the people who waited until the last minute. Tim's right, it's a valuable lesson to learn and Universities should have more modules that require that kind of time management early in degrees when the consequences are lower so students have already developed the skills when they need them later in their course and working life.
- Joined
- Jan 28, 2011
- Messages
- 97,515
I'll repeat myself again that Tim Cain just gets it when it comes to work ethic! Hopefully his videos reach the inner souls of some of these younglings starting out in today's workplace. His advice goes well beyond the video game industry and pertains to the work environment generally. @Tim Cain ...
__scribbles__
Educated
As an Amazon Associate, rpgcodex.net earns from qualifying purchases.