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

State based gameplay recording #18

Open
idoleat opened this issue Jan 29, 2024 · 0 comments
Open

State based gameplay recording #18

idoleat opened this issue Jan 29, 2024 · 0 comments

Comments

@idoleat
Copy link

idoleat commented Jan 29, 2024

I have some thoughts on recording gameplay. For wider usage, recording game states could be an option. Here are several reasons

  • Gameplay can be replayed from any states, backward and forward. By using move sequence to reach certain state in the gameplay, moves need to be aggregated from start. Viewing gameplays in Counter Strike: Global Offensive suffers from long delay when jumping between rounds, which is caused by replaying from start everytime on jumping. In our case, the gameplay of m, n, k game could be long if k is large enough.
  • In case errors can happen while recording, faults only remain in some states rather than whole gameplay, comparing to using moves.
  • A disadvantages is that it may take more spaces to store, comparing to 4 bytes at most per move.

Some ideas on designing encoding: Since later states contain earlier states, we may have the code partial ordered. This may make states search-able. Puffer code for encoding a tree is designed to proved the count of all possible trees. This can be a reference. Or just compress the raw array data by using compression algorithms like LZ4, which kernel has already provided. Perfect hash functions may be considered if the count of possible game states is not too large.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant