Wanted: Pixel Artist

Update 1/26: We’ve received a large number of applications, more than enough to find the artist we need.

Grid Sage Games is hiring! It’s not a full-time position, of course, but freelance pixel artists should take note and read on. Also pass the news on to anyone you know who might be interested.

I know that there are a lot of talented artists out there, but this project may not be for everyone, so making the specifications public should save us all some time.

This post also doubles as a look at what Cogmind is doing in terms of tile support, so let’s start there for some background.

Tiles Mode

Ever since Cogmind was rebooted in 2013, there have been plans to include a tileset. This is easy to forget since I almost never bring it up, but it’s only a matter of time--and the fact that we couldn’t be bothered with that particular feature when we already have ASCII and are busy implementing the mechanics and UI.

I say the game looks great in its “native ASCII,” but some players can’t stand ASCII no matter how attractive and accessible it is, and we want these players to enjoy the game as well. If Cogmind can reach a wider audience that’s good for everyone!

The prototype originally released in 2012 actually comes with a set of simple sprites:

Spritesheet from Cogmind’s 7DRL/prototype version (2012).

Those were put together one afternoon some weeks after the initial 7DRL release, and are only available for the default 12×12 font size. We’re going to need 1) a lot more and 2) better than what you see there :D

I finally turned my attention to this feature and updated tiles mode to catch up with the rest of the game. You can now switch between modes on the fly, and the change even comes with an animated transition (of course =p). For testing I imported the old 7DRL sprites:

Cogmind tiles-ASCII mode transition.

Being able to switch at the press of a button is not exactly a useful feature, but I can imagine playing a joke on someone by introducing them to Cogmind with tiles, then hitting F3 while their back is turned ;) (F3 is currently the key to switch modes).

So internally the game is prepared for tiles--now it’s just a matter of dropping them into the spritesheets, which are ready and waiting.

Specifications

Notice that stylewise my sample sprites might not be what you first think of when imagining a roguelike with “pixel art tiles.” It is, however, the general style we need. Their almost icon-like appearance is more compatible with the game’s overall aesthetic, and in a way you could say it’s very similar to ASCII--minimalist, monochrome. Most importantly, we want them to be readable*, also like ASCII. They could even be more icon-like (other kinds of non-ASCII representative symbols?). (*I’m not implying mine are readable, by the way =p)

I’m open to suggestions and the artist has relative freedom, or as free as you’re going to get within the scope of the technical limitations outlined below.

Technical

As in the sample spritesheet above, all the sprites are drawn in grayscale. This is because they’re recolored by the game as necessary, translating the amount of white into the alpha transparency of each pixel. So you “only” have 255 values to work with, don’t have to worry about multiple colors, and can use shading as little or as much as you want or need to.

A sample sprite (zoomed for detail), the hovering programmer bot from the prototype, in its original sprite form (left) and as the engine would color it using other base colors.

(By the way, if you’re new here and wonder why I’m going over what may seem like a basic feature of pixel art seen in some games, it’s because this is also a regular development post for the general readership.)

Workload

How many of these things do we need? The answer is somewhat flexible, since in quite a few cases we will end up reusing the same tiles for multiple objects. Below is a comprehensive list of the absolute minimum set of tiles/sprites needed:

• 26x medium/large robots (take up maybe 75~100% of cell)
• 5x small robots (take up maybe 50% of cell)
• 4x quad-cell robots (each occupies 4 cells arranged in a square)
• 2x 9-cell robots (each occupies 9 cells arranged in a square)
• 26x item categories
• 8x walls (different styles, no orientations)
• 8x doors (closed)
• 8x doors (open)
• 16x debris, ranging from low to high density
• 4x special terrain (solid earth, secret door, stairs)
• 1x debris-like piece of metal
• 2x destroyed terrain (wall, door)
• 3x scan signal markers

Except where otherwise indicated (multi-cell robots), all tiles are the same square dimensions. My own example set uses 12×12 tiles, but we’ll need other sizes as well (explained further below).

I’ve already prepared the spritesheet where these tiles will go, complete with guides (many hidden here to avoid spoilers):

Cogmind’s new spritesheet layout (12×12 cells). (In total only about half of the cells are used.)

Reference coordinates have already been added to the game data, so it’s ready to drop and load.

Probably the biggest catch to all this: We need each tile to be available at every font size the game supports! I’ve written about Cogmind’s font sizes before. To recap, Cogmind can display fonts at 10×10, 12×12, 14×14, 16×16, 18×18, and 20×20.

Meeting this need may seem boring for some of you, or perhaps you’d enjoy the challenge of representing the same object at different levels of detail, from the more abstract lower end to the potential for much greater detail at 20×20. (We may need to make an exception to that consistency for 10×10, which is pretty tiny. It could even stay pure ASCII.) Aside: I should emphasize here that individual players will generally not see all, or even most, of the different sizes--this is not for some kind of zoom effect (though technically the player can switch sizes at the press of a button)--a single player will usually play at the size most suitable for their desktop resolution, and always stick with that.

The good thing is individual sprites aren’t too much work, being monochrome static images (no animation!!!) that are probably low on complexity (without color to help increase the density of details).

