Author Topic: Blacken 1.1 Released (Java Roguelike Library)  (Read 12619 times)

yam655

  • Rogueliker
  • ***
  • Posts: 59
  • Karma: +0/-0
    • View Profile
Blacken 1.1 Released (Java Roguelike Library)
« on: September 12, 2012, 03:47:00 AM »
In time for the Annual Roguelike Release Party, we're proud to announce Blacken 1.1, the next major revision of Blacken, a Java library for Roguelike development.

Blacken now uses the Apache 2.0 license.

We now have a user-focused site which includes tutorials you can try out via Java WebStart: https://sites.google.com/site/blackenlib/try-it-out

We're now in Maven Central, so use of Blacken is a matter of adding a few lines to your pom.xml:
<dependency>
  <groupId>com.googlecode.blacken</groupId>
  <artifactId>blacken-core</artifactId>
  <version>1.1</version>
</dependency>

The full release notes are online at: https://sites.google.com/site/blackenlib/current-version/release-notes

Improvements over Blacken 1.0

License change: We used to be GPLed, but now we use the Apache 2.0 license. It can be hard to change licenses on a project. This was done before we accepted any contributions to the codebase. That is, it was the project of a single individual when we changed licenses.

Significant performance improvements: Our display updates were sluggish, though we did our best to work-around it so the response time was okay. With Blacken 1.1 the performance itself is good.

Simpler interface: The native programming interface is no longer so similar to Curses. There is a "CursesLikeAPI" wrapper that adds back the functions that were taken out, but by default the class is smaller and simpler. In particular, the management of the cursor is much simpler.

Some features

Originally Blacken was aiming purely for the user-interface. That's still where it is most complete.

Palette support: Indexed and named colors; mixing indexed colors from the palette with arbitrary 24-bit colors; palette rotation; load custom palettes from files using either our own format or GIMP palettes.

Arbitrarily resizing the window: maintains a "preferred size" changing the font size as needed; Alt-Enter for full screen mode; supports the visually impaired (as long as they can see something) by making it easy to make the font very large.

cell walls: Any cell can have walls on any of the four edges; use it for menus; use it for buttons; use it for zero-width walls where zombies can pull you through windows.

Unicode support: A cell contains a sequence of codepoints; codepoints may be outside of the Basic Multilingual Plane; some of the code-points may be zero-width accents.

Curses-style key input: all key input consists of valid Unicode codepoints; special keys are handled by codepoints in "private use" planes; modifier keys are handled through a prefix character (like Unix systems handle Alt via the Escape character).

Growing support for general Roguelike development: We now have BSP Tree support and Perlin noise.

Focus of next release

The 1.2 release will feature a full featured tutorial including a coffee-break-length Roguelike.

The reason that there's going to be another release, instead of just a tutorial is that we'll be resolving the nits and annoyances that crop up during the creation of the Roguelike. The goal is to shake out the last of the issues that would inconvenience a 7DRL developer.

The goal for the tutorial and the accompanying minor release is Jan 2013.

george

  • Rogueliker
  • ***
  • Posts: 201
  • Karma: +1/-1
    • View Profile
    • Email
Re: Blacken 1.1 Released (Java Roguelike Library)
« Reply #1 on: September 12, 2012, 05:25:13 AM »
congratulations, I think this is a real step forward for JVM RLs.

getter77

  • Protector of the Temple
  • Global Moderator
  • Rogueliker
  • *****
  • Posts: 4957
  • Karma: +4/-1
    • View Profile
Re: Blacken 1.1 Released (Java Roguelike Library)
« Reply #2 on: September 12, 2012, 12:25:40 PM »
Congrats, keep at the fine work.   8)
Brian Emre Jeffears
Aspiring Designer/Programmer/Composer
In Training

penguin_buddha

  • Newcomer
  • Posts: 19
  • Karma: +0/-0
    • View Profile
    • Email
Re: Blacken 1.1 Released (Java Roguelike Library)
« Reply #3 on: September 13, 2012, 02:52:49 PM »
Do you have something like a class diagram for blacken?

getter77

  • Protector of the Temple
  • Global Moderator
  • Rogueliker
  • *****
  • Posts: 4957
  • Karma: +4/-1
    • View Profile
Re: Blacken 1.1 Released (Java Roguelike Library)
« Reply #4 on: September 13, 2012, 04:31:56 PM »
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/
Brian Emre Jeffears
Aspiring Designer/Programmer/Composer
In Training

yam655

  • Rogueliker
  • ***
  • Posts: 59
  • Karma: +0/-0
    • View Profile
Re: Blacken 1.1 Released (Java Roguelike Library)
« Reply #5 on: September 13, 2012, 05:36:05 PM »
Do you have something like a class diagram for blacken?

