I had a quick look, out of curiosity - I don't even have the time to work on my own Java game right now, and certainly don't know LibGDX. One thing I would suggest is that to help others contribute it really needs some comments to explain what each member is and does and what each method does and when it is called. It will also help you as down the line; there will be things that you forget what they are for.

Looking at the Anim class a quick improvement would be to use "try with resources" and only for the duration that the reader is needed. The catch blocks can come right after the StringBuilder is filled.

Another suggestion would be to remove any products of compilation from GIT, so no .class files or .jar files that result from your build.

Alright, thanks for the tips!

I am kinda bad about commenting, that one is on me.

So for the Anim class, are you just suggesting I shorten the try/catch to only include the file input?

Also, is there any easy way to filter out the compiler files, like some kind of .gitignore that can do it?

FA will likely mess this up, but the general idea is to make sure try catch blocks are as specific as possible (wrapping only the code that can cause an exception) and ensure all the resources are closed, even if there is an exception. So, something like this:
[spolier]
[noparse]
String[] segments;
StringBuilder builder = new StringBuilder();

try
(
BufferedReader bufferedReader =
Gdx.files.internal(fileName).reader(8192);
)
{
String line;

while((line = bufferedReader.readLine()) != null) {
builder.append(line).append("\n");
}
}
catch(FileNotFoundException ex) {
System.out.println(
"Unable to open file '" +
fileName + "'");
}
catch(IOException ex) {
System.out.println(
"Error reading file '"
+ fileName + "'");
}

fileSplit = builder.toString();
[/noparse]
[/spoiler]

A much more significant change would be to go fully OO on this class and instead of relying on on arrays of Strings holding animation input actually create separate classes for AnimFrame, AnimAction, AnimSetSprite etc implementing an AnimIf that would have only the members they need already parsed to the right types. All the parsing would be done just once rather than each time an animation plays (Integer.parseInt is a non-trivial method, and can throw runtime exceptions).

I'd get rid of the recursion in nextAnimFrame and replace it with a done boolean and a while loop.

I really shouldn't look at other people's code - but I spent too many years employed by Sun doing just that!


On the Git thing it does have ways to ignore files (.gitignore) there's probably an option in your IDE to do this. There are certainly command line ways of removing files from futher commits. I don't use Git much myself - I'm the luddite still using CVS!

Thanks! Don't worry about having looked at my code and stuff, I'm pretty much self-taught so it doesn't surprise me that my style is less-than-100%. I am learning C++ in college right now and learning a lot more about making good, readable code, but this code was largely written before I started learning ^^;

Darn, I've never heard of gradle, so I wouldn't be able to help with the code. Still, really awesome that you're sharing the source. Not enough indie devs doing that.

Heya~!
Don't worry about the gradle bit, that's just what compiles the code :p
The code is written in Java and heavily features the LibGDX game development library. If you are at all interested in doing some code in these but don't know where to start, fret not, I have some tutorials too ^^
http://www.furaffinity.net/journal/8762765/

Hello?