Android support

[devilbuddy]

It would be really cool to get rid of the java.awt dependencies to be able to use this seemingly excellent library on android.

Getting rid of awt dependencies in the algorithm implementations (java.awt.Point mainly) Splitting the awt rendering parts into a separate library depending on the "core" library

Not sure how big the effort would be though...

[tommyettinger]

I agree here, and it should be actually fairly easy to add a Point2D class (I already did it in an earlier library, cuttlebone, that was merged into SquidLib earlier, though a lot has been improved in that code since I last committed anything to cuttlebone). Splitting up rendering is a bigger challenge. Dealing with the very different Maven artifacts I would be publishing could be a bigger hassle. @SquidPony , I have an idea. Keeping cuttlebone present on Maven Central but not updating it seems like a waste; what if the entirety of the logic code (squidai and squidmath package, FOV/LOS/RNG/dungeon generators) was moved into cuttlebone (I could make you a contributor there like you did for me here), SquidLib is made to depend on cuttlebone, and SquidLib contributes only the desktop GUI code (including SColor) to a project. SquidLib could keep the successful-I-think approach of using libgdx as a Maven optional dependency, so projects could use AWT if they want with no additional deps on desktop, use libGDX and get much faster screen updates to allow animation, or use neither and only require cuttlebone, which could be made compatible with Android rather easily.

For now, I'll focus on getting in the remaining bugfixes for squidai before I tag and release 3.0 (maybe calling this next one 2.9 since I don't think there are any breaking changes in the (large) changeset for squidai and GDX support, but the big reorganization will break things if a user doesn't depend on cuttlebone correctly, so a major version bump should be suitable).

[davidbecker]

I think it would be nice to have the rendering part separately from the algorithms, but it is a pain to maintain code that belongs together in different repositories. It would be much easier (and would also allow for a consistent naming scheme) to have the two parts in one repository but in different maven projects.

The following seems consistent and easy to maintain for me: squid-parent - dummy parent pom. Defines the two modules (like squidlib and squidlib-util), common dependencies, version number and so on. squidlib - contains the rendering part and depends on squidlib-util. Will be distributed as the current library, so no changes for most users of the library squidlib-util - contains the algorithms, FOV, dungeon generator and so on. will be distributed as well

[tommyettinger]

@davidbecker that sounds like a much better plan. I'm not sure what it will take to get multiple artifacts on Maven Central under one organization, but your plan seems like the best way to do this.

[davidbecker]

@tommyettinger I haven't deployed anything to Maven Central yet, but it seems to me that a simple

mvn deploy -P squidlib
mvn deploy -P squidlib-util

should work

[tommyettinger]

I'm starting on some needed reorganization for this now. I've already replaced java.awt.Point with Coord from the squidmath package (same exact API), I split up SColor into two versions, one using libGDX Color and one using AWT Color, with almost the same API. Next up is the Maven module mess.

[tommyettinger]

Well it looks like this is pretty much done. Static mutable state shouldn't be a problem anymore, any references to AWT are gone in util (thank you for landing the finishing blow, @devilbuddy ), modules are all split up... I have a few features that are only partially complete in the GDX display code, once those are made fully available I'll publish a 3.0.0b release. I think the master revision does have Android support now, so I'll mark this closed!