thetawavegame / thetawave-legacy Goto Github PK

It would be nice to show some sort of visual indication when the game is paused. Perhaps for now the text "PAUSED" can overlay the entire screen. Later it could be extended to show a menu.

A short description on how to get started contributing to Space Shooter should be available. For now, I think it will be enough to include a quickstart guide:

• Steps for checking out the repository, building, and running the game

• Finding an issue

• Creating a PR

If possible, it would also be nice to have guides available for adding new items, enemies, and characters. But this can be addressed in another issue.

A Motion2DComponent will have the properties for velocity, acceleration, angular velocity, and angular acceleration. This will replace the velocity and acceleration values that are currently stored in the core components for entities.

Motion2DComponent properties:

pub struct Motion2DComponent {
    pub velocity: [f32; 2],
    pub acceleration: [f32; 2],
    pub angular_velocity: f32,
    pub angular_acceleration: f32,
}

Graphical bug where where sprites sometimes appear with a sliver of neighboring sprites attached to their sprite.

Running cargo clippy on the cdsupina-dev branch results in many warnings. The CI should also include running clippy at some point and it would be a good idea to clean up these warnings before doing so.

Currently all enemies move in a straight line downward at a constant speed. I simple idea for a third enemy would be one that strafes left and right while traveling downward.

We will likely want to add abilities to the game that require mouse positioning. Changing the existing controls to only use the player's left hand will free up the right hand to use the mouse.

The player is able to immediately interact with the game (move the spaceship around) while assets are still loading. This makes the experience seem like the game is in a broken state since nothing appears on the screen for a while.

This issue looks at implementing a "Loading" screen that waits for all initial assets to be loaded before the user can start playing.

We can probably start looking at this https://book.amethyst.rs/stable/assets/how_to_use_assets.html to get started.

To add more feedback and satisfaction to destroying enemies, we should spawn little parts of the spaceship and give them a random xy velocity and a random angular velocity.

If we want to keep things "realistic" we should weight the random xy velocity to lean towards the velocity of the source enemy.

Giblet entities should have the following components:

• SpriteRender
• Motion2DComponent
• Transform
• Transparent
• TimeLimitComponent

Phase-out spawn_sprite_entitiy and spawn_animated_entity in entities/mod.rs. These functions are no longer effective for reducing code due to the refactoring of components.

entities/mod.rs

The ManualBlasterComponent would be used for spawning blasts when input is pressed.

UiText elements are not properly scaling depending on the resolution. To see for yourself in main.rs change:

let display_config_path = app_root.join("config").join("display_config_640.ron");
to
let display_config_path = app_root.join("config").join("display_config_960.ron");
or vice versa.

This issue looks at documenting the current state of space_shooter_rs's ECS architecture. This aims to be a helpful resource for both maintainers and new contributors when navigating the project's code. Ideally, this part should have a good balance between text content and visual aids.

Relevant files

• book/src/SUMMARY.md (update the relevant links)

• Create Markdown files for documentation

This issue adds an item to the pool that increases the player's blast size. Implementation details will include accompanying sprite art and modifying BlasterComponent.size_multiplier in systems/item.rs.

Relevant files

• Item entry

• System for apply item effects

A TimeLimitComponent subscribes an entity's lifetime to the duration it's assigned to. This means after a certain amount of time, the entity will be deleted from the game when its duration is done.

The TimeLimitComponent should have the following property:

pub struct TimeLimitComponent {
    pub duration: f32,
}

Relevant files:

• Explosion component
• Explosion entity
• Explosion system

The Enemy and Spaceship (the player) components share a lot of similar attributes. Some examples:

• hitbox_x_offset/hitbox_y_offset
• hitbox_width_offset/hitbox_height_offset
• health

This issue should look into identifying these attributes and abstracting them into their own components where necessary. Doing this will make information management for these components much easier in the future.

Relevant files:

• Enemy component
• Spaceship component

This issue looks at creating documentation for adding new items to the game. This will involve the following steps:

1. Create a new Markdown file in book/src/ called "add_items.md" (or something similar). This will be where the content for adding new items will be.

2. In book/src/SUMMARY.md, update the link for "Adding new items" from "TODO.md" to "add_items.md".

3. Write about it!

Systems in general need to be refactored now that entities are made up of smaller, more modular components. The item system is probably the most complex of the systems to be refactored due to how items are intended to impact the rules of every system in the game.

Current item system in cdsupina-dev branch: https://github.com/amethyst/space_shooter_rs/blob/master/src/systems/item.rs

It may make sense to use an event channel to communicate with other systems in the game with the item data to augment the components in the system.

Blasts are not being despawned in time to not show up on top of the side panels. Blasts should also be at lower Z level than the side panels.

As @tigleym pointed out in her comment in #68, rustfmt is formatting the code in an unpleasing way in some cases.

example

I believe there is a way to create a config file for rustfmt where we can specify exactly how we want code formatted. We should do this to address cases like the example here.

I think this may have been lost during the collisions refactor. We may want to wait to address this when we get to refactoring the character abilities.

This enemy should be very slow and have a low fire rate of missiles that home in on the player.

This issue is for tracking tests added to the project. One place to start is using the guide for testing Amethyst types available at https://docs.amethyst.rs/stable/amethyst_test/.

In systems/collision_detection.rs, we should be able to use Hitbox2DComponent.is_colliding instead of hitbox_collide.

Relevant files:

• systems/mod.rs

• systems/collision_detection.rs

This issue looks at documenting the process for adding pixel art to the project.

Relevant files

• book/src/SUMMARY.md (update the "Contributing art" link)

• Create Markdown file(s) for documentation

There are a few systems that use play_sfx to play sounds whenever a specific event occurs. Because of this, these systems have to read from three extra resources: AssetStorage, Sounds, and Output. This ends up adding data and extra complexity to these systems than is necessary.

It might be worth investigating adding a new event channel called PlayAudioEvent and a new system that receives this event called PlayAudioSystem. The PlayAudioEvent payload would provide some sort of identifier of the type of sounds the PlayAudioSystem should play.

After merging #44 we should remove the use of fire_blast and replace with spawn_blasts in systems/spaceship.rs

Relevant files:

• systems/spaceship.rs

• entities/blast.rs

The Enemy component currently stores data about its Animation component. We can clean up the Enemy component by only specifying this data for the Animation component that's added to the entity created for an enemy.

Relevant files:

• Enemy Component

• Enemy entity

Entities are spawning and despawning in such a way that is unpleasing. If you look for it you can see them just pop in and out of existence at the top and bottom of the arena.

In the first paragraph of your readme, you link to your website. This link is dead; it now leads to a 404 page.

This section is for where people can get a list of all of the items, enemies, consumables, characters, etc. in the game and what they do. This information is currently in the readme.

The AutoBlasterComponent will hold properties used for automatically firing blasts from enemies. This component will ONLY be used for blasts. In the future when other projectiles like the "Missile" enemy are added, they should have their own component for auto firing.

AutoBlasterComponent properties:

pub struct AutoBlasterComponent {
    pub count: usize,
    pub allied: bool,
    pub shot_velocity: [f32; 2],
    pub damage: f32,
    pub poison_chance: f32,
    pub crit_chance: f32,
    pub offset_x: f32,
    pub offset_y: f32,
    pub size: f32, // look into possibility of increasing the size of the image and hitbox without needing to create a new sprite
    
    // frequency of blasts
    pub fire_speed: f32,
    pub fire_reset_timer: f32,
}

When multiple sounds are initiated in such a way that they overlap. They compound to be super loud which makes for an unpleasant experience.

A health component will be used for tracking the current health and limiting maximum health. Currently, it would be used in the Spaceship (Player), Enemy and Defense components. It should lead to the Living trait being phased out.

pub struct HealthComponent {
    pub f32: health,
    pub f32: health_max,
}

Right now there are a number of systems that detect and handle collisions differently through event channels.

For enemy-enemy and player-enemy collisions, there is a single system that detects these events in systems/collision_detection.rs by writing CollisionEvent to a subscribed system . The respective event handlers are then executed in enemy_collision_handler and spaceship_collision_handler systems.

On the other hand, collision events for consumables and items are detected by writing a HitboxCollisionEvent to a subscribed system. This is done in hitbox_system.rs. The respective events are then handled by their systems: item.rs and consumable.rs.

This issue should explore consolidating how collision events are detected and handled effectively. Right now, the following collisions are relevant:

• Enemy to enemy

• Enemy to Player

• Player to item

• Player to consumable

One approach is having one collision event (perhaps use the existing CollisionEvent) that can be written to an event channel and handled separately by their subscribed systems. This means we have one collision detector system. So refactor the existing collision_detection.rs to be more generic. Then have the following collision event handler systems:

