I just committed (2a52dfb) and the diff is much bigger than I had expected. There seems to be something going on with line endings. Did they get converted from CRLF to LF? Or just the other way around? I cannot check this in a reliable way, since Git performs conversions automatically. @johnthagen could you help me with this?

It seems worthwhile to add some mechanism to disallow the player from shooting uninterruptedly, as it ruins the game (the best strategy seems to indefinitely shoot in circles). For instance, we could add a progress bar that shows the heating of the guns. Whenever the bar is full, the player cannot shoot for 3 seconds or something like that.

I've already got a prototype of this going, but I think the idea might work well:

• have a "powerup" spawn every n points/seconds (maybe every 500points/120sec?)
• powerups could be:
  • shooting powerups (shoot 3 bullets at once in different directions)
  • speed powerups (go faster, or make enemies slower)
  • shield powers (get an extra life for a limited amount of time)

Only question remains: How should they be rendered? I was thinking of a star-like structure that rotates in place and changes colour/size as time goes on.

Each time we draw an entity, Piston executes a draw call to the graphics card. This is incredibly expensive, but it can go unnoticed because the game does not have a big amount of entities. However, if we want others to learn from this project, it would be useful to use a backend that is able to scale. Fortunately, the graphics_tree backend seems to do exactly that, because it batches up the calls to draw and groups them together before sending them to the graphics card.

Building the project in debug works:
'''
cargo run
'''

Then I tried building it in release mode and got a crash:
'''
cargo run --release
Finished release [optimized] target(s) in 0.0 secs
Running target\release\rocket.exe
thread 'main' panicked at 'called Result::unwrap() on an Err value: "CreateWindowEx function failed: Invalid access to memory location. (os error 998)"', ../src/libcore\result.rs:799
note: Run with RUST_BACKTRACE=1 for a backtrace.
error: process didn't exit successfully: target\release\rocket.exe (exit code: 101)
'''

There have been some changes in the language around macros, to make them more ergonomic. I don't remember whether that is a nightly only thing or not, but it seems worthwhile to investigate whether we are doing things idiomatically. For instance, is #[macro_use] still necessary? Does the order in which modules are declared influence the availability of a macro for the other modules?

"A toy game in Rust, using Piston" <-- should say ggez.

If you keep pressing space and either left or right arrow, it's almost impossible to lose :3

As described on PistonDevelopers/piston_window#186 (comment)

Fresh install of rust, did not compile, it looks like a problem with a dependency (nalgebra-0.14.4)?

Compiling specs v0.14.3
error[E0502]: cannot borrow *self as immutable because it is also borrowed as mutable
--> C:\Users\44779.cargo\registry\src\github.com-1ecc6299db9ec823\nalgebra-0.14.4\src\core\cg.rs:292:44
|
292 | self[(j, i)] += shift[j] * self[(D::dim() - 1, i)];
| ---------------------------^^^^-------------------
| | |
| | immutable borrow occurs here
| mutable borrow occurs here
| mutable borrow later used here

error: aborting due to previous error

For more information about this error, try rustc --explain E0502.
error: could not compile nalgebra.
warning: build failed, waiting for other jobs to finish...
error: build failed

Note: this is all on a separate wasm branch.

Things that need to happen:

• Extract ggez business logic to its own crate (ggez_backend)
• Add wasm backend, with extern functions to drive execution of the game
• Figure out if we can come up with an abstraction layer for the view, so we can share more code
• Document every method in the root library

Instead of playing the sounds at the same time, it queues them. Therefore, the sound is played multiple times after the enemies are destroyed.

Hi again,

Any chance of updating wayland dependencies to work around this issue?

The version from Cargo.toml is affected whereas master seems to compile cleanly on ARM.

Hi there, I'm attempting to run cargo run --release and I'm running into 19 errors which are all similar to:

error: type `private::ffi::CGSRegionObject` is private
  --> /Users/<user>/.cargo/registry/src/github.com-1ecc6299db9ec823/core-graphics-0.3.2/src/private.rs:81:21
   |
