July 27, 2011


I have to say that over the years I've slowly started to hate programming GUI. It seems every tool and even language has its own way of doing things and very few of them actually line up nicely. Is it really that hard to ask for a common design between them? I've played around with GUI in .NET, Java and C++ (using Qt) and so far Qt has proven to be one of the simplest solutions I've come across to date.

Qt lets you organize and setup your UI to look good and be re-sizable without doing unexpected things. There is a good separation between models and views. The best thing I like about it is how you develop is very sequential, you create your object and then define how it is setup and what it does in response to certain actions. The best part is most of the setting up is done behind the scenes, but gives you the ability to easily code it up yourself without that much effort. Oh did I mention the whole cross-platform compatibility? I'm sure most people who don't know about Qt would laugh at you if they heard you were saying C++ easily supports cross-platform development.

For Java, most of what I've done has been using Visual Editor in Eclipse and also using Netbeans. Netbeans provides a significantly more robust environment for GUI development, but my lack of comfort and familiarity with it has given me a few minor headaches. Overall, it is pretty nice and has that 'advanced' feelings in comparison to Eclipse. I'm pretty sure there are a few people out there that would agree when I say Eclipse has a childish and baby feel to it. (No I'm not a pedophile, its a figure of speech!)

I use a slightly different approach to GUI design inside of my applets. If you want to refer to the MVC model, essentially I have just Model and View, the Controller is basically added to both objects. Basically the View  is responsible for keeping track of its own state and interpreting what the inputs mean locally. Then the Model hooks up to the View and checks to see what 'state' it is in and based on that determines what it should do in response (if anything). I don't use an observer pattern for this because it is a real-time system. The Model has to quickly check the View every loop, personally having your code check the value of a variable every iteration isn't overly costly.

I'm currently in the process of creating a tool to generate serialized objects for use in my projects. The only issue is that I'm learning how Netbeans does GUI so it is a fairly slow process because of the learning. Thankfully, Netbeans really helps the programmer by providing a simple interface for setting up GUI elements and hooking up there actions. So really, don't expect many changes when it comes to my applets, but for the time being I'm planning out what I want to do next with the games anyways.

July 24, 2011

SQLite, Java and Applets

I've basically wanted to die over how painful the combination of SQLite, Java and Applets have been. Honestly, I spent well over 12 hours trying to get the combination to work and it seems to be something very few people do... oddly. I tired about 3 different solutions and the end result was still unsuccessful.

The solutions that I tried were very well designed and I'm actually very impressed at the quality of Java SQLite wrappers and JDBCs that exist. Unfortunately, they are not designed to open SQLite files located inside of a JAR file. That was basically my only real requirement for using SQLite, and it looks to me like I'm going to have to implement my own 'database system'. I could use XML, but at this point in time I'm thinking serialization could be more useful and faster. My database needs don't even require any links between tables so SQLite was almost overkill. Yes, something light-weight is overkill...

I've updated the applets with some background music, and I hacked together a workaround for my 'lack of database issue'. Probably be my next task, as I want something more 'solid' than a few text files. I'm actually curious if you can even use JDBC on a file inside of the JAR that your code is running in... So far, it appears to be down right impossible and very few people seem to have written anything about it. Oh well, it is getting late and Monday is upon us again!

July 20, 2011

Java Audio

I have to say, Java really doesn't make playing audio simple and intuitive. It isn't overly complicated, but I expected it to be as easy as loading images, apparently not. I will have to check to make sure the Applet is loading the audio file from the jar and not trying to download the song from my website every time someone runs the applet (I have a feeling that could get costly).

If all goes well not only will I have background music but also sound effects. For anyone that is interested this is the code required to play wav files: (mp3 requires a third-party library)

import java.applet.Applet;
import java.applet.AudioClip;
import java.net.URL;

public class SimpleAudio {
  public static void main(String[] args) {
    try {
      Applet.newAudioClip(new URL("YOUR_FILE_PATH_HERE.wav")).play();
    } catch (MalformedURLException e) {}

As you call tell... why not abuse the high-level API of Applet to do the dirty work? Java will automatically mix multiple AudioClips, and unlike Clip, AudioClip doesn't appear to have a length limit. Turns out to be a very easy way to do something apparently complicated in Java.

The above is obviously not code I would use for anything practical, but it is simply a way to hopefully show someone how easy audio can be added to a Java application. Now, before people ask me what 3rd-party library they need for mp3... go here: http://www.javazoom.net/mp3spi/mp3spi.html

I was going to tell the guy he should thread his Player play() method so that it is non-blocking, but it is simple enough to workaround I really doubt it is a useful suggestion. I guess a short example to prove my point:

import java.io.InputStream;
import javazoom.jl.decoder.JavaLayerException;
import javazoom.jl.player.Player;

public class ThreadedPlayer extends Player implements Runnable {
    public ThreadedPlayer(InputStream arg0) throws JavaLayerException {
    public void play() {
        new Thread(this).start();

    @Override public void run() {
        try {
        } catch (JavaLayerException e) {

Okay, good enough for me. Yes, calling close() will unblock play and exit the thread. :P

July 16, 2011

New Update

I have done most of the stuff I needed to for an update to Project X, but it really has just been too long. Only missing the actual part of the game that makes it "playable", units killing each other haha. I'm still kind of fighting a cold but it is basically gone so I have no idea how to describe it. I was given an extension on another thing I was working on so that allowed me to put in a bit of time into the game, but we will see how much more spare time I have in the near future.

Here is the listing of user stories I completed:

  • As a User, I can press a wave button when playing to spawn an enemy unit.
  • As a User, when playing I can see the number of lives I have remaining.
  • As a User, when playing I can see the amount of money that I have.
  • As a User, when I press a tower button I get a floating indicator so that I know where it is going to be placed.
  • As a User, when playing I can see the price to place a specific type of tower.
  • As a User, when I click on the board with a tower indicator I can see a tower be created.
  • As a User, I can see the unit change its path to go around a tower if it is placed in the way.
  • As a Developer, I can create a button with an image in the background.
It isn't that much right now, but I'm getting there.

July 12, 2011


It feels like a while since I've made an update, but rest assured this isn't because I'm not trying/wanting to. I am planning on doing a larger than normal update mostly because I don't want to give a bad impression. I'm also getting that sick feeling so instead of staying up and working on development. Then getting sick and regretting it, so I think I'm going to call an early night and get some more sleep.

I had an interesting idea come into my head when I was driving home the other day. Using polymorphism to also classify objects into categories, and no this isn't a new concept to me, I simply found a very useful way to apply it to games. This pretty much makes sense to anyone, but what it allows me to do is treat many different types of objects in a unified way. An example would be, I have a spawn unit which I can have inherent something called 'attackable'. This means it has methods for taking damage or getting an armor value, etc. Then I can very easily make the towers attack-able by simply inheriting that and implementing the related methods. It will make it easy to check conditions because something that is an instanceof attackable is obviously something you can attack.

For non-programmers that probably won't make any sense, so don't worry about it. Tomorrow I plan to put in quite a bit of time to development, but tonight I think sleep would do me some good so I don't get sick.

July 2, 2011

Self Documenting Code

To be fair, some documentation is always a good idea; however, one thing that I've noticed over the years is people who feel it is a requirement. Personally, comments have only been somewhat useful for me after looking back at my code from years ago. Why? Comments take up space. I fully understand how useful comments would be back in the days with heavy assembly programming, but in high-level languages such as Java or C# (no, I don't consider C++ high-level anymore, its more of a mid-high) if the code is written "properly" and written to be easy to understand (typically done by extracting common code) then comments simply waste space.

Usually, when I look up code I see it being documented, which is good, but then I also find extensive commenting where it would have been better to just write self-documenting code. Documentation is great for libraries because you don't usually have direct access to the code. When you do have direct access to code it seems to be a waste. Example, I was looking up an algorithm and the guy had written in a significant amount of comments/documentation. Did it help? No. I spent more time reading comments than code, so simply removing the comments and looking and the code alone (with a few refactorings for names) it took me minutes to figure out the code. I literally cut the content down by more than half because of the comments.

I'm I saying commenting is bad? No, it should just be done in moderation, because it takes almost more time to write it than the code itself, then take into account maintainability. Those two alone are very costly, whenever you need to produce or modify code. If you instead write easy to understand and simple code you won't even need to document. If you choose variable names that are descriptive then you won't have to sit there and refer to documentation on what epsilon means.

Think of this code inside of a class called box:

int static getType(int w, int h) {
    if (w == h)
        return 0;
    if (w > h)
        return 1;
    if (w < h)
        return 2;

So what do you think it is supposed to do? Well, lets look at it again with comments:

  *  Finds the type of box based on its dimensions
  *  a - first side of the box
  *  b - second side of the box
  *  returns 0 if it is a square, non-zero if it is a rectangle
  *  and 1 if width side is larger than the height side or 2 if
  *  height side is larger than the width side
int static getType(int w, int h) {
    if (w == h)
        return 0;
    if (w > h)
        return 1;
    if (w < h)
        return 2;

Now, you probably get what it is trying to do, but how long do you think it took me to do the second code section compared to the first one? How long did it take you to read the second one compared to the first one? And how many things do you think I would have to change if I decided to change the return type to an Enum?  So what would I write?

Well take a look:

BoxType static getBoxType(int width, int height) {
    BoxType type = null;
    if (width == height)
        type = BoxType.Square;
    if (width > height)
        type = BoxType.HorizontalRectangle;
    if (width height)
        type = BoxType.VerticalRectangle;
    return type;

So what is horizontal and vertical rectangle? Well, you don't need comments to figure out what the difference is. Look at the conditional statement prior to the assignment. What is BoxType? Well its a type of box, looks to me like it can be either a Square or a Rectangle. As you can see, this code essentially doesn't need to have comments, or documentation unless you cannot look at the source code.

Could I have changed the above code to return an Enum, sure... but wouldn't I then also have to update the documentation? :P