spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Tjoar, der Text ist jetzt laenger geworden als er sein sollte, ich nehms niemandem uebel wenn er das nicht alles Lesen will

Tag zusammen, nach laengerer Pause hab ich wieder eine neue Idee: Die wirkt auf den ersten Blick zwar ziemlich verreuckt, aber ich glaube dass das bei "Innovationen" immer der Fall ist:
Ein Multiplayer Point-and-Click-Adventure (Ihr wisst schon, sowas wie Monkey Island, aber fuer 2 Spieler)

Hier einige Details die mir eingefallen sind:
- Es soll ein lineares Adventure sein, also keine Moeglichkeit geben zu sterben oder in Dead-ends zu geraten.
- Zur Grafik: 2D, Hintergrund scrollt, animierte Sprites
- Das Spiel soll fuer 1 oder 2 Spieler ausgelegt sein. Es gibt 2 Charaktaere, im Singleplayer beide steuerbar, im Multiplayer uebernimmt jeder Spieler eine Figur.
- Die Charaktaere unterscheiden sich in ihren Faehigkeiten, so koennen bestimmte Raetsel nur von einem Spieler geloest werden, andere erfordern teamwork
- Jeder Spieler hat ein eigenes Inventar, aber die Items koennen ausgetauscht werden
- Beide Spieler koennen sich frei bewegen, und auch in unterschiedlichen "Screens" (die einzelnen Szenen in die ein Adventure unterteilt ist) sein - sollten sich aber nicht zu weit voneinander entfernen koennen.
- Wichtige Features: Man kann die Spielfigut TAUSCHEN, oder einfach den anderen BEOBACHTEN (der Bildschrim wechselt dann auf den des anderen Spielers)

Was ich jetzt von euch will Da ihr ja recht erfahren seid, koennetet ihr mich auf einige Probleme hinweisen auf die ich stossen werde, damit meine Planung nicht vollkommen in die falsche Richtung geht.
Ich hab auch noch keinerlei Erfahrung mit Netzwerk-Programmierung, aber ich glaube nicht dass DirectPlay sonderlich kompliziert sein wird. Verbinden wird man sich durch Eingabe der IP, ein Spieler fungiert dann als Host. Dieser muss dann wohl den gesamten Spielzustand verwalten, und uebernimmt auch das Speichern/Laden etc.

Und jetzt kommt noch mein groesstes Wagnis: Die Engine soll modular sein, also unabhaengig vom Spiel selbst. Mit andern Worten: Es sollen mehrere dieser Spiele auf die gleiche Art und Weise erstellt werden koennen. Am besten nicht nur von mir, sondern auch per Tools oder Scripts (hier wird glaub ich die Bedeutung von "Wagnis" klar)
Jetzt gibt es natuerlich mehrere Herangehensweisen:
1. Vielleicht kennt jemand von euch das Tool ScummVM, ein Emulator mit dem man alte LucasArts Adventures spielen kann. Sowas in der Art koennte ich mir auch vorstellen: Die Engine, bzw die Spieleumgebung ist eine einzige EXE-Datei, in der man dann das Spielmodul laden kann, eine Netzwerk-Verbindung aufbauen sowie Speichern und Laden kann. Ein Spiel selbst waere dann eine Sammlung von Scripts und Ressourcen und daher am einfachsten umzusetzen.
2. Wie 1. nur dass ein Spiel nicht aus Scripts besteht, sondern eine DLL ist. Also weniger Arbeit fuer mich, aber mehr beim Erstellen eines Spiels.
3. Ein System dass dem der Tribase aehnlich ist: Die Engine selbst ist eine DLL, das Spiel eine EXE. Ist zwar am einfachsten, aber ich glaube dass Verfahren ist relativ unflexibel.

Waer nicht schlecht wenn mir jemand Tipps geben kann. Oder einfach schreibt was er von der Idee haelt. Ich wuerde ungern meine Zeit in ein Projekt investieren, bei dem dann spaeter irgendwas unstimmig ist weil ich ein Detail uebersehen hab. Danke fuer's Lesen

Zitat von »"Nox"«

1. Schau mal ob LUA was für dich ist.

Ich hab schon mal was damit gemacht, aber halt nur von der Anwenderseite aus. Keine schlechte Idee, das hiesse also Methode 1: Eine Umgebung in die dann Spiele geladen werden die mit LUA gescriptet sind oder?
Ich tendiere im Moment auch zu dieser Methode, da fuer ein Spiel nichts kompiliert werden muss. Das ist ein immenser Vorteil, vielleicht koennen dann auch andere solche Spiele basteln (*trauem*)

Zitat von »"Nox"«

DirectPlay wurde abgesägt und sollte nicht mehr genutzt werden.

Alternative? WinSock?

Zitat von »"DarkRaider"«

Ein lineares Multiplayer Point and Click Adventure? Ich würde sagen das ist
nicht soo mein Geschmack. Habe früher auf den Super Nintendo eher
Secret of Mana gespielt, sprich RPG's. Die Multiplayer zu zocken, war einfach
der Hammer. Aber RPG's sind nunmal kein Zuckerschlecken, gerade RPG's,
die auch richtig Stil haben. Das ist wahrscheinlich auch der Grund, warum es
keine wirklich guten Freeware RPG's in 2D mehr gibt.

Naja, aber die gibts doch inzwischen zu genuege. Klar, ich bin auch ein grosser RPG-Fan, aber irgendwas "Neues" sollte ein Spiel schon haben. Da ich noch nie sowas wie ein MPPNC gesehen habe, koennte das intressant werden. <= guck mal da, ich habe soeben ein neues Genre benannt, das macht ja schon Spass bevor man ueberhaupt anfaengt :lol:

Zitat von »"DarkRaider"«

Ansonsten: Viel Glück dabei, ich denke mal, man bekommt alles hin, solange
man das durchzieht, was man vor hat. Habe bisher kein Game, dass ich mit
C++ schreiben wollte gecanceled. Hoffe du gehörst auch zu den Leuten,
die ihre Dinge auch wirklich durchziehen, wenn sie es sich in den Kopf setzen.
Freue mich schon auf die ersten Screens.

Ich hab das Ganze mal realistisch auf 1 Jahr Entwicklungszeit eingeschaetzt. Ohne Spiel-Module.

So, auch wenns nur langsam mit der Planung vorran geht (nur am Wochenende :/) hab ich ein paar elementare Fragen. Hier ein Teil meiner Planung:

Ein Spielstand besteht zum Grossteil nur aus einer Ansammlung von gesetzen Variablen. Da diese dynamisch (daher aus Scripts und zur Laufzeit) gesetzt werden koennen sollen, dachte ich an eine Map, die den Variablennamen einem beliebigen Wert zuordnet.
Ich will natuerlich alle Strings irgendwie einheitlich verwalten, und da hab ich auch schon die erste Frage: Einige hier bekommen ja schon Zustaende wenn sie "ASCII" hoeren und Unicode scheint sich doch immer weiter in den Vordergrund zu draengen, ABER: Jede Form von Text die in dem Spiel speater dargestellt wird basiert auf Bitmap-Fonts, daher kann ich nichtmal alle ASCII-Zeichen verwenden, geschweige denn einen UNICODE-Zeichensatz. Ergo: Speicherverschwendung. Normalwerweise minimal und nicht der Beachtung wert, aber da das Spiel ja einen Multiplayer hat, muss ich nicht selten die gesamte Map mitsamt allen Strings per Netz versenden. Und wenn dann, sagen wir mal, 1000 Strings a 10 Zeichen gesetzt wurden ist der Unterschied von 10 KB schon zu bedenken, oder?
Ausserdem hab ich mir mal ein paar Gedanken zur Netzwerkkommunikation gemacht, ohne wirklich irgend eine Ahnung davon zu haben. Ich hab's mal mit Paint dargestellt <Link> und frage mich ob das ganze so funktionieren kann:
Der Server ist gleichzeitig einer der Spieler. Daher hat er direkte Kontrolle uber den Sever- oder Masterspielzustand. Der Client kann zwar seinen eigenen Clientzustand selber aendern, aber in regelmaessigen Abstaenden wird er mit dem Master-Zustand des Servers ueberschrieben. Daher muss ein Event des Clients nicht nur lokal verarbeitet werden, sondern auch an den Server geschickt werden.
Koennte das im Groben so ablaufen ?
(Am besten ich mache erst mal ein Multiplayer-Pong um mit Netzwerkprogrammierung vertraut zu werden. Kennt jemand ein gutes Tutorial ?)

Dann noch zur Scriptsprache: Ich hab mal eine Liste erstellt auf der die Anforderungen die ich an die Sprache stelle aufgelistet sind. Groesstenteils sind das einfache Befehle, das Setzen und Abfragen von Variablen, etc. Sowas wie Schleifen oder gar Funktionen brauch ich nicht wirklich. Jetzt stellt sich die Frage ob man das nicht einfacher selbst machen kann bzw. in wie fern ich meine eingenen Befehle mit LUA verbinden kann. Koennte ein LUA Script beispielsweise so aussehen ?

