Refactor Swing View and Event Code

This is a resubmit of my previous pull request to the Android branch instead of master.  Sorry about the delay.

Overview

This pull request refactors much of the core DroidQuest code with the goal of making a future Android port feasible. I apologize for its size - this pull request rearranges a fair amount of the core code and I wanted to have a complete story before merging in case something went wrong. Because of its size, this pull request is best considered in chunks, which I'll detail below.

Removing controller logic out of RoomDisplay

Commits a21778b - ec5b650

RoomDisplay had a lot of responsibilities. It was the primary view class, but also had all of the controller logic for the game as well. Because it's a swing panel, RoomDisplay can't exist in android. Therefore, I split as much controller logic out of RoomDisplay as possible, changing RoomDisplay to be a pure view class.

Splitting rendering code out of RoomDisplay

Commits 1986d10 - 37d0e51, ee7667a

Even as a view class, RoomDisplay still had quite a bit of logic attached. As a result, I split the rendering logic into a separate class RoomRenderer and refactored each step of the rendering pipeline into separate classes. Also moved rendering code out of model classes like Wire, Room and Materials out of the models and into corresponding view classes. Unfortunately, due to complexity, Item classes still have embedded rendering code, at least for now.

Split DQ.java and DQFrame.java, Created SoundPlayer

Commits fd80aef - e2e995d

Split more environment specific code and services out of the Spring view (JFrame) class and into separate classes.

Operations

Commits 6e33997 - 49e99eb

Event handling code that responded to user key presses and mouse clicks was located in model classes like GameCursor and SolderingPen. Having the event handling code in the model classes would block an android port because android event handling differs from the awt/swing. The first step in moving event handling code out of the model classes was to take the code run for each event and extract it to an Operation (Command) class. These commits took all the event handling code for keyboard and mouse events out of the Item avatar classes and moved them to Operations, created by an OperationFactory. In this way Swing environments could use a different factory to create their Operations than android, but the invoking logic would be the same.

Move Event Handling code out of Items

Commits 82e4f0b - ded8160, 72d20ce, a6efe6b

Having event handler response refactored into Operations makes it easier to possible to move the handlers out of the avatar Item subclasses and into separate handlers (Swing*EventStrategy). The PlayerEventHandler coordinates which strategy is active by listening to change events that are broadcast whenever the current Level or Player changes.

Control Panel

Commits a1882b2 - 1be6966, 21a77d8

This is really more a proof of concept than anything else, but the ability to add a control panel is really a consequence of the Operations and Event Handling refactorings that preceeded it. The control panel is incomplete and the icons used were more or less randomly scraped from google image search. The cursor pad also needs to be completely reworked. However, it is still functional, and provides an alternative to keyboard input, as well as a bit of a UI preview for a tablet port.

It's currently disabled, but can be enabled by adding -DenableControlPanel to the jvm arguments when starting the application. Give it a shot, tell me what you think...

Maven Build Enhancements & Runtime dependencies

Commits d287650, 21a77d8

In the process of coding the above, I added two (well, three really) runtime dependencies to third party jars. The first dependency is slf4j and logback for cross platform logging capability to replace System.out. The second dependency is guava, for predicates and EventBus for events.

To handle the new dependencies, I added an assembly task to the maven build. Now when you build dq using "mvn package", maven will create 3 separate bin (.zip, .tar.gz, .tar.bz2) distributions in the target directory. Unpacking the distribution will reveal the droidquest jar, the third party jars, the assets (sounds, images, and chips) as well as pair of shell scripts (dq.sh, dq.bat) that can be used to start up droidquest.

Summary

There's not a lot of new functionality here (other than the control panel, which is not really more than a POC). However, I think that these changes are worthwhile on their own accord, and pretty much a prerequisite for an Android port.

However, all in all, it's a big change. Feel free to create a new branch for these things if you don't want the changes in master, or if you prefer, you can just ignore this pull request altogether, and I'll just keep working on a fork.

Cheers!
﻿