Messages

31

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

« on: July 24, 2012, 06:43:15 PM »

Reading top-down I had a look at poll choices first. To me, the obvious choice (No, 32-bit unicode is enough) was suspiciously absent.

That's exactly what I was talking about. A true fixed-width glyph for every Roguelike-interesting codepoint. There are a lot of Roguelike-interesting codepoints outside the BMP.

This will be happening. It's just a matter of when.

I do the Java-based Blacken Roguelike library. Since it should be possible to accept SVG-based contributions to the font, I'm going to see if I can use the Apache Batik SVG library to allow previewing vector tiles before they get rolled in to a font.

Which is to say: Working on a font isn't on my schedule until next year.

I'm working on finishing Blacken 1.1 for the Annual Roguelike Release Day (it's mostly feature complete now), then I want a complete tutorial by the end of November. After that, I'll start to work on the Blacken 2.0 features. The font work will spin up after the initial batch of changes are in trunk.

I expect it to miss the 2013 7DRL unless someone else wants to start this project before then.

If someone else wants to lead this effort before then, I would be happy to assist. This can be done using open-source tools -- there's a learning curve for the tools but no purchases required. (We're also talking about vector graphics. You don't need to be a traditional artist.)

Cheers,
Steven Black

32

Programming / Re: Tablet ideal device for a roguelike?

« on: July 23, 2012, 03:09:19 AM »

I think the key in making a roguelike use fewer keys is:

Hang actions off items, not vice versa.

The user-interface of the "every key has a command" type of Roguelike is oriented along the lines of, "here is a verb, select the verb, then get a list of the items it applies to."

If you turn that around, so you have an inventory and you select the item and then are presented with a set of commands to perform on it, I think you solve the biggest problem. You can drop all kinds of dedicated keys.

That same approach can be applied to the dungeon, as well. A generic "modify environment" command directed at a location which then presents a menu of actions.

You can simplify the available commands, sure, but I think -- even with the mega-set of commands in the big roguelikes -- this simple switch can make things much more likely to succeed.

But my preference would be to just have a keyboard. It's how I play roguelikes on my phone now.

Cheers,
Steven Black

33

Programming / Re: Copyright!

« on: July 23, 2012, 02:53:12 AM »

You're infringing copyright just by using the same characters/names. An ASCII-based game with the same characters/names would also draw the attention of a cease-and-desist.

The more money behind a brand the more likely a cease-and-desist is.

I operate on the expectation that a big branded property has interns which do nothing but look for copyright infringement. So it's not "lawyers" I would worry about avoiding but unpaid student interns with too much time on their hand who want to look good to their bosses so that they might have a chance at working for one of these companies some day.

If you're going to go to the effort of being able to quickly rebrand the game to something safe, personally, I suggest the public version you release -- along with assorted promotional material/websites -- focus on the safe version.

That is, you have a legal game that has an option -- ideally handled by a separate download which can be yanked without disrupting your main site -- which turns it in to a copyright violator. That would allow you to hang your hat on a legal product, but still share the copyright-violating add-on with direct friends/family.

Copyright violation is serious business in the US. It is such a serious business in the US, when big media feels someone overseas violates US copyright, they work to get the person extradited to the US and charged in a US court even though the "crime" never happened in the US.

All you need is for Nintendo to claim they "lost sales" because of your copyright infringement for the cease-and-desist to very quickly include polite requests for money and lawyer fees as well.

As my instructor at school regularly reminded us: C.Y.A. (Cover Your Ass/Arse).

Also note: If you're putting up something which violates copyright you will probably be violating your agreement with your ISP and whatever host you're using to store the thing. Unless you're hosting it on your own hardware expect all access to your service provider to be shut down and never brought back up. If you're hosting it on your own hardware you may still be violating your ISP's usage policy and could be blacklisted from ever using that ISP ever again.

For instance, http://www.google.com/intl/en/policies/terms/ lists "We respond to notices of alleged copyright infringement and terminate accounts of repeat infringers according to the process set out in the U.S. Digital Millennium Copyright Act." I would expect the lawyers involved on the opposition side to be very punctual with regards to timing and to actively hope they'll be able to get you terminated.

So... this means you're potentially looking forward to getting a cease-and-desist while you're on a vacation somewhere without Internet access, then have your services all terminated because you didn't respond fast enough. -- This is what could happen to you if you accept the risk of a cease-and-desist.

Cheers,
Steven Black

34

Programming / Re: Randomized Object Stats, Randomized Quests?

« on: July 14, 2012, 05:08:41 AM »

I've thought about making a game where the player has no idea what sort of monster they're facing.

