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

Chunk reading API #7

Open
sathorn6 opened this issue Aug 27, 2014 · 6 comments
Open

Chunk reading API #7

sathorn6 opened this issue Aug 27, 2014 · 6 comments
Labels

Comments

@sathorn6
Copy link

I'm asking myself how the API to read chunks should look like.
From my current understanding, they consist of messages like

  • Entity X bought item Y on slot Z
  • Entity X gains Y gold
  • Entity X moves to x,y,z
  • Update Entity X's inventory to Y (Sent on selling something)

So to make sense of these, you need a lot of game state, like which player is X, where is he, how much gold and what items does he currently have, which i think the lib should keep for you. But how do we expose this information back in a useful way?

@strangeglyph
Copy link
Member

Sounds like an event-based system would be good here (function pointers yay)

@lukegb
Copy link
Contributor

lukegb commented Aug 27, 2014

  • Raw layer - just spits out individual events, one at a time, parsed?
  • Helper layer - allows you to seek to a time (somehow) and make queries about the state of play at that point - peoples inventories, etc. We manage all the state and handle jumping to a keyframe and applying all the events onwards.

@strangeglyph
Copy link
Member

Just raw layer sounds good, with the option to start the parse at a
certain point in time. The second option is basically a fully-featured
replay client, seems out of scope for libol

@lukegb
Copy link
Contributor

lukegb commented Aug 27, 2014

We should definitely have the former. The latter is something I'd like to have after the first is done - it's probably what most people will want, since being able to play forwards in time and see the state change without worrying about the underlying messages (which might change!) is useful.

@toulouse
Copy link
Member

+1 Emitting events
Parsing this in a stateful way can be the job of something wrapping libOL, or libOL can add it later, but it's definitely more advanced usage suitable for a later iteration.

@themasch
Copy link
Member

👍 for events. everyone loves events!

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

No branches or pull requests

5 participants