Levels are explicit inputs
Write each entry as name: level, for example Avery: 9. A level may be an agreed rating, handicap, or quiz score, but the browser cannot assess a player. The algorithm randomizes equal-level ties, processes the highest levels first, and puts each next player on a currently lowest-total, smallest team. The numeric inputs remain visible rather than becoming hidden organizer judgment.
Worked two-team allocation
Enter Avery 9, Blake 8, Casey 7, Dev 6, Emery 5, and Finley 4. One progression places Avery on Team 1 and Blake on Team 2; Casey joins Team 2 because 8 is lower than 9; Dev joins Team 1; Emery joins Team 1; Finley joins Team 2. The totals are Team 1: 9+6+5=20 and Team 2: 8+7+4=19.
It is a greedy method
The procedure balances a running sum and does not search every possible partition. Another arrangement may have a smaller final difference for unusual ratings. That trade-off makes the method quick and understandable for a casual roster. The output lists every team total so the claim is checkable. It does not promise equal ability, only a visible attempt to balance the entered numbers.
Use one meaningful scale
Do not add a self-rating out of 10 to a score out of 100. Bigger numbers must consistently mean stronger ability. Positions, accessibility, language, friendships, equipment, and previous pairings are not represented by one total. If a goalkeeper is required on each side or a learner needs support, state and handle that constraint before random team membership is accepted.
Where it helps
This tool suits pickup games, workshops, informal projects, and classroom groups where similar summed levels are useful. Confirm the ratings, run once, and show the totals. If an accommodation requires a later change, record it as a human decision. It is not suitable for hiring, grading, medical support, employment, or any allocation that changes rights or safety.
Difference from a plain split
A plain team splitter shuffles people and balances headcount only. This page uses numeric levels and random tie-breaking to pursue comparable sums. A duty schedule makes a sequence of dates, not simultaneous groups. The roster and ratings are processed locally in the browser; they are not uploaded or used to form a player profile.
Check the arithmetic after the draw
Read every player exactly once across the displayed teams. Then add each listed level independently and compare it with the reported total. In the six-player example, Team 1 contains 9, 6, and 5, which gives 20; Team 2 contains 8, 7, and 4, which gives 19. A one-point difference is understandable from the available values, whereas a result that silently dropped Finley would not be a valid allocation.
Headcount deserves a separate check. When the roster does not divide evenly by the requested team count, some teams must have one additional person. The implementation prefers a smallest team when totals tie, which prevents an avoidable pile-up early in the assignment. It cannot guarantee simultaneously equal headcount, exactly equal totals, and every social constraint for arbitrary inputs; those goals can conflict.
If the score spread is very large, test a few proposed policies before using a draw. One player rated 100 and all others rated 1 may dominate any simple sum. Splitting that person fairly may require role rules or a handicap, not a more elaborate shuffle. The right response to a bad representation is to improve the agreed inputs, rather than conceal the issue with repeated random runs.
For three or more teams, inspect the range between the largest and smallest totals as well as the average. The average is total entered levels divided by team count and may be fractional; no assignment can always give every team that exact number. The displayed member lists show whether a near-average total was achieved by an implausible team size, which is information a total alone cannot reveal.