# Component Architectures vs Class Hierarchies

After putting Sprite Clipper into a holding pattern, I started looking for a new nerd hobby.  I figured I would naturally progress into using slick2d, the Java game architecture that first set me off to make SC.  I didn’t have much of an idea of what kind of game I wanted to make, so I thought I would investigate different architectures to get some inspiration.

That’s when I ran across component video game architectures, which totally eschew object-oriented programming concepts.  This was completely new to me.  The gospel of OOP had been preached to me in nearly every context I came across it.  But, after reading some articles about the component paradigm, I began to see the drawbacks of class hierarchies.

The main goal of component architectures is to reduce coupling between various parts of the program as much as possible.  Let’s say you have an extensive class hierarchy, but you want to add a new feature to only certain classes in the inheritance tree (call them classes C) but not in some other classes (call them classes NC).  If the youngest common ancestor of all classes of C (call it superclass S) is also an ancestor of any class in NC, then you’re kind of SOL if you want to use inheritance.  You can’t give superclass S the new feature without also giving it to some class in NC.  Essentially, the class hierarchy couples different classes together, reducing your ability to selectively update parts of the tree in a robust manner. (I say robust because you could always just copy and paste the feature into each class in C, but the CompSci gods would strike you down for your heresy.)

In component architectures, inheritance is avoided.  In fact, most classes are avoided altogether.  Instead, all objects are simply containers of components, which are self-contained contained behaviors.  Want an object to respond to user input?  Add a UserInput component to the object.  Want an object to be destructable?  Add the Destructable component.  Using components, the object can be completely customized without affecting other classes or other objects.

Since component architectures are used to manage the behavior of  individual objects, they present a different problem from class hierarchies – how do you manage all the objects in your program?  Well, one strategy is to define a scripting language that will emulate inheritance, kind of like the one described in this Powerpoint presentation.  The presentation gives a good overview of the advantages and disadvantages of component architectures, and was probably the most useful resource I came across while investigating this topic.

So are component architectures next on my list of things to try out?  Probably not, actually.  I came across another intriguing new concept – functional languages – that I think I’ll explore first.  Functional languages are even stranger to me than component architectures, and I’m just a sucker for a new experience.

# Sprite Clipper v0.9 released

The first version of Sprite Clipper, one of the primary reasons I started this site, has been released!  I tried to break the program as best as I could, and if I found something wrong I would fix it.  Since I haven’t been able to break this version, I’m putting it out there for people to use and try out. No guarantees, of course!

Check it out here.

I’ve learned a great deal pursuing this project and this site.  Here’s a bit:

• Java
• Netbeans, Ant, Freemarker
• git and Github
• Setting up a domain and using WordPress
• Blob detection algorithms
• Packing algorithms
• Slick2d library (for testing)

In fact, the reason I started Sprite Clipper was that I started playing with Slick2d, but found getting sprite assets (even ones just for testing) a real pain in the butt.  I’m one of those people who will expend huge amounts of effort to avoid doing tedious tasks.  Tediously cropping sprites is a pain.  Building entire programs to avoid doing that is actually a lot of fun.

# Automatically including a file in your Java jar using Netbeans and Ant

First, a quick note of exposition.  If you’re eager just skip down to the header.

I started this site primarily because I started developing a Java program called Sprite Clipper that I wanted to share with other people.  I also knew it would be a learning experience (in more ways than I anticipated!), and I think maintaining a web presence outside of Facebook is desirable in its own right.

To track my program’s progress, I started to use git in conjunction with GitHub.  GitHub prominently displays a README file at the root of the project repository, which can be used for licensing info (BSD 3 clause in my case).  What I wanted to do was have this README file be automatically generated when I build the jar for my program using the same template text that I use for my new java classes, and also have the README included in the built jar.

Well, I fell pretty short of that goal.  I couldn’t find any information on how to invoke NetBeans’s templating engine, FreeMarker, from Ant without creating a stand-alone installation.  Since I had been working on this for a couple hours at this point, I decided to scale back my ambitions to simply copying a README file I made manually to the jar archive.  While it’s not a slick, sexy solution, it does accomplish what I wanted, albeit with less automation than I would have liked.

## Copying a file into JAR archive

In your Netbeans project, go the file view on the left hand side and open up build.xml.  It should be at the top level of your directory.  Here you’ll see an XML file that has a lot of comments and only a little markup.  This is your Ant build script.  It’s kind of a like a makefile that’s specified in XML.

At the bottom of the file, insert the following just before the </project> tag at the end.

<target name="-post-jar">
<jar jarfile="${dist.jar}" update="true"> <fileset dir="${basedir}" includes="README"/>