event handlers

• collision_handler_system

• spaceship_collision_handler

• item_collision_handler

• consumable_collision_handler

We'd need to pass in the type of event in the event data. This is something we already do and the systems just need to interpret that.

Another approach is to have different event types instead of the one. These events would then have their respective systems listen for a specific event instead of trying to interpret them:

collision event types

• EnemyCollisionEvent: the handler needs to implement how enemy entities are affected

• PlayerCollisionEvent: the handler implements how player entities are affected

I think with either approach we should think of "Player-item" or "Player-consumable" collision as events of type PlayerCollision so it might not be necessary to have the additional item/consumable systems. Though I'd like your input on this @cdsupina!

If a rigidbody has no velocity and is touching a boundary, it can slowly translate through it if the right input is pressed.

Now that a Hitbox2DComponent is available, we should consider removing width/height properties on components that don't have uses for them. For example, the Enemy and Spaceship entities use the Hitbox2DComponent and don't have a use for their width and height properties outside of Rigidbody.contrain_to_arena.

Relevant files

• Spaceship component

• Enemy component

• Consumable component

• Item component

A Hitbox2DComponent specifies a boundary box around an entity in physical space. If two hitboxes overlap the entities are colliding.
Currently, hitbox parameters are specified in each core component of individual entities (Enemy, Spaceship, Blast, Item, etc). These parameters should instead be stored in the Hitbox2DComponent.

A Hitbox2DComponent should have the following properties:

pub struct Hitbox2DComponent {
    pub width: f32,
    pub height: f32,
    pub offset_x: f32,
    pub offset_y: f32,
}

Entities whose Motion2D components with a rigid_body property set to true should be able to neglect any forces exerted on it. So if entity 'A' collides with an entity 'B' with rigid_body, entity B's Motion2D component will not be affected by the collision.

This issue will add an mdbook to the project. It will be where the contributing guidelines will be outlined.

In the future, this book will contain documentation about the project's implementation details and guides on how to add new features.

There are some components that implement the Spawnable trait to assign a name to the entity they are attached to. For example, the Enemy component does this.

There is already an existing component called Named that adds this functionality. This issue is meant to remove the name attribute from components that use it and instead attached the Named component to their respective entities:

Relevant Files:

• Explosion component
• Consumable component
• Item component
• Enemy component

This issue can be broken down into smaller tasks (perhaps per component) if this it turns out the changes are larger than expected.

It doesn't look like the components with the Spawnable trait are using any of its methods. We should remove this trait if they aren't being used anywhere.

Relevant files

• Spawnable

• Item component

• Consumable component

• Timelimit component

If the player tries to buy an item with insufficient funds, there's no indication either visually or through sound, that the item is not purchasable. This can be a confusing experience for players focused on navigating the arena and the item they are expecting to purchase isn't appearing.

The current state of systems is unorganized. Instead of handling the consequences of an enemy's death in enemy.rs, they should be handled in systems related to consumables and explosions. This should be done using an event channel.

Related files: systems/enemy.rs

Add item to item pool that increases the total health of the player by a reasonable amount.

Currently, the "Blast" component stores the data for motion and damage for blast entities. The values for motion should be transferred to a Motion2D component, and the values for damage should remain in the refactored BlastComponent.

The allied property should be removed and the BlastType enum should be expanded to specify whether a blast is from enemies or an ally (including the player).

pub enum BlastType {
    Ally,    // yellow blast
    Enemy,    // red blast
    AllyPoison,    // green blast
    EnemyPoison,    // no sprites drawn yet (for potential future poison enemy)
    AllyCritical,    // purple blast
    EnemyCritical,    // no sprites drawn yet (does it makes sense for enemies to crit?)
}

pub struct BlastComponent {
    damage: f32,
    poison_damage: f32,
    velocity_transfer: f32, // (velocity factor) how much the source velocity should affect the blast velocity
    blast_type: BlastType,
}

velocity_transfer should maybe be moved to a source component such as an Enemy or AutoBlasterComponent.

Currently enemies travel straight downward essentially targeting the total "defense". An enemy should be added that targets the player in an attempt to specifically damage the total "health".

To ensure code quality and to prevent regressions, we should have some sort of CI workflow setup. I think it would be easiest to set up with GitHub Actions.

Side panels and bars were added in 0.10.0 amethyst. Currently they are sprites. It would be more ideal if they were ui elements.