Refactoring Complete

I had previously coded up a bunch of library code for my roguelike game engine. My first idea was to hold all items in a big array. When the items were picked up and them wielded, the item state would change. Then I had a bunch of custom code that switched on the state.

The problem was that most items get removed and regenerated during change of dungeon level. I did not want my players inventory and equipment to disappear when the dungeon level changed. So I needed a refactoring. I decided to create separate containers for the player inventory and the player equipment. Today I refactored all the code to use this new design.

I was pleased to see that much code was simplified. Many functions were no longer even needed. The code was getting really clean. This must mean the redesign was a move in the positive direction. This shall also allow easy changes of inventory/equipment rules in the future.

Not sure what I am going to do next. I am still riding a high of a good code refactoring. It is probably time to implement some more functionality in the dungeon.

Storing Items

I am building a library to help with the development of a roguelike game. Got the maze generation down pat. Next I added items such as weapon and armor to the maze. I implemented these items in a big array. The items knew where they started out in the dungeon.

As the player picks up and wields the items, the items change their location. This was working like a champ. Then I realized the items were tied to the dungeon. The dungeon gets regenerated on each level as the player walks up and down the stairs. Ooops.

I don't want the players to lose the items in their inventory or on their body when they navigate the dunegon levels. What I should have done is to separately manage the dungeon objects and the player inventory/equipment. Then I could move the items from each of these containers as the player picks up or discards the items.

This design change will require some refactoring. While I am at it, I might as well change the containers from arrays to lists. That will make the adding and removing a whole lot easier.

Maze Mechanics

Every year I enter a contest to see if I can create a game in seven days. It must be a roguelike game. Usually I write it in a language that I am comfortable in such as C++. I only tried writing my game in Java once. It was disappointing to say the least.

I learned a lot of Java over the past over the last few months. I am ready to try my hand at a Java roguelike again. But first I thought I would practice with some roguelike library code. You know. I need to knock out some mundane stuff to be proficient for the real game design.

Right now I am wrapping up the basics of maze drawing. I got some rooms connected by halls. Good stuff. The only problem is that the user can navigate around the maze. When I get too close ot the side of the maze, I have some coding problems.

The maze display is based on an array of BufferedString objects. I just index into them based on where the player is on the maze. I keep the player in the center of the screen. So when the player reaches the edge of the maze, we are faced with drawing cells that do not exist in the StringBuffer.

Now an elegant solution would be to detect this and somehow append some virtual walls outside the edge of the maze. I might still opt for that grand solution. For now I am trying to hurry up and get stuff done. So I extend the edges of the maze in all directions to create an outside buffer. This ensures you can use the same dumb code to index into the BufferedStrings even when at the edge of the navigatable maze. Nice trick huh?

The Outstanding Breakout

My advanced Java community college class did not have a final exam. Instead we needed to submit a final project. The instructor came up with a couple ideas for projects we could do. He also said he was open to other ideas upon his approvel.

Initially I thought I might develop an electronic football game. Nothing like Madden. This would be a clone of the old Mattel hand held electronic football games from the 70's and 80's. Then I saw the idea of writing the arcade game Breakout and I knew I had to do it.

The funny thing about the final is that most students opted to do the mortgage calculator. That has the advantage of being easy to do. The instructor provides the GUI and the equations to figure out mortgage payments. The student just needs to implement the equation and hook it up. Boring.

The basic breakout game was pretty easy to implement. I had already coded some exercises with balls bouncing around the screen. I concentrated on my intro and game over screens. I alsmot used this game as a place for some demo graphics on those auxiliary screens. I also concentrated on game play. Another student was excited to play my game and give me UI feedback. In the end I spent a lot of time developing this game. My instructor called is amazing and outstanding.

The real win from this game is the stuff I learned from doing it. It is now a part of my JAva portfolio. Yeah I could have done the mortgage calculator. But where's the glory in taking the easy way out and cheating myself?

Maze Design

I am struggling on how to internally represent my roguelike maze. Currently I maintain a 2D array as well as an array of StringBuffers. The array is used for easy lookup of objects in the maze. The StringBuffer is used to quickly generate a string to draw on the screen. The problem is that I need to update both structure every time something moves in the maze.

I could just keep the 2D array. Then I could generate the Strings on the fly as I need to display. However I do a lot of display updates (whenever the player moves). That might take a lot of time to generate an 80x25 worth of character Strings.

Or I could just keep everything in the String array. Then I could index into it when I need to check different cells of the maze. That just does not feel as natural as the separate 2D array though.

Breakout Performance

I coded up an epic game of Breakout. Most of my effort was spent on my intro screen. I also spent a good deal of time on special effects for the high score screen. The thing rocks on my development machine. But I ran the same game on a laptop with limited hardware, and the results were disappointing.

The intro screen draws a lot of random lines to produce a static effect. It also draws text in increasing font sizes that get really big. This screen works but is painfully slow on the laptop with limited hardware.

Luckily the main game mechanics adjust themselves according to the amount of time it takes to render the game screen. So it plays well whether there is high power hardware, or limited resources. I should have done that with the intro screen as well.