Using this checkstyle configuration results in ~240 errors due to missing Javadocs. For my opinion on the matter see this commit message. The tl;dr is depending on the complexity of the problem being solved well written code does not need verbose, or sometimes any documentation. However, Javadoc is too great of a tool not to use in a sane manner.

I used the SO recommended fix for "Maven is not working in Java 8 when JavaDoc tags are incomplete." However, -Xdoclint:none it seems, does not exist in JDKs 7 and below. I get an error when trying to use the JDK 7

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.10.1:jar (attach-javadocs) on project fuzzy-octo-shame: MavenReportException: Error while creating archive:
[ERROR] Exit code: 1 - javadoc: error - invalid flag: -Xdoclint:none

While the code currently enforces the use of JDK 8 in the POM.xml, in theory it can be compiled using JDK 7. JDK 6 and below will not work because of the use of the Diamond Operator.

For the time being, I would like to have the option to be able to compile via JDK 7. This might change in the future if we start using lambdas or some other 8+ only feature. Thus this is a low priority issue.

The dependency org.lwjgl.lwjgl:lwjgl-platform:2.9.1 has native binaries for the respective OSs that Java needs to know about in order to run the project. We are currently leveraging the mavennatives plugin, however it can be more automated. The process of unzipping and setting the java.library.path variable needs to be relatively transparent to the developer.

Ideally you have it so only the OS you are building on gets those binaries unzipped. I have done this in the past, and with the help of the mavennatives plugin it is rather trivial can be done, just not with the latest version of the plugin(0.0.7 as of 2014-11-12). It is just a matter of wiring it all up in a sane manner so that the build works in any environment.

Use degraph and yed to create high level dependency diagrams.

Thanks to @JakeWharton for introducing me to the tools via his blog post.

Make version properties, add release plugin(to concatenate issues like 25 and 27) *, try to slim down the file down, and optimize the POM.

***** I moved adding a release plugin to a separate issue: #29

Self explanatory. Will fill in more description if necessary.

http://choosealicense.com/

If you hit a tile's corner at just the right point, issues like the image below where the player is not falling down but actually standing on the wall's tile will occur.

I have also noticed when jumping up to a tile that you can make it into, but because of a mistimed jump you should not be able to get to, this bug allows you to "pop" to the top on ledge thereby lowering the skills needed for precision timing of jumps.

Somewhere along the misguided path of my micro-optimization, I suspect I introduced this bug. I modified the original code to do some cheeky floating point arithmetic comparisons which most likely caused the observed problem.

See:

• http://maven.apache.org/maven-release/maven-release-plugin/
• http://blogs.atlassian.com/2013/05/maven-git-flow-plugin-for-better-releases/
• http://www.radcortez.com/maven-git-release/
• http://george-stathis.com/2013/11/09/painless-maven-project-releases-with-maven-gitflow-plugin/
• https://bitbucket.org/atlassian/jgit-flow

I have already botched incrementing the version so automating this mundane task will be clutch.

I choose Guice. However I would like to compare it to PicoContainer, Spring, and straight JSR-330 dependencies.

Write Unit tests with as close to 100% code coverage as possible. roughly 60%-70% code coverage and follow the 80/20 rule.

The current unit tests leave a lot to be desired. Flesh them out more.

see also: #6 #53

Enabling vertical monitor synchronization via org.lwjgl.opengl.Display#setVSyncEnabled causes the game speed to slow down. Disabling it cause "tearing" of the QuadTree's debug lines, that I unfortunately can not seem to get a screenshot of.

Do you know how to get the "tearing" effect to go away while maintain a fast game speed? It feels like an underwater level with VSync enabled.

Smoothing of texture observed when com.jed.actor.Player#draw() is called, but only when com.jed.state.MenuState is pushed to GameStateManager.

See: com.jed.state.MenuState#draw()

Document a rough design for an AI framework.

LJWJGL 2d platformer skeleton has too many Js.

I propose my fork's description:

2D platformer skeleton built with LWJGL and a fork of Slick2D

The current implementation does not handle if a controller is unplugged or plugged in during runtime. This is a known issue with JInput. Look into potential work arounds.

Look into developing and integrating into codebase separate modules, which leverage JMX; possibly for things like real time retrieval of error logs, profiling, etc.

Look at the bottom left part of the image.

Data Classes alone make adding Kotlin a no brainer.

See: http://kotlinlang.org/

With the Gradle wrapper, a new developer does not need to have Gradle installed in their environment to get started. For this reason alone, I suggest migrating from Maven to Gradle.

Provide a clear, and concise getting started guide. It shall include such things as technical requirements, coding conventions, etc.

Currently I rely on Display#create in some of my Unit tests.

This is causing Travis-CI to fail.

I always wanted to try adding Internationalization to an application I worked on.

See:

• Internationalization Trail
• Our resources manager and how it helped in localizing Clash of the Olympians

[edited]

I am not sure if this issue (tiles not loading properly) is local to my environment or if it exists in the develop branch. Please check out the latest from develop of your repo and see if you can reproduce.

I noticed it last night, intermittently and thought it was due to me changing over versions of Eclipse. I want to be sure I did not introduce any bugs before I continue on my milestone goal.

I want to removed the dependency on Slick2D. LWJGL, does most of what we want.

I analyzed our project and we are only using a a limited number of classes from the Slick2D library:

• org.newdawn.slick.Color
• org.newdawn.slick.SlickException
• org.newdawn.slick.UnicodeFont
• org.newdawn.slick.font.effects.ColorEffect
• org.newdawn.slick.opengl.Texture
• org.newdawn.slick.opengl.TextureLoader
• org.newdawn.slick.util.ResourceLoader

The source code to the project can be found at the bitbucket repo.

I propose we "vendor" those classes we are currently using(copy them, and any of their compile time dependencies over to our repo) and remove the overall dependency.

I broke input handling in the develop branch when I implemented a command system to bind multiple inputs(keyboard, controller, etc.) to a command.