You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
118 lines
6.7 KiB
118 lines
6.7 KiB
# An Homage to Rogue
|
|
|
|
When I was a kid I played a game that used only text characters in a terminal called [Rogue](https://en.wikipedia.org/wiki/Rogue_(video_game). This game ran in my little MSDOS computer using only the ASCII characters the computer supported. No graphics and I think no sound but I can't remember. Despite this very low quality graphical experience the game delivered an amazing game experience. Even today the term "roguelike" denotes certain qualities that come from the original _Rogue_:
|
|
|
|
* Dying is permanent but each time you restart you'll retain some previous skills or equipment so
|
|
the next run is easier.
|
|
* However, it's only easier to the point where you previously died, as each level through the
|
|
dungeon gets more and more difficult.
|
|
* A randomly generated world (dungeon) that features a new experience every time.
|
|
* A focus on mechanics rather than graphics, but creative use of the limited graphical characters to
|
|
make the game playable.
|
|
* This lack of graphics weirdly makes the game _more_ imaginative because you have to fill in what's
|
|
going on with your own imagination, similar to a game of Dungeons and Dragons.
|
|
|
|
This is why I chose Rogue as the basis for my first actual game in C++.
|
|
|
|
## A "Classical" Game Development Education
|
|
|
|
In the world of art there's a concept of a "classical education," which means you learn to paint and
|
|
draw using old methods meant to teach a realistic style. These methods are hundreds--maybe even
|
|
thousands--of years old and work very well...assuming you have the patience. Learning to paint and
|
|
draw like this is almost an art history lesson since not many people do art using these techniques
|
|
anymore.
|
|
|
|
I'm planning to do my study of game development in the same way by making games in historic order.
|
|
Rather than run off and start using Unreal Engine immediately I'm going to make an homage to each
|
|
kind of game I played when I was younger. Each game I make will hopefully teach me both the history
|
|
of Game Development and also a technique that's either very useful or long forgotten.
|
|
|
|
My little Rogue game is the first entry in this series.
|
|
|
|
## It's Not 1980 Anymore
|
|
|
|
My goal is to maintain the constraint of "Text Only, but not Terminal Only." What I mean by this is
|
|
I'll use only text glyphs for the graphics in the game but I won't restrict myself to the textual
|
|
grid, layout, or traditional Terminal constraints. I'm rendering these characters using modern
|
|
graphics capabilities that allow me to create a more fun experience.
|
|
|
|
For example, I code the whole UI in a Terminal UI (TUI) library named [FTXUI](https://github.com/ArthurSonzogni/FTXUI) but I render the ANSI terminal output of FTXUI into an [SFML](https://www.sfml-dev.org/) window using an [ANSI Code Parser](https://git.learnjsthehardway.com/learn-code-the-hard-way/roguish/src/branch/main/ansi_parser.rl) that renders to a [Render Pipeline](https://git.learnjsthehardway.com/learn-code-the-hard-way/roguish/src/branch/main/render.cpp). This lets me render full Text UIs at one scale while rendering the map in a different scale and allow zooming.
|
|
|
|
I also use a full true color encoding so I can implement things like lighting effects and complex
|
|
color changes. I even have sounds, simple camera shake effects when you take damage, and other
|
|
things found in top-down games.
|
|
|
|
In addition to that, I'm not limited to _one character per cell_. Since I'm only treating
|
|
characters as sprites I'm actually able to layer them in the same cell, so I can show weapons being
|
|
held, damage effects, and other changes using character on the player or other entities.
|
|
|
|
## Why Not Just Use Pixel Art?
|
|
|
|
I mean...I am...it just looks like text. An Homage doesn't mean you copy something exactly. It
|
|
means you create something that's your own, but references or takes things from another artist's
|
|
work. It's a respectful copy that doesn't really steal but instead pays respects to those who came
|
|
before while still creating something new for the future.
|
|
|
|
In my game I'm using the constraint of "Text Only, not Terminal Only" to give me an artistic
|
|
constraint and to keep the game an homage to all the Rogues that came before.
|
|
|
|
But also, I mean c'mon folks, it's 2025. We do have sound now.
|
|
|
|
## Where's the LICENSE?
|
|
|
|
You don't need a LICENSE that gives everything away to thieving corporations just to publish your
|
|
works online. Nobody makes artists, musicians, painters, photographers, or sculptors get a license
|
|
before posting online, so why do programmers need one? You worried you'll get sued? Ok, so just put
|
|
a disclaimer but why do you _also_ have to give your hard work away for anyone to steal and profit
|
|
from just so they don't sue you?
|
|
|
|
You don't, and no matter what the OSI says, nobody can sue you if they steal your code and cause a
|
|
plane to crash. _They_ would get sued for stealing your code and putting it in a plane, not you.
|
|
Requiring _only_ programmers to release their code with a license to avoid lawsuits creates a
|
|
[Chilling Effect](https://www.thefire.org/research-learn/chilling-effect-overview) on programmer free speech and that violates the First Amendment.
|
|
|
|
So this code isn't licensed, it's copyright by default. I'm publishing it using my free speech
|
|
rights to express myself and that means you can look at it the same as if I posted a painting or an
|
|
essay on my blog. I obviously can't sue you for just looking at it and playing the game because I
|
|
published it so you can, but _that doesn't mean you own shit._ You can't resell it, fork it,
|
|
nothing.
|
|
|
|
Just grab the code and play it. That's it. Tell people about it. Fair use says you can even record
|
|
videos reviewing it and talking about it.
|
|
|
|
See? That's how Free Speech works. You don't need a LICENSE.
|
|
|
|
## Build Instructions
|
|
|
|
Pre-requisites:
|
|
|
|
* Meson -- which need Python
|
|
* C++ Compiler -- Tested with Clang and G++
|
|
* GNU make -- For the convenience Makefile
|
|
|
|
Windows instructions
|
|
|
|
```shell
|
|
git clone https://git.learnjsthehardway.com/learn-code-the-hard-way/roguish.git
|
|
|
|
cd roguish
|
|
# ignore the errors the first time
|
|
./scripts/reset_build.ps1
|
|
|
|
# first compile takes a while
|
|
make
|
|
|
|
# this copies the binary so you can run it
|
|
make run
|
|
```
|
|
|
|
|
|
|
|
|
|
## OSX Build Notes
|
|
|
|
* Quite a bad experience. Need to install Python, cmake, meson, and ninja all which are in homebrew but if you don't use homebrew then this is a problem.
|
|
* You need to run the .command script in Application/your python that updates the SSL certs.
|
|
* You have to give iTerm access to your keystrokes...because wtf it already has them?
|
|
* This points out a problem that I'm getting the keys using FTXUI but should either get them from SFML _or_ connect FTXUI to SFML's keyboard input events instead.
|
|
* No actually this first run delay seems to be related to the security feature that blocks keyboard access on iTerm, so probably fixing that would speed it up.
|
|
|