You can now playtest Alpha20 on Steam! To do this, opt into the dev beta branch in the game's properties in your library. For now I only uploaded Windows (both 64 and 32-bit) builds.

I'm not planning to add any new features before releasing, so if no major problems show up, you can expect Alpha20 to become official within one week.

Please let me know of any bugs or other issues!

The changes from the last two weeks include:

• Fixed the "white screen of death", which prevented a lot of players from launching Alpha20.
• Doppelganger absorbtion was made completely manual.
• New dialog with control mode commands integrated with help.
• Storage is reimplemented as zones instead of floor. This means that you can designate it over any floor or even outside the dungeon.
• Separate experience points for combat. All creatures, excluding the adventurer, can gain a maximum of 4 levels in combat. There is also a dialog which shows the details of experience gains of a creature.
• Legendary humanoids got their limbs back :)
• Added a new trigger to all main villains, which increases their aggression after 7000 turns.
• Fixed tile claiming. You can also claim furniture of destroyed tribes.

You can now playtest Alpha20 on Steam! To do this, opt into the dev beta branch in the game's properties in your library. For now I only uploaded Windows (both 64 and 32-bit) builds.

I'm not planning to add any new features before releasing, so if no major problems show up, you can expect Alpha20 to become official within one week.

Please let me know of any bugs or other issues!

The changes from the last two weeks include:

• Fixed the "white screen of death", which prevented a lot of players from launching Alpha20.
• Doppelganger absorbtion was made completely manual.
• New dialog with control mode commands integrated with help.
• Storage is reimplemented as zones instead of floor. This means that you can designate it over any floor or even outside the dungeon.
• Separate experience points for combat. All creatures, excluding the adventurer, can gain a maximum of 4 levels in combat. There is also a dialog which shows the details of experience gains of a creature.
• Legendary humanoids got their limbs back :)
• Added a new trigger to all main villains, which increases their aggression after 7000 turns.
• Fixed tile claiming. You can also claim furniture of destroyed tribes.

I'm slowly trying to wrap up this release, and with so many new features, it may take a bit of time. Steelmaking is here, as I described in the previous blog post. The steel furnace is just another manufactory, and requires a minion to attend it. It auto-schedules production based on demand, like the workshop does with traps, although the player can manually order extra steel if they have such need.

It quickly turned out that minions need to be smarter about attending manufactories, otherwise the player would have to micromanage them a lot. A typical example is when minions are forging weapons, and they run out of steel. They switch to the furnace, produce as much as they need, then go back to the forge. To make this automatic, I merged all the crafting tasks into one, and a minion will always try to work at a manufactory that's not idle at the moment. You can still change their choice by drag and dropping them somewhere else, but you can't forbid them to attend a specific manufactory anymore.



This works nicely within the crafting task, but minions still won't switch intelligently from training, studying, etc. to crafting, and vice versa. So when all production is done, they will sit idly at the manufactories. To solve this, I would need to add a priority system, like in Rimworld, for example.

Steelmaking is probably the last major feature that I added to Alpha20. Let's go into the smaller stuff now. I've added wall reinforcing, which mostly makes your dungeon look nicer, improves tile efficiency, and gives use to that extra stone lying around. You can see the new walls in the screenshot above. I've added a dedicated skill for every manufactory, and it affects minions' efficiency there. An orc won't be as good at the workshop as a goblin anymore. There is also a skill that affects mana production.

Something that I needed to do for a long time was fixing the sokoban level generation. It was always taking too long, as the algorithm uses a lot of computing power. The easiest solution was to take it out of the game, run it separately, and add a bunch of pre-generated levels to the game in the form of a data file. So it's technically not random anymore, but there are plenty of levels, and they can actually be harder, because I can run the standalone generator for as a long as I want on my machine.

Generating random sokoban levels is actually a pretty interesting topic, and it seems that there hasn't been much research on it. My current generator isn't very sophisticated, and the levels it spits out are rather easy to solve, so I want to take the time to improve it. If you want to have a look, you can find the its source code here.

I've been also looking for other puzzles to insert into the game in the form of special levels that would leverage existing mechanics (Sokoban and boulders are an excellent example of this). If anyone knows of such puzzles, please let me know.

