Planet Roguelike-Dev

January 10, 2018

Grid Sage Games

Color Customization

I’ve always enjoyed adding accessibility features, hence Cogmind’s sizeable options menu and even more extensive config files. Not everyone will have the same habits or abilities, or play a game in the same way, so where possible it’s nice to be able to accommodate different needs. Although I’ve talked a fair bit about fonts before (still more to come on that front!) and four years back also wrote about some of my ideas on potential adjustments related to color blindness, it’s about time for a generalized set of color customization features.

As the player base has grown a fair bit over the past few months, I’ve received a few requests for ways to tweak the brightness and/or saturation, so that was the trigger for finally implementing a display filtering system.


Many games come with a simple “gamma” adjustment option, so that’s where I started. Easy enough:


Comparing the default appearance to a 66% brightness setting.

While it’s true perceived color brightness is non-linear, adding in more complex calculations to compensate would slow the filter down so I implemented it as a direct percentage modifier, just [RGB * (0.0~1.0)].

Note that for comparison purposes the majority of screenshots in this article use the same scene, and all can be clicked to open at full size.

Some players may also want to drop the saturation to take the edge off the eye-burning terminal contrast :P


Comparing the default fully saturated appearance to 66% saturation.

Since I store colors using RGB and it’d be slow to convert everything to HSV simply to adjust the saturation then convert back again, I found an alternative formula for direct RGB saturation adjustment that seems to work nicely.

Filter Settings

So how are these options made available, and how to create a system that will support additional filters? For now I opted to make it a string in the advanced.cfg file. For example the line “renderFilter=BRIGHTNESS(90)|SATURATION(90)” adds two filters, a first which drops the brightness by 10%, followed by a second that then desaturates all colors by 10%.

There are currently eight different filter types, and the code converts this string into a set of filters that the engine renderer applies in separate passes over the terminal grid colors, both foreground and background. They’re applied to every cell individually, so this isn’t some GPU-optimized image modification, just an operation repeated for each cell, meaning each filter pass on the standard-dimension UI costs an additional 12,720 operations xD. Yeah there are better ways used by more competent programmers to achieve effects like this, but it works well with my current engine setup :)

At most the minority of players who will use filters seriously will probably only need one or two anyway.

Getting Wild

Having taken care of basic needs, there are of course even more frequently requested adjustments like the ability to outright change terminal colors.

Traditional terminal players are used to being able to fairly easily customize the appearance of a roguelike, including the color palette, but they also only have worry about maybe just 16 colors. Unfortunately there is a huge range of colors in Cogmind so it would be a lot more work to implement a way to customize individual details, but for now I’ve at least added a very simple method with a broad effect: hue shifting. It can lead to some crazy schemes, but there are reportedly a number of people out there interested in something like this.


