Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - yam655

Pages: 1 2 3 [4]
46
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

47
Programming / Re: Game Flow Idea + Question
« on: March 25, 2012, 05:47:40 AM »

I can't say I've seen one where the city was a menu. There are a lot of them where cities are as boring as a menu -- but few where they actually cut to the chase.

As for multiple dungeons, there are a lot of those out there right now. In most cases when there are multiple dungeons they also have multiple cities. You may have multiple dungeon/quest entrances within the same city, and you can have dungeon/quest entrances outside of cities, so there's no particular need for overlap. At this point this is a fairly common feature among the larger games. ADOM has it. ToME3 and ToME4 both have it. (ToME3 is even a *band-type game.)

So... city-as-menu: I've never seen it. Multiple dungeons: Fairly common (and can be done well, even).

Having never played Megaman, I can't even relate to how such short town-dungeons would work.

If I'm not mistaken, even grand old Omega (which predates Angband) had multiple dungeons and multiple cities. (I know it had multiple cities, and I'm fairly confident it had multiple dungeons, as well.) Though my understanding of Omega was that it had end-scenarios which didn't require any dungeon work at all -- you could spend your entire time in the big city. I was never that good at it, though...

Cheers,
Steven

48
Programming / Re: Java Roguelike Tutorials?
« on: March 25, 2012, 03:36:44 AM »
The 7DRL I wrote this year uses two separate libraries - one for UI and one for FOV calculation. Both were satisfying, but libjcsi has its limits (though I really appreciate its simplicity). I'd love to have a more... comprehensive solution. Especially with regards to some of the cool toolkits libtcod has.

Before I started work on Blacken, I looked at libjcsi.

Had you looked at Blacken before you decided to go with libjcsi? If so, why did you pick libjcsi?

I basically hadn't done any Swing-based work when I started. I started looking at libjcsi and trying to get it to do what I wanted. Eventually I realized it was going to be entirely rewritten.

Was it the license issue that made you pick libjcsi?

I know that we roguelike people tend to do things on our own, but if you need a helping hand, I'd be more than willing to contribute. There's a lot of stuff to do if you really want to catch up with libtcod, and it's going to take a while. I might be able to help out a bit, my fingers are itching to rewrite some of the libtcod stuff.

I am interested in gaining other contributors. Send me a PM with your email.

First look over the existing Blacken code. If you have any experience in Swing, you may be able to tell me I'm doing something blatantly stupid.

I am going to roll a release, branch it, then update the license. This means the source repository will have a version that it licensed for the GPL v3, but the version I'll work on going forward will not. If someone really wants that license, they'll be able to fork it starting from there.

By using an identical license as libtcod we'll basically be able to add features by porting the libtcod stuff to Java. This will be much easier than when I added the Navier-Stokes stuff to Blacken -- when I did that, I looked up the source of their algorithm and rolled my own based upon the same source material.

49
Programming / Re: Unicodetiles.js: JavaScript character tile engine
« on: March 22, 2012, 09:41:35 PM »
@aave:
That's odd about unifont. I would have thought it would have exclusively been either 8x16 or 16x16. The fact that any of them became anything else would have to be a bug in the TTF conversion process. The things start off as an old-school bitmap font -- this is why it is blocky. The dual size thing is should be relatively common for a lot of fixed-width fonts -- it dates back to the old dumb terminals where a Chinese character would be twice as wide as a Latin character. Decent terminal emulators deal with this properly. (Though sometimes they only allow double-wide characters in every other location.)

In my "Blacken" Java library, I explicitly check to see if the max width of a character in the font is twice as wide as an "M". If so, it is a dual-width font. I have code to support it... but I've not gotten around to actually testing it.

I think one thing that would really benefit the roguelike community as a whole would be a high-quality "Roguelike" font. The focus would be on glyphs useful for roguelike games. Sort of a companion and alternative to the shared tile projects... So far, I've gotten as far as getting FontForge installed and working... We'll see how much steam I actually have for the project. ;)

In particular, I want doors which look like doors on architectural drawings -- complete with a directionality. I want to increase the clarity of the display -- something possible with the clear meanings of standardized iconography, but muddied with colorfully drawn tiles. That said, I also want monsters incomprehensibly horrible -- something only possible with fully abstract representations. Any tile graphic fails. With a tile you always eventually know what you're up against. With an letter you may never know...

