[Projekt] Shardcraft (MMO-RTS) - alpha released

[LONy]

Ich möchte euch hier ein kleines Projekt vorstellen, an dem ich schon ein paar Monate arbeite. Hierzu werde ich immer wieder diesen Beitrag aktualisieren um ihn auf dem neuesten Stand zu halten:

Bei Shardcraft handelt es sich um ein Echtzeit Aufbau und Strategiespiel in Entwicklung. Es soll einmal ein MMO-RTS werden ;) Bisher ist es ein Ein-Mann Projekt von mir, dass ich in Unity entwickle. Zielplattform ist momentan PC/Windows, später auch Linux, Mac und Mobile.

Shardcraft download v0.0.4 auf itch.io:
https://lonytoon.itch.io/shardcraft

Teaser auf Youtube:


Vom Spielablauf bekommt jeder Spieler zu Beginn eine Insel, die er um Inselteile erweitern kann, Gebäude errichten muss um Ressourcen usw. zu bekommen. Nebenbei kann er mit einem "Schiff" umher fliegen um weitere Inselteile, Items und Rohstoffe zu suchen.

Das Backend ist ein Node.js Server. Als Verbindung zwischen dem Unity-Client und dem Server verwende ich eine Websocket Verbindung. Als Datenbank wird eine MySQL Datenbank eingesetzt.

Was mich bisher weiter kommen lassen hat als bei früheren, nie beendeten Projekten:
* Assets / Grafiken aus dem Unity Asset Store - es motiviert doch ungemein, wenn dein Projekt gleich mehr nach Spiel aus sieht
* Viele Bordmittel von Unity, die einem die Arbeit erleichtern - Wenn ich überlege wie viel Tage und Wochen bei meinen ersten Canvas / HTML5 und WebGL Experimenten ins Land gingen oder ganz weit zurück an das erste Buch von Stefan Zerbst xD

Was bisher funktioniert (Stand 24.05.2020)
* Login und Validierung mit einer Session-ID
* Übertragung der Insel-Geometrie aus der Datenbank an den Client
* Bewegung eines oder mehrer Schiffe, die Position wird über den Server an weitere Clients verteilt
* Statische Objekte aus der Datenbank Lesen und an den Client übertragen
* Dynamischen nachladen von Objekten in Abhängigkeit von der Position der Objekte des Users
* 2 Basisrohstoffe: Bäume, Steine
* 2 Rohstoffe: Bretter, Quadersteine
* 5 Gebäude: Holzfäller, Steinmetz, Sägewerk, Kran und Wohnhaus
* Den Inselbewohnern können Aufgräte zugewiesen werden (Bau einen Holzfäller, Arbeite als Steinmetz,...)
* Zusätzliche Inselbewohner bekommt man durch ein Wohnhaus

Als nächstes geplant:
* Die Datenbank erweitern und Spielinhalte erstellen (Rohstoff: Nahrung / Gebäude: Händler)
* Händler. Interaktion mit anderen Spielern, kaufen & verkaufen von Rohstoffen
* UI und Dialoge um den Spieler durch die Spielwelt zu führen, das Ganze durch die Inselbewohner die sich hin und wieder zu Wort melden

Probleme / Herausforderungen:
*Das Spiel bekannt zu machen

Grüße,
LONy

[odenter]

Probleme / Herausforderungen:
* Die Datenübertragung im JSON Format funktioniert nicht ganz Reibungslos zwischen Client und Server. Vor allem habe ich Probleme, wenn ich Floatingpoint Zahlen übertrage. Evtl. wandel ich alles in "Fixed Point" um, also Übertragung als Integer und jeweils Mutiplikation / Division...
* Serverseitiges Datenhandling:
- Was macht Sinn über die Datenbank zu organisieren,
- was halte ich lieber in Variablen / RAM und synchronisiere es nur alle paar Sekunden / Minuten mit der Datenbank,
-> um bei einem Neustart keinen Datenverlust zu haben?
-> um Performance vorteile zu haben?

Ganz allgemein. Alles im Speicher halten und ganz ganz wichtige Dinge sofort in die DB und eher unwichtige Informationen zeitlich später also in irgendwelchen Intervallen in die DB schreiben. Idealerweise natürlich asynchron und nicht in Form einer Deine Spiellogik blockierenden Methode. 8)

Ich persönlich würde meine Kommunikation in Form von Byte-Array's durchführen, in wie weit das mit einem Node.js Server (ist das JavaScript oder wie sieht das Backend aus?) funktioniert kann ich nicht sagen.
Im Grunde sendet das Backend ja nur Statusinformationen und Statusänderungen an den Client der den Stuff dann zeichnet. Diese Statusinformationen oder Änderungen kannst in einer Nachricht zusammenfassen und auf dem Client entsprechend wieder auseinander nehmen.

[scheichs]

Tolles Projekt. Sieht sehr gut aus! Zu den Problemen und Lösungen kann ich wenig sagen, aber die Vorschläge von odenter hören sich gut an.

[LONy]

Danke für das Feedback :)

Der Node.js Server ist in Javascript geschrieben. In den letzten Tagen habe ich einiges an der Kommunikation umgeschrieben. Sämtliche float-Zahlen werden jetzt als Ganzzahlen (mit Faktor 1000) übertragen und entsprechend beim Senden / Empfangen umgerechnet. Die Einheitenbewegung wurde vorher jede Sekunde auf dem Server berechnet bzw. jedes Frame auf dem Client nach dem Schema:

Code: Alles auswählen

So lange Startposition != Zielposition: Startposition += Geschwindigkeitsvektor * dt

Ich möchte eigentlich gerne das zwischen allen Objekten (zumindest den Inseln) Gravitation als Kraft herrscht und somit die Flugbahn beeinflusst... Allerdings würde die (effiziente) Implementierung sehr viel Zeit beanspruchen und es wird schwierig so eine chaotische Physik wie Gravitation sinnvoll zwischen dem Server und den Clients zu synchronisieren. Daher hab ich diese Idee erst mal verworfen und berechne jetzt die aktuelle Position nur wenn sie Benötigt wird. Inzwischen werden auch bei jeder Usereingabe die Informationen über die Einheitenbewegungen in der Datenbank aktualisiert.

Eine Herausforderung war noch die Synchronisierung der Serverzeit: Javascript rechnet immer mit 64 bit und Date.now() liefert den Zeitstempel in ms seit 1.1.70. In Unity ist die Zeitrechnung als float in Sekunden seit Applikationsstart. Die Zahl die Date.now() liefert war auch zu Groß um sie problemlos als JSON zu übertragen.
Die etwas Ressourcen verschwendende Lösung: Ich gebe den Zeitstempel als String Serverseitig aus, und Clientseitig speicher ich dein Zeitstempel als long mittels long.Parse(). Je nach Kommunikationsrichtung verrechne ich dann beide Zeiten mit einander...

Sehr effizient ist die Netzwerkkommunikation nicht, aber ich Versuche die Kommunikation und die Spiellogik zu trennen, so dass ich später auf eine "nicht string basierte" Kommunikation umsteigen kann. Momentan ist mir aber erst mal wichtig mit der eigentliche Funktion voran zu kommen... Über Performanceprobleme kann ich mir Gedanken machen, falls tatsächlich so viele Leute mein Spiel spielen, dass dies relevant wird :D

[LONy]

Ressourcen

Eine wichtige Ressource sollen Inselteile werden, mit denen man seine Insel ausbauen kann.
Eben habe ich Serverseitig einen Tile-Generator implementiert. Wenn ein neues Tile generiert wird, wird es automatisch an alle Clients verteilt und bei diesen angezeigt. Die Tile steigen langsam auf und sollen in der Ebene, wo sich auch Inseln und Einheiten befinden, von den Schiffen eingefangen werden, um die eigene Insel erweitern zu können.
Tiles sollen verschiedene Eigenschaften haben und so als Ressourcenquelle oder Bauland für neue Gebäude dienen.
Durch unterschiedliche Technologie soll der Spieler zu unterschiedlichen Zeitpunkten (Technologie weiter ausgebaut = früher Zeitpunkt) die Inselteile sehen können.
Ich erhoffe mir durch diese Spielmechanik ein wichtiges Spielelement -> Man sieht frühzeitig ein neues Inselteil, fliegt zu der Position an der man es abfangen kann und muss ggf. diese Position gegen andere Spieler verteidigen um das Inselteil dann Einzufangen und zu seiner Insel zu transportieren...

Durch das langsame Aufsteigen entsteht auch ein guter 3D-Effekt bzw. Tiefeneffekt wenn man die Kamera bewegt.
Hier ein Test (mit natürlich viel zu vielen Inselteilen):

Tilegenerator

Performance der Datenübertragung: 350 Objekte werden in unter einer Sekunde geladen und angezeigt incl. vielen Debug-Infos in der Konsole, wobei Server und Client momentan am selben Rechner laufen.

[Chromanoid]

Das mit den aufsteigenden Teilen finde ich eine geniale Idee. Wolken könnten die Teile dann auch mal verdecken und man muss dann entsprechende Technologie haben um die Teile trotzdem auszumachen. Sowas wie bei Anno mit Rohstoff vorkommen und Anbaumöglichkeiten sind dann auch sehr spannend. Wann kann ich solche Statistiken in welchem Detail sehen... Man könnte ja auch noch Monster und Artefakte auf diesen positionieren, dann gibt es noch mehr Abwechslung und Anreize. Aber solche Ideen hast du sicher auch gehabt... Verschwinden die nicht eingefangenen Teile sofort oder schweben sie eine Zeit in der Spielebene herum?

Ich fände übrigens einen Steampunk/Dieselpunk Look mit Luftschiffen irgendwie passender. Btw kennst Du die Jugend-Fantasy-Romanserie die Klippenland-Chroniken?

