Fighting Chance

I have been trying to do some balancing with my roguelike game engine. It felt too hard at the start. If you could not locate a weapon before the monsters found you, death was a sure thing. I want players to be able to survive the first level in general. So I thought I would provide the player with some default items to start.

Now at the beginning of the game, I automatically equip the players with one weapon and one piece of armor. I choose these from the maze. And I pick the least desirable weapon and armor. However something is better than nothing.

I also added the ability to quit the game. I give the user the opportunity to confirm the exit. Then the game automatically ends.

Collapsing Unique Monsters

I had previously hacked together some code that dealth with regular and unique monsters. The problem was that this code was separate. I had routines that dealth with regular monsters. And I had routines that dealt with uniques. This was cumbersome. So today I combined the two.

The breakthrough came when I decided that uniques act just like regular monsters in the dungeon. The real difference lies when you create them initially, or kill them. In both scenarios there is only one unique. If you kill it, you don't see that specific monster any more. That is unlike regular monsters such as an orc. You can kill an orc. But you might encounter other different orcs on the same level.

Next up I want to give the player a better chance at startup. Perhaps they could get a daggar and a cloak. It would give them a small fighting chance until they find better items in the dungeon.

Surrounded by Design

I made some changes to the monster movement artificial intelligence. Previously monster would try to move toward the player in the most direct route. If blocked they might try to move vertically or horizontally to align with the player. However this resulted in monsters lining up, and only one attacked the player. That was not realistic. Today I implemented the first part of fixing that.

If the monster is lined up with the player, but prevented from moving toward the player, it will try to go around whatever is in the way. Currently it will only try to go left/right, or up/down. That means there are 3 lanes available to go toward the player: (1) the direct route, one that is left/up, or one that is right/down.

Ideally I would have the monsters keep moving around to get at the player. But I think I have hit the sweet spot for now. I also modified messages in version 0.05 of my roguelike game engine. The messages show up on the right side of the main screen. They also start the first message at the top.

Next I plan to implement unique monsters, weapons, and armor.

True Message History

Previously I had added a scrolling list of messages on the main screen of my roguelike game. The list was 10 messages deep. What happens if you want to find a message older than the last 10? You are out of luck. Until now.

Today I implemented a true message history functionality. You must use the CTRL+P keyboard combination. This brings up another dialog with a history of the messages displayed. Currently I show the last 25 messages. But it should be trivial to provide some more.

I really should allow the player to scroll back really far in the message history. The history screen will need to be a little more complex. But I think I can do it. It is not a high priority. But it should be useful.

Next I want to relocate the location of the messages on the main game screen. The area it occurpies now is high priced real estate. I need that area for more important stats. I plan to move the messages over to the right side of the screen. That should not be that hard. I control all the screen locations with variables.

Message History

Previously my roguelike game engine displayed one line of messages. This meant that when multiple messages were generated around the same time, you could only see the last one. That has been corrected in version 0,03 of my game engine. Now I provide a viewport on screen that shows the last 10 messages.

I also significantly upped the number of rooms in the maze from 60 to 200. Before you could travel the outskirts of the maze and not see too much scenery. The player would get the feeling that the movement keys were not working. Now there are so many rooms that you see them scroll by even when on the edge of the maze.

Finally I experimented with different colors to drzw the maze. My computer is old and is getting some screen burn in. The white on black background seemed to be contributing to the problem. I tried a gray color. But that was too hard to see. I have settled on a light gray color. However I might create and use a custom color that is a little brighter.


Initially I had simple symbols in my roguelike game engine. But now I have taken it to the next level. Instead of one display character for weapons, I have different characters depending on the weapon type. The same is true for armor. It took a while to try to classify the different types of weapons. But I think I have it down.

Weapons fall into one of three categories. They can be (1) pole-arms, (2) edged, or (3) hafted. Pole-arms include weapons such as spears, mauls, pikes, and scythes. They also include more esoteric weapons like halberds, fauchards, mauls, and morningstars.

Edged weapons themselves fall into sub-cagtegories likes knives and swords. They also include mechetes and scabbards. Finally hafted weapons are axes, clubs, hammers, whips, maces, and flails.

Next up is improvements to the messaging system. But that is a task for version 0.03.

Versioning and TO DO List

I finally started versioning my roguelike game engine. I have declared what I got to be v0.01. This will allow me to track what changes I made in each version. It is nice to see some progress when looking back.

I also somewhat formalized the things I need done in a TO DO list. Here are the tasks that top the list. Currently weapons and armor all have the same character display. I want to make the on screen character representing the item be based on the kind of item it is. Then a staff weapon will look different than a daggar for instance.

The current implementation has one line for status messages. When one action results in many messages, you just see the last message. I want to add a scrolling message area. I also want to allow the player to call up a screen showing lots of prior messages.

One problem I have when monsters are chasing the player is that the end up stuck in a line. Only one monster can attack at a time. That is not realistic. I need to modify the monster chase AI to go around other monsters in their way.

The final important task on the TO DO list is to add uniques. This includes unique monsters, weapons, and armor. Whew. That's a lot to do. I guess it is time to knock out TO DO list item number 1. Version 0.02, here we come.


I have only heard about this Skyrim game second hand. My buddy says he sees the commercials on TV all the time. Another friend paid an extra $7 in priority shipping to get the game right away. The real surprise was when I heard people complaining about the game's performance.

Skyrim was written orignally for a console such as the Xbox 360. It was then ported the PC. Apparently some dude did a mod on the PC release to make it upwards of 40% faster. This mod took about a day to create. Customers think this shows either incompetance or negligence from software manufacturer Bethesda Games.

My game-crazy friend is a big fan of Bethesda. If anybody should know who is good, it would be him. I trust his opinion. Sure some hacker might have come out with a speedup. But did he break anything with the hack? And you got to realize that the PC market is just an afterthought. If you want the best performance from the manufacturer, get the console version. I have given up on high performance PC games a long time ago. You should too.

Level Up

I implemented character levels today. The player starts out at level 25, a relatively high level. I did this so we can skip the boring low level character advancement. I also wanted to give the player a chance to surive the harsh dungeon environment. This does not mean the game will be an easy win. You will just have a chance.

Along with character levels comes the opportunity to advance levels. I let the character gain the first couple character levels with ease. You just need to kill a few monsters. It gets harder and harder to advance after a while. I generously add more hit points to your maximum hit points when you gain a level.

In other news, I have been fixing some bugs I found. For example, when a monster was close to death, I got some errors computing damage that the monster did when hitting the character. This was because the damage done is based on the amount of hit points the monster has. I guess the random number generator does not want the range of random numbers to be too small.

Pretty soon I will have to add some more dungeon levels. I will also finally need to add unique monsters. With them will come the need for unique treasures (such as weapons and armor). A lot has been done. But there is so much more to do. Onward.

Monster Fight

Previously I had added the ability for the player to attack monsters in my roguelike engine. Today I let the monsters fight back. The monsters also pursue the player from the get go. There are a lot of monsters in the maze. So life is a challenge as soon as the game starts.

I gave and displayed the health of the player on the screen. I determined how much damage each monster does. There was a cheat involved - I let the monsters do damage according to how many hit points they have left. Now that the monsters attack the player, I need to check whether the player dies.

The monster movement continues to be a challenge. If there are no obstacles, the monster advance directly toward the player. I added the ability for the monsters to move just horizontally or just vertically if one direction is impeded. The problem is when multiple monsters are ganging up on the player. They don't know how to surround the player that well yet.

Battle Engine

I have started implementing the battle portion of my roguelike game engine. There are a lot of variables involved. To determine whether you hit a monster, you must take the monster armor class into account. You must also factor in any bonus to hit with the weapon.

Once you do strike a monster, you must determine the damage inflicted. I check the weapon you are wielding. It will do some base damage, along with any bonus damage. And if we are doing damage, the monster must have some hit points.

So far I do not have the monsters fighting back. But that should be the reciprocal activities as when the player attacks the monsters. Of course if the player runs, the monsters will most likely follow. Not sure if I want to add regeneration to the player and monster hit points yet.

So far progress is pretty darn good. I don't know whether my battle system is the exact mechanics done with Dungeons and Dragons. But it is good enough for my game engine for now. The main thing I am testing for is whether the time it takes to kill certain monsters feels right.

Roguelike Next Steps

I performed a redesign on the code for my roguelike game engine. Changed the way I stored items that were in the player's inventory or equipment list. This made a lot of the routines simpler and more generic. Now I have the power to implement additional items such as potions, rings, amulets, and wands.

But I think I might change directions. Implementing more items is just an extension of what I have already. I need something new. I think it is time to add monster opponents into the game engine.

Monsters have some different behavior. They fight you. That adds some real time battle code. Right now the controls are just the player moving around the dungeon and interacting with items. I got to consider monster movement now as well. Also need to implement the hit points system for both players and monsters. Let's see where this leads.

Wielding a Weapon

I added the ability to wield weapons in my roguelike engine. This includes the ability to take off your weapon as well. There is not much tricky about this operation. If you already are wielding a weapon, and you wield another one, the first weapon needs to go back into your inventory.

Weapon wielding was much easier than dealing with armor. Right now I only have one slot for your weapon. You either are holding one weapon or you are not. I don't have to check different armor wielding locations such as your arm (shield) or your feet (boots).

Now that I got the basics of armor and weapons down, I am rethinking how I handle them. Currently I generate a random list of them to represent what is on a dungeon level. Then I change their state when you pick the up and wield them. However the items are still part of the dungeon level. This is fine if you only have one level. But I plan to have multiple levels. I don't want your inventory or equipment to disappear when you climb the stairs down to another level.

A better idea would be to move items from the dungeon to your inventory. Then you could moves items from your inventory to equipment you are wielding. The inventory and equipment list can persist past the dunegon level. This is going to require some refactoring.


Today I just about implemented equipment in my roguelike game engine. You can wield armor. When you wield another armor of the same type, your new choice replaces the old. The the old armor gets put back into your inventory. I can show what armor you have wielded.

One thing on the TO DO list is to handle the wielding of weapons. It should be easier than armor since I only allow 1 slow for weapon holding right now. I also need to complete the implementation of taking off an item your have worn. Got to deal with a full inventory, as well as presenting the user with a list of what you are wearing.

On a positive note, I got the armor class working. The AC gets updated when you wield something. This takes base armor plus armor bonus into account. I like that. Once I finished the TO DO items, I am really going to want to create some unique armor with really high AC.


Previously I had implemented armor. You could find it in the dungeon and pick it up. Armor showed up in your inventory. You could drop the armor you picked up. Today I implemented weapons.

It turns out that weapons are similar to armor. They have a name. You can pick them up. They show up in your inventory. You can drop them if they are in your inventory. They have a symbol for display purposes.

In programming terms, I found that armor and weapons share properties and functionality. I was able to determine that these are two specific cases of the general idea of items. Once I got the item behavior down, making some weapons that are items was easy.

I hope this mean that other item types such as potions, rings, and amulets are also easy to add. I think I am getting the hang of this.

Inventory Control

I implemented an inventory dialog for my roguelike game engine today. It shows all the items you hold. It also identifies each item by a unique letter. This made it easy to implement a drop dialog as well.

There are some things to think about for my drop dialog. For example, the user must press the letter to identify the item to drop. Fair enough. But I also make the user press the Enter key to complete the choice. I really should make the choice automatic upon the user pressing the letter key.

I have also glossed over the issue of the user dropping an item on top of another item. Right now it will stack the items on top of each other. But I have not implemented what happens when you move over a space that has items stacked on top of each other. Those are small details though.

Currently I only have armor in the dungeon. So the inventory and drop features only work with armor. If I can generalize this to include other items such as weapons, potions, scrolls, and rings, then I should be good.

Real Armor

Previously I had drawn some armor on the roguelike screen. But it was just characters on the screen. When you walked over them, you could not pick them up. All that has changed now. I improved the armor system in my game.

Armor now has a name. It also has a base and bonus armor class. Both numbers are randomly generated. If you want over a piece of armor, you pick it up into your inventory. I also implemented a limit to the amount of items you can hold in your inventory.

Next immediate step is to be able to display your inventory. Then I should try getting the equipment subsystem running so you can wield your armor. Finally I should compute and display your total armor class. This game engine is coming along just fine I say.

Armor, Weapons, and Monsters. Oh My!

There is good news and bad news about the progress of my roguelike game engine. The good news is that I added armor, weapons, and monsters. The bad news is that they don't do anything.

I just got the static symbology down on the maze. You can see the orcs. And you can see some armor and weapons. You just can grab any of the items. You also cannot attack any monsters. Neither will they attack you.

The interactivity is a task that is TBD. But it looks pretty good for now. I think I shall start with weaponry. If you can pick it up, I better implement the character inventory. And I guess you should be able to wield the weapon. So I should implement player equipnment management.

First things first. I need to determine the properties of a weapon. You would think I need number of hits, damage per hit, bonus for hit, and bonus for damage. To be flexible I might also want to record the symbol for the specific weapon. That will allow different weapons to be represented differently. That would be an awesome start.

Original Colors

Now that I pretty much got my maze working, I turned the the issue of color. Currently I had the default colors which come with a Java component. Boring. And it does not feel like a roguelike. No. I want this thing to look like Angband.

So I painted the background black. And the walls are painted white. Yeah this looks like a monochrome game or Moria. But it is an improvement over the default colors I had before. Eventually I shall add some colorful colors. For now I am satisfied.

It is definitely time to fix the problems at the edges of the maze. Then perhaps I shall put weapons and armor in the maze. That shall be fun.

Connecting Corridors

I got some hall connecting my rooms now. The vertical halls do not look great. But at least they work. I try to find rooms that are adjacent horizontally or vertically. Then I draw the hall between them at the centerpoint where they overlap.

Now I only consider rooms adjacent if they are truly next to each other, and a path between them does not cut through another room. That last part is important. If I did not check for that, there would be halls running everywhere. We don't want that.

With the connecting halls I can almost move around the whole maze. I still have a problem if I get too close to the edge of the whole maze. The viewport tries to display an area for which there are no underlying cells. I have two ideas to fix this problem. The simplest is to just fill up the maze with a huge border around all sides. Or I could detect when I get close to the edge, and simulate solid brick behind the outer walls.

The View Port

I am busy working on my roguelike code library. Previously I had a "maze" which fit on the screen. Now I have expanded the maze so that it is bigger than what can be shown on the screen.

The size of the maze is not 800 x 250. You only see an 80 x 25 view port into the maze on the screen. The position of the player is always fixed. I added the ability for the player to move around the maze with the arrow keys. The maze moves around the player in the view port.

I still need to connect the rooms with passages. Then perhaps it will be time to put items on the map such as weapons and armor. I would love to get to the inventory management and player eqiupment modules if at all possible.

Library Code

I just finished my college class for the semester. This time around I studied Advanced Java. Now I should have the skills to write a roguelike in Java. Last time I tried, I was still a bit lacking.

My plans are to put together a library that handles the mundane tasks for writing a roguelike. I just threw together some code to do maze building tonight. It is just the beginning. I can create rooms and draw them. Now I need to connect the rooms with passages/halls.

I figure that in a few months, I shall have a framework that will let me bang out a roguelike in no time (or about 1 week). That way I can concentrate on the important features of the game instead of wrote mechanics.

The Children of Hurin

I purchased and finally read the book The Children of Hurin. This is a type of prequel to The Long of the Rings. The real prequel is The Hobbit. The Children of Hurin takes place thousands of years earlier. The good news is that I am getting a lot of ideas for a new roguelike game.

I am getting ideas for all kinds of unique enemies, as well as great weapons from the book. So I am reading the book a second time and am taking a lot of notes. Perhaps I shall create a game based on the book during the next Seven Day Roguelike (7DRL) competition.

Previously I did a Roguelike called JSRL. But that was limited by my experience with the JavaScript programming language. This time I will write the game in Java. And I plan to rock and roll with it.