A text-style game is a common project for beginner programmers. These can be fun to do, but also require spending time up-front to design it is worthwhile. Before you start designing your own game, look at the design decisions of a few different text-style game genres.

Text Adventures

Also known as interactive fiction or IF, a text adventure game were the first incarnations of these types of games. They are single-player, turn-based (the game paused while the player typed in commands), and presented the user with an English text description of each room the player was in. The player was often a single character with an inventory of items picked up in the rooms. Commands were simple English phrases like "open door" or "get lamp".

West of House
You are standing in an open field west
of a white house, with a boarded front
door.
There is a small mailbox here.
> open mailbox

While the player could die, often the player did not have stats such as hit points, money, or experience points. Text adventures are puzzle-based (such as finding different rooms or figuring out which items to use where), rather than based on progressing in stats or levels.

Text adventure games are more than just "Choose Your Own Adventure" programs, because they take place in open sandbox worlds that the player can freely explore.

These are the simplest types of games to make. In fact, you don't even need a real programming language to make one of these games. There is software specifically for creating text adventure games.

The 1993 hit Myst is an example of a graphical version of this genre. These games became more sophisticated with the graphic adventure game genre (or "point-and-click adventure games"), the most notable coming from LucasArts. Specialized software for making graphic adventure games also exists, chief of which is Adventure Game Studio.

• Single-player
• Turn-based
• Player directly controls a single character
• English text descriptions (not ASCII art)
• English phrases for commands
• Inventory
• No stats or levels
• Puzzle-based and role-playing story elements

Multi-User Dungeons

A MUD (also sometimes called a Multi-User Dimension) was a multiplayer form of text adventures that incorporated hack-and-slash combat. Players connected to a server with telnet client software. Although MUDs still had English text descriptions for rooms and accepted English phrase commands, the games were in real-time: things could happen while you were typing in commands. Players controlled a single character that moved around an open sandbox world, fighting monsters and leveling up. Players could also treat the game as a large chat room to talk to each other.

Because many things could be happening at once, most MUDs made use of colorful text to make the descriptions easier to read (for example, room descriptions in gray, items in the room in white, chat messages in red, etc.)

MUDs still exist today and are often free to play. The Mud Connector is site with a large list of still-active MUD servers.

A Cage
[Exits: north south up]
There is a wimpy goblin here.
kill goblin
Your pierce hits the wimpy goblin.
The wimpy goblin is slain by a final deadly stab.
You receive 170 experience points.
You hear the wimpy goblin's death cry.
You get a metal helmet from the perforated corpse of the wimpy goblin.

MUDs are a bit more difficult to program since they require network programming (and all the concurrency issues that come with that). Although it is entirely possible to create a single-player, turn-based MUD (which is essentially a hack-and-slash text adventure).

Modern MMORPGs such as World of Warcraft are the graphical equivalents of MUDs.

• Multiplayer
• Real-time
• Player directly controls a single character
• Colorful text
• English text descriptions (not ASCII art)
• English phrases for commands
• Centered around advancing stats/levels and acquiring money/items

Roguelikes

Roguelikes get their name from the UNIX game Rogue. Roguelikes dropped the English-based commands and descriptions for rooms. Instead, ASCII art (in which text characters represent objects and are used for simple line drawing) took their place. Commands were done using single-key presses (hotkeys) or menus to do things such as moving the character around the room.

Most roguelikes are single-player and turn-based, but do not necessarily have to be. The player still controlled a single character (often represented by a @ symbol). Colorful text was used to differentiate between different types of things displayed on the map.

 ------                             -  Wall
 |....|      ############           #  Unlit hallway
 |....|      #          #           .  Lit area
 |.$..+########         #           $  Some quantity of gold
 |....|       #      ---+---        +  A door
 ------       #      |.....|        |  Wall
              #      |.!...|        !  A magic potion
              #      |.....|
              #      |..@..|        @  The adventurer
   ----       #      |.....|
   |..|       #######+..D..|        D  A red dragon
   |<.+###    #      |.....|        <  Stairs to a higher level
   ----  #    #      |.?...|        ?  A magic scroll
         ######      -------