Beyond what’s described above there’s the possibility for additional sprites, though this will depend both on style and cost. We may want to increase the number of unique sprites for a certain category of robots, or, it’s certainly not a priority, but projectiles are another category of objects not yet accounted for (these are currently always ASCII, since they’re fast and simple anyway).

In summary, we need tiles for at least everything listed further above in up to SIX (6) different sizes (maybe five if we decide 10×10 doesn’t work).

To put the total workload in perspective, using the spritesheet template as a base I’ve compiled a single image depicting the minimum area of all necessary tiles:

Cogmind spritesheets--total area (click to view at full size).

Considerations

You won’t have to worry too much about color other than knowing what colors might be used for a given tile in game, as that can affect overall brightness and visibility of any detail.

For this purpose you’ll get a copy of the game as soon as you have the job, and can use sandbox mode to test sprites as they’re dropped into the spritesheet. The sandbox contains every object in the game in one big open play area:

One section of Cogmind’s sandbox map (it’s ASCII, but there are contents I don’t want to spoil so I had fun obfuscating it into what appear to be UFO Defense motion detector blips =p).

One major consideration is how pixel art tiles interact with the surrounding ASCII elements. Tiles mode does nothing to change the UI, nor machines, which have to work visually with the rest of the map art. This may seem an odd design choice since the ASCII machines will likely end up with a lower level of detail than the rest of the tileset, but from another perspective this has the interesting effect of making the machines feel even larger than they already are (as multi-space objects):

The prototype sprites mingling with the new version’s ASCII machines.

Increasing machine detail would be a very difficult task, both given the engine constraints and because it would vastly increase the number of required tiles. The only compromise plan I’ve been able to come up with is to mimic the current ASCII setup whereby machines are constructed of reusable smaller pieces, only they’re pieces with greater detail. Without a lot more tiles, though, it would be difficult to add much meaningful machine-specific detail.

I don’t doubt that larger machines could look good. Check out this quick piece from last year by Ben Porter (@eigenbom), of Moonman fame:

Machine: ASCII vs. pixel art concept.

(By the way, Ben is Kickstarting his already three-years-in-the-making pixel art procedural platformer--check it out!)

Requirements

Anyone interested in filling this position should mail me at gridsagegames@gmail.com. Please include “[ART]” in the subject line.

I’d prefer candidates with a professional/freelance background specifically in pixel art, though if you can show me a cool concept I can overlook most other requirements.

The two must-have items for consideration are:

1. A portfolio, something with more than a couple random pieces of art.
2. Billing rates for the type of work detailed above. Obviously you can give a general range here--we’ll get into specifics if you’re chosen. (Offers of “free work” will not be considered.)

I’ll give preference to anyone who also provides a few sample tiles/sprites to demo their concept (in both small (12×12) and larger (18×18~20×20) sizes). Tiles in this style are small and quick to produce, so it should be easy to provide a few examples if you’re really interested in the job. This is not required, but if I’m shown concepts I already really like at a rate I can accept then I’m naturally less likely to do much more proactive searching. (Note: I may want to show some concepts publicly--anonymously--before making a decision, so please inform me if this is not okay with you!)

Because a majority of artists won’t be familiar with this project yet, here’s a list of a few common object types (some given different more descriptive or general names than they have in game; and to avoid spoilers I’m not listing anything that’s new since the public prototype):

• Robots: recyclers, engineers, haulers, fliers, soldiers, sentries, hunters, programmers, behemoths
• Item Categories: engines, treads, legs, guns, cannons, melee weapons, devices, processors

I’m hoping to find someone who both has a good concept and is very interested in Cogmind. I suggest you check out Cogmind’s website for inspiration and to learn about the game. You can even go play the old prototype, linked at the bottom of the FAQ.

It doesn’t really matter where you are, though I’d prefer U.S. artists just because I have an easier method of payment there. As for rates, this is a niche game (at least I’ll continue to believe this until the market proves me wrong =p), so I hope to keep costs down, but I will provide fair pay for quality work. Either way, know that this is not a rev share deal.

Schedule-wise, this is a very flexible job since we don’t have any strict deadlines that absolutely require tiles. The game is only now nearing an alpha launch (aiming for April) and we don’t even need them all ready by then--more like just a small set. There is still plenty of work to do on the game, far more than it will take to finish the tiles. As long as it is economically feasible, though, there is quite likely to be additional intermittent work in the future as more special content is added.

Send any questions via e-mail or leave them as comments here (and anyone else feel free to chime in about anything!). (Remember: E-mails should include “[ART]” in the subject line.)

Credit

Cogmind is 100% going to be a game. This is not some vaporware project you’ll contribute to without any meaningful recognition. The first release is coming soon, even (hopefully with a partial tileset, but we have plenty of players already interested in ASCII alone).

Cogmind may be niche but it’s no small-time project, either, having been recognized as one of the best upcoming games of 2015 by Rock, Paper, Shotgun and making it into Indie DB’s Top 100 of 2014. So there are other benefits to immortalizing your name on this cool page:

Cogmind’s in-game credit’s page (WIP).

As you can see, the position’s waiting to be filled :D

Notification

During the application process I’ll reply to all e-mails (eventually--not immediately), but once the position has been filled this post will be updated to reflect that. So until you see that notice here, this position is still OPEN!

Update 1/26: We’ve received a large number of applications, more than enough to find the artist we need.