Game with Macroquad

This is a temporary devlog until I make a devlog in video form.

Landing on the Macroquad framework for the jam was wild. I wasn’t really sure that I knew enough Rust to start actually writing a game code. For the experience, I think I need to include experience with Rust language too. Since it is built into Rust’s ecosystem, libraries can provide example code snippets in small application isolated use cases. It’s done through terminal/cmd/PowerShell and calling cargo run --example ui in the libraries directory. Rust compared to other conventional programming languages is a strongly typed programming language. Still, most times you don’t need to type the type for a variable if the context is predictable. Also, it integrates into Visual Studio Code or a WIP alternative made with Rust Lapce and shows types on top of your code. In Rust on top of that, you need to decide if you need a variable that’s going to change value a.k.a mutable. And using the variable you need to decide if its existence goes along with it, or pass just reference that variable, or pass a mutable reference, meaning that on another end original can be mutated. That’s just the surface.

I knew my code writing won’t get me far so I focused on a single-screen, top-down shooter. Because physics is going to be as basic as checking distance a.k.a. circle collision . Oh, and if you don’t know what the difference between a game engine and a game framework is - with a framework you make your own systems (sprite animations, physics, events, tile maps) but sometimes some systems are already there. Knowing I’ll have to make pretty much everything I at least wanted to color sprites with code and it’s easier to do in 1-bit sprites. So I took Kenney's 1-bit pack and made a background (walls, gravel, foliage) into separate PNGs. Then I collected characters in one PNG. For sound, I used the Sfxia generator at the jam development end.

With limited capabilities in Rust, I had to structurize the code in top-down tick trickling calling, and giving references.

After getting to render my background and coloring each layer just as I wanted I hit a problem. The camera system in Macroquad is confusing as hell. Here’s an example code from the framework’s developer - it’s a variation for the camera when making pixel art games and cameras top-left be on worlds (0, 0).

pub fn new_camera_top_left()->Camera2D{
    let zoom = (screen_width() as i32 / GAME_WIDTH).min(screen_height() as i32 / GAME_HEIGHT);
    let zoomed_w = GAME_WIDTH * zoom;
    let zoomed_h = GAME_HEIGHT * zoom;
    Camera2D {
        target: vec2((GAME_WIDTH / 2) as f32, (GAME_HEIGHT / 2) as f32),
        zoom: vec2(2. / GAME_WIDTH as f32, -2. / GAME_HEIGHT as f32),
        viewport: Some((0, screen_height() as i32 - zoomed_h, zoomed_w, zoomed_h)),
        ..Default::default()
    }
}

For showing a sprite’s rectangle out of a bigger texture I made SpriteSheet functionality - accessing an individual rectangle by index. I didn’t end up writing animation code in time for the jam.

The framework had very straightforward uses for other things - Sounds, time, random, and input. With text drawing, the origin point is the bottom-left corner, but for rectangle drawing, it is the top-left.

Making list with object collections like enemies and bullets actually wasn’t as frightening as I thought it would be. Rust has a neat implementation of Vectors (some languages called List - dynamic array).

I was so looking for adding particles. As I found out there was a running bug with the emitter’s lifetime. The frameworks developer quickly corrected that and my continuous particle stopped acting like a single shot. But there are some discrepancies between the drawing position and the emission position. That’s why for html5 game size is locked.

Talking about HTML5 the Rust can easily compile a game into WASM that can be loaded with HTML + javascript (template is in Macroquad repository readme).