UGTK / Toolkit / Algorithms Module / ReorderSystem Completed

Reorder System

Summary

The Reorder System sorts a list by a single integer criterion, without writing a comparer every time. Implement IComparableObject — one property, CompareValue — and the list gains three sorting extension methods plus a set of readable comparison helpers.

It is meant for the everyday game case: a leaderboard ordered by score, an inventory ordered by rarity, a turn queue ordered by initiative. If you need to sort by several criteria at once, or by a string, List<T>.Sort with a comparer is the right tool instead.

Content

• Modules Dependencies
• Setup
• How To Use
• Which Algorithm
• Testing Scene
• Technical Info

Modules Dependencies

None. An interface and a static class of extension methods, no UGTK reference.

Setup

No component and no prefab, so there is no GIF. Implement the interface on whatever you want to sort:

public class Player : IComparableObject
{
    public int CompareValue { get; set; }   // the score, the initiative, the rarity...
}

CompareValue is settable on purpose: recompute it when the underlying data changes, then sort again.

How To Use

List<Player> players = ...;

players.InsertionSort();
players.SelectionSort();
players.BubbleSort();
players.MergeSort();

All four sort ascending by CompareValue. Reverse the list afterwards for a descending leaderboard.

The comparison helpers read better than comparing the field by hand:

if (a.LessThan(b)) { ... }
if (a.GreaterThanOrEqual(b)) { ... }

Good to know:

• Use HasSameValue, not Equals, to compare two elements. a.Equals(b) would resolve to object.Equals and compare references: an instance method always beats an extension method. The extension is therefore named a.HasSameValue(b). (Until 2026-07-30 it was called Equals and was simply unreachable.)
• The sorts are in place: the list you pass is modified and nothing is returned. Copy it first if you need the original order.
• The helpers do not check for null: a null argument throws a NullReferenceException.

Which Algorithm

Below a few hundred elements the difference is not measurable and InsertionSort is usually the best choice. Above that, use MergeSort — or List<T>.Sort with a comparer, which allocates less.

Testing Scene

Open Debug/ReorderSystemScene.unity. It holds a single object, ReorderSystemTest, carrying Mn_ReorderSystemTest. Everything happens in the Inspector, with no play mode: right-click the component header and the six entries of its context menu appear.

What to do, in order:

1. Set Count to 20, leave Nearly Sorted off, and run Generate. The Output field prints the list and says it is not sorted.
2. Run Run Insertion Sort. The same field prints the sorted list and how long the sort took.
3. Run Run All. All four algorithms run on the same freshly regenerated list, so the four timings are comparable.
4. Turn Nearly Sorted on and run Run All again. InsertionSort collapses to a fraction of its previous time, while the other three barely move.
5. Turn Nearly Sorted off, set Count to 5000, and run Run All once more. MergeSort is now the only one that finishes quickly.

This is what turns the advice in Which Algorithm from a claim into a measurement. The component regenerates the same list before each algorithm on purpose: without that, everything after the first would be sorting an already sorted list and would look artificially fast.

Technical Info

• Back to the toolkit index

© 2026 Marcello De Bonis. All rights reserved