Egor-ly Painting a game in rust

Win conditions and screen transitions ↩

So we've got the play area, and you can fill in the space. But once you do there's nothing to tell you that you won, or that you screwed up X times, or that you were perfect and made 0 mistakes, or anything that gives us an incentive to fill out the puzzle. Right now, it's sort of like having one of those physical books of Sudoku puzzles, and when you finish it you sigh a little because you finished it, but also now you have no more puzzles to fill out and are bored.

We need dopamine! But not too much, so let's just tell the user that they won and they were perfect if they made 0 mistakes, or that they did their best and they made X number of mistakes. It'd be cool to play a little jingle or something, but let's take things one step at a time. The refactoring I mentioned has tweaked our main file into a smaller unit of abstraction, our main app loop now looks like this:

let mut game_state: gamestate::PlayState = (&test_pbm).into();
let mut debuggable_stuff = DebugStuff::new();
let mut palette = ColorPalette::meeks();

App::new()
    .window_size(1280, 720)
    .title("Logic Brush")
    .run(move |frame_context| {
        for event in &frame_context.events {
            match event {
                WindowEvent::CloseRequested => {
                    std::process::exit(0);
                }
                _ => {}
            }
        }
        if frame_context.input.key_pressed(KeyCode::Escape) {
            std::process::exit(0);
        }

        screens::play_game_screen(&mut game_state, frame_context, &mut palette);
        debug_window(
            frame_context,
            &mut debuggable_stuff,
            &mut palette,
            &mut game_state,
        );
    });

And, as you can imagine, the screen method contains all the code we had which rendered everything up to this point. Since that's just handling rendering things in the immediate context, it can't track the stuff we've been mutating over the course of things. And so, if there's any data I care about tweaking on the fly, it gets tossed into the aptly named DebugStuff struct and passed around. Is it a little funny? A bit. But it does work!

And with that in mind, we can start creating a new screen method to render the win screen. Let's get the vague idea of what we want onto the page first and then we'll jump into some more indepth stuff.

pub fn win_screen(
    game_state: &mut PlayState,
    frame_context: &mut FrameContext,
    palette: &ColorPalette,
    debuggable_stuff: &DebugStuff,
) {
    let gfx = &mut (frame_context.gfx);
    let input = &mut (frame_context.input);

    let screen_size = gfx.screen_size();
    gfx.camera().target(screen_size / 2.);

    let (mx, my) = input.mouse_position();
    let world_xy = gfx.camera().screen_to_world(Vec2::new(mx, my), screen_size);

    gfx.rect()
        .at(world_xy)
        .color(Color::new(palette.background))
        .size(vec2(
            debuggable_stuff.size_x as f32,
            debuggable_stuff.size_y as f32,
        ));

    let num_incorrect = game_state.number_incorrect();
    if num_incorrect == 0 {
        gfx.text(&format!("Perfect!"))
            .size(16.)
            .color(Color::new(palette.group_highlight))
            .at(screen_size / 2.);
    } else {
        gfx.text(&format!("Incorrect {}", num_incorrect))
            .size(16.)
            .color(Color::new(palette.group_highlight))
            .at(screen_size / 2.);
    }

    gfx.rect()
        .at(screen_size /2. + vec2(-50., 100.))
        .color(Color::new(palette.background))
        .size(vec2(200., 100.));
    gfx.text(&format!("Return to Menu"))
            .size(16.)
            .color(Color::new(palette.group_highlight))
            .at(screen_size / 2. + vec2(-25., 150.));
}               

Just like before, we're starting with a mess! No separate ui draw calls or any abstraction. We want all the stuff we're fiddling with to be out in the open to make it easy to poke, prod, and wiggle things around. As such, the size and position of a rectangle to represent the picture the user has just unlocked is in full debug mode while we figure out where to put it:

It seems sensible for the button to get out of the win screen to be centered, maybe not horizontally, but at least vertically it seems like a good idea. This isn't the final form of the button, not by a long shot. But it does roughly represent what we want to have. I'd like to render the properly filled image in the space to the left, and then on the right display PERFECT or N Mistakes, and underneath the return to menu button.

In order to display the complete image, we'll need to write a parser and renderer for a ppm file. That't not too hard to do, but for now, let's put that aside to focus on the slightly more interesting thing. Making the perfect text bigger isn't hard, that's just a tweak to the size arguments. But, Positioning text and the button is kind of annoying. Is there a better way to control the text? Looking at the source of the TextBuilder, the buffer being created is setup like this:

let mut buffer = Buffer::new(
    self.renderer.font_system_mut(),
    Metrics::new(self.size, 1.0),
);

If we look at the underlying cosmic text library then we can see that this text buffer's Metrics is setting its size and line height in pixels. But, that doesn't make any sense does it. A line height of 1 pixel? That's weird. The only sensible thing to assume here is that it's not a single pixel tall, but a single "unit" tall, and then that unit is scaled by the font size we're giving it.

So if I want to center the text on the "button" then we can validate that assumption by doing some rough math based on the fact that we have the height (font size), and can compute the width based on the aspect ratio of the characters. Obviously, every character is a bit different, but we probably can make do with a vague approximation. So, like, if we stare at some of the text for a while, it kind of feels like a teensy bit more than half? Let's give a shot:

fn draw_centered_text(
    gfx: &mut Graphics,
    text: &str,
    center: Vec2,
    size: f32,
    color: Color,
) {
    // average font aspect ratio is 0.53 (eyeballing)
    let w = text.len() as f32 * size * 0.53;
    let h = size;

    let pos = center - vec2(w * 0.5, h * 0.5 - size / 2.);

    gfx.text(text)
        .size(size)
        .color(color)
        .at(pos);
}

Not bad! Pretty good for eyeballing things! Now that we've got the "button" centering its text, let's make it feel like a real button by making it change color on hover:

let button_bg_pos = screen_size / 2. + vec2(-50., 100.);
let button_size = vec2(200., 100.);

let rect = egor::math::Rect::new(button_bg_pos, button_size);
let should_highlight = rect.contains(world_xy);

let (btn_color, font_color) = if should_highlight {
    (
        Color::new(palette.group_highlight),
        Color::new(palette.background),
    )
} else {
    (
        Color::new(palette.background),
        Color::new(palette.group_highlight),
    )
};

Interactivity! It's not perfect, but it will do for now and maybe we'll polish it up later. More importantly, the button, when clicked, should do something! And as its name implies, it should return you elsewhere. Since we only have the one other screen right now, let's just make it swap you over there and when we actually add a menu, then we can change the target.

let left_mouse_pressed = input.mouse_pressed(MouseButton::Left);
if left_mouse_pressed && should_highlight {
    // Okay now waht
}               

You may recall we're inside of a win_screen function right now. We're not in the main loop of the App's closure. I think the obvious solution here is a flag, if we were writing C, we'd probably use a number to indicate the next action via enum. But this is rust! We have super enums!

enum Screens {
    GameScreen,
    WinScreen,
}
enum ScreenAction {
    ChangeScreen { to: Screens },
    NoAction,
}

With these defined we can update the screen functions to return one of these, pattern match on the result and then do the appropriate thing! Easy. So, the game screen becomes like this:

pub fn play_game_screen(
    game_state: &mut PlayState,
    frame_context: &mut FrameContext,
    palette: &mut ColorPalette,
) -> ScreenAction {
    ...
    if game_state.is_complete() {
        ScreenAction::ChangeScreen {
            to: Screens::WinScreen,
        }
    } else {
        ScreenAction::NoAction
    }
}

and the win screen:

pub fn win_screen(
    game_state: &mut PlayState,
    frame_context: &mut FrameContext,
    palette: &ColorPalette,
    debuggable_stuff: &DebugStuff,
) -> ScreenAction {
    ...
    if left_mouse_pressed && should_highlight {
        // Tmp go back to game screen for now
        ScreenAction::ChangeScreen {
            to: Screens::GameScreen,
        }
    } else {
        ScreenAction::NoAction
    }
}

Then the main game loop updates:

let mut current_screen = Screens::GameScreen;

