Ever since I started doing game development, color palettes were always this magical thing that I didn't really understand. I didn't know why they were helpful, how they were made, or anything about them really. Recently we've bumbled our way through creating simple color palettes for the environments and the characters, and I've learned a lot about the process. The first thing I learned is that color is hard. Really hard. And unless you have a good eye for it, it's a very practiced skill. What Is a Color Palette?
So my interpretation of a color palette prior to working on Twoneironauts is that it represents the predetermined colors that can be used for an environment/character. It always seemed odd to me, because I pictured the color palette decided upon first, and then it simply applied to a character/environment. This seems backwards because some color palettes work better on some things, and worse on others - you just don't know until you try it. What I've learned a color palette to be, is more of an experimentation process. We take a character with values that we think will be interesting, and apply colors to the values so that we can see how different color schemes will look. There are many different types of color schemes (7 total color schemes to my knowledge). And what you select depends on the style/limitations of the game, as well as the personality you'd like to get across with the character. However, many different color palettes can work for a single character's values. The process is definitely not linear. We don't select colors, select values, combine, and done. That almost never works without needing some kind of adjustments to make the character's colors work better. One way of working with the characters seems to be slightly segregated, where we develop values and then experiment with colors over the values of the character. Another seems to be more free-form, where we try colors on the character until something looks right, and the values are adjusted and come from the free-form color theory. What works really depends on the artist's understanding of color theory and how comfortable they are with hue and value. If you want a hard definition for what a color palette is, I'd say; A color palette is a sequence of colors that are important to the character/environment in question. Changing these values change the character's look and feel, and all of them rely on one another because of how colors work with one-another to create a cohesive design. So what this means, is you can't just arbitrarily change any one of these colors, it changes the scheme, which might change the other related colors. What Are Value Comps? Value is essentially the brightness that can be seen within the character. If you are unfamiliar with HSV (Hue, Saturation, and Value); Hue is a particular color, Saturation is how much of the color is present, and Value is where that color lies along the spectrum from dark to light. So for instance; red, blue, and green are all different hues. I make no claim that they have separate saturation or values, but if you are picturing the primary colors, it's likely you're picturing them with the same value and saturation. Value is how light or dark that color is, which is not to be confused with how much of that color is present. For example, I can have a 50% gray color, and a green color that matches in that 50% gray value. The amount of green that is present in that same value is known as the saturation of the color. A completely unsaturated green (0%) would just be gray (Green hue, 0% saturation, 50% value). A completely saturated green would be the same setup, but our hue matters because there is now saturation (Green hue, 100% saturation, 50% value). If we can decide on the values of a character, it allows us to easily try different hues and saturation to make. If we know we want the characters to be very easy to see on the screen (or that they may be easy to lose in the background) a trick we can pull is to lessen-saturation for the background, and greater-saturation for the characters (or vice-versa depending on the game). Another change is to make the background have a lower value than the characters to darken it and bring it back further (amount also depends on game, and this can also be vice-versa, the characters could be dark and the background could be light). The idea is the same one presented in the Email Chain about color palettes from Professor Schneuwly that stated: "We always say one thing, light over dark or dark over light will help the scene to be read properly." This is good advice and really helped us understand what direction to take the environment and characters. How Are We Handling Animations? The original idea for animation was a skeletal-animation utility named Spine. The reason - despite unpopular response to the selection - was largely due to the massive scope of Twoneironauts. There are ramp-up times for Spine, but in general changes to a skeletal animation sounded easier to maintain than changes to, say, a frame-by-frame animation. Of course it's not ideal, but many tools use skeletal animations to a great degree, and I think the main issue I encountered when attempting to gain ground for the tool is that I misunderstood the easiest way to solve the issue. A better solution was presented which was just flash-based animation utilities, but with restrictions. We'd have to be careful, because what I don't want is frame-by-frames. The animation being skeletal never was the backbone (pun intended) of why we switched to skeletal animations. It was always to aid in rapid development of animation construction, and being able to quickly, and easily, change the characters outfits in case we wanted to support different pajamas for the characters (a feature that is looking to become more of a stretch goal than a core design pillar). I still think even without pajamas being a pillar for the design, it'd be easier to maintain animations that have graphic symbols for the body parts, and manipulate these symbols through keyframe tweening. This allows us to easily change what a leg would look like without redoing a ton of animations or frames. An example of animations done wrong in Twoneironauts would be that each frame is a keyframe to a completely new symbol. Symbols must be kept to an absolute minimum while also maintaining the high quality graphics we wish to produce. So the current idea is flash animations provided by a swf to the developer team, and the game can parse the swf to get animations from it. The fla file is the file that artists will use to manipulate animations. There are several tools that can keyframe swf files to produce a spritesheet, but I'd rather keep this as efficient and scalable as possible by not producing a spritesheet. It all depends on what the developer team can get to us, and how easy it will be able to be fit into the code in-game. Ideally it'd work almost identically to Spine, as it's Unity API is very strong, just without the restrictions that it has to be a skeletal animation. Currently we are using the animations provided by Guacamelee (which has been a great source of inspiration for Twoneironauts) as an example of a deliverable file for the artists and developers. If we look elsewhere, I'd guess that Night in the Woods would be an excellent reference to understand their animation system, as it looks very much like the style we are seeking, and they are using Unity to make their game. What's Next? Next week will mark a great deal of experimentation with environments, and thought as to how we can get those environments into the game. I will probably have to schedule meetings with a few of the game professors to see what would work best, as it's looking less and less like tilemaps will be useful for this game. (The original concept was pixel art, which works nicely with tilesets/tilemaps, but that needs to change with the new vector-art direction of the game.) We also will be presenting a rough-draft of the style guide in ART399 for Milestone 3 for the artists. After milestone 3 we will begin actually considering to make final sample deliverable content, even though ideally more concept work needs to be done. Despite taking a little over a month in preproduction, I think we are making great progress, and that the game is going well. Gameplay-wise I have some concerns since I haven't been able to prototype at all, but I think that we have a strong enough base for the game that we can produce at least an "okay" game bare-minimum. But we need to definitely do a little more design work to make this game a "great" game, and I think it's entirely possible to do this through theme, visuals, and cohesiveness minimal. (Introducing interesting player actions is the next step though, as a beat-em-up requires a lot of art, and a lot of content.) So until next week - Cheers!
0 Comments
Leave a Reply. |
Archives
April 2015
Tags
All
Production BlogPosts by our team members. |