Incom ist die Kommunikations-Plattform der Fachhochschule Potsdam

In seiner Funktionalität auf die Lehre in gestalterischen Studiengängen zugeschnitten... Schnittstelle für die moderne Lehre

Incom ist die Kommunikations-Plattform der Fachhochschule Potsdam mehr erfahren

No Cards Needed

Dies ist ein Freies-Projekt von Eric Wätke und Silas Wolf. No Cards Needed ist eine Online-Spielkartensimulation. Es bietet einen Rahmen, um jedes Spiel zu spielen – das mit Standard-Spielkarten gespielt wird. Das bedeutet, dass es keine weiteren Regeln zu befolgen gibt, als die, die man sich selbst ausdenkt.

Konzept

Vor drei Jahren hatte ich (Silas) die Idee das haptische Kartenspiel ins digitale zu übertragen. Ich wollte eine Art Gerüst entwickeln, mit dem man nach eigenen Regeln klassische Kartenspiele – mit Karten von Ass bis 2 – spielen könnte. Zu dieser Zeit hatte ich so gut wie keine Development Erfahrungen und gestaltete daher nur das Konzept.

Im Frühling 2022 entschieden Eric und ich uns dazu, dass das Konzept Potential hätte und dass wir es noch einmal durchdenken und anschließend umsetzen wollen.

Das Grundkonzept hat sich seitdem nicht mehr groß geändert. Die Web App soll es ermöglichen, so viele Kartenspiele zu spielen, wie möglich, ohne dabei feste Regeln vorauszusetzen. Damit basiert das Spiel auf sozialer Interaktion und ist nicht spielbar, wenn man nicht miteinander Kommunizieren kann. Regel müssen selbst festgelegt und durchgesetzt werden. Es besteht sogar die Möglichkeit zu schummeln.

Als Nutzungsszenario sahen wir die spontane Langeweile, die z.B. aufkommen kann, wenn man gemeinsam Zug fährt. Jetzt gibt es die Möglichkeit, in solchen Situationen die Langeweile mit einem digitalen Kartenspiel zu vertreiben.

Im Vorhinein legten wir eine klare Struktur für das Projekt fest und machten einen strikten Zeitplan. Diesen Zeitplan setzen wir auch bis zum Development ziemlich strikt durch.

Research

Konzept02.pngKonzept02.png
Konzept01.pngKonzept01.png

Bevor wir mit der Konzeptionierung anfingen, wollten wir erst einmal Informationen sammeln, um den Funktionsumfang und die generelle Struktur besser definieren zu können. Wir wollten uns außerdem den Markt anschauen und gucken, welche Apps es bisher schon gibt und wo ihre Schwächen liegen.

Konkurrenzanalyse01.pngKonkurrenzanalyse01.png
Konkurrenzanalyse02.pngKonkurrenzanalyse02.png
Konkurrenzanalyse03.pngKonkurrenzanalyse03.png
Konkurrenzanalyse04.pngKonkurrenzanalyse04.png

Konkurenzanalyse

Die Konkurrenz lässt sich in zwei Gruppen aufteilen. Auf der einen Seite sind Spiele, die nach bestimmten Regeln eines existierenden Spiels funktionieren und deren Funktionsumfang dahingehend sehr beschränkt ist. Von dieser Art App gibt es sowohl eine große Menge im Web als auch in den App Stores. Darunter fallen die App Mau Mau – Das Kartenspiel oder UNO Online, welches als App aber auch im Browser erhältlich ist.

Auf der anderen Seite stehen die Simulationsspiele, von denen es weitaus weniger gibt. Das bekannteste ist wohl der Tabletop Simulator, der eine riesige 3D Umgebung für das Spielen jeglicher Gesellschaftsspiele bietet. Damit war dieses Spiel mit einem weitaus größeren Funktionsumfang und mit einem Preis von 20€ auf Steam eine ganz andere Liga. Eine etwas unbekannte online Alternative ist Playingcards.io, welches einige vorgefertigte Spielauswahl hat, aber auch das freie Spielen nach eigenen Regeln ermöglicht. Hier gibt es zwar die Funktionen, die wir uns auch für unser Spiel wünschen, jedoch mit einem sehr komplizierten Interface und keiner mobilen Optimierung.

In der Regel ist die visuelle Anmutung dieser Spiele sehr skeuomorph und versucht stark die reale Welt abzubilden. Nur Playingcards.io versuchte etwas schlichter und weniger dreidimensional zu sein.

Technikrecherche

Spielrecherche01.pngSpielrecherche01.png

Spielrecherche

Für die Spielrecherche setzten wir uns mit 12 verschieden Spielen auseinander und versuchten sie in verschieden Kategorien einzuordnen und damit vergleichbar zu machen. Dabei fanden wir heraus, dass wir, wenn wir unseren Funktionsumfang auf ein bestimmte Ebene bringen könnten, eine sehr hohe Abdeckung von Spielen haben würden.

Design

Aufgrund der Recherche und der Analyse legten wir fest, welche Funktionen das Spiel mit sich bringen sollte und welche wir ausschließen werden.

In den Spiele-Voreinstellungen sollte es die Möglichkeit geben, die Anzahl der Karten und Größe der Decks zu bestimmen, die Anzahl der Decks, Joker und Handkarten und ob es einen Nachziehstapel gibt. Ablage Felder sollten jedoch erst im Spielgeschehen selbst definiert werden.

