spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Renegade«

+1 für JSON als Datentyp zum speichern (standardmäßig in Java integriert)

Das wäre mir aber ganz neu.

Bin ich hier der einzige der die Visual Studio Team Services nutzt?

Zitat von »Nimelrian«

Zitat von »Renegade«

+1 für JSON als Datentyp zum speichern (standardmäßig in Java integriert)

Das wäre mir aber ganz neu.

Habe ich das hier dann falsch interpretiert? Btw. kann ich YAML ebenfalls sehr empfehlen: http://yaml.org/

Renegade:
Auf der Oracle Webseite, die du gefunden hast, wird die JSON Library vorgestellt, allerdings ist diese nicht ins JDK integriert.
Allerdings kannst du diese natürlich sehr leicht einbinden, so wie jede andere Java Library auch.
Die JSON Library heißt übrigens org.json, hier mal die Maven Koordinaten: https://mvnrepository.com/artifact/org.json/json/20160810

Zitat von »Chromanoid«

D.h. wenn man das Spiel spielen will, wird auch eine MySQL-Datenbank auf dem Rechner abgeladen - oder man braucht eine Internetverbindung? Wieso ist es einfacher mit einer Datenbank neue Karten hinzuzufügen? Mir kommt das irgendwie schwieriger vor.

Die MySQL Datenbank sollte nie auf den Client Computer geladen werden - ein Datenbank Server ist immer (bzw. meistens, es gibt Ausnahmen wie SQLite) ein Server.
Demzufolge brauchst du auch eine Internet Verbindung zum MySQL Server.
Desweiteren sollte der Client auch nie direkt auf den MySQL Server zugreifen können, da sonst jeder User deine ganze Datenbank manipulieren könnte (wenn er nicht nur Read-Only Rechte hat).
Du bräuchtest also quasi noch nen Server, der die Daten dem Client (z.B. per JSON oder YAML) zur Verfügung stellt.

Wenn es dir schwieriger vorkommt, gibt es für dich 2 Varianten:
1. Du lässt die Datenbank einfach weg, wenn du ohne besser klar kommst und noch nicht mit MySQL gearbeitet hast. Immerhin sollte das bei einem Kartenspiel kein Problem darstellen.
2. Du probierst dich aus und sammelst neue Erfahrungen.

Je nachdem, wie die Datenbank aufgebaut ist, kann sie die Wartbarkeit meiner Meinung nach erheblich vereinfachen, als wenn einige Sachen hard gecoded oder in Konfigurationsdateien ausgelagert sind.
Allerdings ist das Geschmackssache.

Wirago:
Da man für Java kein Microsoft Produkt benötigt, werden auch die wenigsten eins einsetzen.
Vermutlich gibt es aber auch einige Leute, die auf Visual Studio Team Services setzen.

Zitat von »JuKu«

Die JSON Library heißt übrigens org.json, hier mal die Maven Koordinaten: https://mvnrepository.com/artifact/org.json/json/20160810

Nein, das ist eine andere Implementierung. Die von ihm verlinkte Seite referenziert weiterhin eine Dokumentation (bspw. die Seite des JsonObject), welches als namespace javax.json besitzt, die von dir verlinkte Bibliothek verwendet hingegen org.json. Weiter unten wird auch JSON Processing als Referenzimplementierung verlinkt.
Ein Nachteil von org.json ist, dass es dort keine einheitliche Schnittstelle für Werte aus JSON-Dokumenten gibt.

Zitat von »JuKu«

ein Datenbank Server ist immer [...] ein Server

Ja, ein Datenbankserver ist/läuft auf einem Server. Weil MySQL (und Oracle und Microsoft SQL Server) darauf ausgelegt sind, dass sie im Hintergrund auf einem Server laufen, statt mit einer Software mitgeliefert zu werden, eigenen diese sich nicht für die Clientseite bzw. für Standalone-Anwendungen.
Dafür gibt es dann wieder embedded DBMS (Database Management System), bei denen das gesamte System in Form einer Bibliothek mit der Software ausgeliefert wird. Der Unterschied ist, dass nicht zwingend an einem zentralen Ort alle Datenbanken abgelegt sein müssen, sondern dass diese in beliebigen Dateien abgelegt werden können, beispielsweise dem Verzeichnis, in dem auch die restlichen Informationen des Spielstands abgelegt werden.
Wichtig hierbei ist: ein Datenbank Server ist ein DBMS, aber ein DBMS nicht zwingend ein Datenbankserver.
Ob man mit einer Datenbank (embedded DBMS) oder mit anderen Formaten (JSON, YAML, XML) besser zurecht kommt, muss man selbst entscheiden. Tendenziell würde ich hier eher zu einem textuellen Format raten.