App::new()
    .window_size(1280, 720)
    .title("Logic Brush")
    .run(move |frame_context| {
        ...
        let action = match current_screen {
            Screens::GameScreen => {
                screens::play_game_screen(&mut game_state, frame_context, &mut palette)
            }
            Screens::WinScreen => screens::win_screen(
                &mut game_state,
                frame_context,
                &palette,
                &mut debuggable_stuff,
            ),
        };
        match action {
            ScreenAction::NoAction => {}
            ScreenAction::ChangeScreen { to } => {
                // TODO smoother transitions
                current_screen = to;
            }
        };
        ...
    }

Super simple. And, does it work?

It works! But also. Not quite! Since I'm not reseting the game state that's provided to the screen functions, the game is already complete and so we instantly pop over to the win screen. Resulting in that funny flashing because it seems like the time that the left mouse button is counted for is more than a single frame, and so it swaps rapidly back.

This is mostly a temporary problem that will be fixed once we have a better flow and another screen for you to select the puzzle you want to play from. But, we could try to fix this before that even exists! Specifically, if we create a transition between screens, then that would play out and give a bit of a buffer for the click from the button press to clear out before any other action can be taken. This seems like a good idea to me, and the question is, how do we do it?

Well, unfortunately, egor doesn't seem to expose a frame buffer for us. Or at least, not that I can spot in the documentation. I'm not well versed enough with GPUs and whatnot to figure out if I could somehow grab this directly… So instead, we're going to do something a little silly ¹⁶.

To start, let's get a screen in the middle of the two we're going between. Because this enum is going to reference two of the other potential values of the same enum, and technically that could be recursive (though never will be in practice), we have to box the values:

pub enum Screens {
    GameScreen,
    WinScreen,
    WipeScreen {
        from: Box<Screens>,
        to: Box<Screens>,
        duration: f32,
    },
}

And since my plan is to have two halves of this screen transition, we'll make three enum values to represent the action:

pub enum ScreenAction {
    ChangeScreen { to: Screens },
    NoAction,
    WipeLeft,
    WipeRight,
    WipeDone,
}

With these enums defined, I just need a basic screen to draw for the duration of the transition. We'll get it showing first with a minimal proof of concept, and then we'll do the hard part after.

pub fn wipe_screen(
    wipe_progress: &mut f32,
    duration: f32,
    frame_context: &mut FrameContext,
    palette: &ColorPalette,
) -> ScreenAction {
    *wipe_progress += frame_context.timer.delta;

    let gfx = &mut (frame_context.gfx);
    let screen_size = gfx.screen_size();
    let pos = screen_size / 2.;

    gfx.camera().target(screen_size / 2.);

    draw_centered_text(
        gfx,
        &format!("{}%", *wipe_progress / duration),
        pos,
        20.,
        Color::new(palette.group_highlight),
    );

    if *wipe_progress < duration * 0.5 {
        ScreenAction::WipeLeft
    } else if *wipe_progress > duration {
        ScreenAction::WipeDone
    } else {
        ScreenAction::WipeRight
    }
}

I want to made a checkered cell pattern wipe across to the left, and then wipe to the right. But for now, I'll settle for a percentage in the middle of the screen. As always, it's good to start simple I think. We can update our main method to start using this new screen:

let action = match &current_screen {
    Screens::GameScreen => { ... },
    Screens::WinScreen => { ... },
    Screens::WipeScreen { from:_, to:_, duration } => {
        screens::wipe_screen(&mut wipe_progress, *duration, frame_context, &palette)
    }
};

The action is going to be one of the new wipe enums, but for now, we'll only deal with the done one since we don't need the other two yet. We need to tweak the change screen code to construct the from and to state and select the duration though:

match action {
    ScreenAction::ChangeScreen { to } => {
        wipe_progress = 0.0;
        current_screen = Screens::WipeScreen {
            from: Box::new(current_screen.clone()),
            to: Box::new(to),
            duration: 2.0,
        };
    },

And of course, once the transition is done, set the current screen to the new one we've transitioned to:

    ScreenAction::WipeDone => {
        let Screens::WipeScreen {
            from: _,
            ref to,
            duration: _,
        } = current_screen
        else {
            panic!("screen was not wipe!{:?}", current_screen)
        };
        current_screen = *to.clone();
    }
    ...
}

Is this pretty? No, not really. panic aside, having to use the ref keyword is sort of odd. Most of the time you don't have to, and I'm very grateful for the rust compiler because it was the one helping me solve a very weird error. But hey, one borrow checker fight later, and we've got the POC:

This doesn't look like much. But what if we make the wipe function actually do something related to its name? I'm thinking we flood some boxes in from one corner, and then drain them out the opposite one. This isn't too hard to do in code, we just need the almighty LERP function¹⁷!

let box_size = 60.0;
let num_boxes = screen_size / box_size;
let box_progress = *wipe_progress / duration;
let sin = lerp(0.0..=std::f32::consts::PI, box_progress);
let max_boxes_to_draw_x = 1 + lerp(0.0..=num_boxes.x, sin.sin()) as usize;
let max_boxes_to_draw_y = 1 + lerp(0.0..=num_boxes.y, sin.sin()) as usize;
let (even, odd) = palette.even_odd_color(0);
let in_first_half_of_animation = *wipe_progress < duration * 0.5;

for x in 0..max_boxes_to_draw_x {
    for y in 0..max_boxes_to_draw_y {
        let offset = if in_first_half_of_animation {
            vec2(x as f32, y as f32)
        } else {
            vec2(num_boxes.x - x as f32, num_boxes.y - y as f32)
        };
        let pos = offset * box_size;
        let color = if x % 2 == 0 { even } else { odd };
        gfx.rect()
            .color(Color::new(color))
            .size(vec2(box_size, box_size))
            .at(pos);
    }
}

This code is better understood with this quick sketch I think:

We've split the entire screen into a grid, similar to how we've done for the actual gameplay grid. The box size is arbitrary, and I'll probably tweak it, but the main thing is that I don't want to draw every box all at once. Rather, I want to limit the maximum number of boxes to draw based on how far along in our duration we are.

But, we want it to fill the entire screen, and then uh, unfill the entire screen. With the idea that we'll draw the current screen under it, and then draw the next screen during the second half of the animation so that it's revealed. If you're thinking about this in terms of progress, we're going from 0% to 100% and then back down to 0%. For me, this makes me think immediately of our friend the sin function! Because it goes from 0 to 1 as the angle goes from 0° to 180°, and thus the reason we call sin.sin().

A picture is worth a 1000 words and a video is worth a 1000 pictures:

It's a bit choppy, but it's got the spirit! But now for the hard part, the "under draw" as I'll call it. Unfortunately, unlike LibGDX's frame buffer the egor library doesn't expose a way to take a "screenshot" of the previously drawn screen and re-use it. So, in order to draw the screen we're transitioning away from underneath, we need to actually draw it.

Now, the way I set up the enums imply a sort of… Gross idea. Specifically, it implies this:

let action = match &current_screen {
    Screens::GameScreen => {
        screens::play_game_screen(&mut game_state, frame_context, &mut palette)
    }
    Screens::WinScreen => screens::win_screen(
        &mut game_state,
        frame_context,
        &palette,
        &mut debuggable_stuff,
    ),
    Screens::WipeScreen {
        from: _,
        to: _,
        duration,
    } => screens::wipe_screen(&mut wipe_progress, *duration, frame_context, &palette),
};
match action {
    ScreenAction::WipeLeft => {
        // DRAW UNDER SCREEN
        // DRAWN WIPE A SECOND TIME BECASUE OOPS WE'RE IN THE ACTION AREA
    },
    ...

This raises my alarm bells as gross and stupid. I mean, yes it's inefficient to have to draw the entire window underneath us, but we've resigned our fate to doing that since we have no frame buffer to save into with the layer of abstraction that egor is giving us. But drawing all those rectangles doing the wip twice? That's just going to look silly. Not to mention it's going to draw underneath the screen we're coming from too.

Also, how do we know which screen to draw? We've got the WipeScreen struct, so we can use from! But wait, that means we have to do a second match inside of the action match, but we already did this, and so now we're duplicating the action match we just did.

There must be another way!

Since we're drawing things OVER the other ones, then the drawing of the screens is no longer mutually exclusive. So, let's skip all the extra overcomplicate work and just raise a flag when we want the transition to be controlling which screen to render instead of the current screen.

let mut current_screen = Screens::GameScreen;
let mut wipe_progress = 0.0;
let mut show_wipe = false;
let mut last_action = ScreenAction::NoAction;

Then, if the show_wipe flag is set, we'll select the appropriate screen to draw. There must be a nicer way to do this, but at the moment I'm not good enough at rust to know it:

let screen_to_draw = if show_wipe {
    let Screens::WipeScreen {
        ref from,
        ref to,
        duration: _,
    } = current_screen
    else {
        panic!("screen was not wipe!{:?}", current_screen)
    };
    match last_action {
        ScreenAction::WipeLeft => from,
        ScreenAction::WipeRight | ScreenAction::WipeDone => to,
        _ => &current_screen,
    }
} else {
    &current_screen
};

But with that selection made, we can draw the screen and set the action based on the screen to draw, but then ignore it if we're currently wiping the screen for a transition:

let mut action = match screen_to_draw {
    Screens::GameScreen => {
        screens::play_game_screen(&mut game_state, frame_context, &mut palette)
    }
    Screens::WinScreen => screens::win_screen(
        &mut game_state,
        frame_context,
        &palette,
        &mut debuggable_stuff,
    ),
    _ => ScreenAction::NoAction,
};
if show_wipe {
    action = screens::wipe_screen(&mut wipe_progress, debuggable_stuff.transition_duration, frame_context, &palette);
}

and lastly, we set the show_wipe flag to avoid the panic case we added in above:

match action {
    ScreenAction::NoAction => {}
    ScreenAction::ChangeScreen { ref to } => {
        wipe_progress = 0.0;
        show_wipe = true;
        current_screen = Screens::WipeScreen {
            from: Box::new(current_screen.clone()),
            to: Box::new(to.clone()),
            duration: debuggable_stuff.transition_duration,
        };
    }
    ScreenAction::WipeDone => {
        let Screens::WipeScreen {
            from: _,
            ref to,
            duration: _,
        } = current_screen
        else {
            panic!("screen was not wipe!{:?}", current_screen)
        };
        show_wipe = false;
        current_screen = *to.clone();
    },
    _ => {}
};
last_action = action;

With this in place, the screen draws previous or next screen as it draws the wipe:

And that's… almost right. I mean, it is right, conceptually. We're calling the draw calls in the right order, but I suspect that the way egor actually implements the drawing is throwing us off here. Specifically, if you look in the documentation for any of the builders you'll spot this note:

Builder for XXX, drawn on Drop

Is the fact that the draw happens when the builder is dropped screwing with us somehow? But… that doesn't make sense, the builder is dropped when we return from the screen drawing function, isn't it? Wait… If we look at the source code:

impl<'a> RectangleBuilder<'a> {
    pub(crate) fn new(batch: &'a mut PrimitiveBatch) -> Self {

There's a life time here! And…

impl<'a> Graphics<'a> {
    ...
    /// Start building a rectangle primitive
    pub fn rect(&mut self) -> RectangleBuilder<'_> {
        RectangleBuilder::new(&mut self.batch)
    }

The liftime is tied to Graphics! And the graphics is pulled from the frame context, which lasts just as long as the entire closure, which means that all the draw calls get submitted for drawing at the same time? I suppose that makes sense for how the library expects to be used. Kind of. But also, not really. Does egor/egui really expect you to never have any overlapping parts?

Well dang. That's troublesome. There is a flush method that looks like it might be something I could use to maybe try to force this behavior, but it's private so I can't actually call it. I looked at the repository as well and I see that rendering to a texture is an idea floating around for the roadmap as of a few weeks ago, but that doesn't help us now sadly. I'm also not sure if what I'm seeing is a bug of my own making or something real that would be worth raising to the owner of the library¹⁸.

Hm. Well, for now, I guess we do have a screen position. And while I'm enjoying the simplicity of this library, I'm also getting the itch to go one step lower in a future project, so maybe this is okay for now and we'll come back to this later. The win screen isn't quite done yet, but before we can truly render what I want to render, we need to return to something we put off earlier¹⁹.

PPM Files for victory ↩

So earlier, we created a PBM file reader that stores the goal state of our logic paint board. I also said:

Mind you, we'll need to circle back to parse the ppm files later on for displaying the corresponding image, but let's stick to the core game logic first before we dive into the egor related graphics stuff!
- Peetseater in section 2 of the page you're reading.

As you may have surmised, it is time for us to circle back. I want to display the actual image of whatever puzzle the user just solved on the win screen! So, let's write up a NetBPM P3 file type parser! This will be mostly similar to the one we did before, but slightly more complected by the fact that it's not a list of 1s and 0s, but triplet tuples for RGB values! If you need a quick reminder, the files in this format look like this:

P3
# "P3" means this is a RGB color image in ASCII
# "3 2" is the width and height of the image in pixels
# "255" is the maximum value for each color
# Everything after that is the image data: RGB triplets.
3 2
255
255   0   0
  0 255   0
  0   0 255
255 255   0
255 255 255
  0   0   0

The code that we wrote for the PBM file parsing is really similar to this one, so similar, that we can basically copy paste most of it and only change the struct's types and add a field! Since the P3 format specifies the maximum value (up to 2³²), we have some new error codes to return if the file is set up incorrectly:

pub type PpmResult<T> = Result<T, LoadPpmErr>;
#[derive(Debug)]
pub enum LoadPpmErr {
    MissingHeader,
    InvalidHeader { found: String },
    MissingWidthError,
    MissingHeightError,
    InvalidWidthError { found: String, reason: String },
    InvalidHeightError { found: String, reason: String },
    InvalidMatrixSize { expected: usize, got: usize },
    UnexpectedCellValue { found: String },
    MissingColorRangeError,
    InvalidColorRangeError { found: String, reason: String },
	IncorrectCellTripletCount { expected: usize, got: usize },
}

And then, just like PBM, we'll do the parse within a FromStr implementation to support using the ?; style of result handling that we've done before. The header and comments are handled just the same:

impl FromStr for Ppm {
    type Err = LoadPpmErr;
    fn from_str(string: &str) -> PpmResult<Ppm> {
        /* Ignore comment lines, but grab all the characters out otherwise. */
        let mut characters = string
            .lines()
            .filter(|line| !line.trim_start().starts_with('#'))
            .flat_map(str::split_whitespace);

        let header = characters.next().ok_or(LoadPpmErr::MissingHeader)?;
        let "P3" = header else {
            return Err(LoadPpmErr::InvalidHeader {
                found: header.to_owned(),
            });
        };

As are the width and height parsing:

	let width = characters.next().ok_or(LoadPpmErr::MissingWidthError)?;
	let width = width
	    .parse::<usize>()
	    .map_err(|e| LoadPpmErr::InvalidWidthError {
	        found: width.to_owned(),
	        reason: e.to_string(),
	    })?;
	
	let height = characters.next().ok_or(LoadPpmErr::MissingHeightError)?;
	let height = height
	    .parse::<usize>()
	    .map_err(|e| LoadPpmErr::InvalidHeightError {
	        found: height.to_owned(),
	        reason: e.to_string(),
	    })?;

The new code for handling the value range is the same idea as the width and height:

	let max_value = characters
	    .next()
	    .ok_or(LoadPpmErr::MissingColorRangeError)?;
	let max_value =
	    max_value
	        .parse::<u16>()
	        .map_err(|e| LoadPpmErr::InvalidColorRangeError {
	            found: max_value.to_owned(),
	            reason: e.to_string(),
	        })?;

And then the cell parsing I do in two steps. First, we want to get the actual numbers out, one by one regardless of what triplet they belong to:

	let cells: Vec<u16> = characters
	    .map(|c| match u16::from_str_radix(c, 10) {
	        Ok(parsed_number) => {
	            if parsed_number > max_value {
	                Err(LoadPpmErr::InvalidColorRangeError {
	                    found: c.to_string(),
	                    reason: format!(
	                        "parsed number was out of range defined by ppm file min:0 max:{}",
	                        max_value
	                    )
	                    .to_string(),
	                })
	            } else {
	                Ok(parsed_number)
	            }
	        }
	        _ => Err(LoadPpmErr::UnexpectedCellValue {
	            found: c.to_owned(),
	        }),
	    })
	    .collect::<Result<_, _>>()?;

And then, since we know the we're working with triplets, we can use as_chunks to split the vector into triplets. Once again using the pattern matching of the let keyword to raise an issue if the cells don't match up properly and isn't a multiple of 3.

	let expected_count = width * height;
	let (cells, []) = cells.as_chunks::<3>() else {
	    return Err(LoadPpmErr::IncorrectCellTripletCount {
	        expected: expected_count * 3,
	        got: cells.len(),
	    });
	};
	let cells = cells.to_vec();

But this isn't quite enough! The above code just verifies we have triplets of data. We still need to confirm that we have the exact amount of triplets:

	let cells = cells.to_vec();
	// If we had triplets, but not the right width x height then raise
	if cells.len() != expected_count {
	    return Err(LoadPpmErr::InvalidMatrixSize {
	        expected: expected_count,
	        got: cells.len(),
	    });
	}

But, if our parsing code gets all the way past all of that, then we have a valid PPM file! So we can return it:

	Ok(Ppm {
	    width,
	    height,
	    cells,
	    max_value,
	})
}

As per usual, I wrote up a number of unit tests. Basically a copy paste job from the PBM file with a few tweaks. Just like the parsing code, we just need to add in new tests for the max value and that we're not checking out booleans anymore, but instead triplets… Wait a minute.

Wups. I didn't even show you the struct did I?

#[derive(Debug)]
pub struct Ppm {
    pub width: usize,
    pub height: usize,
    pub max_value: u16,
    pub cells: Vec<[u16; 3]>,
}

Since the Wikipedia page on Netpbm notes that 255 and 65535 are the typical range, I figure a u16 is an acceptable value. I suppose technically the page didn't say it couldn't go higher… But I think this is probably fine. I'm not exactly trying to make fine art here. Just pixel art!

Anyway. The tests, like I said, were mostly the same besides the differences between tracking booleans versus triplets, and the max value being tracked:

#[test]
fn fails_to_load_invalid_matrix_cell_oob() {
    let data = "P3\n1 1\n1\n3";
    let result: PpmResult<Ppm> = data.parse();
    match result {
        Err(LoadPpmErr::InvalidColorRangeError { found, reason }) => {
            assert_eq!(found, "3");
            assert_eq!(
                reason,
                "parsed number was out of range defined by ppm file min:0 max:1"
            );
        }
        weird => {
            panic!("Should not have parsed: {:?}", weird);
        }
    }
}

Let's skip all the other tests since there's really nothing interesting about them²⁰, and instead try to draw our cool new file. We'll use the one from section 2 of this post, which matches our 5x5 grid we've been using, and write up a quick render method. The good news is that this is actualy super easy because drawing squares with egor is super easy! We just need to convert the numbers into RGBA!

impl Ppm {
    pub fn rows(&self) -> Vec<Vec<[u16; 3]>> {
        ...
    }

    pub fn to_rgba(&self, cell: [u16; 3]) -> [f32; 4] {
        let max = self.max_value;
        let r = cell[0] as f32 / max as f32;
        let g = cell[1] as f32 / max as f32;
        let b = cell[2] as f32 / max as f32;
        [r, g, b, 1.0]
    }
}

Then, we just need to figure out the way to scale the image to whatever size we feel like. We've already basically done this with our cell grid drawing code before, so this isn't too hard to add into our UI module.

pub fn draw_ppm_at(ppm: &Ppm, top_left: Vec2, size: Vec2, gfx: &mut Graphics) {
    let num_boxes = ppm.rows().len();
    let gutter = 2.;
    let cell_size = (size.x - (gutter + gutter * num_boxes as f32)) / num_boxes as f32;

    for (r, row) in ppm.rows().into_iter().enumerate() {
        for (c, rgb) in row.iter().enumerate() {
            let position = top_left + vec2(c as f32, r as f32) * (Vec2::splat(cell_size) + gutter);
            gfx.rect()
                .at(position - gutter)
                .size(Vec2::splat(cell_size + gutter * 2.))
                .color(Color::new(ppm.to_rgba(*rgb)));
        }
    }
}

Then it's just a matter of passing the PPM down to the win screen code after loading the file within the main method and tweaking the signature of the method:

let test_ppm = read_to_string(filename_ppm)?;
let test_ppm: netppm::Ppm = test_ppm.parse()?;
...
let mut action = match screen_to_draw {
    ...
    Screens::WinScreen => screens::win_screen(
        &mut game_state,
        &test_ppm,
        frame_context,
        &palette,
        &mut debuggable_stuff,
    ),

and, arbitrarily, let's just draw it with a size of 450 and at 75 units in from the top left like we were doing the blank placeholder rectangle before:

pub fn win_screen(
    game_state: &mut PlayState,
    ppm: &Ppm,
    frame_context: &mut FrameContext,
    palette: &ColorPalette,
    debuggable_stuff: &DebugStuff,
) -> ScreenAction {
    ...
    draw_ppm_at(ppm, vec2(75., 75.), vec2(450., 450.), gfx);
    ...

It works! Our weird, shake weight dumbbell… thing. Is revealed for all to see in its glory! I'm not winning any design awards here for this layout. But I'm less interested in making something that looks super pretty, and more interested in exploring the idea of creating a game in rust with this blogpost. So, let's move onto our next important to-do list item.

Selecting which level to play ↩

On our win screen, we have the text "Return to Menu". This implies that we should have a menu! And more specifically, we should have a way for users to select the puzzle they want to play. Now, we've only really had 2 puzzles in play so far, the one I've been using as an example, and a 10x10 that I made by duplicating the 5x5 four times in order to validate our scaling.

We can save the idea of figuring out how to make these puzzles for later²¹, for now, I just want to make it possible for a user to pick between two. This will, of course, be a new screen for our system to show and so we'll be updating our enum:

pub enum Screens {
    ...
    ChooseLevelScreen,
}

Then update our main.rs loop that's matching these, and we'll drop in a function that doesn't work yet:

let mut action = match screen_to_draw {
    Screens::GameScreen => {...},
    Screens::WinScreen => {...},
    Screens::ChooseLevelScreen => {
         screens::level_select_screen(???)
    }
    _ => ScreenAction::NoAction,
};

Let's talk about what arguments we'll need for this guy to work properly. At the moment, within the main file we've just got these mutable buddies hanging out at the top level and getting rendered:

let test_ppm: netppm::Ppm = test_ppm.parse()?;
let mut game_state: gamestate::PlayState = (&test_pbm).into();
let mut debuggable_stuff = DebugStuff::new();
let mut palette = ColorPalette::meeks();
let mut current_screen = Screens::ChooseLevelScreen;
let mut wipe_progress = 0.0;
let mut show_wipe = false;
let mut last_action = ScreenAction::NoAction;

There's nothing wrong with these living at this level. But we do need to be able to more easily control them and bundle them. So I think it's time we formalize what a "level" is. A level is the combination of a PBM and PPM file, and maybe whether or not we've completed it or not. The PBM file is transformed into the current game state, so we can use that to seperate the mutable and immutable aspects of the current level. Basically, when we want to load a level we transform the fresh slate of the pbm file into a PlayState and set the top level game state.

One thing that's kind of nice in the miku paint game is that once you beat a puzzle, you can tell because it displays the image for you in the select menu. This is a nice feature that I'd like to have too, so we'll also include a flag in the level for whether or not the puzzle has been beat or not:

pub struct Level {
    pub info: Pbm,
    pub image: Ppm,
    pub completed: bool,
}

Now, as far as how I'll tell if something's completed or not goes… My first instinct is to just write out a little marker file. So we'd have the pbm, ppm, and then one more .data or something file. We could probably also just write out one file, and store the names of the levels that have been beaten so far. Either works I think, so we'll just do whatever's easiest. For now, let's ignore that and write up a function to look in a folder and load the levels it finds:

And by write up a function, I mean, sigh heavily and get reminded by read_dir that strings in rust, especially when dealing with the operating system's file handles, are really really annoying to work with. Hint:

use std::ffi::OsStr;
use std::fs::{ read_dir, read_to_string};
use std::path::Path;

We're going to do things the panicking unsafe way first, then we'll stop being lazy and make it work with better ergonomics once we can confirm we've loaded the level as expected. So, let me introduce you to our best friend for our task: with_extension this fella will be our bread and butter on how we load the level. But first, the (initial) signature:

pub fn load_levels_from_dir(dir: &Path) -> Vec<Level>

I say initial because we'll tweak it to return a result later, but for now, we'll be expecting a bunch to deal with bad loads. Though not always, in the case of the given path being a file in case of configuration error, we can just return an empty list to silently fail²²:

    if !dir.is_dir() {
        return vec![];
    }

    let dir_iter = read_dir(dir);
    if let Err(problem) = dir_iter {
        panic!("could not load levels {}", problem);
    }
    let dir_iter = dir_iter.unwrap();

I suppose it isn't actually completely silent. If the path is a directory but something like bad permissions or some other sort of nonsense happens we'll happily panic and explode. But, assuming we get past that, then we get to deal with the weird world of wrapped DirEntry:

	let mut level_files = Vec::new();
	for entry in dir_iter {
	    if let Ok(entry) = entry {
	        let path = entry.path();
	        match path.extension() {
	            Some(os_string) => {
	                if os_string.to_string_lossy() == "level" {
	                    level_files.push(path);
	                }
	            }
	            _ => {}
	        };
	    }
	}
	level_files.sort();

I call it weird because rather than getting something like Vec<DirEntry>, we're given a ReadDir<io::Result<DirEntry>>. The ReadDir struct is just an iterator, and that's fine, but that each individual entry is wrapped in a result is what feels weird to me. I suppose one could have permissions to read one thing and not the other, but it feels quite cumbersome to use.

Once we have the actual entry we can grab its path out. And then from that we can get the extension. But this is a weirdo too! It's not a regular string, because operating systems don't just work with "Strings" but rather with OsStr in order to deal with the nonsense jank that has accumulated over the years. Rust, unlike most languages, pushes this jank right into the programmers face. Every time it does it makes me sigh a bit. But anyway, once we have our paths to all files in a directory ending with .level we can load them:

    let mut levels = Vec::new();
    for level_file in level_files {
        match read_to_string(&level_file) {
            Err(problem) => {
                panic!("could not load level {:?} {:?}", &level_file, problem);
            }
            Ok(contents) => {
                // contents are completed 0 or 1, expected to be paired with pbm and ppm file of same name
                let completed = contents.trim() == "1";
                let ppm_file_path = level_file.with_extension("ppm");
                let pbm_file_path = level_file.with_extension("pbm");

                let pbm = read_to_string(&pbm_file_path)
                    .expect(&format!("could not read level file {:?}", &pbm_file_path));
                let pbm: Pbm = pbm
                    .parse()
                    .expect(&format!("could not parse level file {:?}", &pbm_file_path));

                let ppm = read_to_string(&ppm_file_path)
                    .expect(&format!("could not read level file {:?}", &ppm_file_path));
                let ppm: Ppm = ppm
                    .parse()
                    .expect(&format!("could not parse level file {:?}", &ppm_file_path));

                levels.push(Level {
                    info: pbm,
                    image: ppm,
                    completed: completed,
                });
            }
        }
    }

    levels
}

And now you can see why I said with_extension was our friend here. It let's us easily express that these three files in my levels directory are what makes up our game data:

levels/
    1.level  # <-- contains 0 or 1
    1.pbm    # <-- goal state data
    1.ppm    # <-- victory picture

If any of those files are missing, then we'll explode in a giant mess. Well, mostly messy since it panics, but somewhat better than unwrap() since we do raise a useful error not about which file was the problem! Though, since we've already loaded these Netpbm files before, we know they won't explode. To prove that, I can load my directory from my main method like so:

let level_dir_path = Path::new("./levels");
let levels = levels::load_levels_from_dir(level_dir_path);
println!("{:?}", levels);

Tada! Though the results are less than stellar if I tweak one of our files to be invalid:

thread 'main' panicked at src/levels.rs:61:22:
could not parse level file "./levels/1.pbm": UnexpectedCellValue { found: "0x" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Though, admittedly, still decently readable! Still… It leaves a bad taste in my mouth to leave an expect hanging around, not to mention the silent failure on a bad directory path. Imagine for a moment that you're a gamer. Ready to try out the latest and greatest in logic painting puzzle prowess from a fictional version of me that's known for these things. You're excited, wrapped up and warm in a blanket, one hand poking out from under the fuzz to guide the mouse.

You double click. The program fullscreens for a second, black screen popping up to show a loading window and then the game loads. You eagerly look at the level select, primed to pick the puzzle of your dreams and… there's nothing there.

Wwwhhhhhhhhyyyyyyyyy

Dramatics aside. It's a poor user experience. So is crashing to the desktop before ever loading. But eh. Better a crash with a useful trace than false hope and confusion. So let's refactor the code. Similar to the netpbm types, we'll create an enumeration to represent what can go wrong.

#[derive(Debug)]
pub enum LevelLoadError {
    Io {
        path: PathBuf,
        source: std::io::Error,
    },
    ParsePbm {
        path: PathBuf,
        source: LoadPbmErr,
    },
    ParsePpm {
        path: PathBuf,
        source: LoadPpmErr,
    },
    InvalidDirectory(PathBuf),
}

Analyzing our code and the .expect's that we have, we've got 4 main ways to explode. Two of which are parsing problems, and one is just a bad parameter input. The last one, or first one in our list, is just a generic wrapper around the io Errors that we can get from reading the directory itself, and in order for us not to lose context, we wrap the source up with it, just in case the io error itself doesn't include it (common in my experience). Next up, we can declare the return type of our function so that we can avoid the silent failures we've got now:

pub type LevelsLoadResult<T> = Result<T, LevelLoadError>;

While not strictly required, it's nice to implement Display to make the errors easy to print out if we ever need to:

impl std::fmt::Display for LevelLoadError {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        match self {
            LevelLoadError::Io { path, source } => {
                write!(f, "could not read {:?}: {}", path, source)
            }
            LevelLoadError::ParsePbm { path, source } => {
                write!(f, "could not parse PBM {:?}: {}", path, source)
            }
            LevelLoadError::ParsePpm { path, source } => {
                write!(f, "could not parse PPM {:?}: {}", path, source)
            }
            LevelLoadError::InvalidDirectory(path) => {
                write!(f, "{:?} is not a directory", path)
            }
        }
    }
}

And lastly, we can refactor the method to use all these new enums so that we can drop the panics and instead use ? to early return errors as needed:

pub fn load_levels_from_dir(dir: &Path) -> LevelsLoadResult<Vec<Level>> {
    if !dir.is_dir() {
        return Err(LevelLoadError::InvalidDirectory(dir.to_path_buf()));
    }

    let mut level_files: Vec<_> = read_dir(dir)
        .map_err(|e| LevelLoadError::Io {
            path: dir.to_path_buf(),
            source: e,
        })?
        .filter_map(|entry| {
            let path = entry.ok()?.path();
            path.extension()
                .is_some_and(|ext| ext == "level")
                .then_some(path)
        })
        .collect();

    level_files.sort();

    level_files
        .into_iter()
        .map(|level_file| -> LevelsLoadResult<Level> {
            let contents = read_to_string(&level_file).map_err(|e| LevelLoadError::Io {
                path: level_file.clone(),
                source: e,
            })?;

            let completed = contents.trim() == "1";

            let pbm_path = level_file.with_extension("pbm");
            let ppm_path = level_file.with_extension("ppm");

            let pbm: Pbm = read_to_string(&pbm_path)
                .map_err(|e| LevelLoadError::Io {
                    path: pbm_path.clone(),
                    source: e,
                })?
                .parse()
                .map_err(|e| LevelLoadError::ParsePbm {
                    path: pbm_path.clone(),
                    source: e,
                })?;

            let ppm: Ppm = read_to_string(&ppm_path)
                .map_err(|e| LevelLoadError::Io {
                    path: ppm_path.clone(),
                    source: e,
                })?
                .parse()
                .map_err(|e| LevelLoadError::ParsePpm {
                    path: ppm_path.clone(),
                    source: e,
                })?;

            Ok(Level {
                info: pbm,
                image: ppm,
                completed,
            })
        })
        .collect()
}

Admittedly, I do find it sort of bothersome having to write map_err twice with ? between when we read and parse the file, but logically it does make sense. There are two places for the error to propagate up, and so there are two places to map an error. If I didn't care about including the source path in the error, we could create a From implementation and be able to write the code like this:

... enum like ...
Pbm(LoadPbmErr)

... error usage like ...
let pbm: Pbm = std::fs::read_to_string(&pbm_path)?.parse()?;

But this results in useless errors that don't help us fix the problem like this:

Err(Pbm(UnexpectedCellValue { found: "0x" }))

Which is vastly inferior to the error we get like this:

Err(ParsePbm { path: "./levels/1.pbm", source: UnexpectedCellValue { found: "0x" } })

Knowing which level is the broken one is better for the player on the other side of the error if they're trying to load a custom level and running into trouble I think. Also, because this is no longer panicking, we could potentially display this information in a pop-up within the game itself, rather than crashing everything. We'd have to do more work if we wanted to make it possible to not let one bad apple spoil the bunch, but for now this is as far as I want to tidy it.

Anywho. Now that we're able to load the levels, let's get to work on displaying the options to the user in the screen's function. The way I see it, we've got a couple small things to keep track of for display purposes:

• Which page you're on for selecting a level
• How many levels we display per page (we'll probably hard code this)
• If the user wants to load a level or see the next page

Just like the other screen, I'm not overly concerned with making this look pretty. Just functional. Let's start by getting the lay of the land in place. We'll tweak the enum for the level select screen to include the page its showing:

pub enum Screens {
    ChooseLevelScreen {
        page: usize,
    },
}

Then we can pull that out and pass it down to the function:

Screens::ChooseLevelScreen { page } => {
    screens::level_select_screen(&levels, *page, frame_context, &mut game_state)
}

we'll plan to have a screen action to change the page, but before that, let's get the layout down. I'm thinking I'll just center everything for now:

pub fn level_select_screen(
    levels: &[Level],
    page: usize,
    frame_context: &mut FrameContext,
    current_level: &mut PlayState,
) -> ScreenAction {
    let levels_per_page = 15;
    let levels_per_row = 5;
    let levels_to_show = levels
        .iter()
        .skip(levels_per_page * page)
        .take(levels_per_page);

    let gfx = &mut (frame_context.gfx);
    let screen_size = gfx.screen_size();
    let center = screen_size / 2.;
    let title_text_position = center - vec2(0., screen_size.y / 4.);
    let level_bg_position = title_text_position + vec2(screen_size.x / -4., 72.);
    let level_bg_size = vec2(screen_size.x / 2., screen_size.y / 2.);

    gfx.camera().target(center);

    draw_centered_text(
        gfx,
        "Level Select",
        title_text_position,
        36.,
        Color::WHITE, // TODO: bring in the palette
    );

    gfx.rect()
        .at(level_bg_position)
        .size(level_bg_size)
        .color(Color::BLUE);

    ScreenAction::NoAction
}

As you can probably guess from my variable names, we're going to make 3 rows of 5 tiles to show an icon for each level. The user can click on these and this will load up the level for them. We've created a number of grids at this point, so the code to draw one out isn't too different, except for a bit of centering since this isn't a square grid so things don't fit perfectly into place like our play area:

let padding = vec2(10., 10.);
let level_tile_height = (level_bg_size.y - padding.y * 2.) / rows as f32 - padding.y * 2.;
let level_tile_size = vec2(level_tile_height, level_tile_height);
let centering_x_offset =
    (level_bg_size.x - (level_tile_height + padding.x) * levels_per_row as f32) / 2.;
let centering_y_offset = (level_bg_size.y - (level_tile_height + padding.y) * rows as f32) / 2.;

let anchor = level_bg_position + padding + vec2(centering_x_offset, centering_y_offset);
for (r, levels_in_row) in levels_to_show.chunks(levels_per_row).enumerate() {
    for (c, level) in levels_in_row.into_iter().enumerate() {
        let pos = anchor + vec2(c as f32, r as f32) * (level_tile_size + padding);
        gfx.rect().at(pos).size(level_tile_size).color(Color::GREEN);
    }
}

It's not quite perfectly centered vertically. But it's good enough I think. Now there's just one more graphical thing to do before we add interactivitiy. If we complete a level, we should show the winning image to the user as the icon! This is thankfully really easy since we already abstracted out a draw_ppm_at method:

let pos = anchor + vec2(c as f32, r as f32) * (level_tile_size + padding);
if level.completed {
    draw_ppm_at(&level.image, pos, level_tile_size, gfx);
} else {
    gfx.rect().at(pos).size(level_tile_size).color(Color::GREEN);
}

That's pretty good! Now, we just need to make them look more like buttons, and probably also come up with a simple "not completed" icon that isn't a green block. Maybe it's time for us to finally use the load_texture method? That or I just make an "unknown" ppm file and render that… actually that sounds pretty good. After all, the ppm files will share however large I feel like and we already have an easy way to load them!

Pasting 103 lines of triplets isn't something I feel like doing here but the good news is that loading it up once from the main method and then passing along the reference to it down to the screen function gets us something that actually feels like a real game!

let unknown_ppm = read_to_string("./assets/unsolved.ppm")?;
let unknown_ppm: netppm::Ppm = unknown_ppm.parse()?;
...
Screens::ChooseLevelScreen { page } => screens::level_select_screen(
    &levels,
    *page,
    frame_context,
    &mut game_state,
    &unknown_ppm,
),

Ok, and what about making them feel more like a button? How about we draw a rectangle underneath them to provide an outline highlight? Then, when we interact with it, we can make it behave like a shadow or pulse or whatever floats our boat in approximately 30 seconds?

let input = &mut (frame_context.input);
let (mx, my) = input.mouse_position();
let world_xy = gfx.camera().screen_to_world(Vec2::new(mx, my), screen_size);
let left_mouse_pressed = input.mouse_pressed(MouseButton::Left);

...
for (r, levels_in_row) in levels_to_show.chunks(levels_per_row).enumerate() {
    for (c, level) in levels_in_row.into_iter().enumerate() {
        let pos = anchor + vec2(c as f32, r as f32) * (level_tile_size + padding);
        let rect = egor::math::Rect::new(pos, level_tile_size);
        let highlight_color = if rect.contains(world_xy) {
            Color::BLACK
        } else {
            Color::WHITE
        };
        gfx.rect()
            .color(highlight_color)
            .at(pos - padding / 4.)
            .size(level_tile_size + padding / 4.);
        if level.completed {
            draw_ppm_at(&level.image, pos, level_tile_size, gfx);
        } else {
            draw_ppm_at(&unknown_ppm, pos, level_tile_size, gfx);
        }
    }
}

This actually feels pretty good. I mean, sure, it's very blue. But it's readable. Though we're missing something important. We need buttons to change the page! Honestly, we could use the PPMs to make a little sprite again (and I'm sorely tempted) but we could also use the polygon bulder to make some nice wide arrows and I think that might look nice. Let's find out!

Let's say that the button for the arrow is 30 units wide. We'll make it tall, like a big chevron that sits next to the level select area, rather than within it.

let btn_width = 30.;
let btn_size = vec2(btn_width, level_bg_size.y);
let previous_btn_position = level_bg_position - vec2(btn_width, 0.) - vec2(padding.x, 0.);
let next_btn_position = level_bg_position + vec2(level_bg_size.x, 0.) + vec2(padding.x, 0.);

I'll definitely want to refactor this code later, but for now, we'll just inline everything in the screen method while we're prototyping. Speaking of prototyping, let's just use simple colors for the background and foreground:

if page > 0 {
    let rect = Rect::new(previous_btn_position, btn_size);
    let (bg, fg) = if rect.contains(world_xy) {
        (Color::WHITE, Color::BLUE)
    } else {
        (Color::BLUE, Color::WHITE)
    };
    gfx.rect()
        .color(bg)
        .size(btn_size)
        .at(previous_btn_position);
    gfx.polygon().at(previous_btn_position + vec2(btn_width - btn_width/5., 10.))
        .points(
            &[
                vec2(0., 0.),
                vec2(-btn_width + btn_width/4., btn_size.y /2.),
                vec2(0., btn_size.y - 10.),
                vec2(0., 0.),
            ]
        ).color(fg);
}

then the next button will render if there are more levels to be had:

if levels.iter().skip(levels_per_page * (page + 1)).len() > 0 {
    let rect = Rect::new(next_btn_position, btn_size);
    let (bg, fg) = if rect.contains(world_xy) {
        (Color::WHITE, Color::BLUE)
    } else {
        (Color::BLUE, Color::WHITE)
    };
    gfx.rect().color(bg).size(btn_size).at(next_btn_position);
    gfx.polygon()
        .at(next_btn_position + vec2(btn_width / 5., 10.))
        .points(&[
            vec2(0., 0.),
            vec2(btn_width - btn_width / 4., btn_size.y / 2.),
            vec2(0., btn_size.y - 10.),
            vec2(0., 0.),
        ])
        .color(fg);
}

Being able to draw a triangle is probably something I could generalize, but let's see what it looks like first.

Hm.

It's not as nice looking as I would hope. For some reason I was thinking that a triangle would be smooth. I mean, it's three points. Instead it's very… pixel-y I guess. Makes me think that I should have made a ppm file instead. But… let's stay focused. We can always polish in the future after all, and it's not like making those buttons look better is going to change how prototype-jank-filled the rest of the vibe of the game gives off.

Let's just make sure the buttons work. It's pretty easy to do, we just create a mutable action and then set it over the course of the screen call.

let mut action = ScreenAction::NoAction;

... then inside the previous button if statement ...
if rect.contains(world_xy) && left_mouse_pressed {
    action = ScreenAction::PreviousPage;
}

...  and inside the next button if statement ...
if rect.contains(world_xy) && left_mouse_pressed {
    action = ScreenAction::NextPage;
}

There's nothing special about these two enums, so I'll skip their definition in the enums list, but we do need to update the match statement within main.rs's app loop to handle when we raise one of these signals up:

ScreenAction::NextPage => {
    let Screens::ChooseLevelScreen { page } = current_screen else {
        panic!("screen was not level select {:?}", current_screen);
    };
    current_screen = Screens::ChooseLevelScreen { page: page + 1 };
}
ScreenAction::PreviousPage => {
    let Screens::ChooseLevelScreen { page } = current_screen else {
        panic!("screen was not level select {:?}", current_screen);
    };
    current_screen = Screens::ChooseLevelScreen { page: page - 1 };
}

So long as we don't screw anything up, that page - 1 won't underflow the usize value. And at the moment, that's not hard to do! With all of that settled, we need to actually handle and create the action that this screen is all about, selecting a level! In order to work with the rest of the code, we'll need to somehow set the level to the clicked one. Which means setting both the game state, and the victory screen's eventual image:

pub fn level_select_screen(
    levels: &[Level],
    page: usize,
    frame_context: &mut FrameContext,
    current_level: &mut PlayState,
    current_win_image: &mut Ppm, <-- this is new!
    unknown_ppm: &Ppm,
) -> ScreenAction {
    ...
    for (r, levels_in_row) in levels_to_show.chunks(levels_per_row).enumerate() {
        for (c, level) in levels_in_row.into_iter().enumerate() {
            ...
            if rect.contains(world_xy) && left_mouse_pressed {
                action =  ScreenAction::ChangeScreen { to: Screens::GameScreen };
                let to_load: PlayState = (&level.info).into();
                *current_level = to_load;
                *current_win_image = level.image.clone();
            }
    ...

After creating a reference in the main loop, and also adding #[derive(Debug, Clone)] to the Ppm struct so that .clone() will work. This all compiles! And, it works!

It does feel a little gross though. Not to mention a little misleading variable wise. We're definitely accruing technical debt here. But we're also making good progress. Such is the balance of things, it's not that I don't like that we're passing in something to be mutated, with an immediate mode UI it feels very much like a natural given unless we structure our program a different way. But rather than we mutate TWO things based on one action, and conceptually those two things are really the same thing. You know?

Before we shift our attention to cleaning up our mess, I think it's important we not only tweak the other screen's return to menu button to send us to the right place, but also that we mark a level as completed! Let's do both of those things now, one is a one line change:

pub fn win_screen(
    ...
) -> ScreenAction {
    ...
    if left_mouse_pressed && should_highlight {
        // Tmp go back to game screen for now
        ScreenAction::ChangeScreen {
            to: Screens::ChooseLevelScreen { page: 0 },
        }
    } else {
        ScreenAction::NoAction
    }

Okay I guess technically we deleted our todo comment too, but whatever. It doesn't really set us up to send the user back to the potential page their level was on in the past, but that's okay. We could probably figure that out if we really wanted to, but it's very low on the list of priorities to me. More importantly, when we hit that win screen, we ought to mark the level as done! Or maybe, when we trigger the change over to the win screen?

I think maybe what we should do is represent this as a screen action. If we do this, then we can tweak the win screen code to send the signal to mark the level complete on each frame:

if left_mouse_pressed && should_highlight {
    ScreenAction::ChangeScreen {
        to: Screens::ChooseLevelScreen { page: 0 },
    }
} else {
    ScreenAction::MarkLevelComplete
}

Obviously, we don't want to open the file and write out to it every frame. That'd probably tank the FPS and also ruin the hard drive of whoever's running the game! But we can handle that "do this once" type behavior by using the Level struct itself. Except, there's an important detail we're glossing over by accident:

How do we tell which file to update?

We loaded the files, but we didn't actually keep track of a name or path to write back to, did we? Wups. We can fix this pretty easily, it's just a matter of tweaking the struct and loading method,

pub struct Level {
    pub info: Pbm,
    pub image: Ppm,
    pub completed: bool,
    pub path: PathBuf,
}

and a teeny tweak to the load_levels_from_dir method's final assignmet:

level_files
    .into_iter()
    .map(|level_file| -> LevelsLoadResult<Level> {
        ...
        Ok(Level {
            info: pbm,
            image: ppm,
            completed,
            path: level_file.clone(),
        })
    })
    .collect()

Besides being able to have a handle on which file we need to update to persist the change itself, we also now have an easy way to distinguish the levels from each other besides comparing their entire PBM file or similar. Also a boon.

let mut current_level = levels[0].path.clone(); // tmp garbage for now
...
match action {
    ...
    ScreenAction::MarkLevelComplete => {
        let found_level = levels.iter_mut().find(|level| level.path == current_level);
        if let Some(played_level) = found_level {
            if !played_level.completed {
                played_level.completed = true;
                // TODO: Persist this to the file
            }
        }
    }
    ...

This gets us almost all the way there. But we need to update the level_select_screen to pass the new path down just like we did the game_state and win_image so that the level select code can mutate it on the fly whenever we change the level. Otherwise we'd end up updating the wrong level all the time.

pub fn level_select_screen(
    levels: &[Level],
    page: usize,
    frame_context: &mut FrameContext,
    current_level: &mut PlayState,
    current_win_image: &mut Ppm,
    current_path: &mut PathBuf,
    unknown_ppm: &Ppm,
) -> ScreenAction {
    ...
    if rect.contains(world_xy) && left_mouse_pressed {
        action = ScreenAction::ChangeScreen {
            to: Screens::GameScreen,
        };
        let to_load: PlayState = (&level.info).into();
        *current_level = to_load;
        *current_win_image = level.image.clone();
        *current_path = level.path.clone();
    }
    ...

While this growing list arguments is begging for a parameter object refactor, we're not done yet. This does set the completed flag when we finish a level

But if I restart the program it blows it away. So, to really call this done, we need to write one more little helper method:

use std::fs::write;

impl Level {
    pub fn mark_completed(&mut self) -> std::io::Result<()> {
        self.completed = true;
        write(&self.path, "1")
    }
}

And call it at the same time as when we mark the level completed.

ScreenAction::MarkLevelComplete => {
    let found_level = levels.iter_mut().find(|level| level.path == current_level);
    if let Some(played_level) = found_level {
        if !played_level.completed {
            played_level.mark_completed().expect("could not persist level completion")
        }
    }
}

And just like that. The completed levels now persist through play sessions. Excellent! ²³

A level editor ↩

If you've been paying attention to the videos in the level building section you may have noticed something.

Each of the completed levels are the same. This is because every single level is the same. For the sake of testing I ran a little bash script that basically did this 15+ times:

cp 1.level 2.level
cp 1.pbm 2.pbm
cp 1.ppm 2.ppm

But obviously, I'd like to have different levels for users to enjoy! But, I'm not sure if you could guess, but writing out the BPM and PPM files by hand is a bit of a pain in the butt. Not terribly difficult, and in fact the unsolved.ppm file I made by doing the bpm of the shape I wanted first, and then doing a find and replace on the 1 and 0's to the gray triplets I wanted. Shocking, I know, but you may have suspected it when you saw that the ppm was only two colors.

Speaking of not terribly difficult, the way we used draw_ppm_at got me thinking:

Why don't I make an easy ppm paint program?

Nothing as complicated as MSPaint ²⁴, but a bit of egui color picker and sliders and friends can probably enable us to make a simple tool to construct our levels. Up to this point, we've only had a single main method though, but luckily for us, we should be able to make an extra bin folder and create an extra binary to run for this. Unluckily for us, the way that I've been declaring out modules so far has made everything private to the main main.rs file.

So, first things first. We need to create a src/lib.rs file to move some of the code around so that we can easily share things like the Netbpm format structs around. The short way to describe things is that we have to create src/lib.rs with the contents of:

pub mod gamestate;
pub mod levels;
pub mod netbpm;
pub mod netppm;
pub mod screens;
pub mod ui;

And then, we tweak the src/main.rs file to do use XXX instead of mod XXX that we had before. This will all almost work. But because we're now using a lib.rs file, everything in the main.rs file is private to itself. This means that our screen methods that were relying on our helpful mutable debugging struct now run into this:

error[E0432]: unresolved import `crate::DebugStuff`
 --> src/screens.rs:1:5
  |
1 | use crate::DebugStuff;
  |     ^^^^^^^^^^^^^^^^^ no `DebugStuff` in the root

While I'm not actively using most of this, the debugging on the colorpalette is something I still appreciate and may want to use later on when we're doing any sort of polishing. So, for now, I just shifted over the entirety of the debug struct and its helper window into the src/ui.rs file and updated the imports. With that done, we can begin thinking about our level editors.

Let's start small, let's not think too much about loading and changing existing levels, instead, let's think about just making new ones and saving the output. Since the BPM and PPM are interconnected, it would make sense to me if the user edits them both at the same time. Though, we won't translate any clicks from each grid to the other automatically. I mean, look at an example grid vs its image in the miku game:

You can see how the simple binary colors set up the shape, but then when we actually look at the image there's plenty of colors to define the shading and details that make you say: aaah I see the penguin!

Looking at the pixel art, it occurs to me that a good idea for a feature would be to show the used colors so far in the PPM file as a palette for the user to select from, that way it's easy to select and draw the pixel art without having to fuss around with the RGBa color wheel too often. So, here's our list of MVP requirements for our tool:

1. Display PPM and PBM files next to each other
2. Save button to save files
3. Color selector for current color
4. Display colors in-use in PPM, allow re-selecting as current
5. Able to edit PBM and PPM by clicking to fill cell with color

While looking at the egui home page for a reference about how to make a textbox for the filename, I noticed an interesting pattern in the code example source. Creating a ui function in the struct implementation to avoid having to write &mut everywhere all the time. This also seems like a nicer way of doing what we were doing with the DebugStuff before too! Let's give it a try:

struct LevelSettings {
    width: usize,
    height: usize,
    filename: String,
    current_color: [f32; 4],
    lru_colors: Vec<[f32; 4]>,
    max_colors: usize,
}

And we can define an implementation function for the ui to render using &mut self in order to avoid all the boilerplate and all the passing around. Rendering some of the simple fields is easy, since we've done this before with the DebugStuff struct. The width, height, and color for example are simple:

impl LevelSettings {
    fn ui(&mut self, ui: &mut Ui) {
        ui.add(Slider::new(&mut self.width, 5..=20).text("Level Width"));
        ui.add(Slider::new(&mut self.height, 5..=20).text("Level Height"));

        ui.separator();

        ui.label("Color: ");
        ui.color_edit_button_rgba_unmultiplied(&mut self.current_color);

        ui.separator();

But this is the first time we've used the horizontal helper, which allows us to put two widgets next to each other side by side:

        ui.horizontal(|ui| {
            ui.label("Filename (no extension)");
            ui.add(TextEdit::singleline(&mut self.filename));
            if ui.button("Save").clicked() {
                // TODO: Save out to file!
            }
        });

        ui.separator();
        ui.label("Current Palette:");

This isn't too bad, but one thing that was interesting to figure out was how to render the color palette! The LevelSettings field lru_colors is meant to track the used colors so far in the PPM file that we're making. So it would be nice if these were buttons that were the color of what you are getting, kinda of like a paint palette.

Figuring out how to do this involved hunting down this github issue and then extrapolating from that and staring at the WidgetVisuals documentation. But with their power combined we get this:

        for mut color in &mut self.lru_colors {
            ui.horizontal(|ui| {
                ui.scope(|ui| {
                    ui.style_mut().visuals.widgets.inactive.weak_bg_fill =
                        Rgba::from_rgba_unmultiplied(
                            color[0], color[1], color[2], color[3],
                        )
                        .into();
                    if ui.button("Select").clicked() {
                        self.current_color = color.clone();
                    }
                })
            });
        }
    }
}

All the styles used within a ui scope, can be controlled by the visuals field. Sinec buttons are widgets, we can control their properties from there, and then it was a matter of trial and error to figure out if we needed to modify weak_bg_fill or bg_fill. I went with bg_fill but it didn't work, so, "weak" it was! And then, like magic:

This of course uses some Default data I setup:

impl Default for LevelSettings {
    fn default() -> LevelSettings {
        LevelSettings {
            width: 10,
            height: 10,
            filename: String::from("test"),
            current_color: [0., 0., 0., 1.0],
            lru_colors: vec![[0., 0., 0., 1.0], [1., 0., 0., 1.0], [0., 1., 1., 1.0]],
            max_colors: 12,
        }
    }
}               

We'll empty out the lru_colors soon, but first we need to work on getting the level data shown for editing purposes. One thing that I think is important before we start working on this is that I don't know if we'll actually re-use our existing Pbm and Ppm structs, for one specific reason:

When you slide the sliders to control width and height, what happens to the cell data of the cells that are being trimmed away? If I accidentally slide something over, do I lose ALL the data for the pretty picture I was drawing? That seems awful, and frustrating! So I think we actually want to work slices of a full 20x20 level, and then export only the width and height that we've chosen.

We can create a seperate struct to track this information. And since the PBM and PPM sizes must be the same in order for this to work, let's just track it all together as one struct:

struct EditorGrids {
    pbm_grid: Vec<Vec<bool>>,
    ppm_grid: Vec<Vec<[f32; 4]>>,
    size: Vec2,
    top_left: Vec2,
}

I wanted to use [[[f32;4]; 20]; 20] but I couldn't remember how to do this without typing out false 400 times, so I opted to stick with vectors for the time being, and initialize them with some simple default properties:

impl Default for EditorGrids {
    fn default() -> EditorGrids {
        let mut pbm_grid = Vec::with_capacity(20);
        let mut ppm_grid = Vec::with_capacity(20);

        for _ in 0..20 {
            let mut pbm_row = Vec::with_capacity(20);
            let mut ppm_row = Vec::with_capacity(20);
            for _ in 0..20 {
                pbm_row.push(false);
                ppm_row.push([0.0, 0.0, 0.0, 1.0]);
            }
            pbm_grid.push(pbm_row);
            ppm_grid.push(ppm_row);
        }

        EditorGrids {
            pbm_grid,
            ppm_grid,
            size: vec2(400., 400.),
            top_left: vec2(400., 120.), // [ 400 + 400 + gutter + 400 ]
        }
    }
}

The position and size values are magic numbers, but I think it's okay to hard code these for now since it's not like we're moving these grids around on the screen dynamically at all. Just their contents! For drawing purposes, even though we'll be using the Graphics of the frame context, and not the ui.* methods, I'll stick with the pattern and call the function ui:

To start, we can just render the general shape of what we want. Which is two grids, side by side, not overlapping with our tool window:

impl EditorGrids {
    fn ui(&mut self, frame_context: &mut FrameContext, level_settings: &mut LevelSettings) {
        let gfx = &mut (frame_context.gfx);
        let pbm_anchor = self.top_left;
        gfx.rect()
            .at(pbm_anchor)
            .size(self.size)
            .color(Color::WHITE);

        let ppm_anchor = pbm_anchor + vec2(400. + 50., 0.);
        gfx.rect()
            .at(ppm_anchor)
            .size(self.size)
            .color(Color::WHITE);
    }
}

Then we can define the grid, and call the ui function to actually render it from the main app loop:

Window::new("Settings")
    .anchor(Align2::LEFT_TOP, egor::app::egui::Vec2::ZERO)
    .default_size([100.0, 500.0])
    .show(egui_ctx, |ui| {
        level_settings.ui(ui);
        grids.ui(frame_context, &mut level_settings);
    });

And then we can work on drawing the actual grids themselves, starting with the simple PBM which also has a simple interaction with the mouse click:

fn ui(&mut self, frame_context: &mut FrameContext, level_settings: &mut LevelSettings) {
    ...
    let input = &mut (frame_context.input);
    let left_mouse_pressed =
        input.mouse_pressed(MouseButton::Left) || input.mouse_held(MouseButton::Left);
    let right_mouse_pressed =
        input.mouse_pressed(MouseButton::Right) || input.mouse_held(MouseButton::Right);
    let (mx, my) = input.mouse_position();
    let screen_size = gfx.screen_size();
    let world_xy = gfx.camera().screen_to_world(Vec2::new(mx, my), screen_size);

    let num_boxes_x = level_settings.width;
    let num_boxes_y = level_settings.height; // TODO: maybe just always have a square
    let gutter = 2.;
    let cell_size = (self.size.x - (gutter + gutter * num_boxes_x as f32)) / num_boxes_x as f32;
    let cell_size = Vec2::splat(cell_size);

    let pbm_anchor = self.top_left;
    gfx.rect()
        .at(pbm_anchor)
        .size(self.size)
        .color(Color::WHITE);

    let pbm_anchor = pbm_anchor + gutter;
    for r in 0..num_boxes_y {
        for c in 0..num_boxes_x {
            let position = pbm_anchor + vec2(c as f32, r as f32) * (cell_size + gutter);
            let color = if self.pbm_grid[r][c] {
                Color::RED
            } else {
                Color::BLACK
            };

            if Rect::new(position, cell_size).contains(world_xy) && left_mouse_pressed {
                self.pbm_grid[r][c] = true;
            }
            if Rect::new(position, cell_size).contains(world_xy) && right_mouse_pressed {
                self.pbm_grid[r][c] = false;
            }

            gfx.rect().at(position).size(cell_size).color(color);
        }
    }
    ...

The red color is just to make life easy and obvious for us while we work. The rest of the code is the same sort of grid drawing code we've done this entire time. One nice trick is that the mouse pressed and mouse held makes life easier on the fingers, because you don't have to click every cell, instead you can just drag to draw a line, which makes making red blobs like this, easy:

The ppm drawing code is similar for the grid itself, though we'll need to think harder about the interaction between clicks and the cells (but not too much harder). One thing that's nice about the full capacity of the grid, and that we're limiting the updates to the width and height that the level settings define, is that we preserve anything out of bounds, so you don't lose work:

This is great! What's less great, is that I'm starting to think the answer to the // TODO: maybe just always have a square is Yes, we should just have a square and not have to think about weird awkward shapes. We can circle back to that in a bit, let's get the PPM drawing working. And by "working" I mean, we won't do the LRU related thing yet

let ppm_anchor = pbm_anchor + vec2(400. + 50., 0.);
gfx.rect()
    .at(ppm_anchor)
    .size(self.size)
    .color(Color::WHITE);

let ppm_anchor = ppm_anchor + gutter;
for r in 0..num_boxes_y {
    for c in 0..num_boxes_x {
        let position = ppm_anchor + vec2(c as f32, r as f32) * (cell_size + gutter);

        if Rect::new(position, cell_size).contains(world_xy) && left_mouse_pressed {
            self.ppm_grid[r][c] = level_settings.current_color;
        }
        if Rect::new(position, cell_size).contains(world_xy) && right_mouse_pressed {
            self.ppm_grid[r][c] = [0.0, 0.0, 0.0, 1.0];
        }
        let rgb = self.ppm_grid[r][c];

        gfx.rect()
            .at(position)
            .size(cell_size)
            .color(Color::new(rgb));

    }
}

This is enough for the basics to work, preserve things out of bounds as needed, and draw any 20x20 pixel art picture one might want to make:

Once again, the potential for the height to be higher than the width is causing some funny things to happen. But, before we fix that, let's finish the base functionality by making the save button work. Since I don't want to interupt the drawing of the ui settings with an early return or with a call out to write files mid-frame, let's return an action and act on it from the main loop. Our new actions are simple:

pub enum UiActions {
    Nothing,
    SaveLevel,
}

As is the usage:

impl LevelSettings {
    pub fn ui(&mut self, ui: &mut Ui) -> UiActions {
        let mut result = UiActions::Nothing;
        ...
        if ui.button("Save").clicked() {
            result = UiActions::SaveLevel;
        }
        ...
        result
    }
}

But we don't have an actual save method yet. Or a way to convert the grid into a file, so let's work on that. Like I said before, we'll only save the defined region by the height and width, so it makes sense to me for us to make a temporary copy of what we're saving, and if we're going to be saving the data out to the ppm and pbm files for the level, I think it makes sense to create the serialization to a string in those struct's helper methods.

We already implemented a FromStr implementation, and if you read the Display documentation, it does seem to suggest a trait for us to implement to do just that:

However, if a type has a lossless Display implementation whose output is meant to be conveniently machine-parseable and not just meant for human consumption, then the type may wish to accept the same format in FromStr, and document that usage. Having both Display and FromStr implementations where the result of Display cannot be parsed with FromStr may surprise users.

Thankfully, the PBM and PPM file formats are so simple, that these are both easy to make:

impl std::fmt::Display for Pbm {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> Result<(), std::fmt::Error> {
        write!(f, "P1\n{} {}\n", self.width, self.height)?;
        for cell in &self.cells {
            write!(f, "{}\n", if *cell { "1" } else { "0" })?;
        }
        Ok(())
    }
}

impl std::fmt::Display for Ppm {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> Result<(), std::fmt::Error> {
        write!(f, "P3\n{} {}\n{}\n", self.width, self.height, self.max_value)?;
        for [r,g,b] in &self.cells {
            write!(f, "{} {} {}\n", r,g,b)?;
        }
        Ok(())
    }
}

So then, we just need to write up a conversion method to create Pbm and Ppm structs from the grids the level editor is tracking. Once we have that in place, then we can construct a Level struct, and then implement a simple save method:

impl Level {
    pub fn save(&self) -> std::io::Result<()> {
        write(&self.path, "0")?;
        let pbm_path = self.path.with_extension("pbm");
        let ppm_path = self.path.with_extension("ppm");
        write(&pbm_path, format!("{}", self.info))?;
        write(&ppm_path, format!("{}", self.image))?;
        Ok(())
    }
}

So, let's fill in the missing link. The conversion of the editor data to a Level we can save. I think a relatively nice way to organize this is with a handy caller of our above save function, that will in turn, use into to do some of the conversions.

 <pre>               
pub fn save_grid_as_level(level_settings: &LevelSettings, grids: &EditorGrids) -> Level {
    let ppm = grids.into();
    let pbm = grids.into();
    let path: PathBuf = ["./levels", &level_settings.filename, ].iter().collect();
    Level {
        info: pbm,
        image: ppm,
        completed: false,
        path: path.with_extension("level"),
    }
}

This code won't compile yet:

error[E0277]: the trait bound `Pbm: From<&EditorGrids>` is not satisfied
   --> src/bin/level_editor/editor_grids.rs:117:21
    |
117 |     let pbm = grids.into();
    |                     ^^^^ the trait `From<&EditorGrids>` is not implemented for `Pbm`
    |
    = note: required for `&EditorGrids` to implement `Into<Pbm>`

error[E0277]: the trait bound `Ppm: From<&EditorGrids>` is not satisfied
   --> src/bin/level_editor/editor_grids.rs:116:21
    |
116 |     let ppm = grids.into();
    |                     ^^^^ the trait `From<&EditorGrids>` is not implemented for `Ppm`

But I do love how the compiler helps drive our development process here. Oh, you want to convert one type to the other? You'll need to satisfy this trait bound to do that! It's so handy! And so, we can follow along with what it's asking us to do:

impl From<&EditorGrids> for Pbm {
    fn from(e: &EditorGrids) -> Pbm {
        // .... WAAAIT
        Pbm {
            width: usize,
            height: usize,
            cells: Vec<bool>,
        }
    }
}

But wait a minute. We need more information than this, we need both the editor grid AND the level settings to do this. I suppose I could do this:

let ppm = (level_settings, grids).into();
let pbm = (level_settings, grids).into();

But I do kind of wonder if I'm bending this backwards to use into here, rather than just having a ppm_from(level_settings, grids) sort of function. But I mean, naming that function makes me think level_settings_and_grid_to or ppm_from_grid_and_settings or something like that. And well, the From semantics match that without me having to contort into the verbosity of an average Enterpise™ Java programmmer to name the function.

Alright let's just use a From + tuple manuever. The Pbm file is simple and easy as we're working with a grid of booleans either way, so there's no conversion:

impl From<(&LevelSettings, &EditorGrids)> for Pbm {
    fn from(tuple: (&LevelSettings, &EditorGrids)) -> Pbm {
        let (level_settings, grids) = tuple;
        let width = level_settings.width;
        let height = level_settings.height;

        let mut cells = Vec::with_capacity(height * width);
        for r in 0..height {
            for c in 0..width {
                cells.push(grids.pbm_grid[r][c]);
            }
        }

        Pbm {
            width,
            height,
            cells,
        }
    }
}

For the PPM file we do need to convert things a bit. The Rgba code from the color selector is expressed as an f32 and we need to convert that over into a u16. So something like [0.0, 0.0, 1.0, 1.0] becomes 0 0 255. Sounds like a great opportunity to lerp:

fn percent_to_u16(t: f32, max_value: f32) -> u16 {
    (t.clamp(0.0, 1.0) * max_value).round() as u16
}           

Only thing of note there is that we round since if we just did as, we'd truncate something like 254.745 to 254, which feels wrong since that funny decimal number is actually what you get from doing 0.999 * 255.. Anyway, with that ability to go from a number from the range of 0 to 1 to the 0 to 255 range, we can write our Ppm code:

impl From<(&LevelSettings, &EditorGrids)> for Ppm {
    fn from(tuple: (&LevelSettings, &EditorGrids)) -> Ppm {
        let (level_settings, grids) = tuple;
        let width = level_settings.width;
        let height = level_settings.height;
        let mut cells = Vec::with_capacity(height * width);
        let max_value = 255.;

        for r in 0..height {
            for c in 0..width {
                // [0.15354905, 0.13828914, 0.6661099, 1.0]
                let rgba = grids.ppm_grid[r][c];
                let r: u16 = percent_to_u16(rgba[0], max_value);
                let g: u16 = percent_to_u16(rgba[1], max_value);
                let b: u16 = percent_to_u16(rgba[2], max_value);
                cells.push([r, g, b]);
            }
        }

        Ppm {
            width,
            height,
            max_value: max_value as u16,
            cells,
        }
    }
}

I'm sort of arbitrarily choosing 255 as our maximum value, even though we could go up to the higher range of 65535, my brain still thinks mostly in simple RGB mode that the web uses. Anyway, easy! Now the code compiles and we just have to call the save method!

match level_settings.ui(ui) {
    UiActions::Nothing => {}
    UiActions::SaveLevel => {
        let level = save_grid_as_level(&level_settings, &grids);
        level.save();
    }
}               

Although, considering that I have to call save after using our new function, I think I've named it wrong. So, I'll rename that in a moment, but first, the test!!!

The PBM file writes out each value in the column, row by row, and all in one go. I suppose we could tweak it to print more like a "grid" like I had in my hand made one which was a little easier to check and confirm, but it is correct. What about the PPM?

Yup! This matches things up! Ok, so final test, if open up the game, since we wrote this into the levels folder, I should be able to select and play it in the game itself:

Besides the fact that this just revealed a bug in our save code, it works! Let's fix the save method to not mark the level as completed instantly.

pub fn save(&self) -> std::io::Result<()> {
    write(&self.path, "1")?;
    write(&self.path, "0")?;
    let pbm_path = self.path.with_extension("pbm");
    let ppm_path = self.path.with_extension("ppm");
    write(&pbm_path, format!("{}", self.info))?;
    write(&ppm_path, format!("{}", self.image))?;
    Ok(())
}

And we've proven that our level editor works and can be used to make a level! Awesome! But there's a bit more work to be done before we call it good to ship. Mainly, our concept of the most recently used colors showing up in a palette/what is being used in the PPM file powering that list.

I don't want to pull out the unique colors from the ppm display each frame, that'd be wasteful and silly, so rather than that, let's create a new enum to tell the system to pull out the colors as needed. Specifically, when we click the "Select" button on the panel that changes the color palette we can raise this up, as well as if we modify the current color

pub fn ui(&mut self, ui: &mut Ui) -> UiActions {
    ...
    ui.label("Color: ");
    let previous_color = self.current_color.clone();
    ui.color_edit_button_rgba_unmultiplied(&mut self.current_color);
    if previous_color != self.current_color {
        result = UiActions::RecomputePalette;
    }
    ...
    for color in &mut self.lru_colors {
        ...
        ui.horizontal(|ui| {
            ui.scope(|ui| {
                if ui.button("Select").clicked() {
                    self.current_color = color.clone();
                    result = UiActions::RecomputePalette;
                }
            })
        });
    }
    ...
}

And then, well, what I'd like to do is use something like a hash set, but unfortunately for us:

the trait bound `f32: Eq` is not satisfied

If we attempt to use that with an f32 value. So I guess, rather than using a hashset, we'll use a hashmap and compute a key that should work properly for our purposes. We can take advantage of the fact that we already have a handy dandy function to convert the floats into u16s, and then…

impl EditorGrids {
    pub fn unique_colors(&self) -> Vec<[f32; 4]> {
        let mut unique = HashMap::new();
        for row in &self.ppm_grid {
            for &[r, g, b, a] in row {
                // each value is u16, 16 * 4 = 64 and so...
                let key =
                    (percent_to_u16(r, 255.) as u64) << 48 |
                    (percent_to_u16(g, 255.) as u64) << 32 |
                    (percent_to_u16(b, 255.) as u64) << 16 |
                    (percent_to_u16(a, 255.) as u64);
                unique.insert(key, [r, g, b, a]);
            }
        }
        unique.into_values().collect()
    }

There's probably other ways we could make a key, but I figure since we have 4 values of 16, and u64s are right there that we could use that. Once we've got the unique values in the hashmap, it's just a matter of returning them which is easy. Then, we can use them:

match level_settings.ui(ui) {
    UiActions::Nothing => {}
    UiActions::RecomputePalette => {
        level_settings.refresh_palette_with(grids.unique_colors());
    }
    UiActions::SaveLevel => {
        let level = save_grid_as_level(&level_settings, &grids);
        level.save();
    }
}

And then we just need to make that refresh method to update the color list itself

pub fn refresh_palette_with(&mut self, unique_colors: Vec<[f32; 4]>) {
    self.lru_colors = unique_colors;
}

Also, I originally was planning on us guarding against too many colors at once with that max_colors thing, but honestly, I don't think we need it. So we can just remove it from the code and if someone REALLY wants to draw a PPM color with so many colors that it makes the palette selector unwieldly, then they can go for it.

For now though, this is almost done. While I think I'll only ever make square levels, I suppose the easy way to fix the bleed is to make the cell size respect the height and not only base themselves on the width:

impl EditorGrids {
    pub fn ui(&mut self, frame_context: &mut FrameContext, level_settings: &mut LevelSettings) {
        ...
        let cell_size_x = (self.size.x - (gutter + gutter * num_boxes_x as f32)) / num_boxes_x as f32;
        let cell_size_y = (self.size.y - (gutter + gutter * num_boxes_y as f32)) / num_boxes_y as f32;
        let cell_size = vec2(cell_size_x, cell_size_y);
        ...

This fixes the display so that you end up with the right image, and not the left:

Again, I don't think this looks very good. But for the sake of it, I'll let is be fixed this way instead of forcing all images to always be square. Who knows, maybe when I start making levels I'll want to make some funny shaped guys. Time will tell.

What we can't tell right now though, is when you've actually saved the level!

warning: unused `Result` that must be used
  --> src/bin/level_editor/main.rs:63:29
   |
63 | ...                   level.save();
   |                       ^^^^^^^^^^^^
   |
   = note: this `Result` may be an `Err` variant, which should be handled
   = note: `#[warn(unused_must_use)]` on by default
help: use `let _ = ...` to ignore the resulting value
   |
63 |                             let _ = level.save();
   |                             +++++++

Right now, if I click on the save button there is no feedback to the user about what just happened. So let's fix that. I don't know if egui has a "pop up" sort of dude, but I'm pretty sure we could easily replicate one with a mutable boolean that gets set plus a message, or maybe if we wanted to be a little bit more pure and re-usable… yeah, let's do this!

use egor::app::{egui::Id, egui::Modal, egui::Ui};

pub struct PopUp {
    pub heading: String,
    pub msg: String,
    pub visible: bool,
}

impl PopUp {
    pub fn ui(&mut self, ui: &mut Ui) {
        if self.visible {
            let modal = Modal::new(Id::new("popup")).show(ui.ctx(), |ui| {
                ui.set_width(200.);
                ui.heading(&self.heading);
                ui.add_space(18.);

                ui.label(&self.msg);
                if ui.button("Ok").clicked() {
                    ui.close();
                }
            });

            if modal.should_close() {
                self.visible = false;
            }
        }
    }
}

Just like before, we can define a ui function to construct how we want to display something with mutable data in the ui. Thankfully, I spotted the modal example in egui's documentation and that made life simpler. The modal handles nixing any input besides what's going to itsef while it's displayed, and displaying it is pretty simple for us, since we don't always have a pop up, we can use an option to good effect here:

... above our main loop alongside our other long lived settings
let mut save_pop_up: Option<PopUp> = None;
...

App::new()
    .window_size(1280, 720)
    .title("Logic Brush Level Editor")
    .run(move |frame_context| {
        ...
        Window::new("Settings")
            .anchor(Align2::LEFT_TOP, egor::app::egui::Vec2::ZERO)
            .default_size([100.0, 500.0])
            .show(egui_ctx, |ui| {
                ...
                match level.save() {
                    Ok(_) => {
                        save_pop_up = Some(PopUp {
                            heading: "Saved".to_owned(),
                            msg: "Your level has been saved".to_owned(),
                            visible: true,
                        });
                    },
                    Err(error) => {
                        save_pop_up = Some(PopUp {
                            heading: "Error".to_owned(),
                            msg: format!("Error: {error}").to_owned(),
                            visible: true,
                        });
                    }
                }

                if let Some(popup) = save_pop_up.as_mut() {
                    popup.ui(ui);
                }
            }
        ...

Technically, once a pop up has occurred, we always have one. But once its dismissed it won't show up again. A tiny memory hit, but not enough of one for me to consider adding in a check against the visible flag to then set the save_pop_up back to None.

There's nothing stopping you from overwriting the file or anything like that, but I don't think this editor needs to be that sophisticated. I'm tracking the levels in git after all, so if I mess it up I can revert²⁵. And just like that. Our basic level editor is complete!

Erm. Well, it could probably use some labels of what each thing is, and maybe an instruction or two actually. Only we know how to use it, and while "internal tools" sometimes have a lower bar of tutorials for some reason, that doesn't mean we need to give in to that, right? We can at least toss those in before we move on…

For one, black on black is kind of hard to read. So let's clear the screen to gray instead so that the black boxes of the grids are easier to tell apart from the background:

gfx.clear(Color::new([0.5, 0.5, 0.5, 1.0]));

We can also tweak the Color::WHITE for the pbm board to Color::BLUE for a bit more of a difference to see how we like it:

But more importantly, we can add some labels and instructions to the screen:

ui.heading("Instructions");
ui.label("Left click to apply changes to the grids, right click to remove");
ui.label("The PBM grid defines the cells to fill for the puzzle");
ui.label("The PPM grid defines the pixel art reward. ");
...
ui.separator();
ui.heading("Warning:");
ui.label("Saving will overwrite any file with the same name");

There's really nothing to say here besides we'll rely on people's ability to read instructions. Which is a terrible way for a program to be, but for now, I'll accept the risks of not reading my own notes.

Removing expectations ↩

As a consequence of our side quest to create a level editor, we now have a handy pop up struct and ui we can use. So, let's return to the code we left on the table before:

ScreenAction::MarkLevelComplete => {
    let found_level = levels.iter_mut().find(|level| level.path == current_level);
    if let Some(played_level) = found_level {
        if !played_level.completed {
            played_level
                .mark_completed()
                .expect("could not persist level completion")
        }
    }
}

This code didn't sit well with me before, yes, we have other panicing parts of this code, such as this:

ScreenAction::PreviousPage => {
    let Screens::ChooseLevelScreen { page } = current_screen else {
        panic!("screen was not level select {:?}", current_screen);
    };
    current_screen = Screens::ChooseLevelScreen { page: page - 1 };
}

But that panics because of a programmer error, and so feels more acceptable to me since we should explode and stop if the assumptions we're making about our own code go wrong. But, the completion of a level failing to save feels like it could happen due to something weird about the external world to the program, like a permission error or similar on the player's machine.

This feels like a different class of problem, and so I'd like to handle it more gracefully. It's not hard to use our new pop up structure for this:

let mut maybe_popup: Option<PopUp> = None;
...
ScreenAction::MarkLevelComplete => {
    let found_level = levels.iter_mut().find(|level| level.path == current_level);
    if let Some(played_level) = found_level {
        if !played_level.completed {
            match played_level.mark_completed() {
                Ok(_) => {},
                Err(error) => {
                    maybe_popup = Some(PopUp {
                        heading: "Error".to_owned(),
                        msg: format!("There was a problem {}", error).to_owned(),
                        visible: true,
                    });
                }
            }
        }
    }
}

Though, it is a little funny to actually render the pop up because we need a Ui from egui, and in our usual loop here, we don't have one of those. But we can get one if just make a new window widget for it:

if let Some(popup) = maybe_popup.as_mut() {
    let egui_ctx = frame_context.egui_ctx;
    Window::new("!").show(egui_ctx, |ui| {
        popup.ui(ui);
    });
    if !popup.visible {
        maybe_popup = None;
    }
}

But, unlike before, we need to actually reset the pop-up to None when we're done with it or else the window with the ! will hang around if it ever shows up. Which is annoying.

For now this is okay though. We're running into those little oddities because we're combining egui windows and egor's drawing panes in one app. So a bit of jank is to be expected I think. But I'm okay with it, and I feel like we've learned a lot.

Cross platform releases ↩

The remaining things this game needs are:

• An overhaul of the "graphics" and layout to make it look like an actual game
• Sounds! Music! There's no audio component at all to this game!
• Some tidying up of the code, why do I keep writing the same grid rendering code everywhere
• A deployment process to give the game to YOU

Of these things, the most important to me is understanding the release process. As you may have guessed, I'm not planning on circling back to the graphics, music, or covering the tweaking and twiddling I might do to refactor things in this blog post. My main goal, as I stated above the table of contents, was to dip our toes into the idea of doing game development with rust.

I feel like I've accomplished that, I've learned some stuff along the way, and I've ran into some face-to-rake moments along the way that have me itching to explore alternatives and potentially go deeper in some of these areas. For some reason, I have the itch to find out if this SDL3 thing I've been hearing about recently would be fun to use. And our run in with cosmic-text and friends sort of make me think it'd be fun to see if those two could play along.

But as always, I'm stubborn.

And as I noted at the start, my one fear for this project was that we wouldn't finish it. You might say that since I'm ignoring the music and graphics aspects that I'm not finishing it, but my definition of not finishing is having no deliverable to give to you. Which is why I was so trepidatious about using rust in the first place. With Java and LibGDX, I press a couple buttons and run a few gradle tasks and bada bing, bada boom, we've got zip files to handle out to anyone who wants to play the game!

So the question is, how the heck do I do that for this project? How do I deploy the egor game to YOUR machine?

Well, according to the README file, we can make a wasm build by creating an index HTML file and then running trunk? It requires me to run cargo install trunk, which took a few minutes to compile 510 or so crates together. Then, I tried running trunk serve like the docs suggested and uh

Hm. I tried to look at the documentation on "trunkrs.dev", but the site was just a blank white screen with some errors in the web inspector console

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://router.parklogic.com/. (Reason: CORS request did not succeed). Status code: (null).
failed to contact router, status code: 0 ""

That's uhm. A sign. Maybe not a good one. But a sign. Of something. I'm not really sure if maybe it's unhappy due to use having two binaries and perhaps it doesn't know which to do things for? But I don't think that's it, because if I temporarily name the editor main to a txt doc, it doesn't change the output of the commands at all.

So let's set that aside. How do I generate a build for a simpler target. How about just, linux? Well, making the binaries is easy, we just run cargo build --release and then out pops the data

Granted, becuase they're completely divorced from the folders we created like assets and levels trying to run them results in this pain:

/target/release$ ./logicpaint 
Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }

But that's not really a problem. We can just copy the appropriate folders over and then it should boot up. And, this also gives us an opportunity to see a real user error in the wild if we run the editor and try to save:

So sure, that seems simple enough and honestly, using a make file comes to mind to me for us to copy those files over. But I think that's actually not the right option here. One of the great things about rust is that it compiles on windows, linux, and mac. So, rather than trying to figure out how to build from my linux machine and target those, why don't we just build it on that machine?

Now, technically, I do have access to each of these systems on my own. But an easier solution than me duel—erm, triple-wielding keyboards, would be to just make the robots do it all for me. Specifically, the Octobot! Within a .github/workflows/release.yml file, I can start my plot: ²⁶

name: Build Release Bundles

on:
  push:
    tags:
      - "v*"

jobs:
  build:
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
    runs-on: ${{ matrix.os }}

    steps:
      - uses: actions/checkout@v4

Nothing crazy here yet, just saying that we'll build for the 3 most common targets with the code we've got in the repository whenever we push up a tag that starts with "v".

      - name: Install Rust
        uses: dtolnay/rust-toolchain@stable

      - name: Build release
        run: cargo build --release

These two steps are the same regardless of which platform we're one, cargo is nice like that. At the risk of dumping too much at once, the platform specific runners are pretty straightforward. Linux and mac both can use the same process since cp works the same on each, but of course, the weirdo world of MacroSlop uses all those funny /E /I flags. It's funny, I used windows for most of my life, but besides writing fork bombs to drop onto the school's computers, I never really spent much time learning the CLI for the DOS style shells. Let alone powerfull. Anyway:

      - name: Prepare dist folder (Linux/macOS)
        if: runner.os != 'Windows'
        run: |
          mkdir -p dist
          cp target/release/logicpaint dist/
          cp target/release/level_editor dist/
          cp -r assets dist/
          cp -r levels dist/

      - name: Prepare dist folder (Windows)
        if: runner.os == 'Windows'
        run: |
          mkdir dist
          copy target\release\logicpaint.exe dist\
          copy target\release\level_editor.exe dist\
          xcopy assets dist\assets /E /I
          xcopy levels dist\levels /E /I

      - name: Create archive (Linux)
        if: runner.os == 'Linux'
        run: tar -czf logicpaint-linux.tar.gz -C dist .

      - name: Create archive (macOS)
        if: runner.os == 'macOS'
        run: tar -czf logicpaint-macos.tar.gz -C dist .

      - name: Create archive (Windows)
        if: runner.os == 'Windows'
        run: powershell Compress-Archive dist logicpaint-windows.zip

Lastly, we have the last step (for the moment), which is uploading the assets to the build result.

      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: logicpaint-${{ runner.os }}
          path: |
            *.tar.gz
            *.zip

this doesn't cut a release or attach anything like I've done in the past for java builds. I think we want to see that this works before we do any of that sort of thing.

That's promising! But when I downloaded the linux assets and gave it a shot:

~/Downloads/logicpaint-Linux/logicpaint-linux$ ./logicpaint 
./logicpaint: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.39' not found (required by ./logicpaint)

So we accidentally built on a build that used a very very recent version of glibc, more recent than mine

$ ldd --version
ldd (Ubuntu GLIBC 2.35-0ubuntu3.13) 2.35
Copyright (C) 2022 Free Software Foundation, Inc.

not TOO much more recent, but it doesn't really matter since

The reverse (backwards compatibility) is not true. It is not possible to take program binaries linked with the latest version of a library binary in a release series (with additional symbols added), substitute in the initial release of the library binary, and remain link compatible.
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
stackoverflow post

GLIBC is forward compatible, but not backwards. So if we want our cool new game to work on common systems, we need to target an older version of linux. Sadly, this makes the yaml file a little more complicated, but not too much. We just need a container!

jobs:
  build:
    strategy:
      matrix:
        include:
          - os: ubuntu-latest
            name: linux
            container: ubuntu:22.04 # binary should run on this forward
          - os: macos-latest
            name: macos
          - os: windows-latest
            name: windows

    runs-on: ${{ matrix.os }}
    container: ${{ matrix.container || '' }}

    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies (Linux container only)
        if: runner.os == 'Linux'
        run: |
          apt-get update
          apt-get install -y curl build-essential pkg-config libasound2-dev

      - name: Install Rust (manual for container)
        if: runner.os == 'Linux'
        run: |
          curl https://sh.rustup.rs -sSf | sh -s -- -y
          echo "$HOME/.cargo/bin" >> $GITHUB_PATH

      - name: Install Rust (macOS/Windows)
        if: runner.os != 'Linux'
        uses: dtolnay/rust-toolchain@stable

And then everything else goes along as expected. But speaking of platform specific things, now would probably be a good time to audit some of our code. Specifically, the stuff that deals with paths…

let filename_pbm = match arguments.next() {
    Some(arg) => arg,
    _ => "./assets/P1.pbm",
};

arguments.next(); // skip the name of the program being ran
let filename_ppm = match arguments.next() {
    Some(arg) => arg,
    _ => "./assets/P3.ppm",
};

// todo use options and whatnot to load things up properly and such
let unknown_ppm = read_to_string("./assets/unsolved.ppm")?;

Hey, would you look at that. Past me even had a todo in here. This isn't too hard to fix, we just need to build up our paths from a known location. Your first instinct, like me, might be to just reach for current_exe from the std::env module. And that's mostly right, but when if we do that, then when we try to run cargo again we'll run into

Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }

when the binary runs from the target directory.

Reason being that up until now, the ./ has actually been meaning from our current working directory of where we were running the commands. Not the directory of the binary. This worked in our favor with us sitting at the root of the repo, right next to the assets and levels folder, but that won't work if we swap things around as if we're a non-dev machine. So, we can be clever here:

pub fn base_dir() -> std::path::PathBuf {
    let mut dir = std::env::current_exe()
        .expect("failed to get current_exe")
        .parent()
        .unwrap()
        .to_path_buf();

    // To avoid a bit of friction with cargo run versus cargo build --release + run the binary
    // we can find out if we're in "dev mode" by looking for the tell tale signs of development
    // aka: there's a toml file hanging out somewhere above wherever we are.
    let mut probe = dir.clone();
    while probe.pop() {
        if probe.join("Cargo.toml").exists() {
            return probe;
        }
    }

    dir
}               

This sort of thing very much feels like it's deserving of a comment. After all, walking up from where a binary is is sort of an odd thing to do. For a release version, I suppose it might run into a permission error, but the docs for pop don't seem to throw out any particular thing to watch out for, so this seems ok. Anyway, to detect if we're in editor mode or not, we can just look to see if the toml file exists. We don't ship that, so it's an easy thing to detect our "dev" mode.

Explanations of probing aside, the changes to the rest of the code to make it all behave are pretty minimal, code like

let unknown_ppm = read_to_string("./assets/unsolved.ppm")?;

expands a little bit and becomes:

let exe_dir = base_dir();
let assets = exe_dir.join("assets");
let unknown_ppm = read_to_string(assets.join("unsolved.ppm"))?;

Similar, our use of the array + collect strategy in the level save code removes the relative path part, and then relies on join to combine the base and ending path together:

pub fn save_grid_as_level(level_settings: &LevelSettings, grids: &EditorGrids) -> Level {
    let ppm = (level_settings, grids).into();
    let pbm = (level_settings, grids).into();
    let base = base_dir();
    let path: PathBuf = ["levels", &level_settings.filename].iter().collect();
    let path = base.join(path);
    Level {
        info: pbm,
        image: ppm,
        completed: false,
        path: path.with_extension("level"),
    }
}

Certainly not the worst thing one could be doing to achieve cross platform abilities. Speaking of, checking back in on the github build I kicked off before fixing up the directory related stuff, we're now able to successfully run the linux version we built on github locally from the downloaded zip:

That's pretty exciting! Putting aside the fact that the game still proudly shoves the debug window into your face, and also only has one committed level, this is a pretty good sign that the release process is going smoother than I'd have thought it would. The last step, now that the build is green, is to have it attach the assets to a release version.

permissions:
  contents: write

    ... as another step after the upload artifact step....
      - name: Upload to GitHub Release
        uses: softprops/action-gh-release@v2
        with:
          files: |
            logicpaint-linux.tar.gz
            logicpaint-macos.tar.gz
            logicpaint-windows.zip

thankfully, the softprops folks have done all the hard work, so it's as easy as making sure the workflow job has permissions to write data, and then one little action later and bada bing, bada boom, behold on github, zoom zoom zoom.

Ok, so now that we've got the release process going, we can do any final polishing, tag it, and then we'll be officially done!

A final polish ↩

Besides taking out the debug windows, we need to do a bit more tweaking because when it comes to 5x5 puzzles, we don't always render everything as intended, as seen with this level:

There's three 1's in the first column, but as you can see, we're only showing the last two. So, we'll need to fix that. In general, the overall design of the layout of well, everything, leaves a lot of be desired. The thing is, every time I open excalidraw, draw.io, pinta, or any program to doodle things out, it just never feels right and always feels clunky. So, I did something better.

Yup. Just like the president of Dominos Japan, I decided to have some fun with miku and use my grid notebook to dot out the 16x9 screen, and then get a feel for how I wanted the UI to look from there. I'm not 100% sure it will look good on screen yet, but that's what we'll find out next.

Since I want a quit icon and amybe a few other things, it's time to refactor the way we're passing unknown_ppm down. Right now it's loaded up in the main function and given over to the ui, I don't want to make a new argument for every ppm I want to use, so let's bundle em all up:

pub struct LoadedPpms {
    pub unknown_ppm: Ppm,
    pub quit_ppm: Ppm,
}


impl LoadedPpms {
    pub fn load(assets: PathBuf) -> Result<Self, Box<dyn std::error::Error>> {
        let unknown_ppm = read_to_string(assets.join("unsolved.ppm"))?;
        let unknown_ppm: Ppm = unknown_ppm.parse()?;

        let quit_ppm = read_to_string(assets.join("quit.ppm"))?;
        let quit_ppm: Ppm = quit_ppm.parse()?;

        Ok(LoadedPpms {
            unknown_ppm,
            quit_ppm,
        })
    }
}

I suppose this is where people use "asset managers" and that sort of thing, but since I don't have one of those at the moment, I think this will suffice just fine. You might ask, why not use a hashmap of a file or something to the loaded Ppm? Because I don't want to deal with Options everywhere and if I can't load an icon, then the game shouldn't be played! This refactor is quick, in the main we replace the load for the unbeaten level with:

let loaded_ppms = LoadedPpms::load(assets)?;

and its call site with a reference:

Screens::ChooseLevelScreen { page } => screens::level_select_screen(
    &levels,
    *page,
    frame_context,
    &mut game_state,
    &mut win_image,
    &mut current_level,
    &loaded_ppms.unknown_ppm,
),

Then make sure it compiles. Once that's done (after a few imports and whatnot) I can tweak the function itself:

pub fn level_select_screen(
    levels: &[Level],
    page: usize,
    frame_context: &mut FrameContext,
    current_level: &mut PlayState,
    current_win_image: &mut Ppm,
    current_path: &mut PathBuf,
    loaded_ppms: &LoadedPpms,
) -> ScreenAction {
    ...
    draw_ppm_at(&loaded_ppms.unknown_ppm, pos, level_tile_size, gfx);
    ...
}

Super simple refactor, but it just unlocked the ability for us to do this:

draw_ppm_at(
    &loaded_ppms.quit_ppm,
    quit_position,
    quit_btn_size, 
    gfx
);

Is my "art" for the quit button good? No, but hey, I made it with the level editor so give me a bit of a break. One day, I'll use a proper pixel art program like aesprite or something, but not today! Now, you might be wondering about those new variables for position and size, well, since we're not working off the grid paper, we can tweak the level setup code like this:

let x_unit = 1280. / 32.;
let y_unit = 720. / 18.;
let level_bg_size = vec2(16. * x_unit, 10. * y_unit);
let title_text_position = vec2(8. * x_unit, 5. * y_unit) + vec2(level_bg_size.x / 2., 0.);
let level_bg_position = vec2(8. * x_unit, 6. * y_unit);
let quit_position = vec2(28. * x_unit, 1. * y_unit);
let quit_btn_size = vec2(3. * x_unit, 3. * y_unit);

This helps keep our mental model of "8 graph paper cells to the right" in place in the code, which is helpful for transcribing things. Since the calculations are all from hardcoded values, I'm decently confident that the rust compiler is going to just inline the values and not do any math each frame.

For the quit button to actually do something, we need to wire up a new screen action and then create a rect to check if the user has clicked or not:

// in level_select_screen
let rect = Rect::new(quit_position, quit_btn_size);
let highlight_color = if rect.contains(world_xy) {
    if left_mouse_pressed {
        action = ScreenAction::QuitGame;
    }
    Color::new(palette.cell_incorrect)
} else {
    Color::new(palette.group_highlight)
};
gfx.rect()
    .color(highlight_color)
    .at(quit_position - 4.)
    .size(quit_btn_size + 4.);
draw_ppm_at(&loaded_ppms.quit_ppm, quit_position, quit_btn_size, gfx);              

// in main.rs
match action {
    ScreenAction::QuitGame => {
        std::process::exit(0);
    }

You might notice I'm also starting to use palette here, we weren't passing that in before, but it was a trival refactor to do, and then the vivid blue that screams: "I am a work in progress" disappears:

Also I've decided to combine the two games I know of that do this sort of puzzle mechanic into one word to use as the name of this silly little game²⁷. Interesting, and of note, is that calling gfx.clear(Color::new(palette.grid_even)); just the one time results in every screen using that color as the clear screen. I fully expected to have to call it every time from every screen, but I guess global mutable state is the name of egor's game.

Moving along, we can rework the play_game_screen to also follow our grid paper layout. Its signature needs an update since we'll be wanting our quit button, which means we want our LoadedPpms container passed along as well:

pub fn play_game_screen(
    game_state: &mut PlayState,
    frame_context: &mut FrameContext,
    palette: &mut ColorPalette,
    loaded_ppms: &LoadedPpms,
) -> ScreenAction {

and then it's the usual song and dance of using the graph paper units to lay things out

    ...
    let x_unit = 1280. / 32.;
    let y_unit = 720. / 18.;
    let bg_position = vec2(16. * x_unit, 7. * y_unit);
    let quit_position = vec2(28. * x_unit, 1. * y_unit);
    let quit_btn_size = vec2(2. * x_unit, 2. * y_unit);
    let bg_size = x_unit * 10.;
    let box_offset = x_unit / 8.0;

and then after all the usual play area calls, we can call our new helper to draw the quit button (which I just made) and if it returns an action for us to take, we can quit. Which, in the case of playing a game, means quitting back to the main level select:

    ...
    if game_state.is_complete() {
        ScreenAction::ChangeScreen {
            to: Screens::WinScreen,
        }
    } else if let Some(quit_action) = draw_quit_button(
        quit_position,
        quit_btn_size,
        &loaded_ppms.quit_ppm,
        &palette,
        &player_input,
        gfx,
        ) {
        ScreenAction::ChangeScreen {
            to: Screens::ChooseLevelScreen { page: 0 }
        }
    } else {
        ScreenAction::NoAction
    }
}

This works, and it aligns us to what the graph paper wanted us to be like. Though it does show a bit of a useability issue for us. A 5x5 grid is easily readable:

But if I load up a 20x20:

How troublesome. I think we can fix this, but let's get the other UI elements for the play screen into the world. As you might have noticed in the image, I want to add some basic instructions and a visual guide for the user on how to play. Easy 1 2 punch of, add in the ppm files to the assets struct for them:

pub struct LoadedPpms {
    pub unknown_ppm: Ppm,
    pub quit_ppm: Ppm,
    pub mouse_left: Ppm,
    pub mouse_right: Ppm,
}

And then draw them at the appropriate place with an icon next to them. As before, we can re-work the existing positioning variables to use the graph paper world:

let x_unit = 1280. / 32.;
let y_unit = 720. / 18.;
let bg_position = vec2(16. * x_unit, 7. * y_unit);
let bg_size = x_unit * 10.;
let box_offset = x_unit / 8.0;

let quit_position = vec2(28. * x_unit, 1. * y_unit);
let quit_btn_size = vec2(3. * x_unit, 3. * y_unit);

let mouse_left_position = vec2(27. * x_unit, 5. * y_unit);
let mouse_left_size = vec2(2. * x_unit, 2. * y_unit);

let mouse_right_position = vec2(27. * x_unit, 8. * y_unit);
let mouse_right_size = vec2(2. * x_unit, 2. * y_unit);

And then 4 draw requests later:

draw_ppm_at(
    &loaded_ppms.mouse_left,
    mouse_left_position,
    mouse_left_size,
    gfx,
);
gfx.rect()
    .at(mouse_left_position + vec2(mouse_left_size.x, 0.))
    .size(mouse_left_size)
    .color(Color::new(palette.cell_filled_in));
draw_ppm_at(
    &loaded_ppms.mouse_right,
    mouse_right_position,
    mouse_right_size,
    gfx,
);
draw_x_at(
    mouse_right_position + vec2(mouse_right_size.x, 0.),
    mouse_right_size,
    Color::new(palette.cell_marked_user),
    gfx,
);

While not the best version of hieroglyphics I've ever come up with, it's at least what I intended. It passes the bar of "good enough" for me, because I, as I've said multiple times, am not an artist. Also, we have English!

let instruction_text_position = vec2(1. * x_unit, 1. * y_unit);
let font_size = 18;
...
let instructions = [
    "Fill in the groups of cells based on the hints to their group sizes.",
    "Groups are always separated by at least one cell.",
    "Right click to mark a cell as empty",
    "Left click to fill and find out if you're correct.",
];
for (i, instruction) in instructions.iter().enumerate() {
    gfx
        .text(instruction)
        .at(instruction_text_position + vec2(0., (font_size * i) as f32))
        .size(font_size as f32)
        .color(Color::new(palette.group_highlight));
}

The nice thing about the size for the TextBuilder is that it's the line height, so we can very easily stack instructions on top of each other with equal spacing without any guesswork.

Now, besides the too small 20x20 issue, the play area is aligned with what we wanted! I want to wrap up transferring the physical into the virtual before we consider beating our head against the pain of virtual real estate. Thankfully, theres' really not too much to do for the win screen, it wants a similar signature update:

pub fn win_screen(
    game_state: &mut PlayState,
    ppm: &Ppm,
    frame_context: &mut FrameContext,
    palette: &ColorPalette,
    loaded_ppms: &LoadedPpms,
) -> ScreenAction {

And a quick computation for the graph paper cells to screen coordinates

	let x_unit = 1280. / 32.;
	let y_unit = 720. / 18.;
	let win_image_position = vec2(11. * x_unit, 2. * y_unit);
	let win_image_size = vec2(14. * x_unit, 14. * y_unit);
	
	let quit_position = vec2(28. * x_unit, 1. * y_unit);
	let quit_btn_size = vec2(3. * x_unit, 3. * y_unit);
	
	let result_text_position = vec2(2. * x_unit, 2. * y_unit);

And removing the old gfx.rect version of the return to menu button and replacing it with the new quit button.

    let num_incorrect = game_state.number_incorrect();
    if num_incorrect == 0 {
        gfx.text(&format!("Perfect!"))
            .size(78.)
            .color(Color::new(palette.group_highlight))
            .at(result_text_position);
    } else {
        gfx.text(&format!("Incorrect {}", num_incorrect))
            .size(16.)
            .color(Color::new(palette.group_highlight))
            .at(result_text_position);
    }

    draw_ppm_at(ppm, win_image_position, win_image_size, gfx);

    if let Some(quit_action) = draw_quit_button(quit_position, quit_btn_size, &loaded_ppms.quit_ppm, palette, &player_input, gfx) {
        ScreenAction::ChangeScreen {
            to: Screens::ChooseLevelScreen { page: 0 },
        }
    } else {
        ScreenAction::MarkLevelComplete
    }
}

This gets us pretty dang close to what I sketched out!

The "perfect" text looks okay, but the incorrect text is a bit too small, so I think we should tweak it a bit more:

gfx.text(&format!("Nice try!"))
    .size(78.)
    .color(Color::new(palette.group_highlight))
    .at(result_text_position);
gfx.text(&format!("You got {} incorrect", num_incorrect))
    .size(16.)
    .color(Color::new(palette.group_highlight))
    .at(result_text_position + vec2(0., 78.));

And that looks a bit better, more consistent with the perfect screen at least layout wise.

I think we've all just learned a pretty valuable lesson. We should definitely use graph paper the next time we decide to put things on a screen. It's a lot easier and quicker. I mean, sure, the DebugStuff struct I had and the mutable sliders and all that fun stuff made for satisfying visual feedback within the application, but I wasn't saving any of those values down. Or at least, if I was using them to update the code, I was doing it one variable at a time.

With the graph paper, it made it easier to sketch the idea out and get a feel for the whole picture all at once. Very handy, and next game I'll probably try to remember to use graph paper from the start. Maybe then we wouldn't have had this problem about the interface feeling too small with the larger levels. That's a big maybe though, the bad visibility is a combo of the font color and the scaling of the grid to the given area.

One of these is easy to tweak though:

// Within the ui helpers
pub struct ColorPalette {
    ...
    pub group_font: [f32; 4],
}
...
gfx.text(&format!("{}", groups[g].num_cells))
    .size(0.5 * box_size)
    .color(match groups[g].filled {
        true => Color::new(self.palette.cell_filled_in),
        false => Color::new(self.palette.group_font),
    })
    .at(screen_position);

A new font that's just black actually does help. A little:

But it really feels more like a font weight and size problem, more than just the color. If I just blindly tweak our scalars that we made before from 0.5 to 1.0 then we run into a rather unpleasant result (I only changed the rows here)

And the problem is obvious. I think that if we want to fix this problem, we need to approach this in the same way as we did the layout. Thinking about it on paper. Or at least a little bit more analytically than we did before, I think we can solve a number of little irksome things in the code with one little trick, including the font problem!

What if we had an easy way to compute just the geometry of a grid?

Like, what if we could say GridLayout { area, rows, columns, cell_gaps } and then ask it to give you back an iterator that gives you the row and column you have, as well as a Rect that defines the smaller area within the space we specify that whatever this grid is being used for can use? If we had that, then we could use it so define the gutter size for a specific number of letters, then get back the equally spaced areas for them to appear and use the height of the cell as the font height. We could also use it to refactor all the code like

let anchor = anchor - offset;
for (c, groups) in play_state.column_groups.iter().enumerate() {
    let number_of_groups = groups.iter().len();
    for i in 0..number_of_groups {
        let grid_offset = vec2(c as f32, -(i as f32) - 2.);
        let position = anchor + grid_offset * grid_cell_size * scaler;

without having to do all those grid offset, position, anchor things all the time. The only downside to this I can think of is that iterating a separate struct increases the potential for us to accidentally go out of bounds if we misaligned something. But I think that the trade off is worth it since that should be mitigated since the layouts can be created in relation to whatever grid type thing we need, or even with From trait again maybe.

But first, let's get this layout on the road:

struct GridLayout {
    pub area: Rect,
    pub rows: usize,
    pub columns: usize,
    pub cell_gap: f32,
}

There's nothing too crazy about this, we've already defined grids quite a few times and even tried to use some cute names like halfset before in some helpers. But, this will be a bit better than all of those born of our repeated creation of the grids informing us what we actually need:

impl GridLayout {
pub fn cell_size(&self) -> Vec2 {
    let total = self.area.size;

    // [gap [cell] gap [cell] gap ]
    let gaps = vec2(
        (self.columns as f32 + 1.0) * self.cell_gap,
        (self.rows as f32 + 1.0) * self.cell_gap,
    );

    // (max(vec)) to avoid negative space
    let space_for_cells = (total - gaps).max(vec2(0.0, 0.0));

    space_for_cells / vec2(self.columns as f32, self.rows as f32)
}

// Return the top left of where the cells start within the grid layout (offset by the gap)
pub fn origin(&self) -> Vec2 {
    self.area.min() + vec2(self.cell_gap, self.cell_gap)
}

pub fn cell_rect(&self, r: usize, c: usize) -> Rect {
    let cell = self.cell_size();

    let origin = self.origin();

    let offset = vec2(
        c as f32 * (cell.x + self.cell_gap),
        r as f32 * (cell.y + self.cell_gap),
    );

    Rect {
        position: origin + offset,
        size: cell,
    }
}

But what should make this easier to use than what we've been doing is this new function, where it's time to return an iterator across all the cells for the grid, all precomputed with rectangles ready for input checking and graphics drawing!

    // For me in 3 months: '_ is an anonymous lifetime tied to self.
    // it just means the caller can't let the iterator last longer than this layout
    pub fn iter_cells(&self) -> impl Iterator<Item = (usize, usize, Rect)> + '_ {
        let cell_size = self.cell_size();
        let origin = self.origin();
        let step = cell_size + Vec2::splat(self.cell_gap);

        (0..self.rows).flat_map(move |r| {
            (0..self.columns).map(move |c| {
                let top_left = origin + vec2(c as f32, r as f32) * step;
                let cell = Rect {
                    position: top_left,
                    size: cell_size,
                };
                (r, c, cell)
            })
        })
    }
}

As you can tell by my comment, I have total faith in my ability to remember bizarre nonsense like the tick underscore aka anonymous inferred lifetimes based on the input to the function. Which is a lot of words tosay that the iterator we're returning is valid for as long as the self reference is. Er, and by self I mean the actual instance of the thing that just called iter_cells.

Anyway. In the PlayArea#draw_grid method, we can swap out the chunk of code drawing the grid. As a reminder, this is what the code looks like pre-refactor:

let halfset = self.halfset();
let anchor = self.anchor();
let offset = Vec2::splat(halfset);
let num_boxes = play_state.rows().len();
let box_size = self.box_size(num_boxes);
let cell_size = Vec2::splat(box_size);
let side_areas_size = self.play_area_gutter();

for (r, row) in play_state.rows().into_iter().enumerate() {
    let (even_odd_bg_color, odd_even_bg_color) = self.palette.even_odd_color(r);

    let y_offset = r as f32 * (halfset + box_size); 
    let row_group_bg_position = anchor - vec2(side_areas_size.x, -y_offset); (1)
    let row_group_bg = if row_group_bg_position.y <= input.position.y (2)
        && input.position.y <= row_group_bg_position.y + box_size
    {
        self.palette.group_highlight
    } else {
        odd_even_bg_color
    };
    gfx.rect()
        .at(row_group_bg_position)
        .color(Color::new(row_group_bg))
        .size(vec2(side_areas_size.x, box_size));

    for (c, state) in row.iter().enumerate() {
        let position = anchor + vec2(c as f32, r as f32) * (Vec2::splat(box_size) + offset);
        let color = match state {
            CellState::Empty => Color::new(even_odd_bg_color),
            CellState::Filled => Color::new(self.palette.cell_filled_in),
            CellState::Incorrect => Color::new(self.palette.cell_incorrect),
            CellState::RuledOut => Color::new(self.palette.cell_marked_game),
            CellState::UserRuledOut => Color::new(self.palette.cell_marked_user),
        };
        let cell_rect = Rect::new(position, cell_size);
        if input.overlaps(&cell_rect) {
            gfx.rect()
                .at(position - offset) (3)
                .size(cell_size + offset * 2.)
                .color(Color::new(self.palette.cell_highlight));
        }

        match state {
            CellState::Empty | CellState::Filled => {
                gfx.rect().at(position).size(cell_size).color(color);
            }
            _ => {
                gfx.rect()
                    .at(position)
                    .size(cell_size)
                    .color(Color::new(even_odd_bg_color));
                draw_x_at(position, cell_size, color, gfx);
            }
        };

        if input.can_fill_at(&cell_rect) {
            play_state.attempt_fill(r, c);
        }
        if input.can_mark_at(&cell_rect) {
            play_state.mark_cell(r, c);
        }
    }
}

And using the GridLayout

let layout = GridLayout {
    area: Rect {
        position: self.top_left,
        size: self.size
    },
    rows: play_state.rows().len(),
    columns: play_state.cols().len(),
    cell_gap: self.grid_gutter,
};
let state_by_rows = play_state.rows();
for (r, c, cell_rect) in layout.iter_cells() {
    let (even_odd_bg_color, odd_even_bg_color) = self.palette.even_odd_color(r);
    let cell = state_by_rows[r][c];

    let color = match cell {
        CellState::Empty => Color::new(even_odd_bg_color),
        CellState::Filled => Color::new(self.palette.cell_filled_in),
        CellState::Incorrect => Color::new(self.palette.cell_incorrect),
        CellState::RuledOut => Color::new(self.palette.cell_marked_game),
        CellState::UserRuledOut => Color::new(self.palette.cell_marked_user),
    };
    if input.overlaps(&cell_rect) {
        gfx.rect()
            .at(cell_rect.min() - self.grid_gutter / 2.) (3)
            .size(cell_rect.size + self.grid_gutter)
            .color(Color::new(self.palette.cell_highlight));
    }

    match cell {
        CellState::Empty | CellState::Filled => {
            gfx.rect().at(cell_rect.min()).size(cell_rect.size).color(color);
        }
        _ => {
            gfx.rect()
                .at(cell_rect.min())
                .size(cell_rect.size)
                .color(Color::new(even_odd_bg_color));
            draw_x_at(cell_rect.min(), cell_rect.size, color, gfx);
        }
    };

    if input.can_fill_at(&cell_rect) {
        play_state.attempt_fill(r, c);
    }
    if input.can_mark_at(&cell_rect) {
        play_state.mark_cell(r, c);
    }
}

// The side bar area (1)
let side_areas_size = self.play_area_gutter();
let layout = GridLayout { (2)
    area: Rect {
        position: self.top_left - vec2(side_areas_size.x, 0.),
        size: vec2(side_areas_size.x, self.size.y)
    },
    rows: play_state.rows().len(),
    columns: 1,
    cell_gap: self.grid_gutter,
};
for (r, c, cell_rect) in layout.iter_cells() {
    let (even_odd_bg_color, odd_even_bg_color) = self.palette.even_odd_color(r);
    let extended_across_grid = Rect {
        position: cell_rect.min(),
        size: cell_rect.size + vec2(self.size.x, 0.)
    };
    let bg = if input.overlaps(&extended_across_grid) {
        self.palette.group_highlight
    } else {
        odd_even_bg_color
    };
    gfx.rect()
        .at(cell_rect.min())
        .color(Color::new(bg))
        .size(cell_rect.size);
}

This a lot of code to take in at once, so here's two things I want to call your attention to that I think shows off why this new grid layout guy is cool:

1. The negative offset adds were confusing. When I first wrote it it was confusing, when I'm looking at it now, days later, it's still confusing. If you look at the corresponding (1) in the refactor, you'll see that entire thing is isolated away and the math is WAY more clear. We can easily move this to its own function now!
2. The positioning of the side bar area is a lot more clear it feels. The row group bg position and its input check plus that y offset formed a wall of text that my eyes wanted to have nothing to do with. But the refactored code is the declaration of the struct, which says loudly "here is my position and size" and it makes it obvious to me what's going on.
3. For the background highlight, which exists within the gutter, we still have to do a little bit of math to push the color outside of the current cell's boundaries, but it's minimal and feels a little lighter on my head than before. Maybe because the gutter variables are so close by and not hidden away by the large amount of offset and positional computation code.

Because this is so easy to refactor into two parts now, it also lends itself to that additional tidying. And so, draw_left_group_backgrounds is born! Then the grid is back to being just about the grid, not about anything else. Also of note, in case you didn't spot it, is that the side bar is a grid layout of row by 1 column, which much more mentally aligns to what you see on the screen.

Now, let's apply the grid layout to the draw_row_groups method. The old code, as a refresher, walked backwards from the edge of the play area grid, scaled the font down by half, and then drew out the font from there:

pub fn draw_row_groups(&self, play_state: &PlayState, gfx: &mut Graphics) {
    let offset = self.halfset();
    let num_boxes = play_state.rows().len();
    let box_size = self.box_size(num_boxes);
    let padding = self.grid_gutter / 2. - box_size / 2.;
    let offset = Vec2::splat(offset);
    let grid_cell_size = Vec2::splat(box_size) + offset;
    let scaler = vec2(0.5, 1.);
    let anchor = self.anchor();
    let anchor = anchor - padding;
    let screen_size = gfx.screen_size();

    for (r, groups) in play_state.row_groups.iter().enumerate() {
        let number_of_groups = groups.iter().len();
        for i in 0..number_of_groups {
            let grid_offset = vec2(-(i as f32) - 2., r as f32);
            let position = anchor + grid_offset * grid_cell_size * scaler;
            let screen_position = gfx.camera().world_to_screen(position, screen_size);
            // write out the numbers from the right outward for alignment
            let g = number_of_groups - i - 1;
            gfx.text(&format!("{}", groups[g].num_cells))
                .size(0.5 * box_size)
                .color(match groups[g].filled {
                    true => Color::new(self.palette.cell_filled_in),
                    false => Color::new(self.palette.group_font),
                })
                .at(screen_position);
        }
    }
}

The new code uses the layout, which is explicitly defined in screen space to match the font's needs, and then walks forward until it's time to show the appropriate cell. Which is a little less confusing, because visually you can think of it like this little ascii diagram:

[][x][x]

For a grid of 5 cels, you can at most have 3 groups, but when there's only 2 to fill, we right align them by skipping the first one. Simpler than walking backwards and trying to keep track of a negative offset and reverse ordered groups like we did before:

pub fn draw_row_groups(&self, play_state: &PlayState, gfx: &mut Graphics) {
    let num_boxes = play_state.rows().len();
    let screen_size = gfx.screen_size();
    let side_areas_size = self.play_area_gutter();
    // Because fonts are rendered in screen position, compute their grid layout
    // with respect to that rather than raw world units
    let screen_position = gfx
        .camera()
        .world_to_screen(self.top_left - vec2(side_areas_size.x, 0.), screen_size);

    let layout = GridLayout {
        area: Rect {
            position: screen_position,
            size: vec2(side_areas_size.x, self.size.y),
        },
        rows: num_boxes,
        columns: num_boxes - num_boxes / 2, // If 5 cells, room for 3 numbers [x_x_x] and similar
        cell_gap: self.grid_gutter,
    };

    for (r, groups) in play_state.row_groups.iter().enumerate() {
        let groups_in_row = groups.len();
        let start_col = layout.columns - groups_in_row;

        for (i, group) in groups.iter().enumerate() {
            let column = start_col + i;
            let rect = layout.cell_rect(r, column);
            // for some reason fonts position their _center_ at the position we tell
            // them to be. So just add half in to get the real placement location
            let half_font = rect.size.y / 2.;
            let position = rect.min() + vec2(0., half_font);

            gfx.text(&format!("{}", group.num_cells))
                .at(position)
                .size(rect.size.y)
                .color(match group.filled {
                    true => Color::new(self.palette.cell_filled_in),
                    false => Color::new(self.palette.group_font),
                });
        }
    }
}

The fonts pretty big since we're matching it to the size of the grid, but, importantly, when you look at a 20x20 grid, you can actually read the dang font!

There's still that _slight_ annoyance of the 20 being a bit too big, but we can fix that by properly scaling the cell by the aspect ratio, kind of like how we did the centered text helper before. Hey wait a minute… I'm dumb, why don't I just use the helper I made already to deal with this?

for (i, group) in groups.iter().enumerate() {
    let column = start_col + i;
    let rect = layout.cell_rect(r, column);
    // for some reason fonts position their _center_ at the position we tell
    // them to be. So just add half in to get the real placement location
    let position = rect.min() + rect.size / 2.;
    let text = &format!("{}", group.num_cells);
    let font_color = match group.filled {
        true => Color::new(self.palette.cell_filled_in),
        false => Color::new(self.palette.group_font),
    };

    draw_centered_text(
        gfx,
        text,
        position,
        rect.size.y,
        font_color,
    );
}               

Problem solved! Now I just have to update the column group helper to do the same thing and we'll have solved the font problem woes that I wasn't happy about. I hope.

pub fn draw_column_groups(&self, play_state: &PlayState, gfx: &mut Graphics) {
    let num_boxes = play_state.cols().len();
    let screen_size = gfx.screen_size();
    let gutter = self.play_area_gutter();
    let grid_corner = self.top_left - vec2(0., gutter.y);
    let screen_position = gfx.camera().world_to_screen(grid_corner, screen_size);
    let rows = num_boxes - num_boxes / 2;
    let layout = GridLayout {
        area: Rect {
            position: screen_position,
            size: vec2(self.size.x, gutter.y),
        },
        rows: rows,
        columns: num_boxes,
        cell_gap: self.grid_gutter,
    };

    for (c, groups) in play_state.column_groups.iter().enumerate() {
        let number_of_groups = groups.iter().len();
        let start_row = rows - number_of_groups;
        for (i, group) in groups.iter().enumerate() {
            let r = start_row + i;
            let rect = layout.cell_rect(r, c);
            // for some reason fonts position their _center_ at the position we tell
            // them to be. So just add half in to get the real placement location
            let position = rect.min() + rect.size / 2.;
            let text = &format!("{}", group.num_cells);
            let font_color = match group.filled {
                true => Color::new(self.palette.cell_filled_in),
                false => Color::new(self.palette.group_font),
            };

            draw_centered_text(gfx, text, position, rect.size.y, font_color);
        }
    }
}

This is more of the same refactoring. Draw a grid above the play area, then fill the blocks near the bottom with the appropriate column group numbers. The slightly odd bit about this change is that the text seems a bit smaller than before for the column groups:

I suppose the reason the font was the same before was that it was based on the cell size of the play area's grid, not the cell size of trying to fit into the area we've defined as the place where the cell groups live. Looking at the actual values, the font size values are pretty different from this change, with the 20x20 grid having fonts for the rows and columns of 14.75 and 10.5, and the 5x5 having 74 and 46.6 respectively.

I think there's a relatively easy way to fix this problem now that we have the GridLayout struct. And it's one that was on my mind before when we were first considering the gutter areas themselves. Remember that picture blocking things out?

We've been drawing each grid area seperately, so why don't we just make our various draw_* functions relating to these take in a GridLayout struct, which spans the entire space, and then some direction on the relative position within that large space to fill with their respective bits and pieces? If we do that, then we'll be back to the single cell size for the whole space, and so the fonts for rows and columns will be consistent, and who knows, maybe it will make life slightly easier to think about.

Rather than refactoring ALL the signatures and whatnot, let's take advantage of the fact that we're in a shared PlayArea struct and just define a method to give back the entire layout. Since we've got the information, we can also ditch the boxes - boxes / 2 bit and instead base the gutters off of the maximum size of groups they need to fit, this will also allow the font to be a bit bigger for the 20x20 grids, even though we won't have perfectly balanced rectangles anymore.

fn full_layout(&self, play_state: &PlayState) -> (usize, usize, GridLayout) {
    let max_row_groups = play_state
        .column_groups
        .iter()
        .map(|g| g.len())
        .max()
        .unwrap_or(1); // always include at least a bit of gutter
    let max_column_groups = play_state
        .row_groups
        .iter()
        .map(|g| g.len())
        .max()
        .unwrap_or(1); // always include at least a bit of gutter

    let rows = play_state.rows().len() + max_row_groups; 
    let columns = play_state.cols().len() + max_column_groups;
    let layout = GridLayout {
        area: Rect {
            position: self.top_left - self.play_area_gutter(), 28
            size: self.size + self.play_area_gutter(),
        },
        rows,
        columns,
        cell_gap: self.grid_gutter,
    };
    (max_row_groups, max_column_groups, layout)
}

Since the origin point of the grid for the play area is now dynamic, I'm also returning the max row and column group numbers since that specifies where the red box starts in our picture. If we temporarily stop drawing everything else and tweak the background drawing method to use our layout, we can confirm that things are working as expected

pub fn draw_backgrounds(
    &self,
    play_state: &PlayState,
    input: &PlayerInput,
    gfx: &mut Graphics,
) {
    let (origin_x, origin_y, layout) = self.full_layout(&play_state);
    for (r, c, rect) in layout.iter_cells() {
        match (r < origin_x, c < origin_y) {
            (true, true) => {
                gfx.rect().at(rect.min()).size(rect.size).color(Color::BLUE);
            },
            (false, false) => {
                gfx.rect().at(rect.min()).size(rect.size).color(Color::RED);
            },
            (true, false) => {
                gfx.rect().at(rect.min()).size(rect.size).color(Color::new([128.,0.,128.,1.0]));
            },
            (false, true) => {
                gfx.rect().at(rect.min()).size(rect.size).color(Color::new([1.0, 1.0, 0.0, 1.0]));
            }
        }
    }
    return;
}

As you can see, the gutter is now a bit more dynamic and changes with the levels. So that will help out with the font issue for sure. If I nix the block colors of debugging, and instead replace each arm of the match with the rest of the code from the draw backgrounds method, we get this code:

pub fn draw_backgrounds(
    &self,
    play_state: &PlayState,
    input: &PlayerInput,
    gfx: &mut Graphics,
) {
    let (origin_x, origin_y, layout) = self.full_layout(&play_state);
    for (r, c, rect) in layout.iter_cells() {
        let (even_odd_bg_color, odd_even_bg_color) = self.palette.even_odd_color(r);
        match (r < origin_x, c < origin_y) {
            (true, true) => {
                // Draw nothing here in the space in the corner. Though we could
                // put a cute character smiling or something if we wanted to.
            }
            (false, false) => {
                // The Grid. https://www.youtube.com/watch?v=lWu40FA3eZk
                gfx.rect()
                    .at(rect.min())
                    .size(rect.size)
                    .color(Color::new(self.palette.background));
            }
            (true, false) => {
                // Top gutter (column groups)
                let colors = [even_odd_bg_color, odd_even_bg_color];
                let mouse_within_column_range = true
                    && rect.position.x <= input.position.x
                    && input.position.x <= rect.position.x + rect.size.x;
                let color = if mouse_within_column_range {
                    self.palette.group_highlight
                } else {
                    colors[c % 2]
                };
                gfx.rect()
                    .at(rect.min())
                    .color(Color::new(color))
                    .size(rect.size);
            }
            (false, true) => {
                // Left gutter (row groups)
                let mouse_within_row_range = true
                    && rect.position.y <= input.position.y
                    && input.position.y <= rect.position.y + rect.size.y;

                let color = if mouse_within_row_range {
                    self.palette.group_highlight
                } else {
                    odd_even_bg_color
                };
                gfx.rect()
                    .at(rect.min())
                    .color(Color::new(color))
                    .size(rect.size);
            }
        }
    }
}

And then, still not drawing the rest of the UI elements since we haven't updated them to use the full layout yet, we can see that everything is working as expected before, though it might look a bit funny since the background of the clickable area is just a void:

Now, where the real magic happens is when we update all the other methods to operate within the full grid layout. The update itself isn't too bad, and we can delete a ton of the old boilerplate code. Using the same technique I mentioned above, about computing an offset to start from and then drawing in the groups from that point on, we get this for the rows

pub fn draw_row_groups(&self, play_state: &PlayState, gfx: &mut Graphics) {
    let (origin_r, origin_c, layout) = self.full_layout(&play_state);
    for (r, groups) in play_state.row_groups.iter().enumerate() {
        let groups_in_row = groups.len();
        let start_col = origin_c - groups_in_row;

        for (i, group) in groups.iter().enumerate() {
            let column = start_col + i;
            let rect = layout.cell_rect(origin_r + r, column);
            // for some reason fonts position their _center_ at the position we tell
            // them to be. So just add half in to get the real placement location
            let position = rect.min() + rect.size / 2.;
            let text = &format!("{}", group.num_cells);
            let font_color = match group.filled {
                true => Color::new(self.palette.cell_filled_in),
                false => Color::new(self.palette.group_font),
            };

            draw_centered_text(gfx, text, position, rect.size.y, font_color);
        }
    }
}

and some extremely similar looking code for the column groups

pub fn draw_column_groups(&self, play_state: &PlayState, gfx: &mut Graphics) {
    let (origin_r, origin_c, layout) = self.full_layout(&play_state);
    for (c, groups) in play_state.column_groups.iter().enumerate() {
        let groups_in_column = groups.len();
        let start_row = origin_r - groups_in_column;

        for (i, group) in groups.iter().enumerate() {
            let row = start_row + i;
            let rect = layout.cell_rect(row, origin_c + c);
            // for some reason fonts position their _center_ at the position we tell
            // them to be. So just add half in to get the real placement location
            let position = rect.min() + rect.size / 2.;
            let text = &format!("{}", group.num_cells);
            let font_color = match group.filled {
                true => Color::new(self.palette.cell_filled_in),
                false => Color::new(self.palette.group_font),
            };

            draw_centered_text(gfx, text, position, rect.size.y, font_color);
        }
    }
}

There might be a way to refactor and write this code in such a way that it shares more but that's just yak shaving and really not neccesary, it'd probably be better to toss the drawing of a cell into a helper if I really want less text in front of me. Lastly, if we tweak the background drawing code for the clue areas by their respective uh, pokey bits? Erm. You know, the row clues expand horizontally, but the columns are vertical? Anyway. If we expand a bit while drawing the grid we can combine those together and we're now basically back at our old layout:

Granted there's a few little tweaks to make, like keeping the gap between the groups and the play area instead of it getting joined right now, and also maybe tweaking things so that we have groups of 5 with a slightly thicker border or outline of some kind to make the game more readable. But overall, we're pretty close, and most importantly, the font issues are all gone now and things are centered and looking decent.

The gap issue is easily solved by checking if we're on the border:

// Left gutter (row groups)
let mouse_within_row_range = true
    && rect.position.y <= input.position.y
    && input.position.y <= rect.position.y + rect.size.y;

let color = if mouse_within_row_range {
    self.palette.group_highlight
} else {
    odd_even_bg_color
};
// we + gap to join the squares together
let gapfill = if c == origin_y - 1 {
    vec2(0., 0.)
} else {
    vec2(layout.cell_gap, 0.)
};
gfx.rect()
    .at(rect.min())
    .color(Color::new(color))
    .size(rect.size + gapfill);

You might also notice that the column groups are checkered, we can fix that to make sure that the column group backgrounds aren't based on the row, but just alternated between. The checkered pattern came out because our background columns were changing every row, which works great to checker things for row based iteration, not so much for the column related ones:

pub fn draw_backgrounds(
    &self,
    play_state: &PlayState,
    input: &PlayerInput,
    gfx: &mut Graphics,
) {
    let (origin_x, origin_y, layout) = self.full_layout(&play_state);
    // Hold the column colors fixed for the group clues
    let (column_group_color_a, column_group_color_b) = self.palette.even_odd_color(0);
    for (r, c, rect) in layout.iter_cells() {
        ...
        match (r < origin_x, c < origin_y) {
            ...
            (true, false) => {
                // Top gutter (column groups)
                let colors = [column_group_color_a, column_group_color_b];
                ...
                let color = if mouse_within_column_range {
                    self.palette.group_highlight
                } else {
                    colors[c % 2]
                };
                ...
            }
            ...
        }
    }
}

Alright, looking good! ²⁹ We can also now easily change the anchor point of the PlayArea. Right now, the top left is the top left of the grid you can click on. Since we refactored everything to the point of the top_left field only being referenced within the full_layout helper, we can now shift that around and this is easy:

let layout = GridLayout {
    area: Rect {
        position: self.top_left - self.play_area_gutter(),
        size: self.size + self.play_area_gutter(),
    },
    rows,
    columns,
    cell_gap: self.grid_gutter,
};

Removing the math in red causes the entire play area to shrink as expected:

But then updating the position and size variables makes us able to stretch the whole region a bit more, resulting in a slightly larger grid to work with:

let bg_position = unit_size * vec2(10., 1.);
let bg_size = unit_size.x * 16.;

It's a little subtle, but the easiest way to tell what we changed and how this changed things to give us more room is how the top of the column hints now aligns with the big X button. It didn't do that before!

Now, for our last bit of polish before we dust our hands of this project for a little while. It's not going to be what my friend who plays picross a bunch would like me to do. Nope, we're not going to do something similar to what you see here with the 5x5 grids within the bigger grid.

I admit, it does help a lot in reading the board and not getting lost in cells after cells after cells in a row. But, I'd like to instead polish our screen transition a little. While I liked the idea of the "wipe" before, I think we can do something better now. How about a spiral?

Not a perfectly smooth spiral like you'd draw on your own, nah, we want to keep up the pixely blocky theme and have it do this instead:

This took a bit to figure out, but it's best understood piece by piece. First off, if you're thinking about this, you might think: hey, why don't I just use polar coordinates or something to compute the row and column, then round things off to get indices?

What, you think we're going to use a math solution when we can do a simulation solution instead? Clearly, you didn't enjoy my 2024 Advent of code post enough. Or at the very least, don't know that I much rather simulate a little guy walking around than compute their precise coordinates.

But we do need coordinates. Because if you remember, the wipe animation is based on the current time, so we need a way to jump to the appropriate stage of the animation without any issues. We already did this, just for both x and y before, so now it's simpler, because we don't care about interpolating a row and column, just how many cells need to get filled in:

*wipe_progress += frame_context.timer.delta;
let num_boxes = layout.rows * layout.columns;
let box_progress = *wipe_progress / duration;
let sin = lerp(0.0..=std::f32::consts::PI, box_progress);
let max_boxes_to_draw_this_frame = 1 + lerp(0.0..=num_boxes as f32, sin.sin()) as usize;

And just in case this doesn't click, I offer you this table to explain how things fill in:

Hopefully the little arrows help guide your eyes as if they were a sliding block puzzle on an icy floor of a zelda game. You can see that the order of the indices doesn't really have a great formulaic way to be computed (at least as far as I can tell), but we can encode the whole animation as a list of which row and cell would be filled at that point. For example, let's just take going from 0 to 3, that's running along the top. So, if we were hard coding this we'd write something like

let mut r = 0;
for c in 0..=3 {
    list.push(r, c);
}

Holding the row constant as we push along. But obvious this won't work once we try to do the same thing from index 11, as now we need to do:

let mut r = 0;
for c in 0..=2 {
    list.push(r, c);
}

But you can see the pattern here at least, the sides are shifting in. If we take the left paths it's even more apparent, as we have going from column 4 to 0 starting with index 6; then from column 2 to 1 when going left from index 14.

So it's not just one side, but all sides. Similar, if you consider the top and bottom sides, those also have to squeeze down. Everything must be squished! So let's very seriously smoosh up some cells

fn spiral_indices(rows: usize, cols: usize) -> Vec<(usize, usize)> {
    let mut indices = Vec::with_capacity(rows * cols);

    let mut top = 0;
    let mut left = 0;
    let mut bottom = rows - 1;
    let mut right = cols - 1;

    while left <= right && top <= bottom {
        // along the top going right
        for c in left..=right {
            indices.push((top, c));
        }
        top += 1;
        if top > bottom { break; }

        // along the right side going down
        for r in top..=bottom {
            indices.push((r, right));
        }
        right = right.saturating_sub(1);
        if left > right { break; }

        // along the bottom going left
        for c in (left..=right).rev() {
            indices.push((bottom, c));
        }
        bottom = bottom.saturating_sub(1);
        if top > bottom { break; }

        // along the left going up
        for r in (top..=bottom).rev() {
            indices.push((r, left));
        }
        left += 1;
    }

    indices
}

The only thing else of note in the above code is the break. Since we're collapsing our drawing space each time we take a turn, we can't rely on the while loop's condition to tell us to jump out if we run into a "wall" mid-iteration. Also, we don't ever want to go past 0 by accident, so the saturating_sub will help ensure we don't do anything silly like that.

Once we've got this helper to compute the spiral indices, we can easily adapt our current wipe code to use it to draw in the boxes according to a GridLayout

pub fn wipe_screen(
    wipe_progress: &mut f32,
    duration: f32,
    frame_context: &mut FrameContext,
    palette: &ColorPalette,
) -> ScreenAction {
    let gfx = &mut (frame_context.gfx);
    let screen_size = gfx.screen_size();
    gfx.camera().target(screen_size / 2.);

    let layout = GridLayout {
        area: Rect {
            position: vec2(0., 0.),
            size: screen_size,
        },
        rows: 10,
        columns: 10,
        cell_gap: 2.0,
    };

    let num_boxes = layout.rows * layout.columns;
    *wipe_progress += frame_context.timer.delta;
    let box_progress = *wipe_progress / duration;
    let sin = lerp(0.0..=std::f32::consts::PI, box_progress);
    let (even, odd) = palette.even_odd_color(0);

    let spiral = spiral_indices(layout.rows, layout.columns);
    let boxes = 1 + lerp(0.0..=num_boxes as f32, sin.sin()) as usize;
    for &(r, c) in spiral.iter().take(boxes) {
        let cell = layout.cell_rect(r, c);
        let color = if (r + c) % 2 == 0 { even } else { odd };
        gfx.rect()
            .color(Color::new(color))
            .size(cell.size)
            .at(cell.min());
    }

    let in_first_half_of_animation = *wipe_progress < duration * 0.5;
    if in_first_half_of_animation {
        ScreenAction::WipeLeft
    } else if *wipe_progress > duration {
        ScreenAction::WipeDone
    } else {
        ScreenAction::WipeRight
    }
}

Pretty nice right? The lerping sin wave is doing the same thing as it was before, allowing the maximum number of boxes to shift all the way up midway through the animation, and then back to 0 when we reach 100%. The GridLayout is continuing to pull its weight worth its refactor here too because we're not tied to trying to do for loop over rows and columns to do any math on figuring out which cell to fill in, but rather can just say "hey the spiral index says to draw in row 3 column 4, where is that?", and it just slides a rect down to us across the counter, winks, and says: "I gotchu homey".

Reflection time ↩

Alright, so according to the reading time calculation, you've been potentially reading for nearly 4 hours. Maybe more if you're using this as a sort of follow-along make a similar project yourself. So first off.

Congratulations

Platitudes aside, I appreciate if you read this far. If you're coming from the table of contents because you just wanted to know the results and spoil the ending of this tome, I guess congratulations to you too. You cheated not only the game, but yourself.³⁰ If you just wanted to get my thoughts on how it was making a game in rust versus in Java, then you're in the right place.

First off, I don't think the fact that I'm actively choosing to not include music and sound effects is rust's fault. It's more that I set myself a deadline of end of February, and it's now the end of February. I saw the writing on the wall a week or so ago and made the choice to get the grid layout and font related things polished up rather than risk the issue of cross platform audio support causing a problem with the builds.

And that's okay!

I think it's important that when it comes to these 20 game challenge projects that there are reasonable limits and expectations. The whole point of the challenge is to learn new things, build on the experiences, and strive towards tackling enough weird problems that the next time you face something you don't shy away and give up, but instead feel that push from all the small victories prior that gets your inertia going and says: you can do it.

Maybe that sounds like an excuse to not add sound to the game. But hey, it's my game I'll call the shots on if it's done or not. Fork y You can fork the project on github if you'd like and add your own sounds! It might be fun! The code runs on Mac, Linux, and Windows, so you have no excuse unless you're on like, windows 95 or an IBM 5100 trying to save the love of your live from a time loop death spiral or something.³¹

Ahem. Sorry. Now, about Rust vs Java. It was definitely a very different experience. You'll notice I loaded 0 textures from images at all in the rust project. It's not that egor doesn't have support for that, it does, but I'm not that familiar with the whole, texture ID, thing. Even though that's not actually that different sounding from LibGDX's AssetManager being keyed by name and such, not having the wiki and guide that says: this is how you do thing made me want to stick to what felt intuitive and easy to deal with, and thus, you get lots of rectangles being drawn.

Though I am amused that upon deciding to use PPM files to show the victory image for each level, and setting up a way to draw those, I pretty much instantly capitalized it on it to make my own icons and such. And that was also sort of the motivation for creating the level editor too. Not the whole motivation, obviously I wanted some tool to have to not have to write out PBM and PPM files by hand, but definitely became a gleeful feedback loop of "eating your own dogfood" that brought joy to my heart.

The level editor is actually where I want to spend more time on in a future post. And this is also a place where the development I usually do for Java vs Rust shows another big difference. When working on the Java projects, I hang out in Intellij, write the code, press the buttons, you know, the usual. I dread having to do something that involves touching the gradle files because those things are finicky. So while LibGDX has all those tasks to do nice things for you like say, build for multiple platforms, if anything goes wrong while that happens I'm out of luck and throwing my hands to the sky hoping I'll find something on stackoverflow to fix the problem. All of that is to say, that if I had wanted to create a level editor, I probably would have started a new Java project and had to figure out how to do local builds, references, and then make a fat jar with both things in it and it's all just… Exhausting. Exhausting to think about how to get a custom task to fire up an editor and yeah.

But in contrast, cargo is easy as heck to use. Sure, I ran into some problems when I misunderstood the way src/bin worked and I tried to make a separate library set of files inside of there and share things that were technically in different crates, but hey, that aside, it was easy to just say "Yeah I've got these ppm and pbm structs and I want to use them too and make a new binary". So it felt like it was easier for me to make my own tool to do some specific task I needed to get done. And that's pretty powerful.

On the other hand, because my preferred choice of editor in Java is IntelliJ (one of the few places I don't use sublimetext), LibGDX work definitely has the upperhand when it comes to ease of refactoring. IntelliJ has a ton of built in mechanical refactoring tools that make extracting interfaces, lifting classes up and out, or even generating test boilerplate all super easy. Meanwhile, in rust world, I do it all by hand and have to take breaks because my wrists bother me after a while. There are "fixes" to this of course, probably plugins for sublime I could use, or something similar, but it just doesn't feel quite right. And that's not just the tension in my wrists that feels off. There's just something very normal to me about leveraging and using all those "power tools" in an IDE that makes it feel natural in Java. But with Rust, it's closer to the metal, and it feels better to be flipping between editor and terminal.

Another major difference is that egor is an immediate mode UI. So if you want to check if a button is clicked, you're checking on that frame right then and there. But with LibGDX, it's callbacks and listeners, so very much a retained UI pattern at work. LibGDX encourages abstracting out that interface between those glue points and your core code if you're disciplined about it, and it works well for testing if you do.

Egor makes it both easier and harder to do this glue work. Easier, because what you see is what you get, you write that you checked the button there, you checked the button there. But the back of my mind while doing all that is the question of "is the FPS going to tank because I'm doing this"? It doesn't mind you, but it's what I'm thinking about when I write spiral_indices and then stick it into a call that happens every frame rather than suffer the pain of threading it down from the main method to the callpoint so I only compute them once. It's an easy to reason about model, but it encourages the combination of state and display into one place that's easy to fall into and be trapped by. A far cry from my object oriented interfaces that all for easier testing.

That said, that egor has egui underneath it, and that I could make a debug widget to get the same sort of functionality as you might find with unity or similar is awesome. There's a good post that someone shared with me a while ago about making games with no engine in 2025 that captures the home grown tooling aspects like this can really empower development. And I fully agree with the sentiment. Saying: I need thing, and I can make thing easily. Is really nice. There are definitely better ways to do it than &DebugStuff being passed around, but that's probably for a different post to explore more.

To circle back to Java vs Rust again though; I'm quite comfortable in Java, and in thinking about patterns within that realm. Builders, adapters, trees, strategies, anonymous functions, all that good stuff are things I'm comfortable deploying into the process of making a game and feeling like I know what I'm doing. In case it wasn't obvious to you, I am far more a novice in Rust than I am not. While I understand, abstractly, how to do a lot of things, when it comes to getting the syntax right or fighting the borrow checker to a stalemate, I'm sorry to say that the borrow checker "has hands".

But in a way this is a good thing. Not knowing the idiums means I get to make my own or discover things myself. There's certainly better ways to do things, better ways to organize code, avoid traps and bugs, and certainly more ways to be efficicent than the code I wrote. But it's fun. And that's what's important! I've always enjoying the process of programming, not neccesarily the results. Which is why it's now a good time to take stock of things, did we actually accomplish our goals? Listing these off from the first section, that I wrote, over a month ago: ³²

1. We should be able to create puzzles from a file
2. We must display the constraints for the puzzle
3. There should be a win condition

That low bar was definitely cleared. One other aspect mentioned in that same section, about ensuring puzzles are solveable, is going to be it's own post. There's no way that I'm tackling an NP complete problem in the middle of a game programming tutorial dev log thing. That wouldn't be fair to the interesting parts of doing nonogram solving! And going back to the start of this reflection section, it definitely wouldn't fit into publishing this before February's up!

This has been very rambley, maybe moreso than usual, but that's probably because it's 1:38 am on February 28th and I'm a little tired. But can you blame me? I don't think I've written a post this long since the match 3 game! The game is available, for free as per usual, on Github and you can download the appropriate zip file for your system and play it if you'd like. There are 15 levels, none of which I guarantee are solveable. But you can make your own levels! The level editor comes with the zip and will save things for you to the same folder the game expects it to load from.

Now, is the game any good?

No. Absolutely not. If you think I'm going to be playing my version of picross/logic paint/nonogram over the adorable, fun and happy, cute and adorable, musically wonderful game of Miku Logic Paint S+, then you've got more bugs than we've solved in this post running around inside of your head.

If I wanted this game to hold a candle's chance in a snowstorm levels of being "Ok" in comparison, we'd need to:

1. Add sounds and music
2. Create proper levels that are solveable without guesswork
3. Make proper pixel art
4. Improve the UI and UX to group 5x5 grids together to make the grid more readable
5. Get proper icons for the mouse and not just have the instructions sitting on a side
6. Include a tutorial to orient a user to the game in the first few levels
7. Create settings pages that allow palette swaps for colors
8. Make the color scheme properly accessible and not low contrast like it is now
9. Make the level editor more useable, like being able to load a saved file to modify. Right now it's less level editor and more level create and pray you don't have to change it by hand later.
10. Profile, optimize, and ensure that we don't make unneccesary structs and data where we don't…

Stop

There's probably more stuff that we could think of if our heads tapped together a few times. But that's just what comes to mind that doesn't have anything to do with putting adorable characters into the game! But, to put a pause to the deluge of what could be, remember that this is just another 20 games challenge game. Which means that the key point was to learn, not to make the perfect game.

So. What did I learn? I learned that it is very possible to make games in rust with egor. I also learned that, while egui was great for tooling, I felt the itch to be unconstrained by some of the guardrails and limitations that egor had in place. And that itch makes me want to explore SDL3 a bit, as I've heard good things and am intrigued. Whether or not SDL3 is used in the next project is an open question, we'll see!

Thanks for reading, and again, if you made it this far. Wow! I hope that it was interesting and that you learned something too! If you're hungry for more, there's always another slice if you look around the blag at some other posts. Or if you're looking for side monitor background noise, my twitch channel and youtube vods are linked on this site if you're very bored. But anyway, until next time, have fun with your new game!