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.

Symbology

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.

Skyrimmed

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.

Equipment

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.

Weaponry

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.

Plight of the Halfling

I spend a lot of time playing Angband these days. My name is Thread. I am a Hobbit Warrior. My super strength and dexterity allow me to swing my katana fast to chop down my enemies. These stats do not come naturally. I wield rings and gloves that boost my abilities.

I am a bit concerned about my health. Not that I am sick. But I do not have the reserves required to take many blows in battle. I search for the potions to cure this deficiency. But old Drago in the black market refuses to stock such items. I return time and time again to find other nick nacks for sale there.

I cannot fault Drago too much. He did find and sell me a wonderful chain mail that resists all kinds of attacks. Good stuff. Now if only I could locate an item to prevent the attacks that leave me blind, I shall be ready to dive into the dungeons fo Angband.

Notch Getting Busy

Recently Notch, the creator of the game Minecraft, participated in a 48 hour game creation contest. He spent the two days coding up a game from scratch. Notch has a lot of fans. About 10,000 of them watched as he streamed his computer screen while developing a game. Apparently this was an epic experience.

Notch banged out Java code. He did not need to Google any specific topics. Damn. The guy must know his APIs. The result was a 3D game that wss running a few hours before the 48 hour deadline. We need this guy participating in some roguelike 7DRLs. He might create something revolutionary.

This guy does have a day job. He works on his Mincraft game, as well as some other new games coming out from his company. You got to give this developer credit. He know how to knock out code.

Creepy Girl

I just stumbled upon this web site of a weird girl. On the web she is known as creepy girl. Her eyes track your mouse pointer. At first some thought this was a hot 3D rendering. However that theory has been debunked. It is really a bunch of photographs that are layered to look like 3D.

So So Rogue

I got an iPhone this past year. The apps looked just too delicious to pass up. I downloaded some that my friends had. Then I searched for some myself. I also tried out some apps that were on the top of the popular lists. Finally I tried out Rogue for the iPhone.

Now all of the elements of a roguelike were in there. But the game did not keep my attention. I think the problem was the navigation. One of the fun things about roguelikes is the ability to control actions through the keyboard. The iPhone usually wants you to touch the screen to perform actions. This just did not translate well for the Rogue game.

I have since removed the app. Not sure if it was a free one, or a trial one that would require payment later. Either way I was not going to play it. Perhaps there will be an Angband port to the iPhone some time in the future. I would give it a try. But it needs to come strong.

False Advertising

I was reading about a company taking developers to court. Then I saw an advertisement on the page that looked interesting. There was a hot chick on display. I was "game" for it. So I clicked through.

It turns out this was some sort of war game. I should have figured that out since the game was called Warflow. Still I wanted to cash in on the hot chicks. They were nowhere to be found. Thus, I got the heck out of there.

I understand that you want nice graphics to lure people to come play your game. But if you don't want people to bolt, choose advertising images that match your game please. Otherwise you fail.

Duke Nukem Returns

It looks as if Duke Nukem Forever is finally being release next month. This thing has taken 14 years to come to fruition. It is due to the work of Gearbox Software, 2K Games, and apparently a host of many other.

I read through many comments of people responding to the news of the release. They were mostly cheering. Myself I am a bit skeptical. Haven't they promised release dates many times ago? We shall see next month if this thing can actually be ordered.

What the heck happened that it took so long for a release? Ouch. I guess modern commercial video games are a difficult beast to manage and develop.

JSRL Version 1.3

Previously I had mentioned that my game JSRL did not work right under the Google Chrome browser. Yes it was true. But all that is a thing of the past. I just released JSRL version 1.3. And I fixed the Chrome bugs.

The layout of the game did not look well in the Chrome browser either. That got fixed as well. Functionally I added a bunch of different monsters in the game. I have not rebalanced the game as a result yet.

Here are some tough monsters I added to the game: basilisks, minotaurs, rocs, vampires, beholders, golems, liches, and nagas. There are also some other new monsters that are easy to beat like skeletons, orcs, and ogres. Next time I want to try to add a town level to the game.

Chromed

I had a friend do some testing on the latest version of my roguelike JSRL. She said some of the new graphics looked good. But the functionality of the game was broken. That was strange.

I did a quick test using Internet Explorer. The game mechanics worked fine. Then I tried Firefox which gave me problem before. It worked good there. That's when I found out my friend was running Google Chrome.

After downloaded Google Chrome, I found my game was all messed up. I fixed some of the screen layout. However the JavaScript controlling play was just not functional. Great. I got some real work to do here. I will release an update in version 1.3 of the code soon.

JSRL Version 1.2

A friend wanted to see the latest developments in my JSRL roguelike game. So here is version 1.2 of JSRL. The main addition is this version is better handling of messages to the user. I have a vertical scroller to handle that. You can see the last three lines of message on the screen. You can also scroll back to the last 10 messages.

I also redesigned the top potion of the screen. The dungeon level, gold amount, and hit points have been arranged vertically. They have also been lined up to look cleaner. All this work was for a secret new addition I am working on to put in the upper right hand corner of the screen. You will have to wait until version 1.3 to see what I have in store for you.

JSRL Version 1.1

I have released version 1.1 of my roguelike game JSRL. You can now use your keyboard for player navigation. The screen now has full information on the commands you can use. I also added an intro screen graphic.

Now I plan to concentrate on making the game more playable. I need to add Angband-like features. Definitely need a whole lot more types of monsters. I also want to add different items you can find like weapons and armor.

For now I plan to continue improvement on my game. Let's see how far I can take this.

More work on JSRL

After a short hiatus, I have started development on JSRL again. This is the roguelike I entered into the 2011 7DRL competition. Now it is time to complete version 1.1.

At first I am going to go after some low hanging fruit. I will start by allowing navigation with the number pad. That will involve new diagonal moves as well. Then I might internally redo how I draw the maze to the screen. Right now it is very inefficient. I redraw the whole darn thing when something changes. An incremental change will be to redraw the line that got changed.

If I get ambitious, I might try to add an intro screen. Sure I could put some lame text intro screen in there. But I hear you should really rock your user with a cool graphic intro. So let's see how far I get. I will post a link to the new version of the game as soon as I code and test it out.

Building a Roguelike

I skimmed through a book on building your own roguelike game. It was free so I thought what the heck. The book covers programming in the BASIC programming language. It also goes into detail of the code for a specific game.

The book recommends you do a nice graphic intro screen. It also states you should use a graphic screen for your game, even if you are displaying ASCII symbols. Here is an idea. Put an easter egg or two in your game.

There are many methods for dungeon generation. You could start with one room, draw a corridor, then draw the next room. Or you could split the screen into quadrants, draw rooms in the quadrants, then connect the rooms with corridors. You could also use a perfect maze algorithm. Look it up.

I had some insights for my own roguelike game while reading the book. For line of sight issues, you can use Bresenham's algorithm. Once again look it up. You can also use the numeric keypad with Numlock turned on for character movement. That way you only need to detect the "1", "2", ... "9" keys for movement. I need to also implement monsters running away when they give up on battle.

Defender of the Deep

I am checking out other early finishes in the 2011 7DRL contest. Next up is Defender of the Deep. The actual graphics for the dungeon maze are simple but good. I like that empty spaces in the dungeon are just plain black.

Looking at the scrolling messages at the bottom of the screen, I realized how I should have coded up messages in my game. It was nice that some messages were color coded too. I did notice a lot of attacks in the game came with the message that no damage was done. Dang.

One weird thing about the game is that a DOS style box comes up, but you play the game in a second DOS style window that is a bit bigger. The menu system in this game is top notch. It presents you with a list, you press one key, and the choice is made. I am used to Angband where I need to select an item, then press another key to confirm the selection,.

My first attempt at playing the game was somewhat successful. Nice game balance. I don't like games that are too hard. There were many healing potions on dungeon level 1. I picked up a club on dungeon level 2 briefly. It got quickly replaced with a glowing broad sword. Woo hoo. Have not died yet. Now back to the game.

Vicious Orcs