Für den Anfang solltest du wohl die Spielmechaniken implementieren. Ein Speichern der Karten macht frühestens dann Sinn, wenn ein Speichern unterschiedlicher/anderer Werte einen Sinn macht, die Werte also soweit bereits ausgewertet und berücksichtigt werden können.

Danke für die Aufklärung @JuKu und Saca

Zitat von »JuKu«

Je nachdem, wie die Datenbank aufgebaut ist, kann sie die Wartbarkeit meiner Meinung nach erheblich vereinfachen, als wenn einige Sachen hard gecoded oder in Konfigurationsdateien ausgelagert sind.
Allerdings ist das Geschmackssache.

Mir ist schon klar was eine Datenbank ist und wie man sie einsetzt. Auch mit eingebetteten Datenbanken habe ich schon gearbeitet. Aber wenn man das tut, dann wird alles viel komplizierter.
1. Es kommt eine neue Sprache dazu oder es muss ein Framework für ORM gelernt werden oder es müssen die Tücken der Objekt-Datenbank kennengelernt werden.
2. Es muss ein Datenbankschema gewartet und schlimmstenfalls versioniert werden.
3. Die Daten in der Datenbank müssen bei Anpassungen am Schema aktualisiert werden.
4. Es muss ein Tool/Editor entwickelt werden, damit man die Karten einfach in die Datenbank bekommt.
5. Es müssen Datenbank-Zugriffs-Klassen entwickelt werden.
6.1. Es muss ein Server entwickelt, bezahlt, überwacht und gewartet werden, der eine Schnittstelle für den Zugriff auf die Datenbank ermöglicht.
6.2. Oder die Datenbank auf einem Server (der bezahlt, überwacht und gewartet werden muss) muss wirklich sehr sehr gut konfiguriert werden und noch besser überwacht und gewartet werden.
6.3. Oder die Datenbank wird embedded genutzt. Dann muss man sich darum kümmern, dass die Daten in der Datenbank beim Update aktualisiert werden oder man liefert eh eine statische Datenbank aus, dann kann man auch eine serialisierte Hashmap o.Ä. ausliefern...

Zähl doch mal auf, was mir eine Datenbank nützt, wenn ich ein Kartenspiel entwickle? Wo wird die Wartung einfacher und nicht komplizierter? Mir fallen da nur wenige Dinge ein. Die haben dann eher damit zu tun, dass Spieler Decks auf dem Server speichern können o.Ä.

BTW wenn es nicht mehr als ein paar hundert Karten werden, würde ich stark überlegen, die Karten im Code zu verwalten - für jede Karte eine Klasse. Ich habe noch nie ein Kartenspiel entwickelt, aber mir kommt das ziemlich praktisch vor. Die Namen der Karten-Klassen kann man dann auch gleich benutzen, um einheitlich Ressourcen zu hinterlegen. Verweise auf Regeln kann man direkt im Code ablegen und bei Refactorings wird das gleich mit berücksichtigt. Man kann leicht einen Überblick erhalten, welche Klassen welche Regeln betreffen usw. Alles in der IDE ohne Editor.

Zitat von »Chromanoid«

BTW wenn es nicht mehr als ein paar hundert Karten werden, würde ich stark überlegen, die Karten im Code zu verwalten - für jede Karte eine Klasse. Ich habe noch nie ein Kartenspiel entwickelt, aber mir kommt das ziemlich praktisch vor. Die Namen der Karten-Klassen kann man dann auch gleich benutzen, um einheitlich Ressourcen zu hinterlegen. Verweise auf Regeln kann man direkt im Code ablegen und bei Refactorings wird das gleich mit berücksichtigt. Man kann leicht einen Überblick erhalten, welche Klassen welche Regeln betreffen usw. Alles in der IDE ohne Editor.

Würde ich vielleicht nicht mal machen. Lieber verschiedene Effekte und Regeln definieren und Karten als Komposition gestalten. Ggf. aus einer Datei mit der Beschreibung der Komposition und den dazugehörigen Werten. Macht schnelles testen und spielen möglich - ohne neue Builds.

Naja, wenn man das ganze aus der IDE startet, muss man ja auch nicht warten. Mit Java sind inkrementelle Builds und Kompilieren allgemein ja ziemlich zackig. Wenn man schon eine externe Datei verwendet, sollte man vielleicht überlegen ein Spreadsheet-Format wie XLSX zu nutzen. Dann hat man gleich eine nette "IDE" um die Kartenwerte anhand von Formeln zu bestimmten und darzustellen.

Wenn es nicht um ein CCG geht, sondern um ein Spiel wie Mau Mau, halte ich jede Form von externer Ablage der Spiellogik für sinnfrei. Vielleicht nimmt man dann nicht gerade für jede Karte eine Klasse, aber vielleicht für jede Kartenart.