Individual player page makeover

[GoogleCodeExporter]

Hi, originally posted this on stuntyleeg.com forum. Reposted here as per 
requested.

One more thing to add, I suggested this mainly with tabletop, i.e. non-botocs, 
non-cyanide, use in mind.

--
Hi, I was talking about this yesterday in chat, and now I will try to flesh it 
out better.

Stumbled upon a blood bowl league page with some nice features. I don't 
remember the address, but if needed, I can look it up when I'm home again.

I was thinking about doing this myself, but I'm having some scheduling issues, 
like everyone, so I'm putting all this information up for someone better 
acquainted with OBBLM's php generation and database structure to do the dirty 
work.

The motivation:
I like to get a sense of history to a player, not just how he is now but how he 
got there.

The idea:
On an individual player's page, as a replacement to "Achievements" and "Match 
best" there would be a table for the player's total match history. Headers 
would be match number, opponent, cp, td, int, cas, mvp, inj, new skill, other 
notes.

The instructions:

The breakdown of each:

match number - a running number starting from the first match this player 
played in.

opponent< - the name and link to the team that the match was played against

cp, td, int, cas, mvp - completions, touchdowns, interceptions, casualties and 
mvps awarder for the player in the match

inj - injury, if any, received

new skill - if a skill/stat was gained as a result of the match, it is recorded 
here

other notes - this could include the information that is now recorded in 'match 
best' like 'top scorer' and 'most casualties'

As said earlier, I don't know the details of how OBBLM works, but all the 
information is already basically available:

- match reports record all SPP-activities and injuries
- SPP can be cumulatively added up and checked if a skill threshold has been 
passed.
- skills are already listed on the roster in the order they have been chosen

So the algorithm goes something like this:

1. get match data for next match
2. record match number, opponent, cp, td, int, cas, mvp and injuries
3. add up SPP and compare to the amount before the match. If a star player roll 
was done, get next evailable skill from the player's skills
4. get information for other notes from the current 'match best'-routines and 
generate text if necessary
5. match=match+1 and go to 1 (or +2, if player got MNG)

I hope I did not forget or overlook something important. If someone has the 
time, I'd appreciate, if this was implemented. It is still a bit of work, but 
this should help getting started.

Also, if you have any opinion on if stuff like this is needed, feel free to 
comment.
--

Original issue reported on code.google.com by oxy...@gmail.com on 9 Jun 2010 at 11:56

[GoogleCodeExporter]

What does everybody think about this?

Original comment by Nimda...@gmail.com on 10 Jun 2010 at 10:41

[GoogleCodeExporter]

I'd love to see Player Logs and the sort.  Then again, I'm still hoping we can 
figure out how to parse the Cyanide logs to get more stats from PCBB =(

Original comment by micah.im...@gmail.com on 11 Jun 2010 at 5:48

[GoogleCodeExporter]

I think this type of stuff is good and easy to do as mentioned in the forum

As part of the botocs work i have been doing to allow report regeneration will 
introduce 2 new tables to record rosters and skills of the players in each team 
per match. (Botocs wise it reads the home and visitor xml) but for table top 
can just update the tables as the match reports are added). The algorithm might 
work but only because of skills coming out in the order it was added but that 
could easily get upset (would it work with attribute increases for example). It 
could be used on an initial data gathering but i think actually recording the 
data would be best.

e.g.

CREATE TABLE `match_players_skills`
(
  `f_player_id` mediumint(9) NOT NULL,
  `f_match_id` mediumint(9) NOT NULL,
  `f_skill_id` smallint(6) NOT NULL,
    PRIMARY KEY (`f_player_id`, `f_match_id`, `f_skill_id`),
    FOREIGN KEY (`f_player_id`) REFERENCES players (player_id),
    FOREIGN KEY (`f_player_id`, `f_match_id`) REFERENCES `match_players` (`f_player_id`, `f_match_id`),
    FOREIGN KEY (`f_skill_id`) REFERENCES game_data_skills (skill_id)
);

CREATE TABLE `match_players`
(
  `f_player_id` mediumint(9) NOT NULL,
  `f_match_id` mediumint(9) NOT NULL,
  `name` varchar(60) DEFAULT NULL,
  `value` mediumint(9) DEFAULT NULL,
  `type` tinyint(4) DEFAULT NULL,
  `nr` tinyint(4) DEFAULT NULL,
  `ma` tinyint(4) DEFAULT NULL,
  `st` tinyint(4) DEFAULT NULL,
  `ag` tinyint(4) DEFAULT NULL,
  `av` tinyint(4) DEFAULT NULL,
  `inj_ni` tinyint(4) DEFAULT NULL,
   PRIMARY KEY (`f_player_id`, `f_match_id`),
   FOREIGN KEY (`f_player_id`) REFERENCES players(player_id)

);

In OBBLM we have loads of data we dont have good pages to display it all yet. I 
really think we should open a debate on look and feel of a series of pages from 
the team page to the stats display to the fancier things we can do like this. I 
am happy to do any database work or provide any of the necessary views. OBBLM 
has more info in the backend then just about any of the other league managers 
but unfortunately people find the data hard to access.

Original comment by necrosis...@googlemail.com on 12 Jun 2010 at 7:00

[GoogleCodeExporter]

necrosis, that kind of data (alsomost in the same format) is already in the DB 
tables - why not just use them?

I would suggest, if anyone can, to write this at as a module at first, then, 
later, when it has been testet thorougly, we can replace it with the current 
players page.

Original comment by Nimda...@gmail.com on 12 Jun 2010 at 8:35

[GoogleCodeExporter]

Well the way i read the database we have 
match data
match data extra stats
player data
player skills data

We don't have roster/attributes/skills of each player as they were at each 
game. That is why we have issues with regenerating botocs reports because the 
link can be lost between player number and the number in the botocs report.

You could put some of the data into an extended match data table but you still 
need the skills separate.

Original comment by necrosis...@googlemail.com on 12 Jun 2010 at 12:50

[GoogleCodeExporter]

Original comment by Nimda...@gmail.com on 19 Jun 2010 at 10:16

• Added labels: Milestone-Unknown, OBBLM_module, Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

After looking at the matter, I came to this conclusion on the current state of 
affairs:

1. Assuming there are no stat increases you can backtrack when skills were 
taken (with f_player_id and the match data and achieved skills attached to that 
id). You have to make the assumption that you get the results from 
player_skills table in a chronological order now and in the future though.

2. If there are any stat increases it messes the whole thing up since they're 
on a different table than the skills. Also you can not identify which stat 
increase came first if there are multiple.

The above mentioned tables would fix the issues though.

Original comment by oxy...@gmail.com on 21 Sep 2010 at 8:16

[GoogleCodeExporter]

Addendum the my previous comment:

So add the tables already, so I or someone can implement this.

This kind of historical information of the player and the team is important. We 
can already access the old match results and we can see each team's lineups for 
those matches, but not the players skills back then.

For individual players it'd be easier to observe if any particular advance 
significantly accelerated the player's SPP generation.

All in all the system feels a bit rootless in its current state as the only 
information comfortably accessible is the current situation.

Original comment by oxy...@gmail.com on 21 Sep 2010 at 9:07

[GoogleCodeExporter]

Original comment by Nimda...@gmail.com on 19 Oct 2010 at 6:51

• Changed title: Individual player page makeover
• Changed state: Postponed

[GoogleCodeExporter]

When you start on this you may re-open the issue. Closing it for now to tidy up 
a little.

Original comment by Nimda...@gmail.com on 20 Oct 2010 at 1:15

• Changed state: WontFix