I'm slowly trying to wrap up this release, and with so many new features, it may take a bit of time. Steelmaking is here, as I described in the previous blog post. The steel furnace is just another manufactory, and requires a minion to attend it. It auto-schedules production based on demand, like the workshop does with traps, although the player can manually order extra steel if they have such need.

It quickly turned out that minions need to be smarter about attending manufactories, otherwise the player would have to micromanage them a lot. A typical example is when minions are forging weapons, and they run out of steel. They switch to the furnace, produce as much as they need, then go back to the forge. To make this automatic, I merged all the crafting tasks into one, and a minion will always try to work at a manufactory that's not idle at the moment. You can still change their choice by drag and dropping them somewhere else, but you can't forbid them to attend a specific manufactory anymore.



This works nicely within the crafting task, but minions still won't switch intelligently from training, studying, etc. to crafting, and vice versa. So when all production is done, they will sit idly at the manufactories. To solve this, I would need to add a priority system, like in Rimworld, for example.

Steelmaking is probably the last major feature that I added to Alpha20. Let's go into the smaller stuff now. I've added wall reinforcing, which mostly makes your dungeon look nicer, improves tile efficiency, and gives use to that extra stone lying around. You can see the new walls in the screenshot above. I've added a dedicated skill for every manufactory, and it affects minions' efficiency there. An orc won't be as good at the workshop as a goblin anymore. There is also a skill that affects mana production.

Something that I needed to do for a long time was fixing the sokoban level generation. It was always taking too long, as the algorithm uses a lot of computing power. The easiest solution was to take it out of the game, run it separately, and add a bunch of pre-generated levels to the game in the form of a data file. So it's technically not random anymore, but there are plenty of levels, and they can actually be harder, because I can run the standalone generator for as a long as I want on my machine.

Generating random sokoban levels is actually a pretty interesting topic, and it seems that there hasn't been much research on it. My current generator isn't very sophisticated, and the levels it spits out are rather easy to solve, so I want to take the time to improve it. If you want to have a look, you can find the its source code here.

I've been also looking for other puzzles to insert into the game in the form of special levels that would leverage existing mechanics (Sokoban and boulders are an excellent example of this). If anyone knows of such puzzles, please let me know.

Every tile where work is performed (workshop, library, training dummy, etc) has a certain efficiency number attached to it, which affects how quickly the work is done by minions. The base efficiency is 100, and it is modified with the use of floors. The three types of floors that I've added so far (wooden, stone and carpet) add 2, 4 and 6 points of efficiency, respectively, to the nine tiles in the closest vicinity. Therefore, a tile's efficiency can grow to 154, if it has the best floor around and underneath. It is also dependent on the amount of light, and it can go down by 50% if you don't place torches in your dungeon.

I'm also planning other floor types that have magical effects on whomever is standing on them, and they will be used as part of dungeon defenses. They are yet to be designed, though.

Another feature that I planned were room upgrades, and I started with adding new types of training dummies. I also used the occasion to modify the experience leveling algorithm. The three types of dummy (wooden, iron, and steel) allow gaining respectively 3, 7, and 12 experience levels. The number is the same for every creature, so both an orc and a legendary humanoid can gain 7 levels on iron dummies. The training speed is now constant, and it takes 300-400 turns to gain a level (the number will be subject to balancing :)).

I'm also going to tone down leveling during combat, as it's hugely overpowered now. I need to figure out some clever algorithm to make it still relevant, though.



The last feature that will go into Alpha20, probably, is a new material: steel. As you know, steel is produced from iron and other elements by the means of metallurgy, and it will be the same in KeeperRL. After researching appropriate technology, and getting enough materials, you will build furnaces that produce steel plates. The amount of resources and time that you'll have to sacrifice to produce a meaningful amount will be large, therefore this will be a late-game advancement.

You'll use the steel plates to create weapons, armor, training dummies, and other nice things. Cool stuff!

I'll also test whether it makes sense to add an analogous method of iron production, such that you'll melt iron ore in furnaces to create iron plates, which will be used for buildings and crafting. It would be a nice way to add even more progression to the game, although I'm not sure if it will work nicely with other systems. Any input will be greatly appreciated.

For now, that's all folks. :)