The difference between basing a "Roguelike" font on DejaVu versus "FreeMono" is a one of license. DejaVu is public domain. FreeMono is GPLv3. For a web game, it means you can keep the source to DejaVu secret, but for FreeMono you need to make it available (along with any changes).

I actually think we would need three Roguelike fonts: 1 single width, 1 double width, and one dual width. I think the dual-width can be automatically created from the other two source fonts with a script, so it would be a distributed font but not one that would require a separate source file.

50
Programming / Re: Java Roguelike Tutorials?
« on: March 22, 2012, 08:38:04 PM »
What's up Steven, good to see you around again. I'll throw in my two cents to say that for tutorials Jotaf's Python tutorial at Roguebasin has got a lot of positive buzz. If you were to look at that and create something similar I think you would have a good framework to work from.

<http://roguebasin.roguelikedevelopment.org/index.php/Complete_Roguelike_Tutorial,_using_python%2Blibtcod> ?

Yeah, I think I can pull something like that off.

Quote
I took a decent look at the libraries available and I think blacken is the best one out there, so I think more work on it would be great.

Excellent.

I'm thinking of switching from the GPL 3 license to an Apache/BSD license (the same as libtcod) specifically so I can steal features from it without worrying about licensing issues. I thought it might also be useful to provide a libtcod-like API as an option, at least as much as such a thing will make sense. libtcod is popular specifically because of the rich feature set. If I can get Blacken to feature-parity, that's the first step to driving improvements from my side. (When they are good features, it may make sense for libtcod to steal them from me. This will also be easier for them if we have compatible licenses.)

More immediately, I want to see if using JavaFX instead of Swing will help improve performance. Brogue's initial splash screen with the flaming background is kick-ass, and I know that sort of thing won't work with Blacken right now. If I get the performance to support that, then with my resizable windows I'm already one notch better. ;)

JavaFX looks like the next big thing for UI libraries. I have a hard requirement on pure Java solutions (otherwise you break cross-platform compatibility) so I don't want to link to external libraries via JNI. I've not seen a lot of options in terms of UI libraries. As near as I can tell, there's Swing, the thing Eclipse uses (I forget the name), and now JavaFX. JavaFX is still a little new, but the roadmap says that it is being folded in to Java 8 as a standard feature. (It also has "multi-touch and gesture" support -- and as Windows 8 spreads those features will slowly become the norm on all computing devices.)

Cheers,
Steven

51
Programming / Re: Unicodetiles.js: JavaScript character tile engine
« on: March 21, 2012, 11:47:47 PM »
I also wanted to mention GNU Unifont <http://unifoundry.com/> the font coverage is huge (full support of the Basic Multilingual Plane as of Unicode 5.1).

Unfortunately, it is primarily a dual-width fixed-point font. (8x16 and 16x16) There is a TTF version of the font, though it does appear blocky at some point sizes. (However, in some cases that may be considered part of the style.)

It includes glyphs for COFFIN and FUNERAL URN, but it predates PENTRAGRAM and CHURCH.

If the font works for a Roguelike the available codepoints is really impressive.


52
Programming / Re: Java Roguelike Tutorials?
« on: March 21, 2012, 07:11:11 AM »
Are there any great libraries/engines for roguelikes coded in Java that have tutorials for someone new? Alternatively, did I miss some tutorials for the aforementioned libraries/engines?

If I were to write an ideal tutorial for using Blacken, what would it need to have and how simple does it need to be?

When comparing Java roguelike UI libraries, what features were you most interested in? Those features should be documented and clear to use.

I mean, I know you probably found a solution to your issue for this year's 7DRL, but if there's a need out there, I should have this available before next year's 7DRL -- and that's a time-frame I think I can keep.

I tried to have a number of examples. I've frequently learned programming languages by way of example, so that tends to be what I think about first -- plus they have the benefit of failing when the code changes -- unlike written tutorials. ;)

Cheers,
Steven

53
Programming / Re: Java Roguelike Tutorials?
« on: March 21, 2012, 07:02:44 AM »
I'm the developer of Blacken.

