but we store each round, because we need player actions for further analysis about game trends
returnstrikeHP is a random number in range, that is calculated when a player strikes back. although as you write,
we can calculate the difference between rows, but that may increase the number of selects.
> Date: Fri, 19 Oct 2012 13:54:02 +0200
> From: foo@meisterderspiele.de
> To: arvindps@hotmail.com
> Subject: Re: Improve MMO Game Performance
>
> Hello Arvind,
>
> i worked on MMO (and especially their performance) some time ago. I
> really like(d) them. :)
>
> > we are all aware of the popular trend of MMO games. where players face
>
> > To understand my query, please consider the following scenario
> > /we store game progress in a postgres table./
> > A tournament starts with four players and following activity
> >
> > 1. Each player starts with 100hitpoints
> > 2. player 1 makes a strike (we refer to a chart to convert blows to
> > hitpoints with random-range %)
> > 3. player 2 has 92HP, and returns a light blow, so player1 has 98hp
>
> That is a very simple description or a very simple system.
>
> > The above two round will now be in Game Progress Table, as
> >
> > |ROWPlayer1HP Player2HP Strikefrom StrikeTo ReturnStrikeHP Round TimeStamp StrikeMethod
> > 1 100 100 0 0 0 0
> > 2 98 92 P1 P22 1
> > |
>
> At this point you should reconsider if you need this much data. It is
> faster to store less data.
>
> For example you do not need the colum "ReturnStrikeHP". You can
> calculate the damage from the difference between the rows.
>
> If there is a cyclic change of the attacker (P1->P2->P1->P2->P1->P2 ...)
> you just need to store the starting player and could drop the "strik
> from" and "strike to" column.
> If you need it and there are just 2 players in one fight, reduce the
> column to "attacker" and store if it is player one or two. The one which
> is not in the column is the defender.
>
> Also why do you store each round? Most time there are just reports,
> charts or animations about the fight. You can generate them in a more
> compact form and just store 1 row with this information. In this way you
> will reduce the number of needed INSERT-operations a lot. And you will
> speed-up the SELECT because less data must be read.
>
> I hope this will help you. Greetings from Germany,
> Torsten
