Official development blog

Alpha Release State

Cogmind’s first public alpha release, scheduled for May as announced earlier, will be both playable and fun, but by no means done. This post explains what will and will not be included in the first release, and where development will go from there.

What is ready?

First and most importantly, what exactly can you already do in the game?

Simply put, Cogmind is functionally complete. I wouldn’t want to launch anything that doesn’t already offer an enjoyable experience. Thus we have the entire core game and its wide array of mechanics:

Even once you know the mechanics inside and out, procedural maps combined with plenty of unique content mean the game already contains a huge amount of replayability. Content-wise there is currently plenty to discover and experience:

  • Many completely unique robot classes to interact with, or even control (though allies will not be as plentiful or easy to come by in the initial release as they will be in subsequent versions).
  • Many hundreds of unique items, each with their own ASCII art.
  • Explore 10 depths to the end game (the largest maps cover 20,000~30,000 spaces).
  • Start learning about the world’s story and lore via hacking.
  • A zillion sound effects (or somewhere around that number) for weapons, destruction, and more.
  • An equally zillion ASCII particle effects with the potential to blow minds (effect tripled when combined with sound effects).
  • The most powerful ASCII UI in history (simply too much to link here--so many more features…).
  • Both fully operational ASCII and tiles modes.

If you’ve played the prototype from 2012, and many of you did and had great things to say, it’s like that only x100.

And by the time we’re done it’s going to be x200, or so :)

What are we missing?

While it’s likely we’ll be adding a few new mechanics later on, that part of the game already offers a complete experience. What we’re missing from the must-have category of features is a rather large chunk of the world and related content that guides the overall experience.

Essentially we have a lot of core content as described above, but need to add much of the complementary content that makes up the world, as well as a few features that glue it all together. That’s an abstract way of explaining that we’re missing:

  • Different Maps: While you can currently traverse the main complex straight to the end of the game, the intention is that you’ll sometimes want to take a few detours into other areas for various purposes. As is, beginning in the mid/late-game areas you’ll find a fair number of blocked exits because many of these branches are incomplete and therefore closed off. There are about 7 map styles out of a planned 25-30. For the final stretch of pre-alpha development, just completed, we did add initial versions of the two primary early-game branches.
  • Map Content: Aside from their robot inhabitants, and machines, maps lack additional unique character that will later be provided by encounters and more hand-made content. There is still plenty to enjoy, however. It’s not that you’ll be bored, but more that the game is missing a fair bit of “extra stuff.”
  • Story: The interactive parts of the story have not been added, as almost all of it takes place outside the main complex in branches that aren’t prepared. For now you’ll be able to read background information scattered throughout the complex, and thereby learn about the story indirectly.
  • NPCs: The only unique NPC you’ll see is Revision 17, who briefly greets you as part of the introduction. Other NPCs will be gradually added as their respective maps become accessible. Some of the new branches already contain non-unique NPC encounters, mostly as a demonstration of things to come.
  • Ambient sound, both emitted from machines and the environment in general. I’ll include a placeholder door sound effect because hearing those is rather important, as well as a couple machine sounds just to demonstrate how they work.

As you can see, most everything “missing” can be considered fluff as far as traditional roguelikes are concerned. There is already a fun and mechanically deep game to play, but it will grow to be an increasingly compelling experience as development continues towards 1.0.

Another point worth making is that balance will be rough at first. This is intentional, because planned content will be used to counterbalance some of what is already there. Currently, unless you really know what you’re doing, you stand a good chance of getting roflstomped around the half-way mark (I still want to do a bit more balancing before release, so it’s possible it’ll get a little easier, but my goal here is not to make an easy roguelike--if there even is such a thing).

Alpha and Beyond

The purpose of releasing the alpha version in its current state, shortly after the conclusion of what I consider pre-alpha development, is to demonstrate the game’s solid foundation and make any necessary adjustments before building an entire world on top of it.

That latter stage will be relatively quick since all the building blocks are in place, but we may want to tweak some of those building blocks beforehand, and large scale feedback has the greatest chance of suggesting meaningful changes. And not just subjective player opinions, either--a wide array of optional metrics will let me know how players are interacting with the game and help guide development in the intended direction. This is something I can’t do myself or with just a handful of playtesters.

The remaining path towards 1.0 is 90% decided by the design doc, but the other 10% is fairly flexible, with additional features beyond the full release also possible.

See the diagram below for a visualization of the game’s current state and future direction:


Cogmind Visual Development Roadmap (click for full size)

As you can see, the vast majority of work to do is world building, which aside from a few little things here and there is mostly about adding maps and whatever other unfinished content they might need. For a more specific breakdown of features to come, see the new roadmap maintained on the website FAQ:


Cogmind Development Roadmap (March 24, 2015).

It’s difficult to predict the long-term time frame with any certainty, because much will depend on how the game is received. There is a minimal “I must do all these things for Cogmind to be what it should” list, and a separate “if Cogmind is popular enough I’ll be happy to run with it and add more” list. The final game probably lies somewhere in the middle, but I can’t be sure which of those features will be added and when, so the indicated times are only rough estimates.

One thing is certain: During the alpha-beta period updates will come frequently. With all the game’s internal moving parts in place, creating the rest of the experience will be a smooth process.

Posted in Uncategorized | Tagged , , | 2 Responses

Cogmind Release Schedule

When Cogmind was rebooted in mid-2013, the intent was that it would be a relatively quick production that would take “about a year” to finish. As we approach the two-year mark, it’s looking like an accurate forecast would have been more than twice that.

Of course, the original plan was to simply make “a polished version of the 7DRL, with some new mechanics.” And that would’ve taken about a year. But it turns out the project had so much potential that it seemed like a wasted opportunity to not expand it further. Thus we end up with a huge number of assets, significantly expanded mechanics, and a bigger world and story to go with it.

Not to offer these up as excuses--I wouldn’t have it any other way! As one follower mentioned earlier this year: “I’m away from Twitter for half a year and you turn Cogmind from something amazing into something I can’t describe!” Drawbacks of having an indescribable game aside, that’s a good summary of exactly why it’s been worth the additional investment =p.

Alpha Access

Development could go on for much longer, but the desire to steer clear of feature creep gets stronger with every passing month. So it’s about time to release this thing into the wild.

Cogmind Alpha Access is essentially a paid early access program scheduled to launch in May.

Setting that deadline has also had the positive side-effect of accelerating development beyond full time (we’re deep in overtime territory now). At the beginning of January I drafted a three-month development plan leading up to the alpha launch, and that plan remained right on schedule except when we ventured outside my familiar territory and into tileset land, mostly due to handling the strong response from pixel artists looking to join the project.

For three months I’ve worked day and night to make the intended April launch despite all the additional tileset-related work, and while we could theoretically still be ready to release by late April, I should probably stop developing at breakneck speed to avoid a complete burnout.

The release is still too far away to set a specific date, which probably won’t be announced until shortly before launch. Regardless, now that there’s a feature freeze in place it’s only a matter of (finite) time before we launch. Much of what’s left to do is peripheral business and marketing nonsense rather than actual game development.

Release State

Just because there’s a feature freeze doesn’t mean the game is complete--the freeze is temporary so we can get this thing out the door in a tested, playable state.

As an alpha launch the game is naturally still a ways from its intended final state. That said, the core experience is there and it’s plenty fun, so you’ll without a doubt be getting something you can enjoy immediately.

All the core mechanics are complete, and you can salvage parts, engage in combat (or avoid it) with help from hundreds of unique components, hack multiple types of machines, and interact with dozens of robots while exploring the “main areas” of the world and a couple of the early branches.

Still to add are environmental sound/music, many more “branch” maps, bosses, more story elements, fluff, and NPCs, plus a few other features that aren’t required but will improve balance and/or the overall experience.

Progress has been reported intermittently throughout the development process, on the website FAQ. The pre-alpha progress chart and roadmap have been replaced by new ones which will continue to receive updates as development continues, as before.


Cogmind’s state for alpha release.

A follow-up post after this one will go into even more detail regarding the state of the game and how it will evolve in future months. (Edit: Post is now up.)

Supporter Benefits

Back to Alpha Access: The obvious primary benefit is access to all alpha release builds of the game, including everything up to 1.0 and beyond, forever. While enjoying the game you can also join us in the forums (not open yet) to help improve and shape its future.

Assuming Cogmind eventually finds its way on to Steam, as currently planned, you’ll also be the first to have access to the game on that platform (via private beta testing before it goes public). In that case, everyone in Alpha Access will receive a Steam key.

Your name (or a name of your choosing) will also appear in the game, but not just anywhere…

Item/Art Collecting

Introducing the ASCII Art Gallery and Item Compendium! The game menu Credits page now includes access to a new area where you can browse the many hundreds of pieces of ASCII art from the game. But, you can only view art for those items you’ve discovered so far. Art and names for items never seen before are listed as “unknown.”

The art gallery also keeps track of an interesting piece of meta info: the total number of times you’ve attached an individual part across all your plays combined. So there’s a reason to open it other than just to look at art.

Where do supporters come in?

Everyone* who joins the Alpha Access program is randomly assigned their own unique personal item from among Cogmind’s huge selection. One supporter per item. Your name (or a name of your choosing) is then forever listed with that item in the gallery (you can of course opt out of this if you prefer). Consider this “adopt a component drive” a chance to be immortalized in roguelike history :D.

I wonder who will get Matter, the most basic and common item in the game, or any of the many rare items that could take a while to discover. Some of you may embark on a “personal quest” to find your item ;). Or perhaps you could enlist help from others…


ASCII Art Gallery and item discovery records (click for full size). As an example I added in names left by some of the blog’s more frequent commenters :D. Unshown is some descriptive text telling you which item is yours (unless you haven’t found it yet) and an indicator of the total percentage of the game’s items you’ve discovered so far.

*Personal items are assigned randomly on a first come first serve basis. If all available items are taken by previous supporters, your name will be added to a waiting list and assigned in order as new items are added to the game, though there is no guarantee that new supporters will have a chance for assignment beyond the existing set of items. If we really have so many supporters that becomes an issue (there are a lot of items), I’ll add a separate scrollable list of every supporter. (I may add that anyway, but it’s not in there yet.)


Alpha supporters who, like me, really want a Cogmind T-shirt also have that option by adding the cost of the shirt and shipping (I’m not looking to make money on the shirts).

I went through a lot of potential design concepts, and most of what represents Cogmind doesn’t work too well on a shirt. In the end I settled on two main designs, the title logo and a (previously unshown) Heavy Battle Rifle in ASCII. I ordered a few samples to make sure the ASCII details would come out alright. They sure did:


Cogmind T-shirt Samples! (click for full size)

Aw yeah, I finally got me a Cogmind shirt--so official :D

Now that I know how this company’s process works and the quality of what they can produce, I may add another design or two later on. (And no, I didn’t try green because high-contrast saturated green doesn’t work so well with ink printing.)

Price and Distribution

The Alpha Access price is set at $30. With a T-shirt (mentioned in the benefits section above) it’s $60, which includes the cost of the shirt, printing, handling fees, and international shipping anywhere. It’s not the absolute cheapest shirt available, but I figure that if much of the fee is the base cost for printing anyway, adding a little extra for better quality is worth it.

Alpha Access sales will only be processed through the Cogmind website. This is better since I can receive a much bigger cut than going through a value-added distributor like Steam. It also helps us ease into sales and gradually scale up, rather than jumping in the deep end with more chances to screw something up on the business side of things.

The price of the final game will be lower, but you’ll have to wait, and will miss out on the other benefits. There is no set time limit on Alpha Access availability--it depends on reception and the pace of subsequent development. The details are also subject to change since I haven’t yet set up the business side of things. Final details will be announced on launch. Feel free to share your thoughts in the comments.

Money Matters

In a perfect world we could all sit around and make and play games all day :D. In the real world (or my world at least), making Cogmind a reality has required that it be my full time job for more than a year now. Otherwise it would simply never see completion (unless 2030 is soon enough to be considered outside the figurative realm of “never”). To clarify, I’m not a young carefree kid anymore--I have a family to care for, lots of bills to pay, and nearly zero free time outside work and other responsibilities. Not to put down any carefree devs out there spending their copious spare time making free games! I did that for a decade myself, and my advice to them is to do their best to take advantage of that opportunity!

I felt that it’s worth it at this transitionary period in my life to take a shot at making something grand, with the hope that the investment could be recovered and possibly fund “other grand schemes” ;). Even if it doesn’t turn out that way, we still get a grand game out of the deal, eh? :D

Cogmind in particular has cost over US$ 25,000 to develop, and I expect total costs could reach $45k or more by the time it’s complete. For those of you unfamiliar with expense budgets behind indie games similar in scope to Cogmind, this is actually a very modest amount. (There will be a detailed budget breakdown at or after we reach 1.0, when such data will be more meaningful.) Based on sales potential, recovering that investment is quite possible. Many will agree Cogmind is a unique quality game and has a good chance at being fairly popular. In any case, with enough support during Alpha Access we can continue to make this game better, and hopefully lead to more like it in the future!


We should probably reach 1.0 some time this year, though the pace of development will depend on Alpha Access reception and feedback.

I may put Cogmind on Steam Greenlight around or shortly after the Alpha Access launch, just to begin some community interaction over there and get the voting started. And because by then we’ll also have our first trailer :D.

Posted in Uncategorized | Tagged , , | 26 Responses

Tileset 1.0

Cogmind now comes equipped with an official tileset!

Originally we were aiming for two tilesets, one symbolic and the other realistic, but despite the promising concepts provided for the symbolic set, the artist unfortunately turned out not quite suitable for the position. With that we are down to a single tileset, though one with which I’m extremely satisfied.

Kacper has done an incredible job on the realistic set, going above and beyond simply following the specifications by coming up with a number of great ideas and suggestions that have improved tile mode’s overall visual quality while keeping within our limits. It’s been a pleasure working with someone who’s as into the game as I am :)


Position filled, credits page updated :D

Symbolism vs. Realism

We showed pre-development tileset concepts in a number of different places, and a majority of responses were in support of the more abstract “symbolic” tileset, essentially taking the essence of ASCII and putting it into tileset form.

It’s too bad we won’t see that tileset come to fruition (at least not for now), though there is some consolation to be found in various other factors for consideration:

  • More than one of the prospective artists I consulted with during the hiring process made a valid observation, stating that “some of the symbolic sprites don’t clearly represent anything.” Ignoring the fact that this is in some ways the very definition of symbolic, it’s true that in an unfamiliar fictional world it is sometimes necessary to create unfamiliar new symbols that the player then associates with new objects. In a complex enough world and at small enough sizes, these symbols can begin to seem arbitrary and opaque, making interpreting them somewhat difficult for the same category of player that has trouble with the highly symbolic nature of ASCII in the first place.
  • The question as to which tileset concept is superior was directed mostly at audiences already familiar with ASCII and traditional roguelikes. Players at the edge of or outside that circle generally preferred one of the non-symbolic concepts.
  • All early feedback was also based on rough concepts created by artists with minimal guidance. Any of the concepts could become much more than their original form, as you’ll see below.
  • A portion of the players preferring a more efficient symbolic approach to the map can simply use ASCII (as many will). I’m confident that Cogmind is, after all, the most accessible ASCII game ever with a vast array of UI features to aid usability, among them auto-labeling. Objects are also represented using very uncomplicated symbol conventions and a relatively small number of glyphs--common objects use only 9 punctuation marks and 24 letter glyphs (counting upper and lower case as separate glyphs).

Against this background it would seem that the ideal tileset should be as different from ASCII as possible--non-symbolic, detailed, realistic.

For me as the designer, however, this exaggerates a problem I’ve been dealing with every time I think about Cogmind having a tileset: any pixel art representation runs counter to the intended look and feel of the game. As regular readers know, Cogmind’s entire aesthetic and theme embraces the ASCII rather than using it as a makeshift crutch. You are the Cogmind, and that’s how you see and experience the world. Many of the map and UI special effects rely heavily on ASCII, and the intro, inter-level animations (still WIP) and ending (WIP) are rendered entirely in ASCII as well.

Sure it’s a game, but as part of the design philosophy I’ve made an effort to avoid anything that overtly gamifies the experience. I didn’t even want the game to have a title screen--as it turns out there’s still no start menu (nor will there ever be one), but I did finally cave on the title screen part…

I know, the game has both ASCII and tiles mode, so why fret? I’m sure it’s a bigger issue to myself than anyone reading this blog, because as players most of you see Cogmind as a game. To me it’s art. I have a vision for this piece of art, and feel like I’m sacrificing part of that vision to expand the appeal of the underlying game.

Of course a number of players out there also subscribe to the game-as-art-form mentality, especially in the indie world, and the appreciation of art is always a very personal thing once it’s released into the world, anyway. By providing a tileset I suppose I’m simply giving the audience another tool with which to appreciate it, even if it does significantly affect the intended expression.

While in the future this dilemma will always exist whenever I have to decide how to prefer to present Cogmind, I can at least say that after some days playtesting with this new tileset, it’s awesome, and certainly doesn’t reduce the game component’s awesomeness :D


The non-symbolic representation of map objects should have both meaningful detail and a consistent look, and given the limitations this tileset does a wonderful job of both.


A sample scene showing the tileset at its smallest (12×12 cells) and largest (24×24 cells).

Kacper has squeezed an amazing amount of detail into a tiny area. Robot compositions highlight their primary features and functionality; item forms reflect their categories and subtypes while remaining distinguishable from one another when necessary. How does he do it?

Before getting into analysis of specific object types further below, the short answer is by focusing on a simple shading scheme. At the small sizes required, softening tiles with excessive shading costs too much space that can otherwise be used to define details (an even more significant limitation without multicolored tiles). By contrast, this tileset uses a mere three shades:


Grayscale ramp from Cogmind’s tileset. The detail!

As you’ll see with the robots and items, these shades aren’t used to create any kind of gradient, instead being assigned as a primary color vs. detail color. The result is extremely sharp sprites that pack a lot information into a small area, and also mesh well with the sharpness of the UI.

One drawback we’ve discovered to relying on such a simple monochrome color ramp is that while on the perfect hardware the darker two colors are nicely distinct from one another, they appear much closer on lower-quality LCDs, causing sprites to lose some of their internal contrast. Correcting for this on one setup results in less than ideal viewing conditions on another. The current ramp is best displayed on high-contrast monitors with true blacks. Hm, as I write this I’ve begun imagining some kind of adjustable gamma option that changes the actual ramp itself, allowing the player to set relative brightness of each spritesheet component to whatever looks good on their particular monitor…


Machines were outside the scope of the original tileset specifications. As mentioned before, I’d be okay with mixing ASCII machines with a minimalist tileset, though Kacper decided to tackle the issue, anyway. The result is quite promising, and does a good job of pixelizing the machines such that they fit well alongside our other map sprites.


A comparison of non-interactive machine ASCII originals vs. their pixel version created using one-to-one glyph substitution.

The effect works well enough with non-interactive machines (the gray ones, seen above and as described earlier).

However, because interactive machines are often both smaller and use more outward-oriented designs than non-interactive machines (whose designs are larger and inward-oriented), that subcategory doesn’t look nearly as good. This is cause for some hesitation in making this change permanent as is. A redesign of the base ASCII glyph arrangement would resolve the issue, but also might result in a less effective ASCII version.

Either way, the spritesheet has already been expanded to allow for an alternate set of ASCII line glyphs specifically for machines (the original set was still needed for UI elements that use the map font). For anyone who would like to use tiles but prefers the basic ASCII machines (not yet sure if that type of hybrid player even exists!), the config file does contain that option.


More work went into the terrain than I initially expected. At first I was thinking “okay, we’ll just replace the hashes with one of a handful of wall tiles and that’s it.” It’s not quite that simple, though keep in mind we’re still not doing linked and oriented walls--they don’t really add anything for Cogmind, in which terrain is incredibly simple and the focus is on tactical layout (plus oriented walls can unfairly give you too much information).

The first unplanned change is the removal of ASCII dot/period floors. They are replaced with a faint gray rectangle representing the floor section, and do a good job of reducing visual clutter when the general noise level has already been increased by pixel art.

I hadn’t considered the possibility, and even imagined it might be incompatible with the particle effect animations, but Kacper dropped it into the tileset so I figured I may as well try it out. I like it. Tests show that it is not only perfectly compatible the hundreds of existing particle effects, it even enhances some of them.


See the floor tiles highlighted by these UI animations, the red volley rangefinder and the green launcher AOE scan.

Strewn about on lower levels, and blown off robots and machines to slide across the floor, you’ll often see mechanical debris:


A roomful of mechanic debris in the aftermath of my reckless rocket rampage. Oh look, here comes another to join the scrapheap…

The tileset contains 16 debris tiles in all, one for each of the possible gray background ASCII debris symbols. Both the tiles and ASCII debris punctuation are organized by their pixel density so that areas of debris created by a noise function will look a little more natural.


Tileset debris, with corresponding ASCII for comparison. (A couple of the ASCII may seem out of density order, because that order is based on a multi-font average.)

The most prominent terrain feature, walls, required the most tweaking of any tile type despite their relative simplicity. Adjusting them also required making the tileset’s only deviation from the standard color ramp described earlier.

The issue stems from the tileset coloring system, which draws directly from the colors and levels assigned to the ASCII, all fully saturated colors with a specific brightness level (usually fairly bright).

Wall ASCII universally use the hash (‘#’) symbol, which naturally has a lower pixel count than any wall tile. Thus using the same color for ASCII and tile walls means the latter will require a lower brightness to avoid overpowering everything else on the map, especially since wall tiles are almost always the most numerous visible object. As explained in the original tileset specifications, this is easily achieved in the spritesheet by using a non-white color. So the original grayscale ramp (which uses pure white as its brightest color) needs to change a bit for that. (For the record, Kacper didn’t like the idea of deviating from the ramp, but was a good sport and understood that it had to be done for the greater good =p)

The brightest wall color was therefore lowered from gray 255 to 225, so from 100% brightness to 88.2% brightness. But that doesn’t go far enough to produce the best wall effect for the map as a whole (Kacper cringes). Honestly I really like the walls at their original sharpness, but that detail is at the same time distracting when it’s repeated across the map. We needed to reduce the contrast on those details to help other objects stand out more. So I progressively raised the brightness of all the darker colors to tighten up the color ramp and make it easier to focus on objects other than walls.

You can see the testing process below, taking the factory walls as an example:


Tweaking the grayscale ramp for walls.

If the change seems subtle to you, it’s more meaningful when trying to play on a full-sized map with other objects mixed in that you’d prefer to be focusing on. This effect is even more pronounced at larger tile sizes.

As for unique walls, currently there are only six types--wall variety is a good bit less than the number of map types, because some maps simply use recolors (e.g. for the same general area and theme but still different in some way). Not unlike other traditional roguelikes, Cogmind is not about terrain--it’s about interacting with the occupants and objects found among that terrain. There are (and will be many more) interesting environments, but they are created primarily from machines. Walls are merely barriers to influence tactical positioning, and tentative ones, at that, since you can always blast your way through them to forge new pathways :D. (Note: Always consider what may be on the other side!)

Compared to walls, doors were left completely unchanged from their original ramp, since we want those to stand out--they even use a bright pure orange to achieve that purpose. So we get to keep their juicy crisp details (Kacper sighs in relief). Same with stairs and branch access points.


Heading through a door to find an exit. You are going to be really happy to see one of these in game, because finding them is your primary objective, but not always that easy.


When I first saw Kacper’s robot concepts I thought to myself, this could be Cogmind! It wasn’t the same feeling I had with the other tileset concepts, which could at best be classified as “okay, this could possibly become Cogmind with some work.”

Some viewers might claim the robots are too intricate, with pixel-sized details too small to clearly make out, and this is certainly a valid point (as valid as any opinion about works of art--some of us can make out the details when we stop to inspect them for fun :D).

Most importantly, the tileset is designed such that you don’t have to focus on the details to distinguish robots from one another. Each robot highlights its important features to define an overall shape that is usually unique to that robot. This is not especially difficult with Cogmind’s robots in particular, because each robot must be unique in its loadout and behavior in order to exist in the first place. There are no “this robot is just like that one but with a different gun” situations.

See the cast of early-game combat robot classes that haven’t changed since the 7DRL prototype:


The prototype’s combat robots have all grown up and got sprited!

The many new additions have even more unique appearances. And of course the non-combat robots with their especially unique behaviors look completely unlike anything that you fight. Plus they’re all green. Regarding other colors, combat robots appear in yellow, orange, or red depending on the threat level of that particular variant; NPCs are pink so they really stand out; and there are also gray and brown robots, but those belong to a category you’ll have to discover in the game.

In any case, the robots above are fairly easy to distinguish, even more so when you see them in action because they are both labeled directly on the map and have their own unique weaponry or other behavioral differences--for example Swarmers always travel in big groups, Sentries always work alone, Watchers zip around sending out alerts without shooting anything at all, etc.

Notice I’m not showing the Behemoth here, because it’s now four times as large as any of these… nope, not going to mistake that for anything else!

What I like most about these and the many other sprites is that they accurately depict a cold mechanical world of robots, and at such a small size! The sprites even properly reflect a given bot’s size and loadout (mostly regarding propulsion and tools/weaponry, though sometimes even extending to additional components).

How do they do it?

First of all, the three-shade limit mentioned before is a very useful restriction here, as fewer shades enables sharper images, which means greater detail.

On top of that the robot sprites use a 3/4 oblique right-facing perspective, which is the best way to increase the variety of recognizable features that can be depicted. Forward-facing sprites leave a lot less room for variation, and work better with multi-hued tiles (which we don’t have in Cogmind).

Each visible side uses one primary shade plus a secondary shade for detail (with each side sharing a shade, for a total of 3):


The tri-shade Grunt as it appears in the spritesheet, x10.

Of course at the smaller tile sizes the detail only helps if you want to examine individual units up close, when during normal play all you care about is what is where. So at the same time we tried to give each robot a fairly distinct shape to aid at-a-glance recognition, as explained earlier.

Most interestingly, while you might expect that we’d leave some room in between robot tiles to keep them separate on the map, we didn’t! Robots are allowed to utilize the full width and height of their cell, so 12×12 in the base tileset, and the understanding is that the perspective shading helps you visually identify where one robot ends and another begins. The extra column and/or row of pixels to use for the robot itself gives more room in which to clearly define a unique shape, with a wider stretch of shaded edge where useful.


Robots’ perspective shading aids visual separation on the map. Here I’ve let myself get surrounded for screenshot purposes--don’t try this at home, kids. During combat you can safely ignore anything that’s green, and this particular scene simultaneously contains all four types of combat unit seen in the introductory levels of the game: To the north a pair of incoming grunts along with three surveillance bots happening by (quite rare, actually), and to the south a group of Swarmers flying around a Sentry.

Sure you can end up with dense, broad clusters of objects requiring a little extra time to thoroughly parse, but this is an issue even with ASCII. The point is it’s not incredibly difficult once you’re at least familiar with the individual objects. We’ve playtested it and are satisfied that it works just fine.

(I’ll also add here that if you really are staring down a massive group of enemies in Cogmind, you’re not going to care so much about its composition--you’ll instead do one of two things: run, or point your guided nuke in that general direction and kiss them goodbye… after which you will then probably run anyway because firing a guided nuke tends to piss everyone else off =p)

That’s it for the robots--there are quite a few more cool ones in there, but I’ll leave those for you to discover!


Considering how tiny the items are, Kacper did a great job making them individually recognizable while ensuring that related subtypes share certain qualities. Because there is only one category of items that you won’t find almost immediately in the game, these I’m mostly free to show you now without spoiling anything big.


(Most of) Cogmind’s item types in their uncolored spritesheet form, both at 12×12 and 24×24.

  • Matter and Data Cores are unique items that you’ll be seeing frequently.
  • Propulsion: These are quite distinctive, and each does a good job of resembling its type, for the most part also taking the same form in which they’re used on the robot sprites.
  • Utility: “Devices” is a pretty vague all-encompassing category, so it gets an equally vague sprite. Storage is quite specific by comparison, and appears appropriately box-ish. Processors and hackware are essentially two varieties of the same thing (small chip-like components), so they look similar but not quite the same because the player may or may not be interested in hackware at all. A large portion of protection utilities are armor, hence that riveted piece of metal.
  • Power: The sprites here reflect power source progression itself in that these subtypes are simply increasingly powerful versions of the same general thing.
  • Weapons: Cannons are larger, and energy vs. ballistic each have their own unifying characteristics. The launcher is a monster of a weapon in a size of its own, giving it that extra HELL YEAH feel when you find one (they are quite nice to have). Special weapons are usually tools and whatnot, so they look a bit more functional. Melee weapons (including the datajack), share a basic form but all remain distinctive.

Unlike robots, item sprites are actually colored differently from their ASCII counterparts. ASCII uses glyphs to represent a category and further distinguishes the subtypes within each category by color. This is more efficient for interpreting ASCII map data, enabling the player to quickly locate all items of a particular category (say, all the ‘=’ are types of propulsion) rather than differentiating everything equally at the subtype level; there are also not enough punctuation marks for 27 item subtypes, but plenty of extra if we do it this way. It’s the least confusing way to take advantage of the ASCII representation.

Because item sprites each have their own unique form, we are free to use color however we need to. Thus items are instead colored by their effectiveness rating. Each item is manually rated by how effective it is on a scale from 1~10, and colored appropriately on a sliding color ramp from cyan to purple to crimson. These colors have the advantage of being different from those used for any robots, so you can pretty easily tell the difference between an item and robot sprite even before examining their shapes.


All the treads in the game as they appear on the map, from the lowest-rated Light Treads to ???.

Using multiple colors for these may not be worth the added visual clutter, and to reduce confusion I’d consider changing all items in tiles mode to cyan or purple based on player feedback. (After all, this extra information is not available in ASCII mode, and it’s not a problem there.) I’m not particularly bothered by it, but it’s something I’d like others to weigh in on once they have their hands on the game.

(Color scheme exceptions: The common matter item is always purple, with a brightness based on how much matter is located there; data cores are always green.)

Besides their color and generally smaller size, item sprites are further differentiated from robots by their facing/shading. Notice that items are left-oriented, another good idea by Kacper.


Using the tileset certainly changes the feel of the game, which is somewhat hard for me to get over, but I do love it for what it is, think it handles itself well despite the limitations, and after playing with it for a while I must say it’s starting to grow on me.


Some (true) playtesting with 12×12 tiles. I just found me a ROCKET LAUNCHER. Splash damage be damned, you’re all going down.

Currently this tileset has only been developed at the base size, 12×12 cells, while other sizes will be extrapolated all the way up to 24×24, the 1440p dimension, without additional detail. Thus the relatively tiny size you see above actually applies only to those of you using a 1366×768 desktop (720p). Greater resolutions will be using larger versions of the tileset and have a slightly low-res appearance, working in the same way as previously shown scaled fonts.

A comparison of the two extremes, showing the same scene from Cogmind as it would appear in 720p vs. 1440p:


Cogmind tileset in 720p. (Screenshot taken in a 4:3 window, so the interface is not set to its true 720p aspect ratio--demonstration for tile size only.) Click for full size.



Cogmind tileset in 1440p. (Screenshot taken in a 4:3 window, so the interface is not set to its true 1440p aspect ratio--demonstration for tile size only.) Click for full size.

Regarding even smaller resolutions (e.g. 800×600), the game also supports those, but as this particular tileset can’t properly be scaled down they are currently ASCII only.

So you’ve finally reached the bottom of my 4,000-word Great Wall of Text intro to the tileset… What do you think?

Posted in Art | Tagged , , , | 35 Responses

Map Intel: Information Warfare, Revisited

We’ve covered information warfare on the blog before, in terms of the wide array of components and UI options available to Cogmind. Those features are centered around information about robots and other objects visible, seen before, or detected via sensors.

There is a separate category of useful information, and its source and presentation were the final front-end mechanics to be implemented before Cogmind’s first release. This category has been dubbed “Map Intel,” referring to information about the environment obtained through hacking.

Some of these features were added a while back along with terminal hacking, though before now there was no system for translating them into useful map information. Now that system is fully operational, and useful it is.

Hacking for Intel Markers

In short, you can now hack terminals to obtain position data for different kinds of objects. After a successful hack of a given type, the associated “intel” is displayed directly on the map as ASCII glyph markers at those positions.

Off-screen intel markers are shown at the edge of the map view in the direction towards that object, dynamically repositioning themselves as you shift the view. (This system works like the labels for off-screen exits demonstrated earlier.)


Various types of intel markers repositioned as the map shifts.

There are a number of different intel marker categories.

Machine Locations

If you’re looking for a particular type of interactive machine, you can hack for a list of their coordinates.


The full list of hacking commands for retrieving machine coordinates. (The generic “machines” command simultaneously hacks the locations of all machines--difficulties are not set/balanced yet, and here I have some hackware equipped which modifies the chances.)

As marked on your map, these are represented by capital letters with a background that glows in the color associated with that machine:


Intel markers for two Terminals, two Recycling Units, and a Repair Station, all to the north.

The machine intel system works slightly different from the others. Intel marker data is usually deleted once that marker enters your FOV (i.e. once you’ve explored that area , or otherwise seen it again since last hacking for that intel). This is because most intel is aimed at moving objects, so the information becomes outdated and useless before long, anyway. Re-hacking for the same type of intel will also replace and update all old intel of that type.

As static inanimate objects, however, machines are not removed from your intel on seeing them. Even after leaving sight of a machine, the intel remains. Moreover, those machines you simply see (not hack) to discover are also added to your intel database. Thus all previously seen machines can be conveniently indicated along the map edge. Sure, even without this option you can always still shift the view and see them in previously revealed map areas, but having directional markers is a useful reminder of which direction to look.

Tasked Squads

Groups of robots with a permanent task or one-off mission are marked with lower case letters, placed at their most recent reported location. The marker background color indicates how much you should worry about a given squad: green or yellow for non/low-danger, orange for common threats, and red for major threats.


Registered robots passing through a previously explored area--one surveillance unit (v), two patrols (p), and three maintenance bots (m).

Here is an example of the hacking shell’s output on obtaining the latest coordinates of all patrols on the map:


Results of a successful patrol status hack.

While the fact that almost all squads are mobile reduces the usefulness of revealing positions of distant squads (except for those likely coming to track you down), it does at least show the overall types and composition of potential enemies out there and where their strengths and weaknesses are generally concentrated at a given point in time. More useful is the ability to discover what squads are nearby, and in this way squad intel is an alternative to the usual sensor combos, providing temporary information but at a much greater range.

There are currently nine different types of squad, but I’ll leave the details for you to discover in game. I will mention that hacking positions for security squads is one of the most difficult, as those squads are stationary and knowing their positions across the entire map is incredibly valuable. That’s the kind of information generally only available to dedicated hackers.

Stockpile Inventories

Component stockpiles are marked with their usual punctuation glyph based on item type, also coloring their background based on that type. (Stockpiles containing prototypes are further differentiated by their glowing foreground.)

However, know that stockpiles often contain more than one type of item, as well as multiples of each. To keep it simple (both for the UI, you, and I =p) the system records stockpiles based on their most abundant component, or if there are any prototypes those will become the primary stockpile identifier. So while you can’t know the precise full contents of a stockpile, you can know what it’s mostly comprised of.


A list of common (non-prototype) stockpiles stored on the map, followed by a failed attempt to retrieve the same for prototypes.

This intel can be very useful for determining whether you simply want to leave a map, or stick around to get that stockpile you just learned about in some nearby room. Especially if you see a stash of unguarded prototypes for the taking!

Intel Filters

So what happens if you really like hacking and turn your map edges into a completely unreadable mess of letters and symbols?



I don’t imagine you’ll want to keep a large amount of intel visible at once, instead activating only those that are relevant and current.

For that the intel system has a new filter manager, implemented as the last multi-console mode. If you recall, the top-center portion of the UI is dedicated to the so-called “multi-console,” which has multiple modes for optional features you may activate depending on what you need at the time. There are four modes: extended log space, combat calculations, the ally status and order system, and now intel management.


The multi-console area.

This scrollable console lists all the types of intel you possess for the current map (it always contains a listing for machine intel, since that can be obtained without hacking). Each type of intel can be toggled individually, or all at once via the “ALL” button.


Toggling intel data types for display on the map.

As with the ally management interface (and every other part of the interface), these filters are accessible via keyboard: Just press ‘z’ to enter intel mode, then the number corresponding to the type of intel to toggle.


“Intel mode” for keyboard input.

As an added convenience, newly hacked intel for a given type of object is automatically activated so you don’t have to worry about remembering what intel you acquired after a hacking session.

Style Considerations

For intel markers we obviously need a compact and distinct style easy to distinguish from other map objects since they’ll be persistent (while active) and placed directly on the map.

Fitting each marker into a single cell is naturally the best method of indicating something at that position, so the choice is simplified to one of which ASCII and how to color it. The initial concept was to go with a black character on a colored background, which if you’ve noticed is how the interactive piece of machines is normally represented on the map. So further differentiation is achieved via slow oscillation in background brightness. This helps them stand out from the rest of the (static) map more than anything.

Due to a variable typo in the initial test, the black characters appeared white the first time I saw them. After testing both methods it turns out the white look is better =p. White results in easier to read glyphs, being consistent with the light-on-dark look of the rest of the map, while having no negative impact on the markers’ differentiation from other cells (since we have the glow-highlight effect).


For the past year or so the concept for the final multi-console mode was actually called “signals,” and looked like this:


“Signals” multi-console concept (mockup).

The idea is the console is normally filled with junk data representing encoded transmissions Cogmind is picking up from the environment, and you could attach components capable of deciphering what other robots in your vicinity are thinking/planning, as well as whatever other information can be intercepted, including the number of enemies currently tracking you.

While fun, intel filter management offers a much broader range of possibilities, and serves as a bridge between the terminal hacking system and map overlays (which could even be further expanded in the future). The signals idea could technically still be added, though it might end up being too complicated a mechanic (?).

For now we’ll relegate it to the list of many (though fewer than there probably should be) cut features.

More Terminal Hacks

Along with the intel update we’ve also got a new batch of useful terminal hacks.

Local Map Layout

Like hacking for squad positions, this option is an alternative to relying on sensor data (in this case terrain sensors and interpreters). When successful, this hack reveals the map layout for the zone in which the terminal is located.

I also coded a hacking command that reveals the entire map layout rather than a single zone, but it’s far too powerful and will only be available under special circumstances (once I decide what those circumstances are…).

Hacking the map layout does not, however, reveal secret tunnels and doors. As protected information those are available only via another specific hack.

Exits and hidden doors are not part of the intel management system, since they have their own labeling system described earlier. But as part of the intel hacking update, newly discovered exits and hidden doors are auto-labeled as soon as you close the hacking interface:


While testing the new hacking system via a test terminal, I happen to discover a hidden door right next to me ;).

Alert Level

I still haven’t covered this game mechanic yet because it ties into the world as a whole, but for now know that the global alert level affects how the enemy reacts to you.

You won’t generally know this alert level, but 1) you can guess when it’s on the rise because the enemy will start taking you more seriously and 2) at a terminal you can also hack to learn the current level.


Retrieving the current alert level, which can range from “low security” to 1 to 5.

On the more useful side, if you’re a good hacker you can proactively lower the system’s alert level by falsely reporting that a threat has been dealt with, reducing the likelihood of more combat-enabled robots arriving in the map on various threat-related missions.

Squad Recalls

Beyond simply retrieving squad dispatch records and hacking for their latest position data, you can attempt to issue a recall order to any combat squad only temporarily in the map for a given mission. Call off investigations, strike teams, and even larger assault forces if you’re good enough (and reach a terminal in time).


You can’t recall squads which are permanently stationed on the current floor, but there is a new alternative for influencing them: Sabotage. With this hack you search the machine control network for vulnerable explosive machines, and overload them remotely. The former machine’s location is marked on your map via the intel system, and the enemy will redirect a permanent patrol or security force to that location.


Detonating a nuclear reactor remotely (top), then later surveying the intel marker’s position (bottom). There was obviously more than one reactor housed in this area--the massive explosion cleared out several rooms worth of space. Would have been fun if it were in the room next door (okay, maybe two doors down…) so I could hear them go off :D. It obviously took out some combat robot, as there’s still a weapon lying on the ground nearby.

