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

  • 05/18/13 12:19 AM

    Making it in Indie Games: Starter Guide

    Career Development


    Every now and then someone will ask me for advice on making it as a professional indie game developer. First, it's a huge honor to be asked that. So I want to say "Thank you!" Second... damn, if I really want to help out it's a serious endeavor. Of course, I could always say "Give it your best! Work hard! Be true to yourself!" and it wouldn't be a terrible reply... just not a terribly useful one, either.

    So here it is. Here is what I'm going to link when that rare situation arises again, because it's too much work to write it up more than once! This is advice that I feel may actually be practical to someone who is just starting out as an indie game developer. Hope it helps!


    So yeah, what does being "indie" even mean? Is "indie" short for independent? Is this game "indie"? Is "indie" a genre? IT'S CONFUSING - WHY DO WE NEED THE WORD "INDIE" AT ALL.

    To answer the last question, I offer the following scenarios. Scenario 1: a person is looking to make games, and perhaps start their own studio. They type "game development" into a search engine. The results, to say the least, are underwhelming. Dry. Academic. Programming-centric. (Try it yourself and see.)

    Scenario 2: the person instead types "indie games" into a search engine. Instead of pages upon pages of conferences, bachelor's degrees, and programming tools, that person is met instead with pages upon pages of games to play and vibrant communities filled with people who are doing exactly what he or she wants to be doing. Some of them went to school, but many did not. A wealth of different ideas and tools are used. There are even documentaries about making games! It's not just something where you get a degree and wait in line for a job. You can start making games RIGHT NOW.

    The word "indie" is more than just a way to describe a type of developmental process... like any label, it actually provides an avenue for people to explore that process and then flourish within it. It has a real purpose. It serves real lessons on game creation and entrepreneurialism. It offers real motivation!

    Of course, it can be irritating to see the term misused, or become a vehicle for pretentiousness and arrogance. Like any label, "indie" also breeds a certain amount dogmatism, croneyism, and other -isms. But the net result is really worth something. As someone who once gave up on professional game-making because I thought it meant a 9-to-5, I can tell you that it's genuinely valuable.

    As for what games are "truly" indie, we'll never fully agree, and that's probably for the best. But I can tell you the criteria I've devised for The Independent Gaming Source to determine whether a game is fit for coverage:

    1. "Independent", as in no publisher.

    2. Small studio (roughly 20 members or less).

    I choose that definition because it's the most useful one. Someone who is looking to become an "indie" game developer is interested in what is possible under those constraints and how those types of studios operate. It excludes companies like Valve and Double Fine, which are certainly independent but too large to be "indie". It also excludes "feels indie"-type games that are not self-published.

    Under that definition you still run into gray areas, but hey, just because we don't know when "red" turns into "purple" doesn't mean the words aren't useful. Just think about someone who wants to make a game with a small team and self-publish it... what should they type into Google for inspiration, advice, community, etc.? "Indie" is still as good a word as any, in my opinion.

    So, should I go to school to learn how to make games?

    The most important thing to know about video game development and schooling is that no one, whether it's an indie studio or big company, cares about degrees. How could it, when some of its most prominent members are drop-outs or never-beens? John Carmack, Cliff Bleszinski, Jonathan Blow, and Team Meat are all prominent members of this club.

    A degree is a piece of paper that says you can do something in theory - game developers want to know that you have enough passion to do real work, regardless of whether you're being graded on it. And if you're thinking of going indie, it won't matter what other people think - you'll simply need that passion to succeed or else you won't. You're the only one holding the door open in that case.

    This isn't to dissuade you from going to college, per se (I studied computer science in college, and while it was far from a perfect experience, I also gained a lot from both the curriculum and the friends I made there). The point is make something - games, mods, art, and music. If school helps you with that, great. If it doesn't, then you need to rethink how you're spending your most valuable resources: time and money (both of which can be exorbitant costs for schooling).

    If I go to school, what should I study?

    At a regular university, I would suggest majoring in computer science, even if you "just want to be a designer". The design of games is very much tied to how they are made.

    At an art school, illustration, concept art, and 3d modeling courses are probably the most useful for games.

    At a game school, they will hopefully try to involve you in all aspects of game creation, from programming to design. I would stay far away from design-only schools or curricula - those are either scams or are better suited to academia than actual game-making. Also, it's worth finding out whether or not the school owns what you make while you're a student there.

    See also: Jonathan Blow - How to Program Independent Games (read the comments as well as watch the video)

    Okay, you say make something. How do I start?

    My best advice for those starting out is not to get ahead of themselves. It's easy to start worrying about tools, teams, platforms, deals, marketing, awards, and whatever else before you've even gotten a sprite moving around the screen. Those stars in your eyes will blind you. They'll freeze you up. You need to be actively making games all the time.

    If we were talking about painting, I'd tell you to pick up a painting kit and a sketchpad at your local art store ASAP and just have at it. You'd proceed to put absolute crap down on the pad and get frustrated. But it'd also be kind of fun - so you'd keep doing it. Along the way you'd read some theory and study other people's work. With good taste and under a critical eye, you would keep doing that until the day you painted something good.

    We're talking about games, though. I recommend Game Maker and Unity as two all-purpose game-making suites. They both have a good balance of power versus ease-of-use; they're both affordable or have free demos, and they both have a wealth of tutorials and plug-ins online. Both are used by professional developers (Unity in particular). Grab one of those and start running through the tutorials. When you run into trouble, ask for help. Give help back when you begin figuring things out. Get active in a game-making community.

    But above all else, keep making games. It's the only way to truly answer all of those questions in your head right now.

    Also, watch this:



    1. Finish your games.

    2. Don't skimp on artwork. It's easy to underestimate the importance of artwork to a game. And even if you don't, it's easy to underestimate the importance of having a unique style of artwork. The result is that there are many ugly or generic-looking (i.e. "clip-arty") games failing to capture people's attention.

    If you have no artistic talent, go for style and coherency as many successful indie developers do. And even ugly is probably better than generic, all told. Remember: this is most people's first impression of your game.

    3. Don't blame marketing (too much). In the indie community it's become popular to write "how I failed" articles where the screenshots and comments tell the story of an ugly, boring game and yet the article itself tells the story of bad marketing decisions. Let's face it, no one wants to admit that they lacked any amount of creativity, vision, or talent. It's much easier to put the blame on release dates, trailers, websites, and whatever else.

    This is the internet, though. A good game will make its way out there. Marketing will certainly help, and hype may get you quite far in the short term, but it's not going to make or break you - it's only a multiplier of however good your game is. Saying otherwise is only hurting your ability to self-criticize and therefore improve your craft. It's also encouraging others to do the same.

    4. Indie is not a genre or aesthetic. Make the game you want to make, not what you think an indie game "should be". Recently, the very small and very independent team behind The Legend of Grimrock announced that their very traditional first-person dungeon crawler sold over 600,000 copies. Don't feel pressured to be dishonest about what you'd like to do - after all, what is independence if not freedom from such pressures?

    5. Build yourself a working environment that's healthy for you. Are you introverted and lose energy around other people or are you extroverted and gain energy that way? Or something in-between? What do you want your average working day to be like?

    You'll want to focus all of the energy available to you toward creating, and it's amazing how much of it can be lost to seemingly mundane things. Figuring out your physical working space as well as your personal support system is a key part of the solution to this problem, and its vitally important to you as an independent creator.

    6. Stay independent! To be sure, going indie can be daunting. There is always going to be the temptation of selling yourself or your ideas to someone else for a bit of a feeling of security. But honestly, once you go down that road it's hard to come back - every moment you're simply securing may not be a moment you're progressing. I'm not recommending recklessness, but it's important to stay committed and focused on the task at hand. Life is short.

    Also, don't give up your IP or in any way limit your opportunities long term. Keep exclusivity timed. When Aquaria released we weren't aware of Steam. The Humble Bundle did not yet exist. iPad did not exist. Being on all of those platforms has been great for us. You need to keep your hands untied to take advantage of what future will bring.

    7. Create your own luck. As an artist, I owe a lot to the people around me - my family, friends, peers, and idols. I accept that a lot of my success was simply the luck of being born with these people in my life.

    But it's important to realize that you create many of your own opportunities, too. For example, I met Alec (my friend and Aquaria co-creator) because he offered to help work on I'm O.K. I'm O.K. was a game started on the Pix Fu forums. The Pix Fu forums were part of my personal website and its members were friends of mine I'd made much earlier during my Blackeye Software/Klik n' Play days.

    You could trace a similar path from the XBLA version of Spelunky to the original PC version and the TIGSource forums.

    The point is - put yourself out there. Make things (I can't stress that enough!). You never know when serendipity will strike, but when it does it will likely be related to situations in your past when you chose to actively engage someone or some idea.

    8. Avoid "business as war". As a professional you'll need to do business and make business-related decisions at least occasionally, and as a creative type you might not be that interested in that stuff. Hell, you might even be downright scared of it.

    Well, I'm here to tell you that you don't have to be Gordon Gekko to make it as an indie. And please, don't try to be. In fact, avoid the Gordon Gekkos. Avoid the people who try to confuse you. Avoid the ones who try and nitpick. Avoid the ones who try and rush you.

    If you have a great game, there is no distributor you will absolutely have to work with, platform you have to be on, or person you will have to team up with. Always be willing to walk away from a bad deal, especially if it's to maintain your independence as a creator. In turn, be a direct and generous person yourself.

    People get defensive when they're scared. Don't sit at the table with someone like that or as someone like that and doing business should be fairly pleasant! This isn't Wall Street!

    9. No gimmicks. Simply put, focus on making a good game - a deep, interesting, unique game - rather than devising cheap tricks to grab people's attention. Whether we're talking about clever-sounding-but-ultimately-shallow game systems or off-the-wall marketing ideas, a gimmick is a gimmick. And you should stay away from them because they're short-term, high-risk solutions that ultimately cheapen you as an artist, perhaps literally as well as metaphorically.

    Certainly, one should take risks in game design as well as in life. My point is that they should be honest, worthwhile ones - those tend to be less risky in the long run.

    10. You are your game - understand and develop yourself. As an indie game developer your game will likely be more "you" than a game made by hundreds or thousands of people. You have to understand yourself quite well in order to make a truly successful game. Fortunately, the unraveling of what makes you "you" - your taste, what you care about, your abilities - is one of the great pleasures in life and goes hand in hand with your goal of being an independent creator. Treasure it!

    Reprinted with permission from Derek's blog

      Report Article

    User Feedback

    This is a great article. The points you are getting across are on the spot. This was really a very good read.

    Share this comment

    Link to comment
    Share on other sites

    Well written and incredibly informative. I enjoyed every sentence of this article and I thank you for writing it. You had some really motivational points and I will keep them in the back of my head when I develop new games, thanks! 

    Share this comment

    Link to comment
    Share on other sites

    Please stop saying that an Indie developer is a 20 person company or group.
    You hurt the indie field when you tell people that Indie = 20 or somthing.
    Why, Thats what the MEGA Corps like Google want you to say. THEY WANT CONFUSION ON THE ISSUE, It's easier for
    them to take control of a nich market when it's weakend by confusion. It actualy delivers it to them.

    Look Google is just one MEGA, there are others, So I'm just using it as an example.
    They dont want INDIE=FREE They want = FREE.INDIE;

    #*************** PUSEDO CODE, Google is just an example here, Use your own MEGA if you wish.

    TRUE = (INDIE = 1);
    (If INDIE > 1 Then INDIE == FALSE);
    Set Google.Resource = All.Internet.SEARCH;
    Set Google.Resource = _most.All.Internet.MEDIA;
    # Run program
    Set CONST Google = MEGA;
    Set.Public.Memory = ONLY.GOOGLE;
    Set.Public.Memory.POOL = ONLY.GOOGLE.SAFE;
    Get INDIE.Developer;
            While (INDIE.Developer==FREE)
                    IF  INDIE.Developer == 1      ;        
                       Set Google.Resource = INDIE.Developer;
                       Delete INDIE.Developer FROM Public.Memory;


    Even there staff is condition to speak in forums against replies like mine.      
    I'm sorry, but the term Indie Developer is shorthand for "Individule Developer"
    The term Individule Developer, is first person singular.

    Otherwise, ok article, but it hurt the Indie market yet once again. It hurts Freedom, It hurts the next Niche market, They
    will also destroy it, stealing freedoms and replacing them with a Shrink Wrapped Click that destroy dreams of freedom


    Share this comment

    Link to comment
    Share on other sites
    6 hours ago, Allen Bipster said:

    the term Indie Developer is shorthand for "Individule Developer

    Since the term started to be used and become popular, I don't think I've ever seen that interpretation. Originally "indie" was short for "independent", meaning a developer not beholden to a publisher.

    Over time, that definition has changed, and different people now understand the term to mean different things.

    The majority of the most popular "indie" games over the years have been made by small teams rather than individuals though.

    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 FedGuard
      Hello all,
      I would like to start off with thanking you all for this community. Without fora like these to assist people the already hard journey to making an own game would be exponentially more difficult. Next I would like to apologize for the long post, in advance...
      I am contemplating making a game. There, now that's out of the way, maybe some further details might be handy.
      I am not some youngster (no offence) with dreams of breaking into the industry, I am 38, have a full-time job, a wife, kid and dog so I think I am not even considered indie? However I recently found myself with additional time on my hands and decided I would try my hand at making a game.Why? Well mostly because I would like to contribute something, also because I think I have a project worth making (and of course some extra income wouldn't hurt either to be honest). The first thing I realized was, I have absolutely no relevant skill or experience. Hmm; ok, never mind, we can overcome that, right?
      I have spent a few months "researching",meaning looking at YouTube channels, reading articles and fora. Needless to say, I am more confused now than when I started. I also bought some courses (Blender, Unity, C#) and set out to make my ideas more concrete.
      I quickly discovered, I am definitely not an artist... So I decided, though I do plan to continue learning the art side eventually, I would focus on the design and development phase first. The idea being, if it takes me a year or more solely learning stuff and taking courses without actually working on my game, I would become demoralized and the risk of quitting would increase.
      So I thought I would:
      1: Keep following the courses Unity and C# while starting on the actual game development as the courses and my knowledge progress.
      2: Acquire some artwork to help me get a connection with the game and main character, and have something to helm keep me motivated. (I already did some contacting and realized this will not be cheap...). Also try to have the main character model so I can use it to start testing the initial character and game mechanics. For this I have my first concrete question. I already learned that outsourcing this will easily run up in the high hundreds or thousands of dollars... (lowest offer so far being 220 USD) I am therefore playing with the idea of purchasing https://assetstore.unity.com/packages/3d/animations/medieval-animations-mega-pack-12141 with the intention of then have an artist alter and/or add to the animations (it is for a Roman character so some shield animations are not going to work the same way.). This way I could start  with the basic character mechanics. Is this a good idea, waste of money,...? Any suggestions? I then have a related but separate question. Is it a good idea to buy Playmaker (or some other similar software I haven't yet heard of like RPGAIO), and using this for initial build, then changing/adding code as the need arises?
      3.Get a playable initial level ready as a rough demo and then starting to look for artist for level design and character/prop creation.
      I would really appreciate some input from more experienced people, and especially answers to my questions. Of course any advice is extremely welcome.
    • By Shaarigan
      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?
    • By gdarchive
      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]
  • 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!