Bezüglich Kommunikation: schau dir sonst mal https://msgpack.org oder https://developers.google.com/protocol-buffers an. Ersteres kann man glaube ich leicht zusätzlich zu Json einbauen und dann je nach Debug Modus oder Performance Modus umschalten.

[marcgfx]

Hm, wenn man aufsteigende Teil bei seiner Insel anbringen kann, kann man auch bei anderen Inseln was klauen?

[LONy]

Danke für das Feedback!

@Chromanoid:
Ja die Ideen kommen zum Glück ganz von selbst während man coded :) Das Schiff mit dem der Spieler Umher fliegen kann bewegt sich wie die Inseln auf einer festen Ebene (y=0). Der "Traktorstrahl" des Schiffs soll eine gewisse Reichweite haben. d.H. während einer gewissen Zeit ist es für den Spieler Möglich die Inselteile einzufangen. Wenn sie zu hoch gestiegen sind, reicht die Reichweite des Schiffs nicht mehr und gleichzeitig verschwindet dass Inselteil aus dem Sichtbereich (kann dann einfach wieder client & serverseitig gelöscht werden).
msgpack hab ich mir mal angesehen, sieht sehr interessant aus, danke. Da ich eben noch das "laufen" in Unity lerne werd ich mit JSON erst mal weiter machen um voran zu kommen, aber es ist gut zu wissen, dass es relativ einfache Möglichkeiten zum Optimieren gibt.

@marcgfx:
Ob das Möglich sein wird und wie ich das löse weiß ich noch nicht. Ich stell mir eine art Gravitationsgenerator vor, der die Inselteile zusammen hält. Der Spieler muss ich um Energie o.ä. kümmern, damit er genügend Gravitation aufbauen Kann um seine Insel zusammen zu halten. Bei zu wenig, können sich Inselteile wieder lösen (und schweben dann evtl. einfach auf der y=0 Ebene herum,... mal sehen). Erstmal soll es relativ starke Inselverteidigung geben, so dass man sich lieber nicht einer feindlichen Insel nähert.

Sehr cool fände ichs, wenn Inseln richtig kollidieren können. Für die Phyiskengine von Unity düfte das kein Problem sein, aber ich müsste alles auf dem Server validieren oder komplett auf dem Server berechnen... -> schwacher Gravitation auf der Insel -> man rammt die Gegnerinsel einfach in Stücke :D

Als Spielinhalt habe ich auch viele NPCs geplant, die den Spielverlauf etwas steuern. Um hier komfortable Inhalte zu erstellen will ich Unity nutzen. Während die App läuft platziere ich neue Objekte und weiße sie meiner Insel zu, ein Script durchläuft alle Objekte, ermittelt die IDs, baut einen JSON-String und sendet diesen mit Koordinaten usw. an meinen Server, damit dieser die Objekte in der Datenbank speichert:

Editieren in Unity:

Live-Vorschau im Spiel:

JSON-String, der dann an den Server geht:

Code: Alles auswählen

{"staticObjects":[{"typ":2,"x":-445,"y":311,"z":-736,"rx":270000,"ry":120110,"rz":0,"sx":300,"sy":300,"sz":300},{"typ":2,"x":-1233,"y":150,"z":2065,"rx":270000,"ry":250843,"rz":0,"sx":300,"sy":300,"sz":300},{"typ":2,"x":328,"y":150,"z":-738,"rx":270000,"ry":65768,"rz":0,"sx":300,"sy":300,"sz":300},{"typ":3,"x":-1979,"y":-990,"z":-48,"rx":270000,"ry":152678,"rz":0,"sx":500,"sy":500,"sz":500},{"typ":2,"x":-1557,"y":150,"z":1472,"rx":270000,"ry":181532,"rz":0,"sx":300,"sy":300,"sz":300}],"parent_id":3,"user_id":1,"session_id":"ef6aac41-b0a3-3580-4c22-7be49f481b25"}

Der "typ" bestimmt dann die Grafik, und ggf. weitere Funktionen (Scripte, die ich beim Laden an das Objekt hänge). Bis zum ersten Release will ich relativ viele Objetke gecodet haben, die ich dann einfach über die Datenbank dynamisch einbinden kann und so immer neuen Spielinhalt ohne Update der Applikation erstellen kann...
Einen ersten spielbaren Alpha Release hab ich so für ende Februar geplant, um Frühzeitig Feedback zu bekommen.

[LONy]

Das übertragen von statischen Objekten funktioniert nun in beide Richtungen (Client <-> Server). Damit ist ein kleines Etappenziel geschafft und ich kann anfangen Spielinhalte zu generieren (NPC Inseln usw.).
Als nächstes steht weiterhin auf dem Programm das platzieren von Gebäuden. hier weiß ich noch nicht, ob ich es über mein Datenhandling der statischen Objekte laufen lasse oder für Gebäude noch mal was eigenes schreibe (momentan fällt mir kein Vorteil ein, ein Gebäude anders zu behandeln als z.B. im vorherigen Post die Brücke oder Holzspieße).
Dann noch das Einfangen von Inselteilen und erweitern der Insel und natürlich (weitere) Rohstoffe...

