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
  • Game Developer Survey


    We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a $15 incentive for your time and insights. Click here to start!

    Take me to the survey!

  • Advertisement
  • Latest Featured Articles

  • Featured Blogs

  • Advertisement
  • Popular Now

  • Similar Content

    • By Tomato Head
      Hello everybody,
      I'm very interested in learning what is your process for discarding core game concepts that you've have come up with. Knowing that it is very hard to work on more that one development at once and plenty of people have more than one idea for games in their head, how do you discard or prioritize your concepts? Have many of you created prototypes and only then found the concept is not good? Have you found that there are core concepts that are bad and can never be iterated to get a playable/good game?
      Any advice is very much welcomed.
    • By Pepsidog
      I'm wanting to create a hybrid game between turn based and action.  I'm looking to create a system where the player has a list of attack or move options on their turn, but I want to add a skill minigame in order to make the game more engaging for non-strategists.  I figured some sort of minigame or something.  Any ideas are welcome.  Thanks in advance!
    • By EchoCell
      Hello folks! I’m looking for advice on which engine I should go with for a 2D game I want to make. The goal is to make a side-scrolling beat’em up/2D fighting game hybrid where the main levels are in beat’em up mode, but the boss battles are in 2D fighter mode. The combat controls (combos, special moves, etc) would be the same in both modes, and the game would include a tournament mode that is entirely in 2D fighter mode.
      I have minimal game developing experience, and am essentially a noob. I am mostly familiar with RPGMaker, but have also experimented lightly with Unity. I have zero programming knowledge, and thus am partial to engines more accessible to complete beginners.
      What engine(s) would be best suited to this kind of game? I am interested in both M.U.G.E.N and OpenBOR, but I don’t think either would allow the kind of genre-crossing I want to accomplish without significant programming skills that I don’t have.
      Also - and I realize I’m thinking too far ahead - I would like to be able to release this game via HTML5 and just host it online somewhere if possible. Otherwise I am okay with it being PC only.
      Thank you for your time and input!
    • By Velvet
      Hello everyone! I finally mustered the balls to come here and ask for your advice.
      To simply put it, my friend and I would like to emulate, or make a small private server of, this pretty old MMO.
      We've managed to obtain the database of said MMO, even though it's not the most recent version.
      The issue is.. both of us are what you'd call non-programmers, so we have no idea where we should start.
      Having the database we've used SQL Server to take a look at it, but that's as far as we go.
      He says we need somone who's familiar with c# & sql programming languages to help us set this up, skills that none of us have.
      All we want is to put a small server up and running so that the two of us and a couple other friends can play together, kind of like minecraft.
      We'd like to find people to help us set this up, or to at least guide us on what we have to do so we can hire some programmers.
      So I'd like to ask:
      Since we have the database and (I think) don't need reverse engineering, what are the next steps to make it work and have the server go live? What are the programms that we need to use for said steps? What kind of skills should we look for in the people we'd hire to set the server up? I'm sorry if this sounds halfassed but I really appreciate any advice you'd have to offer.
      Thank you in advance!
    • By JeremyAlessi
      In the 5th PixelCast, Jeremy shares some fond memories of Castlevania IV now that it's October and Halloween gaming is on. Jeremy also dives into the news and covers an issue that's been on his heart and mind lately; the increasing number of game developers who seem to be passing away in their 40's and 50's.

      View full story

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!