81 |             assert!(ffi::CGSSetSurfaceShape(self.context_id,
   |

I'm running rustc 1.22.1 and I'm on macOS 10.12.6. Any idea what could be causing this issue?

Right now, when we want to trigger an event regularly, we manually check whether enough time has elapsed. I am not convinced by this approach, as it leads to some code repetition (we use the same pattern in many places). See below for an example:

if !state.world.player.is_dead
   && self.current_time - self.last_tail_particle > TRAIL_PARTICLE_RATE {
    self.last_tail_particle = self.current_time;
    state.world.particles.push(Particle::new(state.world.player.vector.clone().invert(), 0.5));
}

I am toying with a design to change this, so we don't need to reimplement the timer logic every time. The example below already works in one of my branches, though I wonder whether it is worth it. Maybe the introduced complexity outweights the DRY improvement.

// Init the timer in the constructor of the TimeController
tail_particle_timer: Timer::new(TRAIL_PARTICLE_RATE)

// ...

// Use it in the update function
if !state.world.player.is_dead {
    self.tail_particle_timer.update(self.current_time, || {
        state.world.particles.push(Particle::new(state.world.player.vector.clone().invert(),
                                                 0.5));
    });
}

@acheronfail what do you think?

MVC:

• Introduce view (#62)
• Introduce controllers

Cleanup:

• Use optimized version of Vec::retain
• Split the drawing module in two: Point and Size should go to a geometry module, while color should remain in drawing.
• Rename the traits module to physics or move its contents into the geometry module.
• Run clippy (and maybe rustfmt) on the codebase

Well, I was curious, tried to build it.

Here's what I got:

   Compiling pistoncore-event v0.3.0
   Compiling piston v0.3.0
   Compiling piston2d-opengl_graphics v0.4.0
   Compiling pistoncore-glutin_window v0.4.0
     Running `target/release/rocket`
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: OsError("glx::ChooseFBConfig failed")', src/libcore/result.rs:731
An unknown error occurred

To learn more, run the command again with --verbose.

No idea if it's in your code or somewhere in Rust, just thought you might like to have a look. I've just started learning Rust, so can't make much sense of anything here :P

Right now, we use the derive_position_direction! macro to derive the Position and Direction traits. This is from a time when you were not able to write derive implementations for you own traits... But now you can. This means we could use #[derive(Position, Direction)], which is "the proper way" to do it.

There is a chance that such a change would introduce lots of complexity... In that case we should keep the current macro.

Since ggez uses f32 when drawing, it seems sensible to move our geometry to f32 as well. We don't need f64 precision.

As a consequence of this change, we could remove 25 as f32 occurrences in view.rs, so itseems worthwhile.

It seems that this is caused by an outdated version of opengl being used by AppVeyor (see this).

On Windows, game::Game::new() panics if Rocket was called from anywhere but the project's root directory, because it looks for "resources/FiraMono-Bold.ttf" relative to the working directory Rocket was called from, not relative to Rocket nor the project root.

(I'm not sure if you're accepting issues or pull requests or anything. I just thought you ought to know.)

I tried to add sound effects when we were using Piston, but didn't manage to get it working. It seems that ggez supports this out of the box, so it would be interesting to give this another go.

cc @acheronfail

@aochagavia if you enable a Travis CI build for this project, I'd be happy to contribute a .travis.yml that builds the project.

This will be quite a bit simpler if we remove the SDL2 dependancy. Done.

You should be able to enable it here: https://travis-ci.org/aochagavia

Hi
I have a problem while launching your game (wow, such stack trace !) :

     Running `target/release/rocket`
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: OsError("glx::ChooseFBConfig failed")', /build/rust/src/rustc-1.1.0/src/libcore/result.rs:729
Process didn't exit successfully: `target/release/rocket` (exit code: 101)

glxinfo : http://0bin.net/paste/HKQrvHowf258NjzW#toozRH4d1ONFtB3NvxszDY5D6-CsdHkSgrMQktr1us3
graphic card : intel HD3000

I am getting the error below while trying to run, i.e. cargo run --release

Running target/release/rocket
[glutin] x error code=42 major=0 minor=0!
thread '

' panicked at 'called Result::unwrap() on an Err value: OsError("GL context creation failed")', /home/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/result.rs:729
An unknown error occurred

Is there any lib that I am missing? I am using stable rust.

See this comment: PistonDevelopers/piston_window#186 (comment)

I think having a short doc comment for game::{UPS, BULLET_RATE} would help new readers better understand the update process.

New versions of piston / piston_window do not require freetype as a dependency and instead use a pure rust alternative rusttype. This makes it easier to run by removing a dependency.

I tried to update the dependencies of rocket and get it to run, but was unsuccessful so far. See #19