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.