spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hi

Die 1. Idee ist schon anspruchsvoll. Doch die 2. Idee ist nochmal DEUTLICH umfangreicher/schwieriger zum umsetzen!

Zum einen, Multiplayer Spiele welche nicht so entkoppelt sind wie z.B. ein "Bauernhof Aufbauspiel" , sondern deutlich mehr richtung "Echtzeit Multiplayer" gehen (pro Sekunde mehrfache Datenübertragungen pro Spieler) und kurze Latenzen benötigen weil es z.B. mit Ping 150 unspielbar wäre, sind schon anspruchsvoll zu programmieren. Bei diesem Level wärst du also etwa mit der 1. Idee. bei der 2. Idee kommt aber zusätzlich noch dazu (was ich vermute, in welche Richtung du willst...):

- Ein persistenter Server damit auch der Spielvortschritt der Spieler erhalten bleibt, wenn sie sich Heute ausloggen und morgen dann ihren Char weiter "Leveln" wollen.

- Avatar "individuell" anpassen z.B. durch Kleidung, Haare etc. .. ist auch schwierig (an sowas kämpfe ich selber seit paar Monaten -> Problem das mit den Animationen in einklang zu bringen).

- Handel, ist auch recht komplex. Alleine schon ein Singleplayer Handelssystem mit NPC's kann schon paar Monate Aufwand sein.. und im Multiplayer muss dann auch noch ständog alles zwischen Server und den Clients syncronisiert werden. Und dabei muss man sehr auf kleine Datenstrukturen achten, damit nicht die nötige Bandbreite (Daten pro Sekunde pro Spieler) zu viel wird -> Wird sonst bei den Spieler ruckeln, und das Serverhosting wird teuer.

- Beim Shooter reicht sowas wie ein "Globaler Chat" und Thema Komunikation ist erledigt. Mehrsprachig kümmert dich hier kaum. Doch bei deiner 2. Idee, wirst du vermutlich eher in die Richtung eines Ausgewachsenen Dialog-Systems gehen wollen? Mehrsprachig? => Alle Dialoge übersetzen... und ein Mehrsprachensystem basteln (Stichwort i18n).

- Bei der 2. Idee, denkst du (unbewusst) auch an Quests, oder? => Quest System ... NPS's... Dialoge mit NPC'S ... sollen die Quests auch noch dynamisch sein bzw. leichte zufallsvariation? ... und dann bei einem Multiplayer Spiel, muss das dann auch noch alles über den Server laufen und gesynct werden ..... du ahnst sicher wie Aufwändig alleine schon so ein Quest System wäre ;-)

- Multiplayer bei der immer alle Spieler gleichzeitig auf der gleichen Map sind (Counter Strike, Battlefield etc.) sind die eine Sache. Das kann man noch so mit den normalen Mittel umsetzen. Aber, wenn die Spieler die auf dem Server gleichzeitig spielen, sich auf unterschiedlichen Maps aufhalten können (Spieler A und B, sind im "Dunklen Wald", Spieler C im "Dungen der Temptress" und die restlichen Spieler z.B. Am Markt bei den Händlern)... also ich meine mit unterschiedliche Maps, in Unity in unterschiedlichen Scenen. ... dann ist das nichtmehr mit den Hausmitteln irgendeiner Engine (egal ob Unity oder eine beliebig andere) zu machen.
z.B. musst du dann für viele Probleme, Lösungen finden die bei einer einzigen Scene ganz einfach wären, aber dann bei so einem Server für mehrere Scenen, riesen Probleme verursachen... -> z.B. kann dann der Server nichtmehr so einfach die Physik und Treffer (hast der Schuss aus der AK47 / schwung mit der Axt, nun den anderen Spieler getroffen oder nicht?) vom Server entscheiden lassen. Stichwort "Persistente Welt" (nochmal ganz andere Hausnummer als "nur" Persistenter Server). Glaub mir, da steckt echt viel Programmierarbeit dahinter!
Doch so wie ich dich verstanden habe, willst du wohl bei der 2. Idee, vermutlich genau solche verschiedenen "Orte" zu denen die Spieler auch voneinander unabhängig hin können?


Da ich gerade an einer Steuerung bastle, ähnlich wie in Skyrim, und mir sehr mühe gebe dass sie so wird dass ich dann letztlich sie als möglichst angenehm aber auch einigermassen RP tauglich empfinde... Habe ich aus eigeninteresse aber auch eine Frage :-D
Was ganz genau ist ein ConcJump? Und was empfindest du als angenehme Shooter Steuerung? (du hast was geschrieben bezüglich fehlen der "spassigen Sachen" ?)