Few game concepts are as immediately readable as Frogger. You look at it for three seconds and you know exactly what to do. Cross the road, don't get hit. Cross the river, don't fall in. Make it home. Byte Hopper is a terminal reimagining of that idea — written in C with ncurses, playable in your terminal, and just as punishing as you remember.

The Original: A Brief History of Frogger

Frogger was released to arcades in 1981, developed by Konami and distributed in North America by Sega/Gremlin. The designer was Akira Hashimoto, and the concept was deceptively simple: guide a frog across five lanes of traffic, then across five lanes of river, and land safely in one of five lily pad homes at the top.

What made it stand out in 1981 wasn't just the gameplay — it was the tone. Arcades at the time were dominated by shooters: Space Invaders, Galaga, Defender. Frogger brought no weapons, no aliens, no lasers. Just a frog, a road, and a river. It was immediately approachable and quietly brutal, and players responded to it. Within a year it had become one of the highest grossing arcade games of the era.

The game was also technically notable for being one of the first arcade titles to use stereo sound, with separate audio channels driving left and right speaker outputs. The music — a looping, slightly manic march — became one of the more recognizable earworms of the arcade generation.

The Home Port Era

Parker Brothers licensed Frogger for home consoles and computers starting in 1982, and the ports landed everywhere: Atari 2600, Atari 8-bit, ColecoVision, Intellivision, Apple II, Commodore 64, TRS-80, and IBM PC. The Atari 2600 version alone sold over four million copies, making it one of the best selling cartridges of that generation. The ColecoVision port was widely considered the most faithful to the arcade original.

A sequel, Frogger II: Threedeep!, arrived in 1984, adding underwater and sky zones to the classic crossing formula. But the original structure never needed much improving. The "cross the obstacle field" mechanic was already complete.

The Long Shadow

Frogger's influence on game design is hard to overstate. The game essentially defined a genre: take a fixed grid, populate it with hazards moving on fixed paths, and make the player navigate through them without being destroyed. Dozens of games borrowed from this template across the following decades, including the mobile hit Crossy Road in 2014, which runs the same concept in an endless procedurally generated world.

In 1998, Frogger made a brief cultural cameo in the Seinfeld episode "The Frogger", in which George Costanza attempts to preserve a high score on an arcade machine by transporting it across a New York street — recreating, in real life, the exact scenario the game is built around.

Konami has revisited the IP several times over the years, with the most recent major release being Frogger in Toy Town for Apple Arcade in 2020. The core idea, though, remains unchanged from 1981.

What is Byte Hopper?

Byte Hopper is a from scratch terminal implementation of the Frogger concept, written in C using the ncurses library. It runs entirely in the terminal, targets a minimal 80×15 screen, and reconstructs the classic two-zone crossing structure: a road to dodge, a river to cross, and five lily pads to fill.

It's a clean, self contained project — four source files, a header, and a Makefile — built with the kind of simplicity that makes it easy to read and easy to extend.

Gameplay

The board is divided into four distinct zones, read bottom to top:

• Starting zone — safe ground where the frog spawns
• Road zone — five lanes of cars and trucks moving at different speeds in alternating directions
• Median strip — safe ground between the two hazard zones
• River zone — five lanes of logs and turtles; the frog must ride platforms or it drowns
• Home row — five lily pads at the top; fill all five to complete the level

The road is a test of timing. The river is a different kind of problem — you're not just avoiding obstacles, you're riding them. Logs and turtles drift continuously, and the frog drifts with them. Ride something off the edge of the screen and you're gone. Stand in the water for a single frame and you're gone. The river is where Frogger's design is most interesting, and Byte Hopper preserves that faithfully.

Scoring:

Progressive Difficulty

Byte Hopper scales with each level cleared. Vehicle and platform speeds increase by 12% per level, capped at 2.5× the base speed. Every three levels, additional obstacles spawn into each lane. The game gets meaningfully harder without becoming chaotic — by level five or six you'll be working for every crossing.

Building Byte Hopper