Cogmind appearance with all hue values rotated by 180 to become… Pinkmind! (example #2: 90-shift Bluemind)

Colors have been carefully chosen in Cogmind, designed to make the meanings and implications of certain pieces of information that much easier to intuit, and obviously shifting the hue will ruin a lot of that. Some things which were obvious may not be so obvious anymore, and on the flip side unimportant elements may be overemphasized. In any case, doesn’t hurt to have this as an extra option for whatever reason!

With a system in place it’s also not hard to add new filters.

I mean we can even get crazier than hue shifting and go as far as RGB shifting! Check out the color chaos that results from a +90 shift:


Shifting all RGB values by 90. No.

Are your eyes ready yet? Let’s continue with more serious filter efforts…

Low-Contrast and More

One of my goals with this system was to enable low-contrast settings that don’t overly impact the general color design, and rather than darkening and/or desturating everything, a better approach is to start by not using a pitch black background. This required some actual changes to the source code beyond a basic filter, since for the past five years of development I’ve assumed the background is black, but the necessary adjustments weren’t too difficult and for the most part now work via a global switch.

The idea is to choose some other dark-yet-not-black color. To avoid wasting too much time here, I used Photoshop layers to tweak a game screenshot until it was low-contrast but highly readable, then made sure the system I had was capable of replicating that process step-for-step. As usual, it’s good to have a target to work towards when designing something like this. (For the same reason I always do UI layout mockups in REXPaint first.)


Step 2 for creating Cogmind’s low-contrast mode: Raising the overall brightness, especially for darker colors.

In all there were more steps but I compressed it down to just two:

  1. Swap out the black background with the chosen new color.
  2. Adjust the brightness of all foreground colors using a formula derived from the PS testing above: y = 0.7176x + 59. This raises the brightness of most darker colors so they stand out just enough against the new background, but takes the edge off any really bright ones.

For reasons specific to Cogmind’s color design I did make a couple exceptions--the second step is skipped for any instances where the foreground color is itself black (this is rare but I use it for occasional reverse cell coloring--black characters imprinted over a solid color), or was intentionally set to match the background color (I sometimes do this to temporarily hide the foreground).

So what background colors did I pick as defaults? I started of course with my dark maroon background from the IDE color scheme I designed from scratch and have been using for the past 10 years or so :P


Some Cogmind source as seen in my IDE, the inspiration for the first low-contrast mode.

Like my IDE scheme, this particular filter is called “Autumn.”


Interacting with various Cogmind UI features in Autumn low-contrast mode.

In fact, aside from being my IDE scheme Autumn is also a REXPaint skin, and Cogmind’s other new low-contrast mode borrows REXPaint’s default skin as well: “Sleepy.”


Cogmind low-contrast mode “Sleepy.”

These modes still aren’t quite perfect due to the aforementioned universal assumption of black, though I did specifically update some of the particle scripts to be compatible with this new filter. The few features which might not always look great under this mode are some of the ASCII item art and intro/ending animations, but this only affects the small minority of areas that use their own dark background colors.

If more people start using low-contrast settings I might go back and invest more time in overcoming some of the remaining aesthetic challenges.

Although I implemented two named low-contrast filters, these are merely for convenience--under the hood they’re implemented through a more general filter: LOW_CONTRAST(R,G,B). This means you can create your own low-contrast scheme using your favorite color, or whatever you think works, I just thought I’d provide defaults for some tried and true colors :)

Map-only Adjustments

Earlier I mentioned this setting is called “renderFilter,” but there is a second one as well: “renderFilterMap.” All filters set there apply only to the map, rather than the entire application including HUD and other UI elements. It’s compatible with the same filters except low-contrast, as the latter must be applied across the entire application and cannot be limited to the map area since it’s handled on the engine side (as opposed to the game side).

One of the interesting filters more suitable for the map area rather than the UI: SWAP. This filter swaps the foreground and background color of every cell to create an even more colorful “dark on light” style rather than the usual “light on dark” terminal look.


The results of a renderFilterMap=SWAP, with no other changes to the appearance.

I don’t think this is as good from a parseability standpoint since it somewhat separates color from the character it’s associated with, but maybe it could fun to play around with, plus some players can get used to or even enjoy anything :)


Destructive ASCII action in Swap mode

Notice that these are ASCII examples, because although it’s monochrome the default tileset uses multiple shades, and the whole look is not very compatible with this kind of swapping.


Yeah I don’t think so.

So if you’re interested in trying out this mode I hope you like ASCII, otherwise we’ll have to wait for someone to draw a non-shade monochrome tileset that focuses mostly on solid shapes and symbols. I’m sure we’ll see something like that eventually. It could look pretty cool (and of course also work in the default/non-swapped mode as well, so the idea is that we’ll get that one first then it can be simply swapped over).

Good news is the Swap filter is both compatible with and looks even better when combined with low-contrast mode!


Cogmind ASCII map with both a Swap filter and Low-contrast Autumn filter enabled.

All these customization features are explained a bit more in a new “Color Customization” section of the manual included with the next release (Beta 5).

Specifically with regard to color blindness, I haven’t gotten any real feedback from players who need more options in this regard, though from the start I’ve tried to design the UI such that as much info as possible is conveyed through multiple channels, color only being one of them, so maybe there isn’t much demand for additional features there. I could add new filters if necessary, and although individual color swapping would be problematic (primarily because any dynamic colors are scripted and therefore calculated via formulas), perhaps there are some formulas that could be made available as filters to adjust the final color palette that way.


Bonus GIF: Cycling through various display adjustments in real-time after hooking up the color filter parser to the debug system :D

This post Color Customization originates from Grid Sage Games.

by Kyzrati at January 10, 2018 01:20 PM


2018 Plans

And thus ends 2017: all things considered, a rather disappointing year.

