nicht angemeldet
Struppi
Struppi
Struppi
Struppi
Hallo,
ich wollte in meinem Browsergame eine Art "Engine" ausführen lassen. Diese soll alle paar Sekunden Aktionen ausführen (bewegen von Computerspielern etc.).
Nun habe ich drei Möglichkeiten ausprobiert:
1. Der eingeloggte Spieler mit der kleinsten ID führt die automatisch über Refresh alle 1.5 sec aus. Das hat zur Folge, dass dieser Spieler nicht so schnell spielen kann...
2. Ein CronJob führt jede Minute ein Skript aus. Nachteil hierbei: Langweilig, denn z.B. jeder Computerspieler bewegt sich nur jede Minute, wenn überhaupt.
3. Ein CronJob führt ein Skript aus, das 60 sec läuft und immer wieder die "Engine" ausführt. Hierbei wird der Server nach einiger Zeit sehr langsam.
Wie unschwer festzustellen ist, ist das alles nicht ganz das Wahre.
Meine Frage nun: Gibt es eine alternative Möglichkeit, so etwas zu realisieren?
Meine Idee wäre nur noch, dass (wegen Chat-Aktualisierung sowieso vorhanden) jeder Spieler alle 1.5 sec eine Seite über XMLHttpRequest ausführt, jedoch nur, wenn die letzte globale Aktualisierung der Engine 1.5 Sekunden zurückliegt. Dies hätte zur Folge, dass bei jedem Reload ein anderer Spieler belastet wird. Aber was, wenn zwei Spieler genau zur gleichen Zeit aktualisieren...?
Ich bedanke mich schon einmal für das Lesen meines ja nicht ganz kurzen Beitrages.
Für Rückfragen stehe ich jederzeit zur Verfügung,
Phaltôn
Moin Moin!
Meine Frage nun: Gibt es eine alternative Möglichkeit, so etwas zu realisieren?
Ein permanent laufender Server, der sich -- meinetwegen multithreaded -- um die gesamte Spiellogik kümmert. Ein CGI oder eine sonstige Verbindung, die HTTP-Requests vom Webserver annimmt und in Spielanfragen für den Spielserver umsetzt. Der antwortet mit einer Spielantwort, das CGI oder Equivalent reicht das per Webserver zurück an den Browser.
Solltest Du zufällig die FastCGI-Schnittstelle nutzen, hast Du schon einen permanent laufenden Server -- nämlich Dein FastCGI-Script. Das sitzt in aller Regel in einer select(2)-Schleife und wartet auf Arbeit vom Webserver. So lange könnte es auch Spielstände aktualisieren. Du könntest das Script auch vor der select()-Schleife in zwei Threads aufteilen, von denen der eine FastCGI implementiert und der andere Hintergrund-Jobs erledigt.
Alexander
Yerf!
Meine Frage nun: Gibt es eine alternative Möglichkeit, so etwas zu realisieren?
Wie wäre es einfach ein Programm dauernd in einer Schleife laufen zu lassen und mit einem Sleep die Pausen zu realisieren? Vortgeschrittene Programmierung wäre dann ein Dauer-Sleep und Kommunikation über Signale, wann etwas zu berechnen wäre...
Gruß,
Harlequin
Hello,
das eine ist doch wohl der Prozess, den Du auf dem Host laufen lässt, das andere ist der Client, mit dem Du damit kommunizierst und das Dritte ist das Protokoll, über das Du das bewerkstelligen willst.
Welches Host-OS verwendest Du?
Welche Programmiersprachen stehen Dir dafür zur Verfügung?
Welche Zugriffsrechte hast Du für den Host?
Gibt es schon einen Server auf dem Host, der mit dem Client kommuniziert?
Soll es einen eigenen Server für das Spiel geben (bitte nicht verwechseln mit HTTP-Server)?
Welchen Client willst Du verwenden? -> Browser
Welche PlugIns willst Du dafür voraussetzen?
Welches Protokoll willst Du benutzen -> HTTP (schon Scheiße)
Vermutlich wird es auf Flash mit dynamischer Datenbindung hinauslaufen müssen, da es weit verbreitet ist, die Sicherheitslücken darin den Leuten komischerweise egal sind, jeder es haben will und es sogar funktioniert.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Also:
Tom:
1. Mein OS heißt VPS openSUSE 10.1 Professional inkl. Plesk 8.1.
2. Ich weiß nicht genau, wie du das meinst, also PHP natürlich... Aber vielleicht hilft es dir weiter, wenn ich sage, dass ich einen Strato V-Server habe?
3. Ich hab zumindest Zugriff auf alle meine Dateien.
4. Vielleicht hab ich mich falsch ausgedrückt... Es soll ein Browsergame sein, damit gibt es eine Seite als Client. Und einen Hoster (DB) als Server... Dabei will ich eben was im Spiel aktualisieren, was nur durch Aufrufen des PHP-Skripts zu realisieren wäre (oder ich müsste meine ewig lange Datei in eine andere Sprache umschreiben...).
5. Also am liebsten wäre mir nur JavaScrupt, das würde am wenigsten Aufwand bedeuten und am schnellsten gehen.
Harlequin:
Hm, also meinst du eine ausführbare Datei oder ein Linux-Skript?
AN sowas hatte ich auch schon gedacht, aber das Problem ist, wie bring ich dieses Skript dann dazu, ewig zu laufen? Sobald ich die Konsole schließe, werden da nicht alle Aktionen beendet?
Und außerdem, würd das nicht den Server belasten?
Alexander:
Öhm, ok... Tut mir Leid, ich verstehe zwar viel von PHP, aber nicht so viel bis gar nichts von FastCGI. Aber soweit ich das verstanden habe, müsste man das einrichten, und dann doch über ein Skript aufrufen, oder?
Da bliebe doch wieder das Problem...
Bitte entschuldigt meine Unwissenheit. =D
Ich hätte jedenfalls nicht gedacht, dass es so kompliziert werden kann.
Ich werde jedoch versuchen, euch zu folgen...
Vielen Dank!
Gruß,
Felix
Yerf!
Hm, also meinst du eine ausführbare Datei oder ein Linux-Skript?
Im Prinzip egal, so ein programm sollte auch mit PHP (direkt gestartet, nicht über Webserver) möglich sein.
AN sowas hatte ich auch schon gedacht, aber das Problem ist, wie bring ich dieses Skript dann dazu, ewig zu laufen? Sobald ich die Konsole schließe, werden da nicht alle Aktionen beendet?
Du bräuchtest dafür auf jeden fall die Möglichkeit einen Hintergrundprozess zu starten (so wie es z.B. auch der Apache oder andere Server sind)
Und außerdem, würd das nicht den Server belasten?
Nein, nur wenn das Programm etwas berechnet. Während des sleep verbraucht es exakt 0 Prozessorlast.
Ist aber möglicherweise nicht so ohne weiteres auf deinem Server realisierbar. Dann bleibt wohl nur ein Merken, wann etwas geschehen soll und bei jedem Aufruf eines Users in der DB schauen, was noch zu erledigen ist. Das sollte ja ausreichen, da man keinen Unterschied sieht, ob etwas zum exakten Zeitpunkt ausgeführt wurde oder später bei einem Request nachträglich. Denn solange kein Request war hat auch keiner etwas gesehen...
Gruß,
Harlequin
Ich weiß nicht genau, wie ich einen Hintergrundprozess starten soll.
Ich hab schon überlegt, ein C++-Skript zu schreiben, und das dann zu kompilieren (GCC z.B.). Dumm dabei ist nur, dass GCC nicht installiert ist und ich es auch nicht installiert bekomme. Wahrscheinlich war der Ansatz sowieso falsch...
Nein, ich muss dieses Skript alle paar Sekuden ausführen, da es um komplizierte Brechnungen geht, die von der Refresh-Zeit abhängen.
Wie schon gesagt, sonst müsste ein Benutzer alles tragen... Das wäre aber ziemlich blöd für den. =D
Hello,
Ich hab schon überlegt, ein C++-Skript zu schreiben, und das dann zu kompilieren (GCC z.B.). Dumm dabei ist nur, dass GCC nicht installiert ist und ich es auch nicht installiert bekomme.
Welche Server-Distribution hast Du denn?
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Ich hoffe, du meinst das^^
VPS openSUSE 10.1 Professional inkl. Plesk 8.1
Hello,
Ich hoffe, du meinst das
VPS openSUSE 10.1 Professional inkl. Plesk 8.1
Ja, das meinte ich.
Welche rechte hast Du auf dem Host?
Es gibt da ein nettes Forum http://www.linux-club.de/
Ich habe es selber noch nicht ausprobiert, aber mein Kollege meinte heute Morgen, als er las, wie ich hier wegen Fragen zu Servern usw. angebombt worden bin, dass das Forum "nicht so affig" sei.
Sind seine Worte.
Ich bin eigentlich eher eine treue Seele, aber bevor es Dir nachher genauso geht wie mir ...
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
So ziemlich alle Rechte...
Vielleicht wechseln wir lieber auf den anderen Unterthread^^ Ich sag sonst alles doppelt...
Ah, danke für den Link. SIeht sehr gut aus, vor allem, weil es nur für Linux-Server ist und ein eigenes Unterforum für Plesk-Server hat.
Mal sehen, vielleicht verlagere ich das ganze später lieber dorthin als hier...
[...also ganz ehrlich gesagt finde ich dieses Forum schlecht strukturiert...]
[...also ganz ehrlich gesagt finde ich dieses Forum schlecht strukturiert...]
Das hört man öfters, aber wie hättest du es gerne?
Stell dir vor wie dein Thread jetzt aussähe in einem der üblichen Boards, du hättest einen Strang von Antworten untereinander, zwischendurch mal eine von dir und keiner wüßte wer was zu wem gesagt hat, daher halte ich diese Struktur für die übersichlichste die Möglich ist, allerdings hab ich in meiner perösnlichen Ansicht (die du nach dem anmelden dir einstellen kannst) noch ein bisschen Feintuning gemacht.
Der Vorteil liegt eben daran, dass du in verschiedenen Strängen über verschiedenen Teilaspekte eines Themas diskutieren kannst.
Struppi.
Hi,
ich weiß sehr wohl die Vorteile dieser Struktur zu schätzen. Doch wie wäre es, wenn alle Nachrichten immer unten zu sehen wären (also ich meine den Nachrichtenbaum). Momentan sind ja nur die der tieferen und der aktuellen Ebene sichtbar.
DAS empfand ich als unstrukturiert...
Außerdem... Wie wäre es, wenn die Themen nach der Zeit des letzten Beitrags geordnet werden würden?
ich weiß sehr wohl die Vorteile dieser Struktur zu schätzen. Doch wie wäre es, wenn alle Nachrichten immer unten zu sehen wären (also ich meine den Nachrichtenbaum). Momentan sind ja nur die der tieferen und der aktuellen Ebene sichtbar.
DAS empfand ich als unstrukturiert...Außerdem... Wie wäre es, wenn die Themen nach der Zeit des letzten Beitrags geordnet werden würden?
Ja, so hab ich das bei mir eingestellt. Mag sein dass die default Einstellungen nicht so glücklich sind, aber die Möglichkeiten es zu verbessern sind gegeben.
Struppi.
OK, in Ordnung...
Nach dem Anmelden kann man das umstellen?
Nach dem Anmelden kann man das umstellen?
Ja, wenn ich dich richtig verstanden habe.
wenn alle Nachrichten immer unten zu sehen wären (also ich meine den Nachrichtenbaum).
Das geht auf jeden Fall.
Wie wäre es, wenn die Themen nach der Zeit des letzten Beitrags geordnet werden würden?
Das kann man in den Benutzereinstellungen auch auswählen.
Struppi.
OK, tut mir Leid, ich hab das hier alles unterschätzt^^
Dass man so viel einstellen kann, ist ja wirklich super.
Dann kann SelfHTML wirklich stolz auf so ein dynamisches Forum sein!
Hello,
OK, tut mir Leid, ich hab das hier alles unterschätzt^^
Dass man so viel einstellen kann, ist ja wirklich super.
Dann kann SelfHTML wirklich stolz auf so ein dynamisches Forum sein!
Wenn man die Poster nun auch noch konfigurieren könnte, dann wären sicher Alle glücklich.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hi Tom,
Wenn man die Poster nun auch noch konfigurieren könnte, dann wären sicher Alle glücklich.
Hehe...
Ja und wenn man das eigene Bankkonto, das Auto, die Ehefrau... konfigurieren könnte...
...ja heissa dann ist Weihnachten ;-)
Grüsse
[latex]
gary_\mathrm {max}
[/latex]
Wenn man die Poster nun auch noch konfigurieren könnte, dann wären sicher Alle glücklich.
Hehe...
Du meinst jetzt das optische Erscheinungsbild im Forum? Da gibt es natürlich auch minimale Einstellungsmöglichkeiten. Oder was man von denen als Antwort erwartet?
Tja, da hilft nur "Schöntrinken"
Ja und wenn man das eigene Bankkonto, das Auto, die Ehefrau... konfigurieren könnte...
Da auch.
...ja heissa dann ist Weihnachten ;-)
Ach du Scheiße - schnell weg, jetzt kommen wieder die Schneeflocken
Struppi.
Moin Moin!
Ich weiß nicht genau, wie ich einen Hintergrundprozess starten soll.
Trivial, z.B. mit einem Shell-Script:
/path/to/program < /dev/null > /dev/null 2> /dev/null &
Ich hab schon überlegt, ein C++-Skript zu schreiben, und das dann zu kompilieren (GCC z.B.).
Für Fähigkeiten, die schon die Shell mitbringt, brauchst Du kein C++-Programm. Nicht einmal ein C-Programm.
Die daemontools sind IMHO im Moment der beste, wenn auch anfänglich etwas holperige Weg, ein Programm als Hintergrundprozess laufen zu lassen, mit Logging, Dauerlauf-Garantie und allen anderen extras, und das Ganze ohne eine einzige Zeile Code für das Theater schreiben zu müssen. Anleitung, Erklärung und nötige Patches bei the djb way.
Dumm dabei ist nur, dass GCC nicht installiert ist und ich es auch nicht installiert bekomme.
Du hast ein SuSE, und Du hast einen SSH-Zugang als root. Mehr braucht es nicht. Wenn Du die Pakete mit GCC und Co nicht aus dem Internet installieren kannst, kopiere die RPM-Dateien per scp/sftp/WinSCP auf den Server und installiere die Pakete dort aus den kopierten RPMs.
Wenn bei Dir jetzt ein *TILT* blinkt, solltest Du nochmal nachdenken, ob Du Dich wirklich zu einem Internet-Server-Administrator berufen fühlst.
Wahrscheinlich war der Ansatz sowieso falsch...
Nur über das Ziel hinausgeschossen.
Nein, ich muss dieses Skript alle paar Sekuden ausführen, da es um komplizierte Brechnungen geht, die von der Refresh-Zeit abhängen.
Wie schon gesagt, sonst müsste ein Benutzer alles tragen... Das wäre aber ziemlich blöd für den. =D
Ich habe so langsam das Gefühl, dass an Deinem Algorithmus etwas fürcherlich schief läuft. Bist Du sicher, dass Du per HTTP arbeiten willst?
Alexander
Moin Moin!
Alexander:
Öhm, ok... Tut mir Leid, ich verstehe zwar viel von PHP, aber nicht so viel bis gar nichts von FastCGI. Aber soweit ich das verstanden habe, müsste man das einrichten, und dann doch über ein Skript aufrufen, oder?
Da bliebe doch wieder das Problem...
Wenn Du FastCGI-Support hast (ist bei PHP-Hostern durchaus möglich), muß nichts weiter eingerichtet werden. Dann ist auch kein weiteres Script nötig. Der große Witz an FastCGI ist, dass im Gegensatz zu normalen CGIs eben nicht für jeden Request ein neuer Prozess gestartet wird. Beim ersten Request wird ein Prozess nach FastCGI-Spezifikation gestartet, der dann *ALLE* weiteren Requests für dieses Programm abarbeitet und auch zwischen den Requests weiter läuft.
Link zum Thema: http://www.fastcgi.com/#Docs
Alexander
Das hieße also, ich starte einen Prozess, der durch Sleep-Befehle alle 1.5 sec was macht, und immer läuft?
Ich hab mir grad die Seite da mal angesehen, ist irgendwie etwas unübersichtlich.,.. Aber ich werd mal nach FastCGI bei Google suchen.
In welcher Sprache sollte ich das Skript denn dann schreiben? Und wird das dann kompiliert?
Hello,
das Problem bei shared Hosts ist, dass die oft einmal täglich neu gestartet werden. Das ist die billigste Variante, Zombies und hängende Prozesse loszuwerden und neue Kunden (Virt Hosts) in die Konfiguration aufzunehmen.
Dann ist Dein Prozess natürlich weg, egal, wie Du ihn gebaut hast.
Die einzige sichere Möglichkiet ist dann, seine Kontrolle in einen Cronjob einzubauen.
Um eine praktikable Möglichkiet für Dich zu ersinnen, müsstest Du uns vielleicht etwas mehr über den Server erzählen und welche Programme und Rechte Du darauf hast.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Also ich habe einen Strato V-Server vom Typ A.
http://www.strato.de/v-power/start/index.html
Da müsste man eigentlich alles entnehmen können.
Das Betriebssystem ist VPS openSUSE 10.1 Professional inkl. Plesk 8.1.
Das ist definitiv keine Billig-Variante, schließlich ist Strato der führende Anbeiter...
Ich hab über Plesk und PuTTY alle Rechte dafür. Von einem Neustart über Nacht weiß ich nichts, ich glaube auch, dass das nicht so ist.
Hello,
Ich hab über Plesk und PuTTY alle Rechte dafür. Von einem Neustart über Nacht weiß ich nichts, ich glaube auch, dass das nicht so ist.
Bei einem VServer würde ich mir das auch verbitten.
Ich sprach von Shared Hosting.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Achso ne, so ist das nicht. Sonst hätte ich auch keinen Zugriff über PuTTY^^
Also irgendwie geht das alles nicht. Ich hab versucht, das FastCGI Development Kit zu installieren, doch der sagt mir irgendwas von cc fehlt...
Moin Moin!
das Problem bei shared Hosts ist, dass die oft einmal täglich neu gestartet werden. Das ist die billigste Variante, Zombies und hängende Prozesse loszuwerden und neue Kunden (Virt Hosts) in die Konfiguration aufzunehmen.
Dann ist Dein Prozess natürlich weg, egal, wie Du ihn gebaut hast.
Und er kommt dank FastCGI beim ersten Request wieder. Man kann -- zumindest bei mod_fastcgi -- sogar dafür sorgen, dass der FastCGI-Prozess automatisch mit dem Server gestartet wird, das nennt sich dann "static server": http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiServer
Die einzige sichere Möglichkiet ist dann, seine Kontrolle in einen Cronjob einzubauen.
Nö. Der Prozess wird seine Buchführung wohl kaum komplett im RAM machen, sondern (hoffentlich) auf einer transaktionsfähigen Datenbank aufsetzen. Stirbt der Prozess, ist schlimmstenfalls der letzte Schritt weg und kann ggf. beim Start einer neuen Instanz rekonstruiert werden.
Alexander
Moin Moin!
Das hieße also, ich starte einen Prozess, der durch Sleep-Befehle alle 1.5 sec was macht, und immer läuft?
Nein. Der Webserver startet den FastCGI-Prozess beim ersten Request und hält ihn danach am Leben.
Ich hab mir grad die Seite da mal angesehen, ist irgendwie etwas unübersichtlich.,..
Öm, du findest neun Links unübersichtlich? Hmmmmmm....
Aber ich werd mal nach FastCGI bei Google suchen.
Da wirst Du vor allem auf dieser Seite landen.
In welcher Sprache sollte ich das Skript denn dann schreiben?
Wie es Dir gefällt. Perl, C, C++, Java, ADA, Fortran, völlig egal. Alles, was Du brauchst, sind Sockets.
Und wird das dann kompiliert?
Das kommt darauf an, welche Sprache Du wählst und hat absolut nichts mit FastCGI zu tun.
Alexander
Moin!
ich wollte in meinem Browsergame eine Art "Engine" ausführen lassen. Diese soll alle paar Sekunden Aktionen ausführen (bewegen von Computerspielern etc.).
Die Frage ist doch, ob das wirklich so dringend notwendig ist.
Wenn du dich mal an folgender philosophischen Frage orientierst: Wenn im Wald ein Baum umfällt, und keiner ist da, der's beobachtet, macht der Baum dann ein Geräusch?
Soll heißen: Was bringt es den Spielern, dass deine Engine auf dem Server irgendwelche Änderungen durchführt, wenn das in dieser zeitlichen Auflösung sowieso niemand beobachtet?
Nur mal anhand des Bewegungsbeispiels: Angenommen, du kennst Standort, Ziel und Geschwindigkeit eines Spielers. Dann kannst du natürlich alle X Sekunden den Standort aktualisieren, ohne dass das jemand wissen will.
Oder du aktualisierst den Standort nur dann, WENN das jemand wissen will. Nämlich wenn ein Benutzer einen neuen Request geschickt hat, mit dem er u.A. den Standort abfragt.
Eine Bewertung der Performance beider denkbarer Lösungen ist übrigens ziemlich schwierig, denn es hängt natürlich davon ab, wieviele derartige Requests insgesamt abzuarbeiten sind, wie die Speicherung der Daten gelöst ist, und ob ein Request grundsätzlich alle Daten aktualisiert, oder nur diejenigen, die er auch wirklich ausgibt. Außerdem ist natürlich ein Faktor, ob ein Auswahlmechanismus für selektives Aktualisieren nicht evtl. komplexer wird, als die generelle Abarbeitung von allem.
- Sven Rautenberg
Hi!
Es ist notwendig. SIeh dir mal Browsergames an. Da MUSS einfach alle x Sekunden was aktualisiert werden. Selbstversändlich sind das nicht irgendwelche Anzeigen, sondern Objekte. Diese wiederum werden mit einer hochkomplizierten FOrmel (die ich selbst nicht verstehe) erstellt, bei der Spieler online, Anzahl Objekte bis jetzt, Aktualisierungsgeschwindigkeit etc. angegeben werden müssen.
Soweit so gut, damit wäre die erste Möglichkeit, einfach nur zu aktualisieren, wenn jemand was will, weggefallen.
Nur Aktualisieren, wenn jemand online ist. GInge natürlich auch, aber das müsste auch über diese "Engine" vom Server her gemacht werden, um keinen Spieler zu belasten. Insofern ist es ja auch egal, ob sie nun immer ausgeführt wird, oder erst überprüft, ob jemand online ist. Es stört ja dann keinen.^^
Aber ich habe jetzt ja eine Lösung gefunden.
Vielen Dank für deine Antwort und detailierte Beschreibung.
Ich bin jederzeit noch zum Diskutieren bereit. :D
Gruß,
Phaltôn
Moin!
Es ist notwendig. SIeh dir mal Browsergames an. Da MUSS einfach alle x Sekunden was aktualisiert werden.
Ich habe nicht die Zeit, mich intensiv spielend mit sowas zu befassen. Meine Spieler-Erfahrung stammt aus genau einem Spielkontakt, aus dem ich die gewisse technische Realisierungen extrapoliere.
Grundprinzip eines Multiplayer-Browserspiels ist, dass der Server Herrscher über alle Daten ist, die Clients geben nur die Befehle des Spielers weiter und zeigen die Lage an.
Außerdem läuft so ein Spiel in Echtzeit, und alle erteilten Befehle werden auch dann weiter ausgeführt, wenn der Spieler nicht aktiv und eingeloggt ist. "Zeit" ist also eine wichtige Komponente.
Selbstversändlich sind das nicht irgendwelche Anzeigen, sondern Objekte.
Es mögen vielleicht intern "Objekte" sein (vernünftige Softwareprogrammierung läuft objektorientiert), aber ein "Objekt" kann man nicht anzeigen, man kann es vielleicht auffordern, sich "darzustellen" (sofern das so programmiert ist).
Diese wiederum werden mit einer hochkomplizierten FOrmel (die ich selbst nicht verstehe) erstellt, bei der Spieler online, Anzahl Objekte bis jetzt, Aktualisierungsgeschwindigkeit etc. angegeben werden müssen.
Ich dachte, du bist der Spieleprogrammierer und kennst dich mit den Interna aus.
Aber wie auch immer: Üblicherweise greifen alle Spielmechanismen immer auch auf die auf dem Server vergangene Zeit zurück, denn es ist einfach unpraktisch, andauernd irgendwelche Zähler zu aktualisieren, weil z.B. irgendwo was produziert wird. Denn genau diese Vorgehensweise führt irgendwann, und wenn es schlecht programmiert ist, zum totalen Stillstand. Denn Schreibzugriffe müssen gegen gleichzeitige anderweitige Schreib- und Lesezugriffe abgeschottet werden.
Wenn du eine Datenbank benutzt, regelt die das für dich. Das Blockieren des Lesezugriffs während des Schreibens führt aber ab einer gewissen Menge an sowohl Schreibzugriffen als auch Lesezugriffen dazu, dass die Schreibzugriffe das Lesen merklich behindern. Angenommen, deine sekündlichen Aktualisierungen benötigen eine halbe Sekunde Schreibzeit, dann steht für Lesezugriffe von Benutzern nur noch 50% der Zeit zur Verfügung.
Und wenn eine Aktualisierung länger als eine Sekunde benötigt, befindest du dich in einer ernsthaften Situation, denn dann laufen zwei Aktualisierungen parallel. Oder die zweite Aktualisierung muß auf die erste warten. Was dann aber wieder bedeutet, dass dein Zeittakt aus den Fugen gerät, weil nicht mehr sekündlich aktualisiert wird. Wenn aber das genau wichtig war für die korrekte Zuweisung von Spielressourcen, wird's ernst. Das bedeutet, du mußt also doch irgendwie die tatsächlich vergangene Zeit feststellen, um ggf. zu kompensieren.
Soweit so gut, damit wäre die erste Möglichkeit, einfach nur zu aktualisieren, wenn jemand was will, weggefallen.
Aber nicht deshalb, weil das unmöglich ist, sondern weil du ja anscheinend nicht so ganz durchblickst. Und weil du in der glücklichen Lage bist, dass dein Spiel offenbar noch nicht wirklich beliebt und der Server nicht ausgelastet ist, scheint das für dich im Moment die beste Lösung zu sein. Sie wird sich vermutlich rächen, wenn mehr Leute mitspielen.
- Sven Rautenberg
Richtig, die Zeit spielt in so SPielen eine sehr wichtige Rolle.
Ja ok, Objekte, die angezeigt werden. Aber eben nicht einfach nur Anzeigen, sondern veränderbare Objekte, die sich anzeigen.
Schon wieder falsch ausgedrückt, die Formel bestimmt die Wahrscheinlichkeit, mit der Monster ins Spiel kommen. Für jedes Feld wird diese angewandt, so entsteht eine ziemlich gute Wahrscheinlichkeit.
Ich würde sehr gerne nicht jede Sekunde aktualisieren müssen, doch wie ich das realisieren soll, ist mir nicht klar.
ALso, vielleicht weißt du eine Lösung, wenn ich alles ganz genau beschreibe:
Im Spiel kann man sich über eine Karte bewegen, man klickt auf ein benachbartes Feld, und bewegt sich dorthin.
Auf Feldern findet man Monster, von denen kann man Geld bekommen, wenn man sie angreift.
[Hier gleich die wichtigste Aktion: Irgendwoher müssen die Monster doch kommen, oder? Und das mit einer guten Wahrscheinlichkeit...]
Dann gibt es einen Chat, über den man mit anderen Spielern kommunizieren kann. Dieser muss regelmäßig gelöscht werden, das soll aber nicht unbedingt DAS Problem mit der Zeit sein.
Dann gibt es Events, wo z.B. ein Schneesturm kommt. Hierbei muss allen Spielern was passieren, und das muss auch wieder beendet werden.
Außerdem gibt es Computerspieler, die von selbst rumlaufen.
[Das ist wohl das am Schwersten zu realisierende, ohne "Engine"...]
Vielleicht gibt dir das einen kleinen Einblick in das Spiel.
Sehr gut möglich, sobald die Engine länger als eine Sekunde braucht, hat man echt ein Problem, das würde wahrscheinlich zum Absturz führen.
Mir ist klar, dass das so nicht mit 1000 Spielern funktionieren kann. Doch wie schon erwähnt, wusste ich eben keine andere Möglichkeit, und war erstmal schon sehr glücklich darüber, dass ich immerhin bei wenigen Spielern eine gute Lösung gefunden hatte...
Schon gut möglich, dass ich da nicht ganz "durchblicke", doch leider eröffnet sich mir kein Weg, auf dem ich das ganze programmieren könnte.
Gruß,
Phaltôn
Moin!
Schon wieder falsch ausgedrückt, die Formel bestimmt die Wahrscheinlichkeit, mit der Monster ins Spiel kommen. Für jedes Feld wird diese angewandt, so entsteht eine ziemlich gute Wahrscheinlichkeit.
Hihi, das mit Wahrscheinlichkeiten ist so eine Sache. Microsoft dachte wohl auch, dass sie in Windows 2000 und Windows XP eine "ziemlich gute Wahrscheinlichkeit" integriert hatten, und dann kam das hier raus.
Ich würde sehr gerne nicht jede Sekunde aktualisieren müssen, doch wie ich das realisieren soll, ist mir nicht klar.
ALso, vielleicht weißt du eine Lösung, wenn ich alles ganz genau beschreibe:
Na endlich kommen wir mal zur Sache. :)
Im Spiel kann man sich über eine Karte bewegen, man klickt auf ein benachbartes Feld, und bewegt sich dorthin.
Mit anderen Worten: Jemand mit einer sehr schnellen Internetleitung kann sehr häufig "klicken" und dadurch viele Felder besuchen. Jemand mit einer langsamen Leitung kann das nicht. Die Gleichheit der Spieler hängt also von deren Leitung ab. Das aber nur am Rande.
Auf Feldern findet man Monster, von denen kann man Geld bekommen, wenn man sie angreift.
Je schneller man Felder besuchen kann, desto schneller findet man Monster, desto schneller kriegt man Geld.
[Hier gleich die wichtigste Aktion: Irgendwoher müssen die Monster doch kommen, oder? Und das mit einer guten Wahrscheinlichkeit...]
Richtig, die Monster müssen irgendeinen Grund haben, auf einem bestimmten Feld zu sein. Entweder "leben" sie an bestimmten Orten (dann liegt der Grund in der Kreation der Spielwelt begründet), oder sie rennen nach einem bestimmten Muster durch die Landschaft (so ähnlich wie einst die Geister in PAC MAN), oder sie tauchen auf einem Feld zufällig aus dem Nichts auf.
Wenn sie aus dem Nichts auftauchen, dann gibts pro Feld eine gewisse Monsterauftauchwahrscheinlichkeit. Die ist dann aber unabhängig von irgendeinem zeitlichen Verlauf. Und du könntest dir die ganze Aktualisierung sparen, wenn du einfach nur beim Betreten eines Feldes eine kurze Rechnung ablaufen läßt, ob der Spieler auf ein Monster trifft, oder nicht: Ermittle eine Zufallszahl, und wenn die Zahl größer oder kleiner als ein Grenzwert ist, ist ein Monster anwesend.
Eventuell kann man je Feld unterschiedliche Monsterwahrscheinlichkeiten definieren. Beispielsweise könnte man mitzählen, wieviele Monster auf einem bestimmten Feld schon aufgetaucht sind, und das ins Verhältnis zur Gesamtzahl der Monster in der Welt setzen, so dass die Monsterwahrscheinlichkeit auf genau diesem einen Feld sinkt oder steigt, je nachdem, wie häufig dort Monster aufgetreten sind. Auf lange Sicht gesehen ist das allerdings wieder irrelevant, denn es ist Kennzeichen eines guten Zufallsgenerators, dass er gut verteilte Zufallszahlen ausspuckt. Sofern also die Spieler die Felder gleichmäßig besuchen, werden auch Monster gleichmäßig auftauchen.
Wenn du einen "Aberntungseffekt" haben willst, benötigst du natürlich eine zeitliche Komponente, d.h. die Wahrscheinlichkeit, auf einem Feld auf ein Monster zu stoßen, hängt davon ab, wie lange es her ist, dass dort schon mal ein Monster angetroffen wurde. Mit anderen Worten: Die Wahrscheinlichkeit hängt davon ab, wieviel Zeit seit dem letzten Monster vergangen ist. Der Monsterfaktor muß also kleiner werden, wenn wenig Zeit verging, und er steigt bis zum Normalwert an, wenn eine ausreichend große Zeitspanne vergangen ist. Vollkommen ausgeschlossen sein darf es natürlich nicht, sofort wieder auf ein Monster zu treffen.
Dann gibt es einen Chat, über den man mit anderen Spielern kommunizieren kann. Dieser muss regelmäßig gelöscht werden, das soll aber nicht unbedingt DAS Problem mit der Zeit sein.
Das muß ja nicht jede Sekunde gelöscht werden, sondern jeden Tag reicht vollkommen. Oder meinetwegen jede Stunde. Oder jedesmal, wenn jemand was neues chattet. Jedenfalls kriegst du ja problemlos eine eingeschränkte Liste der letzten Äußerungen, wenn du die Uhrzeit mitspeicherst und bei der Ausgabe nur die letzten X Minuten selektierst, alles vorher nicht. Dann ist es zwar noch gespeichert, und du als Admin kannst auch nachgucken, ob sich z.B. jemand danebenbenommen hat, oder illegale Spielerabsprachen vorkamen, aber die Spieler sehen nichts mehr davon.
Dann gibt es Events, wo z.B. ein Schneesturm kommt. Hierbei muss allen Spielern was passieren, und das muss auch wieder beendet werden.
Das ist auch nichts, was an zentraler Stelle auf allen Feldern ein- und ausgeschaltet werden muß. Du kannst in der Datenbank einfach schon im Vorraus speichern, von wann bis wann Schneesturm ist. Vielleicht gibt es eine Wettervorhersage, die mit einer gewissen Wahrscheinlichkeit den Schneesturm (der sicher kommt) ankündigt. Natürlich muß da ein Skript irgendwann mal die Datenbank wieder mit neuer Zukunft befüllen, aber das ist nichts, was jede Sekunde sein muß.
Außerdem gibt es Computerspieler, die von selbst rumlaufen.
[Das ist wohl das am Schwersten zu realisierende, ohne "Engine"...]
Hängt davon ab, was diese NPC so machen sollen. Wenn ein Fährmann regelmäßig den Fluß überquert, kann man diese Bewegung natürlich speichern. Ist halt die Frage, nach welcher Regel er sich bewegt: Fahrplan oder Spieleraktion. Bei Fahrplan kann man berechnen, wann er wo ist. Bei Spieleraktion wartet er, dass ein Spieler ihn ruft.
Mir ist klar, dass das so nicht mit 1000 Spielern funktionieren kann. Doch wie schon erwähnt, wusste ich eben keine andere Möglichkeit, und war erstmal schon sehr glücklich darüber, dass ich immerhin bei wenigen Spielern eine gute Lösung gefunden hatte...
Klar, das ist halt die Essenz von "entwickeln". Gilt nicht nur für Programme, auch für Programmierer.
- Sven Rautenberg
Vielen Dank erstmal, du hast einige sehr gute Ideen.
Hihi, das mit Wahrscheinlichkeiten ist so eine Sache. Microsoft dachte wohl auch, dass sie in Windows 2000 und Windows XP eine "ziemlich gute Wahrscheinlichkeit" integriert hatten, und dann kam das hier raus.
Haha^^ Naja, aber was soll ich machen^^ Solange es nur annähernd stimmt, reicht es ja.
Mit anderen Worten: Jemand mit einer sehr schnellen Internetleitung kann sehr häufig "klicken" und dadurch viele Felder besuchen. Jemand mit einer langsamen Leitung kann das nicht. Die Gleichheit der Spieler hängt also von deren Leitung ab. Das aber nur am Rande.
Nein. Jeder Spieler muss 3 Sekunden (abhängig vom Gebiet) warten, bis er sich wieder bewegen kann. Trotzdem kann er schneller Monster angreifen, schneller Items aufnehmen, richtig.
Je schneller man Felder besuchen kann, desto schneller findet man Monster, desto schneller kriegt man Geld.
Sehr richtig, beachtet werden muss hierbei aber die Wartezeit.
Richtig, die Monster müssen irgendeinen Grund haben, auf einem bestimmten Feld zu sein. Entweder "leben" sie an bestimmten Orten (dann liegt der Grund in der Kreation der Spielwelt begründet), oder sie rennen nach einem bestimmten Muster durch die Landschaft (so ähnlich wie einst die Geister in PAC MAN), oder sie tauchen auf einem Feld zufällig aus dem Nichts auf.
Auf einem Feld kommt immer das gleiche Monster. Da es pro Gebiet oft 20 oder mehr Felder gibt, ist das nicht so schlimm.
Dieses Monster taucht durch Zufall einfach auf.
Wenn sie aus dem Nichts auftauchen, dann gibts pro Feld eine gewisse Monsterauftauchwahrscheinlichkeit. Die ist dann aber unabhängig von irgendeinem zeitlichen Verlauf. Und du könntest dir die ganze Aktualisierung sparen, wenn du einfach nur beim Betreten eines Feldes eine kurze Rechnung ablaufen läßt, ob der Spieler auf ein Monster trifft, oder nicht: Ermittle eine Zufallszahl, und wenn die Zahl größer oder kleiner als ein Grenzwert ist, ist ein Monster anwesend.
Problem hierbei ist nur: Wie synchronisiere ich das mit anderen Spielern? Man kann leider nicht sagen, ob der Spieler auf ein Monster trifft, sondern vielleicht eher, ob eins erscheint, wenn man auf das Feld geht. So könnte man schon mal einen Teil der Monster steuern, doch es wäre besser, wenn viele auch noch durch Zufall erscheinen.
Eventuell kann man je Feld unterschiedliche Monsterwahrscheinlichkeiten definieren. Beispielsweise könnte man mitzählen, wieviele Monster auf einem bestimmten Feld schon aufgetaucht sind, und das ins Verhältnis zur Gesamtzahl der Monster in der Welt setzen, so dass die Monsterwahrscheinlichkeit auf genau diesem einen Feld sinkt oder steigt, je nachdem, wie häufig dort Monster aufgetreten sind. Auf lange Sicht gesehen ist das allerdings wieder irrelevant, denn es ist Kennzeichen eines guten Zufallsgenerators, dass er gut verteilte Zufallszahlen ausspuckt. Sofern also die Spieler die Felder gleichmäßig besuchen, werden auch Monster gleichmäßig auftauchen.
Interessante Idee. Aber wie du schon sagtest - rand() sollte ausreichen.
Wenn du einen "Aberntungseffekt" haben willst, benötigst du natürlich eine zeitliche Komponente, d.h. die Wahrscheinlichkeit, auf einem Feld auf ein Monster zu stoßen, hängt davon ab, wie lange es her ist, dass dort schon mal ein Monster angetroffen wurde. Mit anderen Worten: Die Wahrscheinlichkeit hängt davon ab, wieviel Zeit seit dem letzten Monster vergangen ist. Der Monsterfaktor muß also kleiner werden, wenn wenig Zeit verging, und er steigt bis zum Normalwert an, wenn eine ausreichend große Zeitspanne vergangen ist. Vollkommen ausgeschlossen sein darf es natürlich nicht, sofort wieder auf ein Monster zu treffen.
Wäre aber blöd, wenn ein Spieler zu einem selten besuchten (oder besuchbaren Ort) kommt, und dort sofort haufenweise Monster vorfindet.
Das muß ja nicht jede Sekunde gelöscht werden, sondern jeden Tag reicht vollkommen. Oder meinetwegen jede Stunde. Oder jedesmal, wenn jemand was neues chattet. Jedenfalls kriegst du ja problemlos eine eingeschränkte Liste der letzten Äußerungen, wenn du die Uhrzeit mitspeicherst und bei der Ausgabe nur die letzten X Minuten selektierst, alles vorher nicht. Dann ist es zwar noch gespeichert, und du als Admin kannst auch nachgucken, ob sich z.B. jemand danebenbenommen hat, oder illegale Spielerabsprachen vorkamen, aber die Spieler sehen nichts mehr davon.
Richtig, das reicht auch so jede Viertelstunde (kommt auf die Spieleranzahl an).
Das ist auch nichts, was an zentraler Stelle auf allen Feldern ein- und ausgeschaltet werden muß. Du kannst in der Datenbank einfach schon im Vorraus speichern, von wann bis wann Schneesturm ist. Vielleicht gibt es eine Wettervorhersage, die mit einer gewissen Wahrscheinlichkeit den Schneesturm (der sicher kommt) ankündigt. Natürlich muß da ein Skript irgendwann mal die Datenbank wieder mit neuer Zukunft befüllen, aber das ist nichts, was jede Sekunde sein muß.
DAS ist die beste Idee von allen!!!
Ich könnte z.B: so für einen Tag alles im Voraus berechnen!
Mann, auf sowas bin ich nie gekommen...
Hängt davon ab, was diese NPC so machen sollen. Wenn ein Fährmann regelmäßig den Fluß überquert, kann man diese Bewegung natürlich speichern. Ist halt die Frage, nach welcher Regel er sich bewegt: Fahrplan oder Spieleraktion. Bei Fahrplan kann man berechnen, wann er wo ist. Bei Spieleraktion wartet er, dass ein Spieler ihn ruft.
Es sollen NPCs sein, die sich ähnlich wie Spieler verhalten, also auch Monster angreifen und zufällig rumlaufen.
Aber auch hier könnte man im Voraus planen, was allerdings etwas blöd ist, denn woher weiß der NPC, ob an dem aktuellen Ort dann ein Monster ist?
Klar, das ist halt die Essenz von "entwickeln". Gilt nicht nur für Programme, auch für Programmierer.
Ja, das Ziel ist es, möglich wenig Performance zu nutzen und so zu programmieren, dass das Spiel dynamisch in Hinsicht auf die Spielerzahl ist.
Gruß,
Felix
Moin!
Mit anderen Worten: Jemand mit einer sehr schnellen Internetleitung kann sehr häufig "klicken" und dadurch viele Felder besuchen. Jemand mit einer langsamen Leitung kann das nicht. Die Gleichheit der Spieler hängt also von deren Leitung ab. Das aber nur am Rande.
Nein. Jeder Spieler muss 3 Sekunden (abhängig vom Gebiet) warten, bis er sich wieder bewegen kann. Trotzdem kann er schneller Monster angreifen, schneller Items aufnehmen, richtig.
Die entscheidende Frage ist halt, was der übergreifend limitierende Faktor ist. Eine Spielewelt ist ja erstmal durch nichts beschränkt, genausowenig wie eine Romanwelt.
Bei "Perry Rhodan" haben die Autoren im Laufe der Serie immer schnellere Raumschiffantriebe "erfunden", so dass die Akteure immer weiter in die Galaxie vordringen konnten, und immer schneller den Ort wechselten. Mit dem Resultat, dass der aktuelle Aufenthaltsort eigentlich kaum noch eine Bedeutung spielte, und die Story erzählerisch zu veröden drohte. Man nahm einen "Kunstgriff" und erfand eine erzwungene Langsamkeit: Irgendwelche Überwesen beschlossen einfach, die Hyperraumimpedanz zu erhöhen, so dass alle bisherigen Antriebe wertlos wurden, und man wieder "normal" reisen mußte.
Dasselbe Problem hast du natürlich in einem Spiel. Es ist ja grundsätzlich denkbar, die gesamte Spielwelt in 0,00001 Sekunden zu durchqueren. Damit geht aber jeglicher Realismus flöten, es sei denn, "teleportieren" wäre eine in die Spielmechanik vernünftig integrierte Bewegungsmethode. :)
Wenn sie aus dem Nichts auftauchen, dann gibts pro Feld eine gewisse Monsterauftauchwahrscheinlichkeit. Die ist dann aber unabhängig von irgendeinem zeitlichen Verlauf. Und du könntest dir die ganze Aktualisierung sparen, wenn du einfach nur beim Betreten eines Feldes eine kurze Rechnung ablaufen läßt, ob der Spieler auf ein Monster trifft, oder nicht: Ermittle eine Zufallszahl, und wenn die Zahl größer oder kleiner als ein Grenzwert ist, ist ein Monster anwesend.
Problem hierbei ist nur: Wie synchronisiere ich das mit anderen Spielern? Man kann leider nicht sagen, ob der Spieler auf ein Monster trifft, sondern vielleicht eher, ob eins erscheint, wenn man auf das Feld geht. So könnte man schon mal einen Teil der Monster steuern, doch es wäre besser, wenn viele auch noch durch Zufall erscheinen.
Wo ist denn da jetzt der Unterschied? Spieler betritt Feld, Monster ist da oder nicht. Warum das Monster da ist, ist für den Spieler nicht interessant.
Kommt ein anderer Spieler auf das Feld, kann ja festgestellt werden, wer noch alles auf dem Feld steht: Spieler, Monster, Gegenstände...
Wenn du einen "Aberntungseffekt" haben willst, benötigst du natürlich eine zeitliche Komponente, d.h. die Wahrscheinlichkeit, auf einem Feld auf ein Monster zu stoßen, hängt davon ab, wie lange es her ist, dass dort schon mal ein Monster angetroffen wurde. Mit anderen Worten: Die Wahrscheinlichkeit hängt davon ab, wieviel Zeit seit dem letzten Monster vergangen ist. Der Monsterfaktor muß also kleiner werden, wenn wenig Zeit verging, und er steigt bis zum Normalwert an, wenn eine ausreichend große Zeitspanne vergangen ist. Vollkommen ausgeschlossen sein darf es natürlich nicht, sofort wieder auf ein Monster zu treffen.
Wäre aber blöd, wenn ein Spieler zu einem selten besuchten (oder besuchbaren Ort) kommt, und dort sofort haufenweise Monster vorfindet.
Wenn die normale Wahrscheinlichkeit z.B. 10% wäre für "noch nie oder nicht innerhalb der letzten Stunde kam ein Monster", und die "abgeerntete" Wahrscheinlichkeit 1% für "innerhalb der letzten zehn Sekunden kam eins", dann kann die Wahrscheinlichkeit zwischen 1% und 10% schwanken, bzw. linear zunehmen, je länger das Erscheinen des Monsters zurückliegt.
Wie hoch konkret die Wahrscheinlichkeit sein muß, ist eine Frage der Spielbalance und des Feintunings, das kann man vorab nicht beantworten.
Aber ein anderer Effekt wäre halt blöd: Wenn es sehr kompliziert oder zeitaufwendig ist, in diese selten besuchte Region vorzudringen, und ein Spieler tut das kurz nach einem anderen Spieler, dann beeinflußt das natürlich dessen Erlebnis. Zum einen könnte er enttäuscht sein, weil er in diesem Abschnitt auf nahezu kein Monster trifft, sich der Zeitaufwand also nicht gelohnt hat. Zum anderen könnte er viel zu leicht noch weiter in diese Region vordringen und evtl. Schätze einsacken, die eigentlich von Monstern gut bewacht sein sollten.
Andererseits sollte es natürlich Auswirkungen haben, wenn sich eine Gruppe von Spielern zu einer Expedition entschließt, d.h. nicht jeder Spieler sollte auf jedem Feld immer wieder gegen die gleichen Monster kämpfen müssen. Allerdings sollte die Gruppe natürlich auf stärkere Monster treffen, denn ansonsten muß man ja nur ausreichend Leute zusammensammeln und würde jedes Monster, dass für einen Einzelspieler ein ernsthaftes Problem ist, einfach niedermetzeln.
Das ist ja z.B. in typischen Rollenspielen durchaus üblich, wenn der Held aufsteigt: Mit jeder Stufe wird er stärker, schneller, besser. Aber auch die Monster werden stärker und besser, so dass letztendlich die Kampfergebnisse doch gleich bleiben.
Hängt davon ab, was diese NPC so machen sollen. Wenn ein Fährmann regelmäßig den Fluß überquert, kann man diese Bewegung natürlich speichern. Ist halt die Frage, nach welcher Regel er sich bewegt: Fahrplan oder Spieleraktion. Bei Fahrplan kann man berechnen, wann er wo ist. Bei Spieleraktion wartet er, dass ein Spieler ihn ruft.
Es sollen NPCs sein, die sich ähnlich wie Spieler verhalten, also auch Monster angreifen und zufällig rumlaufen.
Und was haben die NPCs davon, ohne gesehen zu werden in der Welt herumzulaufen? Relevant werden die doch nur, wenn Spieler auf sie treffen.
Aber auch hier könnte man im Voraus planen, was allerdings etwas blöd ist, denn woher weiß der NPC, ob an dem aktuellen Ort dann ein Monster ist?
Das weiß er auf dieselbe Weise, wie es ein normaler Spieler auch weiß: Indem er das Feld betritt und gesagt bekommt, ob da ein Monster ist, oder nicht.
Du mußt dich halt entscheiden, ob du die NPC eher monsterartig programmierst, d.h. sie sind Teil der Umgebung, in der sich die PC bewegen, oder ob du sie botartig programmierst, d.h. sie sind im Prinzip computergeführte Spieler. Der Aufwand, eine eigene vernünftige Intelligenz zu entwickeln, um die NPC botartig durch die Welt rennen zu lassen, ist deutlich höher - und es bedeutet, dass die NPC auch irgendwelche Ziele verfolgen durch ihre Existenz, die möglicherweise im Widerspruch zu den Zielen der PC steht.
Wenn mir zum zehnten Mal ein streunender NPC das Monstergold wegschnappt, während ich halbtot auf der Wiese liege, werde ich vermutlich etwas ungehalten. :)
- Sven Rautenberg
Hi!
Nein. Jeder Spieler muss 3 Sekunden (abhängig vom Gebiet) warten, bis er sich wieder bewegen kann. Trotzdem kann er schneller Monster angreifen, schneller Items aufnehmen, richtig.
Die entscheidende Frage ist halt, was der übergreifend limitierende Faktor ist. Eine Spielewelt ist ja erstmal durch nichts beschränkt, genausowenig wie eine Romanwelt.
Wäre besser, wenn es nach Zeit ginge, denn ich will keine mit schlechter Internetverbindung benachteiligen. ;)
Bei "Perry Rhodan" haben die Autoren im Laufe der Serie immer schnellere Raumschiffantriebe "erfunden", so dass die Akteure immer weiter in die Galaxie vordringen konnten, und immer schneller den Ort wechselten. Mit dem Resultat, dass der aktuelle Aufenthaltsort eigentlich kaum noch eine Bedeutung spielte, und die Story erzählerisch zu veröden drohte. Man nahm einen "Kunstgriff" und erfand eine erzwungene Langsamkeit: Irgendwelche Überwesen beschlossen einfach, die Hyperraumimpedanz zu erhöhen, so dass alle bisherigen Antriebe wertlos wurden, und man wieder "normal" reisen mußte.
Ja, sonst ginge ja auch eine der Faktoren in der Serie verloren: der Raum. Zumindest teilweise...
Dasselbe Problem hast du natürlich in einem Spiel. Es ist ja grundsätzlich denkbar, die gesamte Spielwelt in 0,00001 Sekunden zu durchqueren. Damit geht aber jeglicher Realismus flöten, es sei denn, "teleportieren" wäre eine in die Spielmechanik vernünftig integrierte Bewegungsmethode. :)
Genau, das fänd ich blöd. Realistisch sollte es sein.
Außerdem wäre es langweilig, wenn man sagen könnte, ich will jetzt dahin und man ist sofort dort.
Problem hierbei ist nur: Wie synchronisiere ich das mit anderen Spielern? Man kann leider nicht sagen, ob der Spieler auf ein Monster trifft, sondern vielleicht eher, ob eins erscheint, wenn man auf das Feld geht. So könnte man schon mal einen Teil der Monster steuern, doch es wäre besser, wenn viele auch noch durch Zufall erscheinen.
Wo ist denn da jetzt der Unterschied? Spieler betritt Feld, Monster ist da oder nicht. Warum das Monster da ist, ist für den Spieler nicht interessant.
Das heißt, jeder Spieler hat "seine eigenen" Monster? Das ginge wiederum gegen die Logik des Spiels.
Kommt ein anderer Spieler auf das Feld, kann ja festgestellt werden, wer noch alles auf dem Feld steht: Spieler, Monster, Gegenstände...
Das wäre logischer. Aber...wie soll das dann mit den Monstern gehandhabt werden? Sind dann z.B. zwei auf dem Feld und beide Spieler können diese sehen und angreifen?
Wäre aber blöd, wenn ein Spieler zu einem selten besuchten (oder besuchbaren Ort) kommt, und dort sofort haufenweise Monster vorfindet.
Wenn die normale Wahrscheinlichkeit z.B. 10% wäre für "noch nie oder nicht innerhalb der letzten Stunde kam ein Monster", und die "abgeerntete" Wahrscheinlichkeit 1% für "innerhalb der letzten zehn Sekunden kam eins", dann kann die Wahrscheinlichkeit zwischen 1% und 10% schwanken, bzw. linear zunehmen, je länger das Erscheinen des Monsters zurückliegt.
Jaaa, das wär natürlich ne Möglichkeit. Damit bekämen immerhin abgelegene Orte eine höhere Bedeutung.
Allerdings darf man nicht zu mathematisch denken^^ Monster tauchen in der Wirklichkeit (naja, da tauchen sie ja sowieso nicht auf :D) nun eben mal nicht immer da auf, wo wenige Spieler sind (im Durchschnitt zeitlich gesehen).
Wie hoch konkret die Wahrscheinlichkeit sein muß, ist eine Frage der Spielbalance und des Feintunings, das kann man vorab nicht beantworten.
Klar, Probieren geht über Studieren.
Aber ein anderer Effekt wäre halt blöd: Wenn es sehr kompliziert oder zeitaufwendig ist, in diese selten besuchte Region vorzudringen, und ein Spieler tut das kurz nach einem anderen Spieler, dann beeinflußt das natürlich dessen Erlebnis. Zum einen könnte er enttäuscht sein, weil er in diesem Abschnitt auf nahezu kein Monster trifft, sich der Zeitaufwand also nicht gelohnt hat. Zum anderen könnte er viel zu leicht noch weiter in diese Region vordringen und evtl. Schätze einsacken, die eigentlich von Monstern gut bewacht sein sollten.
Stimmt. Wobei Monster nicht unbedingt etwas bewachen, sie sind (in vielen Fällen) einfach nur "Objekte" und können angegriffen werden, um Geld zu bekommen. Natürlich gibt es auch besondere Monster.
Ja, ein Spieler würde dann eben alles abräumen, und für die nächste halbe Stunde z.B. für keinen was übrig lassen. Wär auch irgendwie doof.
Andererseits sollte es natürlich Auswirkungen haben, wenn sich eine Gruppe von Spielern zu einer Expedition entschließt, d.h. nicht jeder Spieler sollte auf jedem Feld immer wieder gegen die gleichen Monster kämpfen müssen. Allerdings sollte die Gruppe natürlich auf stärkere Monster treffen, denn ansonsten muß man ja nur ausreichend Leute zusammensammeln und würde jedes Monster, dass für einen Einzelspieler ein ernsthaftes Problem ist, einfach niedermetzeln.
Für sowas müsste das gesamte Spielprinzip geändert werden, im Moment sind Monster eben nur Angriffsobjekte.
Vielleicht baue ich sowas dann eher in "Quest-Gebiete" ein. Da ist man dann eben alleine...mit der Gruppe.
Das ist ja z.B. in typischen Rollenspielen durchaus üblich, wenn der Held aufsteigt: Mit jeder Stufe wird er stärker, schneller, besser. Aber auch die Monster werden stärker und besser, so dass letztendlich die Kampfergebnisse doch gleich bleiben.
Richtig, aber man könnte es ja auch so machen (so ist es jetzt): Es gibt starke und schwache. Ist man also stärker, kann man die stärkeren auch angreifen.
Es sollen NPCs sein, die sich ähnlich wie Spieler verhalten, also auch Monster angreifen und zufällig rumlaufen.
Und was haben die NPCs davon, ohne gesehen zu werden in der Welt herumzulaufen? Relevant werden die doch nur, wenn Spieler auf sie treffen.
Nicht unbedingt, dann würden sie sich ja nur bewegen, wenn ein Spieler da ist; das wär komisch, oder?
Das weiß er auf dieselbe Weise, wie es ein normaler Spieler auch weiß: Indem er das Feld betritt und gesagt bekommt, ob da ein Monster ist, oder nicht.
Hast Recht^^
Du mußt dich halt entscheiden, ob du die NPC eher monsterartig programmierst, d.h. sie sind Teil der Umgebung, in der sich die PC bewegen, oder ob du sie botartig programmierst, d.h. sie sind im Prinzip computergeführte Spieler. Der Aufwand, eine eigene vernünftige Intelligenz zu entwickeln, um die NPC botartig durch die Welt rennen zu lassen, ist deutlich höher - und es bedeutet, dass die NPC auch irgendwelche Ziele verfolgen durch ihre Existenz, die möglicherweise im Widerspruch zu den Zielen der PC steht.
Eigentlich sollten die NPCs das Spiel etwas lebhafter gestalten und in Bewegung (momentan z.B: um Monster anzugreifen und neue auferstehen zu lassen). Sie sollen also Spieler sein.
Im Moment verfolgen sie eher keine Ziele, sie laufen immer in eine zufällige Richtung (1-8) und greifen dort alle Monster an, die sie töten können, nehmen alle Items auf usw.
Sie merken sich allerdings schon Items, die sie benötigen und planen leicht im Voraus.
Alles eine Sache der KI...
Wenn mir zum zehnten Mal ein streunender NPC das Monstergold wegschnappt, während ich halbtot auf der Wiese liege, werde ich vermutlich etwas ungehalten. :)
Ja, so viele NPCs gibt es ja nicht. Bei 1000 Feldern hatte ich vielleicht so an 20 gedacht, damit wäre genug Platz für alle. Abgesehen davon, dass die sowieso nicht an geheime Orte kommen, oder sie müssen ziemlich viel GLück haben^^
Gruß,
Phaltôn
OK, Thema ist erledigt.
Ich habe keine eurer Ideen benutzt, weil sie mir alle zu kompliziert erschienen (zumindest empfand ich sie so).
Meine Lösung war jetzt:
Ich habe ein Perl-Skript erstellt. Im Gegensatz zu PHP hat Perl kein max_execution_time (ich weiß, bei PHP kann man das umstellen, aber das verlangsamt den Server etc.).
Das bedeutet, ich hab einfach das Skript ausgeführt und das Fenster geschlossen.
Seitdem läuft diese "Engine" reibungslos jede Sekunde, denn in dieser Zeit ruft die Perl-Datei immer wieder ein anderes PHP-Skript auf.
Ich danke euch jedenfalls für eure Hilfe!
Moin!
Ich habe ein Perl-Skript erstellt. Im Gegensatz zu PHP hat Perl kein max_execution_time (ich weiß, bei PHP kann man das umstellen, aber das verlangsamt den Server etc.).
Nein, die max_execution_time sollte auf die Geschwindigkeit keinerlei Einfluß haben. Hast du Quellen zu diesem Effekt?
- Sven Rautenberg
Nein, nein. So meinte ich das nicht. Bei Perl gibt es standardmäßig kein max_execution_time, bei PHP schon. Meine Erfahrungen haben gezeigt, dass der Server langsamer wird, wenn die ganze Zeit eine PHP-Datei im Hintergrund läuft.
VIelleicht ist es besser so, weil sie immer neu aufgerufen wird, vom Perl-Skript eben...
Hello,
Nein, nein. So meinte ich das nicht. Bei Perl gibt es standardmäßig kein max_execution_time, bei PHP schon. Meine Erfahrungen haben gezeigt, dass der Server langsamer wird, wenn die ganze Zeit eine PHP-Datei im Hintergrund läuft.
Wenn sie "läuft" und etwas tut sicherlich.
Aber wenn ich Dich richtig verstanden habe, willst Du den Prozess doch die meiste Zeit warten lassen z.B. mit sleep(1). Dann würde er während der Schlafzeit fast keine Prozessorlast bedeuten und nur im übrigen Teil der Schleife ein wenig mit Bedinungsauswertung zu tun haben, solange dann nicht wirklich eine davon zutriftt und es endlich 'was zu arbeiten gibt.
Das macht PERL bestimmt nicht anders, es sei denn, man arbeitet mit Signalen.
BTW: kann man PHP-Prozesse eigentlich auch auf Signale reagieren lassen?
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Genau das ist das Problem, ich kenne keinen sleep-Befehl in PHP.
Hallo Phaltôn.
Genau das ist das Problem, ich kenne keinen sleep-Befehl in PHP.
Hmm, wie wärs denn mit http://de.php.net/sleep?
Servus,
Flo
Oh! Also davon hab ich überhaupt nichts gewusst... Ich dachte immer, PHP ist eben nicht so zeitorientiert mit Skript weiter ausführen lassen und so...
Hmm, danke!^^
