
## Ever Onward

Moving on to [Chapter 10] now. I'm mostly just reading through the tutorial now. I have all the code
downloaded, and I read through it on my own machine to understand it, but I haven't been writing or
even copy/pasting the code from the book.

Also, it's Saturday today, so I'm doing this in the morning. We'll see if I can get through a larger
chunk of the book today.

## Ranged Magic Scrolls

Before I read this, I want to stop and think: How would I implement ranged magic scrolls using the
ECS I know about?

They would use the existing `Item` component. I'd make a `Scroll` component that hold information
about what effect(s) it has, and I suppose a `Ranged` component that describes how an item can cause
effects at a distance... Or something like that.

On second thought, `Item` and `Ranged` plus some type of `Description` for UI might be enough.
`Description` would only hold information for describing the item to users textually, and `Ranged`
would have all the information about effects and their targetable areas.

Let's see how this book implements ranged magic scrolls...

Oh I'm liking this. I haven't finished yet, but they immediately implement a `Consumable` component
and change the `Potion` component to a `ProvidesHealing` component.

And for the scrolls the book is implementing separate `Ranged` and `InflictsDamage` components.

...

And we're implementing several different ranged items. I'm liking this.

...

I've finished reading chapter 10, and I've played the game at this point, and noticed that item
effects target all entities with a position in range: including other items on the ground. I
suppose for this to work there needs to be a way of targeting appropriate entities for a given
effect. Maybe with components like `Confusable` and `Burnable`? Or maybe all entities with an AI
system are confusable...

Also, I can use potions to bring myself back from the dead. And fireball spells can make my HP go
negative.

## Loading and Saving

Time for [Chapter 11].

...

I finished reading. This chapter seemed more hacky.

> I kept running into problems like it failing to compile if I had more than 16 component types!

The fix was to write a custom macro and then call it like this

```rs
serialize_individually!(
    ecs,
    serializer,
    data,
    Position,
    Renderable,
    Player,
    Viewshed,
    Monster,
    Name,
    BlocksTile,
    CombatStats,
    SufferDamage,
    WantsToMelee,
    Item,
    Consumable,
    Ranged,
    InflictsDamage,
    AreaOfEffect,
    Confusion,
    ProvidesHealing,
    InBackpack,
    WantsToPickupItem,
    WantsToUseItem,
    WantsToDropItem,
    SerializationHelper
);
```

And then make a similar macro & macro call for deserializing.

Also, how does this relate to configuration files? I'd like to be able to configure some entities
(like monsters & animals) in my game in text files and let users mod them. This serialization stuff
so far though makes text that isn't very human-readable, though; here's a piece of what it looks
like.

```json
[
  { "marker": [14], "components": [null] },
  { "marker": [12], "components": [{ "x": 28, "y": 5 }] },
  { "marker": [11], "components": [{ "x": 47, "y": 23 }] },
  { "marker": [10], "components": [null] },
  { "marker": [9], "components": [{ "x": 40, "y": 32 }] },
  { "marker": [8], "components": [{ "x": 25, "y": 19 }] }
]
```

I'm going to stop for lunch, and then I'll continue.

## Multiple Levels

And on to [Chapter 12]! Boy, Saturdays are great for this.

This chapter is about implementing multiple levels/depths for the dungeon, so you can go up & down.

In my game the closest things to levels are islands. They're accessible from any direction in an
open world by a flying/gliding character, so they're a little different from caverns. Oh and they
move relative to each other.

None of that really means anything until I make the game, though. 😅

...

I read through the chapter, and played the game a bit.

It's a very simple change. The player can go "down," which generates a new map with new items &
monsters. The old map becomes inaccessible&mdash;the player can't go upstairs, and the map's data is
thrown away.

As it is, the game hasn't handled the player's death, so I can "descend" as far as I like; nothing
about the levels changes as I descend, though.

## Difficulty

Now starting [Chapter 13].

The first step is adding a "wait" key, to let the player skip their turn. I think I want my game to
be real time, with a "pause" button.

...

I read the code and played the game for several levels. The ramp up was a nice change. The game
finally crashed when I collected more items than could be displayed, though. 😆

## Wearable Items

And now in [Chapter 14].

...

That seemed pretty familiar. Lots of components and systems for everything.

Also, that was the last chapter in the first section of the tutorial. 🎉

Good place to stop.

[chapter 10]: http://bfnightly.bracketproductions.com/rustbook/chapter_10.html
[chapter 11]: http://bfnightly.bracketproductions.com/rustbook/chapter_11.html
[chapter 12]: http://bfnightly.bracketproductions.com/rustbook/chapter_12.html
[chapter 13]: http://bfnightly.bracketproductions.com/rustbook/chapter_13.html
[chapter 14]: http://bfnightly.bracketproductions.com/rustbook/chapter_14.html


Roguelike Dev Day 8: Last Several Chapters