Looking back, it was probably the third worst year of my life (the worst being 2013 when I developed my chronic illness, the second worst being 2014 when I was coming to terms with it). I spent half of 2017 in a deeply toxic working environment which had a significant effect on my mental and physical health. I managed to get out, but became completely burned out from writing my book, and after that a complication from the life-threatening illness/injury/trauma of 2013 developed, and triggered a profound change in my emotional and mental well-being, which – six months on, and a very tough six months it has been – I’m finally now starting to get something of a handle on. As long as nothing else happens (I’m too young for this shit, frankly), I think I’m on the road to recovery now. I’m now settled in Canada, working in a great environment and enjoying being in a great new relationship, and these are damned good foundations for getting everything else back on track.

So, what did get done in 2017, and what will get done in 2018? Well:



Finished My First Book. Much of the first half of this year was spent finishing my upcoming first book, The Unpredictability of Gameplay, which is now officially “in press”. Situated somewhere between game studies, game design, and a number of wider engagements with the history of play, various kinds of gambling, and a range of other elements, the volume seeks to develop a framework for thinking through the different “kinds” of unpredictability that exist in games, and in turn to explore a number of interesting cultures or implementations of unpredictability (procedural content generation being one of the case studies!). It was a challenging task this year to write it, which definitely contributed significantly to my burnout, but I’m very happy with the final product. More will appear here about the book once we have a fixed publication date, but with my first ever monograph completed, it’s definitely one of my big successes of 2017.

Almost Finished 0.8. So it didn’t get finished, but a lot of extra work did get done, and it is closer to release than it was a year ago. The NPCs are basically finished, the conversation system is basically finished; this release has been a huge task, and far bigger than I ever imagined, but I’m pleased with what I got done in 2017, even if it wasn’t as much as I hoped. In the extremely difficult circumstances throughout the year, I’m happy with the coding I managed.

Moved To Canada. In 2017 I finally moved out of my home country of the UK and have now settled in Edmonton up in northern Canada, where I now work at the University of Alberta. Moving oneself 4,200 miles away is not just a major practical effort in terms of the transporting of objects, booking of flights, and all that, but also a tremendous administrative one – whereas administrative things build up piecemeal when living in one’s native country, moving to a new country means that one has to do everything, from health to housing from insurance to payment from bank accounts to mobile phones, all at the same time. This is then further complicated by the fact that some of these are contingent on some of the others, making the entire task quite dreadfully confusing. Nevertheless, this is now all done, and I’m comfortably settled in here; this was a big task which was simultaneously exciting and daunting, and I’m glad it’s done.

Wrote Many Many Papers and Chapters. Ordinarily I wouldn’t class this as an “achievement”, being just the standard activity of a (young) academic, but in such a hard year I feel that it is actually worth mentioning. I got out around four journal papers and at least that many book chapters – here’s a quick list of them, and some links for where you can read them if you’re interested.

“It’s like the gold rush”: the lives and careers of professional video game streamers on This paper is the first paper to emerge from my ongoing research project into Twitch, and focuses on the experiences of professionals at becoming professionals, being professionals, and how this status changes and reshapes their lives.

Gamification: What it is, and how to fight it. This paper was co-authored with my colleague Jamie Woodcock, who I will also be co-authoring my second book with, and in it we explored two different kinds of gamification, how to fight against the mainstream of gamification, and what a “true” gamification really looks like.

Gaming-value and culture-value: understanding how players account for video game purchases. This paper was co-authored with Yinyi Luo, a late-stage doctoral student and good friend, in which we examined why people pay for pre-order and why people buy games on Steam sales (and the like) with no intention of ever actually playing them.

Making science fiction real: neoliberalism, real-life and esports in Eve Online. This paper was published just a day or two before the end of the year, and examines some of the ideological content of Eve Online, how playing Eve affects the “real-world” lives of its players, and Eve’s esports competitions!

If you don’t have University access, some of them are already available on my page, and the others will be in the next few days. Finally, alongside these papers, I also worked on a lot of book chapters; here are some of the books I either wrote something for in 2017 (to be published in 2018), or had published in 2017:

As above; although it’s standard practice for my job, in such a hard year, I’m glad I still managed to get out such a large volume of work. Quite a few papers I wanted to write didn’t get finished, but more than enough were.



