As a battle scarred development manager and release manager, I endorse every single point Tim makes in this video. It's rare to see someone who understands the legitimate concerns of both the dev perspective and the management perspective.

@DreamsStreamChannel

Ай бұрын

40+ years of XP hard earned! :} (Also gives off an introspective feel, so probably has thought about this stuff a bit before)

Everyone concerned with this question should read Mythical Man Month by James Brooks then read Scrum TLDR: your estimates are useless unless they come from the team doing the work, and that team has worked together for a long time on similar problems

@CainOnGames

Ай бұрын

Wow, I read Mythical Man Month when I was in engineering school, and it was a decade old book even back then. Project estimation issues are timeless.

@gilgamecha

Ай бұрын

@@CainOnGames yeah it's a really rare example of an IT book that's as relevant today as when it was written. So many of the key insights are still operative. Like: large projects fail (or slip) at the interfaces. Which launched first structured programming and data architecture and then OOP. And we're still struggling.

@cornoc

Ай бұрын

Scrum is a cult.

@joshuachristenson2014

29 күн бұрын

@@gilgamecha Unrelated but love your 'epic' username.

Tim casually outing himself as having never seen Game of Thrones

@MrCaveatLector

Ай бұрын

He's actually spoken about his time in Croatia for a conference talk before, and how he got to visit a lot of the shooting locations and nerded out. 🤷‍♂️

@kotzpenner

Ай бұрын

Eh, me neither

@Chatetris

Ай бұрын

Nice! He's just like me!

@ComissarYarrick

Ай бұрын

I too didn't watch the GoT, yet I'm familliar with all the main characters and overall stroy and how unsatisfing final season was. It's one thing to not watch the show, and another to know nothing about it. Popcultural osmosis simply makes some things unescapeable ( unless you live like a total hermit or something....)

@IamHomelander

Ай бұрын

The only RR I know is Elden Ring. Plan on keeping it that way.

As a previous Director of Technology at an advertisjng and Marketing agency, I can confidently say that these challeneges and your advice are relevant in other industries beyond games. Internal and external stakeholders apply pressure to delivery teams to get the most value with the least investment. Something I would add is to be conscious of when estimates are questioned (from outside the technology team). On a regular basis, it can lead to trust and quality problems within the team. I would say that it's up to the manager to address any gaps of understanding in communications with stakeholders so that the manager can confidently stand over estimates that are shared. If there's a back-and-forth then the manager turns in to an unreliable middle-agent.

