Some thoughts on Graphics in Roguelike Games.
by Darren Hebden [rogue@skoardy.demon.co.uk]


	Traditionally, if you suggested graphics to a roguelike-
stalwart, you would have found yourself out on your ear for speaking 
such heresy. Many would argue that being text-based is a defining 
feature of the roguelike genre. Others want more and look upon 
graphics as a natural progression. 

	Many people (purveyors of quality knee-jerk reactions and 'The
end is Nigh' flavoured rantings) warn of the old-style being phased 
out or graphic-based roguelikes lacking the same depth of text-based.
Personally, I like to believe that both can exist quite happily and
that the addition of graphics in roguelike games is a bonus, not a 
replacement. It is a new feature and it's use within the roguelikes
is still being explored. 

	This document talks a little about the uses of graphics in 
roguelikes, the different styles and some graphic techniques. Not 
being an expert on all systems (or the one I own, come to that), I'll 
try to make my article non-machine-specific. If you know a little 
about the packages you own, you should be able understand my texts.

                              ----//----      

# Why Graphics.

PROS.
1) It's a "draw".
	The visual style attracts the eye to games that many of the 
uneducated heathens (sorry, I mean -- people who haven't encountered
roguelike games before) would ignore and pass over because of their
archaic text-editor style appearance. 

2) It's expected.
	Unfortunately, the expectations of todays game player have been
adversely influenced by big budget, multi-cd, flashy productions. I
don't exactly find this a pleasant situation but ignoring it or 
"taking a stand" won't help you or your game. 

3) So what's a 'Furgikan-bug'?
	Although a great deal of people are up on Tolkien lore and AD&D 
monster theory 101, but an unknown creature shown as a 'F' character 
on-screen may leave several of your players scratching their heads. A
well-drawn image, however, is instantly recognisable and gives a 
better impression of the creatures appearance.

CONS.
1) Graphics kill the imagination.
	The original roguelike style counts on the players imagination 
to transform a simple red 'D' into the terrifying bulk of Fire Dragon
flesh. No matter how detailed your graphics are, they may not be able
to live up to the visions swirling around an over-active imagination.

2) Bigger programs.
	The storage of large amounts of graphics data all adds to the 
overall archive size for your game. It's very difficult to produce a
competent roguelike game with a small selection of graphics without
compromising the colour-depth or tile size. Whichever way you even
things out, graphics mean an increased game footprint.

3) Bad graphics drag a game down.
	Good graphics can really add to the atmosphere of a game but in
the same way, a bad set of graphics can seriously hamper a game which
is technically competent and full of depth. Will you be able to supply
good graphics for your game or would the game be better served staying
with a text only display? Don't treat graphics like the current
band-wagon to climb aboard.

                              ----//----      

# Graphic Styles.

	Although all through this document I speak of older roguelikes
being text based, simple texts characters _are_ a form of graphics. A
'g' from a gremlin may be missing a few limbs and that mad glint in
his eye but people soon become lost within the game world and accept
that a horde of crazed 'g's bearing down on a weakened adventurer is
not a good sign.

There are several different styles that you can use when representing 
your dungeon on-screen. 

1) Flat Tiles.
	The most typical use of graphics in roguelikes is a one-for-one 
replacement of the ascii-characters themselves. A wall character is 
replaced with a brick pattern, a water character by a lump of blue. 
	
	A little work is needed re-assigning what is displayed or how 
they are arranged on screen but often, this method restricts the 
artist in getting the best from the tile size and colour depth 
available. Due to the forced nature of the way the tiles may be 
arranged, the artist could be unable to introduce some details that 
would improve the overall look.

	This style doesn't _have_ to suffer from badly arranged tiles if 
the artist uses the way the tiles are placed to his benefit and the 
programmer is willing to make slight alterations to get the best out 
of the tiles provided. The perfect solution is to be programmer and 
artist :-)

Badly drawn example... XXXXX
                       XXXXX
                       XXXXX
                       XXXXX 
                       XXXXX

	
2) Pseudo-3D Flat Tiles.
	The next style is very similar to the first but instead of flat 
patterns for tiles, the impression of depth is given by drawing front 
edges on lower half of the tile for the walls. It's a cheap trick but 
is quite effective. The illusion is only spoiled by the fact that the 
player cannot walk behind the tiles as they occupy the same space as a 
normal wall tile. A little 'walk-behind' effect can be gained if the 
tiles are overlapped. It okay but you also begin to lose a little of 
the floorspace of the tile above.

	All in all, a popular choice and for tiles that need a little 
more work when it comes to designing them to fit together. It means 
more graphics but generally, it's worth it.

Badly drawn example... XXXXX
                       XXXXX
                       XXXXX
                       ||||| 
                       |||||


3) Isometric Tiles.
	These tiles create the impression that the level is viewed from 
an angle of 45 degrees to the left/right. As they go, this style gives 
a very good illusion of depth (apart from the total lack of 
perspective, ofcourse). 

	A problem with this style is that these tiles really need to 
overlap. I've tried some experiments with not overlapping them and 
they looked very bizarre. The overlap causes a bit of lost floorspace 
of the tiles drawn above the walls but this can be reduced by having 
shorter walls. 

As with the overlapping from the previous style, don't go over the top 
with the shortened walls though or you'll have levels looking like a 
stunted hedge-maze.

	A solution would be to make any wall that overlaps a floorspace 
semi-transparent. This effect can be achieved by either some rather 
clever palette mixing tricks on the programmers side of things (which 
is rather a bit of overkill for a roguelike) or by a chess-board style 
hashing of the pixels over the overlapped area -- one pixel of the 
wall, one of the floor, etc. It is a bit of a cop-out but quite 
effective. 

Badly drawn example...   X
                        XXX  
                       XXXXX
                       |XXX|
                       ||X||
                        |||
                         |


4) Tunnel Vision (or That-Style-From-Dungeon-Master).
	The player is presented with a full perspective view of a
corridor/tunnel of the dungeon. Items in the distance are smaller and
tunnels lead off from the original at right angles. Movement is 
generally made in steps and switching the direction viewed usually
snaps round ninety degrees.

	This style allows for more detail on the wall/floor tiles as the
tiles closest to the player are quite large on screen. I've yet to 
see this used in a roguelike game although it has been suggested 
quite a few times. Other games have used this style and in some
ways, you could argue that Dungeon Master, Eye of the Beholder, etc.
are in essence roguelike.

	One reason for it not being implemented is that the player can
only see in one direction at a time. Usual roguelikes have forces
coming at the player from all sides. This may put several players off
due to the confusing nature of this 'realistic' feature. Other 
windows containing the left/right/back views may help this situation.

Badly drawn example...   .........
                         |.......|
                         ||.....||
                         |||   |||
                         |||   |||
                         ||.....||
                         |.......|
                         .........


5) 3D Texture Mapped.
	The last style I'm going to cover is texture mapping. So far 
(without making a massive leap with the definition of the genre), no 
roguelike game has ever used texture mapped 3D graphics. I'm sure if 
you visualise a game like Quake, or whatever the current splurge of 
the month is, you'll realise what I'm getting at here.

	One problem with texture mapping is that to get a good 
definition on the walls, floors, etc. the textures need to be of a 
fair size otherwise, close inspection of a wall reveals a horrible 
level of pixelisation. 3D accelerator cards (and a certain console) 
can provide techniques to smooth the textures but now we're getting 
into silly-land. Roguelike game with texture-mapped polygons needing a 
3D accelerator card? Hmm. One day maybe...? ;-)

	Anyway, it's really up to you as to what looks right and at what 
point it stops looking like a wall pattern and more like a bunch of 
large square pixels. Working towards high quality textures means 
bigger textures and even more space taken up by the graphics. 

	Obviously, programming such a view for just a roguelike game
is no small fear either when compared to the original text-mode (or
even the other styles mentioned in this document). How you present 
your 3D environment is up to you. Possible options are the fully
submersing environments of Quake/Mario64. Or you could go for an
isometric display such as Bullfrog's Dungeon Keeper. 

