{"id":976,"date":"2014-09-09T08:27:57","date_gmt":"2014-09-09T00:27:57","guid":{"rendered":"http:\/\/www.gridsagegames.com\/blog\/?p=976"},"modified":"2018-01-10T14:14:23","modified_gmt":"2018-01-10T06:14:23","slug":"fonts-in-roguelikes","status":"publish","type":"post","link":"https:\/\/www.gridsagegames.com\/blog\/2014\/09\/fonts-in-roguelikes\/","title":{"rendered":"Fonts in Roguelikes"},"content":{"rendered":"

The first aspect of a traditional roguelike viewers tend to notice is the color palette, but when it comes down to actually playing a game which requires interpreting large amounts of text, color takes a backseat to the importance of the font. Characters\/glyphs form not only words and sentences, they even represent the map and every object contained within, blurring the distinction between font and sprites\/tiles. Thus roguelike developers should not overlook the many considerations that go into creating or choosing the right font. This is the first post in a series that will explore those considerations, share font creation techniques, and look at examples from Cogmind itself. Note that although the topic is discussed in terms of roguelikes, some of the concepts and methods touched on apply to all kinds of games.<\/p>\n

Readability<\/h1>\n

The number one consideration with a font that’s meant to be read a lot is, surprise, readability! This consideration is often at odds with the desire to stylize a font to give it a unique look reflecting the theme of the game. So while roguelikes are often set in a fantasy world, they don’t use the styled fantasy fonts you might see in a lot of graphical CRPGs (especially older ones). There are many reasons for this, and a number of factors that affect readability.<\/p>\n

Single Font<\/h2>\n

By necessity, traditional roguelikes use a single font for everything displayed, be it text or map information. There’s already an inherent dilemma here: The idea of “readability” takes on a different meaning when referring to either text or a map. The ideal readable text font produces easily recognizable words and sentences, while a map font should produce “tactically readable” maps. With the latter, glyphs should be drawn with an eye towards easy individual recognition rather than as a component of a larger word. This is different from regular font design which places heavy emphasis on how letters interact, knowing that we recognize words as a collection of letters and not for the individual letters of which they’re composed. Thus individual letters in fantasy text fonts can be fairly stylized, but would take an extra moment to recognize or distinguish when used in isolation on a map. Certainly it’s possible for a player to adapt to even the strangest fonts used in this way, as they are simply representative symbols, but letters often carry addition information to aid recognition, like using categorical abbreviations such as ‘c’ for canine, ‘h’ for humanoid, ‘z’ for undead, etc. Less readable fonts also create yet another barrier to adoption when players already have to face learning a new set of input, mechanics, and glyph meanings, systems which themselves may already be complex (though are not required to be). Even long-time roguelike players tend to have a low adoption rate for different roguelikes, not even trying them unless there is an extremely compelling reason to do so, or they need a break from their favorite RL ;)<\/p>\n

Another characteristic of tactically readable maps is a square aspect ratio, where horizontal and vertical distances are equivalent in terms of both screen space and game space. Having to translate between the two is something long-time players will be familiar with.<\/p>\n

\"DCSS_aspect_ratio\"<\/a>

Dungeon Crawl Stone Soup in ASCII mode, with all cells within range 7 encircled. Here Sigmund is 7 steps away, but could feel a lot more menacing if he approached from the left or right. As if Sigmund wasn’t intimidating enough…<\/p><\/div>\n

This relic of old console roguelikes is best avoided since it unnecessarily* distorts space and causes a disconnect between what we see and the actual situation. (*Unless we count nostalgia among those necessary qualities.)<\/p>\n

The reason this convention is so prevalent is that we have the “single font” factor (and that font gives preference to text readability due to a high ratio of text content) combined with another roguelike characteristic: the grid-based display.<\/p>\n

Grid-Based Display<\/h2>\n

Unlike most other games, as a traditionally terminal-based genre roguelikes originated in a grid environment. Though technically no longer restricted in the same way, even many newer roguelikes are played in emulated terminals that maintain the same convention to preserve that traditional look and feel (being simpler to code is another factor).<\/p>\n

Given our single-font, grid-based display, what happens if we favor a square aspect ratio to aid tactical decision-making? This:<\/p>\n

\"cogmind_7DRL_wide_text\"<\/a>

The Cogmind 7DRL\/prototype used a square font to make the map easier to interpret, but the effect on the text… not so readable.<\/p><\/div>\n

The issue is even more acute with large blocks of text, which become a chore to read as your eyes have to move 50% faster to decipher each line of text. Libtcod<\/a> seems to be a major force influencing the trend in this direction, because it uses square fonts by default and is one of the primary tools for new developers. Many libtcod games use square fonts, and their text readability suffers as a result.<\/p>\n

Words and sentences are more difficult to clearly lay out in a strict grid because some letters are naturally narrower than others. Interfaces without a grid can specify a static one or more pixels between characters, or even apply kerning (adjusting the distance between letters based on their neighbors), to resolve spacing issues.<\/p>\n

Serifs<\/h2>\n

We can’t discuss fonts without mentioning the two major classifications: serif and non-serif. Serifs are short lines protruding from the ends strokes\/lines that form a glyph.<\/p>\n

\"sans_vs_serif\"<\/a>

Sans-serif vs. serif letters.<\/p><\/div>\n

In roguelikes, serifs can serve to distinguish ‘1’, ‘l’, and ‘I’, which is especially important in cases where all of these are used to represent map objects as they don’t belong to a word which can be used as a reference when interpreting them. This same consideration comes into play when selecting a monospace programming font, where you also want to make sure that ‘O’ (the letter) and ‘0’ (zero) are easy to distinguish.<\/p>\n

In addition to their functional impact, serifs are also meaningful stylistically. Serifed fonts tend to evoke a fantasy aesthetic, though that’s not to say you can’t<\/em> use serif fonts in sci-fi games. For roguelikes at least serif fonts do have the most traditional appeal, no doubt for nostalgic reasons since the IBM PC\/MS-DOS console font was mostly serifed.<\/p>\n

\"cp437_ibm_pc\"<\/a>

IBM PC code page 437.<\/p><\/div>\n

 <\/p>\n

\"caves_of_qud\"<\/a>

Caves of Qud: A sci-fi roguelike displayed with a good old serifed non-square font.<\/p><\/div>\n

Fonts can say a lot about a game, though.<\/p>\n

\"font_sword_of_the_stars\"<\/a>

This font says “I am probably not a fantasy game.”<\/p><\/div>\n

In general sans-serif fonts tend to suggest more sci-fi qualities: crisp, clean, streamlined. I’ll be sticking to that theme for Cogmind’s fonts, so no serifs.<\/p>\n

Solutions<\/h1>\n

There are many solutions for addressing the readability issues discussed above.<\/p>\n

Size<\/h2>\n

If you want a square aspect ratio but don’t want to sacrifice too much readability and don’t mind being forced into a certain style, sufficiently small wide fonts are fairly readable. Like this 8×8:<\/p>\n

\"incursion_8x8\"<\/a>

Incursion: Halls of the Goblin King, shown in a small 8×8 font (click for original size). Characters are small, but then so is the relative space between them.<\/p><\/div>\n

Using small fonts also enables you to pack a lot of content\/information into the UI, though this isn’t advisable for mouse-enabled interfaces where cell size suddenly matters for click accuracy. Fortunately roguelikes are heavy on keyboard use. Despite its many features, Cogmind is entirely playable via keyboard and\/or mouse. However, if you’re on a netbook and running one of the 10×10 mini-fonts, I’d recommend sticking to the keyboard unless you don’t mind occasionally clicking the wrong target ;)<\/p>\n

Choices<\/h2>\n

While properties that make a roguelike “readable” can be defined objectively, players’ own preferences won’t always align with that definition. More importantly, each player’s situation may differ somewhat due to factors including eyesight, available light, monitor size and quality, etc.<\/p>\n

Roguelikes are often pretty good about offering ways to customize the experience to meet these different needs, and with such a low overhead to providing alternative game appearances (just a bitmap), it makes sense to do give players many options in that regard.<\/p>\n

\"cogmind_font_swapping_10x10\"<\/a>

Using the options menu to swap between the two 10×10 mini-fonts I’ve been working on for Cogmind (what you see here is the text version, which is 5×10). With these, the smallest resolution\/window supported by the game is 800×600.<\/p><\/div>\n

Font switching is fairly common in terminal roguelikes, but developers can’t rely on the player to decide on the best one right away. A game’s default font ends up being quite important since a majority of players just go with the default, which becomes the font associated with the game in general (screenshots\/LPs). There’s also the first impression to consider, since a font that doesn’t click with a given player can contribute to them not liking the game early on (in which case they may not get deep enough into it to want to swap in another font).<\/p>\n

Mixed Fonts<\/h2>\n

To get the best of both worlds, a square aspect map font and narrower font for text, we have to take the radical step unavailable to standard terminal roguelikes: use multiple fonts. As mentioned in the intro, roguelike usage of fonts traditionally blurs the distinction between font and sprites\/tiles. However, even if we don’t go as far as using actual<\/em> sprites, by separating the two we can at least choose an ideal font for each.<\/p>\n

Now that many roguelikes with a grid-based interface use an emulated terminal, instructing them to store font information for each cell and pull characters from one of two separate font bitmaps at render time is easy. My own engine uses the simplest implementation, which has the narrow text font take up exactly half the width of the current square font.<\/p>\n

\"cogmind_narrow_text\"<\/a>

A Cogmind parts list like that seen in the earlier 7DRL\/prototype image, converted from 12×12 to 6×12 half-width font. Whew.<\/p><\/div>\n

Half-width text fonts technically double the number of horizontal cells in the interface, but allow layered UI elements to stack nicely while partially obscured lower layers can still be displayed properly. This is more compatible with the cell-stacking system of my own engine which simplifies culling, retains the traditional grid-based look, and is simple to manage since UI offsets are still handled in cells rather than pixels.<\/p>\n

\"mixed_font_visualization\"<\/a>

A random UI layout mockup showing how 6×12 (green) and 12×12 (red) cells stack on each other.<\/p><\/div>\n

The primary drawback to this approach is the heavier CPU load from all the extra cells for the same amount of screen space. Cogmind’s display requires more processing power than the 7DRL, but it’s been two years since then, plus the cell stacking system was later optimized somewhat.<\/p>\n

Resolution<\/h1>\n

The original roguelikes never had to worry about the player’s monitor resolution, expecting instead an 80×25 console window--fullscreen support wasn’t an issue, nor were the implications of different monitors.<\/p>\n

Today many players like to fully utilize their screen space rather than keep a game windowed like some application. To accomplish this, unlike tile-based or 3D games that scale geometry, textures, sprites, fonts, and interface elements, roguelikes have an alternative option (or the only option before\/without the use of non-console engines): swap out font bitmaps to change the resolution of the entire game to match the target resolution as closely as possible.<\/p>\n

For most games it would be costly and time-consuming to manually recreate assets for multiple resolutions, but not so for roguelikes. All we have to do is redraw the font map, a single image, at a different size. This enables us to keep a crisp-looking pixel-perfect appearance at any resolution for which there is a font.<\/p>\n

An example of why we don’t want to just stretch the interface:<\/p>\n

\"caves_of_qud_opengl\"<\/a>

Caves of Qud in OpenGL mode.<\/p><\/div>\n

The OpenGL version of Caves of Qud scales the entire interface rather than using an actual font renderer (compare to the earlier CoQ terminal image, which is pure awesome). While rendering fonts would be a better option, even those don’t always look good at every resolution. Working with pixels we know exactly what the result will look like, and seeing as it’s fairly easy to provide fonts for multiple resolutions, I think we should make that effort.<\/p>\n

Once we decide against automated scaling, the next important question is how many resolutions do<\/em> we have to realistically support? Wikipedia has aggregated some interesting and useful data<\/a> on that topic:<\/p>\n

\"common_display_resolutions_2014\"<\/a>

Most common display resolutions that games should support, because that’s what players are using.<\/p><\/div>\n

Ranking display resolution usage by percentage of Steam users, we see that more than half<\/em> are using one of either 1920×1080 or 1366×768.<\/p>\n

Because a given resolution will not necessarily be evenly divisible by any font, in making these additional fonts we’ll need to consider some other solutions.<\/p>\n

The simplest is to add black strips\u00a0around the interface to fill extra space (a.k.a. letterboxing), though it’s best to minimize usage of this method as some will complain it’s not “true fullscreen” (however, it is important to remember in gamedev that technically someone will complain regardless of what you do…).<\/p>\n

\"gui_layout_1366x768_letterbox\"<\/a>

An 80×60 console GUI rendered using a 12×12 square font, the largest that will fit the entire interface within a 1366×768 resolution. This happens to be Cogmind’s UI layout, and what it would look like letterboxed at this resolution.<\/p><\/div>\n

Ideally one or more interface elements will have adjustable dimensions, so that we can increase the amount of actual visible content as opposed to leaving portions of the screen space unused. For games where the maps are large (like Cogmind), we can increase the amount of visible map area.<\/p>\n

\"gui_layout_1366x768_expanded\"<\/a>

Taking the same GUI elements from above and expanding their content (no stretching) results in a 66% increase in map\/log width (+33 cells), and ~8% increase in map\/HUD height (+4 cells). Because the 12×12 font is not perfectly divisible into 1366, there will be 5-pixel vertical bars along each side, a small price to pay for a pixel-perfect interface.<\/p><\/div>\n

The third font post, in which I’ll cover Cogmind fonts in more detail, will also discuss the selection of font sizes and target resolutions.<\/p>\n

A second observation to take away from the display data: Wide screens are now the norm, thus new games should develop their GUIs accordingly. Cogmind happens to have been designed for a 4:3 aspect ratio, which are growing increasingly rare as far as fullscreen resolutions go. Of course, there are a few advantages as well: 1) takes up less space when windowed, 2) keeps information more evenly distributed, 3) requires less computing power. That said, after reviewing the state of resolutions here, on rebooting development of my other game X@COM<\/a> I now plan to redesign the UI to take full advantage of wide screen support.<\/p>\n

This is the first in a four-part series on roguelike fonts:<\/em><\/p>\n