Ich kann mir halt schlecht vorstellen wie solch ein LUA-Code eingebunden wird und in wie fern ich den selber parsen muss/kann.
Danke fuers Lesen

DigitalDream
Danke fuer die ausfuehrliche Hilfe, auch wenn's im Moment etwas langsam vorran geht bin ich immernoch dran - ist halt ein Langzeitprojekt.

Zitat von »"DigitalDream"«

Werd dir darüber klar,was z.B deine Kommunikationsschicht genau können muss?
Es muss eine zentrale Komponente geben,die Player 1 oder Player2 abfragen kann,welche Objekte jemand hat etc..
Die selbe Komponente kannst du auch für Rätsel verwenden.
Für erfüllte Bedingungsabfragen etc..

Ja, und wie ich merke ist das Planen auch der hauptsaechliche Part beim Programmieren groesserer Projekte, ich hab schon fast einen ganzen Block vollgekritzelt, mit Dateiformaten, Objekten und sogar UML-Diagrammen

Zitat von »"DigitalDream"«

Bei grafischen Ansprüchen wird die meiste Zeit immer dafür draufgehen.
Da hast du schon mal einen Vorteil,da du wohl sprites einsetzen willst.
Wenn du mehr willst,kann ich dir zu Backdropimages raten.
Da kann man gut mit Tiefen tricksen und 3D Figuren drin bewegen lassen.

Also, fuer die Grafik hab ich mir schon ein wenig Hilfe organisiert. Diese "Hilfe" reduziert sich jedoch auf einen Zeichner, der nicht sonderlich viel Ahnung von Bildbearbeitung oder sogar Gamedev. hat. Ich hab mir das so gedacht dass ich ihm Spritevorlagen gebe, die ich dann weiterverarbeite. Zu Backdropimages hab ich nicht viel gefunden, hast du vielleicht einen Link fuer mich ?

Zitat von »"DigitalDream"«

Zitat

Jetzt gibt es natuerlich mehrere Herangehensweisen:
1. Vielleicht kennt jemand von euch das Tool ScummVM, ein Emulator mit dem man alte LucasArts Adventures spielen kann. Sowas in der Art koennte ich mir auch vorstellen: Die Engine, bzw die Spieleumgebung ist eine einzige EXE-Datei, in der man dann das Spielmodul laden kann, eine Netzwerk-Verbindung aufbauen sowie Speichern und Laden kann. Ein Spiel selbst waere dann eine Sammlung von Scripts und Ressourcen und daher am einfachsten umzusetzen.

Du solltest nicht etwas auswählen,was es dir am einfachsten macht.
Sondern das einsetzen ,oder erstmal entwickeln was du wirklich brauchst.
Dazu ist es sehr wichtig,dass du genau planst was du überhaupt willst.
Lieber die Zeit richtig investieren als später von irgendeinem Schrott abhängig zu sein,der nur auf den ersten Blick nach dem richtigen aussah...

Das 'einfach' bezog sich hier nicht auf die Arbeit die ich mir mache. Eine Option die ich in Betracht gezogen habe war, eine Umgebung zu programmieren, mit der man eben solche Spiele erstellen kann, nur mit Tools und einfachen Lua-Scripts. DIESES erstellen sollte natuerlich moeglichst simpel sein, damit ich nicht der einzige bin der damit arbeiten kann.

Eine Ebene weiter hiesse dann, dass das Spiel selbst aus C++-Code besteht, und in welcher Form auch immer kompiliert werden muss. Damit waer die Idee einer modularen Umgebung futsch, allerdings waere das Spiel selbst flexibler (ich hoffe das ist verstaendlich formuliert)

Und dann waere da noch diese sehr wichtige, allgemeine Frage zur Planung offen: Ist das "ok" wenn ich die gesamte Spiellogik per String-identifier ablaufen lasse? In der Praxis heisst dass:
- (Spiel-)Varaiblen werden in Form ihres Names gespeichert.
- Ein Event z.B. wird auch per Name aufgerufen.
- Die meisten Befehle sind ebenfalls Strings die in den Scripts stehen und zur Laufzeit geparsed werden muessen
Ich befuerchte dass das ganz schoen Performace schlucken wird, aber anders kann ich mir nicht vorstellen soetwas Spiel-unabhaengig zu realisieren.