Topics

1

Programming / Blacken 1.1.1 Released (Java Roguelike Library)

« on: September 26, 2012, 11:54:39 PM »

Blacken 1.1.1 was released to address a critical issue with Mac OS X support. Other than functional Mac OS X support there are no significant changes.

Blacken 1.1 Release Announcement

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.

2

Programming / 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.

3

Programming / A Roguelike TTF/OpenFont font: Is there interest in such a thing?

« on: July 12, 2012, 05:05:37 AM »

Character-based Roguelike games could really benefit from some of the great Unicode codepoints now available as standard features.

What sort of codepoints?

How about fullwidth ASCII to go along with the fullwidth CJK for full access to the CJK glyphs while still being true fixedwidth?

How about heiroglyphs? Perhaps http://unicode.org/charts/PDF/U10980.pdf or http://unicode.org/charts/PDF/U13000.pdf

Alchemical symbols? http://unicode.org/charts/PDF/U1F700.pdf

The standard emoticons? http://unicode.org/charts/PDF/U1F600.pdf

Or some of what I really want to see: http://unicode.org/charts/PDF/U1F300.pdf http://unicode.org/charts/PDF/U1F680.pdf http://unicode.org/charts/PDF/U2600.pdf

You can have churches, cemeteries with crosses of various shapes -- and even pentagrams. You can also have maps with real map symbols on them.

The only problem is there doesn't appear to be a font catering to our unique need.

Now, a good free Unicode font should be usable by all Roguelike games using a character-based interface. Old-school curses using PuTTY (or your favorite terminal application for Mac OS X or Linux) would be able to use it just as easily as a more GUI-based solution.

It would benefit almost everyone in the community.

We would want to start with one of the good-looking "console" or "programming" fonts -- designed for looking at for long hours. The steps are: 1. gauge interest. 2. pick a license. 3. pick a starting point that doesn't suck. 4. prioritize codepoints and regions. 5. make it easy for folks to contribute.

There are a lot of potential starting points depending on what sort of license would be suitable for folks.

My personal preference is to focus on two fonts -- both true fixed width -- with one being full-width and one half-width. (Latin characters are half-width. CJK (Chinese/Japanese/Korean) characters are full-width.) Depending on the tools and the build environment, it may be possible to compile a dual-width font out of the two -- with specific Unicode ranges either being fullwidth or halfwidth -- but that's a lesser priority.

4

Programming / Library licenses and patent issues?

« on: March 25, 2012, 10:52:31 PM »

Do folks pay attention to or care about the licenses of the code they use?

I noticed the libtcod stuff used the BSD 3-clause license. The BSD license was a perfectly fine license -- before software patents.

