Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

xardias

Community-Fossil

Beiträge: 2 731

Wohnort: Santa Clara, CA

Beruf: Software Engineer

  • Private Nachricht senden

21

09.01.2009, 10:32

Zur Motivation lese ich gerade ein interessantes E-Book:
http://www.wishfulthinking.co.uk/2009/01/05/how-to-motivate-creative-people/

Dürfte für solche Projekte auch sehr interessant sein. Ansonsten dürfte The Dip von Seth Godin da auch recht informativ sein. Das was er beschreibt ist denke ich Grund Nummer 1 warum so viele Projekte in die Brüche gehen.

Achja: Je nachdem wie groß dein Projekt angelegt sein soll. Für die erste Zeit reicht ein einfacher Root Server (z.b. bei Hetzner für 50 Euro). Je nach Spiel kann so ein einzelner Server auch einige Hundert Spieler bedienen.
Das kommt natürlich letztendlich auf die Last an die ein Spieler erzeugt. Aber gerade in Spielen wie WOW ist die Interaktion mit dem Server sehr gering im Vergleich zu Ego Shootern oder Strategiespielen.
D.h. so hoch sind die Kosten nicht so lange das Spiel nicht zum vollen Erfolg wird und euch tausende Spieler die Bude einrennen ;)

Edit: Meine Güte meine Zeichensetzung ist mal wieder fürn A***. Hier zum selbst einfügen: ..,,..,,,

DasBlub

Alter Hase

Beiträge: 802

Wohnort: Schweiz

Beruf: Programmierer

  • Private Nachricht senden

22

09.01.2009, 10:41

Zitat von »"xardias"«


Das kommt natürlich letztendlich auf die Last an die ein Spieler erzeugt. Aber gerade in Spielen wie WOW ist die Interaktion mit dem Server sehr gering im Vergleich zu Ego Shootern oder Strategiespielen.


einspruch! bei wow wird ALLES auf dem server berechnet (glaub mir, ich weiss es, ich schreib ja selber dran mit ;)). wir haben momentan 2 rootserver, einen für die datenbank, mit dualcore und ca. 4gb ram und einen mit quadcore und 8gb ram. die dinger kosten einiges pro monat (kenn den preis nicht) und wir haben knapp 700-800 spieler online in lastzeiten (wochenende, abends), da fängts dann schon mal an zu laggen (was aber auch an problemen mit dem multithreading liegt welche momentan bestehen :/).
bei einem mmorpg berechnest du alles auf dem server wenn du nicht willst, dass dir ein spieler mit einem clienthack alles versauen kann. beispiel: wenn der client die spielerbewegungen berechnet und dem server schickt kann der client ja manipuliert werden und einfach eine viel grössere strecke schicken -> speedhack (nur als beispiel).
auf dem server musst du die ganze welt berechnen, du musst alle kreaturen bewegen. wenn du dann merkst, dass du damit zuviel cpu verbrauchst fängst du dann an, ein dynamisches grid-ladesystem zu implementieren, dass die map nochmals unterteilt und immer nur die teile im speicher hält, in denen es gerade spieler hat. aus lastgründen wirst du multithreading (und evtl. multiprocessing) benutzen was zur folge hat, dass du extrem darauf achten musst, die threads richtig zu locken, sonst greifen z.b. threads auf kreaturen oder maps zu, die gar nicht geladen sind...

nur so als kleine hinweise ;)

Beneroth

Alter Hase

Beiträge: 969

Wohnort: Schweiz

Beruf: Software Entwickler

  • Private Nachricht senden

23

09.01.2009, 10:57

DasBlub:
Das ist richtig, aber das ist normalerweise auch bei Shootern oder Strategiespielen so, dagegen hat ein übliches MMORGP vermutlich eher weniger zu überprüfen und berechnen in kurzer Zeit.

Mangos ist gut aber vermutlich nicht ganz so optimiert wie Blizzards Implementierung, oder? ;)

24

09.01.2009, 11:03

Warum sollte ein übliches MMORPG weniger zu berechnen haben? Die KI mag zwar nicht so aufwändig sein (wenn man sie im Multiplayer zulässt), aber wenn du dann mehrere hundert Spieler hast und alle Bewegungen überprüft werden müssen, dann wird das wahrscheinlich aufwändiger als eine KI sein.

Beneroth

Alter Hase

Beiträge: 969

Wohnort: Schweiz

Beruf: Software Entwickler

  • Private Nachricht senden

25

09.01.2009, 11:07

mehr != schwieriger -> skalierung...

Bei MMORGPS fällt nicht sehr viel weniger an, aber sicher weniger.
MMORGPS sind auch meistens nur 2D (Spiellogik, nicht Grafik), Shooter meistens 3D.

Bei shootern müssen Geschosse berechnet werden, wird bei MMORPGS selten gemacht (kenne keines das das macht)

Neben Bewegung kommt da ja nur noch den Skill den du gerade gedrückt hast und deren Ziel.

DasBlub

Alter Hase

Beiträge: 802

Wohnort: Schweiz

Beruf: Programmierer

  • Private Nachricht senden

26

09.01.2009, 12:18

