Skip to content

State based gameplay recording #18

Description

@idoleat

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions