Die Befehlsverwaltung bildet den Kern des Spiels. Ein Befehl ist ein Input eines Spielers, mit dem er einer ihm gehörenden Entity eine Anweisung erteilt. Diese Befehle werden in einer Queue vorgehalten und rundenweise abgearbeitet. Befehle werden auf allen Clients abgeglichen, das eigentliche Gameplay ergibt sich durch die deterministische Reaktion der Entities auf die Befehle, die ebenfalls rundenweise berechnet werden. Es gibt voraussichtlich 25 Spielrunden pro Sekunde, wobei bei Netzwerkspielen Befehle für eine bestimmte Rundenanzahl im Voraus registriert werden müssen, etwa entsprechend den Pingzeiten. Auch werden im Netzwerk nur etwa jede zweite oder dritte Runde Befehle verarbeitet (Befehlsrunden), um die Nachrichtenlast gering zu halten. Konkret sind am Ablauf folgende Klassen beteiligt:

Controller generieren die Befehle für die verschiedenen Spieler der Partie. Controller können nur Befehle für Spieler vergeben, für die sie eine Berechtigung haben, anderenfalls wird der Befehl verworfen mit einem Warnhinweis im Log. Es gibt vier Controller: Der LocalController reagiert auf die Eingaben vom lokalen Rechner und setzt diese, soweit zutreffend, in Befehle um. Der NetworkController liefert die Befehler aller über das Netzwerk verbundenen Rechner, er ist gleichzeitig dafür verantwortlich, die Befehle zwischen den Clients zu synchronisieren. Der AIController schließlich repräsentiert einen computergesteuerten Spieler und läuft auf dem Hostrechner eines Spiels. Und schließlich gibt es einen ReplayController, der im Falle des Anschauens von Replays alle Spieler steuert, wobei er deren Befehle aus dem Replay rekonstruiert. Vor Beginn jeder Spielrunde werden die Controller nach ihrem Status gefragt. Controller können hierdurch das Spiel unterbrechen, z. B. wenn der Spieler im Skirmish Pause gedrückt hat oder wenn der NetworkController für eine anstehende Befehlsrunde noch nicht von allen Clients ihre Befehlsliste erhalten hat und daher warten muss.

Listener registrieren sich bei der Command Queue und werden über alle eingehenden Befehle informiert, die sie nach Spieler filtern können. Sie werden auch über das Ende jeder Spielrunde und jeder Befehlsrunde informiert. Im Wesentlichen gibt es zwei Listener, zum einen den ReplayRecorder, der alle Befehle zur späteren Rekonstruktion aufzeichnet. Zum anderen den NetworkController, der die Befehle aller lokalen Spieler registriert und jeweils zum Abschluss einer Befehlsrunde die Befehle für die nächste an die übrigen Clients sendet.

Das Scenario ist Herr über eine komplette Partie; es verwaltet die Map und alle Entities. Auch implementiert es die Command Queue, nimmt also die Befehle von den Controllern entgegen und leitet sie an die Listener weiter. Zu Beginn jeder Befehlsrunde werden alle anstehenden Befehle abgearbeitet. In jeder Spielrunde geht das Scenario dann alle Entities durch und aktualisiert ihren Zustand. Alle paar Spielrunden wird eine Checksumme des Gesamtzustands generiert und an die Listener gegeben, diese können dann in Replays gespeichert oder über Netzwerk verglichen werden. Enorme Sorgfalt muss dafür getragen werden, dass die gesamte Abarbeitung streng deterministisch verläuft, so dass wirklich rechnerunabhängig dasselbe Ergebnis erzielt wird. Insbesondere müssen Traversierungsreihenfolgen für Entities etc. klar geregelt sein.

Command beschreibt jeweils einen Befehl. Zu diesem Zweck muss es zunächst den Spieler und die Befehlsrunde, in der der Befehl aktiviert werden soll, festhalten. Außerdem braucht es eine Liste aller Entities (in Form ihrer Identifikationsnummern), die von dem Befehl betroffen sind, sowie natürlich den Befehl selbst und etwaige nötige Parameter (Positionen, angegriffene Objekte etc.). Wenn ein Befehl ausgeführt wird, muss er anhand der IDs die eigentlichen Entities vom Scenario beziehen und ihnen die jeweilige neue Order mitteilen; hierbei ist sicherzustellen, dass auch wirklich nur Entities Befehle erhalten, die auch dem jeweiligen Spieler gehören. Commands müssen serialisierbar sein, um sie in Replays speichern und über Netzwerk tauschen zu können. Dafür sollte eine möglichst effiziente binäre Repräsentation gewählt werden.