Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time #28

Open
nic-hartley opened this issue Jan 17, 2023 · 2 comments
Open

Time #28

nic-hartley opened this issue Jan 17, 2023 · 2 comments
Labels
k: new system a whole new system to integrate into the engine p: tuig tuig crate
Milestone

Comments

@nic-hartley
Copy link
Owner

I need a way to simulate in-game time passing that can be paused, serialized, deserialized, etc. Maybe u64 milliseconds since the start of the save file? I don't need to be particularly precise about this, and I don't need to handle any of the weird edge cases that come with real-world time. Mostly I need to make sure it's readable by everyone across the whole game while still being easily adjusted, but that's easy enough with AtomicU64. (We'll see if my embedded dreams make that problematic.)

@nic-hartley nic-hartley added this to the v0.1 milestone Mar 23, 2023
@nic-hartley nic-hartley added p: tuig tuig crate k: new system a whole new system to integrate into the engine labels Mar 29, 2023
@nic-hartley
Copy link
Owner Author

I'm wondering now if it might be easier to file this under a more general "centrally updated global state" thing, with the various "game time" things (realtime or round-based) being premade chunks offered (maybe integrated?) by the engine. There's other global state I'll want to be able to pass around so it makes sense to build that in together, and let the game decide what's there.

@nic-hartley
Copy link
Owner Author

Idea for generic global state:

  • Add a type State: Send + Sync to trait Game
  • Expect Game to maintain its State at all times
  • Add Game::state() -> State to get the current state (owned value)
  • Every so often, the Game is polled for the current state
  • Arc<State> is passed around to the various threads
  • Threads pass the respective &State to agents in the normal functions

State is expected (guaranteed?) to be updated every round (do I want to formalize rounds?)

Should have absolutely no issues with lifetimes, and also be possible to make nostd-friendly

Not sure how Cell should be involved, if at all. Maybe in some behind-the-scenes machinery, i.e. using an Arc<Cell<State>> or something instead of a channel to pass the new states around?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
k: new system a whole new system to integrate into the engine p: tuig tuig crate
Projects
None yet
Development

No branches or pull requests

1 participant