It does use Swing, and it does suffer some in terms of the redraw speed. (It has zero flicker -- all updates are clean.) It gets around the speed issue to an extent by having drawing in a separate thread. It will also drop updates to the screen if need be, so in practice the speed isn't bad -- and it doesn't have any threading issues so you can resize the window to your heart's content and things still look good.

It takes a mixed approach to the issue of unlimited colors. You can use a predefined palette if you want. You can hand-code all of your colors if you want. With some limitations you can mix the two. When using a palette you can reference colors by name or by index and it has a number of default palettes available. (From xterm-256color to SVG/HTML5 named colors.) Custom palettes are easy and can be stored in text files.

It includes some simple examples, which (I would like to hope) would be enough to get started.

I'm less than happy about performance in terms of the impact it would have with the traditional ASCII-style animation, but -- as they say -- first make it work, then make it better.

Currently it has a rather rigid view of an "ideal screen size". It defaults to 80x25. When you resize the window (which it fully supports -- unlike some of the other options) it refuses to make fewer than that many columns and rows so it will shrink the text. When you make the window larger it does the reverse so the preference is always to be as close to 80x25 as possible. -- This means when designing the UI you design it once for your ideal screen size and things should "just work".

It also supports cell walls -- these are a part of the Curses spec but never implemented by either terminal emulator or curses. This means you can have zero-width walls. That, in turn, means when there's a window it's visually clear that the creature outside may reach in and grab you.

Anyway, I've been distracted from working on it for some time (otherwise I would have tried for the 7DRL). I'd love to see something somebody made using it.

wire_hall_medic, Outside of Swing or the AWT, what would a person use to create a desktop user-interface? I'd love to switch to something faster. It might inspire me to breath some more life in to it.

Cheers,
Steven Black

54
Programming / Re: Unicodetiles.js: JavaScript character tile engine
« on: March 21, 2012, 06:34:36 AM »
I have a few comments.

1. It would rock if this library could work with smartphones. I have an Android with a hardware keyboard and I couldn't get the arrow keys to do anything but scroll the page. It displays fine and the transition effects work fine, so I think it is just an issue of getting the keyboard input in to the right view.

2. You might want to mention GNU FreeFont as another alternative. <http://www.gnu.org/software/freefont/coverage.html> The FreeMono font in particular needs some catchup. The FreeSans font has 5289 codepoints, but the FreeMono font only has 2120. However, they do have a goal to be rather complete, so this will likely change in the future. (Personally, I think at some point the roguelike community should start a project to extend a font in useful roguelike directions.) I don't know how much active development is going on with the DejaVu font.

3. For the people unfamiliar with some of the fantastic unicode codepoints, you might want to reference <http://unicode.org/charts/>.

Additionally, while Linux has functioning character map tools, (and I don't know about Mac OS X) the Windows default "Character Map" program is broken and can only show one sixteenth of the possible valid Unicode codepoints. Specifically, it is limited to the "Basic Multilingual Plane" which are codepoints between 0x0000 and 0xFFFF.

BableMap <http://www.babelstone.co.uk/software/babelmap.html> is free and has no such limitation. It will also allow you to jump to a codepoint by name or jump directly to a named Unicode block. This is handy when you have been browsing, say, the Unicode charts and you want to check to see whether a font has any glyphs in the "Miscellaneous Symbols" block (2600..26FF). Of course, with the ability to jump to a named codepoint, it is also easy to just do a search of, say "CHURCH" or "PENTAGRAM" or "BUS STOP".

4. If I've not stated it already. I think your library looks really quite interesting. If it could work with my Android phone, I might think about using it. As it is, there appears to be a lot of potential there.

Cheers,
Steven Black

55
Programming / Re: Cave map 'theme' ASCII symbols & colors
« on: September 25, 2011, 04:53:20 PM »
There is a middle-cell dot that I've seen used in Roguelikes supporting IBM Extended ASCII characters (aka CP437). You don't actually have to use periods for the floor. It allows counting the cells, but is smaller than a period.

When I first played Moria (in the 80s) I played it on a PC configured to make use of the Extended ASCII characters for much of the dungeon structure. Moria is really the canonical veined-mine Roguelike. If you've not played Moria or Angband, you should at least download it to look at how it can be configured to display the dungeon.

One thing I wanted to warn you about, though: Make sure the game is *fun*. When I hear about "digging through a level of #'s to get to hidden things" all I can visualize is busy work and boring repetitive tasks. That sort of game mechanic doesn't sound fun to me.

Cheers,
Steven

56
Programming / Re: Random Creature Types
« on: September 25, 2011, 04:28:53 PM »
Along a similar -- but different line -- in one of the Roguelikes I want to write the player fundamentally doesn't understand many of the monsters. Sure, they understand standard animals, but the unusual and horrific are fundamentally misunderstood.

As you'll see, this could be an entirely different solution to the naming issue.

Imagine, if you will, a Call of Cthulu based roguelike where -- as in CoC -- if you were to understand what the creature is you would go insane.

At one time I thought of glyphs that shift on you, then I decided on something significantly easier to impliment.

This takes the abstraction of character-based creatures one step further. It fundamentally breaks the assumption that a particular character is always a particular monster.

Basically, the monsters in your line-of-sight get assigned characters in much the way that inventory in -- say -- Nethack get assigned. I say Nethack because you want the visible letter to be persistant as much as possible. (If you follow a monster you don't want it changing letters on you.)

The way I see it, you'd have a panel on the right-hand side of the window describing what you're seeing. Perhaps something like:

A (Friend) Harry
dirty human
walking with limp

Whoops, you failed to spot the blood stains on his shirt. (He's a zombie, but the player doesn't know zombies really exist yet.)

B shifting darkness
probably nothing
provokes unease

B outline of man
probably nothing
provokes unease

B man in shadows
provokes unease
flash of metal

Is the man a friend or foe? Is the sense of unease due to simple fears or because of something more nefarious. The player shouldn't know.

Additionally, once the player has killed a few zombies:

C Mathilda (daughter)
zombie human
yelling incoherently

But when a zombie breaks off from attacking you to go after Mathilda, it changes:

C (Friend) Mathilda (daughter)
filthy human
yelling incoherently

You can also do target assignment by specifying the letter without confusion.

The (Friend) marker indicates autoattacking is disabled for the creature.

This is some of the sort of thing that people just never try to do with Roguelike games.

I think you can have a true Roguelike horror game, it just requires violating a few common expectations.

You could use similar logic in a fantasy setting with a lot of creatures, too. Imagine the unknown monsters are a standard grey, and the known monsters are all colored appropriately. The player wouldn't know what non-animals are until they talked to folks in a pub -- at that point the unknown monsters fall in to their proper places. In earlier towns folks may not have heard of some of the more obscure creatures so they may not be able to help all the time.

Cheers,
Steven

57
Programming / Re: Any thoughts on explicit facing?
« on: September 25, 2011, 08:45:25 AM »
You can do it in Near Ascii.

What I mean is -- ignore Curses and use a GUI to do the ASCII.

Then you can overlay a directional arrow (or even line-segment -- sort of like a clock hand) on top of the character in the direction that they are facing.

I've thought about doing this for a roguelike before.

It has the benefits of Ascii in that it provides a clean and clear visual that neither requires significant work nor requires a bunch of rotated images. It also allows you to pack in the characters on the map.

My big question is whether it is fun. (If it makes the game harder to play it is a bad idea.) I'm not sure it would add to the player's experience, but I don't think I'll know for sure until I play a roguelike that implements it.

Cheers,
Steven

58
Programming / Re: Simple RPG Systems
« on: September 25, 2011, 08:36:35 AM »
If you want something dead-simple, check out Fudge.

http://www.fudgerpg.com/about/about-fudge/fudge-overview.html

Looking for a piecemeal RPG solution and want to know how to glue it all together? Fudge it. It's heavily used for that sort of thing.

Thinking of writing your own, and wondering what you *really* require? In the "Some Highlights of Fudge" section of the above page it reads:

Quote
Design your own. If you are thinking of designing your own home rules role-playing game, simply reading Fudge can provide an excellent introduction to everything you need consider as a game designer!

Considering you can download a copy of the 1995 edition free from their site -- http://www.fudgerpg.com/goodies/fudge-files/core/ -- it makes it particularly easy to use as a reference.

59
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

Pages: 1 2 3 [4]