Not yet, but I liked the idea so much I'm going to make sure we have one before the end of the year.

If you want to watch the ticket: https://code.google.com/p/blacken/issues/detail?id=43

It should be pretty low-hanging in terms of the amount of work. There are tools specifically designed to do these sorts of things. I'd be surprised if it is more than a single night's work in terms of "find the tool, run the tool, post the output."

I probably won't post to the forums when it is done, so your best bet is to watch that ticket.

Thanks!
Steven Black

yam655

  • Rogueliker
  • ***
  • Posts: 59
  • Karma: +0/-0
    • View Profile
Re: Blacken 1.1 Released (Java Roguelike Library)
« Reply #6 on: September 13, 2012, 06:57:53 PM »
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

getter77

  • Protector of the Temple
  • Global Moderator
  • Rogueliker
  • *****
  • Posts: 4957
  • Karma: +4/-1
    • View Profile
Re: Blacken 1.1 Released (Java Roguelike Library)
« Reply #7 on: September 13, 2012, 09:10:37 PM »
Good info, perhaps the Neon team will contact you to talk shop a bit at the least in the future as, between the pair, these are literally just about the only even roughly overlapping Java-based Roguelike "tools", or at least enablers, out and about trying to make something happen.  Rough break on the licensing complexities as far as crossing streams and whatnot though.
Brian Emre Jeffears
Aspiring Designer/Programmer/Composer
In Training

yam655

  • Rogueliker
  • ***
  • Posts: 59
  • Karma: +0/-0
    • View Profile
Re: Blacken 1.1 Released (Java Roguelike Library)
« Reply #8 on: September 14, 2012, 12:08:39 AM »
Good info, perhaps the Neon team will contact you to talk shop a bit at the least in the future as, between the pair, these are literally just about the only even roughly overlapping Java-based Roguelike "tools", or at least enablers, out and about trying to make something happen.  Rough break on the licensing complexities as far as crossing streams and whatnot though.

Yeah. I've found a lot can be gleamed just by reading source enough to know where the underlying logic came from and is properly called, though. When you read about a routine and compare a couple implementations it becomes pretty straight-forward to directly adapt the theory (or the canonical representation of the theory -- even in another language) in to usable code.

Neon's use of libraries points me toward those libraries as well. Just because I can't use neon's code, doesn't mean we can't both use libraries -- provided they make sense.

Neon uses a 2D solid object physics model that I could use... (BSD style license.) I just can't wrap my mind around the use-case for such a thing in a Roguelike.

The JTexGen generated texture engine may be useful, but uses the LGPL so it is unsupportable in a WebStart-able closed-source game. (More specifically, it currently uses the LGPL 2.1, so you could use it, but if a later version switches to the LGPL 3 the "anti-TiVo-ization" clause would prevent its use in a closed-source web game.)

It also uses "TinyLAF" which alters the look-and-feel of the standard AWT/Swing controls. That would be something useful for the SquidLib folks more than Blacken. (It's LGPL3 so, as mentioned, the anti-TiVo-ization clause prevents it from being used in a closed-source web game.)

Blacken completely hides the native UI system. The reason for this is simple: All along I've wanted to support multiple UI libraries. Exposing a native UI library ruins this goal.

(But with Blacken 2.0 I hope to have a usable generic Swing panel that could compete with SquidLib directly. I'm all about exposing interchangeable pieces that developers can mix-and-match. Hmm... I should create a ticket to have Blacken support SquidLib for the UI.)

Cheers,
Steven Black

george

  • Rogueliker
  • ***
  • Posts: 201
  • Karma: +1/-1
    • View Profile
    • Email
Re: Blacken 1.1 Released (Java Roguelike Library)
« Reply #9 on: September 15, 2012, 07:06:30 PM »
Speaking of SquidLib, I'm wondering what its differences are with Blacken. Is SL mostly a UI library while Blacken is more like libtcod?

XLambda

  • Rogueliker
  • ***
  • Posts: 208
  • Karma: +0/-0
    • MSN Messenger - tau_iota@live.de
    • View Profile
    • The Weird Rogue
Re: Blacken 1.1 Released (Java Roguelike Library)
« Reply #10 on: September 15, 2012, 09:17:05 PM »
Speaking of SquidLib, I'm wondering what its differences are with Blacken. Is SL mostly a UI library while Blacken is more like libtcod?

We definitely want to offer a similarly wide range of utility classes as libtcod. I'm working on porting several libtcod toolkits to Blacken (which did not make it into the 1.1 because I've been horribly busy the last two months). Eventually we want to provide additional interfaces mirroring the libtcod API, to make it easier to switch to or from Blacken.

I haven't looked at SquidLib long enough to make any statements about it, but I think it focuses mainly on the text UI, while Blacken is supposed to become a full-fledged console emulator.