Three Hundred :: Mechanic #171
  Squidi.net Sites:     Webcomics   |   Three Hundred Mechanics   |   Three Hundred Prototypes
 Three Hundred
   - Index Page
   - About...
   - By Year

 Collections
   - Comp-Grid
   - Procedural
   - Tactics
   - Tiny Crawl
   - Misc


 
PreviousMechanic #171Next

  Mechanic #171 - One Line ASCII FPS
Posted: Jan 05, 2014

A first person shooter, rendered entirely in a single line of text. Sort of.


  ASCII FPS

I had challenged myself to come up with game ideas that take place in a single line of ASCII text. I went through a few different genres, like RPGs and adventure games, before realizing that it was largely a problem of information dissemination. You could make a one line RPG easily. It was just a matter of what kind of information you could present at any one time. Ironically, it turned out that the limitations I had set for myself to make something unique just weren't limiting enough.

But during this brainstorming session, I did realize that I could theoretically create a first person shooter in a single line of ASCII. I remember that, back in the day, someone created a text mode filter for Quake, but this is different. This is more like a first person roguelike.

 

[fps1.png]

Fig 171.1 - Pathways Into Darkness.

I realized that when you have a single line of 80 characters, it resembles very much the way that old ray-casting first person shooters worked. Realizing that Wolfenstein 3D is well over twenty years old now, and someone turning 18 now may have never owned a computer without a 3D card, I think I may need a brief explanation of how ray casting works.

Anyway, back before you had OpenGL, 3D graphics was something of a pipe dream for crappy personal computers. John Carmack, when creating Wolfenstein 3D, came up with a somewhat decent approximation of 3D using ray casting. A simple explanation of the process is that for each vertical column of pixels, a ray was shot out from the player and tested where it intersected walls. From this information, we know what column of pixels to draw (early texture mapping) as well as how far away it was (telling up how tall the wall is on the screen, plus how dark it should be if further objects are drawn darker).

I noticed that 80 characters of text is suspiciously similar to 80 columns of pixels, and that ray casting could be used with it to create a sort of ASCII first person shooter. Unfortunately, I don't think I could illustrate this idea without actually writing a program to produce the output, since it is incredibly difficult to figure out perspective with the Photoshop type tool. So, you'll just have to use your imagination for the rest of this entry.

- Each column of characters is a vertical column of the viewport. A ray is cat out for each one, and from that information, we know which character it will be, how dark it will be based on distance, and how large it will be.

- Characters should be centered vertically on the line, which means this isn't strictly a console-style output. However, you can still set the color and font size for the majority of the work. If you don't want to center each character, you could use two lines (one bottom justified, the other top justified), where the horizon is the space between each line. And if you want to go purely text, you could just use a dozen or so lines of uniform scale, and just fill them out accordingly (but at that point, the ASCII just becomes glorified pixels - it's much more interesting with only a single line of characters).

- When the characters change height, they also grow in width. Results may work better if letters are stretched vertically (or squished horizontally) in order to maintain a strict column width.

- Entities on the world are just words. For instance, you can find a [chair]. Because each vertical slice is limited to a single character, you can make the object larger and closer by spreading it out ([c   h   a   i   r]), but to make it further away, you need to drop letters. So in the distance, you might see a [chr] or a [c].

- Using variable colors would help with objects that overlap, such as a [ch[badguy]

- The ASCII characters are more a coarse pattern than individual wall segments. There's no perspective deformation on the characters and a single character could represent only a portion of an entire wall. However, if you set the perspective ahead of time to a strict block-move situation (like Dungeon Keeper), you could emulate a one-ASCII-one-wall format, I would think

 

 





Copyright 2007-2014 Sean Howard. All rights reserved.