Every tile where work is performed (workshop, library, training dummy, etc) has a certain efficiency number attached to it, which affects how quickly the work is done by minions. The base efficiency is 100, and it is modified with the use of floors. The three types of floors that I've added so far (wooden, stone and carpet) add 2, 4 and 6 points of efficiency, respectively, to the nine tiles in the closest vicinity. Therefore, a tile's efficiency can grow to 154, if it has the best floor around and underneath. It is also dependent on the amount of light, and it can go down by 50% if you don't place torches in your dungeon.

I'm also planning other floor types that have magical effects on whomever is standing on them, and they will be used as part of dungeon defenses. They are yet to be designed, though.

Another feature that I planned were room upgrades, and I started with adding new types of training dummies. I also used the occasion to modify the experience leveling algorithm. The three types of dummy (wooden, iron, and steel) allow gaining respectively 3, 7, and 12 experience levels. The number is the same for every creature, so both an orc and a legendary humanoid can gain 7 levels on iron dummies. The training speed is now constant, and it takes 300-400 turns to gain a level (the number will be subject to balancing :)).

I'm also going to tone down leveling during combat, as it's hugely overpowered now. I need to figure out some clever algorithm to make it still relevant, though.



The last feature that will go into Alpha20, probably, is a new material: steel. As you know, steel is produced from iron and other elements by the means of metallurgy, and it will be the same in KeeperRL. After researching appropriate technology, and getting enough materials, you will build furnaces that produce steel plates. The amount of resources and time that you'll have to sacrifice to produce a meaningful amount will be large, therefore this will be a late-game advancement.

You'll use the steel plates to create weapons, armor, training dummies, and other nice things. Cool stuff!

I'll also test whether it makes sense to add an analogous method of iron production, such that you'll melt iron ore in furnaces to create iron plates, which will be used for buildings and crafting. It would be a nice way to add even more progression to the game, although I'm not sure if it will work nicely with other systems. Any input will be greatly appreciated.

For now, that's all folks. :)

A few days ago I finished the big refactoring that I wrote about in the previous update, and now it's time to do more fun things. The minion management UI is pretty clunky, so I added a way to change minion tasks by drag-and-dropping them into appropriate rooms. It's much faster!



With this in place, it was easy to add a simple go-to order by dragging a minion, in case you want to quickly explore some area or order them to join a fight, without having to control them. It's more of a convenience feature than full blown RTS-style commanding. For example you can't give this order to an entire team.

With the new manual production there is potential to make minions smarter, for example have them automatically switch to whichever manufactory is producing something, or revert to training or studying. It's still unclear how to reconcile it with manual assignment, and it will probably require larger internal changes, so I'll leave this for a later update.

Right now I'm going to finish the new floor features, like efficiency bonuses, and I'll maybe add a few special "magical" floor types. I haven't decided whether I'm going to prepare a new release next, or keep adding more gameplay changes.

Let's have a quick look at some of the game statistics that the game now gathers. Since Alpha19 was released 44 days ago, 1644 players played 6103 campaign and 1253 single map games. Of the campaign games, there were 3650 keepers and 2453 adventurers.

The above numbers are nice, however it turns out that only 7% of players played 10 or more games, 21% played 5 or more. 42% played only one game (this single playthrough lasted 6500 turns on the average). This confirms that I need to work more on the gameplay, to make it more absorbing, and try to make players come back more often.

A few days ago I finished the big refactoring that I wrote about in the previous update, and now it's time to do more fun things. The minion management UI is pretty clunky, so I added a way to change minion tasks by drag-and-dropping them into appropriate rooms. It's much faster!



With this in place, it was easy to add a simple go-to order by dragging a minion, in case you want to quickly explore some area or order them to join a fight, without having to control them. It's more of a convenience feature than full blown RTS-style commanding. For example you can't give this order to an entire team.

With the new manual production there is potential to make minions smarter, for example have them automatically switch to whichever manufactory is producing something, or revert to training or studying. It's still unclear how to reconcile it with manual assignment, and it will probably require larger internal changes, so I'll leave this for a later update.

Right now I'm going to finish the new floor features, like efficiency bonuses, and I'll maybe add a few special "magical" floor types. I haven't decided whether I'm going to prepare a new release next, or keep adding more gameplay changes.

Let's have a quick look at some of the game statistics that the game now gathers. Since Alpha19 was released 44 days ago, 1644 players played 6103 campaign and 1253 single map games. Of the campaign games, there were 3650 keepers and 2453 adventurers.

The above numbers are nice, however it turns out that only 7% of players played 10 or more games, 21% played 5 or more. 42% played only one game (this single playthrough lasted 6500 turns on the average). This confirms that I need to work more on the gameplay, to make it more absorbing, and try to make players come back more often.

Between adding features and making other changes visible to the players, I spend quite a bit of time working on the code architecture in KeeperRL. It pays off given the long term nature of the project, and also because working with well designed code simply makes me a happier programmer.

There is a particular bastion of bad design that goes back to the days when KeeperRL was a simple ascii roguelike. All non-moving objects in the game are described by one type of entity, called a square (because each one occupies one square on the grid). There may be only one square at a given position, so when, for example, a chest is placed on a floor, it replaces the floor square. A square is also responsible for tracking any creature that enters its grid cell, and any items that are dropped on it.

When I added the dungeon management features, building and digging was as simple as replacing one square with another. Even cutting trees meant replacing a tree with a tree trunk. When I added graphics to the game (about 10 months into development), the squares had to remember what they replaced and draw that as a background, so you could see the grass under a tree (with ascii you don't have this problem, as each position is always rendered as one character).

As I was adding features to the game, more logic piled up on top of this design, and it stopped being pretty. The right way to do it was to have another type of entity represent all the objects that can be built, replaced, etc. It would also take care of all interactions between the static object and a creature. The change is not simple though, as a lot of things would be influenced: pathfinding, building, lighting, spreading of fire, etc. On the other hand, there was a solid reason against it: the existing code was already well tested and working.

Until a few weeks ago, when I started implementing manual placement of floors. I wanted to allow replacing the floor under an already existing object, like a door, but the existing design couldn't handle it. This was the straw that broke the camel's back, and I went and added the new type of entity, temporarily called "furniture", although it includes other things, like trees, walls, etc. These existing objects and their functionality needed to be translated to "furniture", which caused a chain reaction of other necessary changes deep in the game's internals. The resulting design will be much better, but it will need a lot of testing before it's released to the public.

Anyway, this is what I've been doing in the past week. It's just an example of what I work on, when I'm not adding new features. If some updates seem to take too long, it's because I have to embark on this kind of adventures. :)

Between adding features and making other changes visible to the players, I spend quite a bit of time working on the code architecture in KeeperRL. It pays off given the long term nature of the project, and also because working with well designed code simply makes me a happier programmer.

There is a particular bastion of bad design that goes back to the days when KeeperRL was a simple ascii roguelike. All non-moving objects in the game are described by one type of entity, called a square (because each one occupies one square on the grid). There may be only one square at a given position, so when, for example, a chest is placed on a floor, it replaces the floor square. A square is also responsible for tracking any creature that enters its grid cell, and any items that are dropped on it.

When I added the dungeon management features, building and digging was as simple as replacing one square with another. Even cutting trees meant replacing a tree with a tree trunk. When I added graphics to the game (about 10 months into development), the squares had to remember what they replaced and draw that as a background, so you could see the grass under a tree (with ascii you don't have this problem, as each position is always rendered as one character).

As I was adding features to the game, more logic piled up on top of this design, and it stopped being pretty. The right way to do it was to have another type of entity represent all the objects that can be built, replaced, etc. It would also take care of all interactions between the static object and a creature. The change is not simple though, as a lot of things would be influenced: pathfinding, building, lighting, spreading of fire, etc. On the other hand, there was a solid reason against it: the existing code was already well tested and working.

Until a few weeks ago, when I started implementing manual placement of floors. I wanted to allow replacing the floor under an already existing object, like a door, but the existing design couldn't handle it. This was the straw that broke the camel's back, and I went and added the new type of entity, temporarily called "furniture", although it includes other things, like trees, walls, etc. These existing objects and their functionality needed to be translated to "furniture", which caused a chain reaction of other necessary changes deep in the game's internals. The resulting design will be much better, but it will need a lot of testing before it's released to the public.

Anyway, this is what I've been doing in the past week. It's just an example of what I work on, when I'm not adding new features. If some updates seem to take too long, it's because I have to embark on this kind of adventures. :)