Badly drawn example...   Yeah, right.

                              ----//----      

# Issues

Some problems you might want to take into consideration when working
on your graphics...

# Colour Depth.

	Colour depth is essentially how many colours you're allowed to 
create your wondrous and vivid roguelike graphics. Basically there is 
two camps. The programmers want the less number of colours possible 
and the artists generally want the most. The exception to the 
programmers is when the programmer in question doesn't care how much 
space the game takes or already has the code to handle higher colour 
depths. The exception with artist is when you find an artist who knows 
they can get the same effect with less colours.

	A set of tiles that only use a palette of 16 colours but have 
been stored as in a graphic format that utilises 65,000 colours uses 
up more memory than exactly the same tile set in a format that only 
allows for only 16 colours needed. If your tiles only take up a small 
range of colours, that 16bit (or 24bit) mode could be a waste of time. 
And if you can get beautiful tiles with 16 colours, programmers will 
love you. :)

	Again, it's a balance. Try some test tiles first. If you've got
a list of the tiles needed, experiment with some fairly mis-matched 
sets and see how they stand up to the lower colour depths. If you're 
not happy with how they are working out, move up to the next depth. 
Remember though, an artist may have to compromise the graphics he/she 
creates to work within limits. Do the best you can with the tools 
available and the boundaries you are set.


# Tile Size & Screen Size.

	In a perfect world, all players would have limitless hard-drive 
space, screen-resolutions that stretch into the ten-thousands and 
download the several hundred meg your game takes up in a second. 
Problem is, it  doesn't work like that. Once again, file-size is 
affected by the choice you make over tile sizes. Deciding to expand 
your tiles from 16x16 pixels to 32x32 pixels will increase the file 
space each tiles takes up by 4. If the programming has decided they 
want tiles for each of the five-hundred different flavours of gnome 
they've implemented, we're talking of a big increase.

	Can you do everything you want with 16x16? Can you get all the 
detail you need and is the detail really necessary? In some cases, a 
good artist can 'imply' detail in a very small space. Do you really 
need to see the texture on the knight's chain mail or would a light 
grey mesh give the same impression?

	Another point to take into consideration is the screen size. A 
small screen size and a large tile size could cause trouble and 
restrict the amount of 'dungeon' you can see at one time. Small tiles 
on a huge screen could mean the player has trouble making out the 
tiles and misses out important details. Again - balance.

	See what the programmer wants. How many tiles do they want 
onscreen. Make sure that they understand how big that would allow you 
to make the tiles. A sample screen knocked up in five minutes is 
usually a good visual aid for both you and the programmer. Does it 
look right?

	If there is a lot of other information needed onscreen, the 
amount of screen left over to the level window may be cut down. Make 
sure you take all of that into consideration.


# Resizing or Reducing Colours.

	Okay. You've created all your tiles. Five hundred gnomes of all 
shapes, sizes and colours. All in 64x64 pixel, 24bit colour tiles. The 
programmer gets in touch and tells you that they can't use them. They 
need 16x16, 16 colour. Bugger...

	Well, you've got three choices - call it a day, move to Tibet 
and take up the serene life of a monk or restart from scratch or start 
reducing tile size and colour depth. In the extreme case stated above, 
the reduction is going to pretty much murder your graphics and perhaps 
restarting is the only way to go. In other situations, when you only 
need to reduce the colour depth or just resize, you might just get 
away with it.

	One thing to remember when reducing colours, it always helps to 
choose a good utility/art package. The best way to test this is to use 
it with other graphics first. Choose a picture (maybe a scan of some 
sort) with a fair spread of colours and detail. Reduce the colours. If 
you're coming down from 24bit to 16bit, chances are you won't notice 
the reduction but down to anything less and the package has to create 
it's own palette of used colours.

	Most often, it's a best-fit and most-used kind of technique. 
