Hoi
Wir arbeiten gerade an einem RPG und möchten mit PHP, JS und Ajax eine richtige Karte einbauen, auf der die Spieler durch die Welt reisen können. Sie soll 2D werden und auf Tiles basieren. Jetzt stehen wir vor der Frage, wie wir das genau umsetzen sollen. Layer muss es geben, klar. Spieler müssen ja hinter Bäumen/Gebäuden etc. laufen können und Bäume müssten z.B. Gebäude verdecken können. Ein bestimmter Layer könnte so hoch wie der Spieler sein, der Spieler kann also nicht drüber hinweg oder unten durch laufen. Eine Wand eben. Würde es bei dieser Lösung einen Haken geben, den ich übersehen hab? Und wieviele Layer müsste es geben?
Alternativ könnten wir auch jedem Feld ein Attribut geben, also bei einem Objekt, dass die gleiche Höhe wie der Spieler haben soll, einfach ein "Block" oder so draufsetzen. Aber auch hier könnte es vielleicht wieder etwas zu beachten geben ... Für NPCs könnten wir doch einfach eine Grafik auf die Map setzen und ein Script/Event auf das Feld setzen, oder?
Ich konnte bis jetzt alles irgendwie lösen, aber was Grafiken angeht... puh, da hab ich einfach kein Vorstellungsvermögen und keine Ahnung von nix. *gg*
Wäre nett, wenn mir da jemand ein wenig hilft. Wir möchten ja keine blöden Fehler am Anfang machen.
Edit: Achja, bin kein Programmierer im Team, das vorweg.
Gruss
Daniel
Begehbare Karte: Tiles, Layer, ... - wie?
gepostet vor 16 Jahre, 9 Monate von Flurex
gepostet vor 16 Jahre, 9 Monate von nOnAmE^
Morgen,
sowas in der Art hab ich auch schon mal probiert.
Das Ganze funktioniert soweit auch schon ganz gut. Die ersten Probleme gab es dann mit den Collisionen.
Sprich wenn die Figur auf der Karte läuft, muss man ja ständig abfragen, ob etwas im Weg steht, damit die Figur halt geblockt wird, falls ein Baum davor steht.
Bei ca. 20 solcher Hindernisse war die Laufanimation nicht mehr flüssig ...
Daher hab ich das mit Javascript etc. abgebrochen und gelassen.
Vielleicht hat dafür auch jemand eine Idee oder einen Vorschlaf
MfG.
Patrick
sowas in der Art hab ich auch schon mal probiert.
Das Ganze funktioniert soweit auch schon ganz gut. Die ersten Probleme gab es dann mit den Collisionen.
Sprich wenn die Figur auf der Karte läuft, muss man ja ständig abfragen, ob etwas im Weg steht, damit die Figur halt geblockt wird, falls ein Baum davor steht.
Bei ca. 20 solcher Hindernisse war die Laufanimation nicht mehr flüssig ...
Daher hab ich das mit Javascript etc. abgebrochen und gelassen.
Vielleicht hat dafür auch jemand eine Idee oder einen Vorschlaf
MfG.
Patrick
gepostet vor 16 Jahre, 9 Monate von Kapsonfire
kann das mit javascript überhaupt nicht empfehlen
optimaler wäre java oder flash (ich präferiere flash)
javascript ist meiner meinung nach nicht für soviele daten geeignet die auch alle gespeichert werden müssen oder per ajax schnell nachgeladen werden (es muss jedesmal wieder eine http verbindung aufgebaut werden) was über java oder flash besser läuft
falls ich irgendwas falsch gesagt habe tut mir leid^^
optimaler wäre java oder flash (ich präferiere flash)
javascript ist meiner meinung nach nicht für soviele daten geeignet die auch alle gespeichert werden müssen oder per ajax schnell nachgeladen werden (es muss jedesmal wieder eine http verbindung aufgebaut werden) was über java oder flash besser läuft
falls ich irgendwas falsch gesagt habe tut mir leid^^
gepostet vor 16 Jahre, 9 Monate von Todi42
Original von Browser-Games Worldfalls ich irgendwas falsch gesagt habe tut mir leid^^
Es gibt keine Steigerung von optimal ;-)
gepostet vor 16 Jahre, 9 Monate von Flurex
Nun gut...
Kann jemand Flash und will mitmachen?
Mal angenommen wir versuchen es erstmal mit JavaScript/Ajax. Wie würdet ihr das mit den Layern etc. lösen?
Kann jemand Flash und will mitmachen?
Mal angenommen wir versuchen es erstmal mit JavaScript/Ajax. Wie würdet ihr das mit den Layern etc. lösen?
gepostet vor 16 Jahre, 9 Monate von nOnAmE^
Aufgebaut hab ich das Ganze mit einem 500x500px Layer. Dies war die Karte.
Dann die Figur 30x15px.
Via Onclick wurde die X und Y Position berechnet und die Figur hat sich bewegt.
Das Ganze funktioniert ohne Hindernisse wunderbar.
Bäume hab ich dann in zwei Layer unterteilt. Ein Layer für die Baumkrohne (Figur konnte dahinter laufen mit z-index gelöst) und der zweite für den Stamm.
Nach ca. 10 Bäumen, lief die Figur aber schon nicht mehr flüssig auf der Map.
Dann die Figur 30x15px.
Via Onclick wurde die X und Y Position berechnet und die Figur hat sich bewegt.
Das Ganze funktioniert ohne Hindernisse wunderbar.
Bäume hab ich dann in zwei Layer unterteilt. Ein Layer für die Baumkrohne (Figur konnte dahinter laufen mit z-index gelöst) und der zweite für den Stamm.
Nach ca. 10 Bäumen, lief die Figur aber schon nicht mehr flüssig auf der Map.
gepostet vor 16 Jahre, 9 Monate von Kapsonfire
Original von Todi42
Original von Browser-Games Worldfalls ich irgendwas falsch gesagt habe tut mir leid^^
Es gibt keine Steigerung von optimal ;-)
hmmm ja stimmt
optimierter hört sich auch blöd an also
denkt euch statt optimal einfach besser^^
achja wie man das lösen könnte wäre je weiter hinten ein feld ist desto eine niedrigere index bekommt es
und für den musste das dann auch immer ändern je nachdme ob er hoch oder runter geht
ansonsten musst du mit absolute arbeiten und gucken wie groß ein feld sein soll^^
gepostet vor 16 Jahre, 9 Monate von None
Das Problem liegt weniger an der Performance von JavaScript, als viel mehr an der für Grafische Spielereien nicht geeigneten Browserengines.
Statische Grafiken... perfekt. Animationen welche per Blitting reinkommen... perfekt.
Manuelles Blitting von Grafiken in der Browserengine selbst... no go.
Das wird wohl auch immer so bleiben. Für so etwas, sollte man eher auf Flash o.ä. ausweichen. Das ist dafür absolut geeignet. Zwar grausam zu programmieren, aber von der Performance her noch mit eine der besten Lösungen.
Schon traurig das die heutigen Browser so schlecht sind. Zu meiner Zeit konnte man auf den alten 8 Bit Rechner (1.97 Mhz) mehr Animationen realisieren und darstellen, als die Browser heute packen. Traurig sowas... aber egal... deren Ursprung war ein anderer und wir mißbrauchen sie bei solchen Sachen mit Dingen, wofür sie nie designt wurden.
Just my 2 cents.
Statische Grafiken... perfekt. Animationen welche per Blitting reinkommen... perfekt.
Manuelles Blitting von Grafiken in der Browserengine selbst... no go.
Das wird wohl auch immer so bleiben. Für so etwas, sollte man eher auf Flash o.ä. ausweichen. Das ist dafür absolut geeignet. Zwar grausam zu programmieren, aber von der Performance her noch mit eine der besten Lösungen.
Schon traurig das die heutigen Browser so schlecht sind. Zu meiner Zeit konnte man auf den alten 8 Bit Rechner (1.97 Mhz) mehr Animationen realisieren und darstellen, als die Browser heute packen. Traurig sowas... aber egal... deren Ursprung war ein anderer und wir mißbrauchen sie bei solchen Sachen mit Dingen, wofür sie nie designt wurden.
Just my 2 cents.
gepostet vor 16 Jahre, 9 Monate von Nuky
ich würde das feld wo der baumstamm draufsitzt als blocked deklarieren, und den spieler sich nicht ganz frei bewegen lassen.
wenn du eine karte mit grafik-tiles von 64x64 aufbaust(hausnummern) und die tiles nochmal in 12x12 unterteilst, und für diese nachsiehst ob diese begehbar sind und den pfad selbst ausrechnest, dürfte das nicht so schlimm sein - auch javascript lässt sich toll optimieren..
der ansatz die kronen auf einen höheren z-index zu setzen ist auch gut.
wichtig ist, dass du dem client auch etwas caching zutraust (und IM VORAUS ladest, nicht erst wenns im sichtfeld ist), dann müsste das auch ein flüssiges spielerlebnis geben. falls es etwas ruckeln sollte, würd ich dir einstellbare spielfeldgrößen (ala 300x200, 640x480...) empfehlen, das die spieler dann je nach leistung wählen können.
solang du nicht allzuviel mit opacity arbeitest, müsste das ganze wie gesagt funktionieren.
wenn du eine karte mit grafik-tiles von 64x64 aufbaust(hausnummern) und die tiles nochmal in 12x12 unterteilst, und für diese nachsiehst ob diese begehbar sind und den pfad selbst ausrechnest, dürfte das nicht so schlimm sein - auch javascript lässt sich toll optimieren..
der ansatz die kronen auf einen höheren z-index zu setzen ist auch gut.
wichtig ist, dass du dem client auch etwas caching zutraust (und IM VORAUS ladest, nicht erst wenns im sichtfeld ist), dann müsste das auch ein flüssiges spielerlebnis geben. falls es etwas ruckeln sollte, würd ich dir einstellbare spielfeldgrößen (ala 300x200, 640x480...) empfehlen, das die spieler dann je nach leistung wählen können.
solang du nicht allzuviel mit opacity arbeitest, müsste das ganze wie gesagt funktionieren.
gepostet vor 16 Jahre, 9 Monate von Macavity
Hm wir haben das über JS umgesetzt und nach diversen Anpassungen funktioniert es sehr gut und auch sehr flüssig. Wir haben uns aber auch den Luxus rausgenommen das Spieler mit alten oder inkompatiblen Browsern nicht auf diesen Teil kommen sondern ein alternatives unschönes Interface bekommen.
Wir haben 4 Layer, 3 Unter dem Spieler und eine über dem Spieler. Kollision wird über ein Array extra gespeichert und ist so schnell abfragbar.
Wir haben 4 Layer, 3 Unter dem Spieler und eine über dem Spieler. Kollision wird über ein Array extra gespeichert und ist so schnell abfragbar.
gepostet vor 16 Jahre, 9 Monate von Biki
Danke schonmal für die ganzen Antworten von euch (ich bin der Kollege & Programmierer von Flurex), das hat uns schon sehr geholfen
Allerdings stehe ich jetzt vor einem anderen Problem. Nämlich, wie ich wie eine Map am Besten in der (normalisierten) DB speichere. Irgendwelche Tipps?
Kann auch sein, dass ich grade nur bissl neben der Kappe bin (ist schon spät), aber mir will einfach nichts einfallen. (Der Map-Layer ist 512px X 512px, bzw., 15X und 15Y groß).
Über jeden Tipp wären wir sehr dankbar
Allerdings stehe ich jetzt vor einem anderen Problem. Nämlich, wie ich wie eine Map am Besten in der (normalisierten) DB speichere. Irgendwelche Tipps?
Kann auch sein, dass ich grade nur bissl neben der Kappe bin (ist schon spät), aber mir will einfach nichts einfallen. (Der Map-Layer ist 512px X 512px, bzw., 15X und 15Y groß).
Über jeden Tipp wären wir sehr dankbar
gepostet vor 16 Jahre, 9 Monate von ThaDafinser
x und y als primary key?
und daneben nen status z.B. 1 für freie fläche und 2 für nen baum oder so?
und den status in ne extra tabelle
und daneben nen status z.B. 1 für freie fläche und 2 für nen baum oder so?
und den status in ne extra tabelle
gepostet vor 16 Jahre, 9 Monate von None
Du könntest es auf die alte Art und Weise machen, in dem du zum einen mit Pattern arbeitest und zum anderen aus X und Y eine feste Koordinate ermittelst, welche gleichzeitig die ID der Zeile ist.
So hätte man es früher gemacht. Heute...
Es gibt nur eine Map für alle, oder?
Wenn ja, dann hau das in eine normalisierte Tabelle und sorge dafür, dass diese den Hauptspeicher nicht verlässt.
Entweder nimmst du einen passenden Tabellentyp, oder du baust dir eine Art Cachingmechanismus.
So hätte man es früher gemacht. Heute...
Es gibt nur eine Map für alle, oder?
Wenn ja, dann hau das in eine normalisierte Tabelle und sorge dafür, dass diese den Hauptspeicher nicht verlässt.
Entweder nimmst du einen passenden Tabellentyp, oder du baust dir eine Art Cachingmechanismus.
gepostet vor 16 Jahre, 9 Monate von Biki
Danke euch
Bin nun schon weiter.
Gruß,
Biki
Bin nun schon weiter.
Gruß,
Biki
gepostet vor 16 Jahre, 9 Monate von Macavity
Zwischenfrage, wieso in die DB?
gepostet vor 16 Jahre, 9 Monate von MrMaxx
HiHo Flurex...
Wenn ich das richtig sehe haben wir eine ähnliche Vorstellung von unserer "Kartenansicht".
Wenn du willst kannst du dir ja mal meine WIP Version anschaun => overwatch.de:8080/overwatch
Ich hab dir mal meinen Skype/ICQ/Jabber Kontaktmöglichkeiten geschickt, falls du Lust hast mal über das Thema und welche Erfahrungen wir gesammelt haben zu quatschen.
So long...
Maxx
Wenn ich das richtig sehe haben wir eine ähnliche Vorstellung von unserer "Kartenansicht".
Wenn du willst kannst du dir ja mal meine WIP Version anschaun => overwatch.de:8080/overwatch
Ich hab dir mal meinen Skype/ICQ/Jabber Kontaktmöglichkeiten geschickt, falls du Lust hast mal über das Thema und welche Erfahrungen wir gesammelt haben zu quatschen.
So long...
Maxx
gepostet vor 16 Jahre, 9 Monate von Biki
Original von Macavity
Zwischenfrage, wieso in die DB?
Anderen Vorschlag?
Denkbar (für mich) wäre noch jede Map in eine eigene .php Datei schreiben, am Besten wohl in ein Array, und das dann auslesen.
gepostet vor 16 Jahre, 9 Monate von Nuky
Nein. Tus nicht - für dich selbst.
Wenn du unbedingt willst kannst du von der DB in ein File lesen und das dann auslesen; würd ich auch nur empfehlen, wenn die db ineffizient wird (sehr unwahrscheinlich).
Wie vor kurzem jemand hier gesagt hat, ist die DB auch nicht viel was anderes als ein Dateisystem - nur meist optimierter und dynamischer, wenn ich das anmerken darf.
Wenn du unbedingt willst kannst du von der DB in ein File lesen und das dann auslesen; würd ich auch nur empfehlen, wenn die db ineffizient wird (sehr unwahrscheinlich).
Wie vor kurzem jemand hier gesagt hat, ist die DB auch nicht viel was anderes als ein Dateisystem - nur meist optimierter und dynamischer, wenn ich das anmerken darf.
gepostet vor 16 Jahre, 9 Monate von Fornax
Original von MrMaxx
Wenn du willst kannst du dir ja mal meine WIP Version anschaun => overwatch.de:8080/overwatch
Hm.. Also einloggen und registrieren geht nicht, da die Seite unendlich lange läd.
gepostet vor 16 Jahre, 9 Monate von MrMaxx
sollte jetzt wieder funktioneren...
Ah ja...wenn du ein Spiel gestartet hast gibt es 3 kästchen oben rechts:
Das erste schaltet die Minimap an/aus. Mit dieser kannst du deinen ViewPort bewegen. Der zweite ist der wichtigste, er schaltet die Phasen weiter (und startet somit auch das Spiel). Nummer drei zeigt einfach nur die Runde an.
Das ganze ist noch sehr sehr Userunfreundlich, aber diesem "Feintuning" widme ich mich erst, wenn das Grobe fertig ist.
So long...
Maxx
EDIT: Irgendwie ist das Spiel im Moment seehr langsam auf dem live-system. Das dev-System daheim macht diese Zicken jedoch nicht
Ah ja...wenn du ein Spiel gestartet hast gibt es 3 kästchen oben rechts:
Das erste schaltet die Minimap an/aus. Mit dieser kannst du deinen ViewPort bewegen. Der zweite ist der wichtigste, er schaltet die Phasen weiter (und startet somit auch das Spiel). Nummer drei zeigt einfach nur die Runde an.
Das ganze ist noch sehr sehr Userunfreundlich, aber diesem "Feintuning" widme ich mich erst, wenn das Grobe fertig ist.
So long...
Maxx
EDIT: Irgendwie ist das Spiel im Moment seehr langsam auf dem live-system. Das dev-System daheim macht diese Zicken jedoch nicht
gepostet vor 16 Jahre, 9 Monate von progs
Hab mir das mal angeschaut, schaut ganz gut aus.
Nur, wenn ich auf der Minimap auf ein Tile klicke, zeigt er im Hintergrund Meldungen an (Screen executeScroll width currentX = 0 and CurrentY = 0) und mein Browser (IE7) stürtzt ab.
Nur, wenn ich auf der Minimap auf ein Tile klicke, zeigt er im Hintergrund Meldungen an (Screen executeScroll width currentX = 0 and CurrentY = 0) und mein Browser (IE7) stürtzt ab.
gepostet vor 16 Jahre, 9 Monate von Macavity
Nein. Tus nicht - für dich selbst.
Wenn du unbedingt willst kannst du von der DB in ein File lesen und das dann auslesen;
Irgendwie zweifel ich daran das es schneller ist einen Inhalt aus der DB anstatt direkt aus einer Datei auszulesen Oo
Meine Frage "Warum DB" bezog sich darauf das meist in der DB die einzelnen Felder, ihre Optik und diverse Objects gespeichert sind und dies dann dynamisch zu einer Map generiert und möglicherweise haufenweise JS ebenso. Relativ lahm finde ich, also warum nicht direkt ein JS generieren das alle Mapdaten beinhaltet anstatt den Umweg über DB & PHP-Generierung zu gehen?