The project requires a C compiler (clang or gcc), ncurses, and make.

Install ncurses

# macOS
brew install ncurses

# Debian / Ubuntu / Mint
sudo apt install libncurses-dev

# Fedora / RHEL / Rocky
sudo dnf install ncurses-devel

# Arch Linux
sudo pacman -S ncurses

Build and Run

git clone <repo>
cd c_frogger

# Debug build (default)
make

# Optimized release build
make release

# Run directly
./build/byte-hopper

# Or build and run in one step
make run

The binary lands in build/. The game requires a terminal at least 80 columns wide and 15 rows tall.

Install System-Wide

# Install to /usr/local/bin
sudo make install

# Or install to a custom prefix
make install PREFIX=$HOME/.local

# Uninstall
sudo make uninstall

Controls

A Few Technical Details

Byte Hopper uses fractional position accumulation to handle platform drift. Because log and turtle speeds are sub integer (values like 0.2 or 0.35 columns per tick), the frog's horizontal offset accumulates as a float and only commits to a whole column when the fractional part crosses a threshold. This means the frog stays glued to its platform smoothly even at slow speeds, without any snapping or jitter.

Wrapping collision detection handles objects that span the screen edge — a log that's half off the right side is checked as continuing from the left, which keeps the river zone consistent as platforms cycle endlessly through.

When the frog is killed, a death animation runs for a brief window: the frog sprite flashes as a red * while the rest of the board keeps moving. The hazards don't pause for you, which adds a small additional tension to every respawn.

High scores are persistent, stored in ~/.local/share/byte_hopper/highscores.dat (respecting XDG_DATA_HOME if set). The top 10 scores are shown on the start screen. When you earn a spot, the game prompts for a name — up to 15 characters, no spaces. If you skip it, the entry saves as ANON.

Why Play Byte Hopper?

Frogger's design has aged remarkably well, and Byte Hopper is a good argument for why. There's nothing to learn beyond the first ten seconds, but there's plenty to get better at. The road zone rewards patience. The river zone rewards spatial awareness. Filling all five lily pads cleanly — before the timer, without trapping yourself in a bad position — feels satisfying every time.

It also runs in a terminal, which means it's available everywhere and launches in under a second. That's the whole pitch.

Source: github.com/termplay/byte-hopper

There is a particular kind of pressure that only real-time terminal games can generate. No graphics, no sound design, just a grid of letters crawling across a screen and the growing certainty that you are about to cause a mid-air collision. atc (Air Traffic Controller) is that game. It has been running on Unix systems since the late 1980s, and it remains as stressful and as good as it ever was.

What is atc?

atc is a real-time air traffic control simulation for the terminal. You manage a radar screen full of aircraft: jets and propeller planes entering from the edges of the map, heading for destinations (other exits or airports), and depending entirely on you to get them there safely. You issue commands to change their altitude and heading. The game never pauses. Planes pile up. Fuel runs out. Two letters converge on the same cell.

There is no winning state. The goal is simply to keep going as long as possible, to safely direct as many aircraft as possible before something goes wrong.

History and Background

atc was written by Ed James at the University of California, Berkeley in the late 1980s (copyright 1990). James described it as an adaptation of an unknown PC game he'd encountered, rewritten as a Unix terminal game. His contact at the time was edjames@ucbvax.berkeley.edu the classic UCB VAX address.

The game was distributed as part of BSD Unix and has been carried forward ever since through the bsd-games (also packaged as bsdgames) collection, a set of around 50 classic text-mode games originally from NetBSD, now maintained and ported to Linux. The Linux port used in most distributions is maintained in the vattam/BSDGames GitHub repository. The canonical BSD version continues in OpenBSD's and NetBSD's game trees.

The bsd-games package has been around in Linux distributions since at least the mid-1990s. Current versions are 2.17 (the long-standing Linux port, found in Debian/Ubuntu/Fedora) and 3.3 (a newer revision found in Arch, Alpine, and MacPorts).

Installing atc

Linux

