Cataclysm: Dark Days Ahead (CDDA)

Aniket Samant, Gerardo Moyers, Joan Marce Igual, Naveen Chakravarthy

Table of contents


Cataclysm: Dark Days Ahead is a turn-based survival horror game that takes place in an post-apocalyptic world, in which there is no specific goal, and the basic aim is to survive as long as you can. The game was originally developed by Whales as open-source game under the name Cataclysm. In the days which followed, Whales brought its development to an end. The gaming community later forked the game and renamed it to Cataclysm: Dark Days Ahead (CDDA). The game is available in two graphical versions: text and graphical tile based.

It is now the property of an organization called CleverRaven. Most of the information of C:DDA can be obtained from two important sources:


By looking at the github contributions the most active stakeholders in CDDA project are BevapDin, Kevingranade, Mugling, Rivet-The-Zombie, Coolthulhu and KA101. Using the definitions of Rozanski and Woods, the stakeholders can be classified into:

Acquirers: Oversee the procurement of the system or product

The members of CleverRaven have the rights of the game. They are responsible for the budget of the project and the systems acquisitions.

Assessors: Oversee the system’s conformance to standards and legal regulations

Creative Commons Attribution-ShareAlike is in charge of the regulations and licensing of C:DDA.

Communicators: Explains the system to other stakeholders via its documentation and training materials

VlasovVitaly is in charge of uploading the different languages, and most of his contributions are based on this topic.

Developers: Construct and deploy the system from specifications (or lead the teams that do this)

Rivet-The-Zombie and outside contributors are the project’s developers.

Maintainers: Manage the evolution of the system once it is operational

Most of the outside contributors make small changes to the code to maintain it. Mugling and BevapDin make changes to the code to keep the game operational in the best way possible.

Suppliers: Build and/or supply the hardware, software or infrastructure on which the system will run

C:DDA runs with different fonts like SQUARE and GNU unifont, Catch being the suppliers.

Support staff: Provide support to users for the product or system when it is running

I2amroy and Illi-kun support the game together with outside contributors.

System administrators: Run the system once it has been deployed

Kevingranade is the most active system administrator. He analyzes the changes to be approved or rejected, and is considered the most important stakeholder of the project.

Testers: Test the system to ensure that it is suitable for use

These are the gamers and CleverRaven members. They detect bugs in the game.

Users: Define the system’s functionality and ultimately make use of it

System administrators are the users since they run the game.

The definitions given by Rozanski are really accurate, and there are also other types of stakeholders such as customers who treat the software as a product that passes through their systems. In this case they would be the gamers that identify a bug in the game and inform about it in GitHub. Other possible stakeholders are the competitors - C:DDA is a game where new worlds can be created like in Minecraft; however there is a huge quality gap between them, probably due to the latter being much more popular. Nevertheless, there are more type of stakeholders which are not contained in this project. For instance, C:DDA doesn’t have any sponsors.

Stakeholders are an important part of any architecture - when a change needs to be made, a stakeholder analysis helps address that change to the people that can actually help. This analysis saves a lot of time in the future when an update is needed.


Three stakeholders manage the changes made in the project. These are BevapDin, Kevingranade and Mugling. They are supposed to maintain the coding style. Also, making really small changes is not accepted but fixing spelling mistakes is. Bug fixes are extensively verified before they are accepted.

Solving an issue is not a trivial task. Even thought the issue is solved in terms of programming, there are some factors that have to be taken into account like the writing style and not adding more bugs instead.

Relevant people to contact

After analyzing the project’s stakeholders, four contributors have been found to have the biggest understanding of the project code and its goal. These are:

  1. Kevingranade
  2. Rivet-The-Zombie
  3. BevapDin
  4. Mugling

Context Viewpoint

Apart from the stakeholders described in the previous section, the project relies heavily on some external entities as well for successful development and release, and those are dealt with in the subsections that follow.

System Scope and Responsibilities

C:DDA is a video game designed to run on a laptop or a desktop computer. C:DDA gives the users an uncompromising survival scenario, and it also helps gamers in developing problem-solving abilities. This game only has the responsibility of entertainment for users, with the highest quality achievable.

Context schema


The game is available in the form of:

Moreover, the Experimental has two different types:

Android builds are also available, and are available on the game’s Releases page.

Development and Contributions


The game is mainly written in C++, and most of the data (mods, items, NPCs, etc.) is present in the form of JSON files. Additional scripts (lua, Python) are also used in the build process. i18n support is also added to support multiple languages. SDL and ncurses are also used.


The game can be compiled using the following:

Version Control

The project is hosted on GitHub and the Code, Issues, Wiki, and Projects pages are used for their respective purposes. Any new contribution has to raise an issue or post a pull request.

Build Processes

CMake is used for development purposes although it can build the project unofficially. For official builds, the Makefile in the project’s root directory is used.

The project uses Jenkins CI for its daily builds, and also uses AppVeyor and Travis CI for continuous integration of pushed code.


The Catch unit test framework, based on Boost libraries, is used for performing unit tests on the code.

Community Support

The project has a dedicated website, a dedicated discussion forum, a series of web tools hosted through another GitHub project, and is also supported through an IRC channel. There is also a wiki page for all the game related information.


Doxygen is used to document the entire codebase, in addition to having documentation files in the GitHub repository for contribution guidelines, compiling, etc.


The project is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License.

Development Viewpoint


CDDA is a vast project with approximately 251k lines of code (as reported by SonarQube). The structure of the files is not considered to be the best given the way everything is structured (more depth analysis done in the later sections). All the source files are contained at a single level making the code management very difficult. To get a clear understanding for the development view, efforts were put to segregate the monolithic module into components to enable clear visualization of the underlying functionality.

Module Organization

Module Structure

Most of the information is taken from the documentation 1. Each component defined in the following diagram is presented in the code in the form of classes. These components are categorized into layers with respect to their functionality and level of operation.

core: This layer is mainly responsible for setting up the environment of the game, initializing all the components that are required, and orchestrating the complete game. Every single layer given in this diagram either directly or indirectly communicates with the core layer. The core layer also in turn communicates with another layer called common layer which is mainly responsible for other supplementary functionalities.

common: Contains all the modules that are going to be processed by all other modules present in other different layers. All components in this layer are modified as part of their feedback to an action that took place as part of interaction in the game.

Vehicle Specifics: This layer contains the components that support vehicle functionalities and interface to the modules present in the core level.

vehicles: This layer contains the components whose instance are created from JSON files to make the maintenance easy. Each of these components is mainly responsible for ease of mobility of the player.

creatures: Each of the components under this layer is the living being that is either harmful or harmless. NPCs (Non-Playable Characters) could include doctor, pets, etc., while monsters include zombies, vampires, etc.

possession: Contains all the components that are modeled as behavioral attributes for the player and the NPCs. This layer contains all the components that consist of various kinds of attributes the player possesses which are represented in the form of classes to allow flexibility in interactions.

item: This layer contains all the components that are instantiated dynamically during gameplay. Each of the components defined in this layer is supplied in the form of JSON files to enable maintainability.

Common design models

As a way of reusing code, Cataclysm-DDA uses a library in order to render the game’s graphics, and the library is chosen at compilation time:

Standardized design

Cataclysm-DDA accepts all types of contributors. However, they have to respect some rules when contributing in order to be accepted.

There is a file 2 that states the rules that have to be followed. When contributing there is a commit template that is specified in the .gitmessage file 3 and that all the developers must follow. Moreover, when creating a pull request the first line of the description needs to be a summary line with a specific format that will be later used to create the release changelog.

Also, to ensure that all the code has the same style there are some styling rules for C++ defined in the document 4.

In the document 5 the contents for all the JSON files are described and the syntax that should be used in the files, there’s a total of 96 JSON files specified. The files are classified into general files describing some game messages and basic items, item files adding objects to the game, requirement files that set the required items for crafting some objects and vehicle files that describe different types of vehicles and how they are used.

Codeline Organization

In this section it is explained how the code is managed, tested and built.

The source code is structured in a “flat” form, in that there are no subdirectories within the source directory, and it is difficult to understand purely by looking at the code structure (file names) what the various responsibilities of the files are (for instance, fungal_effects.cpp or melee.cpp provide no idea what the meaning could be).


The testing system is mostly automated. Even thought testing is an important part of software Cataclysm only covers almost one third of the code with tests.

Testing framework

The project uses Catch as the testing framework. All the tests are located in the tests/ directory and every test file tests a different file from src/. Not all the code is covered by the tests since the total coverage is around 29%, this measurement is done through Coveralls.

