If or How to use references and lifetimes

Question

I am experimenting rust by implementing a simple game, and quickly ran into a situation where I find it is hard to decide what is a better approach and I think it is related to a broader question about references and lifetimes in Rust, hopefully, someone has better experience on this.

Assuming I have a Game that represents the game world, and GameObject is the trait for all item in the game. And a GameState to keep track of object collisions for every update, Collision will need to hold reference to other GameObject in order to tell which ones collide, in order to do that I will need to add a lifetime to the Collision then add lifetimes to GameState and then add to Game if I want the Game object to hold the state, Or I can maybe copy the GameState for every update tick.

trait GameObject {
   fn draw(&self, renderer: &Renderer);
   fn update(&mut self, state: &GameState, delta: f64);
}

struct Collision<'a> {
   obj1: &'a Box<dyn GameObject>,
   obj2: &'a Box<dyn GameObject>
}

struct GameState<'a> {
   // other states...
   collisions: Vec<Collision<'a>>,
}

struct Game {
   items: Box<dyn GameObject>,
}

impl Game {
   fn draw(&self, renderer: &Renderer){
      for item in &self.items {
         item.draw(render);
      }
   }
   fn update(&mut self, delta: f64){
      // create a state everytime? or hold a reference to it?
      for item in &self.items {
         item.update(delta);
      }
   }
}

So that's where I am 100% sure what would be the best approach, or in general, once we give a lifetime to an object, then any other object holds this object will need lifetime types, not maybe we should reorganize the code structure to avoid lifetimes? Thanks.

It's worth seeing how [Bevy](https://bevyengine.org) handles this. — tadman, Jan 27 '23 at 17:40
Nitpick: `&Box` is a bad idea. Use `&'a dyn GameObject` instead. — Chayim Friedman, Jan 28 '23 at 18:38
@ChayimFriedman can u elaborate why &Box is a bad idea? Is that stack vs heap thing or is reference to a box has other issue? Thanks. — Jing is coding, Jan 29 '23 at 21:59
[Why is it discouraged to accept a reference to a String (&String), Vec (&Vec), or Box (&Box) as a function argument?](https://stackoverflow.com/questions/40006219/why-is-it-discouraged-to-accept-a-reference-to-a-string-string-vec-vec-o) — Chayim Friedman, Jan 30 '23 at 03:49

score 2 · Answer 1 · answered Jan 27 '23 at 19:42

My advice would be to use lifetimes inside temporary structs but avoid them for structs you want to keep around. So if you create a GameState for every frame, add to it, use it and destroy it, that's ok. But if you want to keep it alive for many frames, then those references will be a problem, because you will be keeping your objects borrowed all the time.

If you have complex references between your objects, there are several solutions that do not require lifetimes and persistent borrows:

Use Rc<dyn GameObject> instead of Box and store Weak versions of the pointer everywhere except in the main container.
Store the objects in a SlotMap and use a key to refer to the objects.
Store the objects in a Vec and use the index to refer to the objects. It is just like the SlotMap but simpler. Still useful for simpler cases such as if your objects are just created once and then never added or removed.
Use an Entity-Component-System (ECS) library, such as Bevy suggested by @tadman in the comment above.

Just realize could not use Rc for GameObject, since it will require mutability in update function. so will probably have to use Rc> — Jing is coding, Feb 03 '23 at 20:25

If or How to use references and lifetimes

1 Answers1