In previous years I’ve almost always met the lofty goals I’ve set myself, but for 2018, I’m going to tone it down a little, and focus on a small number of essential things. There are only really a few core “output” goals I have (I’m not including goals here like spending time with my new partner, keeping fit and healthy, that kind of stuff, and nor am I including publishing papers, as that’s just a normal part of the academic life). But, nevertheless, I have four major objectives for 2018:

Release 0.8. This has to be done. It has been 90% finished for a year now, and it’s just getting ridiculous. My intention is to dedicate a significant block of March and April to getting 0.8 done, polished, bug-fixed, and finally released, and then I’ll be taking stock of my longer-term game design goals after that.

New Website. I think the time has come to move to a new website which more accurately reflects everything I do instead of just URR (especially as it is a smaller part of my time now than a year ago), and one with a new custom wordpress layout. I’m looking at a few possible domain names right now, but I’m pretty sure I know which one I’m going to settle on. This is an objective for some time around May or June or so this year, when I want to begin shifting everything over there. With URR becoming less of my focus, and my academic work becoming more of my focus, it seems strange to keep this as my domain name, honestly. Equally, it is a difficult one for people to read and make sense of, it’s difficult for people to say, and so forth, and I’ve run into this issue now more times than I can count. For the same reason, my Twitter account is now @mrj_games instead of my old account name, for this is both a more general handle, and a more easily-conveyed one as well. More on this in the next few months, but by the end of 2018 – hopefully more like the middle of 2018, but let’s see! – everything will be moved over there.

New Blog. Closely related to the above – as well as a new website that reflects more accurately my broader games interests, it is also time to reshape “the blog” in a similar way. There are two ways the blog will be reshaped, and two reasons for it. Firstly, the blog will continue to shift from a “dev blog” into a “dev and general games commentary blog”, and secondly, the blog will shift from a “weekly” blog into a “monthly” blog, and one without fixed monthly deadlines; a post will appear some time in each month, without precise timings enforced up-front.

The reasons for these changes are twofold. In the first case, although URR remains an active-project-on-hiatus and not an abandoned project, my academic games work is my central focus now, and will be indefinitely. This means my blog should reflect this, and should reflect what I’m spending most of my “games time” doing. In the second case, once the blog update schedule drifted away from weekly in 2017, I came to realise how much of a stressful pressure weekly updates had become. When I started the blog they were an exciting, enjoyable thing to look forward to every week, and something to help guide and centre my thoughts, but this is no longer the case. I’m not quite sure when this change took place – as with all gradual things, one only notices it when one is startled out of complacency and compares the present to the distant past – but it definitely did. This means I need a blog update schedule devoid of pressure, but one still with a degree of regularity, and monthly updates are definitely the way to go on that front.

So, as part of the transition to the new website, the shift to the new blog will take place in stages. Stage 1 will be continuing to post here as the new website is acquired and developed; Stage 2 will be co-posting everything on here and the new blog, but with a link over here that points to the new site; and then Stage 3 will be posting everything on the new blog, and putting up a front-page and top-of-blog notice on this site redirecting  readers to the new site. From that point on my intention will be to retain this website indefinitely (at least for quite some time) in order to direct interested readers to the new one, but posts will no longer appear here.

So yes: the new blog will be on a new website, will have a monthly update schedule, will cover general games commentary as well as game development, and will hopefully end up looking rather nicer than the present site does right now (not that there’s anything wrong with the WordPress standard, but it’s time for something a little more personalised, don’t you think?). I’m really excited about this relaunch, and there will be more information on it in the coming months.

Finish Book #2. My second book is already well under-way, on a more relaxed schedule than my first, and using a lot of important new knowledge I learned from the first book to help me write the second in a healthier manner. A proper announcement will be coming at some point a little down the line, perhaps once we have a cover to show, but basically the book is about Twitch, live streaming, and the labour politics of the games industry more generally, including that surrounding sponsorship, promotion, games reviewing, and the like. We’re (my co-author and I) currently hoping to have it released some time around the middle of 2019, as there’s a particular deadline we want to meet. Again, more on this soon!

Final Thoughts

So there you go: 2017 wasn’t the best, 2018 will hopefully better, but I’m scaling back on my ambitions in order to build things back up in a more sustainable way for the future. I’m excited for the future after a terrible year, and I hope you all are too. More from me soon!

by Ultima Ratio Regum at January 10, 2018 08:49 AM

January 03, 2018

Roguelike Radio