matt-dray/r.oguelike

:crossed_swords::keyboard: R package: a tile-based roguelike toy for R's console, featuring procedural dungeons and enemy pathfinding

{r.oguelike}

A tile-based roguelike toy for R's console.

This is a proof-of-concept. Read more in the blogposts. Suggest improvements or fixes in the issues.

You can install {r.oguelike} from GitHub via {remotes} (CRAN packages {crayon}, {keypress} and {sonify} are also installed):

if (!require(remotes)) install.packages("remotes")
remotes::install_github("matt-dray/r.oguelike")

You could also launch an instance of RStudio in the browser with {r.oguelike} preinstalled, thanks to Binder.

Use start_game() to begin. See ?start_game for details on how to adjust the starting parameters.

r.oguelike::start_game(
  max_turns  = 25,
  iterations = 3,
  n_row      = 15,
  n_col      = 20,
  n_rooms    = 4
)

The console will clear and then you’ll see a dungeon map, an inventory bar, a status message and a prompt for player input. Output will appear in colour if your console supports it.

# # # # # # # # # # # # # # # # # # # # 
# # # # # # # . . . . . . . . # # # # # 
# # # # # # . . . . . . $ . . # # # # # 
# # # . . . . . . # # . . . . # # # # # 
# . . . # # # # # # # . . . # # # # # # 
# . . # # # # # # # # . . . # # # # # # 
# . . . # # # # # # # . . . . . # . # # 
# . . # # # # # # # . . . . . . . . # # 
# . . # # # # # # # # . . . . . . # # # 
# . @ . . . # # . # # # # . . . . . # # 
# . . . . . . . . . . . . . . . . # # # 
# . . . . . . . . . E . # # . . . # # # 
# . . a . . . . . . . . . . . . # # # # 
# # . . . . # # . # # # # . # # # # # # 
# # # # # # # # # # # # # # # # # # # # 
T: 25 | HP: 10 | $: 0 | a: 0
Press W, A, S or D then Enter to move, 1 to eat apple, 0 to exit
Input:

The dungeon map (# for walls and . for floor tiles) is procedurally-generated and the placement of objects (@ is the player, E is an enemy, $ is gold and a is an apple) is randomised.

To move the player character (@), type one of WASD at the prompt and hit Enter. If your terminal supports {keypress} (RStudio doesn't) then you'll be able to type a single arrow key instead.

After instructing the player character to move down, for example, the screen refreshes to show @ is in a new location and the status message has been updated. Simple sound effects will play depending on the outcome of the move.

# # # # # # # # # # # # # # # # # # # # 
# # # # # # # . . . . . . . . # # # # # 
# # # # # # . . . . . . $ . . # # # # # 
# # # . . . . . . # # . . . . # # # # # 
# . . . # # # # # # # . . . # # # # # # 
# . . # # # # # # # # . . . # # # # # # 
# . . . # # # # # # # . . . . . # . # # 
# . . # # # # # # # . . . . . . . . # # 
# . . # # # # # # # # . . . . . . # # # 
# . . . . . # # . # # # # . . . . . # # 
# . @ . . . . . . . . . . . . . . # # # 
# . . . . . . . . E . . # # . . . # # # 
# . . a . . . . . . . . . . . . # # # # 
# # . . . . # # . # # # # . # # # # # # 
# # # # # # # # # # # # # # # # # # # # 
T: 24 | HP: 10 | $: 0 | a: 0
Moved down
Input:

Also note that the enemy's (E) position has changed and it's heading in your direction...

What now? Collect the gold ($). Auto-battle the chasing enemy (E). Collect an apple (a) for your inventory, then eat it with a keypress input of 1 to replenish health. You’ll die if you run out of HP or if you reach the maximum number of turns allowed (T). You can quit the game with 0.

Code of Conduct

Please note that the {r.oguelike} project is released with a Contributor Code of Conduct. By contributing to this project, you agree to abide by its terms.

r.oguelike's Issues

Collecting an apple adds two to the inventory

An 'a' in the dungeon represents one apple, but two are added to the inventory when you walk over it.

T: Inf | HP: 10 | $: 0 | a: 2
Collected apple (+1 a)

Begin item inventory system

Touch an apple (a) and it goes into the inventory rather than an immediate +1 HP.

Could appear in stats line like HP: 10 | G: 2 | A: 1 or whatever.

How to use the item? Easier: dedicated button (how to tell user about this?). Harder: dedicated inventory 'popover' (would still need to let user know what to press to open the inventory).

For use in overworld (and later in battles, see #6).

Small rooms aren't always built correctly

For example, a 4 by 4 room won't always have walls all around the edge. Possibly because of placing actors/items?

game_map <- .make_dungeon(
  iterations = 5, n_row = 4, n_col = 4, n_rooms = 5, is_snake = FALSE, is_organic = TRUE
)

.cat_map(game_map, is_colour)

Results in:

a # # # 
$ E @ # 
. . . # 
# # # # 

Could enforce room dimensions to be above a certain size.

Begin generated dungeons

Currently the room size and object placement is 'randomised'. Actually we want a full dungeon that is randomly generated for each game.

Display everything on one screen, with corridors linking rooms? Could force the terminal window size if so. Would want corridors between rooms. Reveal as the player travels? Player view cone as they enter a room?

Or otherwise show one room at a time. Might be easier implementation. Need to 'remember' rooms in a list or something and ensure that doors link between list elements. Need to remember that items have been picked up/enemies battled (unless certain types respawn?).

Add sound effects

Use {sonify} as per {ActionSquirrel}, e.g. when bumping into a wall.

Use in {r.oguelike} for pickups, battles, etc.

Is there a way to call the system rather than use {sonify}?

Add enemies with different abilities

With different enemy types, difficulty could link to:

• attack power (how many HP you lose when they attack)
• defence (how many HP they have)
• speed (how many tiles they move at once/within certain number of turns )
• locomotion (movement pattern, like a rook or like a queen in chess)
• awareness of the player (move towards player, or move randomly)

Like E is the hard enemy and e is easier.

Keep to the Berlin interpretation

Keep it old skool, keep it ASCII. Stick to the must-haves from the Berlin Interpretation, i.e. require:

• random environment generation
• permadeath
• turn-based gameplay
• grid-based gameplay
• non-modal gameplay
• complexity
• resource management
• hack'n'slash fighting
• exploration and discovery

Allow for user-chosen actions in battle

Rather than just print battle steps automatically (#14), the user could equip items from the inventory for:

• defence (shield/mail)
• attack (sword/potion)
• HP replenishment (food, like in #10)

Begin battle system

Start with autobattler: the turns in the fight happen automatically.

Death is permadeath, obv.

Generating 'dungeon' patterns

• One possible unusual future use-case for {r.oguelike}---if/when it reaches CRAN---could be generating "dungeon" patterns for use with {gridpattern} / {ggpattern}: trevorld/gridpattern#55
• Easiest on the {gridpattern} end if we had a function that generates a matrix of integers.
• Currently not that hard to wrap the current generate_dungeon() for this:

n_row <- 20
n_col <- 30
invisible(capture.output({
    m <- r.oguelike::generate_dungeon(n_row=n_row+2, n_col=n_col+2, seed = 42)
}))
m <- m[2:(n_row+1), ]
m <- m[, 2:(n_col+1)]
m <- matrix(as.integer(factor(m, levels = c("#", "."))),
            nrow = n_row, ncol = n_col)

Print description of turns in a battle

Rather than having a a battle where the outcome happens immediately on contact with an enemy (#6), describe the turns in the battle, like:

• you hit (-1 enemy HP)
• enemy missed

Print this in the 'text line' of the UI, or allow for all battle turns to be visible before being overwritten

`generate_dungeon()` error

I get an error when I try to use generate_dungeon() per the example in the package documentation:

 r.oguelike::generate_dungeon(10, 20, 30, 3)

Error in sample.int(length(x), size, replace, prob) : 
  invalid 'size' argument

If you want I could do a PR that creates a basic testthat::expect_snapshot() unit test for generate_dungeon()...

Get/set/display seed

Generate a seed that can be provided back to the user somehow, e.g. printed as part of the UI (bit annoying)or the start message (once it's gone it's gone); maybe <<- to put it in the user's environment; or possibly it's the only thing that actually get returned from start_game()?

Allow the user to provide a seed to start_game() so they can recreate a dungeon.

Ensure actors/items are visible

Might need the characters to be black to show up on these light-coloured highlights.

Add enemy pathfinding

Consider strong (E) and weak (e) enemies. E closes in on the player and is stronger, e moves randomly and is weaker. (Other ideas: E moves every turn, e every other; E can move like a queen, e like a rook.) Maybe there's a Boss with specific patterns.

Refactor with OOP

I wondered how far I could get without classes. I think this (0.0.0.9004) is far as I want to go without tripping over spaghetti.

Create a player class and then parent classes for enemies, food, maybe rooms, etc, where individual instances of each one inherit their respective parent class.

S3 (benefit of no dependency) or {R6} (benefit of having used it before and possibly better organisationally).

Of course, Giora's approach can be referenced.

Create a Binder instance

Set up another repo with Binder, which launches with {r.oguelike} installed and a single line R file to launch a game.

You wrote about this before and did the same thing for {r2eng} as well.

Consider {isocubes}/{oblicubes} and {eventloop} display and interface

It's entirely possible to put the dungeon-building, player movement and enemy pathfinding into isometric graphics with {isocubes} and use {eventloop} for 'live' reading of user inputs.

I did this here: https://gist.github.com/matt-dray/dcbd5cd2f4bdc471921e5c741a1233c0

Tweet with gif here: https://twitter.com/mattdray/status/1540107713681788928?s=20&t=cHuU2QYsbbVVNtVufR4VPg

Ensure clear command works on all platforms

Write a function that detects the terminal/system/platform and clears accordingly (kinda like this SO example, see also this blog).

Or so at least it doesn't bork the game for people playing on certain platforms, i.e. either clear it or don't, don't allow for errors to occur that break the game.

Error in if (room[move_to] != "#") { : argument is of length zero

I get this error when moving into the enemy:

# # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # . . #
# # # # # # # # # # . . # # # # . . . #
# # # # # # # # . . . . . # # # # . . #
# # # # # # . . # . a . . # # # . . . #
# . # # . . . . # . . . . # # # # . . #
# . . $ . . . . . . . . . # # # # . . #
# . # . . . . . . . . . . # # # # . . #
# # # . . . # # . . # . # # # # # . . #
# # # # # # # # . . . . # # # # # . . #
# # # # # # # # . . . # # # # # # . . #
# # # # # # # # . . # # # # . # # . . #
# # # # # # # . # . # . . . . . . . . #
# # # # # # # . . E @ . . . . . . . . #
# # # # # # # # # # # # # # # # # # # #
T: 13 | HP: 10 | $: 0 | a: 0
Moved left
Error in if (room[move_to] != "#") { : argument is of length zero
>