Our only restriction is to maintain the core reasons for having ASCII
in the first place - functionality, clarity and ease of imagination.
Best,
P.
> So..ASCII graphics. Although I prefer them for my RLs, like most other
> folks, sometimes I find their aesthetics to be rather on the bland
> side.
The properties "functional" and "fancy" often go against each other.
Typical examples are type-setting (good page layout is largely different
from what a typical user of Word, or also of Latex, would produce).
I see outside restrictions as useful: if we had alphabets with 104
letters, imagine the abundance of monsters in roguelikes! Given that most
monsters are usually under-differentiated with 26 or 52 letters already,
more is (again) not necessarily better.
> So, given pretty much a modern OS and an unlimited palette of
> colors and symbols (delivered to the screen via graphical methods),
> how do we go about sprucing the visuals of the stereotypical dungeon,
> its denizens and their environs up a bit?
I am against using more colours and more symbols for flavour only. The
reason is that in a graphical game, things like torches at the wall,
furniture in a room and plants by the wayside are self-explaining. In a
console setting, you have to look these up, making for additional flavour
(to some, not for me) but more tedious play.
> Our only restriction is to maintain the core reasons for having ASCII
> in the first place - functionality, clarity and ease of imagination.
I agree on functionality and clearity. I have never understood the
imagination bit. During last year's roguelike meeting, we discussed this.
It seems that there are really different approaches to parsing a letter
mentally. Since I do not associate a picture with a letter, adding more
symbols (without actual features) will only serve to confuse me.
Just my point of view :)
David
Playing with background colors also doesn't hurt readability, since
they don't require the extra letters that David says contributes to
the noise.
Example RLs in development with screenshots:
http://urprogress.blogspot.com
http://thewayoffallen.blogspot.com
Jotaf
> Our only restriction is to maintain the core reasons for having ASCII
> in the first place - functionality, clarity and ease of imagination.
And not to forget a fourth reason -- you don't have to draw all that
stuff.
I agree with David in that I don't associate a picture with a letter,
but the letter definitely evokes feelings beyond its appearance as a
letter. Is imagination and evocation the same thing?
I also agree that one should be economical in the use
of symbols; the technical possibility of Unicode does
not mean that we should suddenly associate a
monster with every character in the basic
multilingual plane. If standard ASCII or extended
ASCII is not sufficient, it's probably worth taking
a closer look at the game design. (If the game is very
large, not all characters need to map uniquely to one
monster, but they should ideally be more or less
functionally equivalent -- a "d" might represent both
a wolf and a hell hound, if those are not generally
found in the same environment but behave in
more or less the same way.)
I think background colour is where the greatest
possibility for eye candy lies. The reason projects
like Umbrarum Regnum look so nice is mostly
their use of background colour, and that could be
more or less separated from a "functional"
symbol layer. The only difficulty lies in ensuring
that many different colour schemes are possible,
even though symbols must always be displayed
with high contrast relative to the background.
In my opinion there's no problem with using a few
symbols for things that are mostly flavour, but
following the roguelike spirit, even "mostly useless"
flavour items might have some uses. Lamps and
torches might be wrested from the walls and carried,
strong adventurers might toss dungeon furniture
at their enemies. Moss might be edible in times of
dire need. Mostly-equivalent flavour items
should share symbols; e.g. all furniture might have
the same symbol, torches and lanterns definitely
should have the same symbol.
Furthermore, by using screen sizes much larger
than 80x25, and having the computational
resources of a modern computer to calculate
FOV and light maps, the mere visual "shape" of
the information presented can made be fairly
attractive. Multiple light sources and complex,
precise FOV is not merely eye candy, but can also
add to the gameplay. FOV in traditional roguelikes
tends not to support stealth gameplay, for
instance(at least not without abstracting it all away).
-kaw
> Some guys use noise (Perlin, simples, FBM...) to vary the colors of
> the background, resulting in an appealing looking screen. I've shown
> them to some of my non-RL-savvy friends, and they liked it much more
> than regular RLs. (Which are an acquired taste, IMO.)
This is true. I think that 'standard' roguelike (ASCII + console, which is
standard only in some sense) are too abstract to not be an acquired taste
for most players.
> Playing with background colors also doesn't hurt readability, since
> they don't require the extra letters that David says contributes to
> the noise.
Yes. You can do a lot with colours. It is very cheap, but simply using
different colours for floor and wall helps a lot.
The nice pictures I've snipped need more than the 16 colours the standard
console has (so Crawl cannot have that). :(
David
Which has various implications like portability, easier access to the
blind and things like ttyrec/botting.
> I agree with David in that I don't associate a picture with a letter,
> but the letter definitely evokes feelings beyond its appearance as a
> letter. Is imagination and evocation the same thing?
No. The coloured letter can definitely create emotions for me even if I
have absolutely no mental image. I can understand that this kind of mental
processing of information can be intolerable to some -- the range of
approaches to how humans parse these letters seems enormous. Would be a
nice topic for a PhD in psychology :)
David
The mind is a tricky beast. I am intrigued by icons, and the question
of "what is iconic." I would like to submit Monopoly as an example of
a game whose icons have endured despite (and maybe even because of)
total abstraction. (You are a boot competing with a terrier for real
estate?) Because the game mechanics (decisions, risk, and resource
management) are so apparent, the game has the charm of a building with
no facade. I think Roguelikes are charming to me for the same reason.
When we start to idolize the mechanics and bareness, I wonder if
there's isn't a kind of steampunk perversity at play. The temptation
to "geek out" on dice, stats, the process of rolling a character and
looking up all the Thac0 values and skill points. The books, the
tables, the "game screens" that were basically duck blinds made out
statistics, where you could be alone with your dice. If you didn't
have a pewter model, often your 4-sided die was you and the 6-sider
was the troll. The reduction of icons to the barest minimums. The
cult of the imagination. Symbolic, faintly nostalgic resistance
against the tides of shiny drek at our shores. Don't get me wrong, I
love the aesthetic and I think it has enormous real charm. Granted,
there's an initiation and learning curve and I think that might
perversely play into the appeal...
But in the "best of both worlds" spirit, I would also like to use
graphics while preserving those qualities (legibility, subtle charm,
and imagination). The line is a very thin one...I've got to agree
with kaw:
> It's worth noting that graphics can very easily be
> "worse than neutral", though -- if the tile for the
> dangerous troll looks ridiculous or is just plain poorly
> drawn, it's harder to take the game seriously.
Back before Angband supported tiles, I edited a small bitmap font
(7x13px) to give the game graphics. Link:
http://www.benhem.com/angbandgraf.jpg
(the message output was hieroglyphic gobbledygook, of course. I got
most important news to show up in separate windows with normal fonts,
but in time I learned to actually read the new font! Which is an
indication of just how misspent youth can be.)
I recently used those as the launch-point for the 8-bit sprites in
Wayfarer. It's hard to get the essence of the desired image -- I
would compare it to origami. But there's a very low risk of cuteness
or over-realism! Also, I'm very nearsighted and dislike squinting to
distinguish between dragons and newts. I want big, chunky pixels so I
can decide whether to steamroll or flee in the space of one heartbeat.
Another thing I want to throw out there, even though it's not possible
in console-output games: movement. A big part of the way the mind
instinctively recognizes life. In Wayfarer, I'm gambling that
smoothly sliding pieces and 2-frame animations will be enough to
enliven things. Also, the trees are all random yet easily recognized
as a single class of object, which is a simple trick that could be
used for rubble, junk, etc. Link:
http://www.benhem.com/games/wayfarer
I would like to make a graphical roguelike.
But my drawing skill is much worse than my english.
So, that's just not an option for me :(
<snip>
>
> Yes. You can do a lot with colours. It is very cheap, but simply using
> different colours for floor and wall helps a lot.
That's something like I had in mind. Even being restricted to one
colour/symbol per square per unit time there is a lot of leeway and
I'm not sure in general we're grabbing the opportunities that are
there.
>
> The nice pictures I've snipped need more than the 16 colours the standard
> console has (so Crawl cannot have that). :(
>
That's a shame. The later levels of Crawl are wonderfully evocative,
but the beginning levels less so. Of course that may be simply a
function of there being less of a character mythology built up in the
early game and hence less association taking place.
I fully understand and appreciate the reasons for maintaining 16
colour maximum though, and long may that continue (console play of
Crawl).
Best,
P
Well, there's Unicode which enables one to use all characters from
different alphabets. :)
Leaving chinese aside even latin alphabets have more than enough
different character letters to play with.
Although I agree that is wrong to use those characters solely for the
purpose of increasing the number of monsters without differentiating
them.
But it might be another option to let the player recognize different
monsters more easily.
For example NetHack has five brown d's: jackal, coyote, wolf, warg,
werejackal, werewolf.
Unicode offers 14 different d's that could be used:
U+010F LATIN SMALL LETTER D WITH CARON
U+0111 LATIN SMALL LETTER D WITH STROKE
U+018C LATIN SMALL LETTER D WITH TOPBAR
U+0221 LATIN SMALL LETTER D WITH CURL
U+0256 LATIN SMALL LETTER D WITH TAIL
U+0257 LATIN SMALL LETTER D WITH HOOK
U+1D6D LATIN SMALL LETTER D WITH MIDDLE TILDE
U+1D81 LATIN SMALL LETTER D WITH PALATAL HOOK
U+1D91 LATIN SMALL LETTER D WITH HOOK AND TAIL
U+1E0B LATIN SMALL LETTER D WITH DOT ABOVE
U+1E0D LATIN SMALL LETTER D WITH DOT BELOW
U+1E0F LATIN SMALL LETTER D WITH LINE BELOW
U+1E11 LATIN SMALL LETTER D WITH CEDILLA
U+1E13 LATIN SMALL LETTER D WITH CIRCUMFLEX BELOW
>> So, given pretty much a modern OS and an unlimited palette of
>> colors and symbols (delivered to the screen via graphical methods),
>> how do we go about sprucing the visuals of the stereotypical dungeon,
>> its denizens and their environs up a bit?
Modern terminals offer Unicode and 256 color modes. This is not
"unlimited" but goes a long way compared to ASCII and 16 colors if you
don't want to give up on character based displays.
> I am against using more colours and more symbols for flavour only. The
> reason is that in a graphical game, things like torches at the wall,
> furniture in a room and plants by the wayside are self-explaining. In
> a console setting, you have to look these up, making for additional
> flavour (to some, not for me) but more tedious play.
I think it depends on how the color is used and of course that the
game has enough differentiated monsters to start with.
If there are several possible colors for one monster, I don't care. It
only makes the screen a little more colorful.
If color is used to show differences between monsters of the same
monster class it should be consistently used.
Bye
Patric
--
NetHack-De: NetHack auf Deutsch - http://nethack-de.sourceforge.net/
NetHack for AROS: http://sourceforge.net/projects/nethack-aros/
IIRC support for it is quite platform&terminal dependent.
E.g. does this work with mac os x's default terminal? Most mac users
don't even know it exists, let alone change it to something better.
KTerm is also sometimes notorious for it's support of such features
(as well as a couple of other semi-common terminal emulators for
linux).
-Ido.
> The nice pictures I've snipped need more than the 16 colours the standard
> console has (so Crawl cannot have that). :(
>
> David
I think xterm-256 support is farily common among terminal emulators
these days.
Tiled roguelikes often look too 'fan-made', due to the lack of open
source artists. In POWDER, for example, you can still use the Classic
tileset, which immediately gives the game another feel - suddenly,
you're very much aware that you're playing a game by a hobbyist game
developer. The Akoi Meexx tileset, however, adds polish in a way that
makes it believable people would actually pay for the game.
ASCII doesn't suffer from this problem. Graphically, there isn't a lot
of difference between a 7DRL and one of the Major roguelikes. Sure,
the user interface may be a little less polished in a 7DRL, but given
time, the developer can fix this on his own. Compared to modern games,
ASCII rogulikes might look archaic, but not amateuristic. ASCII has a
timeless, professional flavour to it.
Whenever we discussed colours, there was some stumbling block. Not sure if
it was lack of portability (we still support DOS) or lack of a standard.
Crawl needs much less than 256 colours, actually -- I would be happy if we
could have the second 8 colours as backgrounds. This is one of the
limitations about console output that I feel too restrictive.
Thanks for the heads up. I hope tht one day Crawl can use more colours,
falling back on to the 8+8 if needed.
David
I don't see why not. It has a tile mode; why not add a full-color
mode, including full background color for each tile?
Like a hybrid ASCII~Tiled mode?
I'm not sure I like the idea of a background colour in an ASCII-based
RL - it might lose some of the inherent clarity that is one of the
benefits (IMHO) of ASCII. Perhaps animation (beyond blinking) is the
way to go instead?
Best,
P.
I don't think of it that way, but I guess to some extent every
roguelike is a tiled game since they use mono-spaced fonts. I just
mean setting the background color for each character in addition to
the foreground color. MS Word has a feature like this that lets you
"hilite" text in different colors; it's really the same principle.
It has the potential to compromise clarity only if used poorly. Used
well, it greatly improves clarity. Simply setting all impassable tiles
(walls, closed doors, etc.) to have light background colors alone does
wonders for the display -- makes it much easier to parse what is
happening on the screen at a glance. I'm at work now, but when I get
home tonight I'll try to remember to post some screenshots from my
game in development -- I'll be curious to hear what you think of the
aesthetic.
Please do. I've been thinking about how to spruce up the display in
Kharne whilst still adhering to the general spirit of ASCII (1) and
thus pondered my thoughts verbatim onto the group, and anyone else's
perspective would be most welcome.
Best,
P.
(1) Even though I do have one advantage in that I'm merely emulating
an ASCII display by plopping text out in graphical form
Check out some UR screenshots:
http://umbrarumregnum.110mb.com/screenshots/090215_forest5.png
http://1.bp.blogspot.com/_1FGs7prdigU/SceUTD934JI/AAAAAAAAAFg/WE6cGqA6NmM/s1600-h/screenshot023.png
http://1.bp.blogspot.com/_1FGs7prdigU/SceUMD__KkI/AAAAAAAAAFY/zaWsXfoBljM/s1600-h/screenshot022.png
http://3.bp.blogspot.com/_1FGs7prdigU/SceUA2TGkmI/AAAAAAAAAFQ/TWyIWXwMp80/s1600-h/screenshot021.png
I think it works rather well personally. In my own title The Lion
King (never released) I experimented on using similar styles with just
the console's 8+8 colours. Having just 8 backgrouand colorus was very
limiting, but it could still produce a very rich and colourful style.
It worked well in my opinion, and with higher colour depth I think it
looks even better.
--
Darren Grey
From what I've seen it is mostly terminal dependent.
> E.g. does this work with mac os x's default terminal? Most mac users
> don't even know it exists, let alone change it to something better.
No, the default terminal doesn't support it.
But iTerm does.
Although I would recommend every programmer to have a fallback mode
with 8 or 16 colors.
> KTerm is also sometimes notorious for it's support of such features
> (as well as a couple of other semi-common terminal emulators for
> linux).
Googling I found the claim that it does support it but a quick test on
my local machine it didn't work.
Screw curses and terminals. The 8/16 colours are ugly and are a
reason for lots of the angry fruit salad. I'm not a fan of the
libtcod extreme either (font so small that it becomes a bitmap) but I
think there is a lot of nice stuff you can do with 80x25 or 80x50 if
you just admit to the existence of graduations.
Stuff like fading smoothly can make a big difference to the visual
feel, cutting away the blocky transition. But it should bleed into
actual game design. Maybe how injured you are is a smooth fade from a
white @ to a red @?
I had a lot of fun in Jacob's Matrix breaking free of the idea of
paletted colours to build a game where smooth colour transitions were
essential. I don't want to go back.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
>
> Stuff like fading smoothly can make a big difference to the visual
> feel, cutting away the blocky transition. But it should bleed into
> actual game design. Maybe how injured you are is a smooth fade from a
> white @ to a red @?
Ha, degenerate minds think alike. I was going to flicker bloodied
creatures (and the @) bright red in Kharne.
Best,
P.
Yeah the original font was 8x8 pixels, which is insanely small.
Perhaps it was developed on a low resolution? :)
Right now I'm using Celtic Garamond 10x10, which is a lot better
(don't let the 2 pixels difference fool you), especially since it's
anti-aliased. There are some beautiful typographies here. The biggest
fonts in the pack that comes with libtcod, 12x12, are a bit too big
for my tastes, though.
Jotaf
Here are some screenshots:
http://img11.imageshack.us/img11/6273/73281112.png
http://img16.imageshack.us/img16/2051/47081763.png
http://img14.imageshack.us/img14/4766/26605261.png
http://img21.imageshack.us/img21/4740/44183476.png
On display are subterranean lakes, lava lakes, and chasms, as well as
a mouse-driven auto-travel feature. The glowing teal quotation marks
on the floor are patches of luminescent fungus. The last shot does a
decent job at showing off the lighting model.
Sorry, I meant the first shot.
Surely people think of all ASCII roguelikes as being made by hobyist
game developers?
And it's hard to imagine anyone paying money for one.
- Gerry Quinn
Tarn Adams (of Dwarf Fortress) lives off of Paypal donations sent by
fans of the game.
To be fair, of course, the game isn't entirely ASCII (or entirely
roguelike), but I think the counterpoint stands. (But maybe only as
the exception that proves the rule.)
8x8 is the standard terminal font size. The trick is, the terminal
normally is either 80x25 or 80x50 characters. In both cases 8x8 is
fine unless you use windowed mode in 1600x1200 resolution...
Mingos
"People" as in "people who a roguelike for the first time" or "people
who play roguelikes regularly"?
I don't think of roguelike developers as hobbyist game developer
because there are probably almost no professional game developer that
get paid for something that gives them an opportunity in programming
roguelikes.
Roguelikes are just to different from the usual commercial game.
I am sometimes surprised to learn that a roguelike developer is a
professional programmer and wonder how their paid code looks like.
> And it's hard to imagine anyone paying money for one.
People have been paying for Rogue in the 80ies. :)
And if Powder would be sold commercially I'm certain people would buy
it.
Probably not enough to make a living out of it but how many game
developers are?
Depends a bit on the language you are using.
For C/C++ there are the *curses library that offer wide character
support but the built-in support for Unicode is working (but not that
great if you're asking me).
Java has built-in Unicode support but its terminal capabilities are
abysmal to non existent.
Ruby and Python have more or less built-in Unicode support.
I don't know how the special roguelike libraries cope with Unicode.
I would say the semi-standard way to do Unicode is currently just
barfing out UTF-8.
For NetHack-De which currently outputs latin1 encoded strings I
already have done some tests and I will eventually implement an option
to toggle between latin1 and utf-8 output. UTF-8 input is already
handled. But this will only be for output - internally the strings
will stay 8-bit.
NetHacks framework and the capabilities of C don't really allow
anything else without getting yourself into a big mess.
> Fiddling around with my
> local terminal emulator, it appears to have UTF-16 in G2. But this
> strikes me as more than a little implementation dependent.
UTF-16 as default looks odd to me. Terminals that support unicode
usually are a least UTF-8 capable.
Which to be frank is pretty standard for many players.
--
Darren Grey
Hey that looks pretty cool! Do you have a blog or something?
Torchlit (my RL in development) has a similar lighting model. I'll
have to implement some luminescent mushrooms too. They strike my
imagination quite a bit.
Another thing I noticed is how you clearly separate flavor text from
gameplay information. It would be nice if more people adhered to
that ;)
> 8x8 is the standard terminal font size. The trick is, the terminal
> normally is either 80x25 or 80x50 characters. In both cases 8x8 is
> fine unless you use windowed mode in 1600x1200 resolution...
>
> Mingos
Guilty! Although the demo shows how to let the user choose between
different font sizes with simple keyboard shortcuts. It would be
better to leave this option, just in case.
Jotaf
Thanks! No blog, just my occasional wide-eyed ramblings on this
newsgroup. I'm not a pro coder, and this is the first real program
I've ever written from scratch, so I had low expectations starting
out. I'm pretty happy with how it's turning out, though -- maybe I
should start a blog about it. I'm also a Mac OS X guy, and while the
code should be portable (it's all straight-up C except for the custom
terminal front-end which is in objective-C / Cocoa), I don't own any
Windows computers and I haven't the skill nor inclination to learn to
port it, so the audience is necessarily going to be fairly limited
unless someone else takes charge and ports to libtcod or somesuch.
> Torchlit (my RL in development) has a similar lighting model. I'll
> have to implement some luminescent mushrooms too. They strike my
> imagination quite a bit.
I'm always looking for excuses to add colorful lights to the game,
particularly when they aren't flame-colored. Between lava, torches,
fire and flame monsters like will-o-the-wisps and salamanders, there
are enough reddish-gold lights. I think I'm going to add acid pools as
another liquid type and have them glow green. I agree that luminescent
mushrooms are extremely interesting elements for building a mood --
they were near the top of my features list :) -- but I can't claim
complete credit for the idea. Metroid Prime used them to phenomenal
effect in many areas and that is the inspiration.
> Another thing I noticed is how you clearly separate flavor text from
> gameplay information. It would be nice if more people adhered to
> that ;)
Yeah, I agree. I think much of the charm of these games is the epic-
fantasy imagery they evoke. I am trying to make my dungeons as
evocative as I can. Flavor text is part of that. The lakes, lava pits
and chasms are another. I love it when two chasms are generated next
to each other with a narrow traversible strip in between -- reminds me
of the Balrog scene in Lord of the Rings. At the same time, the
message line is basically the most valuable real estate on the screen
and probably should be reserved for functional messages.
I really like these, especially the lighting gradient.
Best,
P.
Ouch... Seems I'm living in the past with my 1280x1024...
Anyways, UR, with its 128x96 console, looks good on my 17" screen in
windowed mode, so I don't find readability a big issue. At least for
me it's perfectly legible... Paradoxically, I found the game very hard
to read on a 26" screen... There's also a possibility of switching to
a 10x10 font and playing UR in fullscreen (1280x960). In theory, this
should provide a good readability boost to anyone, but personally, I
don't like it (I mean, the look of the 10x10 font, not readability).
I'm adding it as an option, together with configurable fullscreen/
windowed mode, map display/stats bar/message bar position just to make
the game a bit configurable in terms of display...
Mingos
> I'm always looking for excuses to add colorful lights to the game,
> particularly when they aren't flame-colored. Between lava, torches,
> fire and flame monsters like will-o-the-wisps and salamanders, there
> are enough reddish-gold lights. I think I'm going to add acid pools as
> another liquid type and have them glow green. I agree that luminescent
> mushrooms are extremely interesting elements for building a mood --
> they were near the top of my features list :) -- but I can't claim
> complete credit for the idea. Metroid Prime used them to phenomenal
> effect in many areas and that is the inspiration.
You don't have to make all flame monsters reddish-gold, you know. :)
I always figured will-o-the-wisps to be more of a bluish light.
You could also have flame critters that are hot enough to burn blue
or white. Or polluted with metals to burn other colors.
Don't swamps have bluish lights from burning marsh gas deposits
(and considered a source of will-o-the-wisp legends.)
Speaking of aesthetics, you should check the latest post on
http://urprogress.blogspot.com.
When I see this, I really believe that colors (more than unicode or
customized characters) can make text-mode roguelikes as attractive as
mainstream games while keeping some of the qualities inherent in
classic roguelikes (readability and so on...).
--
jice
> Screw curses and terminals. The 8/16 colours are ugly and are a
> reason for lots of the angry fruit salad. I'm not a fan of the
> libtcod extreme either (font so small that it becomes a bitmap) but I
> think there is a lot of nice stuff you can do with 80x25 or 80x50 if
> you just admit to the existence of graduations.
Just out of curiosity, if you are going to break out of the terminal
color restrictions, why restrict yourself to the size? If you don't
stick with the 8/16 color palette, which I agree is awful, then you
aren't going to be able to run it across a telnet terminal. At least
not with the standard terminals people run.
I grappled with whether to work in curses for my own work so it could
compile relatively easily and run across a terminal for more players.
I decided to go with Java/AWT instead because these days its extremely
portable and I have better control over the color and screen layout
(in particular I wanted a square aspect ratio on my map). Once I made
that decision, I didn't feel any need to stick to the terminal size
restrictions.
All that said, I do think there are some really well done interfaces
for 80x25. I am consistently impressed by Crawl year-to-year packing a
lot of information into such a tiny display.
What's your definition of "standard terminal"?
XTerm and Putty support 256 colors just fine.
> I grappled with whether to work in curses for my own work so it could
> compile relatively easily and run across a terminal for more players.
> I decided to go with Java/AWT instead because these days its extremely
> portable and I have better control over the color and screen layout
> (in particular I wanted a square aspect ratio on my map). Once I made
> that decision, I didn't feel any need to stick to the terminal size
> restrictions.
That's reasonable. You don't have to restrict yourself especially if
you're not using the console.
What do you think is a reasonable size (x,y) for a graphically-
emulated console, using non-square fonts?
>
> All that said, I do think there are some really well done interfaces
> for 80x25. I am consistently impressed by Crawl year-to-year packing a
> lot of information into such a tiny display.
Agreed. It is a paragon of UI efficiency.
I wish they'd do an all-singing, all-dancing TK-esque version sometime
though.
Best,
P.
Good idea! Consider it done.
On Mar 26, 5:44 am, jice <jice.nos...@gmail.com> wrote:
> Speaking of aesthetics, you should check the latest post onhttp://urprogress.blogspot.com.
> When I see this, I really believe that colors (more than unicode or
> customized characters) can make text-mode roguelikes as attractive as
> mainstream games while keeping some of the qualities inherent in
> classic roguelikes (readability and so on...).
UR is indeed very pretty. The thing about it that gives me pause,
though, is that its beauty seems to depend on extremely small tile
sizes and an enormous number of tiles onscreen at once. In other
words, it's pretty because it approximates a bitmap picture at very
low resolution. I think it will prove difficult to actually play if
your character is the size of a single tile. And if it's larger than a
single tile, then I don't understand why you wouldn't just go the rest
of the way and abandon the text altogether in favor of graphics. On
this screenshot, for example, the '@' sign looks to me like an
indecipherable speck of red, and I can't imagine playing it without
either substantially increasing the size of the tiles or sitting six
inches from my monitor. And in either case, it seems to me that the
bitmap beauty goes out the window.
UR lets you define the console size: 80x60, 100x75 or 128x96. So it's
not altogether that many cells. I take screenshots at max resolution
because of my personal taste.
The cell size is 8x8, so it's standard. If it's small on your screen,
any roguelike will seem to have small tiles at your screen resolution.
Anyway, a 10x10 font is also available, I just never use it.
> words, it's pretty because it approximates a bitmap picture at very
> low resolution. I think it will prove difficult to actually play if
> your character is the size of a single tile. And if it's larger than a
> single tile, then I don't understand why you wouldn't just go the rest
> of the way and abandon the text altogether in favor of graphics. On
> this screenshot, for example, the '@' sign looks to me like an
> indecipherable speck of red, and I can't imagine playing it without
> either substantially increasing the size of the tiles or sitting six
> inches from my monitor.
In 2560x1600 resolution, any game will be indecipherably small. In
1024x768, it's just fine, trust me. I have a laptop with a 15" screen
and in full screen it's fine. On my desktop's 17" screen, windowed
mode in 1280x1024 also appears fine...
> And in either case, it seems to me that the
> bitmap beauty goes out the window.
As soon as the new demo is released, I encourage you to give it a try,
despite your first impression. If you find it unreadable, dump it. But
I'm pretty confident you won't :P
BTW, you mentioned developing your game for Mac OS X only and leaving
porting it (possibly to libtcod) for others. Why's that? Libtcod has a
Mac port - maybe you'd like to give it a shot? That would make
compiling the Winbloze/Linux versions way easier.
Mingos
Well its defaut font is 8x8, which is small but not excessively small.
It's the default font size I'm using in pyromancer and the doryen
arena, and they don't give this extremely small tile impression. I
think UR gives this impression because of the huge console and the
font it's using. UR can be configure to use a smaller console and a
bigger font, like 10x10. With this configuration, it looks less like a
bitmap but it's still pretty.
--
jice
You know... I'm probably confusing my frustration with the ncurses
color mapping and my own lack of patience for changing terminals with
the actual terminal properties. My experience has basically been that
when I change OS's, terminal emulations (for putty) or terminal apps
(for linux) the colors change. In, say, the OSX terminal I had to
override the settings on my crawlrc file on aksraisc (sp?) because
'dark grey' is impossible to see. When I developed in curses (or
hell... even run LS or vim with syntax highlighting), I found that the
colors were terribly inconsistent when I played over putty, my work
terminal (rxvt?) or the OSX terminal.
In hindsight, I probably could have made it work. I'm also not sure if
curses lets you define your own color palette easily... it probably
does. So I might just be flat out wrong.
> What do you think is a reasonable size (x,y) for a graphically-
> emulated console, using non-square fonts?
I stick to 800x600, but I'll probably eventually make it adjustable.
> Well its defaut font is 8x8, which is small but not excessively small.
> It's the default font size I'm using in pyromancer and the doryen
> arena, and they don't give this extremely small tile impression. I
> think UR gives this impression because of the huge console and the
> font it's using. UR can be configure to use a smaller console and a
> bigger font, like 10x10. With this configuration, it looks less like a
> bitmap but it's still pretty.
I ought to try this. I have to confess I share the same opinion that
pyromancer and UR fonts were very very small for my weak eyes. For
terminal roguelikes, I set the font size to 18pts at least, and for my
own I used 16x16 tiles that contain a 20pt font. I also really like
Legerdemain's 22 or 24 pts font. So... clearly is personal preference,
but trying to actually see the characters in UR or pyro makes me all
bug-eyed.
Although for developing, reading, and terminals I am ok with 10pt
fonts. I think its easier to identify words in a smaller font. It gets
hard for me when I want to quickly tell the difference between single
characters like I do in RLs.
On the other hand not using a terminal means you can't play over ssh
and makes it harder to pretend all those weird characters on your
screen are work. ;)
No. Because at 2560x1600 res you have a 30" monitor.
The smallness is a function of DPI. The machine I'm on now is
1280x768, but has a 8.9" screen so 8x8 fonts are actually smaller on
it than on a 2560x1600 30" display.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
I'd be interested to see what a screenshot with larger and fewer tiles
on-screen at once looks like.
> The cell size is 8x8, so it's standard. If it's small on your screen,
> any roguelike will seem to have small tiles at your screen resolution.
> Anyway, a 10x10 font is also available, I just never use it.
8x8 is a standard from when computer monitors were approximately the
same size as today but ran at probably 10% of the resolution. In this
day and age, eight-point text is the illegible braille at the bottom
of contracts.
> In 2560x1600 resolution, any game will be indecipherably small. In
> 1024x768, it's just fine, trust me. I have a laptop with a 15" screen
> and in full screen it's fine. On my desktop's 17" screen, windowed
> mode in 1280x1024 also appears fine...
I'll take your word for it, but I'll also suggest that your eyes may
be better than mine, or your tolerance for tiny text greater.
> As soon as the new demo is released, I encourage you to give it a try,
> despite your first impression. If you find it unreadable, dump it. But
> I'm pretty confident you won't :P
Fair enough, and I don't mean to dump on your project, which is indeed
very impressive.
> BTW, you mentioned developing your game for Mac OS X only and leaving
> porting it (possibly to libtcod) for others. Why's that? Libtcod has a
> Mac port - maybe you'd like to give it a shot? That would make
> compiling the Winbloze/Linux versions way easier.
Maybe I will try at some point. But in general I am not doing this to
release a game, I am doing it because I enjoy programming my
roguelike. I'd still put the odds at less than 50% that I will ever
release anything for public consumption even though the game is
completely playable (and in my mind quite fun) right now. The genre
seems to expect certain niceties that I just don't want to code. The
capability to save your game is one; I don't support that feature at
all. Reading data from special data files is another; all my monsters,
tiles, lights, objects and so on are initialized directly into global
variables in a globals.c file. Libtcod is probably another example.
These are all things that players who are not me would probably like
to have -- but they don't mean much to me, and they sound like a drag
to code, so I have no intention to code them. It's not a grand plan to
exclude these features, it's that when I get home after being a lawyer
during the daylight hours, the prospect of learning a bunch of
libraries is not nearly as appealing as creating spiders that can
shoot webs -- and tomorrow it'll be something else.
You seem to contradict yourself. Indeed, the screen's LCD matrix DPI *
the screen's size define the screen's top resolution. But DPI isn't
the same for all screens, as you appear to imply by saying that "at
2560x1600 I'd have a 30" monitor". I think it's 72 DPI for most
commonly used screens (correct me if I'm mistaken, I'm by no means an
expert in this field). Yours has more. A 19" screen with the same
number of DPI as yours would be able to display 2560x1600.
Mingos
OK, I'll upload a bunch of them later tonight.
> I'll take your word for it, but I'll also suggest that your eyes may
> be better than mine, or your tolerance for tiny text greater.
My sight isn't that good: -2 dioptres (and I refuse to wear glasses,
even though the ophtamologist told me to).
> Fair enough, and I don't mean to dump on your project, which is indeed
> very impressive.
Thank you :).
> Maybe I will try at some point. But in general I am not doing this to
> release a game, I am doing it because I enjoy programming my
> roguelike. I'd still put the odds at less than 50% that I will ever
> release anything for public consumption even though the game is
I estimate my chances with even more scepticism. Maybe 10% ;)
> completely playable (and in my mind quite fun) right now. The genre
> seems to expect certain niceties that I just don't want to code. The
> capability to save your game is one; I don't support that feature at
But it's so simple to implement! Or is it a FEATURE?
> all. Reading data from special data files is another; all my monsters,
> tiles, lights, objects and so on are initialized directly into global
> variables in a globals.c file. Libtcod is probably another example.
Well, the genre doesn't require you to use external data files. It's
totally up to you whether you initialise everything within the code or
using external files. I chose the latter because I find it convenient.
But if you're comfortable with hard coding everything, there's nothing
wrong with it.
> These are all things that players who are not me would probably like
> to have -- but they don't mean much to me, and they sound like a drag
> to code, so I have no intention to code them. It's not a grand plan to
> exclude these features, it's that when I get home after being a lawyer
> during the daylight hours, the prospect of learning a bunch of
> libraries is not nearly as appealing as creating spiders that can
> shoot webs -- and tomorrow it'll be something else.
Fair enough. I think of the console size and cell size along these
lines. The game is, firstly and most importantly, for my personal use.
I like it this way and I have no intention of adapting it to the
others' expectations. Still, I added the chooseable console size (at
RGRD users' request) because it was very easy to implement this
feature. As long as I'm happy with it, I think it's fine (BTW, I'm in
a similar situation: coding UR often helps me relax after an entire
day of formal, suit-and-tie work... well, maybe not lately, since I've
been spending most of the time in the recording studio in the last
weeks, which might explain why UR's progress slowed down, hehe).
Mingos
I was the same until just a few months aqo ;)
> Anyways, UR, with its 128x96 console, looks good on my 17" screen in
> windowed mode, so I don't find readability a big issue. At least for
> me it's perfectly legible... Paradoxically, I found the game very hard
> to read on a 26" screen... There's also a possibility of switching to
> a 10x10 font and playing UR in fullscreen (1280x960). In theory, this
> should provide a good readability boost to anyone, but personally, I
> don't like it (I mean, the look of the 10x10 font, not readability).
> I'm adding it as an option, together with configurable fullscreen/
> windowed mode, map display/stats bar/message bar position just to make
> the game a bit configurable in terms of display...
Abilities to change fonts and font sizes would be nice, and I presume
one of the easier interface options to add. It might also be handy to
have a 200% zoom centred on character option, for those with poorer
vision or much smaller screens.
--
Darren Grey
Erm... maybe not just yet...
This, I can relate to! I've been through a period of trying to find
the fun in programming too -- my previous project just sucked it dry
until there wasn't a single drop of it left. Between my practically
immutable "perfect" engine, and the huge TO DO list that I added to
every day; I felt so depressed at the quantity of fun stuff I wanted
to do but never got to! So after a long period of research and
reflection, I came to the conclusion that I needed to become a hippie
and learn a different language, one that was more indie-friendly. Was
it hard? Well, not that hard. Was it worth it? Hell yes. Serialization
used to be a chore. Yesterday I had it with 2 lines of code: import
yaml, and load("file.txt"). Suddenly all of my structures resided in
memory. I'm happy :)
This, after I tried boost::serialization in the other project, and
failed. Bah.
Anyway I couldn't agree more, there should be no "required features",
this is not a job! If you make a webpage for your project you'll have
to clearly state those intentions there though, otherwise your mail
box will be full with complaints; most people think that programmers
are obliged to conform to some standards (ie, their standards).
Mingos said:
> My sight isn't that good: -2 dioptres (and I refuse to wear glasses,
> even though the ophtamologist told me to).
Are you kidding? I have -3.5 and I'm blind as a mole. You should use
contacts. And have a pair of glasses handy at home so your eyes don't
get tired from watching TV/sitting at the computer with your contacts
(although I did use contacts exclusively for about 5 years in a row,
and there was no problem). You should really consider it, contacts are
easy to get used to, and this way you won't absolutely need heavy
glasses when you get to your 30s, you're damaging your eyes dude :)
Jotaf
> 8x8 is a standard from when computer monitors were approximately the
> same size as today but ran at probably 10% of the resolution. In this
> day and age, eight-point text is the illegible braille at the bottom
> of contracts.
As a small businessman, every time I see a crawling-ants font on
a contract*1, I want to grab somebody's necktie and pull hard*2.
Come on guys, get used to a civilization that has mass-produced
paper now! Being that stingy with something as cheap as paper is
pointless as well as rude.
Besides, lawyers don't get paid in sheep anymore. You don't have to
slaughter sheep to make vellum or those stupid wool wigs these days,
so the cost of paper as a fraction of the attorney's wage is down
considerably since Shakespeare's day and you can eat mutton*3 when
you want to instead of for every damned meal.
Fortunately, these days I can usually get my hands on a PDF file,
convert to HTML, and print from a browser with an option that says
"render no type smaller than 14 points" for review purposes.
In fact, if I'm the first signatory, I'll usually sign my printout
with no crawling-ants fonts, and send that back instead of the
original format.
A lawyer whom I trust makes all her contracts available as plain
ascii text files. We hammer out the details, print in a single
font size, sign, and file. She gets repeat business from me.
Bear
*1 Varying sizes of fonts in a contract might make more sense
if the degree of "legally bound" a clause made the signatories
were proportional to the printed area taken by the clause.
But while it's a delightful idea, that's not the case, so
for what possible reason other than misdirection.... ?
*2 I do not, as a rule, act on this desire, and this is not in
any way a threat.
*3 Excuse me, you can't get "mutton" anymore, they insist on
calling it "lamb" now no matter how big it's gotten when they
slaughter it. Sigh. Yet more misdirection. Is misdirection
really such a basic human need as all that?
I seem to remember a roguelike game that had, as one of its startup
options, the ability to take the characters currently in your console
and use them as monsters, items, etc. Whatever document you were
working on (or your console command history) became the first level
of the dungeon by fiat. Since the prompt was "username@machine>"
you were guaranteed the @ not too far from the initial downstairs.
But you had to use the downstair quick or you'd get mobbed.
Bear
It has only one character for all of the wall tiles, that standard '#'
but with a variety of foreground and background colors you can easily
tell where different stone types change. Once you get more used to it
you can even tell what kind of stone it is from the colors since only
a few color are re-used on multiple stones.
I should point out that it is built in Java using libjsci, which makes
this kind of output very very easy. All of the many colors I used are
pre-defined constants, but you can define your own colors as well if
needed.
I guess I'm saying that if you want more color and unicode, Java
combined with libjsci is the way to go.
I used to see way better, but was spending 12 or 14 hours a day in
front of a CRT monitor... Now I see everything slightly blurry,
especially at larger distances. Luckily, ever since I switched to
using LCD monitors, my sight stopped deteriorating :P. Haven't got
worse in the last 4 years, so I guess there's not much to worry about.
he ophtamologist said I should wear glasses at school (I'm MPhil and
don't go to school anymore), at the movies (last time I went to the
movies was two years ago... and I didn't enjoy the movie anyway) and
while driving (I don't drive). He didn't mention the computer :P.
I do have a pair of glasses. Nice, stylish and very light black wire
rim and some sort of special lenses that also weigh nearly nothing,
but I still don't like to have glass in front of my eyes. While I'm
still able to read, see what's on the screen and recognise people, I
refuse to wear glasses, contact lenses or any other sight improving
gear. If there only was a "clairvoyance" spell to fix the sight
without it... ;)
Oh, yesterday I promised to upload screenshots using the 10x10 font
and completely forgot about it. I made a few during lunch break today.
If I don't forget again, I'll post them tonight.
Mingos
Get glasses with Anti-Glare coating... you'll forget you're even
wearing glasses. I know I do.
Thanks, but no, thanks.
Anyway, I finally remembered about the screenshots using different
terminal and font sizes. You can get it from the screenshots section
on UR's site (http://umbrarumregnum.110mb.com/).
Mingos
The Aesthetics of ASCII Graphics: Discussion about Glasses :P
Whatever suits you best! I always heard that sitting in front of the
tellie or computer is what causes poor sight, but it might not be the
case with LCD monitors. Which would be a big technological advance
IMO :)
<snip>
> Well, the genre doesn't require you to use external data files. It's
> totally up to you whether you initialise everything within the code or
> using external files. I chose the latter because I find it convenient.
> But if you're comfortable with hard coding everything, there's nothing
> wrong with it.
I'd recommend using an SQLLite backend database instead of TXT files -
I've been using one for some time now for my in-dev roguelike and its
a pleasure to use and code against.
Best,
P.
I'm loving YAML for Python by the way. I only need one function call
from the library. That's the secret combination I was talking about
earlier in this thread :)
Jotaf
> I'd recommend using an SQLLite backend database instead of TXT files -
> I've been using one for some time now for my in-dev roguelike and its
> a pleasure to use and code against.
I work with a language whose native data structure is an associative
array, stored either in memory or on disk. It's enjoyable for similar
reasons.
This is because you can't source a 19" monitor with 2560x1600, at
least not anywhere I've seen. Right up to 30" you max out at
1920x1280ish, and then you get the final bump only when you hit 30".
You are quite correct that in the future we may see 2560x1600 on a 10"
display, but for now, if you detect that as your res, you can be
pretty confident you are on a big screen.
> I think it's 72 DPI for most
> commonly used screens (correct me if I'm mistaken, I'm by no means an
> expert in this field).
That is the traditional value. We've seen it creep up, however.
Maxes out around 100 DPI. The 1280x768 on 8.9" is on the high end,
but I think the new Sony Vaio P is even higher.
Personally, I can't wait until we all have 300 DPI so we can junk the
silly concept of "anti aliasing" fonts.
> On Mar 26, 4:56 pm, Mingos <dominikmarc...@gmail.com> wrote:
>> On 26 Mar, 20:35, Jeff Lait <torespondisfut...@hotmail.com> wrote:
>>
>> > No. Because at 2560x1600 res you have a 30" monitor.
>>
>> > The smallness is a function of DPI. The machine I'm on now is
>> > 1280x768, but has a 8.9" screen so 8x8 fonts are actually smaller on
>> > it than on a 2560x1600 30" display.
>>
>> You seem to contradict yourself. Indeed, the screen's LCD matrix DPI *
>> the screen's size define the screen's top resolution. But DPI isn't
>> the same for all screens, as you appear to imply by saying that "at
>> 2560x1600 I'd have a 30" monitor".
>
> This is because you can't source a 19" monitor with 2560x1600, at
> least not anywhere I've seen. Right up to 30" you max out at
> 1920x1280ish, and then you get the final bump only when you hit 30".
> You are quite correct that in the future we may see 2560x1600 on a 10"
> display, but for now, if you detect that as your res, you can be
> pretty confident you are on a big screen.
>
>> I think it's 72 DPI for most
>> commonly used screens (correct me if I'm mistaken, I'm by no means an
>> expert in this field).
>
> That is the traditional value. We've seen it creep up, however.
> Maxes out around 100 DPI. The 1280x768 on 8.9" is on the high end,
> but I think the new Sony Vaio P is even higher.
100 dpi seems most common to me these days, although too many people are
running lower than their LCD's native resolution -- can't really blame
them considering the lack of an easy-to-access zoom function, but it
sure is ugly.
> Personally, I can't wait until we all have 300 DPI so we can junk the
> silly concept of "anti aliasing" fonts.
+1. Can't wait until I can actually get decent font rendering.
>> I think it's 72 DPI for most
>> commonly used screens (correct me if I'm mistaken, I'm by no means an
>> expert in this field).
>
> That is the traditional value. We've seen it creep up, however.
> Maxes out around 100 DPI. The 1280x768 on 8.9" is on the high end,
> but I think the new Sony Vaio P is even higher.
I'm at 128 DPI on my subnotebook. It makes small fonts very hard to
read.
> Personally, I can't wait until we all have 300 DPI so we can junk the
> silly concept of "anti aliasing" fonts.
If resolution gets high enough, we're going to need graphics APIs that
lose the idea of a "pixel" and just specify screen regions in some
artificial or real-valued coordinate system.
Bear
It's not silly, its just a tradeoff.
> If resolution gets high enough, we're going to need graphics APIs that
> lose the idea of a "pixel" and just specify screen regions in some
> artificial or real-valued coordinate system.
No need for resolution to go higher than our eyes can handle.
It may be that 2D graphics will in time become obsolete though.
- Gerry Quinn
--
Lair of the Demon Ape (a coffee-break roguelike)
<http://indigo.ie/~gerryq/lair/lair.htm>
[on screen resolutions, now and later]
> No need for resolution to go higher than our eyes can handle.
I fully agree. Isn't this already the case with digital cameras where the
hunt for extreme resolutions was/is counterproductive?
> It may be that 2D graphics will in time become obsolete though.
I honestly do not understand this. Since 2D is a very clear (and
simplified and abstract) method of displaying information, I cannot see
how it would go out of usage. I can see it going out of fashion for the
commercial game industry but that is more their default than anything
else.
David
I mean 2D screens may go out of fashion in favour of some optical system
that provides full-colour stereographic images.
It will be possible to emulate large flat coloured planes on this, but
it will look a bit old-fashioned.
ASCII oguelikes would be able to use the equivalent of isometric
graphics (i.e. letters standing out of the page) as part of standard
text output functions.
- Gerry Guinn