"Hey, look. I think that's a... oh my god, what is that thing?!"

This is a type of gameplay more reasonable for ASCII-based graphics than for tiles. You want to depict a location on-screen without giving an indicator as to what it is.

My idea is that, (1) the player could identify certain aspects of the creatures depending on what is being done, then (2) visit local bars/taverns and gossip about what it might be.

You wouldn't even need to indicate what is being seen, just keep a counter of the amount of time observed.

And, of course, some of the gossip would be wrong. Better still, the wrong gossip could actually favor monsters the player has seen in earlier games. The wrong information would then play to the players' expectations.

You wouldn't even need to provide a computer-generated name. You can make it random and still make the player name it.

Then about random quests...

Even simple fetch quests are about narrative. A story-driven game has quests that relate to each other within a broader framework. The problem with quests outside of a narrative framework is that you're left continually dealing with short-term issues which act as distractions from the main plot.

Quests are side-plots that shouldn't feel tacked on to the main story arc. There should be reasons the character wants to go on optional quests -- outside of just being a fan of completeness.

For me, it is better to have compelling game play and no quests than it is to have boring forced quests.

Quests should never feel like grinding. In some games they can feel that way.

Cheers,
Steven Black

35

Programming / Re: Resizing Terminal Screen

« on: July 14, 2012, 03:57:31 AM »

Have you looked at the man page for these functions?

http://linux.die.net/man/3/resizeterm

These do not -- can not -- resize a terminal window. These resize the ncurses-internal data structures associated with the terminal.

Did you read this bit?

While these functions are intended to be used to support a signal handler (i.e., for SIGWINCH), care should be taken to avoid invoking them in a context where malloc or realloc may have been interrupted, since it uses those functions.

SIGWINCH is the signal sent to a terminal application when the window it is running in is resized. That is, the user either manually resized the window or changed the font so that contents have been resized though the bounds remain the same.

There is one escape sequence that can resize a terminal -- and that toggles between 80 column and 132 column modes and is rarely supported. It's a genuine xterm escape code -- much like the Techtronix mode is a standard xterm feature that is rarely implemented in terminals advertising themselves as "xterm".

I recommend you do what some roguelikes do: develop a tight dependency on a particular terminal emulator, and use a two-phase process where the "initial" application is just a script that passes arguments to the terminal emulator setting the window resolution, size and font and specifying that it needs to run the "real" executable instead of a shell. There may be standard command-line arguments you can use for this in the general case, but I wouldn't trust them to be universally supported by all terminal emulators. (They should be tested before they're enabled by default.)

The script can easily test for a DISPLAY to see if it can launch the terminal emulator or if it needs to make-do with an unknown lying POS terminal emulator.

I've given up on writing terminal-based games because the terminal emulators are generally crap and it's become the norm for terminal application developers to jump trough insane hoops to work-around lying terminal emulators and incomplete Terminfo data.

Ncurses should be able to know if the terminal emulator has 0, 8, 16, 88, or 256 colors. Official "xterm" terminal emulators have shipped with all of these settings as defaults in the past.

Oh, but now even though ncurses knows that "xterm" is only 16 color, if you ignore that and send xterm-256color escape codes sometimes it will still work.

If TERM is set properly -- and the system even has the "xterm-256color" Terminfo data -- ncurses can handle all 256 colors automatically. It can even tell you when you can arbitrarily redefine the 256 colors. Awesome stuff -- but it only works if the terminal emulators and the Terminfo data is correct -- which it almost never is.

I wish you luck.

36

Programming / Re: Newbie programming Q's

« on: July 13, 2012, 07:14:36 PM »

My big issue with programming in Microsoft Assembly for a subset of architectures that Microsoft supports is...

You're programming for a subset of architectures that even Microsoft supports. Windows 8 moves beyond x86 (32 bit) / amd64 (compatible with x86 -- also called x86_64) / ia64 (not compatible with x86). It brings in ARM support.

So... right now, you have assembly that works with a single operating system and two of the architectures that operating system actually supports.

I'll repeat what others have said. Have you looked at C? It was designed because coding the same thing over-and-over in different assembly languages is boring. You can think of it as an assembly macro-language. The famous "++" operator exists simply because there's an assembly code to perform this, and -- without any fancy optimization -- you could get slightly smaller code.

If you write Windows C code you automatically work on all Windows processors. x86, amd64, ia64, arm, with a little planning you should be able to get something that works on Windows phones. (Are any of those still using SuperH or has everything moved to Arm?)

