Also, is there any official thinking with regards to the things Blacken has going alongside/in spite of/in addition to/??? the also Java-based Neon project?
http://neon.kosmonet.be/
I've not looked at neon seriously. (I think I glanced at it years ago.) There are some significant core differences.
The biggest one is this: Neon is not a library. Neon is a game system.
Blacken -- while currently a single cohesive artifact -- will eventually be broken up in to a set of artifacts. The idea is that you will have Blacken games which use Swing, some that use JavaFX, and some that run on the Android. There will be a few "core" classes that are always required, there will be optional packages -- both for alternative implementations of things we normally provide, as well as for optional backwards compatibility with older serialized formats.
Also, the neon project has greater library requirements, because it does a lot more. The only library requirements that Blacken has are JUnit (for testing only) and SLF4J+Log4J for optional logging. We don't ship a logging configuration file with the main JAR, so logging is implicitly turned off, but it is handy to be able to get internal log messages when diagnosing strange issues. (Each of the examples have a log4j.properties file enabling logging.)
One of the side-effects of neon being a gaming system and not a library is that you can have a neon game with a different license than the neon project itself. The example neon project will
eventually be released under a Creative Commons license and the neon project itself is straight GPL. It would have been a violation of the GPL (had I still been using the GPL) if I wanted to share an example game without also including the source
and also releasing it under the GPL. (Since Blacken 1.1 uses the Apache 2 license there are very few restrictions on what needs to be done. Basically, I have a NOTICES.txt file that needs to be presented with your other legal notices. It is short, and there's an API call to get it if you're running via JNLP.)
So, neon is a program that executes data which are games. Blacken is a library that you use write games in Java.
It also means that neon sees the T-Engine as a competitor, while Blacken sees LibTCOD as a competitor.
The Blacken goal is to make the boring parts of Roguelike development easy but basically put zero restrictions on how and where the code is used. This means that if you're making a 7DRL and you're "violating a fundamental principle of a roguelike" Blacken shouldn't fight you. It might not make it particularly easy, but it should at least stay out of your way. As a consequence, we have BSP Tree code, but we don't force people to use it. Shoot, even though we have a concept of palettes (featuring named and indexed colors and palette rotation) we don't force people to use them -- they can use hard-coded 0xARGB colors instead.
As it stands now we have a generic Grid<Z> class. It's resizable as long as it is square and if it is not resizable it can be arbitrarily shaped. We recently added a "TIM" (Terrain-Item-Monster) cell that contains a triplet of values -- but it's also a generic so you can specify three different classes if you want. The TIM cell approach seems common for quickly implemented Roguelikes, so it should be easy. However, while the TIM approach is common, it is not a
requirement. The existing examples use Grid<Integer> for their maps. (The twinkle is handled by palette-rotation -- none of the cells store their color.) In the past once, I implemented a cell that contained a stack of items which were kept in order based upon a "stacking order" in each item. The idea was the stack could be arbitrarily high with any type of "thing" potentially being duplicated and without limit as to what went in it -- so you could both have multiple tiny monsters in the same cell as well as atmospheric effects blowing over. (I implemented it in Python years ago. It's something I might implement for Blacken, though.)
With neon, a game is written for neon and runs within neon. If you want to use a feature that neon does not provide, you need to extend neon. You can't easily just mix-and-match for your needs.
Another example: I thought about supporting a text-based data format -- perhaps one compatible with LibTCOD's format. I looked at it and concluded it was similar enough to JSON that I didn't need to do anything. Game developers can pick their preferred JSON library and use that. Blacken is a library to be used alongside other libraries. The game developers have the last word on the libraries they use. (The reason for SLF4J is that the underlying logging backend can easily be swapped out by game developers.)
Since it's another open-source Java project it would be nice if I could adapt code from it to extend Blacken. Since it's using the GPL, though, I can't afford the license pollution. I could create a "blacken-gpl-bits" artifact which separately has a GPL'ed license and exists as a separate project with its own source repository. The difference there would be that if someone used it, they would
have to make their game GPLed. It seems easier to use neon code as an example of a technique, do research on the technique and write my own implementation.
Once Blacken's split in to smaller artifacts, it will mean that neon could include some of my artifacts. I can not use any of neon, though.
There's another side-effect of neon being a game system: Things missing in neon are painful, because game developers depend upon neon for all underlying functionality. Things missing from Blacken are simply left to the game developers. Blacken is a 1.x release because as a user-interface library it can be used to make games
today. Sure, there are areas where you need to write what should be commonly used code, but if I made a decision you didn't like you would be doing that anyway.
Cheers,
Steven Black