There were a couple 7DRL entries done and posted to the announcement group before I completed my JSRL game. A nice one I tried was Vicious Orcs. Initially the game was very small in a DOS box style window. The maximize button on the window did not work. Later I found an option to toggle full screen which was better.

Some things in Vicious Orcs puzzled me a bit. At times, locations in the dungeon diagonal to you were not visible. I tried to go in those diagonal directions. But I was prevented. Every time I picked up gold, yellow squares would fall down the left side of the screen and pile like a Tetris.

There were also some cool effects in Vicious Orcs. The screen would slowly fade to black on your death. The app would also move in a direction it thought you might want to go. I would try to go left. It was blocked by a wall, but the app would move me left and down. Sweet.

Introducing my Roguelike JSRL

I have completed development on my 7DRL entry JSRL. The game is actually not complete. But I have run out of time. The entry should be a win since it was done within 7 days, is similar to Rogue, and is playable.

Today I tested the game with Firefox. It did not work. However I kept at the code until it worked in Firefox. The colors actually look better in Firefox than in Internet Explorer. I also made the message box a horizontally scrolling one.

A major addition I put in tonight was the Big Boss on the bottom level. Well he is actually not that big. He is a giant beetle. But his has a lot of hit points, and can do as much damage as you.

The majority of drive for this game from entering the 7DRL contest. I would like to refine the game, improving it, and continuing to learn more JavaScript. We shall see how much time I can spare for this effort.

Monsters

The last item I had to add to my JSRL roguelike game was monsters. This proved to be a challenging task. It was easy to randomly place monster characters in the dungeon. But then I needed to code the monsters to become aware of the player. Then the monster needed to chase the player.

The addition of monsters also required battles. I added the ability for the player to attack the monsters. The monsters needed to be able to attack the player as well. This required me to track the hit points of the player and all monsters. It also required me to start providing messages to the user based on the results of the fight.

There is not much functionality to add. I should test the game in browsers other than Internet Explorer such as Firefox. Then I would like to put a title screen in there. Finally I shall upload the game to a site where everyone can access it. Get ready for some fun.

Stairways

One of the last features to add in my JSRL roguelike game is multiple levels. I implemented this feature today. You need stairs up and down. Of course the topmost level should not have a stairway leading up. And the lowest level should not have a stairway going down.

I wanted to make the stairway movement logical. That means if you go down a stairway to get to a lower level, then you should be right at the location in the lower level where the reverse stairway exists. It was a little tricky, but I got that right. You walk down the stairs to find yourself standing on the stairway that leads back up to the higher dungeon level.

The final major feature I need to add is monsters. I am saving that task for tomorrow.

Gold in the Hills

I need something to give the players of my JSRL roguelike a score. One part will be how much gold they collect. Today I implemented placing random amounts of gold in the dungeon. Then I had to implement a gold display that shows how much you have collected so far. This display will be part of the main player stats line.

There are only two more ideas I want to implement before I call this 7DRL a success. They are multiple dungeon levels and monsters. I think I will tackle the multiple dungeon levels issue next. I want the whole game to be 10 levels. I just need to add some staircases up (and down if you are lower than dungeon level 1). Then I want to make sure the lower levels have more gold.

We Have a Player

I sneaked in a little development on my JSRL roguelike today. Got the player character to display (the great "@" symbol). I even implemented character movement.

Unfortunately I do not have a keyboard with a number keypad. So I had to remap movement keys to alphabetic characters. I think that's how the original Rogue handled movement.

It should be trivial to map the movement back to a real keypad once I test with a standard keyboard. Now I am deliberating on what to add next? Some gold? Stairs to a lower level? Whatever I choose, I will do that work tomorrow.

The Competition

I am keeping an eye on the roguelike development newsgroup to see what others are up to. There were a lot of other people starting up their 7DRL entries after I announced mine.

Some developers are making great progress. It looks as though Stygia has navigational directions implemented already. And I am not sure, but Gnomes might already be done.

Luckily you are only competing against yourself and the clock in this contest. Everyone has the ability to win if you can produce a playable game within the one week time period.

Arrival of the Maze

Made some progress on the JSRL roguelike game. Now I have drawn some rooms in the dungeon. They are of random size and in random locations. Sometimes the rooms are not connected. But it is good enough for now.

Next step is to get the adventurer displayed using the "@" sign. Then I have to process commands from the user. Specifically I want to start with navigational commands. You know. If the user presses up, the symbol moves up one position on the screen unless there is some obstruction.

I am optimistic that the resulting game after a week will be marginally playable.

Pablo is Moving Forward

I had previously played PabloQuest and had some problems with it. Turns out I did not fully understand how the game worked. Once I figured that out, the game did not seem to freeze.

I heard from the author of PabloQuest. Apparently he has a new version out. I downloaded and played this new version. Immediately I saw some new stuff. You start out a new game by stating how many levels you want to play.

This time around I paid more attention to your companion Quest. I guess he is a dog or something. Quest will go into a room and kill the monsters for you. Works for me.

There are still questions I have. For example my hit points don't seem to regenerate by themselves. I tried reading a scroll of heal, but got only 1HP of health back. Also I found it strange that I would walk right over top of gold. I got to press a key to grab it. Look here. I am always going to want to grab the gold. Why wouldn't I?

Finally I must have gained a character level, because I was asked what I want to increase. I answered "life". Not sure what that did. Maybe in the end, when the game is finished, I can read the manual.

The First Screen

I started writing my Angband clone for the Seven Day Roguelike Challenge. It was a rough start. I had programming problems getting the screen to display. There were a lot of errors. I googled the web for some help. Found a technique that works.

Now I got a screen with all dungeon wall characters. However I got some code that backs a general dungeon in memory. That dungeon is being transposed onto the screen. I guess the next step would be to carve out rooms and corridors in the dungeon.

Yeah the screen does not look sexy. But it actually displays something. That is a start. I think I will call it quits for the night. A good night sleep should put me in position to knock out some more code tomorrow. It is still the weekend.

Seven Day Roguelike

It is official. I am going to write an Angband like game in the next 7 days, or die trying. I posted my announcement as a reply in the rec games roguelike development USENET newgroup.

My game will be written in the JavaScript programming language. That means you will be able to run it in your web browser. It will be a challenge as I am learning JavaScript right now.

The goal will be to get anything running. I will be happy if I get some dungeons walls up, an "@" symbol running around, and some gold and monsters. The eventual goal is to have 10 dungeon levels and a big boss to fight at the end. But let's not get ahead of ourselves. Time to start coding.

Going Rogue

Normally I play a mage in Angband. I love the ability to identify things I find in the dungeon for profit. Magic missile and stinking cloud are great weapons. Once in a while I play a fighter. However the lack of any spell casting gets annoying.

Now I am trying out a rogue character. I just started out. The best thing I have so far is a lantern. I pretty much just duke it out with monsters like a fighter. I both a strength and dexterity of at least 18. That gives me some nice bonus to hit and damage.

I do not think this character will get far. But I bet it will be a whole lot of fun. As usual, I just need to resist the urge to dive too far.

Pablo Quest

I just downloaded and tried out Pablo Quest. At first it seemed pretty slick. The dungeon walls were drawn nicely. The keyboard controls were intuitive. Things were looking good.

Then I attacked some monsters. And the game froze up on me. I run Windows 7. I restarted the application. As soon as I got into a fight, the game froze up again. Dang.

The Pablo Quest home page declares that the game is bad ass. I want to believe it. But I need to be able to get past the problems with the game first.

Useless Death

I had a pretty good human fighter going in Angband. Just found Calris and had enchanted the hit up to +9. Then I went down into the dungeon. I felt sleepy and knew I needed to take a nap. But I was kicking butt in Angband.

Next thing I knew I fell asleep. When I woke up, my fighter was dead. What the heck happened? I had pressed the key to search for a door. Then I fell asleep. I guess my poor fighter kept searching.

Eventually the fighter got hungry, was not fed, and died due to starvation. Damn. Time to institute a new rule. If I ever had a good player and start to get tired, then it is time to end the game. Period.