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.)
RSS (posts)
Mastodon
Patreon
Discord
/r/Cogmind
Indie DB
20 Comments
At this point in roguelikes I see the choice between ASCII and tilesets less of a one or the other and more of a Spectrum. The only thing that makes it seem more distinct is that the ability to put text on the screen has been simplified a lot more then graphics (Libtcod is a good example). From the stand point of a player and a person who does YouTube videos my preference is actually “neither” or more specifically I like those tilesets that use ASCII as their core. I can think of a couple of examples of this right off the top of my head. First would any of the Dwarf Fortress tilesets where things like the symbols used for walls have been replaced with wall graphics that allow for smooth diagonals and how the even some of the sets that come with it have replaced the @ with little dwarf images. The is in a few CataclysmDDA tilesets they keep most of the basic things ASCII but the Zombies are actual zombie images.
The tilesets that combine ASCII and graphics elegantly to me tend to stand out the most. By being able to abstract most things down to the core info with various characters while still having room to personalize various special instances you can make stuff pop even more. For this I really like the CataclysmDDA example I used as with pure ASCII the various undead are basically all ‘Z’s with varying color and once you transcend the ascii you are able to more easily tell that the fat one is a boomer zombie though admittedly the hot magenta color used for them always tends to stand out either way.
Really in the end though, either way the method that Roguelikes use to display stuff is almost diametrically opposed to the most other modern game graphic styles. Roguelikes have a heavy focus on clarity of display. Many regular games will have even the smallest things slathered in textures even when you can’t do anything with it. Some games even go so far that they have to highlight stuff you can actually interact with otherwise it would get lost in the visuals. Roguelikes, even at the most cluttered and styleized and even when taken into other genres will tend to have what you need to see stand out without having to put a glowing halo around it. Of course not all things have to have a purpose but even when this is true because of the styles used this tends to be easily discerned without any thought. Going outside the core Roguelike sphere we can see this ina action with games like Binding of Issac and Spelunky. Even when they turned the graphics up the games still manage to keep the distinct separation of matters within their game.
The biggest thing out of this though is the fact that this isn’t something in anyway unique to Roguelikes. Back at the start up till the near past games still did this. What has changed though is the modern attempt at more realistic graphics. This isn’t a bad thing though, the problem lies in the end with going overboard. The biggest thing that makes me sad about it though is that realism currently is at a stage where even games barely a year old look dated.
There are a lot of fun games out there and in only a few years many of the ones which are currently claimed to be greatest will fall because they will look old to the point of unplayability. The oldest games currently look old because they are. When you could only works with pixels or the largest of polygons things are restricted. Now though even rocks most people don’t even look at generally can end up having more detail then the player character of the old games. We just don’t use this wisely. Some of the best examples of doing it right are Windwaker and even Minecraft. One through a toon style of art still looks great even today despite some of the games in the zelda series that come later now looking worse and the other through a simplistic style which while admittedly slightly low res is still something I can spend hours looking at. Realistic is a valid art style but from what I can see most big game companies are just defaulting to it without actually considering other options (this is of course a broad generalization but it makes my point).
Now though I have really gotten outside of the original topic at hand. To reign it back in I just want to say roguelikes are no longer in a state of ASCII vs Tiles but rather we are on this sliding scale of Symbolic to Representative are you. ASCII will of course always have a place because if anything else it is easier to develop a game when all you have to worry about art wise is remembering to make sure the red Dragon is a red ‘D’. The biggest thing left that is propping up the debate is that most of the roguelike libraries are setup to allow text to be easy and tradition. With the 7DRLs causing more and more people to develop their own we see more and more people breathing fresh thought into the genre so I really can’t wait to see what the future holds.
“There are a lot of fun games out there and in only a few years many of the ones which are currently claimed to be greatest will fall because they will look old to the point of unplayability. ”
That’s a key insight. I remember loading up an early 3D game from the 90s I had remember being so much fun, and simply couldn’t play more than a few missions it was so terrible. One advantage of well-designed game with a classic look is that classic looks are timeless ;). With less need to outdo other games graphically, more of the focus can be on actual mechanics and the gameplay experience.
This is the direction a lot of indie developers take these days, and it’s working well to expand a new profitable market. It’s funny that given their vast resources, AAA companies simply won’t take this route. There is certainly more risk involved with a single project, but the investments are so much smaller than their overblown budgets that you can make up for that risk with a larger number of better quality products.
Cogmind in particular is exploring lots of new territory with ASCII, but in the end only a minority of the potential player base can handle it :(
The problem with the triple A industry is in the very nature of them having a lot of money and resources. They want to make use of it most efficiently so they look at what they can invest it into. With video games the development resources are Graphics and Code. Of the two graphics are the one you can most efficiently pump money into, especially with the “realistic” look many games go for.
Because a lot the graphics work is 3d modeling and graphic design that has to all look similar you can just throw more artists and modelers at a project. The money put in affects the work additively. +1 modeler equals +1 more model. More artists means that more art is created. Even better for the bottom line is you don’t have to have high quality people. More precisely though besides someone who needs to be in charge of design as long as someone is able to replicate the look closely enough its all fine because even if they throw a few stinkers you just cut it.
Coding isn’t additive and is more of an art which I find slightly ironic. Just like too many chefs ruins a meal too many programmers can ruin the code base. If you throw more programmers at a problem it doesn’t get done at +1 speed. Rather it gets finished at the same time it would have finished for the best one with maybe some seconds taken off to represent collaboration. Even worse not only is it not a straight +1 the amount added shrinks with every new coder and can even get to the point where instead of adding the new people are taking away. These problems are gotten around somewhat by breaking the code into chunks so while it is a lot of chefs in the kitchen only a few are working on the soup while others are off tossing the salad.
Even worse though than the fact that you can’t just always throw more programmers at a problem but you might not even be able to bring them to bear in the first place. Code builds upon itself so until the base is finished nothing else can be done effectively. In 3d modeling or graphic design if you tell the artist what you want they can probably make it. Need a blue streaked rock for sector 4? Who cares if it has anything done with sector 4 at all, you just need a rock with blue streaks modeled.
Basically it all ads up into an equation that shows using realistic graphics actually lets them spend their money even more effectively. It isn’t even one of those technically true statements. Graphic designers and such are more efficient when looking at it from a cost cutting matter. So we end up with Assassins Creed where the graphics look great if you can get around the fact that you need heavy duty graphics cards to even run it half decent. They spent their money so efficiently it seems they might have starved the programming side of it. Really though in the end even if this all wasn’t the case there is still one trump card on the graphics side. That final thing is the fact that these are what the customer views. Someone high up wants it too look ‘hip’ and modern so it sells more copies. The game can be a buggy mess but people bought it so what does the company care (you know besides the fact that you generally don’t want to annoy your customer base but meh).
Assets are definitely a good money sink, and they do cater to a different audience after all, one that is perhaps more interested in the pure entertainment value than a deeper experience. Truly deep experiences emerge from the level of interaction with the environment and other actors, not simply more realistic graphics (not preaching to you, since you obviously understand this; just making the point).
The alternative I was thinking about was not exactly throwing more people at a project to build a deeper realistic game, but instead have a company split resources into supporting numerous smaller groups, or even individuals (like myself!). It’s inexpensive and can result in many more unique high-quality successes. But then, having dozens of different products wouldn’t scale revenue well as you flood the market, and marketing also becomes an issue once you have less focus on one or two major products. It’s also not the way a standard business works, and game companies have already transformed from the innovation model of the 90s into cash farms for investors :(
The other problem is marketing. Which while outside of the actual production also takes up resources like money. Of course the big thing with marketing is it is both expensive and singular. A marketing campaign for one game won’t work for another so each one needs its own particular insights. Most triple A companies probably prefer focusing on only a couple specific games to push because as you mentioned, too many causes market saturation.
To that I counter: art direction can surpass dated technology and create a timeless charm.
This is true for any medium, and there are plenty of famous games that have this quality.
True it can, though quite a few games lack that level of execution, not to mention vision. I think it’s naturally more difficult to achieve in a corporate environment compared to game development motivated primarily out of passion. There are exceptions, for sure, but the vast majority of games I enjoyed as a kid and could still stand now are 2D/isometric.
At the same time, advances in design are certainly valuable. Usability paradigms have evolved so much over the years that it’s hard for older games to compete. CRPG Addict’s adventures certain prove that much. Maybe we need even more remakes than we’re already getting ;).
So I recently stumbled across this game and I’ve never even thought you could use ASCII symbols to make so beautiful game.
I’ve played classic roguelikes for a while (mostly ADOM) and since i’ve learned to read the symbols properly It’s hard for me to play ADOM with it’s NotEye Tileset. I can see what you mean with the easier readability with the ASCII. If i run into a room with a lot of brown ‘r’s and one white ‘r’ I immediately see that it’s wererat surrounded by rats. With tileset it might take me even one second to actually understand the situation.
For me both L and P look really good, can’t really say which one is better. They both use the tiles as more of a ‘symbols’ than real tiles, which makes the tileset easier to read. A huge plus for tilesets and graphics in general is the timelessness. Games like FTL look beautiful even after many years due to the great artstyle. I dig the idea of hiring both artist to do the tileset, can’t wait to see the results. I’d like to add that the Cogmind logo as PC looks great.
Glad you’ve found Cogmind, and that you’re finding it looks like something you’ll enjoy :D
I didn’t find ASCII roguelikes until long after being used to 2D tiled/pixel art games, but found they’re without a doubt superior for pure tactical decision-making, which is why I now prefer ASCII myself. It can, however, take longer to get used to, an issue that Cogmind addresses with multiple ways to visually identify objects directly on the map. That should make it easier to get into, which is one of the roadblocks to acceptance of a new ASCII roguelike. Of course there’s also the tileset(s), though I hope (and expect) that we’ll have quite a few happy ASCII players ;).
P is going to be the choice symbolic set, though I think anyone familiar with ASCII already might as well use that mode, since it provides better immersion into the “world of robots” and also benefits from letter association. In any case, Austin (artist P) has recently started testing the game itself and has some new ideas, so we’ll see what comes of that over the next couple weeks!
Personally, I am glad that the major roguelikes support both. ASCII allows neat tricks like NOTEYE, tournaments over SSH, and playing in a lightweight VM. Gameplay is the make or break. Tiles are icing on the cake.
Precisely. Cogmind was designed with a gameplay-first attitude (as all true roguelikes are), and will always support both ASCII and tiles. So maybe Cogmind gets to be a “major roguelike” one day ;)
Unfortunately Cogmind is run as an emulated terminal, so no SSH or NotEye support. It’s certainly lightweight, though, and runs in software mode.
Here’s wishing cogmind success in becoming a major roguelike. :) Where there is a will, there is a way. IMHO DCSS is well on its way.
Observation: Every major roguelike is cross-platform, and with one exception, they all come with source code.
Very important observations, indeed. Cross-platform compatibility is a tough strike against me, since a Linux port of the engine is challenging enough to reduce its likelihood (if it were easy it would have already happened, last time I tried :C). Though Cogmind does work fine in Linux under Wine (one of my artists only uses Linux).
That you don’t include DCSS as a “major” roguelike means my definition is apparently a bit broader than your own ;). I think it’s time the old list of a few “classics” are considered just that--classics, while where “major” is concerned we add in the many later roguelikes that have already been played for years by a huge number of dedicated roguelike fans like DoomRL, Caves of Qud, Incursion, Cataclysm…
Most of the classics are certainly open source, but when you start to expand the list to include later games, a greater portion of the better ones with tight design are actually closed source passion projects. DCSS is the sole example I’d cite as a well-managed open source roguelike.
I do however believe that “major” requires development over a very long period in order to mature to that level, and Cogmind may not meet that requirement, either. Development will probably total about 2-3 years and then be considered “complete,” because while there is a lot of room for interesting content, it’s still a more “contained” experience where I’m attempting to create something very specific. I mean, you can’t even select your character =p. Time will tell… My next game will have a much bigger chance of becoming “major” due to its huge modding potential and virtually unlimited scope, but Cogmind not so much.
If anything, Cogmind’s importance will be in pushing the genre to do new things on many fronts. A number of developers are already picking up on some of Cogmind’s advertised features ;).
You know, P’s proto-style of ‘solid’ robots and wireframe items, with blocky terrain pieces helps make a not bad visual shorthand. If they keep it that way, it will be great at sorting the robots from the robotics when fights get messy ;-)
That’s the plan with P. We’ll see what it looks like as a full set--artist P, a regular roguelike player, is playing the game right now looking for how to make it work well :D
The first thing I want to look at is how items will be easily differentiated from robots, since those are the two main things you ever see! ASCII does a great job of splitting the categories by using letters for one, and punctuation for the other.
(Fixed the auto-correct error for you, btw =p)
I like it -- good luck to P, then! I note that neither artist came up with a Cogmind. I assume they’re going to come up with something similar to the logo? That C is awesome and iconic.
(ha, thank you. For some reason in Android’s chrome the main text box gets super zoomed-in when you go to type, so you’re typing half-blind on a shonky keyboard with an aggressive auto-correct… it’s not easy to avoid errors.)
I’m glad the artists didn’t spend any time trying a Cogmind tile, since I was most interested in seeing a variety robots. Cogmind will of course be something very different from the rest to suit the amorphous nature. Some kind of cog-like ‘C’ is appropriate, though we’ll have to see what fits well in each style. I do like the icon a lot, too (though in game you’re azure blue, not green =p). In any case, the artists are certainly interested in coming up with the player sprite.
(Sorry about that. The blog and site are not really optimized for mobile. Some months ago I added a mobile conversion for the blog, but never tested the comment functionality.)
I remain keen to see, then. I do note in passing that P stands out better as iconography if you have screen brightness issues -- the shading on the other dissipates rather than flattens. Still, I remain keen to see just how they both do!
(And don’t apologize, it works way better than the original. It just makes me occasionally look like a babbling idiot. ;-) )
I can imagine P being the better option for display limitations including brightness and smaller monitors. The shading issue with F was partially because Kacper (the artist) wasn’t aware of how the sprites look once converted from the spritesheet for in-game use, so some of the shades were too dark to stand out (or even be visible at all) and ended up trailing off. He’s since corrected that issue. We’ll see what they can do. For the next week or so we’re working on rough concepts, then another week or so for the final touches and making sure everything works well together.
(Glad you noticed, then :D. I don’t use mobile, but I realized that many people browse that way in their down time so the blog really needed a mobile-friendly version.)
Fair enough -- will be interesting to see what they can manage with a better understanding of the alpha channel options, too.