atc ships inside the bsd-games (or bsdgames) package on virtually every major Linux distribution.

# Debian / Ubuntu / Raspbian / Kali
sudo apt install bsdgames

# Fedora / RHEL / Rocky / AlmaLinux
sudo dnf install bsd-games

# Arch Linux / Manjaro / Artix / Parabola
sudo pacman -S bsd-games

# Alpine Linux
apk add bsd-games

# Gentoo
emerge games-misc/bsd-games

# openSUSE
sudo zypper install bsd-games

# Void Linux
xbps-install bsd-games

# Slackware
# Available from SlackBuilds.org as bsd-games

After installing, run it with:

atc

macOS

The easiest route is MacPorts, which carries bsd-games 3.3:

sudo port install bsd-games

Alternatively, you can build from source. The game depends on ncurses, which is present on macOS.

From Source

git clone https://github.com/vattam/BSDGames
cd BSDGames
./configure
make
sudo make install

On OpenBSD and NetBSD, atc is part of the base system and requires no installation.

The Display

When you start atc, the screen is divided into four areas:

1. Radar Display (the large grid on the left) This is the main playing field. It shows the airspace as a 2D overhead view. On it you will see:

• Planes: a letter (uppercase = prop, lowercase = jet) followed by a single digit indicating altitude in thousands of feet. Example: A7 is prop plane A at 7,000 ft; b4 is jet b at 4,000 ft.
• Airports: a digit (the airport number) followed by a directional symbol (^ > v <) indicating the required approach direction. Example: 0> is airport 0, approached from the west (landing heading east).
• Beacons: an asterisk or circle character followed by a number. Example: *1 is beacon 1.
• Exit points: numbers along the border of the map, each representing an entry/exit point.
• Lines: drawn segments (horizontal, vertical, and exactly diagonal) that serve as visual reference guides for routing aircraft. They represent suggested airways.

2. Information Area (right side, upper) A live list of all active planes. Each line shows:

<plane-id><altitude>[*] <destination>: <current command>

The * after the altitude means the plane is low on fuel. Example:

B4*A0: Circle @ b1

This reads: Prop plane B, at 4,000 ft, low on fuel, destination is airport 0, currently circling at beacon 1.

Also shown: elapsed game time and the count of planes safely directed out.

3. Input Area (bottom) Echoes your current command as you type it.

4. Author Area (small credit section)

Aircraft: Jets vs. Props

There are two types of aircraft, and the distinction matters for timing:

• Prop planes: identified by uppercase letters (A, B, C…). They move every other game update - slower.
• Jets: identified by lowercase letters (a, b, c…). They move every game update - faster.

Both types:

• Enter the airspace at 7,000 feet
• Must reach 9,000 feet to exit through an exit point
• Must descend to 0 feet to land at an airport (and be directly over it)
• Can turn a maximum of 90 degrees per move

Fuel: every plane has a fuel supply that depletes each turn. When fuel runs low, an asterisk appears next to the plane's altitude in the info panel. If fuel hits zero, the plane is lost. You must keep planes moving toward their destination.

Collision: two planes are considered to have collided if they occupy adjacent cells in three dimensions, horizontally adjacent on the grid or within one altitude level of each other. This is stricter than it might look. Two planes at the same (x,y) position but at altitudes 4 and 5 are colliding. Two planes at different altitudes but adjacent grid squares can also collide.

Destinations and Safe Handling

Every plane that enters has a destination, either an exit point or an airport. The destination is shown in the info panel. A plane is safely handled when it reaches its destination correctly:

• Exit point: the plane must pass through the correct exit at exactly 9,000 feet (altitude 9). The direction it's heading when it crosses the exit boundary doesn't matter, only that it exits through the right numbered exit at the right altitude.
• Airport: the plane must be at altitude 0 and positioned directly over the airport, moving in the correct landing direction (shown by the directional arrow on the airport).

Losing conditions:

• A plane collides with another plane
• A plane runs out of fuel
• A plane is sent to the wrong destination (lands at the wrong airport, exits from the wrong exit)
• A plane drops to altitude 0 while not directly over an airport
• A plane exceeds altitude 9 (ceiling violation)
• A plane drifts off the map without going through its correct exit

Planes that are on the ground at an airport (altitude 0) are waiting for takeoff. The only valid command for a grounded plane is to increase its altitude, this is how you launch it.

Command Syntax

This is where atc gets interesting. Commands follow a strict hierarchical syntax with a state-machine parser. The input area shows your command as you build it character by character. Pressing ? at any point lists valid next characters. Pressing backspace erases the last character. Pressing Return submits the command.

Commands are rejected if they are semantically invalid (e.g., telling a plane to climb to its current altitude, or giving an airport command to a plane that's already airborne in normal mode).

Step 1: Select a Plane

Type the plane's letter. Uppercase for props, lowercase for jets. Example: A selects prop plane A, b selects jet b.

Step 2: Choose a Command

After selecting a plane, type one of:

Altitude Command (a)

Altitude commands are immediate only, they take effect on the next update. After a, type one of:

Examples:

• Aa9 — Set plane A to altitude 9,000 ft
• Aa0 — Set plane A to altitude 0 (land, if over an airport)
• Aac2 — Climb plane A by 2,000 ft
• Aad3 — Descend plane A by 3,000 ft

Turn Command (t)

Turns are delayable (more on delay below). After t, type one of:

The direction keys (w e d c x z a q) are arranged around the s key on a QWERTY keyboard to form a compass rose:

q w e
a   d
z x c

The "turn towards" sub-command (tt) is very useful. After tt, type:

Example: Attb1 — turn plane A towards beacon 1.

Circle Command (c)

Puts the plane into a circular holding pattern. After c, optionally type:

If you just type c and hit Return, the plane circles clockwise.

Delay Modifier (@ or a)

This is the most powerful feature of the command system. Any delayable command (t, c, and the "towards" variants) can include a delay that tells the plane to wait until it reaches a specific beacon before executing.

After typing a delayable command (but before pressing Return), type @ or a, then b (for beacon), then the beacon number.

Syntax: [plane][command][@/a][b][beacon-number]

Examples:

• Atlab1 — Plane A: turn left, but do it when reaching beacon 1
• Bcrab2 — Plane B: circle (clockwise), execute at beacon 2
• gtte4ab2 — Plane g: turn towards exit 4, execute at beacon 2

The delayed command appears in the information panel next to the plane's status. When the plane reaches the specified beacon, the command fires automatically.

Mark, Unmark, Ignore

• [plane]m — Mark: highlights the plane prominently in the display. Useful to keep an eye on a specific aircraft.
• [plane]i — Ignore: de-emphasizes the plane (shown with dashed representation). Good for planes that are on a clear, safe path and don't need attention.
• [plane]u — Unmark: like ignore, but the plane becomes highlighted again automatically when a delayed command fires — a useful combination with delay.

Special Keys (Outside Commands)

Note: suspending the game (Ctrl-Z) is disabled. The game runs in real time and can't be paused.

Full Command Examples

Scoring

The score system is straightforward:

• Primary metric: number of planes safely directed out of the airspace. A plane counts as "safe" when it correctly reaches its destination (right exit at altitude 9, or correct airport with correct approach direction).
• Tiebreaker: if two players have the same number of planes saved, the one who ran the game longer (in real time and game time) wins.
• Other statistics (radar updates, wall-clock time) are displayed but are "merely for fun" per the man page.

High scores are stored in /var/games/atc_score (Linux) or $HOME/.atc.scores depending on the system. The scoreboard records player name, hostname, game scenario played, number of planes saved, and both game duration and real elapsed time.

To view the high score table:

atc -s

Game Scenarios / Maps

atc ships with a set of built-in game scenarios, each defining a different map with different airport counts, beacon placements, exit positions, dimensions, and difficulty tuning. The available games are listed in /usr/share/games/atc/Game_List (or the equivalent path on your system).

To list available games:

atc -l

To play a specific game:

atc -g default
atc -f OHare

Built-in Scenarios

Killer deserves a special mention: with a 1-second update rate and new planes arriving constantly, it is brutally difficult. The standard difficulty range runs from easy up through default, with Killer at the extreme end.

Custom Scenarios

You can write your own scenario files. A game file has two sections: a parameters block and an elements block.

Parameter syntax (semicolon-terminated):

update = 5;
newplane = 10;
width = 30;
height = 21;

Element syntax (semicolon-terminated, # for comments):

exit: ( x y direction ) ... ;
beacon: ( x y ) ... ;
airport: ( x y direction ) ... ;
line: [ ( x1 y1 ) ( x2 y2 ) ] ... ;

Direction codes use the same compass-key layout as commands (w=N, e=NE, d=E, c=SE, x=S, z=SW, a=W, q=NW).

Constraints:

• Exits must be on the border of the map
• Airports and beacons must be inside the borders
• Lines must be horizontal, vertical, or exactly 45-degree diagonal
• Coordinates range from 0 to width−1 and 0 to height−1

To use a custom scenario, add it to Game_List, otherwise it won't be tracked in the high score file.

Command-Line Options

atc           Start with the default game
atc -l        List all available game scenarios
atc -g NAME   Play the named game scenario
atc -f NAME   Same as -g
atc -r SEED   Set random seed (for replay / reproducibility)
atc -s        Display the high score list
atc -t        Same as -s
atc -p        Print the path to the game data directory
atc -q        Play without sound (on systems that have it)
atc -?        Print usage / help

Game Files Location

The man page is at man 6 atc on most systems. Read it with:

man 6 atc

Tips and Strategies

Start with easy or novice. The small map on easy gives you time to learn the command syntax without being overwhelmed. Novice has a clean symmetric layout that makes routing intuitive.

atc -g easy
atc -g novice

Use the delay system heavily. The @/a delay modifier is what separates casual play from effective play. Instead of watching a plane and manually turning it when it reaches a beacon, you can issue the turn command in advance: Atlab1 (turn A left at beacon 1). This frees your attention for other aircraft.

Use circle to buy time. When you have a plane that's converging toward a conflict and you can't sort it out immediately, put it in a circle (Ac). It'll hold in place, burning fuel but not crashing. Use this as a stall tactic while you handle higher-priority traffic.

Altitude is your primary separation tool. Two planes can safely occupy the same grid square if they're more than one altitude unit apart. When two planes are converging on the same path, stagger their altitudes rather than trying to route them around each other. A two-unit altitude difference is safe.

Watch the fuel indicators. The * in the info panel means a plane is at low fuel (below 15 units). Prioritize those planes immediately. Route them directly to their destination without delays.

Use mark/ignore to manage attention. Mark (m) planes that need watching. Ignore (i) planes that are safely on course. The visual de-emphasis helps you focus on what matters. Use unmark (u) with a delayed command so the plane re-highlights when the command fires.

Jets are harder to manage. Because jets move every update while props move every other update, jets cross the map faster, arrive at conflicts sooner, and give you less time to react. Pay closer attention to lowercase-letter aircraft.

Don't let planes exit through the wrong exit. This is an immediate game-over condition. Make sure you know each plane's destination before routing it. The destination is always shown in the info panel.

Landing requires exact positioning. A plane must be at altitude 0 AND directly over the airport AND moving in the correct approach direction all at once. Set up the approach from a distance, descend gradually and align with the runway heading well before the airport. Landing in the wrong direction at the right airport is still a loss.

Empty Return = time skip. If you need to quickly advance to the next update (e.g., to see where a fast-moving situation goes), press Return with no command typed. Use sparingly.

Ctrl-L fixes screen corruption. If your display gets garbled (which happens in some terminal emulators), Ctrl-L forces a full redraw.

Known Bugs

The BUGS file in the source records a few known issues:

• The log file restarts if interrupted
• The screen sometimes refreshes after you have quit (the original author's own note)
• Ctrl-Z (suspend) is disabled but the behavior of this may vary by system
• The process doesn't exit cleanly after a SIGHUP

These are minor and don't affect normal gameplay.

Why atc Holds Up

atc is an old game in every sense. Its author's email address ended in .berkeley.edu. Its graphics are ASCII characters. Its sound support is a terminal bell. It has one known bug that the original author documented himself in 1990 and which still ships in the BUGS file today.

And yet it's a genuinely difficult, genuinely interesting real-time management game. The command syntax, while initially cryptic, is actually efficient once internalized. The delay system in particular is elegant design: it lets you think ahead and pre-program aircraft behavior, which is exactly the kind of forward planning that real traffic management requires.

It also scales naturally in difficulty through its scenarios and update rate. easy is forgiving enough to learn on. Killer is punishing enough that achieving any meaningful score on it is an accomplishment.

If you have bsd-games installed, atc is already on your system. It's worth at least one session.

Man page: man 6 atc Source: https://github.com/vattam/BSDGames/tree/master/atc OpenBSD man page: https://man.openbsd.org/atc.6 FreeBSD man page: https://man.freebsd.org/cgi/man.cgi?query=atc&sektion=6

If you've ever wanted a game that rewards careful thinking but punishes you for being too clever, Greed is it. It's a deceptively simple terminal strategy game where the goal is to consume as much of the board as possible, without trapping yourself in the process.

What is Greed?

Greed is a curses-based terminal game originally written for Unix by Matt Day in 1996, adapted from a DOS freeware game of the same name. After Day stepped away from the project, Eric S. Raymond (ESR, author of The Cathedral and the Bazaar and longtime Unix toolsmith) adopted it, added color support, and continues to maintain it today. The current stable version is 4.3, released under the BSD 2-Clause license.

The concept is razor thin: you sit in the middle of a 79×22 grid packed with random digits 1–9. You move in one of eight directions. The number you land on determines how far you travel — and every cell you pass through gets consumed. The game ends when you can't move anywhere. Your score is how many cells you've eaten.

Gameplay

The rules take about thirty seconds to learn. The strategy takes much longer to master.

• The board starts full of random digits 1–9
• Your position is marked @
• Each move you pick a direction (any of 8, including diagonals)
• You travel exactly N cells in that direction, where N is the digit in the first cell you'd enter
• Every cell along the path is erased
• You can't move off the board or into already consumed space
• When no legal move exists in any direction, the game is over

The tension comes from how quickly you can corner yourself. A high digit might eat a satisfying chunk of the board, but it can also wall you off from the remaining space. Low digits give you precision but less score. Every move is a small gamble.

Toggling the move highlight mode (press p) will show you which directions are currently legal — useful when you're trying to identify the least bad option before it disappears.

Installing Greed

Linux

Greed is packaged in most major distributions:

# Debian / Ubuntu / Mint
sudo apt install greed

# Fedora / RHEL / Rocky / AlmaLinux
sudo dnf install greed

# Arch Linux
sudo pacman -S greed

From source:

The canonical source lives on GitLab, maintained by ESR:

git clone https://gitlab.com/esr/greed
cd greed
make
sudo make install

macOS

Using Homebrew:

brew install greed

Keybindings

Greed supports three control schemes simultaneously, so you can use whatever feels natural:

The numeric keypad works for all 8 directions as well.

A Few Extra Tricks

Color output is configurable via the GREEDOPTS environment variable. It takes a 9-character string where each character maps to a color for digits 1–9. For example:

export GREEDOPTS="rGcYbMwCg:p"

Appending :p to GREEDOPTS enables move highlighting from the start, which is handy if you always want it on.

High scores are stored at /var/games/greed/greed.hs — so there's a real scoreboard if you're playing on a shared system.

Why Play Greed?

Greed is the kind of game that fits perfectly into the two minutes before a build finishes. It's fast to start, fast to lose, and just complex enough that you'll immediately want a rematch to try a different approach. There's no randomized luck in how the board unfolds — the digits are set at the start. Every loss is a bad decision somewhere, which makes it oddly satisfying to keep going back.

It's also a good reminder that in the terminal, you don't need much to make something compelling.

Project page: http://www.catb.org/~esr/greed/ Source: https://gitlab.com/esr/greed

If you've ever wanted to chomp ghosts without leaving your terminal, MyMan is the game for you. It's a faithful text-mode recreation of Namco's classic Pac-Man, running entirely in your console using curses — no GUI required.

What is MyMan?

MyMan is an open source, MIT-licensed terminal game written in C. It brings the full Pac-Man experience — dots, power pellets, ghosts, and mazes — to color and monochrome text terminals. It earned a SourceForge Community Choice badge after crossing 10,000 downloads, which speaks to how much terminal gaming enthusiasts have embraced it.

Beyond being a fun game, MyMan is impressively portable. It supports an extensive list of display backends:

• curses/ncurses — the standard terminal UI library on Linux/macOS
• PDcurses / XCurses — Windows and X11 variants
• aalib / libcaca — ASCII art rendering libraries
• Allegro / GGI — graphical backends
• Carbon — native macOS output
• Win32 console, VMS console, and more

This means MyMan can run almost anywhere you can get a shell.

Gameplay

The rules are classic Pac-Man:

• Navigate the maze eating all the dots to advance to the next level
• Avoid the ghosts — they'll cost you a life
• Eat a power pellet to temporarily turn the tables and hunt the ghosts yourself
• Chase high scores across increasingly difficult levels

The text-mode rendering is surprisingly charming. Characters and block elements stand in for the sprites, and on a color terminal it looks exactly like what it is: a love letter to arcade gaming.

Installing MyMan

Linux

From source (recommended):

MyMan's source tarball is available from SourceForge. You'll need ncurses development headers and a C compiler.

# Install dependencies (Debian/Ubuntu)
sudo apt-get install build-essential libncurses5-dev

# Fedora/RHEL
sudo dnf install gcc ncurses-devel

# Arch Linux
sudo pacman -S base-devel ncurses

Download the latest source from SourceForge and build:

tar xzf myman-*.tar.gz
cd myman-*/
./configure
make
sudo make install

Then launch it:

myman

Arch Linux (AUR):

yay -S myman
# or
paru -S myman

macOS

Using Homebrew:

brew install myman

If it's not in the main tap, install from source. You'll need Xcode command-line tools and ncurses:

xcode-select --install
brew install ncurses

tar xzf myman-*.tar.gz
cd myman-*/
./configure
make
sudo make install

On modern macOS you may need to tell configure where Homebrew's ncurses lives:

./configure CPPFLAGS="-I$(brew --prefix ncurses)/include" \
            LDFLAGS="-L$(brew --prefix ncurses)/lib"
make
sudo make install

Keybindings

Why Play MyMan?

There's something deeply satisfying about playing an arcade classic in the same environment where you compile code and push commits. MyMan is lightweight, requires no X server, works over SSH, and is a perfect five-minute distraction between tasks. It's retro gaming at its most minimal — and most charming.

Project page: https://myman.sourceforge.io

Some terminal games try to recreate twitch arcade experiences. Cavez of Phear takes a different approach — it's a slow-burn puzzle game about caves, diamonds, rolling boulders, and the ever-present threat of being crushed or eaten. If you ever played Boulder Dash or Digger, you'll feel right at home.

What is Cavez of Phear?

Cavez of Phear is an open source Boulder Dash-style game for consoles and terminals. The goal is simple: collect all the diamonds in each cave level to advance toward freedom. The execution, however, involves careful planning — boulders roll, monsters roam, and a single wrong move can bring the ceiling down on you.

The game was originally created by Tom Rune Flo (v0.5.1, 2011) and is currently maintained by Dmitry Marakasov (AMDmi3). The latest release is 0.6.2, published in September 2025. It's licensed under the GNU General Public License v3.

Gameplay

You navigate underground caverns using the arrow keys, digging through dirt and collecting items:

Collect all the diamonds in a level to unlock the exit to the next cave. Earn an extra life for every 1,000 points scored.

The twist: physics. Boulders and stones obey gravity — they roll off rounded surfaces and fall when unsupported. Dig carelessly and you'll get crushed. The bombs add another layer: pick them up, place them with b, and detonate everything at once with t. Bombs are also subject to physics, so placement matters.

Controls

Built-in Level Editor

Cavez of Phear ships with a map editor. Launch it with:

phear -e <mapfile>

Use numeric keys to place objects and build your own caves. Great for sharing custom levels.

Installing Cavez of Phear

The game is built with CMake and written in C, so it compiles cleanly on any Unix-like system.

Linux

From your package manager:

# Debian/Ubuntu
sudo apt-get install cavezofphear

# Arch Linux (AUR)
yay -S cavezofphear

# Fedora
sudo dnf install cavezofphear

Build from source:

Install the dependencies first:

# Debian/Ubuntu
sudo apt-get install cmake gcc libncurses5-dev

# Fedora/RHEL
sudo dnf install cmake gcc ncurses-devel

# Arch Linux
sudo pacman -S cmake gcc ncurses

Clone the repository and build:

git clone https://github.com/AMDmi3/cavezofphear.git
cd cavezofphear
cmake .
cmake --build .
./phear

For a system-wide install:

cmake -DSYSTEMWIDE=ON .
cmake --build .
sudo cmake --install .
phear

macOS

Install the build dependencies via Homebrew:

brew install cmake ncurses

Then clone and build:

git clone https://github.com/AMDmi3/cavezofphear.git
cd cavezofphear
cmake . -DCMAKE_PREFIX_PATH="$(brew --prefix ncurses)"
cmake --build .
./phear

For a system-wide install:

cmake -DSYSTEMWIDE=ON -DCMAKE_PREFIX_PATH="$(brew --prefix ncurses)" .
cmake --build .
sudo cmake --install .

Why Play Cavez of Phear?

Most terminal games go for action. Cavez of Phear rewards patience and spatial thinking. Every level is a small puzzle: where do the boulders fall? Which path clears the diamonds without trapping you? When do you use a bomb versus digging around a monster?

It's a game you can play in a terminal over SSH, in a tmux pane, or on a server with no display. It's lightweight, thoroughly enjoyable, and scratches a very specific retro itch. The active maintenance (latest release: September 2025) means it builds cleanly on modern systems without fighting your toolchain.

Source code: https://github.com/AMDmi3/cavezofphear

This blog is a small corner of the internet dedicated to building, breaking, and experimenting with things in the terminal.

The main focus is simple: time-waster applications. Terminal games, strange utilities, odd experiments, and little programs that exist mostly for the fun of making them. Some will be useful, some will be pointless, and some will probably be both.

Along the way, I’ll also be exploring a few other interests that naturally intersect with this space: a bit of offensive security, some lightweight data engineering, and the process of building tools with modern AI assistants.

Why This Blog Exists

One of the goals of this blog is to embrace AI as part of the future of development.

Rather than treating AI as a black box, I want to treat it as a collaborative tool, something that helps explore ideas, prototype quickly, and experiment with concepts that might otherwise never get built. Many of the projects here will involve AI somewhere in the process: generating ideas, debugging code, suggesting architectures, or helping refine experiments.

But the point isn't automation.

The point is learning while building.

A Throwback to the Old Web

This site is intentionally simple.

No growth hacks. No content funnels. No endless optimization.

It’s closer in spirit to the early web of the 90s, when people created websites simply because they enjoyed making things and sharing them. Projects here might be small, rough, or weird — and that’s exactly the point.

Expect:

• Terminal games and command-line toys
• Experiments built with AI assistance
• Notes from learning offensive security
• Small data engineering side projects
• Random technical curiosities

Most of it will be built for fun.

Some of it might even be useful.