Gameplay was centered around hack-and-slash and progressing in levels and items by fighting monsters in dungeons. Since the rooms were not created with English descriptions but rather ASCII art, roguelikes had procedurally-generated levels that were unique (although formulaic) each time the player started a game.

Because there is an actual geometry and space for the map (as opposed to a MUD's English description), "line of sight" calculations become a factor for what the player and dungeon monsters can perceive. Rather than display the full map, a "fog of war" might shroud unexplored areas.

Other aspects of roguelikes: "pets" that would follow you and attack nearby monsters, permanent-death, and magical items that are initially unidentified. (These also commonly appear in MUDs.)

Because the text characters are easily interchangeable with simple tile graphics, graphical roguelikes are also available. The Diablo games are graphical, real-time modern equivalents of roguelikes.

• Single-player
• Real-time
• Player directly controls a single character
• ASCII art
• Hotkeys/menus for input
• Centered around advancing stats/levels and acquiring money/items

Dwarf Fortress

Dwarf Fortress is a single game (rather than a genre) first released in 2006 programmed solely by Tarn Adam. It uses procedural generation to create an entire game world, along with history, lore, and natural resources. It extensively uses ASCII art and colors and looks like a roguelike except with a much more extensive system of menus and screens.

The player controls a entire tribe of semi-autonomous dwarves (each with a unique name, personality traits, skills, and stats) as they build a fortress and try to survive. The learning curve is incredibly steep for this game due to the complexity of its simulation. It is a single-player game that runs in real-time.

Dwarf Fortress is a monstrously complicated game, so programming something like it would not be too difficult so much as the large amount of design needed.

• Single-player
• Real-time (but can be paused since it is single-player)
• Player indirectly controls several autonomous dwarves
• ASCII art
• Hotkeys and menus for input
• City-building and simulation genre

Creating Your Own Text-Style Game

The largest advantage to creating a text-style game is that you do not need to be a good artist or spend time acquiring graphic assets for your game. However, these games still require design work to be done beforehand, along with decisions about how the gameplay should work.

When making your own game, consider between the following design decisions:

1. Single-player or multiplayer. Single-player is easier but multiplayer is more fun and social. Multiplayer requires learning network programming.
2. Turn-based or real-time. Turn-based is easier, but real-time is often more fun. Single-player games can be turn-based or real-time (with pausing and controllable time-speed) but multiplayer games almost always must be real-time (adding to their programming difficulty).
3. English descriptions or ASCII art. Writing English descriptions is easy, but it requires a lot of work to create an expansive game world. Using ASCII art to draw out worlds is also easy-but-a-lot-of-work, however you can use procedural generation algorithms to automatically create large, unique (but formulaic and often repetitive) worlds, monsters, and characters.
4. English commands or hotkeys/menus. Typing an English command like "get lamp" or "say 'Hello' to elf" offers a richer way to engage with the game, although it can also be opaque at times. (And nothing is more frustrating than constantly reading, "I did not understand that command.") While hotkeys and menus are more limited, they are also more obvious. Games with story and role-playing are often better suited for English commands, while hack-and-slash games use hotkeys and menus.
5. Story-base or hack-and-slash. Story-based games require more design work, and players may or may not like the story and writing. Hack-and-slash games are simple, but can become repetitive.
6. Player directly or indirectly controls one or multiple characters. The player can either directly control the movements of one or more characters, or indirectly give instructions. Indirect control requires more complicated AI for the characters but makes it easy to control multiple characters by issuing orders and letting the character carry them out.
7. Monochrome or colorful text. Colorful text is almost always better, but might require the use of a curses library to program this.
8. Puzzles or stats-progression Similar to story-versus-hack-and-slash, puzzles require more design which the players may or may not end up liking. Stats-progression games where the player acquires better weapons or advances in levels can be fun but also repetitive.

Game design is all about decisions and trade-offs, but knowing what these choices are gives a hobbyist programmer more insight as to what's been done, and what can be possible.