Im Spiel selbst sollte es dann die möglichkeit geben aus der Mitte Karten auf die Hand zu nehmen und andersherum, beim Ablegen der Karten in die Mitte sollte es möglich sein neue verdeckte oder offene Ablagestapel zu erzeugen, durch ein schüttel eines ganzen Staples soll dieser gemischt werden und durch einen Longpress soll ein Kontextmenü aufgerufen werden, über das man auch mischen, Stiche sammeln und Karten aus dem Spiel entfernen kann. Über ein Hamburger Menü sollte der Nachziehstapel neu gemischt werden und dazu sollten auf irgendeine Weise Stiche und aus dem Spiel entfernte Karten angeschaut werden können. Wir entschieden uns dagegen Funktionen des Schummelns z.B. Karten unter den Tisch fallen lassen, anpassbare Punkteliste, Funktion, um Karten um 90° zu drehen oder die Hand offen spielen zu können, zu integrieren.

Wireframes03.pngWireframes03.png
Wireframes01.pngWireframes01.png
Wireframes02.pngWireframes02.png
Wireframes04.pngWireframes04.png

Wireframing

Mit dem geklärten Funktionsumfang starteten wir mit dem Wireframing und probierten ein paar Konzepte aus.

Mood03.pngMood03.png
Mood01.pngMood01.png
Mood02.pngMood02.png
Mood04.pngMood04.png

Visuelle Gestaltfindung

Um auf Ideen für die Visualität zu kommen machten wir ein Moodboard auf und probierten einige Stile aus. Wir entschieden uns am Ende für einen sehr cleanen Look mit einer Akzentfarbe, um nicht vom Spielgeschehen abzulenken.

Mit dem gefundenen Stil begannen wir dann die App ganzheitlich auszugestalten. Für das Design nutzten wir erst noch ein Kartenspiel-Design, das Silas 2015 einmal gemacht hatte. Welches am Ende jedoch durch ein eigens dafür konzipiertes Deck ausgetauscht werden musste. Das Deck ist im Stil an unsere App angeglichen und ist etwas höher skaliert als bei haptischen gedruckten Decks. Außerdem benötigten wir noch eine Miniaturversion, die in den Einstellungen verwendbar ist.

Während der Entwicklung fiel uns dann bei Tests auf, dass die Einstellungen ohne eine visuelle Repräsentation der Karten nicht verständlich sind und fügten sie nachträglich ein.

Design01.pngDesign01.png
Design03.pngDesign03.png
Design02.pngDesign02.png
Design04.pngDesign04.png
Karten01.pngKarten01.png
Karten02.pngKarten02.png

Entwicklung

Technologie

Am Anfang stand noch die Entscheidung, ob wir das ganze mit einem Javascript Framework machen oder mit Unity. 

Eine Game-Engine, wie beispielsweise Unity oder Godot, würden uns schon spielwichtige Funktionalitäten bereitstellen, wie z.B. ein Scaffolding für Multiplayer.

Wir entschieden uns dann für die Javascript-Library React.js, da wir wollten, dass das Spielende No Cards Needed ohne installation auf jedem Gerät spielen können. Nach anfänglichem scheitern eine eigene Peer-to-Peer Engine zu entwickeln, entschieden wir uns einfach ein vorhandenes System zu nehmen. Nämlich der Realtime-Database von Firebase.

Drag and Drop, die wichtigste Funktion unseres Spiels lösten wir mit der react-draggable Extension.

Die Entwicklung stellte sich als sehr viel komplizierter heraus als gedacht. Sodass die Arbeitsteilung, von „einer macht die Gestaltung und der andere die Entwicklung“ nicht mehr aufging. So musste Silas sich auch an die Frontend-Entwicklung setzten und lernte das erste Mal React.

Während dessen setzte sich Eric mit der Mechanik des Spiels auseinander und stoß auf einige Hindernisse. 

Zum einen funktionierte die erste Networking-Implementierung mit dem Peer-to-Peer approach gar nicht. → Komplette Neu-Implementierung

Dann gab es in der neuen Datenbank ein Problem mit der Stack-Order der Karten, was nicht trivial lösbar war → Komplette Neu-Implementierung

So gab es immer wieder Probleme im Code, die riesige Änderungen mit sich zogen.

Da sich die einzelnen Features als komplizierter herausstellten, als gedacht, Reduzierten wir etwas. Nun war es noch möglich die eigenen Karten von der Hand auf vordefinierte Stapel offen oder verdeckt abzulegen und Stapel zu mischen.

Fazit

Am Ende hat das Projekt statt einem Semester drei gedauert. Zusätzlich mussten wir unseren Projekt Scope drastisch reduzieren, um ein spielbares Ergebnis zu bekommen. Auch den Aufwand der Entwicklung haben wir unterschätzt. Trotzdem war alles eine sehr lehrreiche Erfahrungen und Silas konnte damit seine Development Skills weiter ausbauen und Eric hat sich das erste Mal mit Peer-to-peer Networking und Realtime networking auseinandergesetzt. Außerdem stießen wir an die Grenzen von React. Diese sind im Grunde die komplette Funktions-Struktur von React und insbesondere das State-Management. Unser Hauptproblem war, dass wir oft „Stale State“ hatten. Das ist äußerst problematisch für Echtzeitspiele, da es bedeutet, dass die Spiellogik einen alten Spielstand hat, obwohl ein neuerer schon verfügbar wäre. (mehr dazu hier).

Now have fun playing the game!

Fachgruppe

Interfacedesign

Art des Projekts

Freies Projekt

Betreuung

foto: Prof. Dr. Sebastian Meier

Entstehungszeitraum

SoSe 22 – SoSe 23