Continuous integration

Continuos integration is a development technique used when many developers work together changing parts of the code. It is usually used every time that there’s a pull request or a release in order to check the new changes and look for errors as soon as possible. C:DDA uses Travis CI to check Linux and MacOS builds and AppVeyor to check Windows builds.

Through the CI, they make sure that the code compiles properly and then they execute the tests to check that the new changes do not break any existing code. There’s also an additional test that builds the code and deploys a new build if it is merged, it also checks for a properly formed pull request message. They use Jenkins in this last check.

Continuous integration


Cataclysm has major versions (0.C and 0.D) but the release daily builds. This means that every day when a pull request is accepted this is uploaded into the releases page.

The building process is done through GNU make. The makefile defined has different options to create a release or a debug build that can be defined when calling make. The makefile also supports different platforms so from one platform it can be build for other ones. In general from Linux it can be compiled to Windows, Mac OS or Android as a cross-compilation option.


The releases of the game are automatically created and uploaded into the release website 6 every time that a pull request is merged by using a Jenkins script.



Another way that the developers use to know how the game is behaving is through instrumentation. This is done through debug builds that print messages to the console that later can be used to understand how the code was behaving when an error ocurred. This is the default build method of Cataclysm-DDA and to disable it the flag RELEASE=1 has to be added when calling make.

Functional Viewpoint

As part of a new perspective, we chose to add this viewpoint as it is more relevant in terms of the game structure. The game is turn-based in which the player makes a move (turn), the NPCs subsequently make their own moves, and then the control is returned to the player ad infinitum. This sequence goes on till the user decides to quit the game (or is killed).

Based on this idea, the game is run in the form of a single while loop which calls several functions related to each character’s turn and their interactions related to other components. From a high-level perspective, the functioning of the game can be represented graphically as seen below

Context schema


