Representation of Asciimon in the game

[Hopson97]

When it comes to creating the acsiimon for the game, there are basically 2 types.

1. Basic base data of the Asciimon.

This is things like base stats, their type, what level they evolve into other Asciimon and what they evolve into, their cry, what they look like (from behind and in front), what moves they can learn etc

This is the sort of things that is shown when looking up the Asciimon in an "AsciiDex". (Which is another issue on its own!)

2. Asciimon owned by the player (and maybe trainers throughout the world?)

This is what level the Asciimon is, what the asciimon is, what it's stats are, their nature, what moves that particular Asciimon has.. I believe this is seperate from the "base data" representation of the Asciimon.

---

The issue is, what could be the best way to actually represent this kind of thing in the code, without duplication of data.

[CAD97]

Here's a rough sketch of how I think this could be handled. Basically: use indices instead of references to make everyone's life easier and avoid the self-borrow issue.

struct DexEntry {
    /// Equivalent to "Base Stats" on Bulbapedia: the numbers that serve as a base for stat calculation
    base_stats: Stats,
    /// Potential abilities that the Asciimon can have
    abilities: Vec<Ability>,
    /// Any non-gameplay information that should be shown in the dex
    trivia: Trivia,
}

struct DexNumber(usize);
struct Dex(Vec<DexEntry>);
impl Index<DexNumber> for Dex {
    type Item = DexEntry;
    fn index(&self, idx: DexNumber) -> &DexEntry {
        &self.0[idx.0]
    }
}

struct Asciimon {
    name: String,
    current_hp: u32,
    level: u32,
    ability: usize, // or Ability iff Ability is Copy
    stats: Stats,
    nature: Nature, // etc, personality things
    dex_number: DexNumber,
}

The stats of the Asciimon reflect their current stats at this level. This is recalculated whenever they level up based on their base stats and nature, etc.

The key point to realize here is that the dex is basically a graph. In order for a graph to work decently well, it's best to use indices into the graph rather than try to use references. (You could also Rc and Weak it, but that'd be... messy at best). Take advantage of the fact that it's static data and use immutable indices to reference other entries.

Also, if you're open to adding dependencies later on, consider using serde to load in the dex from a configuration file! (Similarly, if you want to support saving or any sort of de/serialization, serde is the go-to defacto serialization library for Rust, use it instead of rolling your own.)

[Hopson97]

Fantastic ideas, thanks!

[EternalMC]

I just want to say if you're are adding dark types make a day-night cycle and the dark types only spawn at night and in the night the colors get a little darker so players know that its night of course. the way I thought of doing it is a little simple but its basic increment a little until a number reaches like 2000 then make it night.