Object Oriented Programming

When I was setting up my game engine, and even when developing my game, I took the time to create a nice class hierarchy. It took a little extra time. I did not go overboard. There may have been 15 classes tops. And some of those were small subclasses.

During a final round of testing, I found some of the text was coming out wrong. That was disturbing as the text worked fine in some scenarios. I traced it back to find some code doing extra work to get the job done right. To fix the global problem, I moved that code to a base class. Then everyone got the fix. I did have to tweak a few instances where the specific code made some wrong assumptions. But I essentially fixed the problem in one location. Bonus.

As an aside, I find the Java Collections Framework very helpful in developing games. Now I cannot imagine how I lived without them. Oh yeah. I used arrays. Painful. Luckily there is no more of that pain in my projects.

JDialog to the Rescue

I had a requirement to display a list of choices in a window. Furthermore I wanted the dialog to be dismissed as soon as the user pressed a key. Turns out the JDialog was the class I needed. Mapped the keys of interest to a listener and I was good to go. But then I needed to handle the display of the dialog.

I must confess that I really did not have that much experience with JDialogs. Found out that it defaults to a BorderLayout. For my application, I needed more of a GridLayout. I surveyed a bunch of code on the web while searching for my solution. Learned that I could call the pack() method to size the dialog with the minimal amount of space required to fit the contents.

I had one hiccup where I wanted to map the keys with the JRootPane. Thought I needed to do that when I created the JRootPane in createRootPane(). Unfortunately that method gets called from the superclass. I could not pass it any data. That's okay. I found I could later call getRootPane() and handle my business.

All About the Keys

I wanted to provide an easy to use interface in my latest program. At times I put up a dialog where the user must choose a value. I want the user to be able to just press one key to make the choice. Initially I tried using the JOptionPane. But it required the user to press enter after making the choice.

I thought I needed to somehow specify an option (no pun intended) for the JOptionPane to just require a keypress. After a while, it felt like I was hacking to much to get this to work. I seemed to need to set some weird user interface options, then set up some maps, and I was still struggling to figure out which key got pressed.

Then I researched some mneumonics. Turns out those require you to press the Alt key along with the choice you make. No good. Finally I figured I needed some custom code. I forgot about the canned JOptionPane and started concentrating on a straight JDialog. Got an assist from the Java2s web site. A map plus a listener was all I needed. Now I am going back to the basics of drawing some user choices on the dialog. That should be a snap. I wish I knew to go straight to the JDialog in the first place. I been spending most of the day on this issue.

Anatomy of a Framework

I have known for a while that I was going to use Java to develop a game to enter this years 7DRL contest. The last time I tried using Java to compete in such a contest was disastrous. I did not know how to do any graphics. That puts a cramp in your game development abilities. This time I was going to be prepared for a strong showing. Therefore I started working on a gaming engine well in advance. You could call it a framework.

I figured I could just use a toy app to develop, mature, and test my framework. That worked out pretty well. I got some good code written and tested. The problem was that the framework became highly coupled with my sample application. Now that I am trying to make use of the framework for the real thing, I find myself ripping out the example code to get at just the engine.

Note to self: create an API that is truly separate from any demos. That way I will be ready for reuse. I guess I need to put that to the test early as well. I should have created a second sample app that tried to use the framework. The issues would have been clear from the beginning.

Acronym Hell

I just saw a massive blog post on developing a web app. Not only was the length of the blog post long, the list of related technologies was large. The post is going to hit JSF, CSS, EJB, DAO, JPA, JAAS, MVC, and MySQL. I have done a little bit of web application development. But I did not recognize all these terms. I guess you got to keep up.

So far I have only checked out the first piece of this blog post. I plan to go through the whole thing. This just seems like a lot to take in to do web programming. Then again this makes web developers more in demand if the skill list is huge.

The question I keep asking myself is whether I want to get into all this. The pain would be that the technologies would become obsolete or replaced just as soon as I master them. Such is life I guess.

Move to JavaScript

I have been sick for the last few weeks. So my Java roguelike game engine has been put on hold. That's okay. I shall enter a contest around March of this year to develop a game with the engine. I suspect I shall be doing a massive amount of Java coding that week. The engine will get some bug fixes and updates as a results.

The Spring school semester is just about to start up. I am taking an intro JavaScript course this time around. I plan to stop my Java learning for a few months to concentrate on the JavaScript. By summer I should be back in full swing with Java develoopment.

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.