npm install
ng serve
Danach im Browser http://localhost:4200 laden.
IP Adresse und Port müssen den lokalen Gegebenheiten angepasst werden.
ng serve --host 192.168.1.121 --port 4200
Danach im Browser http://192.168.1.121:4200/webpack-dev-server/index.html laden.
ng test
npm run e2e
Das Script "pree2e" muss in package.json vorhanden sein, damit die E2E Tests laufen. Es muss jedoch nicht explizit aufgerufen werden.
URL: https://casfee2019-p2-g4.web.app/
Falls nicht bereits früher gemacht: Firebase Tools installieren und mit Google-Account einloggen:
npm install -g firebase-tools
firebase login
Dann im Root der Applikation builden und deployen (dist/casfee2019-p2-g4):
ng build --prod
firebase deploy --only hosting
Alle Elemente deployen:
firebase deploy
Ein oder mehrere Elemente deployen:
firebase deploy --only firestore
firebase deploy --only firestore,functions
Die vorhandenen Umgebungen sowie die aktuell selektierte können mit folgendem Befehl angezeigt werden:
firebase use
Es bestehen die Umgebungen default
(Produktiv) und staging
. Letztere dient primär dem Testing von Anpassungen an den Cloud Functions.
Wechsel der Umgebung mit
firebase use staging
... oder aber
firebase use default
Folgender Befehl kann verwendet werden, um Angular mit dem Staging-Backend zu starten:
ng serve -c=dev2
- Authentisierung
- Benutzerprofil
- Spielvorbereitung
- Herausforderung
- Schlacht
- Hall of Fame
- Angular
- Firebase (Auth, Firestore, Cloud Functions)
- State Management mit NGXS
- Mehrsprachigkeit mit NGX-Translate
- Angular Material
- Angular Flex Layout
- Unit Test mit Jasmine
- e2e Test mit Protractor
- Usability Test
- Mehrsprachigkeit
- Unterstützung von mobilen Geräten
- Echtzeit-Datenbank
- Backend-Architektur mit Cloud Functions (kein Mogeln)
- Animationen
- Nicht cheatable: Ein böswilliger Benutzer kann nicht mit Crafted Reads/Writes den Spielverlauf zu seinen Gunsten ändern
- Nicht mass-writeable: Ein böswilliger Benutzer kann nicht Daten ausserhalb des definierten Datenmodells schreiben (verhindert parasitäre Nutzung der Datenbank).
- Alle Collections sind für den Client read-only
- Geschrieben wird ausschliesslich über Cloud Functions
- Lese-optimierte Datenstruktur (denormalisiert). Jeder Spieler sieht nur seine eigene Kopie des Spielzustands
- Dies erlaubt triviale und dennoch sichere Firestore-Rules
- Avatar (ersetzt durch generischen Avatar)
- Admin-Modul (ist teilweise ersetzbar durch die in Firebase eingebauten Admin-Tools)
- Zeitbeschränkung pro Spielzug
Dies Funktion wäre im echten Produkt zwingend. Sonst kann ein Spieler seinen Gegner durch Inaktivität zur Niederlage zwingen: denn dieser muss in der Folge kapitulieren, um ein neues Spiel anfangen zu können.
Usability Issues
- Platzierung der Schiffe ist speziell auf Mobilgeräten etwas hakelig. Drag&Dop könnte verbessert werden.
- Einen Gegner zu finden ist nicht ganz einfach - man muss sich praktisch
ausserhalb des Games verabreden.
- Einerseits fehlt eine Kritische Masse von Spielern, welche es erlauben würde, jederzeit einen Gegner finden kann. Sinnvoll wäre dementsprechend die Möglichkeit, bei Abwesenheit menschlicher Gegner gegen einen Bot spielen zu können.
- Andererseits ist das Problem, dass die Spieler im Status "Gegner finden" verbleiben, auch wenn sie gar nicht mehr aktiv bzw. offline sind. Eine Herausforderung läuft dann ins Leere. Mögliche Lösungen: Online-Status der Spieler anzeigen (vergleichbar mit Messenger-Applikationen); Push-Meldung anbieten ("Dein herausgeforderter Gegner XY ist jetzt online").
- Error Handling: Wir haben zwar dafür gesorgt, dass etliche Fehler abgefangen und im UI kommunziert werden, aber typische Zustände wie z.B. "Kein Netz", sind nur teilweise behandelt.
Technische Issues
- Modulstruktur (weniger Module, trennen zwischen Feature- und Service-Modulen).
- Redux/NGXS noch konsequenter einsetzen.
App
User
Spiel