Re: ASCII meets games

Rudy Nacken Wrote:
>Hello, my name is Rudy Nacken and I'm from Holland,
> so sorry about the poor English. I do a lot of programming in >QuickBasic.
Right now, I'm working on a game, especially for the old >XT-pc's. Therefore, I
can't draw lines or set points, and I must use the >ASCII-characters for a 
substitute for gfx. Are there any guys with nice >ASCII-drawing skills who want
to help me? The graphics that I use are >horizontal 8 spaces and vertical 3
spaces. . . <snip>

Hello,

You actually have several options available. I am assuming that since your
targeted hardware are XT's that you are using text mode because you are limited
to it, although hopefully you are able to use the sixteen basic colors (i.e.
the XT's need EGA or CGA video cards). 

If you can't change the color of the characters you are pretty much limited to
rudimentary assignment graphics (that is, this here blotch represents that
there tree etc.). However with the added dimension of color your options
broaden and the effectiveness of the grfx multiplies.

 For example a moving starfield (parallex scrolling) can easily be pulled off
in TEXT MODE by defining four star planes and assigning colors and velocities
to each plane. Use only Darkgray, Gray and White for the colors, make the two
farthest planes Darkgray and with the slowest velocity (movement of say 1 space
per cycle/loop) , the next plane is Gray with a medium velocity (3 spaces per
loop), the final plane and closest plane is white with the fastest velocity(5
spaces). Now to create the moving starfield just create an array of about 150
stars and randomly assign each star to one of the four possible planes (the
plane the star is assigned to determines its color and velocity). Now give each
star an initial X,Y value (asuming text-mode resolution of 80 columns(X) by 40
rows (Y)) run a loop and plot a character at that location in the color defined
by its plane. now increment (or decrement depending on desired direction) each
stars X,Y coordinates according to its velocity (e.g if star.plane = farthest
then X = X + 1), include some errorchecking to make sure you are not trying to
plot a star out of bounds (just reset and wrap around at the edge of the
screen), repeat loop. The result is an animated text star-field that is
virtually identical to a GRAPHIC MODE one with a lot less overhead.

I only go into all that because you said Zelda-like and this algorithm can be
easily modified to emulate rain, snow, etc. You can overlay this concept onto
your (text)tiled background for an added dimension of realism (every bit counts
in text-mode).

Back to the graphics. Using 8x3 tiles obviously limits the detail one can
include but several techniques can be employed. For example to create a grass
tile set the background color to bright green and the foreground color to dark
green. Now every empty space you print will show as bright green and every
character will print as dark green. 

so the following:  "    .    "
                         " .    .   "
                         "   .     ."
should tile out as a green field (tweak it as needed to suit) with dark bits
for depth/texture. Use a similar technique for water, trees, dirt, building
tiles etc.

The sprites (player, monster, items) themselves are gonna be kinda tricky. This
is due to the fact that TEXT-MODE does not easily allow for the utilization of
a transparent color. This means that when the character walks over a
predominately green (such as grass) background you must set the sprites
background color to match, always, otherwise it will end up even chunkier than
text sprites already are. The problem arises when the player is bridging two
areas (such as walking off of the grass and onto the dirt) you'll need some
tight functions/subs to toggle the colors accordingly, otherwise you'll have a
blocky sprite with a strange hue about it. 

On the other hand collision detection should be simplified in TEXT_MODE. Say a
brown arrow is shot at a red target, just check the existing color at the next
plotted location of the fired arrow. If it is red then the target has been hit.

Another option since you mentioned elsewhere that you would be willing to go
beyond pure ASCII and use extended characters, why not go one step further and
temporarily redefine the ROM character set. This will enable you to work on a
bit level for your graphics. since each text character is actually made of of
an 8X8 array of bits (toggled either on or off) this would enable a much
greater level of resolution. In a sense (very loose) you could then work on a
pixel level in TextMode. By making your own temporary (restore original upon
exit) character set you gain an added degree of flexibility. You could then
create text characters that looked much more like a pile of cash then  "$$$"
does.

Anyhow, hope any of this helped. Good luck, it sounds like quite a project. I'd
like to see the results, it seems very interesting.

BTW Don't worry about your English, nobody would know it wasn't your native
tongue if you didn't mention it. Looks fine to me.

][ncogni']['o

Related ASCII art in the Gallery

Explore these categories from our collection of 11,000+ artworks:

  ______
 /|_||_\`.__
(   _    _ _\
=`-(_)--(_)-'
         hjw

   .="=.
 _/.-.-.\_ 
( ( o o ) )
 |/  "  \| 
  \'---'/jgs  
  /`"""`\\ 

 _________
|  _____  |\
| |\ ___| | \
| | |   | | |
| | |___| | |
\ | |____\| |
 \|_________|
 Andy Johnson

  __      _
o'')}____//
 `_/      )
 (_(_/-(_/

[>====]

   ))
 .-#-----.
/_________\
 |[] _ []|
 |  |*|  |

Make your own ASCII art

Turn images, text or 3D into ASCII, or draw your own – right in your browser.