software-challenge · xeruf · Apr 16, 2020 · Apr 1, 2020 · Apr 1, 2020 · Apr 2, 2020
diff --git a/README.md b/README.md
@@ -1,70 +1,72 @@
 # Software-Challenge [![Build Status](https://travis-ci.com/CAU-Kiel-Tech-Inf/socha.svg?branch=master)](https://travis-ci.com/CAU-Kiel-Tech-Inf/socha)
 
-Das offizielle Repository der [Software-Challenge](https://www.software-challenge.de/), welches aus Server, Client und Spiel-Plugins besteht.
+Dies ist das offizielle Repository der [Software-Challenge](https://www.software-challenge.de/), ein Programmierwettbewerb für Schüler.
+Ziel hierbei ist, für ein jährlich wechselndes Spiel eine künstliche Intelligenz zu entwickeln, die den Gegenspieler besiegt.
+Das Repository besteht aus Server, Client und Spiel-Plugins.
 
 ## Struktur
 
 | Ordner | Beschreibung |
 | ------ | ------------ |
 | helpers | Zusätzliche Tools (aktuell nur der TestClient) |
-| player | Simpleclient dieses Jahres |
+| player | SimpleClient dieses Jahres |
 | plugin | Plugin dieses Jahres |
 | server | Spielserver |
 | socha-sdk | Projektübergreifend verwendete Klassen |
 
 ## Collaboration
 
-Wir nutzen den type-scope commit message Syntax nach [Karma Runner](http://karma-runner.github.io/4.0/dev/git-commit-msg.html), wobei die verfügbaren scopes in [.dev/scopes.txt](.dev/scopes.txt) definiert werden. Bitte führe nach dem klonen des repositories einmal folgendes im Terminal aus, damit die entsprechenden git hooks aktiv werden:  
+Unsere Commit-Messages folgen dem Muster `type(scope): summary` (siehe [Karma Runner Konvention](http://karma-runner.github.io/latest/dev/git-commit-msg.html)), wobei die verfügbaren Scopes in [.dev/scopes.txt](.dev/scopes.txt) definiert werden. Bitte führe nach dem Klonen des Repository's einmal Folgendes im Terminal aus, damit die entsprechenden Git-Hooks aktiv werden:  
 
     git config core.hooksPath .dev/githooks
 
-Um bei den Branches die Übersicht zu behalten, sollten diese ebenfalls nach der Konvention benannt werden - z.B. könnte ein Branch mit einem Release-fix für gradle `fix/gradle-release` heißen und ein Branch, der ein neues login-feature zum server hinzufügt, `feat/server-login`.  
-Branches werden normalerweise beim mergen gesquashed, außer die einzelnen commits des branches haben jeweils eine alleinstehende Aussagekraft.
+Um bei den Branches die Übersicht zu behalten, sollten diese ebenfalls nach der Konvention benannt werden - z.B. könnte ein Branch mit einem Release-Fix für Gradle `fix/gradle-release` heißen und ein Branch, der ein neues Login-Feature zum Server hinzufügt, `feat/server-login`.  
+Branches werden normalerweise beim Mergen zu einem einzelnen Commit zusammengefügt (Squash-Merge), es sei denn, die einzelnen Commits des Branches haben jeweils eine alleinstehende Aussagekraft.
 
-Detaillierte Informationen zu unserem Kollaborations-stil findet ihr in der [Kull Convention](https://xerus2000.github.io/kull).
+Detaillierte Informationen zu unserem Kollaborations-Stil findet ihr in der [Kull Konvention](https://xerus2000.github.io/kull).
 
 ## Build
 
-Als Build-Tool wird [Gradle](https://gradle.org/) verwendet. Das gesamte Projekt kann sofort nach dem checkout per `./gradlew build` gebaut werden, es ist keine Installation von Programmen nötig.
+Als Build-Tool wird [Gradle](https://gradle.org/) verwendet. Das gesamte Projekt kann sofort nach dem Checkout per `./gradlew build` gebaut werden, es ist keine Installation von Programmen nötig.
 
 Die wichtigsten Tasks:
 
 | Task | Beschreibung
 | ------ | ------------
-| `build` | baut alles, deployt und testet
-| `test` | führt tests aus
-| `deploy` | erstellt hochladbare ZIP-Pakete
-| `integrationTest` | testet ein komplettes Spiel sowie den TestClient
-| `startServer` oder `:server:run` | führt den Server direkt vom Quellcode aus
-| `:server:startProduction` | startet den gepackten Server
-| `:player:run` | startet den SimpleClient direkt vom Sourcecode
-| `:player:shadowJar` | baut eine jar des SimpleClient
-| `:test-client:run` | startet den Testclient
+| `build` | Baut alles, deployt und testet
+| `test` | Führt Tests aus
+| `deploy` | Erstellt hochladbare ZIP-Pakete
+| `integrationTest` | Testet ein komplettes Spiel sowie den TestClient
+| `startServer` oder `:server:run` | Führt den Server direkt vom Quellcode aus
+| `:server:startProduction` | Startet den gepackten Server
+| `:player:run` | Startet den SimpleClient direkt vom Sourcecode
+| `:player:shadowJar` | Baut eine jar des SimpleClient
+| `:test-client:run` | Startet den TestClient
 
 ### Unterprojekte
 
 Tasks in Unterprojekten können über zwei Wege aufgerufen werden:  
-`./gradlew :server:run` führt die Task "run" des Unterprojektes "server" aus.
-Alternativ kann man in das server-Verzeichnis wechseln und dort `./gradlew run` ausführen.
+`./gradlew :server:run` führt den Task "run" des Unterprojektes "server" aus.
+Alternativ kann man in das Server-Verzeichnis wechseln und dort `./gradlew run` ausführen.
 
-Bei der Ausführung eines Unterprojekts via `run` können per `-Dargs="Argument1 Argument2"` zusätzlich Argumente mitgegeben werden. Zum Beispiel kann der TestClient mit folgendem Befehl direkt aus dem sourcecode getestet werden:
+Bei der Ausführung eines Unterprojekts via `run` können per `-Dargs="Argument1 Argument2"` zusätzlich Argumente mitgegeben werden. Zum Beispiel kann der TestClient mit folgendem Befehl direkt aus dem Sourcecode getestet werden:
 
     ./gradlew :test-client:run -Dargs="--player1 ../../player/build/libs/defaultplayer.jar --player2 ../../player/build/libs/defaultplayer.jar --tests 3"
 
-### Arbeiten mit Intellij IDEA
+### Arbeiten mit IntelliJ IDEA
 
-Zuerst sollte sichergestellt werden, dass die neuste Version von Intellij IDEA verwendet wird, da es ansonsten Probleme mit Kotlin geben kann.
+Zuerst sollte sichergestellt werden, dass die neuste Version von IntelliJ IDEA verwendet wird, da es ansonsten Probleme mit Kotlin geben kann.
 
-In Intellij kann man das Projekt bequem von Gradle importieren, wodurch alle Module und Bibliotheken automatisch geladen werden. Dazu sind folgende Schritte notwendig:
+In IntelliJ kann man das Projekt bequem von Gradle importieren, wodurch alle Module und Bibliotheken automatisch geladen werden. Dazu sind folgende Schritte notwendig:
 
 - Projekt klonen: `git clone git@github.com:CAU-Kiel-Tech-Inf/socha.git`
-- In IDEA auf "File" > "New" > "Project from existing sources" > socha Verzeichnis auswählen
+- In IntelliJ auf "File" > "New" > "Project from existing sources" > socha Verzeichnis auswählen
   - "Import project from external model" > "Gradle" auswählen
   - Im folgenden Fenster:
     - "Use auto-import" ankreuzen
     - bei "Gradle JVM" JDK 8 auswählen, wenn sie nicht schon ausgewählt ist
     - "Finish" drücken
-- Warten, bis das Gradle build fertig ist
+- Warten, bis das Gradle-Build fertig ist
 - Einmal im Terminal `git checkout .idea` ausführen, um sich die codeStyles zurückzuholen
 
-Nun können Gradle tasks auch direkt in IDEA vom Gradle Tool Window (befindet sich normalerweise in der rechten Andockleiste) ausgeführt werden.
+Nun können Gradle-Tasks auch direkt in IntelliJ vom Gradle-Tool-Fenster ausgeführt werden; dieses befindet sich normalerweise in der rechten Andockleiste.