Jump to content
  • Advertisement
  • 11/13/14 05:49 PM
    Sign in to follow this  

    Setting Realistic Deadlines, Family, and Soup

    Production and Management


    Jan. 23, 2015. This is my goal. My deadline. And I'm going to miss it. Let me explain. As I write this article, I am also making soup. Trust me, it all comes together at the end.

    Part I: Software Estimation 101

    I've been working on Archmage Rises full time for three months and part time about 5 months before that. In round numbers, I'm about 1,000 hours in. You see, I have been working without a specific deadline because of a little thing I know from business software called the "Cone of Uncertainty":
    In business software, the customer shares an idea (or "need")--and 10 out of 10 times, the next sentence is: "When will you be done, and how much will it cost?" Looking at the cone diagram, when is this estimate most accurate? When you are done! You know exactly how long it takes and how much it will actually cost when you finish the project. When do they want the estimate? At the beginning--when accuracy is nil! For this reason, I didn't set a deadline; anything I said would be wrong and misleading to all involved. Even when my wife repeatedly asked me. Even when the head of Alienware called me and asked, "When will it ship?" I focused on moving forward in the cone so I could be in a position to estimate a deadline with reasonable accuracy. In fact, I have built two prototypes which prove the concept and test certain mechanics. Then I moved into the core features of the game. Making a game is like building a sports car from a kit. ... but with no instructions ... and many parts you have to build yourself (!) I have spent the past months making critical pieces. As each is complete, I put it aside for final assembly at a later time. To any outside observer, it looks nothing like a car--just a bunch of random parts lying on the floor. Heck! To ME, it looks like a bunch of random parts on the floor. How will this ever be a road worthy car? Oh, hold on. Gotta check the soup. Okay, we're good. This week I finished a critical feature of my story editor/reader, and suddenly the heavens parted and I could see how all the pieces fit together! Now I'm in a place where I can estimate a deadline. But before I get into that, I need to clarify what deadline I'm talking about.

    Vertical Slice, M.V.P. & Scrum

    Making my first game (Catch the Monkey), I learned a lot of things developers should never do. In my research after that project, I learned how game-making is unique and different from business software (business software has to work correctly. Games have to work correctly and be fun) and requires a different approach. Getting to basics, a vertical slice is a short, complete experience of the game. Imagine you are making Super Mario Bros. You build the very first level (World 1-1) with complete mechanics, power-ups, art, music, sound effects, and juice (polish). If this isn't fun, if the mechanics don't work, then you are wasting your time building the rest of the game. The book Lean Startup has also greatly influenced my thinking on game development. In it, the author argues to fail quickly, pivot, and then move in a better direction. The mechanism to fail quickly is to build the Minimum Valuable Product (MVP). Think of web services like HootSuite, Salesforce, or Amazon. Rather than build the "whole experience," you build the absolute bare minimum that can function so that you can test it out on real customers and see if there is any traction to this business idea. I see the Vertical Slice and MVP as interchangeable labels to the same idea.
    [/media] A fantastic summary of Scrum.
    Finally, Scrum is the iterative incremental software development methodology I think works best for games (I'm quite familiar with the many alternatives). Work is estimated in User Stories and (in the pure form) estimated in Story Points. By abstracting the estimates, the cone of uncertainty is built in. I like that. It also says when you build something, you build it complete and always leave the game able to run. Meaning, you don't mostly get a feature working and then move on to another task; you make it 100% rock solid: built, tested, bug fixed. You do this because it eliminates Technical Debt.
    What's technical debt? Well like real debt, it is something you have to pay later. So if the story engine has several bugs in it but I leave them to fix "later," that is technical debt I have to pay at some point. People who get things to 90% and then move on to the next feature create tons of technical debt in the project. This seriously undermines the ability to complete the project because the amount of technical debt is completely unknown and likely to hamper forward progress. I have experienced this personally on my projects. I have heard this is a key contributor to "crunch" in the game industry. Hold on: Gotta go put onions and peppers in the soup now. A second and very important reason to never accrue technical debt is it completely undermines your ability to estimate. Let's say you are making the Super Mario Bros. World 1-1 vertical slice. Putting aside knowing if your game is fun or not, the real value of completing the slice is the ability to effectively estimate the total effort and cost of the project (with reasonable accuracy). So let's say World 1-1 took 100 hours to complete across the programmer, designer, and artist with a cost of $1,000. Well, if the game design called for 30 levels, you have a fact-based approach to accurate estimating: It will take 3,000 hours and $30,000. But the reverse is also helpful. Let's say you only have $20,000. Well right off the bat you know you can only make 20 levels. See how handy this is?!? Still, you can throw it all out the window when you allow technical debt. Let me illustrate: Let's say the artist didn't do complete work. Some corners were cut and treated as "just a prototype," so only 80% effort was expended. Let's say the programmer left some bugs and hard-coded a section just to work for the slice. Call it a 75% effort of the real total. Well, now your estimates will be way off. The more iterations (levels) and scale (employees) you multiply by your vertical slice cost, the worse off you are. This is a sure-fire way to doom your project.

    So when will you be done?

    So bringing this back to Archmage Rises, I now have built enough of the core features to be able to estimate the rest of the work to complete the MVP vertical slice. It is crucial that I get the slice right and know my effort/costs so that I can see what it will take to finish the whole game. I set up the seven remaining sprints into my handy dandy SCRUM tool Axosoft, and this is what I got:
    That wasn't very encouraging. :-) One of the reasons is because as I have ideas, or interact with fans on Facebook or the forums, I write user stories in Axosoft so I don't forget them. This means the number of user stories has grown since I began tracking the project in August. It's been growing faster than I have been completing them. So the software is telling the truth: Based on your past performance, you will never finish this project. I went in and moved all the "ideas" out of the actual scheduled sprints with concrete work tasks, and this is what I got:
    January 23, 2015 This is when the vertical slice is estimated to be complete. I am just about to tell you why it's still wrong, but first I have to add cream and milk to the soup. Ok! Now that it's happily simmering away, I can get to the second part.

    Part II: Scheduling the Indie Life

    I am 38 and have been married to a beautiful woman for 15 years. Over these years, my wife has heard ad nauseam that I want to make video games. When she married me, I was making pretty good coin leading software projects for large e-commerce companies in Toronto. I then went off on my own. We had some very lean years as I built up my mobile software business. We can't naturally have kids, so we made a "Frankenbaby" in a lab. My wife gave birth to our daughter Claire. That was two years ago.
    My wife is a professional and also works. We make roughly the same income. So around February of this year, I went to her and said, "This Archmage thing might have legs, and I'd like to quit my job and work on it full time." My plan was to live off her--a 50% drop in household income. Oh and on top of that, I'd also like to spend thousands upon thousands of dollars on art, music, tools, -- and any games that catch my fancy on Steam. It was a sweetheart offer, don't you think? I don't know what it is like to be the recipient of an amazing opportunity like this, but I think her choking and gasping for air kind of said it all. :-) After thought and prayer, she said, "I want you to pursue your dream. I want you to build Archmage Rises." Now I write this because I have three game devs in my immediate circle--each of which are currently working from home and living off their spouse's income. Developers have written me asking how they can talk with their spouse about this kind of major life transition.

    Lesson 1: Get "Buy In," not Agreement

    A friend's wife doesn't really want him to make video games. She loves him, so when they had that air-gasping indie game sit down conversation she said, "Okay"--but she's really not on board. How do you think it will go when he needs some money for the game? Or when he's working hard on it and she feels neglected? Or when he originally said the game will take X months but now says it will take X * 2 months to complete?
    Yep! Fights. See, by not "fighting it out" initially, by one side just caving, what really happened was that one of them said, "I'd rather fight about this later than now." Well, later is going to come. Over and over again. Until the core issue is resolved. I and my friend believe marriage is committed partnership for life. We're in it through thick and thin, no matter how stupid or crazy it gets. It's not roommates sharing an Internet bill; this is a life together. So they both have to be on the same page because the marriage is more important than any game. Things break down and go horribly wrong when the game/dream is put before the marriage. This means if she is really against it deep down, he has to be willing to walk away from the game. And he is, for her. One thing I got right off the bat is my wife is 100% partnered with me in Archmage Rises. Whether it succeeds or fails, there are no fights or "I told you so"s along the way.

    Lesson 2: Do Your Part

    So why am I making soup? Because my wife is out there working, and I'm at home. Understandably so, I have taken on more of the domestic duties. That's how I show her I love her and appreciate her support. I didn't "sell" domestic duties in order to get her buy-in; it is a natural response. So with me working downstairs, I can make soup for dinner tonight, load and unload the dishwasher, watch Claire, and generally reduce the household burden on her as she takes on the bread-winning role. If I shirk household duties and focus solely on the game (and the game flops!), boy oh boy is there hell to pay. Gotta check that soup. Yep, we're good.

    Lesson 3: Do What You Say

    Claire is two. She loves to play ball with me. It's a weird game with a red nerf soccer ball where the rules keep changing from catching, to kicking, to avoiding the ball. It's basically Calvin ball. :-)
    She will come running up to my desk, pull my hand off the mouse, and say, "Play ball?!" Sometimes I'm right in the middle of tracking down a bug, but at other times I'm not that intensely involved in the task. The solution is to either play ball right now (I've timed it with a stopwatch; it only holds her interest for about seven minutes) or promise her to play it later. Either way, I'm playing ball with Claire. And this is important because to be a crappy dad and have a great game just doesn't look like success to me. To be a great dad with a crappy game? Ya, I'm more than pleased with that. Now Claire being two, she doesn't have a real grasp of time. She wants to go for a walk "outside" at midnight, and she wants to see the moon in the middle of the afternoon. So when I promise to play ball with her "later," there is close to a 0% chance of her remembering or even knowing when later is. But who is responsible in this scenario for remembering my promise? Me. So when I am able, say in between bugs or end of the work day, I'll go find her and we'll play ball. She may be too young to notice I'm keeping my promises, but when she does begin to notice I won't have to change my behavior. She'll know dad is trustworthy.

    Lesson 4: Keep the Family in the Loop like a Board of Directors

    If my family truly is partnered with me in making this game, then I have to understand what it is like from their perspective:
    1. They can't see it
    2. They can't play it
    3. They can't help with it
    4. They don't know how games are even made
    5. They have no idea if what I am making is good, bad, or both
    They are totally in the dark. Now, what is a common reaction to the unknown? Fear. We generally fear what we do not understand. So I need to understand that my wife secretly fears what I'm working on won't be successful, that I'm wasting my time. She has no way to judge this unless I tell her. So I keep her up to date with the ebb and flow of what is going on. Good or bad. And because I tell her the bad, she can trust me when I tell her the good. A major turning point was the recent partnership with Alienware. My wife can't evaluate my game design, but if a huge company like Alienware thinks what I'm doing is good, that third party perspective goes a long way with her. She has moved from cautious to confident. The Alienware thing was a miracle out of the blue, but that doesn't mean you can't get a third party perspective on your game (a journalist?) and share it with your significant other.

    Lesson 5: Life happens. Put It in the Schedule.

    I've been scheduling software developers for 20 years. I no longer program in HTML3, but I still make schedules--even if it is just for me. Customers (or publishers) want their projects on the date you set. Well, actually, they want it sooner--but let's assume you've won that battle and set a reasonable date. If there is one thing I have learned in scheduling large team projects, it is that unknown life things happen. The only way to handle that is to put something in the schedule for it. At my mobile company, we use a rule of 5.5-hour days. That means a 40-hour-a-week employee does 27.5 hours a week of active project time; the rest is lunch, doctor appointments, meetings, phone calls with the wife, renewing their mortgage, etc. Over a 7-8 month project, there is enough buffer built in there to handle the unexpected kid sick, sudden funeral, etc. Also, plug in statutory holidays, one sick day a month, and any vacation time. You'll never regret including it; you'll always regret not including it. That's great for work, but it doesn't work for the indie at home.
    To really dig into the reasons why would be another article, so I'll just jump to the conclusion:
    1. Some days, you get stuck making soup. :-)
    2. Being at home and dealing with kids ranges from playing ball (short) to trips to the emergency room (long)
    3. Being at home makes you the "go to" family member for whatever crops up. "Oh, we need someone to be home for the furnace guy to do maintenance." Guess who writes blogs and just lost an hour of his day watching the furnace guy?
    4. There are many, many hats to wear when you're an indie. From art direction for contract artists to keeping everyone organized, there is a constant stream of stuff outside of your core discipline you'll just have to do to keep the game moving forward.
    5. Social media marketing may be free, but writing articles and responding to forum and Facebook posts takes a lot of time. More importantly, it takes a lot of energy.
    After three months, I have not been able to come up with a good rule of thumb for how much programming work I can get done in a week. I've been tracking it quite precisely for the last three weeks, and it has varied widely. My goal is to hit six hours of programming in an 8-12 hour day.

    Putting This All Together

    Oh, man! This butternut squash soup is AMAZING! I'm not much of a soup guy, and this is only my second attempt at it--but this is hands-down the best soup I've ever had at home or in a restaurant! See the endnotes for the recipe--because you aren't truly indie unless you are making a game while making soup! So in order to try and hit my January 23rd deadline, I need to get more programming done. One way to achieve this is to stop writing weekly dev blogs and switch to a monthly format. It's ironic that writing fewer blogs makes it look like less progress is being made, but it's the exact opposite! I hope to gain back 10 hours a week by moving to a monthly format. I'll still keep updating the Facebook page regularly. Because, well, it's addictive. :-) So along the lines of Life Happens, it is about to happen to me. Again. We were so impressed with Child 1.0 we decided to make another. Baby Avery is scheduled to come by C-section one week from today. How does this affect my January 23rd deadline? Well, a lot.
    • Will baby be healthy?
    • Will mom have complications?
    • How will a newborn disrupt the disposition or sleeping schedule of a two-year-old?
    These are all things I just don't know. I'm at the front end of the cone of uncertainty again. :-) SDG


    Agile Game Development with Scrum - great book on hows and whys of Scrum for game dev. Only about the first half is applicable to small indies. Axosoft SCRUM tool - Free for single developers; contact support to get a free account (it's not advertised) You can follow the game I'm working on, Archmage Rises, by joining the newsletter and Facebook page. You can tweet me @LordYabo


    Indie Game Developer's Butternut Squash Soup (about 50 minutes; approximately 130 calories per 250ml/cup serving)
    soup.jpg Dammit Jim I'm a programmer not a food photographer!
    I created this recipe as part of a challenge to my wife that I could make a better squash soup than the one she ordered in the restaurant. She agrees, this is better! It is my mashup of three recipes I found on the internet.
    • 2 butternut squash (about 3.5 pounds), seeded and quartered
    • 4 cups chicken or vegetable broth
    • 1 tablespoon minced fresh ginger (about 50g)
    • 1/4 teaspoon nutmeg
    • 1 yellow onion diced
    • Half a red pepper diced (or whole if you like more kick to your soup)
    • 1 tablespoon kosher salt
    • 1 teaspoon black pepper
    • 1/3 cup honey
    • 1 cup whipping cream
    • 1 cup milk
    Peel squash, seed, and cut into small cubes. Put in a large pot with broth on a low boil for about 30 minutes. Add red pepper, onion, honey, ginger, nutmeg, salt, pepper. Place over medium heat and bring to a simmer for approximately 6 minutes. Using a stick blender, puree the mixture until smooth. Stir in whipping cream and milk. Simmer 5 more minutes. Serve with a dollop of sour cream in the middle and sprinkling of sourdough croutons.

      Report Article
    Sign in to follow this  

    User Feedback

    As a senior business dev with a fiance, I can relate to this 100%. Although I don't have the stones to swap over to game development.

    Share this comment

    Link to comment
    Share on other sites

    So... quick question regarding prototypes and scrum:
    With scrum, you're supposed to build something "shippable" and each task needs to be 100% complete, yet a prototype or "vertical slice" is just a rough sketch of what needs to be built, so how do you use scrum to build a rough draft version to test out a particular game mechanic / game system?


    In my project, I've been writing about 85% complete code and focusing entirely on "just get it done", which causes some refactoring when my initial architectural implementation was incompatible. The intent is to build the game prototype to be an accurate representation of how the final product should work / behave, and when it comes time to build the final product, it's mostly a matter of porting most of the established systems over to a commercial game engine. Should I be aiming for 100% complete code? How do I know when its 100% complete if the next task may require it to change?

    Share this comment

    Link to comment
    Share on other sites

    I have to say you are quite lucky to have friends who are game devs. My main problem with going forward with any project is that, at some point, i just lose momentum :(


    Best of luck with both your game and Child 2.0 ;)

    Share this comment

    Link to comment
    Share on other sites

    This Article.

    ...though I don't agree with your opinion on 'technical debt';

    in my experience leaving chunks of sorta-broken, hard-coded, badly implemented functionality can help you fail faster.

    If i had a dollar for every "system" I worked to perfection, only to have it "cut" later, I could afford an artist ;)

    Given the cone of uncertainty you ideally want an inverse cone of 'gilding the lilly'.

    So you are spending the most critical time, on the most defenite stuff.

    ...another key here is using technology/methods that allow you to develop in this haphazard modular manner; some examples being:

    • dependency injection
    • obeying Law of Demeter
    • using 'soft' serialization/data formats: human readable, hand editable, non-sequental
    • anonymous objects, implicit interfaces (duck typing)

    Share this comment

    Link to comment
    Share on other sites

    I was just chatting with EDI, saying tech debt is a major problem in linux, php, wordpress, web browsers. Then I read the article. Gotta agree with him in this context. You can evaluate mechanics (and mood to some extent) without a full vertical slice. If it's going to be fun with polished graphics and everything, it WILL be fun with blocky graphics, borrowed music, and sketchy code.


    As for estimating, I think of it as an arbitrary constraint to keep cost and scope in check. Pick a number, double it, adjust features/quality/deadlines if you still can't make it. If you don't have tech debt you can't compromise on features or quality. I've never seen that on a business project but perfectionism kills a lot of 'labor of love' projects.

    Share this comment

    Link to comment
    Share on other sites

    Great article. I'm so glad you've mentioned MVP and Vertical Slice (now I don't have anything to say!)

    Share this comment

    Link to comment
    Share on other sites

    Very nice article sir. It's nice to see real wisdom spelled out every so often, and I'm truly happy for you.  I'm blessed enough to be in a similar situation with a supportive wife and a decent chunk of time to dedicate towards game development. 


    Congratulations on the progress you've made so far. I can't wait to get to that point where my collection of parts starts coming together.


    I wish you the best with Child 2.0's health, balancing being a good father/husband, and still somehow making progress on your game with a newborn in the house.

    Share this comment

    Link to comment
    Share on other sites

    Thank you for this great article.


    Your thoughts on technical debt pretty much reflect the lousy situation that i'm experiencing right now.

    The project itself has deadlines from hell. This is because the executives want to satisfy the customer

    with no regard for anything. In such situations you are always working on the limit especially if the team

    isn't that large. So you are making compromises on tasks that will lead to shippable software (hopefully)

    with a total mess under the hood.


    So here is the bad news:

    You know that the software is badly written at several points but the next features need to get implemented

    to satisfy the customer "one more time". Hence you can't do anything about the critical state of the software.

    Instead you're building something on top of an unstable construct - what could go wrong :-/

    After several iterations of this process you will come to a point where you can't implement anything without

    breaking the whole thing at another part you weren't aware of.


    The amount of time that is needed to "repair" this huge clusterfuck your project has become could be

    pretty huge. In some situations you are better off hitting the delete button and throw it all directly into the

    trash bin. 

    But if one decides to tackle the task and do a massive refactoring you are loosing time. For sure the customer won't understand why you are not able to put all his requested features into the next version anymore.

    Consequently there is a chance you are loosing the customer in the worst case.



    Conclusion (based on my personal experience):

    Never let the technical debt exceed a specific limit (depends on the size of the project, team size and several

    other factors). Otherwise you will pay the price - and it will be expensive!



    I would love to read more articles from you :)

    Until then i wish you all the best with your project and your family.

    Share this comment

    Link to comment
    Share on other sites

    "And this is important, because to be a crappy dad and have a great game just doesn't look like success to me. To be a great dad with a crappy game? Ya, I'm more than pleased with that."


    I can get behind that...

    Share this comment

    Link to comment
    Share on other sites

    Just wanted to chip in with a compliment, this is one of the best article I've read this whole year, both from a conceptual standpoint AND a technical one.


    Very Good.



    "And this is important, because to be a crappy dad and have a great game just doesn't look like success to me. To be a great dad with a crappy game? Ya, I'm more than pleased with that."


    Best Quote ever, wish you the BEST for all your endeavours.

    Share this comment

    Link to comment
    Share on other sites

    Great article!


    I can relate to everything you've said there (Also being a 38 year old developer, who has been writing games (Although only as a hobby) for about 24 years). 


    I wish you all the luck in the world. I also wish I had the balls to do what you've done.



    Share this comment

    Link to comment
    Share on other sites

    Great article! I'm just leaving my job to start working at my own developing games. Probably similiar situation but in smaller scale, because in fact I don't have much experience and this will be small experiment. And of course rest from crappy, dull and boring work at corporation. My wife will be working and I'll be "housewife" so I'll probably check this recipe. Thanks!

    Share this comment

    Link to comment
    Share on other sites

    Thank you for this article. I would like to eventually quit my full time job to pursue indie game dev. I have a plan and a due date. I need to definitely bring my wife on board as I am the sole bread winner at the moment. It is encouraging to hear your approach on this. I agree with family first though I pine often to make "making games" my job.


    Thanks again!

    Share this comment

    Link to comment
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!