Thread: (Why you should implement) Event based saves

Page 1 of 2 12 LastLast
Results 1 to 10 of 11
  1. #1 (Why you should implement) Event based saves 
    Registered Member
    Join Date
    Jul 2012
    Age
    25
    Posts
    122
    Thanks given
    16
    Thanks received
    21
    Rep Power
    15
    Currently, all servers (that I know off) handles a Player-save as the following:

    A player is its' current status. A player is its' items, coins, armour, etcetera. Which is true.

    Let me present to you an alternative:

    A player is the sum of all of its' actions.

    This is event based saves.

    Why is event based saves good?


    Using time-stamps every player is always backed up at every state of time (might want to run another backup on a separate storage though).

    If a dupe is noticed it is easy to determine who is abusing it - and also how it is abused.

    Adventurer's log is now a lot easier to implement.

    You only need to save the actions done since last game interaction.

    Once a player is logged out (saved) a currentState can be generated for that player (which would act like the traditional save files).

    Why would traditional saves be better?

    It doesn't use as much space.

    It is already implemented.


    I will attempt to implement this myself as soon as I have time for it. I just wanted to share this thought with everyone and hear some eventual feedback. Am I missing something?
    Reply With Quote  
     

  2. #2  
    Registered Member

    Join Date
    Dec 2015
    Posts
    166
    Thanks given
    77
    Thanks received
    87
    Rep Power
    404
    this is called event sourcing and is quite difficult to engineer yourself the proper way. you'd be better off using Akka Persistence but the problem here is that this doesn't fit in your average server and actually forces you, to redesign your entire system to make fully use of that e.g turn every Player instance into an actor

    Quote Originally Posted by Sarkastisk View Post
    It doesn't use as much space.
    not true. storing every event will definitely use more disk space

    Quote Originally Posted by Sarkastisk View Post
    It is already implemented.
    yeah sure you have your little client to server message pojo's but what you'd actually want is every tiny game event that happens (add item to inventory, remove item from inventory, take one step, subtract 10 from bank)
    "It's all a matter of perspective. There is no single path in life that is right and fair and does no harm."
    Reply With Quote  
     

  3. #3  
    Registered Member
    Join Date
    Jul 2012
    Age
    25
    Posts
    122
    Thanks given
    16
    Thanks received
    21
    Rep Power
    15
    Quote Originally Posted by Whis View Post

    not true. storing every event will definitely use more disk space



    yeah sure you have your little client to server message pojo's but what you'd actually want is every tiny game event that happens (add item to inventory, remove item from inventory, take one step, subtract 10 from bank)
    What you're replying to is about traditional saving, i.e, the saving that is currently being used in servers.

    Quote Originally Posted by Whis View Post
    this is called event sourcing and is quite difficult to engineer yourself the proper way.
    [*] Each event has a unique eventID[*] Each event changes one thing

    Create an event interface with the function "log" and "execute".
    Call the function log everytime something happens.

    Save events as:
    eventID : parameters : repeats

    The parameters could be location (walkevents), item ids (drop/pickup/bank/withdraw events), skill ids and experience. It's not that much things that actually happens in the server that requires saving - and implementation is not complicated, only it takes a lot of time.
    Reply With Quote  
     

  4. #4  
    Registered Member

    Join Date
    Dec 2015
    Posts
    166
    Thanks given
    77
    Thanks received
    87
    Rep Power
    404
    Quote Originally Posted by Sarkastisk View Post
    What you're replying to is about traditional saving, i.e, the saving that is currently being used in servers.
    yes thank you i couldnt of figured that out myself from your very first sentence

    Quote Originally Posted by Sarkastisk View Post
    [*] Each event has a unique eventID[*] Each event changes one thing

    Create an event interface with the function "log" and "execute".
    Call the function log everytime something happens.

    Save events as:
    eventID : parameters : repeats

    The parameters could be location (walkevents), item ids (drop/pickup/bank/withdraw events), skill ids and experience. It's not that much things that actually happens in the server that requires saving - and implementation is not complicated, only it takes a lot of time.
    lol yeah ok this is a waste of time
    "It's all a matter of perspective. There is no single path in life that is right and fair and does no harm."
    Reply With Quote  
     

  5. #5  
    Registered Member

    Join Date
    Dec 2012
    Posts
    2,999
    Thanks given
    894
    Thanks received
    921
    Rep Power
    2555
    would take far 2 long with little advantages, along with you needing to write a shitload of code since every action needs to be defined as a pojo. and also are you suggesting that the events should be 'flattened' on logout into a player state (so event history is only during the session, not persistent) ? if so doesn't this remove the entire point of this design, which is to be able to apply events onto a default state?
    Attached image
    Reply With Quote  
     

  6. #6  
    Registered Member
    Join Date
    Jul 2012
    Age
    25
    Posts
    122
    Thanks given
    16
    Thanks received
    21
    Rep Power
    15
    Quote Originally Posted by Whis View Post
    yes thank you i couldnt of figured that out myself from your very first sentence
    You missed it the first time. Don't be a dick.

    Quote Originally Posted by Kaleem View Post
    would take far 2 long with little advantages, along with you needing to write a shitload of code since every action needs to be defined as a pojo. and also are you suggesting that the events should be 'flattened' on logout into a player state (so event history is only during the session, not persistent) ? if so doesn't this remove the entire point of this design, which is to be able to apply events onto a default state?
    Recoding it into a current source would definentely take a lot of time, but it would create a stability that regular saves do not.

    It doesn't remove the entire point of the design. Using both lets the event sourcing be a source of time based backups, while the default state is used for stable logins. It takes a lot more time to go through all states a characters have visited (growing over time).
    Reply With Quote  
     

  7. #7  
    (Why you should implement) Event based saves



    Scu11's Avatar
    Join Date
    Aug 2007
    Age
    30
    Posts
    16,307
    Thanks given
    7,215
    Thanks received
    12,308
    Rep Power
    5000

    Attached image
    Reply With Quote  
     

  8. Thankful users:


  9. #8  
    kierandevvs
    Guest
    Quote Originally Posted by Sarkastisk View Post
    Currently, all servers (that I know off) handles a Player-save as the following:

    A player is its' current status. A player is its' items, coins, armour, etcetera. Which is true.

    Let me present to you an alternative:

    A player is the sum of all of its' actions.

    This is event based saves.

    Why is event based saves good?


    Using time-stamps every player is always backed up at every state of time (might want to run another backup on a separate storage though).

    If a dupe is noticed it is easy to determine who is abusing it - and also how it is abused.

    Adventurer's log is now a lot easier to implement.

    You only need to save the actions done since last game interaction.

    Once a player is logged out (saved) a currentState can be generated for that player (which would act like the traditional save files).

    Why would traditional saves be better?

    It doesn't use as much space.

    It is already implemented.


    I will attempt to implement this myself as soon as I have time for it. I just wanted to share this thought with everyone and hear some eventual feedback. Am I missing something?
    Sever architecture and hardware already solves this problem.
    Your proposal defeats hardware logic 101, RAM is faster to write to than persistant storage is.
    Off load your work asynchronously and persist the users state to disk when the user isnt using the service. (AKA how saving already works.)

    At an enterprise level you would use UPS's and dedicated RAID cards with internal batteries so make sure your memory / IO transfers can succeed.
    As for an unexpected software failure, implement better error handling.
    Also adopt a database storage solution as they provide much better disaster recovery and help mitigate data loss.
    Reply With Quote  
     

  10. #9  
    Registered Member
    hc747's Avatar
    Join Date
    Dec 2013
    Age
    26
    Posts
    1,474
    Thanks given
    3,312
    Thanks received
    691
    Rep Power
    1098
    Quote Originally Posted by Whis View Post
    yes thank you i couldnt of figured that out myself from your very first sentence



    lol yeah ok this is a waste of time
    You clearly did miss the point, lol.

    OT: This is a good concept, but what if a change is made down the line that is not backwards compatible? For instance, what would happen if replaying movement events that were previously fine lead to the player being located in an invalid area (i.e, a wall etc).
    Reply With Quote  
     

  11. #10  
    Registered Member
    Join Date
    Jul 2012
    Age
    25
    Posts
    122
    Thanks given
    16
    Thanks received
    21
    Rep Power
    15
    Quote Originally Posted by hc747 View Post
    You clearly did miss the point, lol.

    OT: This is a good concept, but what if a change is made down the line that is not backwards compatible? For instance, what would happen if replaying movement events that were previously fine lead to the player being located in an invalid area (i.e, a wall etc).
    If we can trust that the pathing worked at the last walk, perhaps it can be accepted as a fact that the last location of the player is indeed the last location of the player (the last successful walk). As the final path always reaches a specific destination.
    Also in most scenarios the pathing can be at least counted as the location from the last teleport.
    But there should absolutely be a portion of fail-safes for these kind of scenarios.
    Reply With Quote  
     

Page 1 of 2 12 LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Similar Threads

  1. Why you should not buy rares.
    By Shawn Patel in forum Old School RS (2007)
    Replies: 3
    Last Post: 07-13-2013, 01:48 PM
  2. Replies: 31
    Last Post: 11-11-2011, 05:45 AM
  3. Why you should bot on RuneScape - my poem
    By Grey in forum Literature & Language Arts
    Replies: 5
    Last Post: 03-01-2010, 07:45 PM
  4. Getters & Setters - Why you should use them
    By PSNB in forum Tutorials
    Replies: 11
    Last Post: 12-15-2009, 01:51 PM
  5. Why you should use events
    By Chachi in forum RS2 Server
    Replies: 11
    Last Post: 07-09-2009, 05:29 PM
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •