This article is aimed at hobbyists/indie developers with limited spare time to dedicate to their projects. It seeks to help them increase their motivation (and finish their projects) all the while improving their working environment setup and productivity.
From past experiences, I have learned that the single most important factor to get games done lies with the ability of the developer to deliver increments of functionality at a steady pace.
Essentially, a project will only get done if an external eye to the project sees consistent progress throughout longer periods of time. The odds of succeeding are also generally tied with the ability to deliver these increments at more or less regular intervals.
There are many reasons why a developer that sets out with the best of intentions will end up being unable to deliver functionality over time, and these reasons will end up killing the project. Rather than discussing the symptoms here, I'll explain my way of overcoming them.
Implementing a Development Routine (5,1,1 Routine)
To establish sustainable development over long stretches of time, a developer needs to have a Routine. This mental construct will initially be forced, and eventually become a habit, so that the majority of threats endangering the project will be met with fierce and effortless resistance.
Different developers will prefer different routines, of course, so bear in mind this works for me and may not work for you. However, the idea of a Routine remains universal.
I call mine the "5,1,1 Routine"...
I accidentally created the 5,1,1 Routine during one of my hobby projects, and decided to stick with this method as it allowed me to meet three very important objectives:
Remain motivated with the project by working on fun features most of the time.
Deliver shippable increments of functionality regularly (sustained velocity).
Perform a constant health check of my code with limited effort.
What is the 5,1,1 Routine?
The 5,1,1 Routine is a representation of the workload in a given week in regards to three axis.
5 Dev Days... (I deliver a new feature or improvement)
1 Refactor Day... (I cleanup and optimize the code)
1 Rest Day... (I don't look at the project)
What are Dev Days?
This methodology assumes that my codebase is healthy enough to allow me to develop new aspects of the game five days per week, which is what will keep me motivated to continue my work on the project.
During these five days, I will develop new features with the quickest possible route in mind, regardless of how "unclean" it will look. The reason for this is twofold:
a - We're developing an entertainment product (game), and fun is hard to catch. Rarely will the first implementation feel right, therefore it's better to be able to try several messy ways in a single day than to try a single clean way.
b - These dev days are meant to keep my motivation high. The fun comes from seeing new things working in my game, not from clean code. The more new stuff I get to try, the more excited I get about the project as a whole. I don't feel wrong because I know that 90% of the things I'll try will end up being discarded, thus won't harm my codebase much at the end of the day.
Usually, I'll want to deliver something new EVERY day. To achieve this, I like to keep the JIT / DWYN attitude.
JIT (Just-In-Time): While generally employed to relate to inventory, one can correlate this with information flow in regards to decision-making. Essentially, postpone any technical decision until later. Code your new feature quickly and don't have any foresight about how it can be reused (you can always use your refactor days for that anyway).
Do what you need (Lean): A good way to prevent over-engineering, this tells you to code exactly what you need and nothing more. When you refactor later or need to build a more complex mechanic that leverages the same logic, you can always revisit, but assuming that you will and over-engineering will result in tremendous amounts of time loss.
What is a Refactor Day?
If you've been developing for a while, chances are you've quit on many projects solely because they reached a point where it would take too long to implement any new idea. This can be explained as technical debt.
Though I spend five days per week adding stuff without caring much about how clean the code is, I discipline myself into adding an extra day per week where I am not allowed to develop anything new, and rather, I seek only to clean up my codebase, refactor, etc. In other words, I deal with my technical debt.
Note that I use the term discipline to represent that I not only force myself to refactor but that I allow refactoring a very specific amount of time. This allows me to ensure I do enough refactoring so that I can maintain my development velocity, but not too much refactoring, which would pointlessly halt development altogether. This is used as a means to prevent me from falling into either the prototyping mood (which can never amount to shipped large scope projects) or the coder's mood (where the technological thrill outweighs the goal of delivering a game).
In the methodology known as Test-Driven Development (TDD), the goal is to reach a functional state as quickly as possible and then refactor. This is usually done within a few minutes. In 5,1,1, this Routine is stretched across a development cycle of a week.
The other advantage of having a sixth day dedicated to refactoring is to keep a general understanding of the project. Since I spend five days looking at the new code, I don't want to lose sight of what the rest of the code base looks like, and how I can find ways to optimize/refactor. It also ensures that I'm still familiar with the codebase when I get back to development on the next Dev day the week after.
I used to be the kind of developer that tried to get things done through weekend development sprees believing that having longer stretches of time would be more beneficial as my concentration would be easier to muster. It turns out that the amount of concentration required to undergo these sprees is largely due to forgetting a lot about the codebase in-between sprees. As a result, I find a lot more value in spacing that development time across a week and retain a constant understanding of the codebase.
For more information on refactoring (and clean code), see
">this video. I went to college with this guy, and he's grown into a very successful indie, so I was amazed to watch this video after completing this article.
What if 5,1,1 breaks?
It's entirely possible that the 5,1,1 will break, and though this is not desirable per se, it exposes any threat so that it becomes actionable.
Determining that the 5,1,1 is broken is fairly simple and can be answered with a very simple question:
Did I deliver an increment of functionality on each dev day?
The key to 5,1,1 is to understand why the method broke, and how to fix it. One of the most common reasons for the cycle to break will be that a specific class, function or segment of code is currently in a state that makes it impossible to deliver new increments of functionality on each dev day. This could be due to code readability, unnecessary complexity resulting from multiple iterations, or any other logical issue that could be dealt with on a refactor day.
When this occurs, I willingly choose to sacrifice one of my dev days and turn it in an extra refactor day (turning that specific week in a 4,2,1), knowing there's a very specific goal to be attained in order to restore my cycle.
I generally refrain from using the 7th day (rest day). The rest day should, most of the time, be sacred. It is a day that keeps everything in equilibrium and allows for this routine to last. No matter how asocial one might be, there's always a time when other things need to get done, and having a routine that leaves room for this is essential. It's also a good way to stay clear from burn-outs.
Ways to make refactoring fun
Some developers refactor too much and over-engineer. If you are one such developer, I recommend reading this article.
For the more gameplay-oriented programmers, however, refactoring is often perceived as a pain, a necessary evil, and is often cause for grief.
We've already addressed a way to build up momentum and motivation by having five dev days, but unless you come to your refactoring day with a plan in mind, you're still likely to loathe it. There are various ways you can approach this, but the important thing here is to prioritize the work that makes the most sense all the while keeping your sanity above ground.
My personal approach is to come with a specific goal in mind. It could be that I have identified throughout the week a very painful bit of code that I need to deal with recurrently that could be refactored into something more intuitive and easier to use. It could also be that I happen to think that I've broken enough encapsulation rules to try and fix this before it becomes spaghetti code. The key here is that your recent development cycle is still fresh in memory, so you know where you've struggled, and what you have stained with poor (new) code.
Whatever the problem you may have identified, make sure that it will reduce your development time for new features. That way, you won't feel like you're shooting in the dark. Also, make sure to vary your method and focus from week to week to keep things interesting. It's a good way to make sure it does not feel redundant over longer stretches of time.
Ways to make each dev day more efficient
Here is a short list of tools and techniques that can help you stay focused and gain velocity. These are software that I have used in various projects. Please note that while I suggest specific software for each category, it may not be the most suitable for you, but it doesn't hurt to know where to start looking.
Source Control (SVN / GIT / Perforce)
I'm always surprised by developers (generally "lone" wolves) that don't use source versioning. These allow you to do many things at once with relatively little effort:
Share your source code with somebody and allow more than one person to work on the project at once. Though you may not plan on having anybody else contributing to the project at this stage, it's not a given that it will never happen.
Prevent data loss when your development setup unmistakenly breaks. A simple checkout will restore your project a few minutes away from where you were at.
Help you establish a "system." By establishing the rules of "when to commit," you have a more healthy relationship with your development cycle.
Also, when looking for free hosting for source versioning, I recommend: Assembla.Task / Bug Tracking (Trello, Assembla)
As an indie, it's easy to fall prey to the misconception that it's possible for one person to "know-it-all" because of the scope of the project. Even if it were accurate, it would take such a toll on a person's memory that the impact in everyday life is not desirable.
Rather, the use of tools that allow you to track tasks and ideas is preferable. I use Trello for my projects. The key here is that a simple tool allows you to do more. Trello has the advantage of being flexible (create your own workflow/categories, the ability to add checklists, etc.). Furthermore, it works on mobile, making it also good at taking notes in the context of a project (rather than in a standalone app).
What I like about Trello is that it allows you to create one item (say, a feature) and break it down in many sub-checklists. This way, you can contain within a single feature the necessary logical components, the assets you might need and other requirements, the polish ideas you have along with any bug or optimization requirements you might have. Thus, your Trello board can be a collection of high-level features that display something along the lines of "Feature name - 10/93 items".
Continuous Integration (Jenkins)
A bit more recent perhaps than other items listed here, the concept of continuous integration is really something to delve into. It allows you to minimize the amount of time lost "building" the project and makes it simple to screen a build whenever you want. By default, it will build a version after every commit you make. Versioning might prove catastrophic at first, but you'll get the hang of it.
I'll admit that I've never looked at alternatives to Jenkins. The gain I've experienced when first using Jenkins was so great that I did not bother to compare, but there may be better ways to do this out there.
How to get Games Done
You may follow all of the above and still not get games done. That's because while you may understand how to "get there," it's possible that you have no idea where "there" actually is. Say you want to go to Newark's airport, and I tell you it's somewhere along the New Jersey Turnpike, it's quite possible you'll end up god-knows-where along the turnpike because you have no idea what an airport looks like (arguably they've done a pretty good job at putting signs up, and well, there are planes, but without prior knowledge about what planes are it won't help you much).
Making games is no exception. If you know your way around development tools and have a development cycle, it's possible you'll miss out on completing a project, despite being highly motivated. If this is your case, here are a few things to bear in mind as you define your overall development "strategy" (something you should think about before starting, and iterate on as time passes by).
Have a clear idea of what you want to demonstrate
What you should have at this stage is a "game vision." In simple terms, you should be able to describe the end-user experience before the software is built, knowing that some things will need to shift along the way. You should not know everything in finer d?tails, but you need to have this sort of high-level interpretation of how it will all come together.
A good way to confirm that you have a clear idea of what you want to demonstrate is to try to explain your game to a friend using as few words as possible, and yet hype them. If your friend starts saying "oh and you should do this and that..." you should probably ignore the specifics, but you'll at least know you've come up with an idea that is fertile ground. Your job then will only be to squeeze out the fun where it really is and exploit the fun-vein to a maximum.
How to scope & iterate (MVP)
As a game developer and designer, your role is initially to demonstrate fun gameplay. The core of your job should be to build a skeleton of the game you want to build, by focusing on its most important aspects (what makes it unique, fun, etc.). If you're not going for original gameplay, and rather focus on execution, then there should be fewer unknowns in regards to what's fun early on, but timing will still be critical. Don't assume that just because you are doing a final fantasy rip off, the same pace should be used in exploration and combat just because it worked for these games.
The next logical step is to build an MVP: Minimum-Viable Product. In essence, the MVP represents the minimum your game can ever be. It's a condensed game that contains very few mechanics. However, each mechanic will be brought to complete fruition.
The process to get there is to build the skeleton first. Prog-art, your prototype, check what works, what doesn't. Then iterate until this part makes sense. Then, proceed to the next core gameplay mechanic. Once each CORE gameplay mechanic feels right, hone them. Develop each of these mechanics until you feel like your game is a polished gem, with much untapped potential. Play this build over and over again and ask for feedback. THIS is your MVP. If anything happens tomorrow, you'll have at least achieved that (the minimum your game can ever be to deserve to be called a game). Instead of being a shady prototype halfway through completion of the next uber MMORPG, you'll have achieved a shippable game that may just lack depth.
Why is this critical? Because from now on, you can release this game anytime you want, and you know the quality you are delivering. In fact, you knew the quality you were delivering every step of the way, never worried about whether other mechanics would feel right or not.
Knowing that you can release anytime alleviates the pressure of the unfinished project and helps you keep a high motivation. It's much easier to think in terms of polishing a final product than to get everything missing for release. While you may spend the same amount of time on the game, you've had a lot more control on overall quality, always working on that which has more value and always judging of new feature's value based on their coherence with what is established.
This is a mindset that takes some getting used to, but over time, it's something I've grown incapable to avoid based on the sheer benefits of this approach.
The drawback to this approach is feature-creep. Having an MVP in hand puts you in a state of mind where you need to consider the features you feel you need to add to complete the greater experience. The problem is that you might get excited about way more features than the game would normally support. There's no real rule to determine when you've entered the feature-creep lane, but if you find yourself months beyond your MVP and still have a lengthy list of things you'd like to add, consider releasing first and adding whatever you need based on user reviews instead. If the game allows it, consider metric-driven development if at all relevant.
Let's face it, there are many reasons not to set deadlines. This is likely a hobby project, and the truth is that you might enjoy the indefinite nature of it. I won't argue here as I have plenty of side projects of my own that don't have a set deadline. The key difference is that I did not choose to make these a priority and I did not determine I wanted to get them Done.
The premise of this article is that you want to get this game done. If this specific project does not fit this criterion, you are more than welcome resuming work on it without actually applying any system or deadline. Just know that it is likely to fail/fall in an indefinite hiatus at some point. There's nothing wrong with that. As a matter of fact, it's better to toy with many ideas at once and choose to only pursue the most fun.
Once you've browsed over your projects and have identified the one you really want to complete, then it's time to trade the safety you had knowing there were no "rules" for a system and actual deadlines.
Deadlines shouldn't be daunting. You are not liable for a contract here as you would in the corporate world. Rather, think of deadlines as goals, ways to keep a macro idea of where you are headed. I personally like to think of my own deadlines as extremely lax and vague, but they allow me to place tangible milestones in time and give me an idea of the commitment I need to put towards achieving what I want.
For example, your first milestone could be just a prototype, and it may take as many milestones as you want just to get to the MVP. Don't try to be too micro. However, you're only likely to make your milestone definition irrelevant as time passes by.
Also, don't put an exact date on a milestone. Depending on the scope, a specific week or month may be enough. I personally use quarters of a year and calendar events as references ("I'll get this done before Christmas, and this somewhere in Q1 2014).
You don't have to stick to your milestones if the circumstances change (if a core gameplay element isn't as fun as it should and you've chosen to take the time to fix it or find alternatives) but you should always have a broad plan of where you are headed days, weeks, months from now (task tracking helps, especially in the form of notes for "later").
The mere effort to project your project in time is what matters, not the end result. Pat yourself on the back if you meet a deadline, don't focus on the deadlines you miss and simply keep in check the reasons why you have failed. Are you overthinking things? Are you still working on the MVP? It's possible that you'll find out you've been feature-creeping. If you are, learn to let go, push these ideas through Trello instead, and focus on what needs to be done first. Perhaps you'll discover your game vision has grown blurry? Take a pause, reassess what you think the game should be, how it should feel, then resume work. It's pointless to work on fun bits of the game if they can't become part of the greater whole and feel coherent with the experience.
Random Thoughts & Rants
Here's a short list of practices you might want to set up. These are mostly aimed at team work environments (2+ people).
One good practice is to do weekly team review. If you can afford it (even over Skype), this is extremely helpful in setting everybody's expectations straight and keeping the vision clear. It's also a good opportunity to discuss potential features, solutions to some problems, and more importantly, evaluate the level of fun resulting from the current implementation.
If using the 5,1,1, you can probably do these every other Rest day.
If you're working on something on your end while others work on something else, it's always good to send them something partial as you are progressing with minimal information. If possible, seeing them manipulating it is ideal, but comments can also work. It will give you an idea how intuitive what you're doing is and will grant you impressively useful feedbacks.
The often forgotten effect of doing this is keeping the motivation across the team. This article does not discuss teamwork much, but it is critical to leverage each other's motivation to keep the boat afloat in larger teams (or risk chain reaction of demotivation). Experiencing what others are doing and receiving a stream of comments on what you are doing keeps the dialogue open. You need to use each other's mind as much as possible to make this the best game it can be.
Often discarded... sadly.
You need to get out there and let people play your build. Ideally, you want to see them in action (moreso than team members). Be aware of who these players are compared to your target audience (this will let you know which part of the notes you are taking will be truly relevant). There are various ways to do this which doesn't fit within the scope of this article, however. I recommend reading further on the subject of defining your target audience through the big five.
Leadership (who owns what)
As the team becomes larger, it's important for roles to be clear. By "who owns what," I'm not referring to the final product and legal ownership of the end-result. Rather, I'm discussing about who should have final say on what matters.
The best approach I've used this far is to allow everyone to pitch into everything, but give the final say to the one most proficient with that discipline. For example, I do some programming on my projects, but it's not uncommon for my partner to have superior programming skills, and I tend to grant him the final say in everything technical. Likewise, I tend to have a clearer vision of the end product (especially when I'm responsible for initially creating the high-level concept) and like to keep final say in design matters, but not all.
To keep other team members motivated on the team, I also break down the design into various features/components. For example, if making a tactical game, though the game may be my original idea, I may end up being teamed with a Tactics Ogre // Final Fantasy Tactics freak. Why not share design ownership?
There may be reasons not to share this ownership, though. The important part is to make sure that ownership is clear for everyone to avoid people feeling like they are in control until denied later. Confusion on who owns what can be a real team killer as it turns out, and it's better to gauge team member's assumptions early on (and tell them outright where they might not have authority) than to lead them on until you need to squash their dreams by imposing your vision.
If you do all of the above, you may not make a great game, but you'll at least complete it, knowing that you've completed something that is as good as you could make it. The difference if you lose hope is that you'll have something to show for instead of nothing. Putting that "decent project that could've been so much more" on your website might draw people to you, either in the form of potential players, or collaborators. Never under-estimate the value of completed projects when gauging for partners. It gives people faith in your ability to get things done, and with the number of indie developers lurking about, this is key to forming bigger teams or relationships.
What you'll learn from this experience will also help you on the next project, and the next... until ultimately you release games in the state you want them to be. It can take 4-5+ projects before you get there, but hopefully, this method will make the journey less painful, and leave you with tangible proofs of your efforts.
If you have your own system, let me know! I'm always curious about how other minds work, and how people manage to motivate themselves. Though my system allows me to complete games, it's not perfect, and I'm always looking for ways to further improve it.
Article Update Log
28 Jan 2014: Created Draft, modified templating from the original file.
2 July 2015: Updated broken link.
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!
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.
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?
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.
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.
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.
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.
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]
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?