Suggestions for a square font?
Alexin
seek some advice. I have recently started messing around with making
some kind of a proto-roguelike. (I doubt it will ever get to the point
where it would qualify as a true roguelike.) I've been using SDL for
the graphics side of things, and want to have both a text-display mode
and a sprite-based mode. As such, I figured that I might just as well
go about writing a system which is able handle both in the same way,
with a simple toggle for whether images or text is blit'ed to the
screen.
The problem, however, is that there don't seem to be any free (or
really, any at all) monospaced square (16x16, 24x24, 32x32; that sort
of thing) fonts on the internet. Without such a font, I would need to
deal with translating the proper places to blit font in relation to
where the sprite's footprint is, which would make the entire idea
somewhat senseless, aside from causing the toggle from sprite to
text-display modes to be disorienting.
So, I figured I'd ask ya'll what you think. Do you know of any such
square fonts? Since I am using SDL anyways, should I even bother to use
the standard ascii set of characters, or should I use some other
character set? Chinese characters are fairly square-shaped, although I
am not sure if the fonts used on computers are actual squares; do you
think that might make sense, or would it just be too confusing to
people unaquainted with the symbols? Basically, if you could have a
text-graphic roguelike made from whatever kind of glyphs you desired,
what glyphs would you choose?
Interested in hearing what ya'll think.
-Alexin
Krice
> The problem, however, is that there don't seem to be any free (or
> really, any at all) monospaced square (16x16, 24x24, 32x32; that sort
> of thing) fonts on the internet.
Why they need to be a square? (didn't read your message that closely:)
If you need something square you might consider tiles. I mean, why
people use fonts these days when almost(?) all computers can show
graphics? Back in old days computers didn't have other than text
mode displays, so it made sense to make the game in text mode..
Plus, when you use graphics tiles you can get rid of the limitations
of ascii.
Elethiomel
Because text symbols are extraoridnarily easy to distinguish from each
other. I, also, when I get around to actually coding my Dream Roguelike
(tm) (rather than just writing design docs of a few game aspects) will
go for blitted characters to a "bitmap canvas" (To Even Purer Purists: I
know this defeats remote playing capabilities. That does not disturb me).
Radomir 'The Sheep' Dopieralski
Elethiomel wrote:
> Krice wrote:
>> Alexin wrote:
> Because text symbols are extraoridnarily easy to distinguish from each
> other.
Especially 'l', '1', 'I', '!' and '|' ;)
--
Radomir `The Sheep' Dopieralski @**@_
(^^) 3 Bee!
. . . ..v.vVvVVvVvv.v.. .
edw...@lore.net
> The problem, however, is that there don't seem to be any free (or
> really, any at all) monospaced square (16x16, 24x24, 32x32; that sort
> of thing) fonts on the internet.
Square fonts are an unusual requirement.
8x9 and 8x16 are easy enough; the "console-data" package in
Debian Linux contains a number of psf fonts in a variety of sizes. I
don't know what graphical tools can display psf, but I'm sure they can
be converted.
Alternatively, a google search for
video terminal screen ttf
should give you a truetype font which replicates 8x16 ASCII. It is free.
You could then stretch it sideways to make it square, though I'm sure it
would look ghastly.
Best bet is probably to find a font you like, monospaced or not, then
write your low-level graphics display such that it places one letter at
a time with fixed spacing. I've done this successfully, with the result
that my display functions don't care which graphics wrapper they use, it
all looks pretty similar. It should be noted that I'm assuming 8x16, not
16x16, however. The graphics system can handle 8x9 or any other font
size, but for text characters, 8x16 or an equivalent ratio looks better
IMO.
> Basically, if you could have a
> text-graphic roguelike made from whatever kind of glyphs you desired,
> what glyphs would you choose?
ASCII or a replica thereof. Others may disagree and call me a fanatical
purist. They wouldn't be entirely wrong, either.
--
--jude hungerford.
John Connors
> So, I figured I'd ask ya'll what you think. Do you know of any such
> square fonts? Since I am using SDL anyways, should I even bother to use
> the standard ascii set of characters, or should I use some other
> character set? Chinese characters are fairly square-shaped, although I
> am not sure if the fonts used on computers are actual squares; do you
> think that might make sense, or would it just be too confusing to
> people unaquainted with the symbols? Basically, if you could have a
> text-graphic roguelike made from whatever kind of glyphs you desired,
> what glyphs would you choose?
>
> Interested in hearing what ya'll think.
>
> -Alexin
>
Why not use a TTF font, and use SDL_ttf to render it onto a square
surface which you can then blit to the video surface? Although square
fonts don't always work so well visually: it's usually better if the
aspect ratio of the font roughly follows the aspect ratios of the screen..
Personally, I can reccomend this font:
http://www.apollosoft.de/ASCII/indexen.htm
John Connors
http://badbyteblues.blogspot.com
Krice
> Because text symbols are extraoridnarily easy to distinguish from each
> other.
Ever had difficulties to distinguish graphical tiles? Human brains
can notice very small differences and you can keep the graphics simple
to avoid any problems in that area. Using graphics you can also
see easier what the object is in the first place. Just think about
how Nethack (for example) displays items. You need to go and check
them every time to find out what they actually are.
konijn_
welcome ;)
I think the following
http://www.renanse.com/furballz/webstart/furballzsrc.zip
Which contains font_rgba.png which seems to contain a square font.
Dont think you can use it for commercial purposes.
Good luck,
T.
R. Alan Monroe
>> Basically, if you could have a
>> text-graphic roguelike made from whatever kind of glyphs you desired,
>> what glyphs would you choose?
>
>ASCII or a replica thereof. Others may disagree and call me a fanatical
>purist. They wouldn't be entirely wrong, either.
Something I haven't seen is a roguelike game that takes advantage of
all the unicode characters built into good old Windows' arial.ttf. It
has a complete set of greek, cyrillic, arabic, hebrew characters in
it. If you have more than 26 creatures in your game, seems ideal.
Windows users can just do Start/Run and enter "charmap" to see them
all.
Alan
Risto Saarelma
This is a pretty big topic, but I think there are good arguments for
using something like text characters.
One idea is that roguelikes are made to be played over and over again.
Commercial games often make a mess here. Civilization III has great
graphics the first time you play, but after a while the graphics are
just annoying as all the pseudo-photorealistic junk makes it harder to
figure out exactly what the Mongols are throwing at your capital this
time.
It's easy to distinguish a few graphical tiles, but what about the Adam
Bolt tileset for Angband? They're very good tiles, but can you really
even begin to tell what kind of critter each tile represents when you
first see it? With text, you get 25 (the alphabet) x 2 (capital letters)
x 15 (EGA colors) = 750 different types of creatures, and each can be
identified at a glance. Of course this implies a rather rigid schema
where there are precisely 50 categories of creature and each has 15
variations.
Still, you could say that this system gets you more immersed in the game
world than tiles. Say you have gotten deeper into the dungeon than ever
before and encounter a cyan W. Now you know that W's are wyrms, which
are tough enemies, and cyan creatures are frost-based, which means that
they are particularly strong and resistant to cold, but not very fast or
bright. So you prepare for a long fight and see if you have any firebolt
quarrels, which should do extra harm to a cold creature. After having
barely survived the encounter with the frost wyrm, you run into a new W.
This one is yellow, which means it's a boss monster of its type. Which
means that fighting it is a very bad idea when even a regular wyrm gave
you lots of trouble. You frantically cast a teleport spell and get away
just before being melted with a spray of emperor wyrm acid.
Now think about the same scenario with graphical tiles. You can color
the tiles, but the player will still have more trouble figuring out the
creature's type and variation. The question is, what benefit does using
tiles give here. The player is interested in what he is facing and where
it is. Both can be presented with symbols such as letters. Tiles make it
harder to tell creatures apart once there are several hundreds of them
(which might be the case with a roguelike), and make it very difficult
to infer anything about a creature you haven't previously encountered.
Then again, the character set is limited, and the characters used for
items aren't very descriptive. So why not use single-color tiles where
you can draw more symbols than the basic letters of the alphabet, but
still get the easily recognizable symbol + color combos instead of
representative tiles which you must memorize individually?
Still another thing is that when you start making the graphics
representative, the players start expecting all sorts of bothersome
things. If the tiles are graphical, why aren't they animated? Real
creatures are constantly moving, they don't stand around like statues.
If the tiles are in the style of Ultima V, why is the perspective
inconsistent? Shouldn't the tiles show the weapons the player and the
enemies are wielding? Shouldn't they show the wounds the player and the
enemies have suffered? And when you got tiles, why don't you show
actions like swinging a sword, reading a scroll, drinking a potion or
falling into a trap door with animation instead of just printing it as a
text message? Isn't it a bit confusing that you tell some things that
happen in the world with text messages and show other things with
animations, even though there isn't any clear-cut difference between the
two?
--
Risto Saarelma
Krice
> x 15 (EGA colors) = 750 different types of creatures, and each can be
> identified at a glance.
You still need to know what brown 'o' is at first time. You either
look/hit it or read from a manual. You can do the same with tiles,
but some creatures can be identified right away. For example orc is
usually an ape-looking critter with flaming eyes. Brown 'o'
can be an orc, but it can be other creature too. In Nethack
big O is an ogre and small o is an orc. How consistent is that?
Besides I have difficulties to remember or even understand
the meaning of color codes of Nethack.
> You can color
> the tiles, but the player will still have more trouble figuring out the
> creature's type and variation.
I don't think so. It's easier to represent the creature's type with
real graphics. It's not limited to color and capital/small letters.
> Still another thing is that when you start making the graphics
> representative, the players start expecting all sorts of bothersome
> things. If the tiles are graphical, why aren't they animated?
I have never expected things like that when playing tile based games.
Radomir 'The Sheep' Dopieralski
Krice wrote:
> Risto Saarelma wrote:
>> x 15 (EGA colors) = 750 different types of creatures, and each can be
>> identified at a glance.
> You still need to know what brown 'o' is at first time. You either
> look/hit it or read from a manual.
You do it only once per creature. It takes O(n) time, where n is the
number of creatures.
With tiles, you do it every time you want to distinguish one tile from
another, and it takes O(n*m) time, where m is the number of games you
play. Well, you can recognize some of them instantly, then you've got
O(n*m-n), which is O(n*m) anyways... ;)
Note: This is a joke and is by no means a proper way to estimate such
things, altrough it could maybe give some idea...
> You can do the same with tiles,
> but some creatures can be identified right away.
No, because it's generally hard to remember the relevant features of
the tiles, the ones you should pay attention to, before you even see the
others, the ones you want to distinguish this particular tile from.
I mean, you already know the shapes of letters and their colors, you know
how to tell 'F' from 'E'. It's not that obvious with tiles, especially
when you don't see them one next another, so that you can compare them and
find and memorize the differences.
> For example orc is
> usually an ape-looking critter with flaming eyes.
Funny, I always thought they are a pig-like creatures with dumb look
in their eyes. Probably too much japanese console RPGs...
> Brown 'o'
> can be an orc, but it can be other creature too.
As can be an "ape-looking critter with flaming eyes" -- a winged ape, for
example.
> In Nethack
> big O is an ogre and small o is an orc. How consistent is that?
I always considered ogres as larger and dumber cousins of orcs. I think
it's perfectly consistent -- both are roughly humanoid, strong, somewhat
dumb and savage creatures, with the exception of ogres being a little
larger -- which is idicated very nicely by the use of upper-case letter.
> Besides I have difficulties to remember or even understand
> the meaning of color codes of Nethack.
You don't have to. It's sufficient to recognize them as different.
Besides, it's not even necessary -- NetHack plays good also on monochrome
terminals.
>> You can color
>> the tiles, but the player will still have more trouble figuring out the
>> creature's type and variation.
> I don't think so. It's easier to represent the creature's type with
> real graphics. It's not limited to color and capital/small letters.
But there's a tendency to use the same 3D model and only change the
clothes, or add a characteristic attribute. This way, you've got tiles
with almost 5 pixels differing them...
--
Radomir `The Sheep' Dopieralski @**@_
(TT) 3 Waaah!
Martin Read
>Risto Saarelma wrote:
>> x 15 (EGA colors) = 750 different types of creatures, and each can be
>> identified at a glance.
>
>You still need to know what brown 'o' is at first time. You either
>look/hit it or read from a manual. You can do the same with tiles,
>but some creatures can be identified right away. For example orc is
>usually an ape-looking critter with flaming eyes.
Ape-looking critters with flaming eyes are not always orcs, easily
windshielded by a competent warrior. They might be ravening ape-demons
from Hell that delight in ripping people's arms off to use as bludgeons
which are a threat even to master swordsmen wielding sacred swords and
clad in adamantite armour.
Now, the chap in black plate armour with glowing red eyes is probably a
"death knight", or other such champion of evil, and the glowing robed
skeleton next to him is probably a lich.
>Brown 'o'
>can be an orc, but it can be other creature too.
I cannot remember the last time I played a roguelike in a fantasy
setting where a brown 'o' was anything other than an orc of some
description.
>In Nethack
>big O is an ogre and small o is an orc. How consistent is that?
Sounds quite consistent to me. Small 'o' is a thing of a kind of thing
that begins with 'o'. Big 'O' is a thing of a kind of *big* thing that
begins with 'o'.
>Besides I have difficulties to remember or even understand
>the meaning of color codes of Nethack.
The only colours you really need to take to heart are the dragon
colour-breath mappings, the unicorn colour-alignment mappings, and the
fact that things which are marked with the colour of princes are usually
quite dangerous things of their kind.
>> You can color
>> the tiles, but the player will still have more trouble figuring out the
>> creature's type and variation.
>
>I don't think so. It's easier to represent the creature's type with
>real graphics. It's not limited to color and capital/small letters.
How do I distinguish, with a small graphical tile, between orc sword
fodder, orc veterans, orc champions, orc sergeants, orc captains, orc
chieftains, and orc warlords. (The orc shaman's relatively easy to
distinguish from other kinds of orc.)
People have noted in rgr.angband time and again that the plethora of
'p' monsters aren't made significantly easier to distinguish by the use
of tile graphics.
--
Martin Read - my opinions are my own. share them if you wish.
\_\/_/ http://www.chiark.greenend.org.uk/~mpread/dungeonbash/
\ / "tempted white eyes blinded by the night hollow like the towers from the
\/ inside laura's a machine she's burning insane" fields of the nephilim
Jeff Lait
Risto Saarelma wrote:
> On 2005-10-08, Krice <pau...@mbnet.fi> wrote:
> > Elethiomel wrote:
> >> Because text symbols are extraoridnarily easy to distinguish from each
> >> other.
> >
> > Ever had difficulties to distinguish graphical tiles? Human brains
> > can notice very small differences and you can keep the graphics simple
> > to avoid any problems in that area. Using graphics you can also
> > see easier what the object is in the first place. Just think about
> > how Nethack (for example) displays items. You need to go and check
> > them every time to find out what they actually are.
>
> This is a pretty big topic, but I think there are good arguments for
> using something like text characters.
>
> One idea is that roguelikes are made to be played over and over again.
> Commercial games often make a mess here. Civilization III has great
> graphics the first time you play, but after a while the graphics are
> just annoying as all the pseudo-photorealistic junk makes it harder to
> figure out exactly what the Mongols are throwing at your capital this
> time.
>
> It's easy to distinguish a few graphical tiles, but what about the Adam
> Bolt tileset for Angband?
The Adam Bolt set is designed to look good, but isn't very functional.
POWDER still defaults to my own "classic" tileset which goes for strong
iconography over good shading.
> They're very good tiles, but can you really
> even begin to tell what kind of critter each tile represents when you
> first see it?
If you can't differentiate creatures in the tileset, it isn't a good
tileset. Recognizing the creatures when you first see them is a moot
point, as no one can recognize the letters when they first see them.
> With text, you get 25 (the alphabet) x 2 (capital letters)
> x 15 (EGA colors) = 750 different types of creatures, and each can be
> identified at a glance. Of course this implies a rather rigid schema
> where there are precisely 50 categories of creature and each has 15
> variations.
With iconic graphic tiles, you have *at least* that number of icons.
You have them by definition as you could always just use text for your
icons!
In POWDER, grid bugs are large purple x's.
> Still, you could say that this system gets you more immersed in the game
> world than tiles. Say you have gotten deeper into the dungeon than ever
> before and encounter a cyan W. Now you know that W's are wyrms, which
> are tough enemies, and cyan creatures are frost-based, which means that
> they are particularly strong and resistant to cold, but not very fast or
> bright.
Which means the person making the monsters engaged in rampant
orthogonalization. Typical of 'bands, but I personally find it cheap
to just automatically create fire/ice/gravity/vortex hounds. There
shouldn't be such blind orthognalizatin that there are such boring
rules governing monster's types. Just because there is an Ice Wyrm
does not mean one should make a Fire Wyrm. And, if you should happen
to make one, it had better not just be the Ice Wyrm except with a
different breath attack and resistance!
> So you prepare for a long fight and see if you have any firebolt
> quarrels, which should do extra harm to a cold creature. After having
> barely survived the encounter with the frost wyrm, you run into a new W.
> This one is yellow, which means it's a boss monster of its type. Which
> means that fighting it is a very bad idea when even a regular wyrm gave
> you lots of trouble. You frantically cast a teleport spell and get away
> just before being melted with a spray of emperor wyrm acid.
>
> Now think about the same scenario with graphical tiles. You can color
> the tiles, but the player will still have more trouble figuring out the
> creature's type and variation. The question is, what benefit does using
> tiles give here. The player is interested in what he is facing and where
> it is. Both can be presented with symbols such as letters. Tiles make it
> harder to tell creatures apart once there are several hundreds of them
> (which might be the case with a roguelike), and make it very difficult
> to infer anything about a creature you haven't previously encountered.
I don't see how you can tell hundreds of characters apart, but seem
unable to tell hundreds of tiles apart. In the worst case, the tiles
could just be the characters.
Inferring from previous encounters is easier with icons as you aren't
limitted to 50 categories and 15 colour variations. POWDER sports a
wide range of kobolds, for example, kobolds, kobold mages, kobold
fighters, and kobold assasins. They all share the same underlying form
factor so (I think) can be recognized as kobolds after you learn what a
normal kobold looks like.
> Then again, the character set is limited, and the characters used for
> items aren't very descriptive. So why not use single-color tiles where
> you can draw more symbols than the basic letters of the alphabet, but
> still get the easily recognizable symbol + color combos instead of
> representative tiles which you must memorize individually?
Why limit yourself to single-colour when you can likely distinctly show
two colours? Why base it off the letters of the alphabet when you
could devise your own iconography which has a closer match?
The best bet part of using iconographic tiles rather than trying to use
characters is that you get a greater variety in creatures. When you
put down an 'o', everyone expects an orc. This biasses your creature
selection to match your pre-existing roguelike experiences. If we want
to step out of the "every roguelike has orcs", one approach is to stop
using "o" all the time.
> Still another thing is that when you start making the graphics
> representative, the players start expecting all sorts of bothersome
> things.
A slippery slope argument. The players will expect all sorts of
bothersome stuff even if you don't have graphics and only use Curses.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Krice
> How do I distinguish, with a small graphical tile, between orc sword
> fodder, orc veterans, orc champions, orc sergeants, orc captains, orc
> chieftains, and orc warlords. (The orc shaman's relatively easy to
> distinguish from other kinds of orc.)
>From clothing, weapons or other gear? How do you distinguish same
in ascii? I can't believe we are having this discussion, because
it should be obvious that graphics are superior compared to ascii.
Radomir 'The Sheep' Dopieralski
Krice wrote:
It should be obvious that ornages are superior to apples.
Or that a screwdriver is a better tool than a hammer.
Depends on what you want to do and how you use them to do it. It is,
for example, possible to screw in a screw using a hammer. It might require
more skills and work, but it's possible. It might be fatal for the screw,
however.
It's possible to represent monsters and items and whatnot distinctively
and in a very comfortable (for the player) way using graphical tiles -- it
just requires much more skills, knowledge and work. And it's easier to
make a mistake...
On the other hand, you can hit a nail with a screwdriver. It won't be as
effective as if you used a hammer, and you can hurt yourself, but you can
do it.
In similar way, you can try to represent the monster's equipment,
three-dimensional dungeon, amazing special effects and beautiful menus
with ascii. It requires some tricks and can be very uncomfortable for the
player, but it certainly can be done.
Now, the only question that remains is what job you actually want to do
and which tools suit it better.
--
Radomir `The Sheep' Dopieralski @**@_
(--) 3 ..zzZZ
Brendan Guild
@g47g2000cwa.googlegroups.com:
ASCII is not much more than a symbol set. It happens to be widely
recognized, the benefit of all standards, so that it can be saved in
text files and posted to usenet. The ascii symbols are innately
meaningful and distinct which makes them easier for the player to
remember. So my roguelike is going to be inspired by ascii in such a
way that any situation in the game will have an ascii representation,
even though it won't necessarily be displayed to the player with
strictly ascii member symbols.
Graphics are good because they allow you to use any display technique
that you desire, but the last thing you should do is try to draw a
picture of every monster. The problem is the number of monster that
have two legs and two arms. You have an infinite symbol set and yet
somehow you manage to force the player to stare at the 5 or 6 pixels
that make up a creature's hat to figure out the monster type. A drawing
of a man is innately meaningful, but that's not helpful if everything
looks like that. Some graphics are obviously inferior compared to
ascii, but the closer to ascii they become, the better.
konijn_
> >I don't think so. It's easier to represent the creature's type with
> >real graphics. It's not limited to color and capital/small letters.
>
> How do I distinguish, with a small graphical tile, between orc sword
> fodder, orc veterans, orc champions, orc sergeants, orc captains, orc
> chieftains, and orc warlords. (The orc shaman's relatively easy to
> distinguish from other kinds of orc.)
Right, I think you should just not use small graphics, and you'll be
fine.
Not to mention that these orcs are distinguished (verb?) in ASCII with
colors,
graphical tiles have colors these days as well.
T.
Radomir 'The Sheep' Dopieralski
konijn_ wrote:
Indeed, however...
For some mysterious reason, all the grphical tiles of
orcs tend to be green...
--
Radomir `The Sheep' Dopieralski @**@_
(Uu) 3 Sigh!
Martin Read
>>From clothing, weapons or other gear? How do you distinguish same
>in ascii? I can't believe we are having this discussion, because
>it should be obvious that graphics are superior compared to ascii.
Perhaps the fact that it *isn't* obvious should tell you something.
Jeff Lait
It would not take a leap of ingenuity to grant one's orcs some
clothing, and then colour said clothing differently depending on
whether it is an orc peon or orc commander.
All of the Kobolds in POWDER are purple, but the Kobold wearing
chainmail (fighter) looks different than the Kobold in the blue robe
(mage).
The arguement against graphical tiles seems to be based on the
misguided belief that graphical tiles should be shaded, dark, and
blurry.
Please look at:
http://www.olywa.net/cook/nhack.htm
for a simple proof that, in terms of appearance, graphical tiles are
inherently superior to ascii tiles.
Radomir 'The Sheep' Dopieralski
Jeff Lait wrote:
> Radomir 'The Sheep' Dopieralski wrote:
>> At 11 Oct 2005 13:18:51 -0700,
>> konijn_ wrote:
>> > Not to mention that these orcs are distinguished (verb?) in ASCII with
>> > colors,
>> > graphical tiles have colors these days as well.
>> Indeed, however...
>> For some mysterious reason, all the grphical tiles of
>> orcs tend to be green...
> It would not take a leap of ingenuity to grant one's orcs some
> clothing, and then colour said clothing differently depending on
> whether it is an orc peon or orc commander.
Sure. You're already reducing the "active" area of the tiles.
It's not unusual to take another leap of ingenuity, and make the clothes
brown/gray and very small - since orcs are savages and it looks cool.
Sure, the orc shaman can hace a brown cape while the orc scout has a brown
leather armor... And the shaman doesn't have that 4-pixel metal cap, so it
should be easily distinguishable.
> All of the Kobolds in POWDER are purple, but the Kobold wearing
> chainmail (fighter) looks different than the Kobold in the blue robe
> (mage).
> The arguement against graphical tiles seems to be based on the
> misguided belief that graphical tiles should be shaded, dark, and
> blurry.
Sure, the alternative is a set of icons that doesn't fit each other and
look together like a mad fruit salad.
With graphics, you need to make trade offs. WIth ascii, most of them has
already been made and widely accepted.
> Please look at:
> http://www.olywa.net/cook/nhack.htm
> for a simple proof that, in terms of appearance, graphical tiles are
> inherently superior to ascii tiles.
Well, the ones that actually depict letters are ok. All the others (the
ones for items, for example) are unreadable.
Note that ascii doesn't necessarily mean using text mode.
Note also, that you can devise your own set of abstract symbols and use it
instead -- but it won't be as widely recognizable. For example, I can't
imagine playing a roguelike with japanese symbols for monsters...
--
Radomir `The Sheep' Dopieralski @**@_
<..> ] 0110110?
Christophe
> At 11 Oct 2005 15:38:29 -0700,
> Jeff Lait wrote:
>
>
>>Radomir 'The Sheep' Dopieralski wrote:
>>
>>>At 11 Oct 2005 13:18:51 -0700,
>>> konijn_ wrote:
>>>
>>>>Not to mention that these orcs are distinguished (verb?) in ASCII with
>>>>colors,
>>>>graphical tiles have colors these days as well.
>>>
>>>Indeed, however...
>>>For some mysterious reason, all the grphical tiles of
>>>orcs tend to be green...
>>
>>It would not take a leap of ingenuity to grant one's orcs some
>>clothing, and then colour said clothing differently depending on
>>whether it is an orc peon or orc commander.
>
> Sure. You're already reducing the "active" area of the tiles.
> It's not unusual to take another leap of ingenuity, and make the clothes
> brown/gray and very small - since orcs are savages and it looks cool.
> Sure, the orc shaman can hace a brown cape while the orc scout has a brown
> leather armor... And the shaman doesn't have that 4-pixel metal cap, so it
> should be easily distinguishable.
Why should people who bash graphics always take example of badly done
tiles to prove that ASCII is better ? Graphical tiles don't need to be
8x8 squares you know.
And if the visual appearance of two monsters is so close as to be hard
to see the difference between them, why should the ASCII symbol allow
you to do that ?
>>All of the Kobolds in POWDER are purple, but the Kobold wearing
>>chainmail (fighter) looks different than the Kobold in the blue robe
>>(mage).
>>The arguement against graphical tiles seems to be based on the
>>misguided belief that graphical tiles should be shaded, dark, and
>>blurry.
>
> Sure, the alternative is a set of icons that doesn't fit each other and
> look together like a mad fruit salad.
> With graphics, you need to make trade offs. WIth ascii, most of them has
> already been made and widely accepted.
>
>
>>Please look at:
>>http://www.olywa.net/cook/nhack.htm
>>for a simple proof that, in terms of appearance, graphical tiles are
>>inherently superior to ascii tiles.
>
> Well, the ones that actually depict letters are ok. All the others (the
> ones for items, for example) are unreadable.
> Note that ascii doesn't necessarily mean using text mode.
> Note also, that you can devise your own set of abstract symbols and use it
> instead -- but it won't be as widely recognizable. For example, I can't
> imagine playing a roguelike with japanese symbols for monsters...
Well, myself I think it could be fun. After all, those symbols were made
for reading too and with some minor training it should be easy enouth to
remember the few symbols used in a roguelike.
Radomir 'The Sheep' Dopieralski
Christophe wrote:
> Radomir 'The Sheep' Dopieralski a écrit :
>> At 11 Oct 2005 15:38:29 -0700,
>> Jeff Lait wrote:
>>>It would not take a leap of ingenuity to grant one's orcs some
>>>clothing, and then colour said clothing differently depending on
>>>whether it is an orc peon or orc commander.
>> Sure. You're already reducing the "active" area of the tiles.
>> It's not unusual to take another leap of ingenuity, and make the clothes
>> brown/gray and very small - since orcs are savages and it looks cool.
>> Sure, the orc shaman can hace a brown cape while the orc scout has a brown
>> leather armor... And the shaman doesn't have that 4-pixel metal cap, so it
>> should be easily distinguishable.
> Why should people who bash graphics always take example of badly done
> tiles to prove that ASCII is better ? Graphical tiles don't need to be
> 8x8 squares you know.
Because that's what bad about the graphics -- it has to be done goodly to
be usable. I'm not saying it's not possible to make good tiles -- ones
that are both easily recognizable and nice. And fit the theme of the game.
But it's hard, requires lots of work, tweaking and testing. Not to mention
skills and time. Artistic and "usability expert" skills.
With ascii you get pretty decent results with minimal effort. Sure, you
can do better with graphics. But most of the time you do worse.
You can write text-processing programs in Prolog. You can write tower of
hanoi-solving program in Perl. Both of them are Turning-complete, so
theoretically it's possible to write anything in them. But there's
a question of work inwolved.
> And if the visual appearance of two monsters is so close as to be hard
> to see the difference between them, why should the ASCII symbol allow
> you to do that ?
Because it's not a "spot the difference" game, but a slow-paced,
turn-based game. You don't want to force the player to carefully examine
each pixel (there was an RPG game that marked secret passges with a few
different pixels. Very annoying). Plus, you don't want some players having
an advantge because of lower resolution or different brightness setting of
their displays.
Either you make it differ at the first glance, or not different at all.
>> Note also, that you can devise your own set of abstract symbols and use it
>> instead -- but it won't be as widely recognizable. For example, I can't
>> imagine playing a roguelike with japanese symbols for monsters...
> Well, myself I think it could be fun. After all, those symbols were made
> for reading too and with some minor training it should be easy enouth to
> remember the few symbols used in a roguelike.
That;s the key. You don't want to *require* training for each and every
new game, do you?
--
Radomir `The Sheep' Dopieralski @**@_
(..) 3 Bee!
Martin Read
>Note also, that you can devise your own set of abstract symbols and use it
>instead -- but it won't be as widely recognizable. For example, I can't
>imagine playing a roguelike with japanese symbols for monsters...
I could imagine myself doing that. It would be a bit of a headfuck for
a while, but I could do that.
Christophe
> At Wed, 12 Oct 2005 10:02:53 +0200,
> Christophe wrote:
>
>
>>Radomir 'The Sheep' Dopieralski a écrit :
>>
>>>At 11 Oct 2005 15:38:29 -0700,
>>> Jeff Lait wrote:
>>>
>>>>It would not take a leap of ingenuity to grant one's orcs some
>>>>clothing, and then colour said clothing differently depending on
>>>>whether it is an orc peon or orc commander.
>>>
>>>Sure. You're already reducing the "active" area of the tiles.
>>>It's not unusual to take another leap of ingenuity, and make the clothes
>>>brown/gray and very small - since orcs are savages and it looks cool.
>>>Sure, the orc shaman can hace a brown cape while the orc scout has a brown
>>>leather armor... And the shaman doesn't have that 4-pixel metal cap, so it
>>>should be easily distinguishable.
>>
>>Why should people who bash graphics always take example of badly done
>>tiles to prove that ASCII is better ? Graphical tiles don't need to be
>>8x8 squares you know.
>
> Because that's what bad about the graphics -- it has to be done goodly to
> be usable. I'm not saying it's not possible to make good tiles -- ones
> that are both easily recognizable and nice. And fit the theme of the game.
> But it's hard, requires lots of work, tweaking and testing. Not to mention
> skills and time. Artistic and "usability expert" skills.
You don't need usability expert skills to notice that 2 monsters look
too much like each other.
> With ascii you get pretty decent results with minimal effort. Sure, you
> can do better with graphics. But most of the time you do worse.
>
> You can write text-processing programs in Prolog. You can write tower of
> hanoi-solving program in Perl. Both of them are Turning-complete, so
> theoretically it's possible to write anything in them. But there's
> a question of work inwolved.
As a matter of fact, hanoi-solving programs are easy to write in any
language that allows recursion. The first such example I've seen was
writen in matlab by my math teacher. I bet you can do it in 4-5 simple
lines of Python code.
>>And if the visual appearance of two monsters is so close as to be hard
>>to see the difference between them, why should the ASCII symbol allow
>>you to do that ?
>
>
> Because it's not a "spot the difference" game, but a slow-paced,
> turn-based game. You don't want to force the player to carefully examine
> each pixel
Of course, that's why an orc shaman is nearly naked with just a
loincloth and a big staff with a skull on top and an orc warrior is in
chain mail with his big sword or hammer ( selected at random ).
Protection against bashing weapons means you should kill the sword
weilding orc first.
> (there was an RPG game that marked secret passges with a few
> different pixels. Very annoying).
It isn't worse than in Angband where the secret pasages are completly
invisible.
> Plus, you don't want some players having
> an advantge because of lower resolution or different brightness setting of
> their displays.
In the roguelike where you can change the font and resize the display
window, some players are already at an "advantage" because they can see
more of the dungeon at once.
> Either you make it differ at the first glance, or not different at all.
And then you can do that with graphics too. If the one creating the
tiles insist cannot produce sufficiently different looking monsters,
then it's time to find somebody else.
>>>Note also, that you can devise your own set of abstract symbols and use it
>>>instead -- but it won't be as widely recognizable. For example, I can't
>>>imagine playing a roguelike with japanese symbols for monsters...
>>
>>Well, myself I think it could be fun. After all, those symbols were made
>>for reading too and with some minor training it should be easy enouth to
>>remember the few symbols used in a roguelike.
>
> That;s the key. You don't want to *require* training for each and every
> new game, do you?
Well, yes I do. Each new game requires training you see. And training to
learn a new set of symbols is the easy part provided the designer didn't
go out of his way to make the symbols hard to read. Of course
familiarity with the symbol set makes it easier to recognise at first,
but you still need time to learn what monster is that 'c' or that 'X'. I
say that part is the hardest, not the visual training it takes to read
'c' or 'X' on the screen.
One example of the advantage of graphics against ASCII is Tome and
ZAngband. In those games, each weapon type has it's own tile to
represent it. It means that you can at a glance differentiate between a
dagger and a longsword. It also means that if you face one of the
infamous DeathSword mimic ( one of the worse cause of insta death at low
to mid level ), since it is a longsword mimic you don't need to be
cautious when you see a dagger on the ground. In ASCII, once you reach
the point were you can find that monster you have to stay clear of all
swords on the ground and probe them at a range.
Radomir 'The Sheep' Dopieralski
Christophe wrote:
> Radomir 'The Sheep' Dopieralski a écrit :
>> At Wed, 12 Oct 2005 10:02:53 +0200,
>> Christophe wrote:
>> But it's hard, requires lots of work, tweaking and testing. Not to mention
>> skills and time. Artistic and "usability expert" skills.
> You don't need usability expert skills to notice that 2 monsters look
> too much like each other.
Sometimes you need one to tell you that it's important at all.
Lots of such small and 'obvious' things make up the 'usability' field.
>> Either you make it differ at the first glance, or not different at all.
> And then you can do that with graphics too. If the one creating the
> tiles insist cannot produce sufficiently different looking monsters,
> then it's time to find somebody else.
Sure, because you've got so many of the to choose from.
They are ready to even kill each other to make graphics for your game.
They queue up under your door every morning to ask for permission to
make at least one small icon for you.
--
Radomir `The Sheep' Dopieralski @**@_
(TT) 3 Waaah!
David Damerell
>in ascii? I can't believe we are having this discussion, because
>it should be obvious that graphics are superior compared to ascii.
Proof by blatant assertion, much?
--
David Damerell <dame...@chiark.greenend.org.uk> Distortion Field!
Today is First Oneiros, October.
David Damerell
>Please look at:
>http://www.olywa.net/cook/nhack.htm
>for a simple proof that, in terms of appearance, graphical tiles are
>inherently superior to ascii tiles.
Ummm. While I think Geoduck's set is terribly, terribly ingenious, it does
tend to be a bit too angry-fruit-salad in actual play...
Jeff Lait
> sheep1 % sheep.prv.pl wrote:
> >Note also, that you can devise your own set of abstract symbols and use it
> >instead -- but it won't be as widely recognizable. For example, I can't
> >imagine playing a roguelike with japanese symbols for monsters...
>
> I could imagine myself doing that. It would be a bit of a headfuck for
> a while, but I could do that.
I know I'd keep being killed by the katakana "-n" beast because I'd
mistake it for the peaceful "so" beast that differs by only a pixel or
two.
konijn_
>instead -- but it won't be as widely recognizable
Yes ;)
I am still playing with the JMonkeyEngine, in my demo the player is a
yellow sphere.
I can just imagine some flaming post stating that yellow sphere's are
obviously better than a textured trimesh because a crappy textured
trimesh is hard
to distinguish ;)
T.
R. Dan Henry
wrote:
>Why should people who bash graphics always take example of badly done
>tiles to prove that ASCII is better ? Graphical tiles don't need to be
>8x8 squares you know.
True, you can make a different trade-off and have large, beautiful,
easily-interpreted 128x128 tiles and a much smaller visible area. This
trade-off may be tolerable if you are making a particularly cramped
dungeon crawl, but is going the wrong way for those roguelikes that have
gone outside.
--
R. Dan Henry = danh...@inreach.com
R. Dan Henry
sheep.prv.pl> wrote:
>Note also, that you can devise your own set of abstract symbols and use it
>instead -- but it won't be as widely recognizable. For example, I can't
>imagine playing a roguelike with japanese symbols for monsters...
Actually, when it would be suitable for the world in question, I
wouldn't mind seeing a different character set -- Chinese characters for
a Wuxia game, hieroglyphs for an Egyptian themed game, Greek alphabet
for GREEKIE, Tengwar for Middle-Earth.
Wolfgang Groiss
>>> konijn_ wrote:
... chiming in on a discussion that smells a bit like "vi vs. emacs",
but i've got this little idea coming up reading your musings:
ASCII is way more abstract than tiles. People who like tiles enjoy the
fact that an orc looks like an orc. People who like ASCII (apart from
technical reasons) enjoy the fact that they don't have to look at single
pixels to distill the important facts (it's an orc!) from the symbolic
representation.
Now what i'm thinking about is this: Do you notice that in chess
(especially in printed form), a king looks nothing like the robed guys
you see on old oil paintings? It is only a symbol, albeit a very
specifically crafted one. Same for pretty much every other chess figure.
The idea behind this is to make the figures easily distinguishable.
Remove everything that's unneeded for this purpose, but no more.
Hence, my idea was this: it should be possible to come up with a tile
system that's somewhere in between ASCII and the usual colorful
pseudo-realistic tilesets.
The character/monster symbols might actually end up looking a bit like
chess symbols, and maybe there are some composites, too, so - for
example - it is instantly visible wether a symbol represents a horse, a
saddled horse, a saddled horse with the player on it, a saddled horse
with an orc on it, etc.
Just an idea i had, to throw a bit more fuel into the fire :)
wg
--
One Word to write them all, one Access to find them, one Excel to count
them all, and thus to Windows bind them.
Erik Piper
David Damerell wrote:
> Quoting Jeff Lait <torespon...@hotmail.com>:
> >Please look at:
> >http://www.olywa.net/cook/nhack.htm
> >for a simple proof that, in terms of appearance, graphical tiles are
> >inherently superior to ascii tiles.
>
> Ummm. While I think Geoduck's set is terribly, terribly ingenious, it does
> tend to be a bit too angry-fruit-salad in actual play...
...
...
...I give up. What *does* "angry-fruit-salad" mean??
e.
Krice
> People who like ASCII (apart from
> technical reasons) enjoy the fact that they don't have to look at single
> pixels to distill the important facts (it's an orc!) from the symbolic
> representation.
You don't have to look at single pixels to see what the tile is.
Tiles graphics are also more or less symbolic, but they don't
usually need to be interpreted like ascii (or other) symbols.
When you see something that looks like orc, it probably is an orc.
When you see 'o' first time, you can't be sure what it is.
I can understand that some people like ascii and prefer it over
tiles, but they seem to go deaf when someone tries to explain
why graphics are better.
Radomir 'The Sheep' Dopieralski
Have you ever seen when some young programmer, writing a text-mode
program, takes it for his point of honour to use each and every
foreground/background color combination on the screen?
What comes out can be described as an 'angry fruit salad', because
it has many very bright colors intermixed with each other, as if
it was a mix pices of fresh fruits.
This kind of "design" is usually very tiring for the user and far
form, uhm, "visually appealing".
--
Radomir `The Sheep' Dopieralski @**@_
(@a) 3 Be?
Radomir 'The Sheep' Dopieralski
Wolfgang Groiss wrote:
> Radomir 'The Sheep' Dopieralski wrote:
>> Jeff Lait wrote:
>>>> konijn_ wrote:
> The character/monster symbols might actually end up looking a bit like
> chess symbols, and maybe there are some composites, too, so - for
> example - it is instantly visible wether a symbol represents a horse, a
> saddled horse, a saddled horse with the player on it, a saddled horse
> with an orc on it, etc.
Yes, I think that would be the perfect solution in terms of the game play
(but you still have to learn the pieces). Still the tiles can have much
better effects when it comes to immersion... ;)
--
Radomir `The Sheep' Dopieralski @**@_
(==) 3 Yawn?
Radomir 'The Sheep' Dopieralski
Krice wrote:
> Wolfgang Groiss wrote:
> I can understand that some people like ascii and prefer it over
> tiles, but they seem to go deaf when someone tries to explain
> why graphics are better.
apples and oranges
--
Radomir `The Sheep' Dopieralski @**@_
(..) 3 Bee!
Martin Read
>Wolfgang Groiss wrote:
>> People who like ASCII (apart from
>> technical reasons) enjoy the fact that they don't have to look at single
>> pixels to distill the important facts (it's an orc!) from the symbolic
>> representation.
>
>You don't have to look at single pixels to see what the tile is.
>Tiles graphics are also more or less symbolic, but they don't
>usually need to be interpreted like ascii (or other) symbols.
>When you see something that looks like orc, it probably is an orc.
What does an orc look like, then? New Line Cinema's rendition of
Tolkien's orcs? The pig-snouted barbarians of Dungeons and Dragons?
The luridly green hunchbacks with enormous teeth that feature in Games
Workshop's games? The flaming-eyed ape-men someone suggested earlier
in this thread, which I would in fact expect to be some kind of ravening
ape-demon, not an orc? Something else?
>When you see 'o' first time, you can't be sure what it is.
When I see a particular kind of semi-bestial humanoid figure for the
first time, I can't be sure what *that* is, either, beyond "semi-bestial
humanoid". I don't know whether it's an orc, a troll, an ogre, or some
kind of demon-thing from a nameless corner of Hell.
>I can understand that some people like ascii and prefer it over
>tiles, but they seem to go deaf when someone tries to explain
>why graphics are better.
That's because graphics are not inherently better.
Krice
> What does an orc look like, then? New Line Cinema's rendition of
> Tolkien's orcs? The pig-snouted barbarians of Dungeons and Dragons?
Doesn't matter that much, really. It's still easier to distinguish
different monster types from each other when using graphics, and
easier to guess what the monster is when you see one.
> I don't know whether it's an orc, a troll, an ogre, or some
> kind of demon-thing from a nameless corner of Hell.
Well, you know a lot less when you look at ascii symbol.
> That's because graphics are not inherently better.
Makes me wonder why they invented graphics adapters at all, if
ascii is better:)
Risto Saarelma
>> With text, you get 25 (the alphabet) x 2 (capital letters)
>> x 15 (EGA colors) = 750 different types of creatures, and each can be
>> identified at a glance. Of course this implies a rather rigid schema
>
> With iconic graphic tiles, you have *at least* that number of icons.
> You have them by definition as you could always just use text for your
> icons!
That's right, and actually that's a good proof for why a graphical
display is inherently superior to a text-based one.
My main idea was that with characters, you can have very small tiles
that can still show around 50 easily distinguishable shapes. So
something like letters or other similar abstract symbols might be a good
choice for representing creature tiles.
[Reasoning about creature color]
> Which means the person making the monsters engaged in rampant
> orthogonalization. Typical of 'bands, but I personally find it cheap
> to just automatically create fire/ice/gravity/vortex hounds. There
> shouldn't be such blind orthognalizatin that there are such boring
> rules governing monster's types. Just because there is an Ice Wyrm
Right, that wasn't a very good example if you aren't doing something a
lot more abstract than a fantasy game. The bestiary feels a lot less
artificial when you can't expect standard elemental variations of every
critter. Of course you could build the reason why all creatures come
with elemental variations into the cosmology of your setting.
Color can be used in a setting-dependant way. For example, having purple
creatures always being chaos monsters works well in ADOM, but if your
setting doesn't feature similar chaos and corruption, it's not very
useful.
I think that having a special color for exceptionally strong boss
monsters is a more generally useful idea though.
> Inferring from previous encounters is easier with icons as you aren't
> limitted to 50 categories and 15 colour variations. POWDER sports a
> wide range of kobolds, for example, kobolds, kobold mages, kobold
> fighters, and kobold assasins. They all share the same underlying form
> factor so (I think) can be recognized as kobolds after you learn what a
> normal kobold looks like.
Yes, this would work. If you can make a basic kobold shape that's
recognizable in the same way as 'k' is recognizable, you can give more
information by adding nuances like that.
Of course with this approach 16x16 is pretty close to the lower limit of
useful tile size. With letters, you could go below 8x8 and still have
perfectly legible tiles. This is mostly of interest if you're working
with a very small display like that of a cell phone.
> Why limit yourself to single-colour when you can likely distinctly show
> two colours? Why base it off the letters of the alphabet when you
> could devise your own iconography which has a closer match?
>
> The best bet part of using iconographic tiles rather than trying to use
> characters is that you get a greater variety in creatures. When you
> put down an 'o', everyone expects an orc. This biasses your creature
> selection to match your pre-existing roguelike experiences. If we want
> to step out of the "every roguelike has orcs", one approach is to stop
> using "o" all the time.
Making a good iconography is a lot of work. The basic approach of making
the tiles look like the creatures works, but the tiles aren't as easily
scalable as letters (drawing them with vector graphics would solve
this). And there's the problem that the tiles of 'g', 'k', 'o' and 'h'
are all pretty much short and human-shaped things. You can distinguish
between them pretty easily, but the shapes still aren't as distinct as
the letters. If you've got a small screen or a huge amount of tiles on a
big screen, distinguishing between the tiles with minimum effort becomes
important.
So a really good solution would be to make very symbolic tiles that are
as scalable and easy to distinguish as letters, but have unique designs
that are better suited to represent various types of game objects. An
interesting challenge.
>> Still another thing is that when you start making the graphics
>> representative, the players start expecting all sorts of bothersome
>> things.
>
> A slippery slope argument. The players will expect all sorts of
> bothersome stuff even if you don't have graphics and only use Curses.
I think the problem is that when the graphics switch to representative
tiles, I start thinking the display as an actual window into a virtual
world instead of a symbolic tactical map, and start thinking about all
sorts of useless things about how object perspectives are wrong and how
the creatures aren't moving (an Ultima V style single animation cycle
would make me happy enough though, it draws the eye to the enemies that
are awake, which most of the time are the most important thing on the
map).
This isn't a problem when I'm playing a game, then I just grumble a bit
and get used to the graphics. But when I'm trying to make something, I
always end up thinking about irrelevant things about object and terrain
display instead of thinking about actual game mechanics and content. Of
course it could be just that graphics programming is easy and good game
design and content development is a lot harder.
--
Risto Saarelma
Ray Dillinger
> Martin Read wrote:
> <clip - another iteration of graphics vs. ascii>
Guys, stop it. This is one of the ancient and unwinnable
arguments on RGRD, and arguing it using your own respective
assumptions that you are right as evidence that you are right,
is a sure ticket to flamewar territory.
You both know better than to try to direct other people in
this matter; make your own games the way you want 'em, because
the essence of roguelike is that the coder makes the game that
he wants to play himself.
Bear
Simon Richard Clarkstone
> ASCII is way more abstract than tiles. People who like tiles enjoy the
> fact that an orc looks like an orc. People who like ASCII (apart from
> technical reasons) enjoy the fact that they don't have to look at single
> pixels to distill the important facts (it's an orc!) from the symbolic
> representation.
>
> Now what i'm thinking about is this: Do you notice that in chess
> (especially in printed form), a king looks nothing like the robed guys
> you see on old oil paintings? It is only a symbol, albeit a very
> specifically crafted one. Same for pretty much every other chess figure.
> The idea behind this is to make the figures easily distinguishable.
>
> Remove everything that's unneeded for this purpose, but no more.
>
> Hence, my idea was this: it should be possible to come up with a tile
> system that's somewhere in between ASCII and the usual colorful
> pseudo-realistic tilesets.
I was thinking a bit along the same lines, but:
* This is little better than graphics for people on text links, e.g.
traditional nethack telnet servers. (Except that you could use Unicode
symbols, transmitted as UTF-8, as your abstract symbols.)
* You would now have to learn to recognise the symbols (like graphics)
*and* learn their meanings (like ASCII), and there are more than the 6
types in a chess set. (Not actually *that* hard, especially for the
"use-vi-keys-or-don't-play" crowd. ;-> )
It may end up looking like Egyptian hieroglyphs, which could be thematic.
(/me mails Chris Morris, who he has met IRL, to suggest a Unicode port
of ChessRogue.)
--
Simon Richard Clarkstone: s.r.cl?rkst?n?@durham.ac.uk/s?m?n.cl?rkst?n?@
hotmail.com ### "I have a spelling chequer / it came with my PC /
it plainly marks for my revue / Mistake's I cannot sea" ...
by: John Brophy (at: http://www.cfwf.ca/farmj/fjjun96/)
R. Dan Henry
<newsl...@littlelui.de> wrote:
>People who like tiles enjoy the
>fact that an orc looks like an orc.
Except that it more often doesn't.
R. Dan Henry
>You don't have to look at single pixels to see what the tile is.
>Tiles graphics are also more or less symbolic, but they don't
>usually need to be interpreted like ascii (or other) symbols.
Which is utter nonsense. All raw data needs to be interpreted in order
to become meaningful information. And graphics are very, very good if
they are as easy to interpret as ASCII.
>When you see something that looks like orc, it probably is an orc.
Except that usually, the graphics are at best, ambiguous. Is that
supposed to be an orc? A goblin? An ogre? An ugly man?
>When you see 'o' first time, you can't be sure what it is.
Which is just as true of graphics, except that one creature of the same
class will be represented by the same letter in ASCII, but may look very
different in a graphic tile set.
>I can understand that some people like ascii and prefer it over
>tiles, but they seem to go deaf when someone tries to explain
>why graphics are better.
Maybe that's because those "explanations" tend to be full of bogus
claims like graphics not requiring interpretation.
wild.h...@gmail.com
R. Dan Henry wrote:
> On 13 Oct 2005 03:44:10 -0700, "Krice" <pau...@mbnet.fi> wrote:
>
> >You don't have to look at single pixels to see what the tile is.
> >Tiles graphics are also more or less symbolic, but they don't
> >usually need to be interpreted like ascii (or other) symbols.
>
> Which is utter nonsense. All raw data needs to be interpreted in order
> to become meaningful information. And graphics are very, very good if
> they are as easy to interpret as ASCII.
>
> >When you see something that looks like orc, it probably is an orc.
>
> Except that usually, the graphics are at best, ambiguous. Is that
> supposed to be an orc? A goblin? An ogre? An ugly man?
>
> >When you see 'o' first time, you can't be sure what it is.
>
> Which is just as true of graphics, except that one creature of the same
> class will be represented by the same letter in ASCII, but may look very
> different in a graphic tile set.
For some classes of games, "interpretation" is relatively easy, since
the number of symbols to be interpreted is small. For a fairly
complicated game, with a large number of monsters or other elements
that require symbols for interpretation, low-resolution graphics do not
provide much benefit over ASCII fonts.
Considering the differences in tile-based graphics and ASCII for most
amateur games, I think both are relatively the same, and in some
poor-planning instances, graphics can actually be worse than ASCII in a
readability sense. If one does choose to utilize graphics, color
palette differences make a bigger difference than small shape
differences for small graphics.
Christophe
> R. Dan Henry wrote:
>
>>On 13 Oct 2005 03:44:10 -0700, "Krice" <pau...@mbnet.fi> wrote:
>>
>>
>>>You don't have to look at single pixels to see what the tile is.
>>>Tiles graphics are also more or less symbolic, but they don't
>>>usually need to be interpreted like ascii (or other) symbols.
>>
>>Which is utter nonsense. All raw data needs to be interpreted in order
>>to become meaningful information. And graphics are very, very good if
>>they are as easy to interpret as ASCII.
>>
>>
>>>When you see something that looks like orc, it probably is an orc.
>>
>>Except that usually, the graphics are at best, ambiguous. Is that
>>supposed to be an orc? A goblin? An ogre? An ugly man?
>>
>>
>>>When you see 'o' first time, you can't be sure what it is.
>>
>>Which is just as true of graphics, except that one creature of the same
>>class will be represented by the same letter in ASCII, but may look very
>>different in a graphic tile set.
>
>
>
> For some classes of games, "interpretation" is relatively easy, since
> the number of symbols to be interpreted is small. For a fairly
> complicated game, with a large number of monsters or other elements
> that require symbols for interpretation, low-resolution graphics do not
> provide much benefit over ASCII fonts.
Wrong ! In a game with a large number of symbols for interpretaion,
ASCII doesn't cut anymore it because you are limited by the number of
symbols and colors. Once you've filled up the 15 different colors for
'o' what can you do ? Reuse colors ? Have fewer different orcs ?
Creative use of blinking between different colors ?
> Considering the differences in tile-based graphics and ASCII for most
> amateur games, I think both are relatively the same, and in some
> poor-planning instances, graphics can actually be worse than ASCII in a
> readability sense. If one does choose to utilize graphics, color
> palette differences make a bigger difference than small shape
> differences for small graphics.
Graphics allows you a few tricks that are impossible or very hard to do
in ASCII :
- Ability to see the ground tile under the monster. In ASCII you are
limited to using a background color for the terrain but most of the time
it is a bad idea to do that.
- Careful shape and multiple color placement allows many more different
monsters to be represented in an easy to interpret way.
- Graphics allow many different levels of modifications for the monster
representation. You can have small differences ( different weapons,
minor effect on gameplay ) and bigger differences ( cave orc is much
more dangerous than a hill orc )
- Can be zoomed in and out. For example for a minimap.
- Visual representation of the state of the monster : important magic
effects, status like poison, pet/familiar/friendly summon status etc ...
- More liberty for background tiles. Allows you to use many different
ground and wall tiles for some gameplay features. Here is a big win for
graphics I think. ASCII is just too limited when you want more than the
simple wall, ground, door, water dungeon features. Lots of possibilities
here like displaying monster footsteps, drawing canals on the ground for
electricity to pass ( see GoldenSun for what I mean ;) )
- 3D iso effect allows you to add height considerations to your
gameplay. If someone finds me a way to do that in ASCII I'm really
interested.
And many more. Btw, since graphics are abviously superior than ASCII for
dungeon features ( ;) ) did someone consider a mixed usage roguelike
with tiles for all except for items and monsters ?
Chris Morris
> (/me mails Chris Morris, who he has met IRL, to suggest a Unicode port
> of ChessRogue.)
What, you mean the Unicode ChessRogue that I wrote months ago? ;)
http://compsoc.dur.ac.uk/~cim/chessrogue2u.tar.gz
It works, sort of, if the terminal co-operates (and I couldn't get a
windows version working at all), but trying it mainly convinced me
that Unicode in roguelikes isn't worth the hassle, and I should stick
to plain ASCII.
--
Chris
Timothy Pruett
ASCII is just a standard code used to represent various letter, symbols,
and escape sequences. The ASCII standard has nothing to do with the
actual representation of these letters and symbols. That is left up to
the app developer. You seem to be confusing curses with ASCII. Curses
is one particular (and popular) way of displaying ASCII characters on
terminals. And just because curses is limited to 15 colors does not
mean all RL developer's face the same limitation with their own ASCII
display. Jeff Lait's "You Only Live Once" game features bitmapped,
spiffy looking characters, and he even allows you to swap in characters
of your own design (granted, it isn't technically ASCII, since it's
missing a large number of characters, and includes a few original ones,
but it proves the point).
My (or anybody's) ASCII display in a roguelike can feature as many
colors as I can think of. Hell, I could slap a texture on the symbols.
I could make them 3D textured characters, and it would still be ASCII.
So, your initial statement is only a half-truth. Yes, you are limited
by the number of symbols, but not colors. I think you'd be surprised
how incredibly limited 8x8 tiles are, by the way, when it comes to the
number of symbols you can represent. You can only make so many visually
appealing/easy to interpret symbols in such a small space.
>> Considering the differences in tile-based graphics and ASCII for most
>> amateur games, I think both are relatively the same, and in some
>> poor-planning instances, graphics can actually be worse than ASCII in a
>> readability sense. If one does choose to utilize graphics, color
>> palette differences make a bigger difference than small shape
>> differences for small graphics.
>
>
> Graphics allows you a few tricks that are impossible or very hard to do
> in ASCII :
>
> - Ability to see the ground tile under the monster. In ASCII you are
> limited to using a background color for the terrain but most of the time
> it is a bad idea to do that.
Yes, this is an obvious advantage of graphics. Granted, in many, many
cases, that isn't really that useful of an ability. Typically, the tile
the monster is standing on will be of the same type as the surrounding
tiles. Also, you usually already know what type of tile it is in the
first place. And lastly, how often do you really need to know the type
of ground tile a monster is stepping on?
> - Careful shape and multiple color placement allows many more different
> monsters to be represented in an easy to interpret way.
That's a matter of opinion.
> - Graphics allow many different levels of modifications for the monster
> representation. You can have small differences ( different weapons,
> minor effect on gameplay ) and bigger differences ( cave orc is much
> more dangerous than a hill orc )
And yet, somehow, I can do the same thing in ASCII. Brown 'o' (cave
orc) is more dangerous than the green 'o' (hill orc). Tada! And for
the weapons, I can't visually represent it, but I can certainly allow my
creatures to carry different weapons.
> - Can be zoomed in and out. For example for a minimap.
ASCII can do the same. For example, JADE allows zooming.
> - Visual representation of the state of the monster : important magic
> effects, status like poison, pet/familiar/friendly summon status etc ...
How many magical effects can you really represent on a tiny little tile?
Not many. And how would you go about representing summon status
visually, in such a small area?
> - More liberty for background tiles. Allows you to use many different
> ground and wall tiles for some gameplay features. Here is a big win for
> graphics I think. ASCII is just too limited when you want more than the
> simple wall, ground, door, water dungeon features. Lots of possibilities
> here like displaying monster footsteps, drawing canals on the ground for
> electricity to pass ( see GoldenSun for what I mean ;) )
Yes, this is a big advantage. However, you still need much greater
resources to actually make use of this ability. For example, a talented
artist is necessary (and yes, they must be talented, because nothing can
ruin the mood quicker than ugly graphics).
> - 3D iso effect allows you to add height considerations to your
> gameplay. If someone finds me a way to do that in ASCII I'm really
> interested.
Sure, this is certainly doable. Once again, you're confusing one
particular implementation with the standard.
> And many more. Btw, since graphics are abviously superior than ASCII for
> dungeon features ( ;) ) did someone consider a mixed usage roguelike
> with tiles for all except for items and monsters ?
Didn't one of those NetHack tilesets *sorta* do that?
Radomir 'The Sheep' Dopieralski
Christophe wrote:
> wild.h...@gmail.com a écrit :
>> R. Dan Henry wrote:
>>>On 13 Oct 2005 03:44:10 -0700, "Krice" <pau...@mbnet.fi> wrote:
> Graphics allows you a few tricks that are impossible or very hard to do
> in ASCII :
Yes. You can do much more with graphics -- in particular, you can do
ASCII. It's obvious.
But this comes at a cost. ASCII is pretty well-crafted symbol set
(yes, it could be better, but it's not bad). There are very few really
bad ways to use it, and those can be usually recognized instantly.
With graphics you've got more freedom. Freedom means responsibility.
It's sufficient to make only a few minor mistakes to make your game
very uncomfortable, and the reason behinf the uncomfortability is not
apparent. It takes a few more errors to make tha game totally unplayable.
ASCII is a nice scheme you can use. To make this, ehm, discussion a little
more constructive, what other schemes are there for the graphics
developers? I mean something a little more strict than just "isometry"
or somethng... ;)
--
Radomir `The Sheep' Dopieralski @**@_
(TT) 3 Waaah!
ga...@dsdata.it
>
> For some classes of games, "interpretation" is relatively easy, since
> the number of symbols to be interpreted is small. For a fairly
> complicated game, with a large number of monsters or other elements
> that require symbols for interpretation, low-resolution graphics do not
> provide much benefit over ASCII fonts.
Most tabletop wargames have tens or hundreds of different unit
counters, and they have successfully implemented easily interpreted and
low resolution graphics for them thanks to a common structured
approach.
In the middle, a stylized icon of the basic unit type: there are only a
few in a given game and anybody can recognize them unambiguously and
often in several variants (e.g. in whatever style light tanks and heavy
tanks are drawn, the latter are expected to be larger). Icons are
usually very small and simple: they need to resemble the real object
only enough to be identified correctly.
In the corners and possibly along the sides, numbers; it is assumed
that the player knows the rules, so their meaning is obvious.
In the upper center, abbreviated text and small icons giving the name
and/or affiliation (3rd regiment, platoon B, Old Guard, etc.); note
that even if the player cannot recognize such icons, it is unambiguous
that they are different, which units are larger is obvious from the
numbers, and often such icons form sorted families (a "rectangle with
two dots" is obviously part of a "rectangle with three dots").
And everywhere, colour with already known or easily recognized meanings
(e.g. traditional uniform colours of different countries are used as
background to distinguish factions at first sight) or based on common
conventions (if there is a border or a differently coloured number, the
unit is somewhat special; if something is in gold, it is either a
commander or an elite unit).
Compared to tabletop wargames, RL games are somewhat disadvantaged.
1) Only a minority of icons, no matter how well drawn, can be
recognizable; the others can only hope to be easily distinguished,
because they represent imaginary stuff.
A sword needs only to be longer than a dagger, shorter than a
two-handed sword and more elongated than an axe, but most creatures can
only look like a peculiar species of humanoid, quadruped, blob, etc and
not like the nonexistent real thing; they are therefore a game-specific
language that needs to be learned.
Coherent graphics can contribute to the player's enjoyment with a sense
of immersion and consistency, but learning that orcs are denoted by 'o'
and ogres are denoted by 'O' is as arbitrary as learning that in this
game orcs are depicted as little green armoured humanoids and ogres
seem tall brutes dressed in furs.
(Except that if a player assumes, for example, that orcs are bestial
and ogres are cunning and civilized he cannot be offended by 'o' and
'O' while the graphics would look false and unpleasant.)
2) There are many more basic objects (creatures, items, fixtures) and
therefore making different icons is harder; a lot of detail is needed.
In some cases, as others have suggested, icons can be combined in order
to make different representations from distinguished small sets of
components: for example a plain humanoid figure and his weapon on the
side, or more complex systems of interchangeable faces (green orcs,
pink and brown humans, white zombies), hair (a few styles and many
colours), headgear, clothes, footwear, left and right hand equipment.
3) Due to the more complex ontology and to the limited awareness of
rule mechanics, the meaning of numbers, text and abstract icons
wouldn't be obvious; on the other hand most data are either hidden from
the player or too complex.
> [...]
> If one does choose to utilize graphics, color
> palette differences make a bigger difference than small shape
> differences for small graphics.
A magnificent example of small graphics distinguished by colour is
offered by Warcraft II and Starcraft: the 8 or more sides that can
appear in a battle have identical units, but shirts, ribbons, panels,
flags, hull paint and other ingenious details have a different colour
for each faction.
Human infantry units in Starcraft, which are among the smallest units
in the game, are differentiated by their colour more than by their
necessarily similar shape: medics are white, basic space marines are
grayish (with a prevalence of the faction colour) and marines with a
flamethrower are red.
It should be noted, however, that these games have been produced by a
well-funded team of unusually competent professionals: RL game
developers should not assume they can do a good job.
Lorenzo Gatti
Erik Piper
Timothy Pruett wrote:
> Christophe wrote:
> > wild.h...@gmail.com a écrit :
> >
> >> R. Dan Henry wrote:
> >>
> >>> On 13 Oct 2005 03:44:10 -0700, "Krice" <pau...@mbnet.fi> wrote:
[ASCII vs. graphics -- which can present more information better?
ASCII's limited ability to display variants of a type of thing]
> ASCII is just a standard code used to represent various letter, symbols,
> and escape sequences. The ASCII standard has nothing to do with the
> actual representation of these letters and symbols. That is left up to
> the app developer. You seem to be confusing curses with ASCII. Curses
> is one particular (and popular) way of displaying ASCII characters on
> terminals. And just because curses is limited to 15 colors does not
> mean all RL developer's face the same limitation with their own ASCII
> display. Jeff Lait's "You Only Live Once" game features bitmapped,
> spiffy looking characters, and he even allows you to swap in characters
> of your own design (granted, it isn't technically ASCII, since it's
> missing a large number of characters, and includes a few original ones,
> but it proves the point).
>
> My (or anybody's) ASCII display in a roguelike can feature as many
> colors as I can think of. Hell, I could slap a texture on the symbols.
> I could make them 3D textured characters, and it would still be ASCII.
>
> So, your initial statement is only a half-truth. Yes, you are limited
> by the number of symbols, but not colors. I think you'd be surprised
> how incredibly limited 8x8 tiles are, by the way, when it comes to the
> number of symbols you can represent. You can only make so many visually
> appealing/easy to interpret symbols in such a small space.
Anybody's graphical display in a roguelike game can feature as large a
tile size as I can think of. :-) The usual reason for not doing so is
avoiding the need to scroll, but that's only because the map display
areas of most roguelikes have character counts high enough to be
unfriendly towards large tiles. For an example of just how good things
can get in terms of a marriage of tile aesthetics and tile
functionality when this ISN'T the case (even inadvertently so), see the
tiles version of Dungeon Crawl. But perhaps even a larger display and
decently large tiles could be married, with a bit of ingenuity...
better support for mouse-free map scrolling than is present in any
major roguelike today would be a good start.
[...]
> > Graphics allows you a few tricks that are impossible or very hard to do
> > in ASCII :
> >
> > - Ability to see the ground tile under the monster. In ASCII you are
> > limited to using a background color for the terrain but most of the time
> > it is a bad idea to do that.
>
> Yes, this is an obvious advantage of graphics. Granted, in many, many
> cases, that isn't really that useful of an ability. Typically, the tile
> the monster is standing on will be of the same type as the surrounding
> tiles. Also, you usually already know what type of tile it is in the
> first place. And lastly, how often do you really need to know the type
> of ground tile a monster is stepping on?
In existing roguelikes, rarely... because most roguelikes are designed
to usually fit the limitations of textmode display. :-P I think that
was the point the OP was trying to make.
> > - Can be zoomed in and out. For example for a minimap.
>
> ASCII can do the same. For example, JADE allows zooming.
Haven't seen JADE's ASCII minimap (didn't know there was anything in
JADE worth looking at yet), but have seen ToME's... not very
impressive. Overall, I have a hard time imagining a top-quality ASCII
minimap rivalling a top-quality graphical minimap. On the other hand, I
have a hard time imagining the *need* for one in an ASCII game unless
it goes over the top with level sizes... not that any existing
roguelike does THAT. :-)
> > - Visual representation of the state of the monster : important magic
> > effects, status like poison, pet/familiar/friendly summon status etc ...
>
> How many magical effects can you really represent on a tiny little tile?
> Not many.
This goes back to the 8x8 thing. 32x32 is pretty close to tile size on
console RPGs, and these do OK in that department (though admittedly,
they tend to use animation for the job).
> And how would you go about representing summon status
> visually, in such a small area?
TileCrawl uses a little heart in the corner of the tile, which IME
works out OK unless you're working with huge summonswarms, where it
really does get a bit confusing.
> > - More liberty for background tiles. Allows you to use many different
> > ground and wall tiles for some gameplay features. Here is a big win for
> > graphics I think. ASCII is just too limited when you want more than the
> > simple wall, ground, door, water dungeon features. Lots of possibilities
> > here like displaying monster footsteps, drawing canals on the ground for
> > electricity to pass ( see GoldenSun for what I mean ;) )
>
> Yes, this is a big advantage. However, you still need much greater
> resources to actually make use of this ability. For example, a talented
> artist is necessary (and yes, they must be talented, because nothing can
> ruin the mood quicker than ugly graphics).
I agree with this objection of yours. I wonder though, are relatively
simple, iconic graphics easier for a mediocre artist to do passably
than "representative" graphics are, and thus a possible way out of the
dilemma for the developer not lucky enough to have/be a Real Artist?
> > - 3D iso effect allows you to add height considerations to your
> > gameplay. If someone finds me a way to do that in ASCII I'm really
> > interested.
>
> Sure, this is certainly doable. Once again, you're confusing one
> particular implementation with the standard.
I think what he was trying to say is that you can do new things in
gameplay if you're no longer restricted by a curses-like interface.
Heck, those ISO graphics could even be little dancing alphanumerics.
:-)
(Reminds me of the roguelike idea that ISTR from a while back where the
PC would, again ISTR, represent nothing more or less than... an at
sign! And the letters represented not monsters, but letters themselves,
who were out to get you!)
> > And many more. Btw, since graphics are abviously superior than ASCII for
> > dungeon features ( ;) ) did someone consider a mixed usage roguelike
> > with tiles for all except for items and monsters ?
>
> Didn't one of those NetHack tilesets *sorta* do that?
Yes, although I don't recall which one (I've never used it, sadly).
Somehow I snipped out above a mention of representing monster armament
with tiles, and the retort that you can certainly still give your
monsters armaments. Of course you can, but it's much nicer to the
player in terms of helping her stay easily informed, and immersive in
its own way IME, when the player can see the armaments in question.
Here again, see TileCrawl.
e.
Timothy Pruett
That does kind of illustrate one key advantage of ASCII: it is easily
possible to fit a *lot* of info on the screen.
>>>Graphics allows you a few tricks that are impossible or very hard to do
>>>in ASCII :
>>>
>>>- Ability to see the ground tile under the monster. In ASCII you are
>>>limited to using a background color for the terrain but most of the time
>>>it is a bad idea to do that.
>>
>>Yes, this is an obvious advantage of graphics. Granted, in many, many
>>cases, that isn't really that useful of an ability. Typically, the tile
>>the monster is standing on will be of the same type as the surrounding
>>tiles. Also, you usually already know what type of tile it is in the
>>first place. And lastly, how often do you really need to know the type
>>of ground tile a monster is stepping on?
>
>
> In existing roguelikes, rarely... because most roguelikes are designed
> to usually fit the limitations of textmode display. :-P I think that
> was the point the OP was trying to make.
I can't even visualize how knowing the tile type beneath a monster
would be routinely useful/necessary. I can't think of any
CRPG/Adventure/etc games that require you to know that information,
except in very rare circumstances.
>>>- Can be zoomed in and out. For example for a minimap.
>>
>>ASCII can do the same. For example, JADE allows zooming.
>
>
> Haven't seen JADE's ASCII minimap (didn't know there was anything in
> JADE worth looking at yet), but have seen ToME's... not very
> impressive. Overall, I have a hard time imagining a top-quality ASCII
> minimap rivalling a top-quality graphical minimap. On the other hand, I
> have a hard time imagining the *need* for one in an ASCII game unless
> it goes over the top with level sizes... not that any existing
> roguelike does THAT. :-)
You should check out the JADE screenshots at
http://www.adom.de/jade/10060101.php3. And, just so you know, his
zooming feature is *very* cool. It's not like ToME's minimap. In
fact, it's not even a minimap at all. You can zoom in and out, and
zooming actually changes the size of the ASCII characters. So zooming
way out would make the characters very tiny, and zooming way in would
make the characters huge. An incredibly cool feature. :-)
>>>- Visual representation of the state of the monster : important magic
>>>effects, status like poison, pet/familiar/friendly summon status etc ...
>>
>>How many magical effects can you really represent on a tiny little tile?
>> Not many.
>
>
> This goes back to the 8x8 thing. 32x32 is pretty close to tile size on
> console RPGs, and these do OK in that department (though admittedly,
> they tend to use animation for the job).
Yes, but this is all at the expense of the player's ability to see a
large portion of the playing field. The larger you make the tiles,
the less the player gets to see. Not really a good trade-off, unless
you design your entire game around that point.
>>And how would you go about representing summon status
>>visually, in such a small area?
>
>
> TileCrawl uses a little heart in the corner of the tile, which IME
> works out OK unless you're working with huge summonswarms, where it
> really does get a bit confusing.
>
>
>>>- More liberty for background tiles. Allows you to use many different
>>>ground and wall tiles for some gameplay features. Here is a big win for
>>>graphics I think. ASCII is just too limited when you want more than the
>>>simple wall, ground, door, water dungeon features. Lots of possibilities
>>>here like displaying monster footsteps, drawing canals on the ground for
>>>electricity to pass ( see GoldenSun for what I mean ;) )
>>
>>Yes, this is a big advantage. However, you still need much greater
>>resources to actually make use of this ability. For example, a talented
>>artist is necessary (and yes, they must be talented, because nothing can
>>ruin the mood quicker than ugly graphics).
>
>
> I agree with this objection of yours. I wonder though, are relatively
> simple, iconic graphics easier for a mediocre artist to do passably
> than "representative" graphics are, and thus a possible way out of the
> dilemma for the developer not lucky enough to have/be a Real Artist?
Most definitely. But, when you start doing simple, iconic graphics,
the end result ends up being something not too terribly far from ASCII
anyway. ;-)
>>>- 3D iso effect allows you to add height considerations to your
>>>gameplay. If someone finds me a way to do that in ASCII I'm really
>>>interested.
>>
>>Sure, this is certainly doable. Once again, you're confusing one
>>particular implementation with the standard.
>
>
> I think what he was trying to say is that you can do new things in
> gameplay if you're no longer restricted by a curses-like interface.
> Heck, those ISO graphics could even be little dancing alphanumerics.
> :-)
>
> (Reminds me of the roguelike idea that ISTR from a while back where the
> PC would, again ISTR, represent nothing more or less than... an at
> sign! And the letters represented not monsters, but letters themselves,
> who were out to get you!)
Yeah, that was ASCIIWorld, my failed 7DRL attempt. This discussion
has made me consider giving it another go, though, but using SDL
instead of curses, and trying out some interesting visual effects I
had planned (variable sized ASCII, multicolored ASCII, ASCII art used
in place of tiles, etc.).
>>>And many more. Btw, since graphics are abviously superior than ASCII for
>>>dungeon features ( ;) ) did someone consider a mixed usage roguelike
>>>with tiles for all except for items and monsters ?
>>
>>Didn't one of those NetHack tilesets *sorta* do that?
>
>
> Yes, although I don't recall which one (I've never used it, sadly).
>
> Somehow I snipped out above a mention of representing monster armament
> with tiles, and the retort that you can certainly still give your
> monsters armaments. Of course you can, but it's much nicer to the
> player in terms of helping her stay easily informed, and immersive in
> its own way IME, when the player can see the armaments in question.
> Here again, see TileCrawl.
I'm going to have to check out TileCrawl later, and see what all the
fuss is about ;-).
--
My projects are currently on hold, but I do have
some junk at the site below.
http://www.freewebs.com/timsrl/index.htm
--
Christophe
>> Anybody's graphical display in a roguelike game can feature as large a
>> tile size as I can think of. :-) The usual reason for not doing so is
>> avoiding the need to scroll, but that's only because the map display
>> areas of most roguelikes have character counts high enough to be
>> unfriendly towards large tiles. For an example of just how good things
>> can get in terms of a marriage of tile aesthetics and tile
>> functionality when this ISN'T the case (even inadvertently so), see the
>> tiles version of Dungeon Crawl. But perhaps even a larger display and
>> decently large tiles could be married, with a bit of ingenuity...
>> better support for mouse-free map scrolling than is present in any
>> major roguelike today would be a good start.
>>
>> [...]
>
>
> That does kind of illustrate one key advantage of ASCII: it is easily
> possible to fit a *lot* of info on the screen.
You either get information about lots of tiles ( ASCII ), or a lot of
information about slightly less tiles ( graphics )
>>>> Graphics allows you a few tricks that are impossible or very hard
to do
>>>> in ASCII :
>>>>
>>>> - Ability to see the ground tile under the monster. In ASCII you are
>>>> limited to using a background color for the terrain but most of the
>>>> time
>>>> it is a bad idea to do that.
>>>
>>>
>>> Yes, this is an obvious advantage of graphics. Granted, in many, many
>>> cases, that isn't really that useful of an ability. Typically, the
tile
>>> the monster is standing on will be of the same type as the surrounding
>>> tiles. Also, you usually already know what type of tile it is in the
>>> first place. And lastly, how often do you really need to know the type
>>> of ground tile a monster is stepping on?
>>
>>
>>
>> In existing roguelikes, rarely... because most roguelikes are designed
>> to usually fit the limitations of textmode display. :-P I think that
>> was the point the OP was trying to make.
>
>
> I can't even visualize how knowing the tile type beneath a monster would
> be routinely useful/necessary. I can't think of any CRPG/Adventure/etc
> games that require you to know that information, except in very rare
> circumstances.
Tome with items and traps on top of lava or frozen ground for example.
Monters aren't the only items that obscure the vision of the ground :)
>> Haven't seen JADE's ASCII minimap (didn't know there was anything in
>> JADE worth looking at yet), but have seen ToME's... not very
>> impressive. Overall, I have a hard time imagining a top-quality ASCII
>> minimap rivalling a top-quality graphical minimap. On the other hand, I
>> have a hard time imagining the *need* for one in an ASCII game unless
>> it goes over the top with level sizes... not that any existing
>> roguelike does THAT. :-)
>
>
> You should check out the JADE screenshots at
> http://www.adom.de/jade/10060101.php3. And, just so you know, his
> zooming feature is *very* cool. It's not like ToME's minimap. In fact,
> it's not even a minimap at all. You can zoom in and out, and zooming
> actually changes the size of the ASCII characters. So zooming way out
> would make the characters very tiny, and zooming way in would make the
> characters huge. An incredibly cool feature. :-)
Not bad but the zoomed in view is ugly :) Too much spaces between
symbols I think. Symbols just aren't made for such a close view.
The zoomed out view is neat too although a little hard to read. In fact,
at that zoom level, the readability doesn't come from the symbol but
from the color and the weight of the symbol ( ie : the ratio of black to
colored pixels for the symbol ) :)
>> This goes back to the 8x8 thing. 32x32 is pretty close to tile size on
>> console RPGs, and these do OK in that department (though admittedly,
>> they tend to use animation for the job).
>
>
> Yes, but this is all at the expense of the player's ability to see a
> large portion of the playing field. The larger you make the tiles, the
> less the player gets to see. Not really a good trade-off, unless you
> design your entire game around that point.
Fast dynamic zoom goes a lot to offset that problem. Stay in zoomed out
mode for most of the time and when the state of the monsters does
matter, zoom in a little.
>> I agree with this objection of yours. I wonder though, are relatively
>> simple, iconic graphics easier for a mediocre artist to do passably
>> than "representative" graphics are, and thus a possible way out of the
>> dilemma for the developer not lucky enough to have/be a Real Artist?
>
>
> Most definitely. But, when you start doing simple, iconic graphics, the
> end result ends up being something not too terribly far from ASCII
> anyway. ;-)
That's a matter of taste I guess.
Erik Piper
Timothy Pruett wrote:
[in a discussion involving many people, of which the last was me]
> > [graphical tiles only tend to be so small because big ones get in the way when displays are designed to show lots of squares at a time, which is usually the case]
> > [...]
>
> That does kind of illustrate one key advantage of ASCII: it is easily
> possible to fit a *lot* of info on the screen.
That is indeed nice, but not necessary IMO -- see again the many
console games with nice UIs demanding that the player (painlessly)
scroll, (painlessly) make use of minimaps, etc. I have a hunch that
it's just come to feel necessary in roguelikes because curscii makes it
so easy to do that it seems you have to make use of it.
> >>> [graphics makes it possible to show terrain under a monster]
> >> [yeah, so? where is it even used, anyway?]
> > In existing roguelikes, rarely... because most roguelikes are designed
> > to usually fit the limitations of textmode display. :-P I think that
> > was the point the OP was trying to make.
>
> I can't even visualize how knowing the tile type beneath a monster
> would be routinely useful/necessary. I can't think of any
> CRPG/Adventure/etc games that require you to know that information,
> except in very rare circumstances.
The latter point is just a question of what's been created to date, not
what CAN be created. Some examples below actually refer to existing
games, but again, it's a moot issue. As to the former point:
Is that monster standing on a terrain that damages per turn or not?
Which monster is on the square with the lever that raises the
drawbridge? I only have a few turns to get it raised before <terrible
thing x happens>!
Is that monster wading in water, reducing its melee ability, or on dry
land?
Which spot underneath that big horde is the one where the stairs are?
Which monster is on the altar nearby and thus the one that will get
live-sacced if I pray right now?
My geomancy powers will get that monster easily if it's standing on
sand, but hardly affect it if it's standing on stone. Which one is it?
> >>>- Can be zoomed in and out. For example for a minimap.
> >>
> >>ASCII can do the same. For example, JADE allows zooming.
> > [Really? blah bingle gooby geeby mirkl splee]
> [Really! [description of how really]]
Exciting! I'm so excited about JADE I'm going to go out and buy Duke
Nukem Forever when it's released just to get the copy of JADE they
say'll be bundled with it!
(But seriously now -- that sounds *really* neat, and I hope TB makes a
million soon in his suit-and-tie stuff so he can retire and finally
spend the quality time with JADE needed to release it.
It's also a superb example of why none of us here should confuse ASCII
with CurSCII.)
> >>>- Visual representation of the state of the monster : important magic
> >>>effects, status like poison, pet/familiar/friendly summon status etc ...
> >>
> >>How many magical effects can you really represent on a tiny little tile?
> >> Not many.
> >
> > This goes back to the 8x8 thing. 32x32 is pretty close to tile size on
> > console RPGs, and these do OK in that department (though admittedly,
> > they tend to use animation for the job).
>
> Yes, but this is all at the expense of the player's ability to see a
> large portion of the playing field. The larger you make the tiles,
> the less the player gets to see. Not really a good trade-off, unless
> you design your entire game around that point.
Showing a large portion of the playing field, having a great iconic
tileset that costs no extra development/art time, etc. is all at the
expense of the advantages of graphics, including the "think of the
NEWBIEEEEEES" advantage that surprisingly hasn't come up yet this time
around. Not really a good tradeoff, unless you design your entire game
around that point. Which many authors HAVE, and it's worked great --
but that doesn't mean that tradeoff is the only way.
> >> [tileart that doesn't ruin the mood requires good artists]
> > I agree with this objection of yours. I wonder though, are relatively
> > simple, iconic graphics easier for a mediocre artist to do passably
> > than "representative" graphics are, and thus a possible way out of the
> > dilemma for the developer not lucky enough to have/be a Real Artist?
>
> Most definitely. But, when you start doing simple, iconic graphics,
> the end result ends up being something not too terribly far from ASCII
> anyway. ;-)
Even an iconic orc can be displayed to show its dagger and the ground
it's standing on. Heck, silly-looking though it might be, you could
even do that with an "o", as long as it was a bitmapped "o".
> > [foo reminds me of [describes ASCIIWorld but can't remember whose it is and what it's called]]
> Yeah, that was ASCIIWorld, my failed 7DRL attempt. This discussion
> has made me consider giving it another go, though, but using SDL
> instead of curses, and trying out some interesting visual effects I
> had planned (variable sized ASCII, multicolored ASCII, ASCII art used
> in place of tiles, etc.).
Here's rooting for you!
> > [blah blah TileCrawl blah blah]
> I'm going to have to check out TileCrawl later, and see what all the
> fuss is about ;-).
Incidentally, it was with TileCrawl, rather than the otherwise vastly
less player-hostile ADOM, that I finally got my brother-in-law to try a
roguelike. "Finally," I could see him saying, "something that looks
like an actual game!" Getting him to try one or two of the other
biggies in the genre are still a ways ahead on my Plan for
Brother-in-Law Domination, though, now that he's thoroughly obsessed
with finally getting one of his string of Minotaur Berserkers past
dungeon level 12. :-)
e.
Radomir 'The Sheep' Dopieralski
Christophe wrote:
> Timothy Pruett a écrit :
> Fast dynamic zoom goes a lot to offset that problem. Stay in zoomed out
> mode for most of the time and when the state of the monsters does
> matter, zoom in a little.
Like The Worms! Yay!
--
Radomir `The Sheep' Dopieralski @**@_
(==) 3 Yawn?
David Damerell
>Martin Read wrote:
>>I don't know whether it's an orc, a troll, an ogre, or some
>>kind of demon-thing from a nameless corner of Hell.
>Well, you know a lot less when you look at ascii symbol.
Not in the least; we have the benefit of the established conventions -
like, say, that 'o' is an orc.
>>That's because graphics are not inherently better.
>Makes me wonder why they invented graphics adapters at all, if
>ascii is better:)
No doubt you only read books with pictures in, too. That explains a lot.
--
David Damerell <dame...@chiark.greenend.org.uk> flcl?
Today is First Aponoia, October.
David Damerell
> Christophe wrote:
>>Graphics allows you a few tricks that are impossible or very hard to do
>>in ASCII :
>Yes. You can do much more with graphics -- in particular, you can do
>ASCII. It's obvious.
Well, no. You can't do "playable over a telnet/ssh connection", which is
one of the advantages of ASCII.
Christophe
> Quoting Radomir 'The Sheep' Dopieralski <sheep1 % sheep.prv.pl>:
>
>>Christophe wrote:
>>
>>>Graphics allows you a few tricks that are impossible or very hard to do
>>>in ASCII :
>>
>>Yes. You can do much more with graphics -- in particular, you can do
>>ASCII. It's obvious.
>
>
> Well, no. You can't do "playable over a telnet/ssh connection", which is
> one of the advantages of ASCII.
ssh -X distant_computer
export DISPLAY=mylocalcomputer
graphics_roguelike
David Damerell
>Is that monster standing on a terrain that damages per turn or not?
>Which monster is on the square with the lever that raises the
>drawbridge? I only have a few turns to get it raised before <terrible
>thing x happens>!
>Is that monster wading in water, reducing its melee ability, or on dry
>land?
>Which spot underneath that big horde is the one where the stairs are?
>Which monster is on the altar nearby and thus the one that will get
>live-sacced if I pray right now?
>My geomancy powers will get that monster easily if it's standing on
>sand, but hardly affect it if it's standing on stone. Which one is it?
As a side note, these game mechanics could be easily introduced into a
ASCII game with a "display terrain only" keypress. I'm not saying it would
be as easy as tiles, but it's certainly feasible.
... actually, dear ASCII roguelike authors, how about it?
David Damerell
Congratulations, you
a) don't know how to drive ssh -X
b) have a solution that only works with good bandwidth
c) have a solution that only works if your local computer has an X display
d) have just allowed the distant computer to own your X display completely.
Christophe
> Quoting Christophe <chris.c...@free.fr>:
>
>>David Damerell a écrit :
>>
>>>Quoting Radomir 'The Sheep' Dopieralski <sheep1 % sheep.prv.pl>:
>>>
>>>>Yes. You can do much more with graphics -- in particular, you can do
>>>>ASCII. It's obvious.
>>>
>>>Well, no. You can't do "playable over a telnet/ssh connection", which is
>>>one of the advantages of ASCII.
>>
>>ssh -X distant_computer
>>export DISPLAY=mylocalcomputer
>>graphics_roguelike
>
>
> Congratulations, you
>
> a) don't know how to drive ssh -X
What ? Can you be more specific here ?
> b) have a solution that only works with good bandwidth
It works, bandwidth wasn't mentioned here.
> c) have a solution that only works if your local computer has an X display
And so what ? Next you'll tell me graphics are inferior because they
only work on computers with a graphical display ?
> d) have just allowed the distant computer to own your X display completely.
Please, if the distant computer can be trusted ( and since it is often
my own computer, it can ) then it doesn't matter. Also, if you use
things like cygwin server, it doesn't matter because the X display can't
take control of the whole screen. And on Linux you can spawn a second X
server just for that.
R. Dan Henry
>Somehow I snipped out above a mention of representing monster armament
>with tiles, and the retort that you can certainly still give your
>monsters armaments. Of course you can, but it's much nicer to the
>player in terms of helping her stay easily informed, and immersive in
>its own way IME, when the player can see the armaments in question.
>Here again, see TileCrawl.
Although then you develop a tendency to make weapon selection depend on
available graphics or at least to lag until new graphics can be made.
Also, to truly be useful, you need several varieties for each weapon
type, as it is much more useful to know that the kamakazi kobold has a
butterfly knife of *poisoning* than that it has a butterfly knife
instead of a spear.
Never mind the difficulty of showing the monster's armor, weapon,
shield, helmet, boots, potions, wand, and scrolls. And a wand is going
to be more significant than anything else most of the time.
You still need the look command to get the important information about
what a monster is carrying in every tile set I've ever seen. You really
can't show monster inventories properly even with 64x64 tiles and the
work involved for even a modestly complex game would be quite large.
R. Dan Henry
<dame...@chiark.greenend.org.uk> wrote:
Exactly my thought.
Krice
> You still need the look command to get the important information about
> what a monster is carrying in every tile set I've ever seen. You really
> can't show monster inventories properly even with 64x64 tiles and the
Maybe because showing monster inventory is a silly demand for any
game. What you can show is the weapon and armour (see: H-World).
But you can't do that in ascii.
wild.h...@gmail.com
Radomir 'The Sheep' Dopieralski wrote:
> At Fri, 14 Oct 2005 10:39:00 +0200,
> Christophe wrote:
>
> > wild.h...@gmail.com a écrit :
> >> R. Dan Henry wrote:
> >>>On 13 Oct 2005 03:44:10 -0700, "Krice" <pau...@mbnet.fi> wrote:
>
> > Graphics allows you a few tricks that are impossible or very hard to do
> > in ASCII :
>
> Yes. You can do much more with graphics -- in particular, you can do
> ASCII. It's obvious.
>
> But this comes at a cost. ASCII is pretty well-crafted symbol set
> (yes, it could be better, but it's not bad). There are very few really
> bad ways to use it, and those can be usually recognized instantly.
My original comments were directed mainly in the amateur-RL developer
category. I lack the graphical talent of my six-year-old cousin who
thinks rainbows are really fun to draw, and appears to have received
her inspiration on the human form from the signs on bathroom doors.
Graphics, as a whole, DO offer an immensely more powerful medium, but
the complexity sacrifices something as well. In a 16x16 tile set, most
humanoids will look almost identical. In most 16x16 console games, many
humanoid figures look almost identical (except for vastly different
color palettes), and its these certain
similar-looking-but-wildly-different-tiles that cause problems.
Sometimes it can be difficult to adequately distinguish "wall" with
"wall with switch" as well. Combine this with the typical RL
programmer's acute lack of drawing ability, and you have an overall
pretty crappy looking game.
> With graphics you've got more freedom. Freedom means responsibility.
> It's sufficient to make only a few minor mistakes to make your game
> very uncomfortable, and the reason behinf the uncomfortability is not
> apparent. It takes a few more errors to make tha game totally unplayable.
>
> ASCII is a nice scheme you can use. To make this, ehm, discussion a little
> more constructive, what other schemes are there for the graphics
> developers? I mean something a little more strict than just "isometry"
> or somethng... ;)
Here's some I've been thinking of. Laud them or pick them apart at your
leisure.
Being a fan of several console RPG games, there are a lot of visual
"tricks" which are relatively easy to pull off that can be added to
this category. If you're using tiles, you can fake some perspective by
making them slightly taller than they are wide, and using some overlap
over the next tile up (Final Fantasy VI anyone?). There's also Zelda,
which utilized some interesting "wall" tiles which create the illusion
of 3D. If I remember correctly, the developers assigned a "height" to
each tile - if objects were below this height, they weren't drawn, if
they were above it, they were. Simple, but visually impressive.
A couple animated tiles can go a long way to making your game look more
dynamic. If you have a torch, utilize a short flame animation. Water?
Make funky-looking waves. Conveyor belts should... convey. For simple
animations like these, if you have the underlying tiles already drawn
(fire, water, belt), adding the resulting animations to the mix
shouldn't be terribly difficult.
If you ARE sticking to ASCII because you completely LACK drawing talent
(again, like myself), consider utilizing true-type fonts and a 24-bit
color display. There's a lot you can do with that many colors,
including colorizing the background away from hard-to-see black, but
you'll need to plan ahead to make sure your text is clearly visible on
the background colors (i.e. no light green monsters on light green
terrain). You can easily add animations and simple special effects
also, since you're moving away from the conventional plain console
display. One of the most useful might be to include gradient lighting
on tile backgrounds and monsters. Again, color-collisions will be
important considerations for this scenario.
Even more complicated: Vector graphics. Allow resizing and scaling,
along with 3D perspective if you go that route. You can also do cel
shading this way, if that's your thing.
Timothy Pruett
ADoM does it.
Owen Jacobson
> David Damerell a écrit :
>> Quoting Christophe <chris.c...@free.fr>:
>>
>>>David Damerell a écrit :
>>>
>>>>Quoting Radomir 'The Sheep' Dopieralski <sheep1 % sheep.prv.pl>:
>>>>
>>>>>Yes. You can do much more with graphics -- in particular, you can do
>>>>>ASCII. It's obvious.
>>>>
>>>>Well, no. You can't do "playable over a telnet/ssh connection", which is
>>>>one of the advantages of ASCII.
>>>
>>>ssh -X distant_computer
>>>export DISPLAY=mylocalcomputer
>>>graphics_roguelike
>>
>>
>> Congratulations, you
>>
>> a) don't know how to drive ssh -X
>
> What ? Can you be more specific here ?
ssh -X creates a tunnel from distant_computer to your real X server at
:10 and up (by default; configurable). Your 'export DISPLAY=' bypasses
the tunneled X display, connecting directly (or not at all) to the X
server.
>> b) have a solution that only works with good bandwidth
>
> It works, bandwidth wasn't mentioned here.
Playability is generally a safe assumption here. While X is potentially
fairly quick, blitting bitmaps (eg., tiles) over it won't make it
particularly usable over the internet.
>> c) have a solution that only works if your local computer has an X display
>
> And so what ? Next you'll tell me graphics are inferior because they
> only work on computers with a graphical display ?
For better or for worse, it's unsafe to assume that only people with an X
server will want to play your game. "But they can get one" is sophistry
at best; certainly some players will, but the vast majority will simply
move on to a game with a lower barrier to entry.
If that's acceptable, more power to you. If you're going for broad
appeal, well...
>> d) have just allowed the distant computer to own your X display completely.
>
> Please, if the distant computer can be trusted ( and since it is often
> my own computer, it can ) then it doesn't matter. Also, if you use
> things like cygwin server, it doesn't matter because the X display can't
> take control of the whole screen. And on Linux you can spawn a second X
> server just for that.
"It's safe most of the time" is no excuse.
R. Dan Henry
My point was that simple weapon-and-armor isn't the most important
inventory information generally, so it doesn't really much save on using
the look command, so you're down to the purely subjective "I like
pictures" form of graphics endorsement. And you can do a look command in
ASCII just fine.
Also note that the effort to produce graphics was one of the more
serious handicaps H-World suffered under. There are few monster and few
items and the graphics for them are of variable quality. H-World is a
good example of why anyone who wants to finish their game should avoid
making graphics at the same time. Add graphics later or use an existing
set -- and using an existing set artificially constrains you to a world
that matches the available graphics. Ugh.
Christophe Cavalaria
> On Fri, 14 Oct 2005 18:45:43 +0200, Christophe wrote:
>
>> David Damerell a écrit :
>>> Quoting Christophe <chris.c...@free.fr>:
>>>
>>>>David Damerell a écrit :
>>>>
>>>>>Quoting Radomir 'The Sheep' Dopieralski <sheep1 % sheep.prv.pl>:
>>>>>
>>>>>>Yes. You can do much more with graphics -- in particular, you can do
>>>>>>ASCII. It's obvious.
>>>>>
>>>>>Well, no. You can't do "playable over a telnet/ssh connection", which
>>>>>is one of the advantages of ASCII.
>>>>
>>>>ssh -X distant_computer
>>>>export DISPLAY=mylocalcomputer
>>>>graphics_roguelike
>>>
>>>
>>> Congratulations, you
>>>
>>> a) don't know how to drive ssh -X
>>
>> What ? Can you be more specific here ?
>
> ssh -X creates a tunnel from distant_computer to your real X server at
> :10 and up (by default; configurable). Your 'export DISPLAY=' bypasses
> the tunneled X display, connecting directly (or not at all) to the X
> server.
You're right. Let's say that the first line was for ssh users and the second
for telnet users :)
>>> b) have a solution that only works with good bandwidth
>>
>> It works, bandwidth wasn't mentioned here.
>
> Playability is generally a safe assumption here. While X is potentially
> fairly quick, blitting bitmaps (eg., tiles) over it won't make it
> particularly usable over the internet.
And what ? The point of the op was that it was "impossible" to play a
graphical roguelike that way. I just said that it was indeed possible and
even very easy when you add a X server on your current computer. You'll
note that the distant computer has to be a Unix-like system for you to
connect through ssh and play a curses game.
>>> c) have a solution that only works if your local computer has an X
>>> display
>>
>> And so what ? Next you'll tell me graphics are inferior because they
>> only work on computers with a graphical display ?
>
> For better or for worse, it's unsafe to assume that only people with an X
> server will want to play your game. "But they can get one" is sophistry
> at best; certainly some players will, but the vast majority will simply
> move on to a game with a lower barrier to entry.
For better of for worse, it's unsafe to assume that a significant number of
players will want to play the game on a distant computer.
> If that's acceptable, more power to you. If you're going for broad
> appeal, well...
Makes me laugth when you talk about broad appeal for a feature none of us
even know if it is used by more than 0.1% of roguelike players.
And btw, you'll note that you can do that with VNC too. And know what ? It
works ok even with somewhat limited bandwidth and it can be used with *any*
kind of computer at both ends of the communication. It's just a little
harder to setup.
>>> d) have just allowed the distant computer to own your X display
>>> completely.
>>
>> Please, if the distant computer can be trusted ( and since it is often
>> my own computer, it can ) then it doesn't matter. Also, if you use
>> things like cygwin server, it doesn't matter because the X display can't
>> take control of the whole screen. And on Linux you can spawn a second X
>> server just for that.
>
> "It's safe most of the time" is no excuse.
It's safe when I control both endpoints of the comunication. It's safe
enouth for me and if that isn't enouth for you, I suggest that you should
pull the plug on your internet connection now before the hackers attack.
Krice
> My point was that simple weapon-and-armor isn't the most important
> inventory information generally
I think it's somewhat important to know what the npc is wearing
and wielding. What could be more important?
> so it doesn't really much save on using the look command
It does, if look isn't going to reveal more, like the inventory
of the creature. That sounds silly and I don't know any game that
shows the entire inventory of a creature when you look at it.
> Also note that the effort to produce graphics was one of the more
> serious handicaps H-World suffered under.
Really? I think it is one of the best features in that game, although
graphics can require a lot of work. But I guess there were other
reasons why the development of H-World was stopped. (Or was it?)
Again, compared to other elements of a roguelike, graphics are a
relatively easy task. You can even find someone to help you in
that if you are lucky.
Radomir 'The Sheep' Dopieralski
Krice wrote:
> R. Dan Henry wrote:
>> My point was that simple weapon-and-armor isn't the most important
>> inventory information generally
>
> I think it's somewhat important to know what the npc is wearing
> and wielding. What could be more important?
Probably whether it is neutral, friendly or hostile, and in the case of
the latter, whether it's asleep, looking for a fight or about to run away.
It's health status might be pretty important too... and it's
posisoned/paralyzed/blind/confused/etc. status too...
--
Radomir `The Sheep' Dopieralski @**@_
(--) 3 ..zzZZ
Elethiomel
> R. Dan Henry wrote:
>
>>My point was that simple weapon-and-armor isn't the most important
>>inventory information generally
>
>
> I think it's somewhat important to know what the npc is wearing
> and wielding. What could be more important?
Now you're just trolling. In the post before the post you replied to, in
this thread, R. Dan Henry said;
>>>>Although then you develop a tendency to make weapon selection depend
>>>>on available graphics or at least to lag until new graphics can be
>>>>made. Also, to truly be useful, you need several varieties for each
>>>>weapon type, as it is much more useful to know that the kamakazi
>>>>kobold has a butterfly knife of *poisoning* than that it has a
>>>>butterfly knife instead of a spear.
>>>>Never mind the difficulty of showing the monster's armor, weapon,
>>>>shield, helmet, boots, potions, wand, and scrolls. And a wand is
>>>>going to be more significant than anything else most of the time.
Which is pretty clearly what he is referring to here. Why did you ignore
these points in your original reply to that post?
>>so it doesn't really much save on using the look command
>It does, if look isn't going to reveal more, like the inventory
>of the creature. That sounds silly and I don't know any game that
>shows the entire inventory of a creature when you look at it.
You don't know about Crawl?
Radomir 'The Sheep' Dopieralski
> R. Dan Henry wrote:
> Again, compared to other elements of a roguelike, graphics are a
> relatively easy task.
Right... er, no, wrong.
--
Radomir `The Sheep' Dopieralski @**@_
(`') 3 Grrr!
wild.h...@gmail.com
Radomir 'The Sheep' Dopieralski wrote:
> Krice wrote:
>
> > R. Dan Henry wrote:
>
> > Again, compared to other elements of a roguelike, graphics are a
> > relatively easy task.
>
> Right... er, no, wrong.
I second that. Decent graphics - on par with a mid-level console game,
or the original Diablo - take a LOT of work, and are very complicated
to do right. In my opinion, the other "complex" roguelike elements -
dungeon generation algorithm design and AI creation - are on par with
designing a good graphics engine, without the added complexity of
having to draw every single sprite/tile/polygon ever used in the game.
For the conventional RL designer, this option is less than appealing.
Martin Read
>Again, compared to other elements of a roguelike, graphics are a
>relatively easy task.
For me, producing figurative graphics suitable for use in a roguelike
is very hard and time-consuming, while writing code is easy and designing
game mechanics and content is only moderately hard. Also, I *enjoy*
writing code and designing game mechanics and content; that's why I'm
writing a roguelike.
>You can even find someone to help you in
>that if you are lucky.
Those people I know who *are* good artists do not generally produce the
sort of art that's suitable for my roguelike. My friends, by and large,
have pretty peculiar taste in art.
And for the UI of a roguelike, crap graphics are worse than curses-based
terminal displays.
--
Martin Read - my opinions are my own. share them if you wish.
\_\/_/ http://www.chiark.greenend.org.uk/~mpread/dungeonbash/
\ / "tempted white eyes blinded by the night hollow like the towers from the
\/ inside laura's a machine she's burning insane" fields of the nephilim
Martin Read
>As a side note, these game mechanics could be easily introduced into a
>ASCII game with a "display terrain only" keypress. I'm not saying it would
>be as easy as tiles, but it's certainly feasible.
>
>... actually, dear ASCII roguelike authors, how about it?
Your feature request has been added to the wishlist as W1.4-10.
R. Dan Henry
>R. Dan Henry wrote:
>> My point was that simple weapon-and-armor isn't the most important
>> inventory information generally
>
>I think it's somewhat important to know what the npc is wearing
>and wielding. What could be more important?
His freakin' Wand of *Death*!
But then that was clear to anyone who actually read what I wrote the
first time. Since you aren't willing to have an actual conversation,
I've better things to do than continue this exchange.
Krice
> His freakin' Wand of *Death*!
Well, you could make the npc wield the wand first before being able
to use it. But really that was not the point. Besides, I would
never put things like wand of death in my game. I like to give
the player come chances to survive, instead of sudden deaths.
> Since you aren't willing to have an actual conversation,
> I've better things to do than continue this exchange.
Is throwing things like "wand of death" an actual conversation?
Look is probably required, but then again, you need to use it
more often in ascii roguelike.
R. Alan Monroe
>So, your initial statement is only a half-truth. Yes, you are limited
>by the number of symbols, but not colors. I think you'd be surprised
>how incredibly limited 8x8 tiles are, by the way, when it comes to the
>number of symbols you can represent. You can only make so many visually
>appealing/easy to interpret symbols in such a small space.
If anyone wants to see what CAN be done with 8x8 pixels in 8 colors, I
made some .pngs of the Amiga Larn tileset:
http://javajack.dynalias.net/rl/amigalarn/amigalarnmonsters.png
http://javajack.dynalias.net/rl/amigalarn/amigalarnobjects.png
While playing the game I definitely never had any problems identifying
any monsters or normal objects. Rings weren't always obvious though.
Alan
David Damerell
>>>ssh -X distant_computer
>>>export DISPLAY=mylocalcomputer
>>>graphics_roguelike
>>Congratulations, you
>>a) don't know how to drive ssh -X
>What ? Can you be more specific here ?
The "export DISPLAY" means you aren't actually using ssh connection
forwarding at all. And presumably are either "xhost +" (idiot) or have
specifically done "xhost + distant_computer" - permitting anyone on it to
own your X display rather than just root.
>>b) have a solution that only works with good bandwidth
>It works, bandwidth wasn't mentioned here.
So if you don't have good bandwidth it, er, doesn't work.
>>c) have a solution that only works if your local computer has an X display
>And so what ?
So concievably Windows users - who there do seem to be one or two of
playing roguelikes - will not be entirely enthused by the prospect of
having to install one of the (often non-free and/or extremely shonky) X
servers for that platform.
>Next you'll tell me graphics are inferior because they
>only work on computers with a graphical display ?
From the point of view of someone with a text display, graphics are indeed
inferior. From the point of view of someone without an X display, using X
connection forwarding is inferior. This doesn't seem very contentious to
me.
>>d) have just allowed the distant computer to own your X display completely.
>Please, if the distant computer can be trusted ( and since it is often
>my own computer, it can ) then it doesn't matter.
Oh, well, since it's *often* your own computer, that doesn't matter. After
all, we can trust every public NetHack server admin implicitly (more
significantly, you seem to think we could trust the public server admins
we'd get for a game that had such significant cracking potential) because
*often* we aren't using their machines and that somehow stops them being
naughty when we are.
Huh?
>Also, if you use
>things like cygwin server, it doesn't matter because the X display can't
>take control of the whole screen. And on Linux you can spawn a second X
>server just for that.
This certainly isn't making the game AT ALL complicated to play.
[And, it doesn't help. If at any point you've got a terminal window open
on this second X server, the game server can input any shell commands it
likes.]
--
David Damerell <dame...@chiark.greenend.org.uk> Kill the tomato!
Today is Gaiman, October - a public holiday.
Kostatus
> The problem, however, is that there don't seem to be any free (or
> really, any at all) monospaced square (16x16, 24x24, 32x32; that sort
> of thing) fonts on the internet. Without such a font, I would need to
> deal with translating the proper places to blit font in relation to
> where the sprite's footprint is, which would make the entire idea
> somewhat senseless, aside from causing the toggle from sprite to
> text-display modes to be disorienting.
I know this is an older thread. But I'll throw in a comment anyway.
I was recently playing around with my graphical tiles, and decided to see
how it would look if I replaced every Graphical tile with an ASCII tile
(ie. an image with black background with a coloured ASCII symbol on top).
It did not take long at all and it turned out to look quite good, though
unorthodox with the 32x32 tiles. It worked to be just like a square
font, which is what you want.
So if you want square ASCII, try to just replace them with with square
ASCII tiles.
--
Kostatus
kostatus001 at ihug co nz
http://www.geocities.com/kostatus/ (My project)
http://www.geocities.com/kostatus/reviews.html (My reviews)