Jump to content
  • Advertisement
  • Remove ads and support GameDev.net for only $3. Learn more: The New GDNet+: No Ads!

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

    Setting Realistic Deadlines, Family, and Soup

    Production and Management

    LordYabo

    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":
    image.png
    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]
    [/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.
    debt.jpg
    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:
    never.jpg
    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:
    better.jpg
    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.
    Test_Tube_Baby2.jpg
    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?
    pp42_marriage_conflict.jpg
    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. :-)
    redball.jpg
    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
    Board-table.jpg
    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.
    1176429_orig.jpg
    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

    Jigsaw-Puzzle.png
    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

    Links:

    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

    Recipes:

    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.

     

    Also:

    "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.

     

    Ben

    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
  • Advertisement
  • Latest Featured Articles

  • Featured Blogs

  • Popular Now

  • Similar Content

    • By Shaarigan
      Hey,
      I'm currently starting next iteration on my engine project and have some points I'm completely fine with and some other points and/or code parts that need refactoring so this is a refactoring step before starting to add new features. As I want my code to be modular to have features optional installed for certain projects while others have to stay out of sight, I designed a framework that starting from a core component or module, spreads features to several project files that are merged together to a single project solution (in Visual Studio) by our tooling.
      This works great for some parts of the code, naming the Crypto or Input module for example but other parts seem to be at the wrong place and need to be moved. Some features are in the core component that may belong into an own module while I feel uncomfortable splitting those parts and determine what stays in core and what should get it's own module. An example is Math stuff. When using the framework to write a game (engine), I need access to algebra like Vector, Quaternion and Matrix objects but when writing some kind of match-making server, I wouldn't need it so put it into an own module with own directory, build script and package description or just stay in core and take the size and ammount of files as a treat in this case?
      What about naimng? When cleaning the folder structure I want to collect some files together that stay seperated currently. This files are foir example basic type definitions, utility macros and parts of my Reflection/RTTI/Meta system (which is intended to get ipartially t's own module as well because I just need it for editor code currently but supports conditional building to some kind of C# like attributes also).
      I already looked at several projects and they seem to don't care that much about that but growing the code means also grow breaking changes when refactoring in the future. So what are your suggestions/ oppinions to this topic? Do I overcomplicate things and overengeneer modularity or could it even be more modular? Where is the line between usefull and chaotic?
      Thanks in advance!
    • By PlanetExp
      I've been trying to organise a small-medium sized toy game project to supports macOS, iOS and Windows simultaneously in a clean way. But I always get stuck when I cross over to the target platform. I'll try to explain,
      I have organised my project in modules like so:
       
      1. core c++ engine, platform agnostic, has a public c++ api
      2. c api bindings for the c++ api, also platform agnostic, this is actually part of 1 because its such a small project
      3. target platform bindings, on iOS and macOS this is in swift. Basically wraps the c api
      4. target platform code. This part just calls the api. Also in swift.
       
      So in all I have 4 modules going simultaneously, all compiled into a separate static libraries and imported into the next phase/layer. Am I even remotely close to something functional? I seem to getting stuck somewhere between 2 and 3 when I cross over to the target platform. In theory I would just need to call the game loop, but I always end up writing some logic up there anyway.
       
    • By trapazza
      A few years ago I started creating a procedural planet engine/renderer for a game in Unity, which after a couple of years I had to stop developing due to lack of time. At the time i didn't know too much about shaders so I did everything on the CPU. Now that I have plenty of time and am more aware of what shaders can do I'd like to resume development with the GPU in mind.
      For the terrain mesh I'm using a cubed-sphere and chunked LODs. The way I calculate heights is rather complex since it's based on a noise tree, where leaf nodes would be noise generators like Simplex, Value, Sine, Voronoi, etc. and branch nodes would be filters and modifiers (FBM, abs, neg, sum, ridged, billow, blender, selectors, etc). To calculate the heights for a mesh you'd call void CalcHeights( Vector3[] meshVertices, out float[] heights ) on the noise's root node, somewhere in a Unity's script. This approach offers a lot of flexibility but also introduces a lot of load in the CPU. The first obvious thing to do would be (I guess) to move all generators to the GPU via compute shaders, then do the same for the rest of the filters. But, depending on the complexity of the noise tree, a single call to CalcHeights could potentially cause dozens of calls back and forth between the CPU and GPU, which I'm not sure it's a good thing.
      How should I go about this?
      Thanks.
       
       
    • By gdarchive
      Intro
      Due to my belief in learning through self-discovery and my ongoing creative evolution, I've long put off doing any tutorials. However, after making pixel art for over 3 years I've established many solid techniques worth laying out in a concrete fashion. While I'm excited by the prospect of helping others with my experience, I still urge artists to explore things their own way. The wonderful thing about art is the unlimited number of solutions to a problem. I offer you solutions that have worked for me and I hope they work for you, but I will be even more thrilled if you discover a better solution along the way.

       
      When it comes to pixel art, it all starts with a good color palette. Creating a custom color palette can be a very satisfying and powerful way to establish your own unique look. I'll guide you through my method as I create a new palette. But first, let's go over some basic principals.
       
      It's all about HSB
      I find it easiest to understand and control color through HSB.
      Hue - The actual color (0 - 360º)
      Saturation - The intensity or purity of a color (0 - 100%)
      Brightness - The amount of black or white mixed with a color (0 - 100%)
      By understanding and adjusting these 3 fundamental properties you can create custom colors with precise control. I recommend this article by Steven Bradley for more detailed definitions of HSB.
       
      Color Ramps
      A color ramp is a specific range of colors that work well together, arranged according to brightness. Here is an example of what I consider a good color ramp. 

       
      Brightness steadily increases from left to right in this example. As the colors reach high brightness levels it's important to decrease saturation, or you'll end up with intense eye burning colors. Also, colors with very low brightness can become overly rich and weighty with high saturation. Saturation peaks in the middle swatch in this example.  
      A good color ramp should also apply hue-shifting, which is a transition in hue across the color ramp. In the previous example the hue is shifting by positive degrees as the brightness increases. 
      Many beginners overlook hue-shifting and end up with 'straight ramps' that only transition brightness and saturation. There is no law that says you can't do this but the resulting colors will lack interest and be difficult to harmonize with ramps of a different hue. This only makes sense to me if you want a monochromatic look and stick to one straight ramp.
       
      The Palette
      A color ramp is essentially a palette, but most palettes contain multiple ramps. I like to create large palettes with lots of ramps, which I can then pull smaller palettes from per assignment. 
      Mondo  - 128 colors

      Become a Pixel Insider member and download Mondo
       
      I took the opportunity to make a brand new palette for this tutorial. My intention was to create a general purpose palette that strikes a balance between vibrant colors and desaturated natural colors. So, how to make such a large palette?
      First I decide how many swatches I want per ramp and how many degrees of hue shift. For this palette I want 9 swatches per ramp with 20 degrees of positive hue shift between each swatch. I like a lot of hue shift because it creates harmony between ramps and just looks neat, but 20 is about as high as I go.

      The color picker panel in Photoshop. We only need to be concerned with adjusting HSB.
       
      I use Photoshop, but a similar color picker panel should be accessible in just about any graphics software. To start I pick a color that will fit right in the the middle of a ramp. The hue is somewhat arbitrary, but the saturation and brightness is critical. I want the middle color to be be the most vibrant so I set the saturation and hue to the max combined number I'm willing to go.

       
      After I've chosen my first color I can set the hue for the remaining swatches based on the positive 20 degree shift I wanted. I could reverse the direction of hue shift if I want but positive hue shift usually results in more natural colors, warming as they become brighter. 
      I still need to sort out the increments for S&B. Unlike hue, shifting the S&B in uniform increments doesn't necessarily produce satisfactory results. However, there are a few tendencies I follow. Brightness consistently increases from left to right and usually never starts at 0, unless I want black. Saturation peaks around the middle and never fully goes to 100, or 0. The goal in mind is to create even contrast between each color.

       
      After some tuning and eyeballing these are my final values and resulting color ramp. The hue shift looks pretty strong but it will make sense when I add more ramps.

       
      This version shows the difference in the increments. Pay attention to what the S&B are doing. You can see there is some consistency in the pattern. The saturation takes larger steps on the ends and smaller steps in the middle where it's the highest percentage. The brightness takes smaller steps as it gets closer to the end at full 100%.

       
      Here's another visualization that clearly shows the flow of S&B as line graphs. You don't have to follow this general flow of S&B. It just depends what look you're going for. I've made ramps where the saturation continues to climb as the brightness decreases, creating an X pattern. This results in vivid dark colors. The biggest mistake is combining high saturation and brightness, unless you want to burn some eyeballs. I recommend a lot of experimentation with the HSB values of your ramp. I've tried to come up with mathematically precise formulas but it always seems to come down to trusting the eyeballs to some extent.  
      Now let's finish the palette.

       
      Up to this point all I have been doing is picking colors and drawing them as single pixel dots on a tiny canvas. I haven't actually added any swatches into the swatch panel. With the first ramp established all I have to do to create more ramps for my palette is shift the entire set of hues.
       

       
      I want 8 ramps total so I will shift the hues of each ramp by 45 degrees to complete the 360 degree cycle around the color wheel. I could do this in the color picker by adjusting the H value one color at a time, but In Photoshop I can save a lot of time by duplicating the ramp and changing the hue of the entire selection (Image-Adjustments-hue/saturation, or ⌘+U).

       
      After adjusting the hue of all my color ramps my palette appears like this. It looks pretty nice but It's lacking more neutral desaturated colors.

       
      To add desaturated colors I duplicate the whole middle section of the palette, omitting only the darkest and lightest colors on the ends, flip it over and desaturate them with the Hue/Saturation panel. I omit the light and dark columns because they appear nearly the same as the originals. I flip the colors because it makes for easy navigation, and it looks cool. The desaturated colors can provide a more natural look, and work well as grays in combination with the vibrant colors.

       
      The final task is actually adding the colors into the swatch panel. With the color picker panel open I sample each color with the eyedropper and click the 'Add to Swatches' button. I add them from left to right, top to bottom so they will appear in the swatch panel in the correct order. This is quite tedious but the only way I know of to add the colors in the particular order I want. 

       
      Once I've added all the colors into the swatch panel I click on the panel options and make sure to save my palette. I can then easily load the palette as a .aco file into the swatch panel anytime. Also, by selecting 'Save Swatches for Exchange' you can create a .ase file, which can be loaded into several other Adobe programs. Save the image of your palette as a .png file and you can load it into Aseprite.   
      Well, that completes my 128 color palette - Mondo. Now let's look at how I use the palette with some examples. 
       
      Picking Colors

       
      This example keeps it pretty simple, mostly relying on horizontal ramps of adjacent colors. You can also see how the warm desaturated colors work nicely with the vivid hues. I've added white into palette for extra contrast. 
       

       
      This example shows how ramps can move horizontally and diagonally. Because of the hue shift every color is surrounded by colors that can work together.
       

       
      Harmony is everywhere, just pick and play!
       

       
      This example uses complimentary color in combination with neutrals. The result captures an ominous yet hopeful feeling that perfectly fits the mood I wanted. 
      Picking colors for your art always requires some good sense, but a versatile palette with criss-crossing ramps like this makes it much easier. A little color goes a long way with pixel art, as you can see I never use a lot of colors for any one image.
      Creating a palette with this method also works great for game art, and will ensure everything in your game has consistent colors. I used this method to create a 160 color palette for Thyrian Defenders. We've been able to depict an incredible range of environments and characters while maintaining a consistent look overall. Other aesthetic choices come into play, but color is the fundamental ingredient that ties everything together.  
       
      Final Word
      Overall I'm quite happy with how this palette turned out. I think you'll be seeing more of my work in the Mondo palette from now on!
      I hope this helps you come up with some palettes of your own. I know It can take a bit of time to get a feel for HSB, but even if you're a beginner I think making palettes like this is a great way to understand color. Go crazy with HSB and don't be afraid to experiment with formulas that look different than my example. Also, you don't have to make such a large palette. Start with trying to make a small ramp.
       
      About The Author
      Raymond Schlitter (Slynyrd) is a former graphic designer who turned his creative passion to pixel art and game design in early 2015. Now he shares his knowledge with tutorials while he continues to make fantastic art and work on games. Support him on Patreon and get the inside scoop on his latest work.
       
      Note: This post was originally published on Raymond's blog, and is reproduced here with kind permission from the author.  If you enjoyed this article please consider supporting Raymond on Patreon, where he provides backers with exclusive downloads such the Mondo palette as .aco, .ase, and .png files. Get Mondo!  You can also make a one time donation to the author if you prefer not to subscribe on Patreon.
      [Wayback Machine Archive]
    • By chimchooree
      I'm mostly following AGILE, but it's the only software development methodology I know. Do we know what methodologies are used by the AAA guys like EA and Ubisoft? Which ones are popular among indie devs?
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!