I'm not sure we do for this library, maybe another project?

Also what would that look like in code. Let's create a discussion here.

Functions that create meshes are starting to get messy.

We could create a mesh structure to store them in the same place.

Sometimes we want things to happen every n seconds. This could be useful for adding food on a regular schedule, or anything else in real time.

I'm thinking of something similar to what @dannyfritz is doing here

Currently our main.rs file looks like:

use fluid::*;
use ggez::{ContextBuilder, event};
use ggez::conf::Conf;

fn main() {
    let mut conf = Conf::new();
    conf.window_mode = conf.window_mode
        .dimensions(1860.0/2.0, 1015.0)
        .resizable(true);
    conf.window_setup = conf.window_setup.title("Fluid Resistance");
    let (mut context, mut event_loop) = ContextBuilder::new("Fluid Resistance", "Brookzerker")
        .conf(conf)
        .build()
        .expect("Game context was not able to be created");
    let mut game = Game::new(&mut context);

    match event::run(&mut context, &mut event_loop, &mut game) {
        Ok(_) => println!("Exited cleanly"),
        Err(error) => println!("Error occured: {}", error),
    };
}

I think we can simplify this by creating a wrapper where we pass in what we need, and the library will take care of creating and running the game.

It could look something like

use fluid::*;

fn main() {
    match bbggez::run(Game, "Fluid Resistance", "Brookzerker") {
        Ok(_) => println!("Exited cleanly"),
        Err(error) => println!("Error occured: {}", error),
    };
}

What do we think about this?

We have random light colors for use on dark backgrounds. It would also be nice to have random dark colors for use on bright backgrounds

It would be nice to have a function that takes in the arena size and returns a random location inside the arena.

The tests fail sometimes because the color is not always > 0.7. We should switch to using 0.0 - 1.0 for generating the colors to ensure that we are in the same range.

To avoid merge conflicts, and make the code more organized, I've made up this file structure.

src folder

multiple_part_module/
  - module_part_1.rs
  - module_part_2.rs
tests/
  - module_1_test.rs
  - module_2_test.rs
  - ...
module_1.rs
module_2.rs
module_3.rs
main.rs

main.rs

extern crate random //Crates that won't get exported

pub extern crate ggez //Expose ggez so users can do custom things

pub mod module_1
pub mod module_2
pub mod module_3
mod private_module

The ecosystem project creates a triangle, that would be nice to have in the library.

The triangle should be equilateral in size.

We can re-export GGEZ as we are already using it in the library. That we if we don't need to worry about bringing in the wrong version when making a game, and we don't need to add anything else into the crates.toml file.

We want to easily create circles when writing GGEZ programs like

self.utility.create_circle(x, y, radius, color)

And then we would get a mesh back of the color

This will make it easier to test the code base visually before merging in and updating the library on crates.io.

I just ran the tests and received a failure. There's not a genuine issue because running the tests again were successful, but I think this should still be addressed.

Nicholass-MacBook-Pro:bbggez nbailey$ cargo test
   Compiling bbggez v0.5.0 (/Users/nbailey/git/bbggez)
    Finished dev [unoptimized + debuginfo] target(s) in 4.89s
     Running target/debug/deps/bbggez-02d635cba9813948

running 3 tests
test tests::generates_random_location ... ok
test tests::creates_a_random_color ... ok
test tests::creates_a_random_dark_color ... FAILED

failures:

---- tests::creates_a_random_dark_color stdout ----
thread 'tests::creates_a_random_dark_color' panicked at 'assertion failed: color.r + color.g + color.b !=
    another_color.r + another_color.g + another_color.b', src/lib.rs:163:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.


failures:
    tests::creates_a_random_dark_color

test result: FAILED. 2 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

Currently the tests creates_a_random_color, creates_a_random_dark_color, and generates_random_location can potentially fail at random due to the random nature of functions being defined.

Currently, creates_a_random_color and creates_a_random_dark_color have tests that create one random color after another and vaguely assert that they're not equal. Due to the random nature of the functions it's possible, but not probable, that they'll be the same.

assert!(color.r + color.g + color.b != another_color.r + another_color.g + another_color.b);

Making this strictly check if ther, g, and b values are the same would definitely increase the entropy, but I think it could still fail because there are no guarantees that the exact same color won't be generated twice in a row.

The generates_random_location follows suit by testing two generated locations

assert_ne!(first, second);

For the food in the ecosystem project that goes bad we are creating a strange kind of circle thing. This ends up looking like an asteroid or corrupted circle.

A mesh generator for this would be great.

We could use traits that get added to entity structures. Or they could be functions that get references to two entities and determine if they are clipping into each other. What do you all think?

It would be nice to be able to create meshes with a single command like

self.utility.create_rect(x, y, width, height, color)

We often use very similar structures each challenge. For example the Ball struct. We can probably create a entity structure that will allow us to skip manually creating this type of structure over and over again.

An example ball struct: fluid resistance Ball

What we would want on it

• base structure
• location
• velocity
• acceleration
• mass
• mesh

Functions

• new
• move
• apply force
• get speed

Currently the crates.io page doesn't have a link to the documentation. We should figure out how to generate the docs website and add a link.

We need to create a logo for the project so that we look good. Lets start a conversation on what one would look like

It would be nice to get the difference between the previous frame and the current frame. This is known as the delta time.

This number can be used to make the animations smooth and not dependent on hardware speed.

Set up a CI/CD platform for testing and deploying the library when merged into master

We use the rand crate a lot in our games. Let's export it the same way we did #12 so we don't need to add it to every cargo.toml file we create.

We don't have an example for creating a random location. Let's create a example file to show off how that function works.