Jetzt bin ich aber erst mal eine Woche im Urlaub und melde mich Anfang Februar wieder :)

[LONy]

Ich melde mich mal wieder mit einem kleinen Update... Die letzten Wochen war ich nicht untätig, allerdings musste ich erst einmal allerlei grundlegende Sachen mir überlegen z.B. wie ich mit Ressourcen umgehe.

Ressourcen handhabe ich jetzt als "invisble object" in einer eigenen Tabelle in der Datenbank. Es sind Objekte die keine Position haben, sondern einem statischen Objekt wie z.B. Baum, Gebäude,... zugeordnet sind.
Ein Holzfäller z.B. sucht in seiner Umgebung nach Objekten mit dem unsichtbaren Objekt "Baum". Er läuft zwischen seiner Holzfällerhütte und dem Baum hin und her und holzt diesen ab, bis das invisible object des Baums 0 wird oder bis das Lager der Holzfällerhütte voll ist... ebenso der Arbeiter vom Sägewerk oder der Arbeiter vom Lager... Das ganze hab ich jetzt so dynamisch hin bekommen, dass ich für neue Rohstoffe nicht eine Zeile Code schreiben muss, sondern alles über die Datenbank handhaben kann. Die "funktion" des Holzfällers sieht z.B. so aus. In der DB ist es einfach als JSON String gespeichert:

Code: Alles auswählen

{"data":[{"name":"workerID","value":13},{"name":"use","value":1},{"name":"produce","value":3},{"name":"prodSpeed","value":30},{"name":"storage","value":9}]}

Der node.js Server berechnet nun sämtliche Arbeiter und schickt nur Statusupdates an den/die Clients. Somit ist die Spiellogik komplett auf dem Server und ich kann ohne ein Update der Client Seite auch die Spiellogik ändern.

Bei einem Test konnte ich Problemlos 200.000 Arbeiter gleichzeitig vom selben Gebäude aus den gleichen Rohstoff abbauen lassen (Serverseitig ohne Anzeige).
Wenn viele Spieler irgend wann einmal gleichzeitig online sein sollten, könnte das Update der Clients das Nadelöhr werden.. aber darum kümmer ich mich, wenn es so weit ist. Ich kann ja die Spiellogik 1:1 auf dem Client nachprogrammieren (z.B. verarbeiten von Rohstoffen) und muss dann nur beim Verbinden des Clients einmalig den Status aller Objekte vom Server übertragen. Erst wenn der User aktiv eingreift (neues Gebäude baut,...) muss ich dann einen Sync vom Server zum Client vor nehmen.

Hier noch ein Screenshot mit zwei Holzfällern, Steinmetz, Sägewerk und Lager:

Momentan bewegen sich die Arbeiter nur geradlinig ohne Rücksicht auf Hindernisse. Später will ich sie an den Kanten der Sechsecke entlang laufen lassen... evtl. muss der User dafür auch Wege bauen, mal sehen.
Der blaue Balken gibt Rückmeldung darüber, wie lange der Arbeiter noch für den aktuellen Arbeitsschritt braucht.

Hier noch etwas Brainstorming zu Rohstoffen, mal sehen was ich davon umsetzte...

[marcgfx]

Cool gehts weiter! Scheint ja noch um einiges komplexer zu werden als ich erwartet habe. Ich hatte ursprünglich gedacht das wird ein Spiel mit kurzen Runden sein. Bin gespannt!

[LONy]

Hey Marcgfx,
ja langsam aber sicher geht es weiter :) Das ganze soll ein RTS werden, dass über Monate oder gar Jahre läuft.

Ich habe viel am node.js Server gearbeitet. Der Server verteilt jetzt automatisch alle relevanten Objekte an die Clients. D.h. wenn ein Objekt eines anderen Spielers in die Nähe der eigenen Objekte kommt, wird es auf Client Seite erstellt, oder wenn es sich wieder weit genug entfernt hat auch wieder automatisch gelöscht. Es wird auch nur noch an die tatsächlich in der Nähe befindlichen Spieler verteilt und nicht einfach an alle, die eingeloggt sind.

Jetzt habe ich angefangen am UI zu arbeiten. Hier bin ich mir noch unsicher, ob ich das UI in der 3D Welt darstellen will oder nur 2D auf dem Monitor (World Space vs. Screen Space)...
Ich plane, dass der Spieler durch Dialoge von den Inselbewohnern durch das Spiel geführt wird. NPCs sollen kleine Quests an die Spieler verteilen und so für Abwechslung sorgen. Gerade hier bin ich schwer am Überlegen, ob ich diese Textnachrichten tatsächlich Einheiten in der 3D Welt zuordne und diesen Einheiten auch eine Persönlichkeit gebe, oder einfach nur den Text im Screen Space UI darstelle... Die Gefahr ist groß sich in Details zu verlieren und das Spiel nie fertig zu bekommen!
Wo ich mir auch unsicher bin, ob ich dann die UI Elemente je nach Zoomstufe der Kamera auch kleiner werden lasse, oder fest in der Größe halte. Der Würfel als Testeinheit hat ein kleines gelbes Ausrufezeichen. Ich denke es ist cooler, wenn der Spieler hier hinein zoomen muss um sich dann der kleinen Einheit zu widmen als wenn auch bei maximaler Entfernung das gelbe Ausrufezeichen deutlich und groß sichtbar ist...

