Author Topic: Sessions vs. Database for short-lived data  (Read 1278 times)

Offline Sinzygy

  • Level 28
  • **
  • Posts: 420
  • Reputation: +11/-0
    • View Profile
Sessions vs. Database for short-lived data
« on: May 14, 2007, 06:19:16 AM »
Which one is better for storing fast-living data? Sessions or a database?

Example: picture KoL and their battle system: You hit once, the monster hits once. Then you get to chose again what you want to do (attack again, use item, flee).
Now, which one is a better way to store the monster you're currently fighting and it's current hp?

Offline Zeggy

  • Global Moderator
  • Level 35
  • *****
  • Posts: 1,187
  • Reputation: +13/-4
    • View Profile
Re: Sessions vs. Database for short-lived data
« Reply #1 on: May 14, 2007, 02:08:16 PM »
Well, sessions are not as secure as databases, so they could be manipulated for cheating in the game.
I would say, go for databases :)

That way you could also resume battles if a player leaves and comes back the next day.

Offline Sinzygy

  • Level 28
  • **
  • Posts: 420
  • Reputation: +11/-0
    • View Profile
Re: Sessions vs. Database for short-lived data
« Reply #2 on: May 14, 2007, 02:33:27 PM »
Yeah, those were my thoughts as well.

well, I guess I'll go with the database-way then.

Offline beam

  • Level 15
  • *
  • Posts: 132
  • Reputation: +2/-0
  • Dance Commander
    • View Profile
Re: Sessions vs. Database for short-lived data
« Reply #3 on: May 15, 2007, 02:58:24 AM »
Yeah, definitely stored in database. That way, if a player accidentally closed the browser window or something, they could pick up the battle where it left off.

Offline Sinzygy

  • Level 28
  • **
  • Posts: 420
  • Reputation: +11/-0
    • View Profile
Re: Sessions vs. Database for short-lived data
« Reply #4 on: May 15, 2007, 04:51:28 AM »
heh, I just had a nice idea:

I'ma go store the data of the monster in a seperate table and make it so that every player (or the players from the same guild) can attack it simultaniously.
This way there will be some slight Co-op fell... or at least that's what I hope it will accomplish

Offline Zeggy

  • Global Moderator
  • Level 35
  • *****
  • Posts: 1,187
  • Reputation: +13/-4
    • View Profile
Re: Sessions vs. Database for short-lived data
« Reply #5 on: May 15, 2007, 05:59:55 AM »
Eh? How would that work?
I had a similar idea, but only for boss monsters that would actually require many players to attempt to kill it, and there would be a limited amount of those monsters.

Offline Sinzygy

  • Level 28
  • **
  • Posts: 420
  • Reputation: +11/-0
    • View Profile
Re: Sessions vs. Database for short-lived data
« Reply #6 on: May 15, 2007, 07:08:28 AM »
I would store the unit  and the battle-location in a seperate table.
this table would also include fields for when the monster was first attacked, by which player and by which guild.
Now every player of tht guild that visits the same location get's a to chose to either find and attack a new monster or attack an already found monster.
But the monster will only be fightable 5 minutes (or so) from the last attack. So the guild would have to work together and plan it accordingly to actually kill it.
And when the monster is killed everyone that fought it will gain some xp, in relation of how often he fought the monster. (So a player that attacks 3 times and a player that only attacks once will get 3/4 and 1/4 of the total experience)

And yes, this will probably only be done for boss monsters, quest related monster or really, really strong monster.

Offline Shapulin

  • Level 9
  • *
  • Posts: 50
  • Reputation: +2/-4
    • View Profile
Re: Sessions vs. Database for short-lived data
« Reply #7 on: May 15, 2007, 09:43:05 AM »
but thats is easy if you design the database with inheritance.... and create a instance of the moster type in relation with the player and the time of creation for each battle....

so the instance is not longer living i they time creation is more than X or if they last attack time is more than X or something like that


 


SimplePortal 2.3.3 © 2008-2010, SimplePortal