I'm not sure what simplifying assumptions I should make. So, unless you (Dan) object, I'll assume: Consistency: If A can ever beat B, A can always beat B. Transitivity: If A can beat B and B can beat C, then A can beat C. Ordering: No two players are equal in ability, and (equivalently, given consistency) there are no tie games. I'm not sure of the significance of "sessions," as contrasted with simply the total number of games. Given that "the schedule is to be decided in advance, independent of any tournament outcomes," the order in which they play, and whether any games are simultaneous, is irrelevant. Only which players play which other players matters. Unless I'm not understanding the problem correctly. For 8 players it would take 28 games for every player to play every other player, representing the unique complete graph with 8 vertices. With only 16 games (the number of games you specified) there are about 30 million possible labeled graphs. That's a small enough number that it's practical to simply try all of them (on a computer) and see which do best. I'll do so unless you tell me I'm misunderstanding the problem or unless someone comes up with a cleverer solution. I think it's unambiguous what "the maximum information about players' strengths" means, given my assumptions. For every pair of players, we want to know which one would win if they were to play each other. That's 28 bits. For every pair for which we can't deduce who would win, subtract 1 bit. Given transitivity, there's actually only log2(8!), about 15.3, bits. The difference from 28 is due to the fact that it's often possible to deduce whether A or B would win a game even if they never played each other. Specifically, this is possible iff there's a path on the *directed* (by who won that game) version of the versus graph that links them, in either direction. Since 15.3 is less than the 16 bits that 16 games provide, it's (barely) possible that there is a perfect solution. I agree that the versus graph should be in one piece, since if it wasn't, there would no way to rate anyone in one piece of the graph against anyone in any other piece. I think you want to maximize the average weighted number of paths between each pair of players. Weight a path by counting each path of length N as having weight 1/2^(N-1), to account for the odds that the N segments of the path won't all point the same way. This assumes that the directions are random and uncorrelated, which may be wrong, given transitivity, i.e. there can't be any loops in the directed graph. Given the lack of loops, the directed graph can always be drawn such that the arrows always point down, like water flowing in unpressurized pipes. Of course we won't be able to draw it that way until we know who won each game. Thoughts on programming: I plan to label each graph vertex with 1 through 16, those being the rankings of the players, and iterate over all 30421755 (28 choose 16) vertex-labeled directed graphs. Of course it would be cheating to choose the ones that get a perfect score, e.g. the ones in which player N plays player N+1 for N=1 through 7 and the other 9 games can be ignored. Instead, for each graph I'd take the average score over all 40320 (8!) graphs that are identical except that the labels are permuted and, equivalently, the directions are changed. For each relabeled (hence re-directed) graph I'd score it by raising its adjacency matrix to successive powers, 1 through 7 (7 being the longest possible path), and seeing if A,B or B,A is non-zero in any of these matrices. For each non-zero a,b pair, (A!=B) add a point, for a maximum score of 28. (Note that A,B and B,A can't both be non-zero unless I screw up somewhere.) (An adjacency matrix has a 1 at A,B iff there's an arrow from A to B, i.e. if player A beat player B in a game, and is 0 otherwise. The Nth power of this matrix is non-zero at A,B iff there's a path of length exactly N from A to B, e.g. for N = 3, if player A beat a player who beat a player who beat B.) I'm still trying to figure out how not to waste time testing equivalent (under relabeling) graphs. Not just because it would be slow and ugly, but because I don't want to see 40320 equivalent best solutions presented to me. Other than this, I have the whole program written (except for the typing part).