Secondly, if you really have a thing for assembly programming, (1) get a copy of FreeDOS, (2) install it to a freely available virtual machine, (3) write assembly code specifically for the VM. You can then share your code as a virtual machine. (A virtual machine that could use a floppy disk image. I didn't say it would need to be large.)

Why start with FreeDOS? You want to write a Roguelike game and not an operating system. FreeDOS gives you a compatible filesystem and some other handy functions.

Cheers,
Steven Black

37

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

« on: July 13, 2012, 10:11:06 AM »

Oddly enough this sort of thing, albeit in a strange tangential manner, was/is one of the various things I'd been plotting on for awhile now---though out of my depth on all ends as of yet, as per always.     My angle was more "What if?" history based and tied to gameplay directly---but the whole Raster versus Vector part also rang my bell....though also under the first clause from my art tutorial hunting days before my creative spark had escaped me.

That said, and I imagine of at least some interest given the subject, this thing just happened:

http://doryen.eptalys.net/2012/07/the-font-from-outer-spaaaaace/

More details in the forum thread there

In terms of random license thinkings, um, some strange corners of what I track have went to zlib, which seems pretty ideal in terms of being moreso straightforward than the personally confusing GPL situation while just a sidestep or so away from public domain.

That's really kind of sad, considering the Basic Multilingual Plane (BMP) of Unicode (the first 16-bit plane) totally fails the Japanese community. ( http://tronweb.super-nova.co.jp/unicoderevisited.html ) -- This from an article I actually just ran across last night. (While the article is actually quite old, the BMP's been relatively constant for some time.)

Yamamushi used the "unifont" which only supports a fraction of the Unicode 5.1 spec, and only at horribly small sizes. -- The font's originally a bitmap font and has been converted to a truetype font through a method that leaves it, well, pixellated-looking at larger sizes. The smaller sizes are suitable for Roguelike games -- but talk about no ability to scale up for larger monitors... ouch. (That font's whole purpose is to have complete BMP coverage -- not complete Unicode coverage -- See http://unifoundry.com/unifont.html )

In my initial call to arms, I referenced Unicode code ranges above the 0xffff mark. In fact, only one of the ranges I mentioned was in the BMP at all.

For those paying attention, it means that if using 16-bit "wchar_t" values (as Yamamushi implies he is using in his Doryen forum post) you will need to use "surrogate pairs". That is, to show one codepoint you need to write a pair of 16-bit values. If LibTCOD doesn't support this then it doesn't support Unicode as surrogate pairs have existed since Unicode 2.0. (Linux (and probably Mac OS X), including the ncursesw library, use 32-bit values for wchar_t. Windows, for historical compatibility, is guaranteed to use only 16-bit wchar_t values.)

See the Unicode spec Chapter 5 ( http://www.unicode.org/versions/Unicode6.1.0/ch05.pdf ):

The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently,
programs that need to be portable across any C or C++ compiler should not use wchar_t
for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide
characters, which may be Unicode characters in some compilers. However, programmers
who want a UTF-16 implementation can use a macro or typedef (for example, UNICHAR)
that can be compiled as unsigned short or wchar_t depending on the target compiler
and platform. Other programmers who want a UTF-32 implementation can use a macro or
typedef that might be compiled as unsigned int or wchar_t, depending on the target
compiler and platform. This choice enables correct compilation on different platforms and
compilers. Where a 16-bit implementation of wchar_t is guaranteed, such macros or
typedefs may be predefined (for example, TCHAR on the Win32 API).

This isn't new. The Unicode 4.0 spec said basically the same thing. The difference is in the 6.1 spec it recommends the use of char16_t and char32_t for UTF-16 and UTF-32 values.

For those wondering, yes, since Java defines a "char" as being 16-bits, to pass around a complete code-point you need to either use an int or a String. The Character class has a whole set of functions supporting this.

As for licenses... When the FSF -- a group that sincerely cares about licenses -- says "merely referencing the font (as in the CSS font-face: caslon;) does not create a derivative work of that font. So why did we worry about font licensing at all?" then goes on to talk specifically about font-embedding as being the reason that fonts need specific types of licenses... I think there's some confusion about them. Loading a font in your program is just referencing it, after all.

Still, as I said earlier, if our goal is to get the missing codepoints in to fonts, (and not to also create Roguelike additions)... We can do this by using the most lenient of the possible licenses (public domain) and working with the other font folks to adapt our glyphs to fit their font styles. The key thing there would be whether we needed to do some sort of assignment-of-copyright thing to get the glyphs used by various font products. Though, if our output is dual-licensed Public Domain and CC0 -- http://creativecommons.org/about/cc0 -- it should be usable world-wide without restriction. (This is important because "Public Domain" doesn't exist in some countries.)

Cheers,
Steven Black

38

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

« on: July 13, 2012, 12:03:39 AM »

My point/question is why would anyone see this font and suddenly abandon tiles (which is what you say will happen in an ideal circumstance), when they could just as easily make a tile for the extra glyphs you have.  There are plenty of free graphics sets, so availability is also not an issue.  I'm just curious why you think this would be so great, since I expect people who are really devoted to ascii will also think that this is more of a tileset than a character set.  Your argument above is a complaint about implementation (which you even acknowledge is committed by font users as well), and not an actual reason why someone would want to switch to this font from tiles.

I'm not arguing with you here, I sincerely want to know why you think this way, because it seems like such a dramatic limitation to me and, while I certainly see the appeal of ascii, using a bunch of custom made characters seems to be heading away from that ideal.

(This is not to mention that I think, tiles or else, having a set of visuals that a lot of people use is absolutely horrible for the genre)

You do have a good question.

It fundamentally boils down to my existing prejudices against tiles: Raster-based tiles are hard to tell apart when they can easily become a smear of color with a single pixel being the difference between two different things. Additionally, I'm prejudiced against Roguelike games having a minimap. In a Roguelike game, the main map screen is the minimap. Tiles tend to need to be massive for them to be both distinguishable and to have any sort of the visual meaning that a graphic image would normally imply.

I'm not even saying I think people will see it and suddenly abandon their tiles. That's a matter of dreaming big. That's really a goal of any project of mine.

What's the fundamental difference between a character-based and a tile-based game? A character-based game is color-limited -- not in terms of the number of colors available, but in terms of the number of colors used in a single cell. A character-based game has simple line-art that is easily recognizable at very small sizes.

So, being both color-limited and visually simple, character-based displays can fit far more cells on the screen while still being visually distinguishable than can usually be done with a tile-based game. Of course, to be visually distinguishable it also helps to have a fixed palette for things of particular importance. (You can't have the only difference between two wildly different things be +/- 2 on a single color channel.)

Will people abandon raster--based tiles for SVG-based tiles that scale with the window so they can do things that are trivial to do with fonts? Goodness, that would be a fantastic idea. The problem there, though, is that because of the lack of simplicity and the number of colors, you still can't get the number of cells on screen without making them look like a font.

People make graphics look like fonts all the time. That's standard practice for some libraries. Still, though, raster-based graphics don't scale.

Ultimately, I don't care if people say, "This is so awesome, I want to drop graphics" or they say, "This is so awesome. I want to do something like this with graphics." Anything advancing the genre in new and interesting directions is good.

In a perfect world, we could just use normal reasonably complete Unicode fixed-width fonts. We'd have enough even if we didn't have architectural symbols. They wouldn't be custom, they would be what is defined in the spec. It's a very large spec.

Some of the things missing should be reasonably adaptable to a variety of fonts. It is possible that instead of pushing for a single font family we could push for the advancement of a number of popular fonts.

I'm not actually against tile-based graphics. As I said, in many cases tile-based graphics look like character-based graphics, so it can be hard to tell the two apart. What I want -- with character-based graphics or tile-based graphics -- is simple graphics which are color-limited per cell, easy to tell apart, and easily scale to any size.

(ASCII-based visuals are fundamentally a common set of clearly distinguishable visuals used by a wide variety of games.)

Cheers,
Steven Black

39

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

« on: July 12, 2012, 10:49:59 PM »

It sounds to me you are talking more about a monospace unicode font than specifically a roguelike font. Are you suggesting adding custom glyphs outside the Unicode? How is CJK helpful in roguelikes, unless you are making translations?

In a perfect world we could use any old monospace Unicode font, yes.

Have you looked at the codepoint selection of the monospace Unicode fonts? Big on various languages, light on interesting symbols.

Since the font makers have been lax to create the glyphs that would most benefit us, why not add them ourselves? If that's the only goal -- strictly limiting it to Unicode -- we could easily contribute it back to the original font folks and not bother with "Roguelike extensions."

For a fullwidth font, CJK provides a large set of visually interesting symbols. CJK support is basically a freebie because most, if not all, of the fonts we would start from would have it. To get reasonable CJK support what we need is a reasonable full-width font. A full-width font is handy for some of the more detailed glyphs -- there are some codepoints that are unfeasible in a half-width font. (Some things expect a square cell instead of a rectangular cell.)

To my knowledge there are no fixed-point fullwidth Unicode fonts.

Now, while we could just limit it to Unicode there are Private Use Areas for a reason. We could go with a true Roguelike font with glyphs optimized for our genre. I've mentioned the lack of architectural symbols in Unicode. There may be other things that would benefit us as a whole.

40

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

« on: July 12, 2012, 09:53:15 PM »

Ideally, a really great font and a few applications that take advantage of it should cause developers to second-guess whether they really want to go with a tile-based approach or not.

It seems to me that those applications would be essentially tile based.  You can put it in a font but that doesn't make it not tiles.

How many tile-based games allow dynamic resizing of the window and auto-resize their tiles? This should be a trivial operation.

It's gotten so bad that even character-based Roguelikes don't recognize it as something that should be easy to support.

Now, if you're talking about the difference between scalable vector-based tiles with antialiased black-and-white lines which are recolored and resized as appropriate, then -- yes, it's the same as using a font. (Except for being able to accent things without precomposed tiles.)

Cheers,
Steven Black

41

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

« on: July 12, 2012, 08:59:28 PM »

I think that could be interesting, although I'm going the graphical route for my personal project. In any case, I'd definitely recommend an open license, or a lot of developers won't be able to  profit from your work. I can't see a closed font gaining much momentum in the RL community.

As always,
Minotauros

I'm not really a fan of closed source products. In this context closed-source would likely be free-to-use (at least for non-commercial purposes).  I'm really just trying to gauge interest.

I want a developer to be like, "I really want codepoint <FOO> for my game, but it's not in the font yet. How can I help?" Then we say, "Use this Inkscape template and sketch it up as an SVG file. Contribute it back to the project and we can easily roll you a copy of the font before our next major release." In an open-source community this is easy and allows everyone to benefit.

The GPLv3 -- because it isn't being "linked" to a program -- shouldn't cause license pollution. While there is a GPL "font exception clause", it only exists because of font embedding -- this is literally taking the contents of a TTF (or other) font file and shoving them inside the body of a document. (See http://www.fsf.org/blogs/licensing/20050425novalis ). Referencing a font, or even installing it for the end-user in your installer, is perfectly acceptable with a GPL v3 licensed font so long as the user (1) has access to the source, (2) can modify it, and (3) can install a modified version for use by your program.

Ideally, a really great font and a few applications that take advantage of it should cause developers to second-guess whether they really want to go with a tile-based approach or not.

For our purposes we could take advantage of some of the private use area to add things like, say, architectural symbols so that a building can look like building plans. (So that, say, when the player gets building plans, the background flushes blue, and they have the option to look at floor plans for floors they are not on.) -- After all, there are already established simple symbols for components of maps of all sorts...

Cheers,
Steven Black

42

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.

43

Programming / Re: Rogue-like without combat

« on: April 10, 2012, 05:00:07 PM »

Check out Cataclysm. <http://whalesdev.com/>

It was reviewed on Roguelike Radio <http://roguelikeradio.blogspot.com/2012/01/episode-20-cataclysm.html> where they talked about it.

Of note: While there are a variety of creatures, most of them will easily kill you, and you gain no experience for killing them.

Of course, I could see a game take a mixed approach, where you can win the game without combat but you do gain skills by killing things -- they're just exclusively skills related to killing, maiming and torture...

Cheers,
Steven

44

Programming / Re: Java Roguelike Tutorials?

« on: April 10, 2012, 04:37:17 PM »

@ghostable, there are a lot of ways to contribute to a project.

If you're talking about Blacken, we have a Google Group -- blacken-dev <https://groups.google.com/forum/?fromgroups#!forum/blacken-dev> which can either be used online or via email. It is archived and there is low noise.

I'm currently focusing on some minor refactoring before I look in to ways to speed up Blacken. Once Blacken's performance is up, I'll be focusing on writing the tutorial. The goal is to be done with the tutorial is one month before the next 7DRL. (So the tutorials are available for people to check out and try while they're evaluating libraries for the 7DRL.)

Once I have the tutorials done, I'll be announcing them here.

So, you can join the Google Group and either visit the site as you have a moment, get it sent to you like a mailing list, or just keep your eyes open for the announcement here when the tutorials are ready and check it out then.

Cheers,
Steven

45

Programming / Re: Library licenses and patent issues?

« on: March 27, 2012, 01:31:41 AM »

Software patents are quite idiotic. They, like GPL, BSD and other idiotic stuff, is coming from US. What is the problem with you guys? Why can't you be intelligent like other people?

I agree software patents are quite idiotic.

They're also big business in the US. Not good business, mind you, but big all the same.

Software licenses were a good idea before software patents. They continue to be good ideas. Without a software license, the software is covered by standard copyright and that means they can't be legally copied at all.

Cheers,
Steven