Since the game is supported on multiple platforms (Android, Windows, OSX, and Linux) with multiple builds (Tiles and Curses), some of the platform-specific functional elements are compiled accordingly (using #ifdef). Moreover, there are mods available which are loaded at run-time depending on installations.

Game Elements and Interactions

This section is based on manual code inspection to understand what the various elements do and how components interact.

Main flow

Below are some important modules that are crucial during the run of the game.


The game module’s do_turn() function is called in every while loop iteration in the main program. This function internally performs a lot of actions in the form of calling functions defined in the game class itself. A high-level summary of what goes on in the loop is as follows (and also the associated interactions, if any):

player and NPC

The player of the game is modelled as a user object with which interactions occur. Player actions are accumulated in a data structure and then the game objects processes the actions one at a time. The user can quit the game at any point, or can be killed - each of which causes the game loop to be broken and the game to end. The game polls for player’s input in the while loop under the function do_turn().

The NPCs are modelled similar to the user object and their interactions are with the game object. Sounds and actions are processed in every do_turn() iteration.


Each components during the their initialization, register their events that should occur periodically. Few such events could be changing the daylight in the game every thirty minutes, healing wounds of the character (player or NPC) by a certain amount every one hour, changing the season in the game every three months. During every iteration of do_turn(), the registered events are checks for triggering them individually to change their state and later update their effect on other components.

Summary of functional viewpoint

Since this is a single-threaded game in which everything (game actions, sounds, graphics) gets processed in one loop, the interactions between the various elements are simple and can be understood by going through the code step by step (there’s no scope for race conditions). The inter-element interactions are mainly the ones between the character objects and the main game object instance, and the rest of the interactions are miscellaneous functions related to game startup, load/save, etc.

Technical Debt


This section deals with the technical debt seen in the project. Generally speaking from a high-level perspective, since this is an open-source game project with no major consequences of bad code quality on the end users (the gaming community), it is clearly seen that the code is not maintained up to a good standard. It could well serve as an example of how a software project could end up in a mess if not maintained from the very beginning, as will be detailed in the forthcoming subsections.


The game is written mostly using C++ 11 with JSON files for data fetching, and hence a starting point for analysis is to calculate code metrics particular to C++. Two main approaches were followed to evaluate the technical debt of the project:

Though the project’s repository provides a direct Visual Studio solution consisting of all the source code, its analysis using VS proves to be cumbersome. The Visual Studio 2019 blog provides an insight into what can be expected from VS 2019, and more specifically a good C++ code metrics analysis experience. VS 2017 does not provide intuitive tools for it, and hence wasn’t be used for analyzing the source code.

SonarQube was attempted to be used to analyze the project for metrics, but using the standard SonarScanner installation (through SonarCloud) for C++ failed to work, and hence an open source SonarQube plugin, Sonar-cxx was used instead. The following analysis is provided:

SonarQube analysis

CppCheck provides more insights about the code, as seen below.

Types of problems

We see that there are very few errors in the code, and most of the reported problems pertain to styling issues and warnings (which must not be overlooked, ideally).

In order to understand the issues related to code smells, performing an in-depth analysis yields the following data:

Code smells

A pattern is observed in the 251k lines of code calculated using the tools - some code smells stand out more than others, and the following set of code smells shows up prominently:

Code debt

As previously stated, the source code is structured in a “flat” form, in that there are no subdirectories within the source directory, and it is difficult to understand purely by looking at the code structure what the various responsibilities of the files are. If the code had been structured in a logical directory format, it would have been much easier to understand and maintain. Moreover, the cyclomatic complexity of several functions and methods is very high given the number of switch case and else if blocks present. These are very clear signs to show that the code is very difficult to maintain.

The bus factor of this project is very high (most of the code is gated by Kevin Granade) and hence there is no guarantee of it being stable in the long run, unless the core development team is distributed across more developers. This is the most worrisome factor for the project, and definitely needs to be handled to allow the project to continue being developed from a long-term perspective.

In terms of SOLID violations, the following can be said:

Testing debt

Any commit made to the source directory is through Travis CI and AppVeyor, and hence unit tests are performed on the changed code before being allowed to be merged into the master branch. However, the test coverage for the project is quite poor, at 29%, and hence there isn’t a good guarantee that the tests written would prevent issues from arising during runtime, even if the code compiles successfully and passes all ASAT tests.

The testing debt can be reduced by writing new unit tests and ensuring that any new commit that is made has associated unit tests with it. However, it puts the burden of ensuring test cases to be written on the contributing developer and does not seem to be good practice. An overhaul of tests is much needed for the project. Moreover, the presence of “mega-classes” (for instance, the file game.cpp) in the source code makes writing good tests virtually impossible.

Documentation debt

Doxygen is used to document the source code so as to help new developers come up to speed with regards to understanding the responsibilities of the various classes and methods. However, on going through the codebase, it can be seen that there is quite a lot of code that is not covered in the documentation, and moreover there is a lot of inconsistency in terms of style and volume of documenting (some code snippets are under-documented and some have unnecessary documentation). Though it is a good practice to follow a standard style of documentation and the developers of C:DDA have even provided guidelines for it it is clearly seen that good documentation practices aren’t enforced in the project. In fact, they also recommend that new developers may require to document the internals of implementations since “many classes in Cataclysm are intertwined.” This shows that they are aware of the technical debt present in the project already.

Such documentation debt is only expected to grow over time unless code reviewers enforce good documentation practices by rejecting pull requests for poorly documented code.

Defect debt

There exist lots of code snippets wherein comments pertaining to “TODO:”s and “hacks” are present, so we can clearly see that defect debts are quite common in this project. Implementing the corresponding code in the form of marking issues and through new contributions would reduce the defect debt greatly.

Evolution of technical debt

On going through the commit history of the source code, it can be seen that right from the very beginning the files have been organized in a flat structure, and hence the technical debt in this regard has simply grown over time - it seems unlikely that the structure would change, and a good understanding of the codebase would only be with the original developers.

Defect debt has also risen over the years, as can be seen below. These numbers are from commits made at some points in the years mentioned.

Evolution of defect

Given that the game runs on ideas for new features like weapons, food, abilities, etc. (for instance, see PR #29366), defect debt is expected to increase with the increasing popularity of the game.

Based on the current trend of not enforcing the writing of covering code tests, testing debt is likely to grow in size unless testing rules are enforced for all future commits.

Documentation follows a similar trend as testing, as quite a few discussions take place in the form of comments between contributors on GitHub, but a follow-up of documentation in the code not enforced.

Managing technical debt

Though the project suffers from a lot of issues related to technical debt, it can certainly be managed. The following points can be taken into consideration:

A project like Cataclysm:DDA runs on ideas provided by developers and non-developers alike for new features (weapons, food, etc.), and it is only expected that a good volume of defect debt will persist. Those features may require a lot of rework to be backward compatible, and adding them with the “TODO”s would probably be the fastest way to roll them out. This is a structural issue that cannot really have a solution in a project of such a dynamic nature, and it can only be managed, not eliminated.


This chapter was a result of analysis of the project Cataclysm:DDA. The game could be appreciated for its complexiety, which is obvious based on the fact that it doesn’t use any external game engines. The game is fully written in C++11. Unlike other open source projects where sometimes there are big companies supporting them, as this game is mainly for entertainment, the stakeholders are mostly players that play the game and also take multiple roles at developing it.

To understand the vast architecture, UML diagrams of the whole class structure and their interactions were analyzed. One major downside of the project was that it has no proper documentation of the architecture and functionality. There were a lot of efforts put to manually analyze the code through instrumentation and debug builds. On the technology front, the project has been using tools (like CI and testing) to make the development process smoother and maintainability easier.

Analyzing the project’s PRs showed the denial of new features by the maintainer. However, any kind of anomoly in the functionality is taken care by a few lead contributors. This, being a modular game, opens up space for other gamers to add MODS they wish, leaving the core of the game untouched.

With roughly 200 components in a flat structure in the game, it is onerous for one to understand the architecture and fix issues. To exacerbate the code organization, a few of the classes are humongous in length. In short, the project violates many SOLID design principles.

Upon analyzing, we suggest that it is high time that the architecture be split into modules before the maintainability goes off hand.

Annex A - PR Analysis

Merged pull requests

1. Vehicle propulsion overhaul - #19275 - (November 2016)

This pull request changed the propulsion component and added engine gears. Previously the users were creating too powerful vehicles that went at non-realistic speeds. Some contributors did not like it since some countries usually drive automatic cars and that would confuse players. Finally, after some bug fixing, the pull request was merged. However, the changes were reverted by the owner because it broke other components.

2. Better handling of item templates - #19583 - (December 2016)

Related to bug #19566 introduced in PR #19058 and was created one month after introducing the bug. This PR fixed a pointer issue introduced in the previous one and also improved performance. Most of the discussion went around whether to use or not the assert macro in release builds. Finally it was decided not to use the macro and the PR was merged.

3. [READY] Light attenuation based system for FoV and dynamic lighting - #12290 - (May 2015)

Addressed many issues related in how the light and the vision worked in the game which were part of the legacy code. The discussion first was about what should the player see during the night and then it continued with bug fixing and finally it was merged.

4. More Survival Tools Series 6 - #12405 - (May 2015)

Added more objects to the game and balanced some already existing ones in order to make the game more realistic. The discussion was focused in small bug fixes, changes that may nerf too much the game balance and how some developers play it differently.

5. Rebalance aiming and skill training - #18020 - (September 2016)

Balanced how the aiming and shooting skill training worked. It was mainly focused in changing the amount of dispersion that a bullet could have. Some developers found the new shooting range to be too short. After agreeing on a new range and some bug fixing it was merged.

6. [DONE] [CR] Field dressing corpses aka Butchery overhaul - #24480 - (August 2018)

Changed the mechanics for butchering a prey, it was related to the discussed issue #24145 that asked for development in food preserving methods. Some developers did not like the new idea but others argued that it made the game more realistic. After reviewing the code it was merged.

7. Skill training overhaul - #11695 - (March 2015)

It redesigned how the skill leveling worked from linear to exponential and removed a level cap. Everyone seem to agree with it but some developers wanted a level cap back as this topic had been previously discussed. After adding the level cap again and some bug fixing it was accepted.

8. [CR] CMake: update rules; add Linux install targets; add support for dev-builds - #11970 - (May 2015)

Updated the cmake build rules which had not been updated because cmake was not the official build system. The PR author did not have a windows machine so most of the discussion was with other contributors that could test the configuration on Windows. After making sure that it worked in every platform it was merged.

9. Zombie burner - #23729 - (June 2018)

Introduced a new zombie creature with a flame thrower. Some developers liked the idea while others thought that fire was to difficult to handle for the player and thus this creature was overpowered. After removing some of the zombie’s abilities the PR was merged.

10. Use %zu for printf-style formatting of size_t values. - #19339 - (November 2016)

Updated a printf flag to the C++11 style. Some bugs were fixed and it was merged. However, they later found out that some compilers were not properly supporting the new flag and the changes were reverted while they were updating the compilers. Finally it was re-introduced again in #19488.

Rejected Pull Requests

1. Sidebar info3 - #27809 - (January 2019)

Suggested reordering and alignment of the sidebar element which included many changes to the C++ source code that dealt with the sidebar. Contributors raised concerns that aesthetics should be given least preference. While the author argued the changes might help beginners, contributors pointed out that it could be more obvious to anyone as time progressed. This PR was superseded by another PR created around the same time leading to closure.

2. Sidebar to panels - #27439 - (January 2019)

Proposed a UI overhaul, in which the sidebar would be fragmented and involved modifying many JSON files and other source files concerned with the sidebar. Contributors raised their concern of having different text field widths for various languages. Others pointed to the unused space in the sidebar region with this PR. This PR was closed as a result of dissatisfaction among the community and the owner.

3. Reduced HP regen to 70% current value - #25628 - (September 2018)

Dealt with the regeneration of health calling the current too high. Proposal was to be reduce it to 70%. Issue related. Involved changes to the JSON files that handled the regeneration rate. The author wanted injuries to be more punishing than simply being healed quickly. The author asked for more suggestions and corrections to his comments. The author failed to give a convincing justification and resulted in closure of the PR.

4. Foundation for implementing medieval mod shields - #14711 - (January 2016)

Proposed to use off-the-hand shield which consisted of various modification to both source and JSON files. The discussion dealt with core C++ code with which the author was not confident enough. After investigating, it was realized there needs a lot of work to be done. Hence, the author split the PR into multiple PRs and closed the existing PR unmerged to favor more focused development on others.

5. Enable frostbite, remove cold damage - #18401 - (September 2016)

Proposed ways to bring frostbite into the game and changes included only JSON files relevant to armour component. Contributors brought some challenging use-cases to the author and suggested making the frostbite a gradient level. By the end of the discussion, contributors suggested that doing this would re-enable the dead-code. Hence, to merge, the dead-code was needed to be analyzed. To which the author felt he was not competent and led the author to close the PR himself.

6. Mining Mod - #18459 - (September 2016)

Author proposed to make the occurrences of metal ores more frequent and contained changes to a few JSON files. A contributor gave suggestions and offered some help in rewriting parts implementation he suggested. The owner suggested a backwards sketching and due to the lack of this, the PR got closed. This was addressed two years later by another contributor.

7. Improbable weapons mod - #18332 - (September 2016)

Proposed to eliminate some improbable weapons and had changes to only JSON files related to weapons modules. Contributors pointed that the fun in the game was usage of improbable weapons and bringing them down would only bring dissatisfaction among the players. For the amount of changes needed, after realizing the efforts were not worth and might break something else more functional, leading the author himself to close.

8. Reload using magazines - #14949 - (January 2016)

Focused on bringing more tools to the rifle magazines. This PR seemed to be very important at the very first sight and also more obvious and contained significant changes across JSON files and source files that dealt with ammo. Owner suggested that this be added as a mod first. While initially merged there were a few functional flaws with the display of ammo and lead to reversion.

9. Use SDL_gpu library for faster SDL rendering - #19412 - (November 2016)

Was meant for fixing an issue where the game was slow. It proposed on using GPU. and involved changes to the build system and source files relevant to the graphics. The author pointed a caveat to his implementation. In the midst of the discussion, the owner commented that it could be a deal-breaker. The owner affirmed that unless this change got tested on a software-rendered build, this PR would be left unmerged.

10. Increases blocking ability of smaller shields - #21503 - (July 2017)

Wanted to increase the blocking capability of smaller shields and included changes to JSON files related to the shield component. The author found the idea of increasing blocking ability for smaller shields not right in its essence. As the owner was ignoring the changes the author himself closed the PR.


  1. Module documentation, 

  2. Cataclysm-DDA rules for contributors, 

  3. Cataclysm-DDA git commit message template, 

  4. Cataclysm-DDA code style rules, 

  5. Cataclysm-DDA JSON file contents, 

  6. Cataclysm-DDA Linux Tiles releases,