I don't work in game development, but I do in software. I think the sweet spot is to pad your estimate by about 30 - 40%. So if you think it would actually take you a 10 days, say it will take you 14 days instead. This is still in the realm of what your actual estimate would be, so if a feature is dropped it likely wouldn't be because of the padding, while also giving you some room to tackle any hiccups that come up. It is very difficult to account for these hiccups in your initial estimate, so often times I find that the slightly padded estimate ends up being right on target. The other thing to keep in mind when estimating is that a task is not just the actual work listed. From my experience these are the main things you should be considering when estimating: 1) The actual work as listed (break it down into as small pieces as you can). 2) Developer testing (you need to be testing your own code). 3) Communication time (Higher ups, other teams, etc). 4) Feedback adjustments (typically I do ~20% of #1). 5) Documentation.

@Snout007

Ай бұрын

I work in creating data management systems, I use the same principles and also extend my estimate by 20-40 percent. Sometimes managers themselves change the requirements because their initial idea was not thought out well.

@marcsh_dev

7 сағат бұрын

Heh, Hofstadter's Law (yes, that one): It always takes longer than you expect, even when you take into account Hofstadter's Law.[2]

Something else to take into account is whether feedback and feedback implementation is accounted for in the estimates. You'd be surprised how often producers and leads don't even think about that. You may have 2 days to do a task, you'll finish EOD on day 2, the lead or directors will give feedback and the producer will poke you on day 3 asking why the task isn't closed. Like Tim said, communication is super important to make sure everyone is on the same page with the timeline. Having a structured set of stage definitions is also incredibly important to know what the expectations are of the task (Blockout, Functional, Presentable, Shippable, Polish). That way if someone asks why the textures aren't setup on the asset, you can point to the stage we're on for that asset and show that "Functional" doesn't include final textures. It helps keep everyone on the same page with the same expectations. This also helps with bugs, as you can implement checking systems in between each stage, from accurate collision volumes, to physics materials, to VFX implementation, etc.

@ToyokaX

Ай бұрын

Yep, this is why I always give a conservative estimate of around +2-3 days to most of my tasks so I have room for feedback implementation.

I thought for sure when Tim talked about why it took him so long to make this video it was because he underestimated how long it would take him :P

This comment could be a lot longer, but I'll try to keep it short! This channel came at just the right time for me. Like you, I've always had such strong opinions on RPGs that I play, about what aspects and mechanics I do and don't like. Similarly to how you have said that you made your channel in the hopes that other people make games you like, I have been thinking for a long time that maybe someday I could create an IP that would scratch the itch that I have, and that I see others have online for a game that has all the right boxes checked, as there seems to be a large group of folks who are looking for the same thing as me in a game, but not a lot of game companies seem to think it is a worthwhile style of game anymore. Just over a year ago, I finally started writing down all of my thoughts. Eventually, I started a map, naming races and characters, and developed a plot. You have your approach to designing a fictional world, but I have been jumping between setting, plot, and mechanics the entire time, which I've found is creating a very tight knit idea, where story, setting, and mechanics are able to lean more heavily on eachother. Anyway, I'm a long ways out, I'm sure if I kept the pace I have kept, it would take me years to have what would feel like the entire vision complete. My question is- when that day comes, how would you handle approaching the huge task of getting something made into a game? I am imagining something on par with the scale of FNV, which would not be cheap or easy. Certainly outside the scope of what one person can build. If someone had the entire wiki for FNV, and approached a studio, would it even mean anything to them? Ideas are cheap, but what is a fully thought out game/in game universe worth? I'm sure it would be worth more with a vertical slice done. But would that be enough? And then there's the fear of losing the wheel on creative rights. I couldn't imagine putting years of my life into an IP, only then to have a room full of people who never cared about it until now, start changing things that are fundamental to the IP. I have thoughts like "should I make a book? Or convert it into a table top campaign to get the IP some traction? Start a development channel?" I'm sure you can see where my head is at with all of this. Let me know if it is anything you feel you have any insight into. My second question- How/where do you find yourself wanting to draw the line for evil options in an rpg? Similarly to how I find myself having a hard time choosing the evil option in a game, I find myself having a hard time writing them! I think to myself, I don't want anybody doing this awful thing to that character I like so much. But I do feel that the options should be there, to an extent. Now, most games I have played have far fewer bad karma options than good. Maybe one evil dialogue, to the half dozen good dialogue options. How do you weigh in on this? If you have any thoughts on either of these things, I'd love to hear it. Your channel has been a huge help. Even if the video you put out has nothing to do with what I'm thinking about, it is still the exact right blend of words for me to be listening to while I mow the grass. I find myself constantly pulling my phone out to write a note down about an idea I have for my IP. It is amazing the ideas I have, that have nothing to do with what you are talking about, but because you are talking about development as a whole, somehow it all bleeds through. This channel is really such a creative ecosystem. Anyway. Thanks again Tim!

@CainOnGames

Ай бұрын

These are both good questions. I started writing a response, but I think they deserve video responses for two reasons. First, my answer is long and nuanced, and I don't think my writing ability is up to the task. And second, a video will be seen by more people than a comment, and it's easier for me to refer back to it in future videos. These are very different questions with different responses. So...two videos are coming up!

@nashuaaaaa

Ай бұрын

@@CainOnGames That is the best answer I could have hoped for! Thanks a ton

My background is software development, not games development. I dont know if its the same in the games industry, but I don't begrudge product teams for asking for estimates, nor do I struggle to provide them. The thing that gets my knickers in a twist is when we've provided an accurate estimation to the best of our ability, and other forces in the organisation are promising it earlier than we have estimated and expect us to deliver on that, with consequences for not doing so. I don't know what the solution to that is

@CainOnGames

Ай бұрын

Other than communicating that those “other forces” provided incorrect estimates, I’m not sure what to do either

@zwmmbrl7974

27 күн бұрын

Who are they promising it to then? Is there no way for your team to directly communicate with the client? For example, we have a meeting every two weeks where all stakeholders can log into an online room. The point of the meeting is to be very brief and to update everyone on where projects and tasks are at in their development cycle. This way, open communication is guaranteed across the organization. The meeting often ends in less than 15 minutes and it helps set everyone's expectations in line with reality.

@theburntcrumpet8371

27 күн бұрын

@@zwmmbrl7974to the client. Who we also meet with every two weeks to show progress on the project, but the deadline discussions happen over our (the actual developer's) heads

I'm not in the game industry, but in my experience time estimates are should be twofold between you and your manager. You as a dev should try to give a reasonable and accurate (as far as you can be) estimate, but I also think it makes sense for your manager to communicate a buffer on top of that up the chain. 4x is excessive, but saying something will take 4.5 weeks or 5 weeks instead of 4 seems very reasonable, especially when you both are tuning your estimates.

@bricaaron3978

Ай бұрын

But 4.5 - 5 instead of 4 is nowhere near 2x...

@zwmmbrl7974

27 күн бұрын

This has already been commented, but it is common to estimate x1.3 up to x1.5 times the original estimation to deal with unforeseen circumstances. Also, if you estimate two tasks on x1.5 times the original estimation, and you solve one within the original time frame, you can double the original time foreseen on the other issue. For example: Two tasks are estimated for 2 weeks of work each. You communicate 3 weeks of work to the stakeholder. You finish one task within two weeks of work and the other within four. --> You still reached your estimation goals.

Your inisight is priceless! I would never be able to have this deep understanding of these topics if it wasnt for you. Lots of Love from The Netherlands!

At 6:00 You can see the dog's reflection on the glass to the left of Tim.

@MagnusEdvarsson

Ай бұрын

He has to show us the doggo in his next video 🥺

@bricaaron3978

Ай бұрын

Yes, I know. And it caused me to have to rewind a bit because I was paying attention to the dog instead of Tim.

@arrjantarach7538

Ай бұрын

@@MagnusEdvarsson we demand it!

@CainOnGames

Ай бұрын

@@MagnusEdvarsson You should check out the Shorts in this channel. Many dog videos.

This is a great topic that comes up in almost every freelance career. Really helpful insights! Thanks!

"the answer to everything is money." Too true Tim, too true.

No idea why this video was recommended to me but very valuable information regardless. Even if im not a programmer, everyone with a job should work on their time estimation

After many years of gamedev (though not as many as Tim), Ive found the biggest helper for time estimation is allowing folks to fail at it. At places where people start getting in trouble over estimation (and this can be passive aggressive versions of getting in trouble), people will start using defensive responses to doing it. This can be a lot of things, but padding time is a big one, but also skimping on quality is a big one, along with just shipping programmer known bugs to hit some arbitrary date.

@marcsh_dev

7 сағат бұрын

Programmers of similar skill taking different amounts of time to do something isnt uncommon, unless they have really really similar backgrounds. At any given moment programmers have a litany of things theyve done, and these can be radically different, even if theyre in the same programming task group (ie, graphics, gameplay, UI, etc). When its your third UI system and youve done it from scratch each time, vs someone that has worked with Unreal's system, even though they both have 'UI' experience, theres all sorts of reasons one might be faster than the other on a particular new UI task, regardless of its details. Its a wicked problem

"How much is that doggy in the reflection?" 😄 great video. As a programmer, time estimation can get to the point where it's a joke. Many things are not often taken into account unfortunately.

You reminded me to add inventory sorting and tagging to my game. Thanks Tim.

Thanks for this great, balanced take on both sides of an oft-contentious topic.

As a junior, these videos are super awesome. I can really relate to some past experiences I had and really, reeeeeally things would have come way better if I had asked or communicated better with my managers.

God tier video

Uncle Tim, thanks for helping me become a better professional. I was recently thinking just about this topic, and having you lay it out with your experience is incredibly valuable

Regarding getting angry at a manager pressing you for an estimate (or asking you "can you do X till Y?") if you struggle with those questions under stress try to say: I'll have to check that, I can give you my answer tomorrow/in an hour. As long as you follow up instead of the manager having to run after you, it might be annoying to the manager but if that prevents you from giving false estimates that's worth it. It's better to tell someone no then to be on the hook for a yes you can't fulfill.

One key point is to never stop dialogue, each party needs to clearly communicate with each other, in order for any project to be more streamlined and done as advertised.

@lindsaysfallout

Ай бұрын

Exactly. We have to be able to trust and communicate with each other about the constraints we're up against, respectfully, instead of just being snippy and mad we aren't getting the answers we want.

I wish we hear more stories like this. Day to day, from the trenches, how it is to be a game developer. I mean you've already got a lot of them, but I wish we hear more about he dark side.

A running joke from my bike mechanics hobby: "If I say it will be done in a week, then it will be done. You needn't remind me every month!" :) Relja

Oooh! This is a good one. I've been trying to learn best practices regarding the communication (and managing the communication of) estimations from as many veterans as possible as it's something I've felt I've always failed at.

While SCRUM has many issues, I do like how it has the team estimate task together to (hopefully) get a balanced estimate. Although there is that pressure not to be the one who strays for the general estimate the rest of the team is leaning towards

@cornoc

Ай бұрын

Yeah, Scrum is very flawed at best and basically a cult at worst. You already pointed out one of the main issues, but there's also the fact that people can't accurately estimate tasks in abstract units of "effort". Half the people secretly use it as a proxy for time in their heads without saying so or even being conscious of it. Stakeholders and managers question the assigned story points in the refinement session and try to get it knocked down. Devs know they're supposed to assign a generic "effort" value, but the scaling is never accurate because seniors and juniors have a different internal representation of what kinds of tasks are effortful and to what degree. Something that takes half the time for a senior to complete vs. a junior won't be scored in such a way that a team full of seniors would end up with twice the sprint velocity. Sprint velocity is calculated as a moving average based on how many points were completed in recent sprints, and people either develop an aversion to scoring tasks with low numbers because that ends up with too many tasks assigned in a sprint for them to complete (making the burndown charts look bad), or they develop an aversion to assigning over a certain number of story points per sprint. Either way, story point or velocity estimates tend towards never ending inflation. Bugs, QA, and exploratory tasks are the absolute worst in terms of estimation because of their open-ended nature, and consistently throw off predictions to the point of it starting to seem like an exercise in futility.

This goes to software developer career in general, and as someone in industry this is good wisdom to apply and be aware of.

Great video! Teams in the agile world often use techniques that involve estimating tasks through consensus from the team. An example of this is planning poker. In this context, it is not possible to tie the estimation to an individual. In this context what would be the negatives, if any, for someone that overestimates? The negatives you mentioned around overestimation all involve tracing the estimation back to an individual

really good advice!

The difficulty of time estimation is why we have Agile/Scrum -- where you estimate by complexity.

Oo this had a lot of useful info, had to get out my notebook to take notes lol

Hello Tim! Lately I've been thinking a lot (like A LOT) about something I call "personality roleplay", perhaps designers have their own term for that. I’m talking about conversations with multiple reply options that ultimately (or immediately) lead to the same outcome and basically are just different flavors of the same reply. Historically multiple reply options were associated with actions and consequences, so when such thing came into massive public spotlight, like certain scenes in Mass Effect with “Enthusiastic Yes”, “Neutral Yes” and “Annoyed Yes”, it was made fun of, because it didn’t affect anything. But in later games it’s much more refined concept, and games like Cyberpunk 2077 rely heavily on flavored replies, even some of such unlock only if some required stat is high enough, just to empower your roleplay fantasy without any real effect on the world. And Baldur’s Gate 3 leans into it a lot adding replies based on race, class, backstory that lead to the same outcome as generic replies, but reaffirm your character. I believe it’s something that lets the player feel a bit of agency in a linear situation, like your character can’t affect the situation, but they can express your feelings about that more accurately making even a linear story more personal. And it can enhance experience when it is actually about actions and consequences, allowing the player to express sorrow or enthusiasm about making same tough choice. I think it’s something that is often misunderstood by players most likely and not really talked about publicly. Developers can boast about vast amount of conversation lines and a separate fact of having actions and consequences system, what makes players connect the dots and assume that conversations are all about that, sometimes even preventing from diving in playing the role being afraid that if you say something in negative tone to a character it would immediately ruin your run for the side of the good guys. And then ultimately expressing their disappointment when it turns out that most of reply options are about personality roleplay and actual world-affecting choices are rare and very emphasized in the moment. I’m interested to know, what do you think of personality roleplay in video games? Is it something that should be obviously differentiated from important choices to allow players to deviate from ‘top listed reply’ without pressure, or not, to allow surprise consequences? Thanks for your time, games and channel, Tim! _ P.S. My favorite such moment of late was in Baldur’s Gate 3 in a romance scene with Shadowheart where you have option to just kiss her, or say something to basically confirm her consent, and since player character is not voiced, both options just lead straight to the same scene, but it’s nice to have such option if you are as player not really comfortable with an idea of unspoken consent.

@CainOnGames

Ай бұрын

Good question…and I’ll need to chew on my answer. I’m not a good writer, but I do have strong opinions on player choice in dialog.

In art, there's a joke about "take the number you think, double that, then double it again, that's how long it really takes." Since estimating requires constant measurement and tracking, I'd recommend (especially early in your career) starting with a random guess of what you think is right before you start and then literally time yourself by the hour even with a simple website timer and record the hours it takes for each task you do. You'll find you get more accurate very quickly, and then this expands as you go from an individual contributor to actually managing projects. However, on management, one thing you mentioned that I really disagree with: I think dropping the conversation after someone's estimate is too long is, in fact, not good management. If someone calls you a bad manager for trying to adjust their estimate, that's on them, but you not communicating your response, good or bad, is your responsibility. You don't give that person the opportunity to learn from their mistake, whether it's padding or their inaccurate.

@joshuachristenson2014

29 күн бұрын

IIRC, Tim mentioned in the video that his previous attempt(s) to push further with someone's too-long estimate, ended up with some staff perceiving him to be managing badly or something to that effect; so this time around he didn't believe it was worth it to push the subject. Sometimes people try to adjust for the feedback their staff provide, and sometimes keeping people happy and motivated may be worth more in the long run, depending on how minor that feature was.

I'm going to clip this video and make little videos where Tim is my boss.

Thank you for the insight Tim!

And yes I am a nerd for info I would never do anything with (I am no programmer/software engineer) But I love listening to these topics alot!

While it's not good to add excessive arbitrary padding, you can use data from your previous estimates to give more accurate estimates. At a previous job, we tracked estimates and time spent thoroughly and determined our ratio of estimate vs actual time spent. We then multiplied future estimates by this. E.g. my estimates over many projects averaged to about 2:1, i.e. 100% over estimate. Ever the optimist. So I would multiply my estimates by 2 and other people in the team had their own multipliers. Even as people got more experienced doing a certain thing this number held pretty steady. It didn't seem to really matter how much time was spent estimating. A gut feeling vs 2 hours spent breaking down a project resulted in a similar number (we did some experiments with that too). It seems that people have an inherent level of optimism when estimating that stays relatively consistent. The tedious part is that you need to collect the data first. You can start with an arbitrary number, but don't go crazy. Something like 1.5x your estimate might be a good starting point. Record your unpadded estimates though for your data points, or else keep good track of exact paddings used. You have to track all your time, as honestly as possible. This can be hard until you've built a habit of it as it's very easy to forget to log when you started or finished working on something, but if you get in the habit it's just a sub-conscious thing you do. It can also be useful to log time for specific tasks, e.g. dev, testing, meetings, admin, etc. so you have a breakdown of that, but it's less important than the overall number. If your workplace doesn't log time or estimates like this and you can't convince them to, you can also just do it for yourself in a spreadsheet. It's a valuable exercise to get to know your own level of optimism in this context. There are still cases where it's too unknown to estimate, in which case you can allocate a window of time to doing a POC of the unknown parts and then come back to the estimate after that time. For a very unknown project you can split it into multiple of these POCs. The other important thing, which Tim already said, is to make sure to track your progress and talk to people when you see something taking longer than it should, or unexpected elements of a task appear, or whatever. It can be easy to fall into a trap of thinking it's a failure to not meet your estimate (which probably wasn't realistic to begin with but you don't realise that at the time) and try to hide it and do whatever it takes to make it work in the background. That will usually end you up telling them at the last minute that it won't be finished, when there's no time to change course, or burning yourself out getting it over the line and hiding how many hours you really spent getting it done. Neither are great outcomes.

Imo proper time estimations just comes with enough experience, and even then it might be ways off at times. Sadly some treat the estimate as a strict deadline. When I estimate time on work I also make sure to include how reliable each part of the estimation is on a scale of (High/Medium/Low Reliability) and reasons why each part is or is not reliable. And as you noted breaking up tasks that are too large to more easily estimate time is a must sometimes, I've met enough vague and gargantuan tasks that needed to be broken up and given more information before I was able to properly estimate each part of it

Would be interested to hear your opinion on time vs story point based estimation. I haven't worked in game dev, so I'm not sure if this is applicable.

Thanks for this video. Always been an issue. I fear all the times I've been let go have been because of my inability to estimate time. I'm in the construction industry technically. Even though I was a junior level, I was asked to give time estimates on tasks I had never done before. And if I estimate too long, you just get grouped as a labor liability.

I like to look if it's harder or easier than another task. If it's twice as hard double the other tasks estimate

I always do what Scotty did. Over estimate and deliver it early.

Hey, Tim. I mentioned before that I was the lead writer of the Fallout 2 Resoration Project. I'd like to know how you feel about mods that expand upon games you've worked on and how you feel about that.

@CainOnGames

Ай бұрын

Hi Adam, I have talked about mods and specifically mods of my games here: kzread.info/dash/bejne/fnxozs6GgdCwYag.html I do not review specific mods or games, however, for reasons given here: kzread.info/dash/bejne/n3qOtdZshMSrZ7Q.html

@adamdravian

Ай бұрын

@@CainOnGames Thanks for the response,, Tim. It's an honor

@CainOnGames

Ай бұрын

@@adamdravian It's an honor that people care enough to mod games I worked on,

@adamdravian

Ай бұрын

@@CainOnGames Thank *you* for providing me with my favorite games of all time

I'm trying these days to hack in a feature when I'm unsure. This has often revealed to me if it is something simple or needs a long time to do. (Does not always work but work out but I usually can make a better estimate when I'm unsure about how much time a feature would take)

I am a quant portfolio manager (which in my case, involves almost entirely programming). I generally add time (padding) for unforeseen issues. In that sense, I view padding as a way to improve accuracy. It's just a matter of figuring out what the right padding factor is. For me, it's something like 1.5x but I suppose if you are sufficiently precise, then you won't even need a padding factor, but I sadly lack that skill of precisely breaking down a task.

@pieflies

Ай бұрын

Agreed. I've seen this work first hand. We gathered quite a lot of data of estimates vs time spent at a previous job and the multipliers stayed consistent over time. While there was a decent range of multipliers across the team, there was never anyone that didn't need some padding, and gaining experience didn't really change people's multiplier. I think it would be a rare person that is accurate without a multiplier. Even as you build a bigger mental database of the components and gotchas of a task, your inherent level of optimism in your estimation remains and affects your overall estimates. I'm not sure how/if you can change that personal optimism level but it's a whole other topic I'm sure.

@JavierBonnemaison

Ай бұрын

If you could be sufficiently precise, you wouldn't be estimating.

Hey Tim, How do you deal with the goal posts repeatedly getting shifted? Other than pointing out that that renders previous time estimates obsolete, of course, or is that enough?

@CainOnGames

Ай бұрын

That’s exactly what I do. “Oh, you want all the NPCs voiced? Ok, that means we need to finish the writing earlier, and have a bigger budget for voice talent and audio processing, and it will take up more space so the game will be much larger shipped. Here are the new time and budget numbers, please sign off on it here”.

@nickquejada

Ай бұрын

@@CainOnGames Give honest, accurate information; allow them to make a decision (and hope that the decision's a good one). Sounds like I'm on the right track then, thanks!

Hey Tim I've got a question regarding getting started I've got ideas for system design iterating on games like Monster Hunter and FF7 rebirth right Are there any game dev tools with like, 3d action game libraries i can use so i can more easily get a working, even if non -sellable, skeleton going for gameplay i can then edit and iterate on? I'm expecting a learning curve with any given program, i just don't even know if looking at, say, unity will have the tools want I know this is a far cry from where you're at in your development but I'm coming from a scripting and modding background so i don't know where I'd even begin with building this If you've answered this basic question previously just link me if you recall the video. Thanks for all you do, love the channel love your work

Any suggestions about how to better communicate with managers who are pressing us for time estimates that aren't really possible to determine? I hear you - it's their job to manage the resources - that's the world. But it's also just as simple a plain reality that there are so many factors that are out of our control that will affect that timing. I haven't worked in this kind of setting in a while, but when I did, I found myself really wanting to explain "I respect you're doing your job but you're asking me for answers I don't have yet - can I at the very least explain to you why I don't have those answers and have a back and forth?" But then they just get mad at US. So if we're expected to understand how reality works, shouldn't they? One time on a job I just full on walked out the door and left for the day. In retrospect, it's amazing I still had a job the next day. But I had a job the next day because they needed me - I had the technical expertise they needed. But I was just so sick of them putting time demands on me that were impossible. They didn't trust me or factor it into their plans when I explained the insanity of what they were asking for, and doing the impossible also wasn't an option, so I just panicked and walked out. I felt a lot like Geordie in those days. The producers were on the bridge negotiating and planning, but I was the one who made the ship run. I was the one who knew how to fix a warp core breach. And they made me feel like just another piece of equipment they paid for and owned, and they expected me to deliver what they paid for without any consideration for the strain that their expectations were putting on a human being. I really wanted to be a respectful team-player who acknowledged their vital role in the whole process, but it's so hard to do that when it feels so much like they aren't putting in the same effort.

Tim, you have a beautiful dog.

time estimations are not about time estimations, they are about pushing people to work harder (elon musk method)

Do you estimate for bug fixes as well? Do you reckon it’s even feasible - perhaps a risk/complexity based approach? I find that teams can learn to be great estimators, but in my 10 year career I have never encountered a dev who can/will estimate for bug fixing

@CainOnGames

Ай бұрын

We usually scheduled as much time as possible for the beta protection stage, which in theory should be a time for doing nothing but fixing bugs and balancing the game.

When it jumped into my feed I first read the title as "Tim Estimation" and was wondering if that's gonna be a new game development sciene term...

Ave, true to TimCain

Let me share my gaming time-related story I have. I was trying my luck in a video game industry and I saw an open position for a junior quest designer. I thought, what the hell, let's try. I submitted a CV a got a reply with a task I needed to finish. The task was to create a 30-minute long playable demo based on one of the stories in a provided corresponding table top RPG handbook. One main quest, side quest, from start to finish. UI, graphics, mechanics, characters, dialogue, everything. I've never touched any game creation tool in my life and I cannot code :D. I had 10 days to do this. So, after my 8.5h work day, once my kid and wife went to bed, I spent whole nights learning RPG Maker. Long story short, I got rejected (of course), but I was also kinda proud of my creation. Buggy, simple. But I stand behind my level design :). It was an interesting experience indeed.

@CainOnGames

Ай бұрын

The test for a junior quest designer was to make a 30 minute long playable demo?! That is not sane.

@decode.666

Ай бұрын

@@CainOnGames I apologize, made a mistake. It was an Intern Quest Designer :D At least one side quest. Focus on believable psychological interactions and non-linear decisions (reading straight from the task document). High technical quality and lack of bugs is required. Additional features will be a plus.

@CainOnGames

Ай бұрын

@@decode.666 An intern position??!! This gets worse and worse.

@decode.666

Ай бұрын

@@CainOnGames It was an experience indeed. I'm playing the demo I've made right now. Good memories :D

@InvalidationX145

Ай бұрын

@@decode.666 Sounds like you dodged a bullet there!

Now do one about Tim estimates

@CainOnGames

Ай бұрын

Keep your Tim estimates low. 😀

@cantthinkofanythingwitty

Ай бұрын

@@CainOnGames you just outed yourself as someone who pads their estimates 😎

The real time was the friends we made along the way.

How to estimate tasks... ...experience. There is no shortcut. You make that less painful with asking questions, making progress reports, and requesting feedback. Example from my life: Super: Fix the jet. What is the ETC? Technician (Me): 20 minutes-24 hours. Super WTF?! 20 minutes: 5 minutes to walk to jet, 5 minutes to hook up power, 5 minutes to check the system, 5 minutes to sign off the jet as no fault. 3 hours: All of the above. The main controller is bad. Order part, pickup part from supply, install part, check it, etc. 6 hours - everything from 3 hour job, but the first part out of supply was bad. The second one worked. 8 hours - parts aren't available, we have to cannibalize part from another jet. 12 hours multiple problems that we find after fixing the first issue. 24 hours, after we chased our tails for 3 shifts, we figure out it's actually a hydraulic problem, not an electronic controls issue. Super: Well which one is it? Me: I'll let you know which one it isn't in 30 minutes, then again at 3 hours, then 6, etc Every one of those scenarios was learned only after experiencing them.

@JavierBonnemaison

Ай бұрын

You are focusing on reducing uncertainty gradually, which is the right intuition. The fact that your range is so wide is a direct result of the current design of your work system (part availability, lead time for part ordering, problems that only surface after checking for another problem, knowledge handoff and skill differential between shifts, etc.). The supervisor should focus on fixing the range of variability in the system of work they are supposedly managing rather than WTFing you when you show that you know how things actually work.

@GeoFry3

Ай бұрын

@JavierBonnemaison never been in the military have you?

@JavierBonnemaison

Ай бұрын

@@GeoFry3 No, I have not.

@JavierBonnemaison

Ай бұрын

@GeoFry3 but if you ask because you think things cannot improve there, I suggest you read "Turn this ship around!" by David Marquet.

@GeoFry3

Ай бұрын

@JavierBonnemaison after 20 years in the Air Force, I know it can improve. Usually, after leadership pulls their head out of their asses and kicks the decision to the line troops and their NCOs.

Yeah there are issues with just counting lines of code. I had a project where I had to write 500 lines of pretty straight forward C. This took an afternoon to write and in another project I was spending several days to do 50 lines of OCaml lol :)

What should I do when my manager comes back with needed updates to a task but refuses to provide additional hours? So my options become: -Log it under admin time and then get punished for having a low utilization rate. -Work for free in my off hours. -Sacrifice PTO hours to the project so that my utilization rate remains decent. I don’t like either of those. I’ve let my manager know. He just tells me to duck off (politely). I usually pick the third choice. Is there any way to let the manager understand how terrible these situations are? Ideally I’d like to let him know in a diplomatic way so that I don’t have to look for another job asap.

@CainOnGames

Ай бұрын

I have tried all of your options before. I’ve also sent back the task with a note “hours not available. Please remove other tasks to free up time for this one”. Expect to be told you’re not a team player.

@Gulpathfinder

Ай бұрын

​@@CainOnGames Hi Tim. Really appreciate the reply. So it seems that there's no way to settle this diplomatically in a way that we can all be happy in the end. I also found out from a friend who used to be a project manager at the company that PMs get bonuses based on how few hours are used on projects. So the fewer hours they allocate to me to do more stuff, the more bonuses the PMs would get. I'm guessing they have significant influence on my manager and his manager. Sounds like the best solution is to look for a new job. Seems like a very inefficient way to manage people, as this would surely discourage the good folks from giving their full effort.

Estimates... - Estimates are by definition not 100% accurate. There should always be a margin for deviation from the estimate. - The more fine-grained the task breakdown, the more accurate estimates will generally be. - If the tasks to be estimated are too big and vague, your estimates become guestimates (and they're likely too small). - If you feel pressure from management to make your estimates smaller and smaller, your estimates become wishtimates (and you'll be very unlikely to ever make them). And that is true for the entire software development industry.

Time estimation can be very difficult. I agree with Tim when he says splitting the task into smaller tasks and iterate them can help. Since the smaller tasks take less time you can see what happens with them and re-estimate the remaining ones.

Hi everyone. It's me. Aegon Targaryen 1390

@aegontargaryen1390

Ай бұрын

Thanks for doing this video Tim :) I'm a SWE in the "web industry" and while my experience in terms of work process seems different from the game industry, I found the video insightful and helpful. I'll definitely keep in mind some of the things you said. One change I'll make is to stop using Speech as a dump stat.

