diff --git a/README.md b/README.md index 8fbd72029aee419768bf1741bcd01c01cda9e820..1dc9de628a7c63d1027ddd5f450762e21b6c413c 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # MyLittleZombie -A small example of sprite animation. Tested under linux (arch) and win10. +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. ## Prerequisites @@ -15,18 +15,62 @@ Tested mainly under win10. ## Key dependencies - [bevy](https://www.bevy.com/) - [bevy_esc_tilemap](https://github.com/StarArawn/bevy_ecs_tilemap) +- [rs-tiled]() ## Assets - [Zombie sprite sheet](https://www.kenney.nl/assets/toon-characters-1) - [Tiles](https://kenney.nl/assets/pixel-platformer) -## Tools +## Tools used -Tile map created with [tiled](https://www.mapeditor.org/) +- [Tiled](https://www.mapeditor.org/) +- [Piskel](https://www.piskelapp.com) -## Design +## Documentation +- [Cheatbook](https://bevy-cheatbook.github.io/) + +## 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](https://arewegameyet.rs/), 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](https://bevy-cheatbook.github.io/) 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](https://www.kenney.nl/assets/toon-characters-1), 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](https://github.com/StarArawn/bevy_ecs_tilemap), 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](https://www.mapeditor.org/) (classic tiled map editor) for the map creation and [Piskel](https://www.piskelapp.com) for sprite and tile artwork. Other popular alternatives are [LDTK](https://ldtk.io/) (map editor) and [Aseprite](https://www.aseprite.org/) (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 mini-boss. + + + + + + + + +## 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