beneroth: wow berechnet geschosse, wenn du die vmaps an hast (fressen viel ressourcen :/) dann kannst du nicht mehr durch ecken durch schiessen, dann wird das berechnet.
und wow ist auch 3d...
und wegen der optimierung: natürlich nicht... mangos verdient ja auch nicht ein paar millionen im monat... :roll:

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

27

09.01.2009, 13:47

zum Thema Optimierung:

Zitat

ein dynamisches grid-ladesystem zu implementieren, dass die map nochmals unterteilt und immer nur die teile im speicher hält, in denen es gerade spieler hat


Interessante Idee, aber meiner Meinung nach eigentlich genau in die falsche Richtung, denn ihr macht euch zu Nutze, dass ihr Teile auslassen könnt, wenn wenig Spieler on sind. Wenn also viele Spieler on sind, habt ihr einerseits fast alle Kreaturen geladen und andererseits auch noch die Spieler!
Das ist so die Logik "unser Server wird schneller je weniger Spieler on sind". Durchaus nett nur eben Nachteilhaft, wenn man dann doch mal mehr Spieler hat ;) . Ihr habt doch sicher einen der mit einem Profiler umgehen kann, oder?
Der soll sich da mal dran setzen. Hat mir auch sehr geholfen bei dem Netzwerkprojekt. Gut das macht dann bei 1000 Testclients und nen paar 100000 Elementen dicht, aber das nur weil die Iteratoren von std:: so "langsam" sind auf Grund des _Has_container Aufrufs der Iteratoren (macht über 30% der Leistung aus).
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

DasBlub

Alter Hase

Beiträge: 802

Wohnort: Schweiz

Beruf: Programmierer

  • Private Nachricht senden

28

09.01.2009, 14:16

das ist nicht von mir, das wurde schon vor längerer zeit entwickelt ;)

und die überlegung ist einfach die, dass kleinere server mit weniger user auch weniger leistung haben -> man lädt weniger. liegt halt einfach daran, dass du sonst immer für jedes viech die update() methode ausführen müsstest...
und noch was: bei dem projekt arbeiten einige der genialsten opensource entwickler daran mit, die nützen jede möglichkeit aus um das ding schneller zu machen, die kratzen teilweise noch extra 2 zeilen generierten assemblercode raus nur um zu beweisen, dass die andere möglichkeit schneller wäre, was danach wieder zu einer performanceerhöhung führt ;)
noch was: wenn ein server unter last läuft (500+ user) dann ist die cpu über 90%, ab 1000 leute 100% (ohne db server) ;)

und ich hab noch nie mit einem profiler gearbeitet :oops:

29

09.01.2009, 14:26

MMORPG sind schon FETT, den Fehler machen viele zu denken ach das Ding ist nix, lol wenn das so einfach nur sein würde*schnüff* überlegt euch mal was der server alles leisten muss ..... alleine bei RF Online, oder garnicht erst mal anfange wow, die Koreaner legen verdammmmmmt viel arbeit in Details, was den Server ziemlich belastet, man merkt es wenn man in der HQ (Zentralle steht) und 100 Spieler einer Rasse sich Buffen. OMG .....
Dazu kommen dann noch 100 Spieler der einen und nochmal 100 Spieler der anderen Rasse, jede Rasse hat ihre eigenen Buffs mit Animation, dann die Tiere, u.s.w. dazu dann diese vielen Details die in diesen Spielen sind, das haut einem fast um und das muss alles berechnet werden.
Dazu kommen noch die Minen und das die Wirtschafts Programme, wer RF Online mal getestet hat, weis was die da reinhauen, das gilt für viele der Spiele aus Korea, die haben oft dinge darin, da würde keiner drauf kommen, alleine schon Kirschblüten die ins Wasser fallen und vom Berg zum Tal mit schwimmen, ver schaut den auf so Dinge wenn er Monster töten muss. Die Monster KI ist zum teil auch nicht so leicht, so rennen die Monster dem Spieler doch echt solange nach bis der tot ist, oder sie, verlieren sie ihn aus den Augen rennen sie selbständig zurück und greifen nebenbei die anderen Spieler an, wenn sie Agro Monster sind, sonst laufen sie einfach nach Hause zur Herde. Stell ich mir schwer vor das alles muss ja berechnet werden.


"Wer Rechtschreibfehler findet, kann sie behalten, ich hab genug davon"
Account wurde gelöscht

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

30

09.01.2009, 15:08

Das wovon du redest ist alles Clientseitig bzw. die Aggro ist sehr einfach zu realisieren (einfach Abstand in ner Formel mit Aggromenge und Leveldifferenz und gut ist).
Das Problem ist viel mehr, die Algorithmen so zu gestalten, dass sie wirklich gut skalierbar sind. Da fängt das Problem nämlich an. Wie kann man verschiedene Bereiche möglichst unabhängig voneinander gestalten, so dass nicht zu viel synchronisiert werden muss, aber dennoch nicht der Eindruck entsteht, dass die Spielwelt irgendwo klare Grenzen hat.
Denn was bringen einem 32 Kerne, wenn sie ständig aufeinander warten müssen. Ich habe testweise auch mal eine CAS-Queue entwickelt, da diese ohne Locks auskommt, aber leider wird dabei der Cache der Kerne synchronisiert und im Endeffekt war die von mir entwickelte Queue langsamer als eine normale std::list mit einer CriticalSection (das war ein emotionaler Tiefpunkt).
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Werbeanzeige