Here's another danger of overestimating: you think that you have a lot of time to do an easy task and start slacking. Sometimes you slack so hard you still miss your extra generous estimate.

Or you know you could use continuous integration, and always keep the game in a stable state. Then before the funding dries out you take the latest stable version, run another round of QA testing on it, fix the most urgent issues, and release the game. \o/

DOG SPOTTED 5:50

Doge spotted!

By the way, something I've been thinking about. If you're spending money on a story based game, you can trade off: 1) depth: length of the average quest 2) breadth: number of side things you can do 3) branching: number of different paths you can take 4) concentration: amount of money / effort invested in each moment of the player's experience (e.g., motion capture for NPCs, spending a lot of effort on each line of dialogue, or making a lot of detailed and unique NPCs) Practically, I believe the cost scales with the product of these four parameters. Do you think this paradigm is accurate or does it miss the mark? If the former, how do you view the tradeoff between the things in order to build a great game (or more specifically, a game that you might find great)? Thank you!

@CainOnGames

Ай бұрын

There’s a pretty accurate model. For me personally, I like 2 and 3 the most, meaning give me lots to do and lots of ways to do it. Some people like 1 too. Everyone wants 4 (which could also be called quality), but I have found it to be very subjective. People have loved things in my games that were done cheaply and quickly (like Fallout’s opening narration) and disliked features that we spent a ton of time on.

This doesn't even account for changes to the spec mid-development 😅 Fun times

As an adhd person, I've learned to always overestaminate everything. If my brain says it takes an hour, better say 3. A week? How about week-and-a-half?

Use the Star Trek method

There was this one thing I liked to do when I was doing something I never did before, which would be to see if there are any days to spare where I could return to a simpler fallback feature even if those extra days were not used properly. And let's say that you find out that there's about a week to spare, in that week you can try to do the more complex/unknown feature you had planned, see how it progresses within that week and figure out an estimation from there. That way you can see if the more complex/unknown thing is viable to finish in a reasonable amount, and if it turns out that it'd take far too long, you can just discard it and work on the simpler fallback feature. Doing that lets you not have any regrets about what you could have done, and it gives you experience in being better at estimations, while of course this won't always work if your timeline is really tight, it is good to keep in mind for situations where you could do it.

I think you might have gone over your estimated time for the video.

Ok this has been really insightful. I have a tangentially related question: How can I better be aware of the "quality bar"? As an artist I have this issue in which I always think "this could be better", or "there's room for improvement", which has caused me to be late on tasks when there was actually no need to improve the artwork. How can you tell enough is enough when the concept of "good" and "bad" can be nuanced?

@CainOnGames

Ай бұрын

As a programmer, I have this machine that tells me nope, not good enough. It won’t compile. It’s too slow. It has bugs. As a designer, I had other designers saying nope, not good enough. It won’t work. It conflicts with design pillars. It’s hard to understand. I’m not sure the equivalent is for an artist. Other artists?

Hey Tim would you like to make a detailed video about the budgets? You almost always say its a money problem so I like to hear your take on that.

@CainOnGames

Ай бұрын

Hmm, it’s a good question, but I’ve never been asked to estimate a budget. I’ve always been given a budget (and a time frame and sometimes a team) and asked what I could make. I’ve talked about that in How To Pick The Right Project kzread.info/dash/bejne/ipt5sqizkdC4Zaw.html Is there something you want to know that I didn’t cover in that video?

@ozancobanoglu812

Ай бұрын

@@CainOnGames Sorry for the late reply I watched the video and there was almost none so no Tim thanks.

In any project, in any industry, there are just three things that vary: 1) Time 2) Budget 3) Scope You explained how over/under estimation of time, which developers are looking at will often affect budget and/or scope which the developers rarely realize are there. If anyone wants to learn how to reduce the amount of bias and corruption in projects, they should learn about Goldratt's CCPM. It is a method to manage projects in such a way that time is not wasted, even with corrupted estimations in place.

@gilgamecha

Ай бұрын

You forgot 4. Quality.

@kesor6

Ай бұрын

kzread.info/dash/bejne/aH14pJOzgZCyg7Q.html

@kesor6

Ай бұрын

PMI statistical report of 2017 indicates less than 70% of projects met their goal, less than 60% performed within their budget, and about 50% were completed on time (PMI, 2017). The same report of 2021 shows 73% of projects met their goal; however, the projects meeting budget were still less than 60%, and those finishing on-time 55% (PMI, 2021).

Tangentially related question: what are the strategies you've found to be effective when managing work collaboration between different functional groups within a game studio (eg design vs art vs programming) when communication breaks down, for instance due to reputational or political problems? A recent example: an "exposé" that came out from a former Creative Assembly lead AI programmer recently. It alleged that political favoritism on the part of the game director (and "leadership" more broadly), led to situations where the design team often "won" versus other functional groups on contentious topics/discussions. This was cited as a major contributor to the studio's inability to deliver on the game as promised. To be clear, I'm just using this specific example to ground the discussion, but I'm more interested in how *you* have experienced this in your career (or what you or others have done to avoid this), and how this type of problem can be solved in an organization.

I feel like another part of the issue with time estimation in any creative industry is that exploring new ideas sort of inherently makes for unpredictability. Given that, I wonder how this varies in other specializations of game dev aside from programming, like concept art or narrative design.

@CainOnGames

Ай бұрын

I know that concept artists are often asked to redo their work, because it's not quite what the leads wanted. Same thing for narrative design, audio, and even marketing. When part of your job is to explore a space of ideas, redoing work is part of the process. This is why I always say that R&D is so important.

Aegon Targaryen wanting to know about time estimations is pretty in character

oh man this is a sore subject.

Since time estimation is hard, that's why your programmers told you that the "simple testing module" took 4 weeks. Even after you showed them the idea, it's still only reduced to 2 weeks. When in reality it might be able to finish in just a few hours.

DOG

Sheesh get a load of the amateur that doesn't know what a 52 Is

I don't think I wanna hear about "time management" from a game dev lol we all know how bad devs, publishers, the entire game industry is with that. Obviously I'm joking...kind of.... actually not really, lol. Personally I have to deal with this issue everyday at work (different industry) in general I think most people procrastinate till the last second, unless they are babysat, and even then it's really difficult to get people to communicate, coordinate, & execute.