<h2 id="finishing-inventory"><a href="#finishing-inventory">Finishing Inventory</a></h2>
<a href="http://bfnightly.bracketproductions.com/rustbook/chapter_9.html">Chapter 9</a> is right over there.
...
I wonder if Systems (the "S" in "ECS") always have these big data selector types. I'd like to look
into other ECS implementations to see how they handle this.
<pre class="shiki poimandres" style="background-color: #1b1e28"><code>impl&#x3C;'a> System&#x3C;'a> for PotionUseSystem {
 type SystemData = (
 ReadExpect&#x3C;'a, Entity>,
 WriteExpect&#x3C;'a, GameLog>,
 Entities&#x3C;'a>,
 WriteStorage&#x3C;'a, WantsToDrinkPotion>,
 ReadStorage&#x3C;'a, Name>,
 ReadStorage&#x3C;'a, Potion>,
 WriteStorage&#x3C;'a, CombatStats>,
 );

 // More PotionUseSystem stuff
}</code></pre>
<h2 id="other-ecss"><a href="#other-ecss">Other ECSs?</a></h2>
I've looked a bit into other Rust ECS options and so far haven't found a recent comparison. I may
just have to read through <a href="https://arewegameyet.rs/ecosystem/ecs/">the ECS list</a> on <a href="https://arewegameyet.rs">arewegameyet.rs</a>.

Roguelike Dev Day 7: Finishing Inventory

## Making a User Interface

I'm starting [Chapter 8] tonight.

I'm really disliking all the "magic constants" in this code. Take this code, which renders the
message log:

```rs
let log = ecs.fetch::<GameLog>();
let mut y = 44;
for s in log.entries.iter().rev() {
 if y < 49 { ctx.print(2, y, s); }
 y += 1;
}
```

What are the numbers `44`, `49`, and `2` for?

I believe `44` & `49` tell the program to write the messages between lines 44 and 49 (and those
lines are only special because of the chosen dimensions of our game). And reading the documentation
for `ctx.print`, the `2` is the x-coordinate of where to start printing the message.

I'm guessing these magic constants will be cleaned up later...

Also, I've noticed that the monsters won't chase me around corners, and it makes me sad. :'(

## Items & Inventory

On to [Chapter 9]!

...

### Epiphany

I'm pretty happy. So [yesterday] I was frustrated by the explicitly bracketed scopes all over the
place in this code, and wanted to know if there is a better pattern. Today I just figured out a
better pattern: put the scope in a function!

As an example, I turned this code...

```rs
fn random_monster(ecs: &mut World, x: i32, y: i32) {
 let roll :i32;
 {
 let mut rng = ecs.write_resource::<RandomNumberGenerator>();
 roll = rng.roll_dice(1, 2);
 }
 match roll {
 1 => { orc(ecs, x, y) }
 _ => { goblin(ecs, x, y) }
 }
}
```

Into this...

```rs
fn roll(ecs: &mut World, dice_count: i32, dice_sides: i32) -> i32 {
 ecs.write_resource::<RandomNumberGenerator>()
 .roll_dice(dice_count, dice_sides)
}

fn random_monster(ecs: &mut World, x: i32, y: i32) {
 match roll(ecs, 1, 2) {
 1 => orc(ecs, x, y),
 _ => goblin(ecs, x, y),
 }
}
```

And then you also get all the other benefits that go with smaller functions: reusability,
testability, etc.

I also managed to refactor that code that was bugging me yesterday using a function, but it's not as
compact of an example:

```rs

impl State {
 // Other state stuff here

 fn runstate(&mut self) -> RunState {
 *self.ecs.fetch::<RunState>()
 }
}

impl GameState for State {
 fn tick(&mut self, ctx: &mut Rltk) {
 // Other tick stuff here

 let mut newrunstate = self.runstate();

 match newrunstate {
 RunState::PreRun => {
 self.run_systems();
 self.ecs.maintain();
 newrunstate = RunState::AwaitingInput;
 }
 // More matches here
 }

 // More tick stuff here
 }
}
```

### Event-driven

The ECS stuff takes getting used to. It seems to be an event-driven architecture.

The specific thing that made me realize this is the [`WantsToPickupItem`] component in this chapter.
This component represents an event, or notice, that any other part of the game (a "system") can
subscribe to.

Oh. It's a state machine. The ECS keeps track of the world's state, and the systems run the
transitions from state to state.

Why represent the transition as another state? I've found it useful in my own work. As a simple
example, I often write web pages that need to fetch data from an API, and model the process with
four states: `Waiting`, `Loading`, `Error`, and `Ready`. `Waiting` is the initial state without
data, `Loading` is the transition state that represents the app is fetching data, and then `Error` &
`Ready` are the two final states, depending on the outcome of the API fetch.

The real question is how to decide when to represent a transition as a state (like `Loading`), and
when to implement a transition as a state boundary (ie, if I had no loading state and went straight
from `Waiting` to either `Error` or `Ready`). I'm not sure I have a good answer to that right now.

That's it for tonight. I'll have to finish Chapter 9 another time.

[chapter 8]: http://bfnightly.bracketproductions.com/rustbook/chapter_8.html
[chapter 9]: http://bfnightly.bracketproductions.com/rustbook/chapter_9.html
[yesterday]: http://localhost:3002/posts/2023-01-18-roguelike-dev-day-5#done-reading
[`wantstopickupitem`]: http://bfnightly.bracketproductions.com/rustbook/chapter_9.html#picking-up-items