Skip to content

Noah2610/deathframe

Repository files navigation

deathframe

An opinionated rust game development framework using the amethyst game engine.
It's like a "goodie-bag" of features and boilerplate code for amethyst projects.
deathframe abstracts many of amethyst's features, the way I find it easier to use,
with less boilerplate, setup, copy/paste. Very opinionated.

Usage

For the latest release from crates.io, put this in your Cargo.toml file ...

[dependencies]
deathframe = { version = "0.5.1", features = ["vulkan"] }
# Features must include one of:
#     "vulkan", "metal", "empty"

For the development version on the develop branch ...

[dependencies.deathframe]
version = "*"
git = "https://github.com/Noah2610/deathframe"
branch = "develop"
features = ["vulkan"]

Features

deathframe is split-up into a couple crates.
All sub-crates follow a similar structure.
The root deathframe crate re-exports all of these,
and provides some common specs / amethyst preludes ...

  • bundles
    Every sub-crate gets a bundle in the root crate.
    This makes plugging-in a crate's systems easier.
  • components, systems, states preludes
    These simply re-export a bunch of specs and amethyst types,
    which are needed to write components, systems, and states.
    They also re-export components and systems from all enabled sub-crates.
  • resources
    Re-exports resource types from sub-crates.
    A resource is something that is usually inserted into the specs world,
    and that is usually used in systems.

deathframe_core

The main crate. Holds common types and components, used across all sub-crates.
Also holds miscellaneous data types and traits,
that I find useful, but don't know where to put.

A core feature is the entity loading system.
Using the Loadable, Loaded, and Loader components, together with
the EntityLoaderSystem (or write your own), many systems through-out
this crate will be enabled or disabled for entities, depending on their
Loaded and Loadable components.
Many systems will only run on entities that either have both the
Loadable and Loaded components or have neither component.

The CustomGameData is a big one, which manages multiple dispatchers,
which can be updated individually from within states.
It's supposed to be used as a state's GameData.
I really need to rename that. Also needs refactoring.

There's also the InputManager, which is an abstraction over
amethyst's InputHandler, which enables you to check for
keydown, keypress, and keyup events separately.
It's not perfect. Like everything in deathframe.

SpriteSheetHandles is another note-worthy resource. I still use it,
although I think you can definitely do without. Basically, it simplifies
loading sprite-sheets, and getting handles to them.
This was useful when I was learning amethyst, and the asset loader was weird new to me.

deathframe_animation

Frame-by-frame animations for entities. Cycle sprites with delays.
Animate entities that have a SpriteRender with the Animation component.
An entity can hold and switch between multiple animations with
the AnimationsContainer component.

deathframe_audio

Adds abstraction over playing and controlling audio with amethyst.
There are two main resources in this one:

  • Sounds (SFX)
    For loading and playing sound-effects.
    Sounds that you simply play and forget.
    You can attach the SoundPlayer component to entities,
    to easily allow entities to queue sound-effects.
  • Songs (BGM)
    For loading, playing, and controlling playback of background music.
    The major differences to Sounds, is that this can or should only play
    a single song at once, and that the playback has state,
    which you can manipulate (play, pause, change song and playback behavior).

deathframe_physics

Adds some common physics-related components, such as Velocity and Gravity.

It also adds my implementation of collision detection, for general collision checking,
and for moving solid entities, without them intersecting.
Make entities collidable and solid with combinations of the components
Collidable, Collider, Solid; all collision checking entities
will also always need a Hitbox component.

The actual collision detection "algorithm" is very naive and simple.
For now, it only works with rectangles. Surprisingly, it seems efficient
enough for my game projects (as long as entities are properly loaded and unloaded).

To make checking for collision events easier, there's the query module,
with which you can build and run collision queries on Collider entities.

Cargo feature flags

Name Description Default?
vulkan For amethyst's vulkan backend.
metal For amethyst's metal backend.
empty For amethyst's empty backend.
animation Use deathframe_animation crate.
For sprite frame-by-frame animations.
Yes
audio Use deathframe_audio crate.
Simple BGM (Songs) and SFX (Sounds) systems.
Yes
physics Use deathframe_physics crate.
Adds velocity, gravity, friction, other stuff, and my implementation of collision detection and solid collision for moving entities.
You should consider doing your own thing with a proper collision engine.
Yes
debug To enable some specific debugging code.
Unnecessary, but I always turn this on while developing.

License

Distributed under the terms of the MIT license.

About

Rust game development framework using the amethyst game engine.

Resources

License

Stars

Watchers

Forks

Packages

No packages published