Artwork
In order to deliver a unique but consistent new art style, we’ve set some guidelines on how to go about designing new graphics for the game. Please make sure you refer to these closely if you plan on contributing artwork for inclusion in the game. You’ll be credited for any work that makes it into the final product.
These are the graphics shown for enemy Pokémon and entries in the Pokédex. We’re not keeping any backwards compatibility with the DMC Game Boy, so all design work should be done to make the most of the GBC’s graphics hardware, rather than being concerned with making it appear nicely on the original Game Boy too. Even in the second-generation Pokémon games, these were only hybrid GB/GBC games, in that they had enhancements for the Game Boy Color but could still be played on the original Game Boy, but they didn’t necessarily utilise the GBC as much as they could because of this backwards compatibility.
- Pokémon graphics after Red, Green and Blue (which were released before the anime) often appeared significantly differently to how they did in all future Pokémon games (including Yellow), where the art style was amended to match the designs from the anime. As such, we should follow this pattern and use the anime Pokémon as reference for the new Pokémon sprites.
- In the original games, many Pokémon sprites include black pixels in the bottom-most scanline of the sprite. When the battle scene is constructed, this line is rendered flush with the top of the player’s HUD, meaning there isn’t always a gap between these UI elements. Always make sure the bottom line of the Pokémon sprite contains no black pixels to avoid this happening in the DX version for extra polish.
- It’s not necessary for a Pokémon to have a completely solid (i.e. black) outline, in fact it may be desirable at times to not have the entire outline solid for visual variety and to give the impression of an additional shade, in a kind of faux-dithering style, perhaps to illustrate highlights caused by top-down lighting (see the Charmander example in the palette section below).
- If a Pokémon’s graphic shows them airborne (e.g. a flying or ghost type), then colour 4 of palette #4 (see palette section below) must be used as a playfield shade colour in order to represent a top-down shadow cast by the Pokémon onto the playfield, instead of being used as an additional colour for the Pokémon itself. Note, however, that this same concept unfortunately cannot also be applied to water Pokémon (as if swimming, where only their top half is visible, and they’re surrounded by a playfield shade colour to indicate disturbance on the water’s surface) who would only be ever shown on a water playfield in the wild, because they will also appear as part of trainer battles, where the playfield isn’t guaranteed to be water – i.e. say you met a member of the Elite Four who have a water Pokémon, the playfield would likely be something like a light grey to indicate being in a room, so it wouldn’t make sense for the Pokémon to be swimming as they would appear to be coming-up through the floor instead!
As outlined in the specification, each tile of the front-facing Pokémon sprites has access to one of three four-colour palettes that are reserved for its use. The required usage of these three palettes is as follows:
| # | Purpose | Colour 1 | Colour 2 | Colour 3 | Colour 4 |
|---|---|---|---|---|---|
| 4 | Used for enemy Pokémon’s outline and HUD | Black | Playfield base colour | Pokémon colour 1 | Pokémon colour 2 or playfield shade colour (e.g. for Pokémon’s shadow or glow) |
| 6 | Enemy Pokémon’s primary palette | Anything | Anything | Anything | Anything |
| 7 | Enemy Pokémon’s secondary palette | Anything | Anything | Anything | Anything |
An example of how this could be applied is demonstrated in the screenshot below. The screenshot is from a Photoshop session where I (@andidavies92) was prototyping converting @JackalOfTime’s pixel art to a format that conforms to the hardware and game’s colour requirements.
Each 8×8 tile is allocated one of the three palettes available to it (the palette allocated is illustrated in the screenshot by the blue number in the top-left of each tile in the grid), and the palette definition for this specific Pokémon is shown in the top-right of the image. The graphic has been meticulously lined-up to the grid and tweaked in order to make the best use possible of the available colours given the hardware limitations and number of palettes available.
In designing your own graphics, keep this in mind, that you may get benefit from shifting the entire graphic over in one/two directions by a few pixels, or by slightly expanding/compressing elements of the character, in order to get the best out of the colours at your disposal – examples of how this was done in the image below include:
- Using the aditional colour in palette #4 for the whites of Charmander’s eyes (given these tiles include the border of the character)
- The inside of Charmander’s mouth and their iris being contained within the same cell so that they can use two of the colours in palette #6 for visual variety by highlighting these features
- The belly being aligned such that it contains no playfield pixels meaning it can use an alternative palette in order to give the belly a different colour from the rest of Charmander’s skin.
- The belly colour being chosen as a compromise between the true colour of Charmander’s belly from the anime reference and fire-like yellow and brown shades, so that these colours can then be reused as part of their tail flame.
- Expanding the size of their tail flame to fill an entire tile so that it can use palette #7’s various shades of fire-like colours (as if it was only allocated palette #4 then it would only have access to orange and black for the flame).
- Moving the image up enough so that there are no black pixels on the bottom scanline, otherwise these may touch the top of the player’s Pokémon name in a battle scene.
- The middle of Charmander’s tail flame’s right-hand edge has to be entirely flat as a tradeoff, otherwise if the image was shifted a pixel to the left then the left-most pixels of Charmander’s mouth and belly wouldn’t be able to use their specifically-allocated colours.
- Another small tradeoff can be seen under Charmander’s left arm, where a pixel along the right-hand edge would ideally be the playfield colour, but because the graphic can’t be moved right (as this would negatively affect other areas of the graphic), brown is chosen as a next-best option, which shouldn’t be that noticeable in practice.
Photoshop screenshot:
