Official development blog

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 , , , | 4 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

Web Support in Single-Player Roguelikes

While we often think of single-player games not requiring an internet connection, and certainly many of us do play our roguelikes offline, there are advantages to implementing optional online features in a roguelike.

Browser games, or roguelikes that require a persistent server connection to handle gameplay/content, are beyond the scope of this article. Those are also more likely to be real time or multiplayer (i.e. “less roguelike”) and require a connection anyway, while here I’m talking about single-player turn-based roguelikes that can also/normally be played offline.

Many of the original classic roguelikes, pretty much anything that runs in a terminal, can be set up to work through a connection (telnet etc.). (See here for a collection of classics accessible via this method in your browser.) But there is so much more you can do than simply play a roguelike hosted on a server by feeding it commands. What about value-added features?

Modern Examples

Now that most players have access to the internet, modern roguelikes are using the web in new and interesting ways. The two best examples are Dungeon Crawl Stone Soup (DCSS) and Tales of Maj’Eyal (ToME 4). These are games fully playable offline, but with many additional benefits to online play.

DCSS has a wonderful so-called “webtiles” system whereby you can play online, watch others as they play, and chat with them in game. It also collects stats you can browse, and is naturally a great system for hosting competitions. Back when I used to play a lot of DCSS (in the pre-son days when I had this thing called “free time”) I wanted to use webtiles (mostly as a way to force me to be honest--no temptation to savescum, and also to take part in competitions), but latency is a huge problem for me since there are no servers nearby. I did occasionally watch other players, though, a fun learning experience.


DCSS webtiles lobby.

I’m less familiar with ToME4 because it’s not really my type of roguelike, though it’s easy to see that Dark God has built quite an expansive virtual empire via online support for his game. The website has player accounts, character dumps, real-time stats from everyone playing the game, and, most interesting of all, there’s in-game chatting with anyone else playing the game. Classic roguelike mechanics don’t lend themselves to the multiplayer format, and as single-player games they miss out on potential unique benefits of playing with others, be it asking for help or sharing an experience. In-game chat is one way to bridge that gap.


An excerpt from ToME’s in-game chat log, as mirrored on the website.


What can single-player roguelikes gain from integrating some degree of web support?

  • Metrics. Stats collected during normal play are both fun for players and useful for developers looking to improve the game. Real numbers are more useful than player feedback when looking to balance content, because players’ opinions can be skewed by many different elements contributing to their personal experience. (That’s not to say player balance feedback should be ignored, but we should compare it to the numbers and hopefully see a more complete picture.)
  • Leaderboards. Even in single-player games, many players enjoy comparing their progress and strategies to those of other players. Providing an automated way to upload scores and stats simplifies the process and helps build a stronger community. Sure it’s possible to hack these systems unless the game is actually played out and/or verified in its entirety on the server side (another advantage of DCSS webtiles), but it’s still fun.
  • Data sharing. Some types of roguelikes can benefit from automated sharing of data between players, like morgue files (for player ghosts), maps, and other content-specific information. If I was a more savvy web developer, I’d almost certainly try out a concept roguelike that enables the game to asynchronously share data between players even in a turn-based environment (included as a major feature of the game design, of course).
  • In-game news and update notifications are good for keeping players up to date. This is especially useful for roguelikes which may be updated quite frequently and/or over a very long period.
  • Automated error reporting lessens the burden on the player to report a problem, and increases the likelihood and efficiency of a solution on the dev’s end.
  • (This is a basic list, as there are many more possibilities. Get creative! Feel free to share other ideas in the comments.)

Cogmind, Connected

I’m more interested in design than banging my head against technical problems I don’t understand (I love solving challenging technical problems, but only those for which I’m likely to already have most of the required background knowledge), so I avoid web development whenever possible.

That said, ever since the first Cogmind design doc I’ve imagined and hoped that the game would support at least some web-enabled features. For the 7DRL I even held a tournament (more of these will happen, only bigger and better =p), though scores were provided by e-mailing them to me. Not so efficient, and it definitely doesn’t scale well.

More recently as I moved to plan for a first release and decide what that release absolutely must have, the usefulness of an optional web connection made it a higher priority. After a day or so of research I went for the simplest solution possible (for me): An SDL_net-based class that can send HTTP POST messages combined with a tiny bit of corresponding PHP to talk to the game from the web.

What does this little bit of code do for Cogmind?

First, and most importantly for a game that will have frequent substantial releases, we now have an update checker. All this does is retrieve the latest Cogmind version number from the server, and check whether it’s newer than the current local version. Because it’s easy to add extra info to the data transfer, I made it possible to send a text message along with the version number, in case there’s some kind of important game-related announcement. So this feature doubles as a news checker. Here you can see it in action:


Cogmind’s news and updates page. It happens to be showing the first news item I was using for, um, “testing.”

This is not an automatic updater--you’ll still have to go download the new version yourself, it’s just a reminder/notice. To make sure you know there’s a newer version available, until the update/news page is opened its button will glow in the game menu:


A glowing reminder that there’s a newer version or news you haven’t read yet.

This and all web features are optional, and all but update checking are disabled by default. While the other features come disabled, I do hope you turn them on ;).

In addition, there are now automated crash log uploads. If the game crashes for whatever reason, which is unlikely but not impossible during early releases, before shutting down it will try to upload the precise reason and a reference to the source code that caused the crash. With this system in place we should be able to fix any serious bugs very quickly (assuming you turn it on).

Score sheet submission is also automated. All this feature does is upload the same score and stats file you see in .txt form after a victory or loss, but it’s a lot better than sending the file manually! Very convenient for anyone who wants to help improve Cogmind’s balance, take part in tournaments, and contribute to anonymous overall game stats published for reference.


An excerpt of stats listed in Cogmind’s score sheet. There are currently about 300 entries. (A future post will be dedicated to exploring character dumps and morgue files in roguelikes.)

As part of these new features, I’ve revamped the score record system, and added “player name” to the game options (you can also choose to upload data anonymously). While we may see a more robust web interface for Cogmind in the future, with even more features, I can’t guarantee it. Even if it does happen, it will almost certainly be handled by someone other than myself, and would require the use of an actual server-side database (interested parties have already contacted me; we’ll see).

On a technical note, because I wouldn’t want the game to be stopped while it waits for a data transfer or response from a slow or unavailable connection, all the web code is managed from separate threads, so Cogmind is technically now multi-threaded for the first time :D.

Posted in Internal | Tagged , , | 8 Responses

Tileset Concepts, an Open Poll

The response to last week’s advertisement for a pixel artist was overwhelming. I did expect a fair number of random artists from art forums just forwarding their portfolio, and certainly got that, but there were also a good number of applicants genuinely interested in the project itself.

In total the ad had nearly 1,000 unique views, attracting 34 applicants. Of those, 17 provided concepts for a Cogmind tileset, which I’m sharing with you today (anonymously!). Of those who didn’t provide concepts, 5 are qualified candidates to consider for hiring if we don’t find any initial concepts that are already on their way to being a good fit for the game.

But first, let’s look at the concepts. Naturally these grayscale samples will feel somewhat different once colored in game, but the results will still be monochrome, painted with a fully-saturated color of varying brightness to reflect the tile’s shading (if any).

The list--order is random, click to open the image and make sure to zoom it to 100% size for details:


Cogmind tileset concept submissions. (Click to open full size for details.)

I’m not making my own criteria or critiques public yet, hoping to instead hear what you all have to say. Some of you (those not using ASCII) will be the ones to actually use these, so I want your input. Have opinions? Favorites? Suggestions or preferences regarding style? Which of the above samples would you like to see expanded to become the game’s tileset and, more importantly, why? Leave a comment here or at any of the many other locations this post is mirrored.

Next Steps

If enough of you concur that some of these concepts are something you’d like to see in the game, the selection process will continue as I contact those artists to work out the details, as well as compare candidates based on other criteria, like experience and, um… cost ;)

Bonus Art

While we were only interested in concepts for tilesets, some applicants provided samples of other kinds of art, some of it pretty cool… This wasn’t required, but let’s not let those efforts go to waste :D.

These are all different takes on my ASCII art for Cogmind:


Chainsword and Quantum Rifle partially pixelized by Linus Chan.


Anti-matter Cannon illustrated by Gustavo Santos.


Mini-pixelized weapons and components by Gurkan Te (ShroomArts).


Update 2/12/2015: We’ve chosen two artists. See some initial revised versions of these tileset concepts in game, and a discussion of the selection process and ASCII vs. Tiles aesthetics here.

Posted in Art | Tagged , , , , , | 16 Responses

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.


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.


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.)


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).


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!)


Anyone interested in filling this position should mail me at 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.)


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


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.

Posted in Art | Tagged , , , , , | Leave a comment