Bei Filmen sieht man ja manchmal riesige Schriftzüge zwischen z.B. Hochhäusern während des Intros... beim Rumspielen ist folgender Screenshot entstanden :D

Es hat leider schon ein anderes Spiel den Namen Gravitiy Island... Gravity Islands unterscheidet sich dann aber doch zu wenig. Ich hab noch ein paar andere Ideen für einen Spielnamen, aber ihr dürft auch gerne eurer Phantasie freien lauf lassen ;)

[Chromanoid]

Mal ein paar Ideen :)
Shardcraft
Rising shards
Shards in the sky
Anchored lands

[marcgfx]

Ich wollte clever sein und kam auf "Buoyancy", gibts auch schon: https://store.steampowered.com/app/1012610/Buoyancy/

Rise & Raze?

die drei Wörter könnten hilfreich sein:
Raise means to elevate (something upwards).
Rise means to ascend.
Raze means to destroy.

Raise-Rise-Raze the first tripple R game of it's kind.

[LONy]

Die Ideen gefallen mir alle ganz gut :) Langsam wird es auch ernst mit dem Namen. Ich hab mir heute einen vServer geholt, alles Nötige installiert und es hat alles ganz gut geklappt. Latenz ist nicht spürbar, wenn ich mit 2 Clients gleichzeitig online bin und die Einheiten mit einem bewege und am anderen Client die Bewegung verfolge (da hatte ich etwas Angst, dass man eine Verzögerung spürt, da ich bisher ja bisher nur lokal entwickelt habe).

Das UI hat jetzt ein Radar, dass automatisch scrollt und alle Einheiten im Sichtbereich anzeigt.

Jetzt noch eine Registrierung, automatisches Eintragen der Userdaten + neuer Insel in der Datenbank, Rohstoffe, das Generieren und Einfangen der Inselteile und ich könnte schon fast ne Alpha Version starten :D

[Chromanoid]

Ich würde mir an Deiner Stelle Shardcraft.com schnappen. Das ist ein guter Name und da schwingt viel mit, das Du ausnutzen kannst.

[LONy]

Gesagt, getan... manchmal muss man einfach Nägel mit Köpfen machen. Danke Chromanoid :)

http://www.shardcraft.com

Das ganze ist noch sehr rudimentär und meine html, php usw. Kenntnisse sind sehr eingerostet... aber ein Grundgerüst steht und die Seite ist so hoffentlich auch rechts konform. Meine letzte Domain hatte ich vor ~12 Jahren oder so, da gabs noch keine DSGVO ;)

[LONy]

Man kann jetzt im Spiel direkt einen Account erstellen. Serverseitig wird dann in einem definierten Bereich an einer zufälligen Koordinate eine neue Insel erstellt.
Für die neuen Funktionen habe ich auch ein wenig an der GUI gearbeitet. Dazu habe ich mir Prefabs für Buttons, Text- und Eingabefelder erstellt. Hierdurch kann ich recht schnell neue Menüs zusammen klicken und bei bedarf später hoffentlich einfach die Darstellung ändern. Hier der Login Screen:

Wie schon erwähnt, gibt es jetzt auch ein Radar. Scrollen kann man momentan mit WASD, den Pfeiltasten oder durch Klicken im Radar. Eigene Einheiten werden grün dargestellt, alle anderen rot. Aber hier werde ich sicherlich noch mehr Variation rein bringen ;)

Serverseitig kann ich nun Nachrichten an den Client schicken, die der User dann lesen und wegklicken kann...

Was ich weiterhin vor mir her schiebe ist die Darstellung und Berücksichtigung von Rohstoffen. Das hängt natürlich maßgeblich vom Gameplay ab. Sieder, Anno,... haben sehr viele verschiedene Rohstoffe, dahingegen C&C, Warcraft,... nur 1-2. Shardcraft wird aber voraussichtlich viele verschiedene haben, was natürlich die Darstellung nicht einfacher macht ;)

[Chromanoid]

Voll gut. Hast Du eigentlich noch mal über Diesel-Punk oder Steam-Punk nachgedacht? Kennst Du "Last Exile"? https://www.youtube.com/watch?v=28roJHeVaZU https://www.youtube.com/watch?v=SQYDIG4g9ik

Ich glaube ein Steam-Punk + "Flugstein" - Technologie-Baum würde das ganze noch etwas interessanter und vielleicht auch plausibler machen.