Some free software projects have suffered because someone has contributed a patch where the contributor (or the contributor's company) owns a patent, then the patent owner goes in asking for money for the use of the patent. In the case of software libraries this means a person can sneak in a patent to a library, then once folks use the new version of the library, they can go in asking the folks making money on the library to pay for the privilege of using of the patent.

This is one of the reasons the modern software licenses have specific patent clauses. The Apache v2 license gives the same sorts of rights as the BSD licenses but does so while protecting the software developers (and the users of libraries) from patent issues. For folks that prefer GPL-styled licenses, the GPLv3 family all include patent clauses.

I know few folks would logically go looking for patent issues (or money) with something as old-school as roguelike games, but nothing is fair when it comes to software patents. It's all about crushing innovation and threatening small developers -- and roguelike developers are almost exclusively small developers...

Cheers,
Steven

5

Programming / Blacken Java UI library to compete with libjcsi

« on: September 25, 2011, 08:18:58 AM »

I'm a long-time Roguelike fan, first time poster.

I missed the annual Roguelike Release day, but I don't know when my schedule will change, so I'm going to talk about this now.

I've been working on a library to assist with UI for Roguelike games in Java. (Why Java? I need to know Java for work.) I call it Blacken: http://code.google.com/p/blacken/

It is in development, but has reached a point where further development on my part will likely be tied to my work on a Roguelike of my own.

It has zero support for graphical tiles. Games with graphical tiles need minimaps. Games with ASCII/Unicode graphics *are* the minimaps -- just more usable.

The library includes some sample code, but only one of the samples resembles a roguelike game and it was done in less than a week of work-time and looks like it.

Some features it has that I wish more Roguelikes had:

1. It has support for arbitrary color palettes. Xterm-256 color palettes are supported out-of-the-box, but you can create your own and there is no length limit.

It should also support changing a palette without needing to explicitly redraw the entire screen (as you see in real palette-based environments) but that has not yet been tested.

It also supports named colors and also (or additionally) has support for the SVG/HTML color names.

2. It supports arbitrarily resizing the window.

It has a concept of a "preferred size" for a Roguelike window (in terms of rows and columns) which it will try to maintain that size by resizing the font as appropriate.

As a developer if you're writing a game for a 80x25 display, you know you always have at least 80x25 available. It may actually be 80x100, or it may be 256x25, but it is always at least 80x25.

This means that maximizing the window generally zooms in, making the font bigger, but stretching a single dimension, expands the number of rows or columns.

I may add something like the Linux/X Control-Alt-Plus/Control-Alt-Minus feature where you can switch between some established min. sizes for windows without requiring explicit code for this in-game. (They will probably be 80x25, 80x50, 132x25, 132x60.)

3. It supports zero-width walls.

So, the X/Open Curses standard appears to have an entirely unsupported feature allowing a cell to have all four walls to have a line on them.

I call it "cell walls", and currently it is always just the foreground color. I may allow it to be something different as well at some point, but this works for now.

This was an early requirement for me, and one of the reasons Blacken doesn't have a Curses output mode (it only supports Swing right now).

I want a survival-horror Roguelike where you can be pulled through a window. Sure, you can do this without zero-width walls, but I think the impact will be heightened if, for instance, the only way to prevent the boarded-up window from being torn apart is if you stand at it and attack the creatures on the other side and if you don't have a projectile weapon you can only attack the creature directly next to you that just also happens to be on the other side of the window.

4. It supports Unicode.

A single cell in Blacken is defined as taking a String to describe the image -- not a 'char'. This is because there are numerous zero-width codepoints that you should be able to stack.

When a single codepoint is required, the standard requires an 'int' not a 'char'. Java 'char's are too small to hold a whole Unicode codepoint outside of the Basic Multilingual Plane. To pass a whole codepoint, you need to accept a pair of 'char's -- so you can get both halves of a surrogate pair -- or you need to just accept an 'int'. -- No one wants to deal with surrogate pairs, so Blacken just uses 'int's.

getch() returns an 'int' which is a valid Unicode codepoint. Keys which do not map to Unicode characters are assigned to values from one of the Private Use Planes. We handle modifier keys similar to what Linux/X does with the 'ESC' prefix, except we use a prefix pulled from another Private Use Plane which maps to all of the modifier keys.

5. It has support for font attributes other than foreground color.

It uses the same palette for foreground and background of text. -- I've noticed a lot of Roguelikes avoid background color, but then most Roguelikes also seem to stick to the old 16 color palette.

It also It has support for monochrome font attributes, but I've not tested that yet.

6. It uses GPL v3.

It does not use the LGPL, which means if you use Blacken, you must use the GPL.

This is more a feature for the players and for developers of mods/variants of your game.

This was done because as a player, I hate finding a Roguelike game I'd like to play, only to find the developer has stopped maintaining it and there isn't a version for my platform. I hate this the most when it is clear the Roguelike wants to use an older version of a library I have -- in these cases a simply recompile may be all I need, but I can't do it because I don't have the source.

If you want any more clear example of just how severe of an issue this can be consider all of the Angband variants, then consider that Robert Alan Koeneke was surprised when he got on Usenet and found a group dedicated to Moria as he didn't know that people were still playing it. Had he not open-sourced Moria, Angband would have never existed, and -- as an aside -- I would have never gotten serious in to programming. (I started programming to cheat at the PC port of Jim Wilson's Unix port of Moria. -- Remember Moria started on VAX.)

Comparisons to the competition:

The nearest competing library is libjcsi. Both are Java libraries with Swing interfaces available.

Now, I've not looked at libjcsi since before I started working on Blacken, so some of this may no longer be accurate.

libjcsi supports other UI backends including Curses. Blacken only supports Swing at this point, and will never support Curses.

libjcsi doesn't support background colors. Blacken does.

libjcsi doesn't support resizing the window. Blacken does.

libjcsi follows the GUI standard of Column then Row. Blacken follows the Curses standard of Row then Column.

Both use threading to mask the Swing event-driven mechanism and make it appear to be more like Curses.

The big one is Blacken is GPL and libjcsi is not.

Blacken should currently have a super-set of the functionality of libjcsi. However they are definitely not drop-in replacements.

Long-term direction:

Aside from some bug fixes and testing of some features that may or may not currently work like wide-character support and additional font styles and officially supporting Java 7, there are a few cases where I have some big ideas.

A. Support for a Blacken "virtual font" allowing different regions to be mapped to different physical fonts.

This should allow for real support for nearly all of the Unicode codepoints -- including Egyptian Heiroglyphs.

B. Support for line-drawing (maybe an SVG subset) graphical substitutions.

The ultimate goal here is to turn the traditional ASCII/Unicode map in to something resembling a real map. Buildings should look like blueprints using the same visual shortcuts. This would mean that we know which direction doors open.

Cheers,
Steven Black