Skip to content
Snippets Groups Projects
Select Git revision
  • ca5b1a5729e9d271860522120eb8fd47de4c211b
  • master default protected
  • refactor
3 results

README.md

Blame
  • Per Lindgren's avatar
    Per Lindgren authored
    ca5b1a57
    History

    MyLittleZombie

    This project is created with the main purpose of learning (and perhaps teaching) a little bit of game development, the tools used and the methods applied. This crate is a living document and a platform for experimentation, see sections Background and Progress for the journey. The Tricks and Tips section elaborates on related tools and libraries used, I wrote it mainly as a note to self, but others might find the information useful too. I'm open to all kinds of discussions and suggestions. Everything is WIP, expect no release until 2077.

    Prerequisites

    • Rust toolchain with nightly (for faster builds)

    Tested mainly under win10.

    Usage

    cargo run --release

    Key dependencies

    Assets

    Tools used

    Related Documentation


    Tricks and Tips

    Piskel 0.14.0

    Typical workflow:

    • Tile sheets:
      • Decide on the size of each tile, e.g. 16 * 16 pixels, 32 * 32, 64 * 64 (I believe this is the current maximum for use in bevy_ecs_tiledmap).
      • Select "Resize" to set the size of the canvas, e.g. 10 * 10 tiles (in the case each tile size is 16, this means 160 * 160). There are some options here to resize, re-position the current canvas if you already started out painting. You may store the default canvas size as well, so a new instance will automatically inherit the setting (new Canvas "+" upper right corner to create a new Piskel instance).
      • Select "Setting/Grid" grid size "1", and grid setting "16" (matching the size you chose for your tiles). (Grid size is currently limited to 2^n, e.g., 8, 16, 32, 64).
      • When working with your tile sheet you may want to preview how a tile would look when "tiled" together. Under "Setting/Tile Mode" you can enable tiled mode, however the complete canvas will be tiled (which might not be what you want). You can work around this problem by creating a new instance with a canvas size set to match your tile size, select "Tiled mode" for that canvas and use this Piskel instance to preview the tiled appearance. From your original tile sheet, copy ("Rectangle Selection" and Ctrl-C) the area of the tile. Paste the tile to the top left corner (if not already working on the top left tile that is). Now the top left corner area and paste it in the tiled mode preview instance (tick the "Settings/Tiled Mode" for the preview instance). The reason for this somewhat cumbersome workflow is that copy/paste in Piskel operates relative to the top left corner of both instances (as the target instance is only one tile, it corresponds to the top left corner of the source instance). If you find a better way to do this please make an "Issue" on this repo (or even a PR).

    Background

    Starting from a clean slate (never did any modern games programming, though I was attempting to program games in the early days of the C64 and later Commodore Amiga). For me best way to learn is by doing, experimenting and playing around, so let's dig into it. Rust as language was a natural choice since I work with Rust on a daily basis, both as a researcher/teacher at Luleå University of technology (LTU) and as expert consultant for Grepit AB. In both cases focus is on embedded programming where where we adopt Rust due to language properties (zero-cost abstractions, memory safety, modularity etc.) as well as the excellent ecosystem (building and versioning) together with a very active and welcoming community.

    Which tools and why?

    There is a fair number of games related developments emerging see e.g, Are We Game Yet, which one to choose? Let's take a step back. Using Rust a program passing compilation is ensured to be memory safe (either proven statically e.g., life-time and borrow checking at compile time, or (in special cases) at run-time (by injected assertions, e.g., bounds checking). While memory safety is great news (ask any C/C++ programmer that abandoned ship for a biased opinion), the programmer is forced to face resource management up front which may be taxing, expressions like "fighting the borrow checker" and "a lifetime to master" comes to mind. There is no free lunch here, though the price goes down with time and experience.

    With this in mind, the core of any game engine (or framework) is the way to organize your data and perform the rendering. To the first part, an Entity Component System (ECS) is a common approach, providing abstractions to manage resources or "assets", e.g. sprites, textures, tiles etc. That's where Bevy shines, providing a clean (and relatively) simple to grasp way of managing and associating resources, even in the presence of concurrency. At the time of writing, Bevy undergoes further improvements to the ECS API, promising to further improve the ease of use. Make no mistake, there is a lot of type system trickery going on under the hood in order to accomplish the polished surface and memory safety of Bevy, a beautiful work of software engineering! This alone was sufficient for me to get onboard, now after a few weeks of usage I'm gradually getting familiar with the design and its usage (still learning by the day/night). Easy to grasp is relative, still you need to learn and understand the API and how to put it in use.

    Leaving rending details aside for the moment, we want to get something going. To that end, Bevy comes with a set of small examples that demonstrates key features. There is also the Cheatbook that explains concepts in more detail, very helpful.

    In order to make things simple, I set out to experiment in 2D retro style. I found a free and ready to use sprite sheet Zombie sprite sheet, and within ours I had an animated zombie limping on the screen controlled by a keyboard input system. Indeed easy things were easy (given that you can live with the fact of knowing what is really is going on).

    Next up, any game needs a map right? And maps are (typically) made from tiles. While tile maps are (currently) not part of Bevy we can leverage on third party (free standing) libraries for additional functionality. The selection fell on bevy_esc_map, which adopts (as the name indicates) an ECS approach to managing tile related resources (more on that later).

    After playing around with a few sprite and tile editing tools, I decided on Tiled (classic tiled map editor) for the map creation and Piskel for sprite and tile artwork. Other popular alternatives are LDTK (map editor) and Aseprite (sprite editor).

    Within a few more hours, a My Little Zoombie were walking on tiles (or rather walking through tiles as no collision system was in place).

    Already at this point, artistic creativity could be explored! Together with my 8 year son Sten and my wife Iris we had a blast playing with Piskel and Tiled enjoying the trade of pixel art. Tile and sprite sheets were flying back and forth over Telegram, while I was struggling with the animation code. Gradually we replaced the professionally designed tile sets with our (not so professional) attempts as seen. Shitty is pretty!

    When playing with Tiled, we encountered some shortcomings of the crates at hand. So, let's dig into the first challenge, the Tiled animation mini-boss.

    Progress report

    StarAwan date 2021-08-10 (approximately).

    Tiled animation

    Tiled rotation and flipping

    Tiled parallax

    Controller input

    Some platform specific tips

    Win10

    When developing under Win10, you need git https://git-scm.com/downloads. Gitbash comes with a shell/terminal. Alacritty is a another (fast) terminal, that uses the GPU for rendering. Under the hood it defaults to powershell.

    In powershell you set environment variables through $Env:<NAME> = "<VALUE>". To get a full call stack trace on panic:

    > $Env:RUST_BACKTRACE = "full"

    You may also use this to set log level.

    Thanks

    I like to express my gratitude to StarAwan for patiently pushing me in the right direction. Also, I'd like to thank Parallellaxiom for numerous discussions further the project. Moreover, I'd like to thank Johannes Hirche at Embark for enlightening discussions, there will be "easing" of the camera soon I promise

    License

    TBD