Some packages offer different methods for reduction and some use a 
dithering algorithms to fool the eye. Sometimes it even works. 
Remember though, you may be reducing the colours of some fairly small 
tiles and when they begin to repeat in the game, the pattern these 
dithered tiles create may become very noticeable. The key to reduction 
is getting a good palette. Again, this depends on the tool you use.

	One thing I have noticed is once your package has reduce the 
colours, it tends to organise the colours in the palette in a manner 
which I find a little 'random'. Personally, I like my colours divided 
up into nice hue sets but after reduction, most packages generate 
light-to-dark range or that bizarre mac-style organisation that I 
dislike so much :) It's a little gripe but remember that if you're 
drawing more tiles after the reduction, finding the exact colour 
you're after may become a pain in the ass.

	Resizing is another matter. Most resizing does cause your tiles 
to lose all their detail and essentially makes touching-up afterwards 
a must. Some packages anti-alias or blur the tiles to cover the loss 
of detail. This is all very nice within the tile but you've got tiles 
with areas that are supposed to be transparent (for overlaying onto 
floor tiles, etc.) then the program tends to blur the edges of the 
shapes and destroy the clean edge you need. A good package will allow 
you turn this off. 


# 1001 Monsters.

	Not just monsters but potions, swords, shields, helmets, 
scrolls, spell-books, traps, walls, floor, stairs, food... well, you 
get the idea. When you think of all the tiles you may be called on to 
draw, you start begin longing for those simple ascii-characters. When 
drawing your tiles, it's always a good start to have some sort of idea 
of how many monsters, etc. will be required. If you need several 
different types of mold (green mold, yellow mold, red mold, blah-blah-
blah), you would probably be able to get away with the same graphic
but with changes to the colour. It saves time and allows you 
concentrate on making the basic mold design stand out from your other 
creatures.

	It is also useful to find a theme within creatures. If you need 
several ranks of orc, maybe changing their size and armour might help. 
If you have a set of monsters that have a specific trait (nether 
beasts, lava beasts), it'll help player recognition if you style those 
creatures similarly. 


# 3D packages.

	All styles can enjoy the benefits that using a 3D package can 
give. For the 2D bitmap tiles, building your objects and monsters with 
a 3D package means that size or colour depth isn't really an issue any 
more. The object you create can be rendered from any angle, at any 
size and with varying amounts of colour (if the package you're using 
is any good in the first place). And because the output is from the 3D 
package itself, outputting a smaller render will generally give a 
better result than trying to reduce the size of the tile with another 
graphics utility. 

	Ofcourse, the amount of work required initially is massively 
increased as you need to model all the objects you wish to show. The 
benefit comes from the flexibility afterwards. For the user wishing to 
create modeled creatures for a Quake-style roguelike, a 3D package is 
essential. I'm sure there are people out there who can quite happily 
create some very good models with a pencil and graph paper but with
so many cheap and shareware modelers on the market, save yourself the 
bother.


# Size matters? 

	Okay, first you're asked to draw a mouse and then you're asked 
for a poison breathing dragon. Do your work in scale? Draw a mouse 
that takes up a tile then draw a dragon that fills half the screen? 
'Course not. If you're drawing a dragon that takes up a tile but a 
mouse in scale would be hard pushed to fill a pixel. It takes some 
getting used to be it's usually a good idea to throw scale out of the 
window. Just pretend that mouse is really, really, really close. :)


# Conclusion.

	As you've probably gathered by now, how you go about creating 
your graphics depends largely on the games needs. If you have been set 
limits either by the programmer or the hardware you're aiming for, 
always experiment to get the best you can from the tools you have 
available. If you're given an open-ended project with no definite 
requirements, planning will save you a lot of work in the long run. 
Decide which colour depth and tile size is best for the game and stick 
with it.

Whatever style you choose, its all a question of whether your 
roguelike needs these graphics. Do they honestly add something to the 
game? Ignore those who automatically scream 'no!' or have built up 
some kind of barrier to considering the option. Graphics are just 
another feature to add to your game. Like everything you add, whether 
it works or not is up to you.