Edit: Ich sehe gerade auf den Screenshots, dass es sowieso in die Richtung geht. Nur die Fluggeräte sehen finde ich recht futuristisch aus, aber da kommt es sicher auch auf die Bewegungsmuster und so an. Außerdem arbeitest Du da ja sicher noch dran :) BTW wie wäre es statt Traktorstrahl mit einer Harpune + Anker?

[LONy]

Hey Chromanoid,
Steam Punk hast du ja schon mal vorgeschlagen und gefällt mir von der Idee ganz gut... Klippenland-Chroniken kenne ich nicht, allerdings habe ich als Kind gerne Spellbinder geschaut, was ja denke ich auch in die Richtung Steampunk geht https://www.youtube.com/watch?v=77KwqlTDj3M

Das Flugschiff ist ein Kostenloses Asset aus dem Unity Asset Store. Um die Dummy-Arbeiter (Würfel) gegen richtige Figuren auszutauschen werde ich mir das mal holen:
https://assetstore.unity.com/packages/3 ... ters-97186

Von der Zeit her spielt das Ganze entweder in der Zukunft oder in einem Paralleluniversum, da bleiben mir von den Grafiken her ja alle Möglichkeiten offen, so lange es halbwegs zusammen passt.
Ich denke das Inselleben wird Richtung Fantasy geht (Rohstoffe gewinnen usw.) aber die Flugeinheiten dann Richtung Steampunk. Mal sehen. Der Assetstore gibt jedenfalls unendlich viel her wenn man etwas sucht und man weiß gar nicht so recht in welche Richtung man gehen mag/soll... wenn ich da an die alten Zeiten zurück denk, wo man selbst erstellte "programmers art" Grafiken aus Paint als Platzhalter verwendet hat :D

https://assetstore.unity.com/packages/3 ... ol-1-37041
https://assetstore.unity.com/packages/3 ... ot-2-69977

[Chromanoid]

Hört sich super an. Vom Setting fände ich glaube ich eine postapokalyptische Zukunft cool. Dann kann man auch immer mal Teile und Maschinen der alten Welt aufsteigen lassen, die besondere Fähigkeiten verleihen. Das Konzept gefällt mir jedenfalls in vielen Brettspielen gut, z.B. Scythe oder Eclipse - und auch das Warhammer 40k Universum lebt ja teilweise von "Archeotech".

[LONy]

Ich bin gerade dabei das Einfangen der Inselteile zu Implementieren...

Warum nicht gleich eine ganze Insel an den Hacken nehmen :D

[LONy]

Ich habe am Baumenü gearbeitet. Es werden nun auch die Kosten aus der Datenbank geladen und angezeigt. Vom UI her bin ich momentan darauf beschränkt, dass ein Gebäude maximal 4 verschiedene Rohstoffarten kosten kann, aber ich denke das sollte genug sein.

Es gibt auch ein neues Gebäude, den Kran. Wenn man ein Inselteil an die Insel andocken möchte, muss man vorher am Rand einen Kran bauen. Der Kran übernimmt dann vom Crafter das Inselteil und muss es noch eine Zeit lang halten, bis das neue Teil mit der Insel verwachsen ist (die Funktionen muss ich aber noch implementieren). Danach kann der Kran wieder abgebaut werden und man bekommt einen Teil des benötigten Holzes zurück - so der Plan ;)

Momentan entwickel ich die Klasse zum Rohstoff-Kosten berechnen und zur Kommunikation der Rohstoffe zwischen Server und Client. Wenn das funktioniert hab ich eigentlich schon ein kleines "fertiges" spiel :)

Nun zu dem "eigentlich" - einerseits möchte ich möglichst früh einen Prototypen veröffentlichen, um User Feedback zu bekommen, den Bekanntheitsgrad zu steigern, evtl. Bugs aufzudecken usw. ABER umgedreht so lange das Spiel in einem so frühen Stadium der Entwicklung ist, nichts balanced ist und auch noch viele Inhalte fehlen muss ich wahrscheinlich mehrmals einen DB-Reset machen, das Spiel quasi neu starten, um zu sehen wie sich die neuen Features insgesamt integrieren. Als ich vor langer Zeit Zudos Stonequest mal angespielt habe und mit meinem Bruder einen großen Turm gebaut hab, war der Moment als er die Spielewelt reseten musste (Umstellung in der Datenbank oder so) sehr deprimierend... einem Alphatester ist zwar durchaus bewusst, dass es eine frühe Version des Spiels ist, aber wenn man in einem frühen Stadium schon "richtig" spielen kann, aber dann am Tag x der Spielfortschritt gelöscht wird, ist das doch ein Grund vielleicht nicht weiter zu spielen :/

Eine Möglichkeit wäre, einfach einen neuen Server zu starten wenn es eine neue Version mit größeren Änderungen gibt, und den Alten weiter laufen zu lassen... somit wäre der alte Spielerfolg nicht gelöscht und jeder kann sich selbst entscheiden einen neuen Account auf dem neuen Server mit neuen Features zu erstellen, die evtl. mit den alten Features nicht kompatibel sind?! - Habt ihr Ideen zu dem Thema?

[Schrompf]

Du machst Dir zuviel Gedanken. Du hast genau einen einzigen Release gegenüber der Öffentlichkeit, und das ist der Stand, den die Spielerinnen bewerten. Du kannst bis dahin aber ne Version auf itch.io anbieten. Solange Du dort deutlich hinschreibst, dass regelmäßig der Spielfortschritt gelöscht wird, sollte das kein Problem sein.

[marcgfx]

Ist halt eine Frage des Aufwands, aber eigentlich sollte es immer Möglich sein ein Update/Migration der DB vorzunehmen ohne einen kompletten Reset. Wenn du eine alte Version weiter laufen lässt, bekommst du halt auch kein neues Feedback. Wenn viel Arbeit verloren geht, verlierst du womöglich die Spieler. Oder du schaust halt, dass die Spiele sowieso kurz gehalten werden, bzw. max eine Woche dauern mit einem klaren Sieger und darauf immer der Reset erfolgt.

[LONy]

marcgfix, du arbeitest ja fleißig weiterhin an Devader... stellst du dann bei neuen Features einfach ein kostenloses Update zur Verfügung, für alle die dein Spiel z.B. bei Steam gekauft haben?

Der Spielverlauf soll bei mir stark an ein Browsergame angelehnt sein, also schon über einen längeren Zeitraum gehen. Ich könnte natürlich beim Release der "Version 1" diese so weit fertig stellen, dass man sie mit einem festen Ziel durchspielt... danach gibt es ein neues Release von "Version 2" mit weiteren Features, balancing usw. mit einer komplett neuen Runde.

Natürlich mach ich mir auch etwas Gedanken über Monetisierung. Das mit den Versionen hätte den Vorteil, dass ich die ersten Versionen die noch einen kleinen Funktionsumfang haben kostenlos anbiete... wer sich zu dieser Zeit schon einen Account holt hat glück und bekommt folgende Updates auf neue Versionen kostenlos.. ab Version x kostet das Spiel dann einen kleinen Betrag, der mit zunehmendem Funktionsumfang steigt. Ähnlich will es Tesla ja bei seinem Autopiloten machen, je mehr Features dieser hat, je teurer soll der Autopilot beim Kauf sein... wer ihn schon hat bekommt alle Updates kostenlos.

Als wir mal im Freundeskreis vor über 16 Jahren ein Browsergame entwickelt hatten, kamen wir auf ca. 2000 registrierte Spieler... Allerdings haben wir es nicht geschafft das Spiel zu Monetisieren und die 40€ Serverkosten monatlich gingen ganz schön ins Taschengeld bzw. später in den Azubi-Lohn. Wir wollten das ganze damals über Werbung finanzieren, allerdings immer wenn eine Auszahlschwelle überschritten war, haben sich die verschiedenen Anbieter unter verschiedenem Vorwand geweigert auszuzahlen. Einzig später Google adwords hat funktioniert, aber dabei kam nicht viel raus.

Bisher hab ich mich überhaupt nicht mit itch.io auseinander gesetzt... wird wohl mal Zeit :)

[xq]

Ich würde an deiner Stelle erst mal ein funktionierendes Spiel machen, und auf sowas wie "Early Access" oder ne offene "Beta" scheißen. Wenn du wirklich Spielerfeedback brauchst, denk über sowas wie ne "Closed Beta" nach, also die Leute müssen bei dir nachfragen, ob sie teilnehmen können und du kennst die Leute dann und kannst sie auch direkt auf sowas wie "Ich werd die Spielstände regelmäßig wipen" aufmerksam machen.

Bzgl. Monetarisierung: Ich bin mittlerweile eher der Meinung: "Lieber monatlich für ein Onlinespiel zahlen als Werbung zu haben oder irgendwelche Freemium-Scheiße". Und wenn du nur 2€ pro Spieler nimmst, damit hast du schon bei 15 Spielern die Monatskosten für nen Rootserver bei Hetzner gedeckt, der 16te Spieler deckt dann die Kosten für die Domain und was du mit dem Rest anstellst, ist dann die Frage ;)
Bezahlen sollte möglichst schmerzfrei und prepaid sein, also sowas wie Paysafecard, Paypal, opt-in monatliche Abbuchungen über $Service

Ansonsten: Geil, dass das Projekt voran geht, ich find die Idee mit dem "Inseln zusammenbauen" auch total geil. Je nach dem, wie sich das entwickelt hätte ich auf jeden Fall mal Lust, reinzuspielen,

[Chromanoid]

Du solltest vielleicht schon prüfen, wie viel Du für X Spieler an Serverkosten hinlegen musst und ggf. Dein Gameplay entsprechend anpassen. Ansonsten hast Du ein Spiel, dass sich nicht in dem Modus betreiben lässt, in dem Du das vorhast. Da lohnen sicher auch ein paar Benchmarks.

Ich kann mir kaum vorstellen, dass man da um Freemium herumkommt. Die Betriebskosten werden eine Herausforderung sein. genauso wie bei Deinem Browserspiel. Am besten wäre es wahrscheinlich, so viel auf "clientseitiges Berechnen", "unabhängig nebeneinanderher" und "Instanz-basiert" (in dieser Reihenfolge) wie möglich zu setzen.

Aber wenn alle auf einer Karte sind, ist das sicher nicht das, was Du Dir vorstellst. Die Gedanken, die man sich da bzgl. Gameplay machen muss, sind Dir ja sicher auch bekannt. Also so Sachen wie unterlegene/abwesende Spieler in der Umgebung "ernten" usw.

Ein Alternativvorschlag wäre, dass man mit der eigenen Insel umherfliegt und Begegnungen mit anderen Spielern anders als über eine gemeinsame Karte gesteuert werden. Der Kampf zwischen Inseln müsste dann auch eher ein asynchroner Kampf sein - so a'la Clash of Clans. Dann könntest Du sehr viel auf dem Client machen lassen und Interaktionspunkte zwischen Spielern wären minimal. Das macht den Betrieb viel skalierbarer. Ansonsten würde ich glaube ich auf ein recht brutales Spiel mit Permadeath setzen, so dass die meisten Inseln schnell dem Untergang geweiht sind. Sonst hast Du viel zu schnell ganz viele inaktive Inseln, die Du berechnen musst, die aber keiner mehr bespielt. Vielleicht kann man ja auch so eine Art "wenn Du Dich nicht nach X Tagen einloggst, zerfällt die Insel"-Mechanismus einbauen.

BTW https://store.steampowered.com/app/7186 ... c_Revival/ kennst Du?

[LONy]

Danke für Feedback und Input :)

Seit vorgestern bin ich auf itch.io registriert: https://lonytoon.itch.io/shardcraft

Die Serverkosten sind ja inzwischen sehr überschaubar... ich hab nen VServer bei Hetzner der deutlich günstiger ist als damals der Rootserver und wahrscheinlich dazu noch viel mehr Leistung hat. Beim Browsergame musste der Server mit PHP jede Seite die Angezeigt wurde vorher zusammen bauen und an den Client ausliefern... Dadurch das ich jetzt mit dem Client Backend und Frontend sauber getrennt habe, ist die Server Belastung hier schon mal deutlich geringer.
Alle Spielzustände müssen ja auch gar nicht synchronisiert werden - vieles kann man Faken und den Schein einer riesigen, zusammenhängenden Spielwelt erzeugen... Die Architektur ist momentan so ausgelegt, dass der Rechenaufwand weitestgehend linear mit der Anzahl der Spieler steigen sollte. Z.B. werden nur Einheiten, die sich gerade aktiv Bewegen berechnet. Erst nach einer gewissen Distanz prüft eine Einheit gegen alle beweglichen Einheiten auf dem Server, ob sie in der Nähe ist und ggf. eine Interaktion nötig ist. Auch wenn von einem Gebäude das Lager voll ist, hört der Arbeiter das Arbeiten auf. Es wird zwar automatisch geprüft, ob es wieder was zu tun gibt, die Reaktivierung könnte ich aber auch dem Spieler überlassen - die Auswirkung inaktiver Inseln hält sich in Grenzen.
Über Optimierung mach ich mir Gedanken, wenn sie nötig ist :D

Die Zeit, die ich für die Sinnvolle Implementierung von Werbung bräuchte, steck ich lieber in Spielinhalte... zumal schon sehr viele Spieler denk ich aktiv spielen müssen, dass da was rum kommt.. und ich hasse Werbung^^ Das Gamedesign will ich auch nicht darauf auslegen, dass ich mit irgend welchen Ingame Coins, die man für Echtgeld kaufen kann, irgend wie Umsatz mache.

Momentan ist das ganze ein reines Hobby Projekt, ich hab Spaß am Programmieren und Lernen neuer Technologien und wenn das Ganze am Ende ein Erfolg wird ist es um so besser ;)

Ob ich das Spiel im laufenden Betrieb weiter entwickle oder noch etwas Zeit investiere und einen späteren Release mit mehr Funktionen favorisiere muss ich noch sehen. Ein Freund von mir hatte Glück mit einer App und kann von den Einnahmen leben. Er hat mir den Tipp gegeben, so früh wie möglich zu veröffentlichen.

[LONy]

Ich hab mal die Textur der Tiles angepasst... die Grafik wirkt gleich ganz anders, allerdings stechen jetzt die Gebäude mehr hervor und ich bräuchte beim Platziern von Gebäuden entweder wieder ein Sechseck-Raster das ich Einblende oder ich müsste eine 3D Vorschau des Gebäudes anzeigen (was wahrscheinlich besser ist).

Um eine art Erd-Textur über die Gras-Textur zu blenden, nach welchem Begriff muss ich da suchen? Hab von Grafikprogrammierung bisher nicht wirklich viel Ahnung ;)

@Chromanoid Driftland The Magic Revival kenne ich nicht, allerdings wenn man danach sucht gibt es erstaunlich viele Spiele die die Idee mit dem Inselbau aufgreifen.