This is a fairly easy hack because you cannot completely control the effects--the vulnerable machine is chosen randomly from among those which may explode, the system itself decides what squad to relocate, and the overload may even fail to destroy the machine despite successfully hacking its system. To improve the strategic value of this hack I later went back and gave the system a much higher chance to relocate the squad nearest your terminal, so theoretically it becomes an effective option for clearing out dangerous areas without any fighting. In any case, sabotage is certainly a fun option--blowing up a reactor somewhere else on the map and later happening across the debris and a crater in the floor (if it hasn’t already been cleaned up by then). Chain reactions are common and the resulting explosions can easily catch enemy robots passing by ;)

Warning: Going on an unchecked sabotage spree will most certainly raise the alert level and summon a whole lot of new friends to play with… or maybe that’s what you want? :D

Posted in Design | Tagged , , , | 8 Responses

ASCII vs. Tiles

Ah, a visual dichotomy not nearly as old as roguelikes themselves, but nonetheless of great significance today.

While a game’s visual style need not always be rooted in its underlying mechanics (especially the case with traditional turn-based roguelikes), the choice between an ASCII or tileset map representation obviously has a major impact on the experience. And that impact occurs at a deeper level than “oh this looks better than that,” affecting even the efficiency and precision of decision-making itself. Not that any individual preference for ASCII or tilesets is right or wrong, or one is inherently better in every way. Each representation has benefits and drawbacks, and to suit all types of players many popular roguelikes have the option of using either, as will Cogmind.

The Good and the Less Good

This discussion doesn’t seem entirely necessary given that Cogmind will be both ASCII- and tileset-enabled, but the topic also serves as a background against which to explain the choice for Cogmind’s primary tileset.

So what’s so good about ASCII?

We can’t look to roguelike origins for the answer, since early usage was born of limitation rather than free choice. To an extent we can attribute ASCII’s modern relevance to tradition, continuing to use it because those who came before did the same. But the choice to use ASCII (as now it is a choice) must be more meaningful than that, because traditions that have lost their meaning tend to die out to be replaced by more meaningful approaches.

It turns out ASCII is actually quite practical, with a number of inherent benefits that are difficult or even impossible to replicate with a regular tileset.

Certainly ASCII’s purely symbolic approach appeals to players who enjoy experiences more reliant on the imagination, but that feature is more a factor of personal preference. Here I’m interested in comparing the technical qualities of ASCII vs. tilesets that can be used to inform the tileset selection process. From another perspective, simple symbolic glyphs help distill information for tactical decision-making into its purest form--i.e. with no “superfluous visual distractions.” In that respect my initial vision for a future tileset when starting Cogmind was something akin to “icons” in their simplicity.

ASCII also benefits from the fact that we can leverage years of experience distinguishing a very specific set of symbols to identify them even when densely clustered and/or at small sizes. Our eyes are already well-trained to parse alphanumeric information--all that’s required is learning to associate symbols with specific objects. After learning those associations, visual information can be absorbed both quickly and with a very low chance of error. This is even possible using ASCII fonts only 7~9 pixels tall.

Tilesets simply cannot do this to the same degree of readability, so our “training” obviously has its advantages. Unfortunately that benefit is at the same time ASCII’s biggest disadvantage. Those years of training also apply to the glyphs’ meanings, which we must re-associate with a new meaning in the context of a game. Many players have difficulty making that conceptual leap, preferring instead to associate new meanings with new representations (or in many cases representations based on similar previous representations that are already familiar for that same object--e.g., a drawing of an orc rather than an ‘o’).


A comparison of Dungeon Crawl: Stone Soup ASCII vs. tiles mode (a similarly crowded but not identical scene). Assuming you know what the symbols represent, the ASCII here is far clearer despite showing 50% more creatures, and doing so with less space overall. As an aid for beginners, a symbol key is provided at the side of the ASCII window (not shown).

Interestingly, the process of learning and using a new tileset is somewhat the opposite of ASCII: the association step is fairly easy, while differentiation can be more time consuming, especially when dealing with numerous smaller pixel sprites.

In the above DCSS example, without help or experience we have little idea what those letters mean, while we can pretty easily guess what most everything is in the tiles version. However, it is highly likely that anyone equally familiar with both systems will take a moment longer to read the entire situation on the right compared to taking in most of the information provided by the ASCII. The difference might be mere milliseconds, but that processing time adds up with every turn, more so when taking actions quickly and many creatures are moving around.

At least the tiles are fairly large at 32×32--the smaller the tiles the greater the lag, while ASCII doesn’t suffer that same problem.

Of course, compared to the task of parsing and differentiating tiles, associating letters and numbers with objects is generally harder because it is less based on prior knowledge (roguelike ASCII conventions aside), thus the average player will always choose to play with a tileset.

Tiles also have the benefit of increased pixel space and freedom to convey more information than ASCII, and a well-designed tileset can overcome many of the readability issues, or at least make up for them in other ways. In any case, unless they’re incredibly simple (e.g., not DCSS tiles) they still can’t beat the readability of alphanumeric glyphs displayed against a solid black background.

In that context, let’s analyze some Cogmind tileset concepts…

Tileset Concepts, in Game

I took the most complete and promising concepts originally submitted here, and dropped them into the game to see what they look like in action. This is an opportunity to see them in color as well as how they work together as a whole. Some things to note:

  • None of these are the original submissions you saw in the tileset poll. They are subsequent updates based on feedback the artists received either from me directly or from reading my discussions about the art direction with other developers (it continues for about four pages, and gets increasingly detailed). I didn’t ask that anyone provide additional samples, but each proactively updated their set to more closely match the style and needs of the game.
  • Don’t bother comparing glyphs between different tilesets for what they are. The tileset concepts being only samples, in most cases there were not enough sprites to go around, so I sometimes simply applied sprites to completely unrelated robots or objects just to get them in the map for viewing.
  • The images below are small excerpts from possible scenes that can occur in game. The left side is from the beginning Materials floors; the right side is the Factory. (7DRL players will remember the names of these areas, though their contents have changed significantly since then.)
  • Notes specific to some sets: Artist F provided no items, so they are all left blank (the empty spaces); Artist P provided only one item (a key, which actually doesn’t exist in Cogmind), so I used that as a substitute for all items.

Cogmind tileset concepts, as they appear in game (click to open full size).

Assuming the goal is readability, we want something that shares the clearly defined and easily distinguishable shapes of ASCII. This implies a need for less detail, though we can retain some inner detail since the monochrome requirement helps make it more apparent where one object ends and another begins when in close proximity on the map. (Incidentally, regardless of the tileset, monochrome sprites reduce the map’s visual noise overall, a useful feature that makes use of one of ASCII’s inherent advantages.)

My analysis comes as 20/20 hindsight because honestly I didn’t realize all this when advertising for an artist, otherwise I could’ve used the information to give applicants more guidance for their initial concepts. At the time I was still unfamiliar with the best practices of using a tileset that can mimic ASCII’s look and feel, and was even unsure if that’s what the ultimate goal was! I suppose this demonstrates the value of having concepts to analyze and draw conclusions from in the first place.

My take on each of the concepts above:

  • [A]: The original A concept looked great on its own, and was noticed by a good number of roguelike regulars commenting on the tilesets. However, there were some dissenting voices that this and other similarly shaded tilesets were not “Cogmind” enough. I’d have to agree. The revised “ASCII-fied” version reduces the shading and does seem more appropriate, but loses a good bit of its appeal as a result. Its heavily line-based appearance makes it more difficult to read individual objects on the map when bunched together, as lines tend to stream into one another in adjacent cells. The seamless blending of the Factory walls is excellent, though I think for Cogmind we’ll probably be going with discrete wall segments.
  • [F]: The version of F shown above is completely different from the original concept, switching from what was a stylized version of my original 7DRL tileset to something more unique. Compared to other shaded tilesets, this one handles the shading better because it has more room to do so, using a surprisingly large number of the pixels for each robot (in many cases leaving no rows or columns completely empty). It has both detail and easily recognizable form. (Note that Factory wall might have been intended as a door, but I used it as a wall for now--overall the walls are less important where concept comparisons are concerned, because Cogmind’s terrain is far simpler than other objects and doesn’t require nearly as much variation.)
  • [L]: This is a contentious tileset. In its original form, which lacked shading, commenters either praised it for its uniqueness or directly opposed it as a jumble of pixels. The new version vastly improves its readability through effective but not excessive application of shading. I love this set for its detail, though once the number of sprites is increased beyond what you see here it could become necessary to pay attention to that detail in order to differentiate objects, making the set overall somewhat less readable. Playing Cogmind often requires that the player interpret large groups of sprites, and this set does not seem as suitable for that purpose.
  • [P]: The original concept for P was rather dark and went unnoticed by many, though I saw potential in its form. Sure enough, the artist later provided a brighter version that really stands out from the others. Rather than use lines and pixels to convey detail, P relies on thicker shapes with recognizable outlines. Much like ASCII, their contiguous form does an excellent job of keeping individual sprites in one piece and enables them to be distinguishable even in dense groups, very much like ASCII. Solid walls separated by space also do a good job of translating the ASCII look and utility into tileset form.

Cogmind Tileset

If we focus purely on readability, tileset P is without a doubt the top choice--it’s the most icon-like and preserves many of the advantages of ASCII. However, to me the style doesn’t quite feel like Cogmind. The only other tileset here to emphasize a solid cohesive form is F, and I also quite like its appearance, which aligns more closely with my vision for what the world actually looks like.

At their current scope, neither shows enough to be sure of which would provide a better final product. It remains to be seen how effectively each style can be expanded to include a variety of robots and other objects without resulting in too much similarity. Also, neither shows how well items fit into the style. The map objects we have to consider for Cogmind’s tileset are basically just robots and items, so we’re essentially missing half the picture here.

Therefore I’ve chosen to hire both artists, F and P, to do a complete tileset at only the base 12×12 size, then from that determine which to use as the “official” set and further expand it to all tile sizes. Now that we’ve made a decision, welcome to the team Kacper Woźniak (F) and Austin McGuire (P)!

It is also possible to expand both tilesets to the full size range, or even hire additional artists depending on the results of these first sets. We know that different players enjoy different visual styles, regardless of readability (a definition which can very somewhat from individual to individual, after all), so I hope to have the opportunity to provide more tileset options for those of you who will use them. Please leave comments on the sets I’ve chosen, or any of the many others that weren’t.

I can also imagine some interested players will eventually add their own tilesets, because they’re very easy to add and don’t require a huge amount of work.

For now, check out what these look like in action--disregarding the fact that not all objects resemble what they actually are, and some are duplicates ;).


Tileset concept F, in game. (Remember this one’s missing items completely.)


Tileset concept P, in game. (Remember this one substitutes a single key icon for all items.)

Posted in Art | Tagged , , , | 20 Responses