Zelda AKS mit Pixelmovement

Zelda AKS v1.0


Endlich hab ich's geschafft, dank nochmal an:
-Zidane FFIX (für deine Hilfe)
-Makenshi (für die Inspiration ein Zelda KS zu makern)
-Wachenröder (für die Ressourcen, die ich mir aus deinem Script geborgt hab^^)

Aber nun zum Inhalt des Scriptes..


Features:
- Pixelmovement in 8-Richtungen (diagonal)
- Kollisionsabfragen mit Umgebungund Events
- normaler Angriff
- Wirbelattacke (durch Gedrückthalten)
- Gegenstände (Büsche) hochheben/ werfen
- 1 Gegner
- Mapwechsel (1 Haus)
- Joypadunterstützung (durch JoyToKey)


Systemvorraussetzungen:
Minimum
2 GHz Prozessor
256MB Ram

Empfohlen
2,5GHz Prozessor (oder mehr^^)
512MB Ram

Ihr benötigt keinen installierten Keypatch und kein installiertes RTP. Das Script sollte auf jedem Rechner (der schnell genug ist) auch ohne den Maker laufen.
Die deftigen Hardwarevorraussetzungen könnte man mit Feintuning des Scriptes sicher noch um 50% oder mehr senken. Ist zwar unwahrscheinlich, dass ich mich da noch mal dransetze, aber vielleicht in einer späteren Version..

Screens:

http://www.GoRyoSaeba.de/ftp/s01.jpg

http://www.GoRyoSaeba.de/ftp/s02.jpg

http://www.GoRyoSaeba.de/ftp/s03.jpg

http://www.GoRyoSaeba.de/ftp/s04.jpg


Download:
Der Download wurde aufgrund der Forenregeln (Fanspiele sind nicht erlaubt) entfernt.



Wenn ihr ein Joypad verwenden wollt, müsst ihr vor dem Starten des Scripts die JoyToKey.exe öffnen, und diese laufen lassen (am besten minimiert). Natürlich könnt ihr die Joypadbelegung auch ändern, bei Problemen, lest die beigefügte JoyToKey-Readme oder postet in diesen Thread.
Das Script ist leider nicht frei von Bugs aber sollte spielbar sein..

Meinungen, Anregungen und Fragen bitte hier rein.
Viel Spaß^^

Ui, das gefällt mir.
Das System ist ausgeklügelt und funktioniert einwandfrei, aber einen Bug habe ich gefunden: wenn man die rötlichen Dinger (diese Teile, die auf dem zweiten bild links von den Büschen sind) hochhebt, oder besser gesagt, es versucht, hat man einen Strauch auf den Händen. Etwas unlogisch.^^'

Desweiteren läuft alles noch ein wenig langsam ab, das liegt aber evtl. am Rechenaufwand.

Alles in allem muss ich aber sagen, dass das System mir gut gefallen hat und es mir in einem Spiel sehr gut gefallen würde. Planst du/ihr so etwas?

Wirklich gut ! Habe bisher noch nie ein besseres Zelda KS gesehen. Das Pixelmovement ist auch gut gelungen, auch wenn es sich imo nicht auf das Schwert ausgewirkt hat (irre ich mich ?)

Wie bereits vom Vorredner gesagt, ist das ganze einwenig langsam (wobei meine Werte ziemlich weit über den empfohlenen liegen.)


Ich hoffe, jetzt kommen mal einpaar tolle Zeldagames, bisher war das KS ja der einzig schwer umsetzbare Punkt an Zeldagames.

Einen Bug habe ich noch gefunden: Bevor der Gegner mich trifft, wird er kurz unsichtbar.

Seltsam. Ich hab 2.8 GHz und 512 MB, aber das Teil lässt sich sowenig spielen wie ne saure Gurke mit Schlagsahne. o0

Sehr gut! Einfach sehr gut! Das ist genau das was ich brauchte!
MfG, Oburi
PS. @ Ryo: Du hast ne PM

Schön, schön...
...aber sind ein paar Buggs drinnen:
- man kann die Türe hochheben, und dabei erscheint ein Busch
- wenn der Gegner auf der Map ist und man hebt einen Strauch hoch
läuft man automatisch in die Richtung, in der man beim Hochheben
gekuckt hat

Das mit dem Laufen hatte ich auch. Allerdings liegt das glaube ich nicht am Gegner. Wenn man beim aufheben eines Buschens in eine Richtung drückt und diese dann sofort loslässt, bewegt sich der Held solange in die Richtung weiter (selbst wenn man ihn in die entgegengesetzte Bewegt (dann bewegt er sich dahin und läuft, nachdem man die Taste losgelassen hat einfach munter weiter in die erste Richtung)) bis man erneut die Taste in die Richtung in die er läuft, drückt.

Mein PC ist nicht gerade der neuste, also kann ich nicht ganz sagen, wie es so läuft. Bei mir hat es (solange der Gegner auf der Map war) extrem geruckelt, und wenn ich versucht habe mit dem Schwert anzugreifen, wurde scheibar zwar der Schaden berechnet, ich sah aber keine Animation...

Ein Punkt, der vieleicht noch zu verbessern wäre (weiß nicht genau ob das möglich ist (hab mir den Code noch nicht angesehen)) ist das, ja, wie soll ich sagen? Das "Schräge". Bin mir jetzt nicht sicher ob das am Ruckeln lag, aber beim normalen Zelda wird ab einem bestimmten Punkt der Held, wenn er gegen eine Wand läuft, in die Richtung der nächsten Öfnung bewegt. D.h. wenn ich z.B. die Tür knapp verfehle und statdessen nur den Türrahmen erwische, rutsche ich automatisch in die Tür rein. Das war hier, vor allem wegen dem ruckeln, etwas schlecht, da ich so einmal zwischen den Büschen feststeckte und nicht rauskam (außer durch zerhacken der Büsche).
Das man den Gegner mit einem Busch auch treffen kann ist sehr gut gemacht (hatte man in bisherigen Zelda-KS soweit ich weiß nicht).

Alles in allem ein sehr gutes KS womit man noch einiges machen kann. Ein weiterer Schritt in der Maker-Geschichte :A

1.8 Ghz, 512mb ddram, läuft absokut flüssig, hab aber probleme mit dem aufheben von sträuchern und mit dem rundumschlag (Held läuft von alleine nach rechts, rundumschlag will nicht funktionieren).

1A, ich bin stolz auf dich.

Edit:
Hm, mir ist aufgefallen das es da ziemlich große Bugs gibt wenn man mit gedrückter 0-Taste, sprich vorbereitetem Rundumschlag ins Haus läuft. Manchmal hört man einen Busch, der zerschnitten wird (mit Animation.) Und manchmal, da erscheint der Gegner im Haus (ich hab ihn ganz oben links gesehen, wahrscheinlich da wo der Gegner zuletzt auf der anderen Map war, unsicher). Anschließend wurde ich von allen Seiten aus dem Nichts angegegriffen, bis game over war :O!

Edit2:
Ay, mir sit aufgefallen das man bei gedrückter 0-Taste noch einen Busch aufheben kann. Und - äh - das sollte man glaub ich nicht o.o.

läuft 1A das Script ist Ginial nur Ganz erlich glaube ich NICHT das sich jeh jemand die Mühe machen wird es in sein Spiel einzubauen da es IMO sehr viel Arbeit ist mit jeder Map die Bäume etz. Da muss man schon viel langeweile haben.

Aber sonst n1 echt ginial

Ja, das Zelda Ks ist wirklich gut gelungen :D
Einfach gut...
Viel mehr kann man dazu auch nicht sagen... ;)

Mfg Tscheme

Hey, das ist echt mal ein cooles Zelda-KS ;):A

Kann es sein, dass es fast das gleiche ist, wie damals das Pixelmovement-Skript, dass jemand (afaik du, Ryo) hier gepostet hat? ^^
Es sit auf jeden Fall richtig gut gelungen, lediglich der Wirbelschlag hätte schneller sein können ^^

Und nen Bug hab ich gefunden:
Wenn man, während man einen Busch hochhebt, in eine Richtung drückt, läuft Link so lange in die Richtung, bis die Richtungstaste für diese Richtung wieder gedrückt und losgelassen wurde...sofern das jetzt jemand verstanden hat xD

Naja, ansonsten das wohl beste Zelda-KS das es gibt. Besser gehts fast nimmer :A

@Phönix Tear: Das mit dem "Reinflutschen" ist prinzipiell einfach, aber aufwendig einzubauen und kostet auch wieder mehr Leistung, da die Kollisionsabfrage um ein paar Forks bereichert wird^^ Ich hatte auch mal vorgehabt eine Kollision für diagonal verlaufende Hindernisse einzubauen, aber naja, kostet auch wieder Leistung. Beim mir ruckelte es btw auch ziemlich auf meinem alten 1GHz Rechner, sodass ich von den Schwertschlaganis nix mitbekommen hab xD. Bei der Wirbelattacke hab ich's etwas anders gemacht (man sieht also, dass ich mit der Zeit bessere Wege fand, aber den alten Code nicht immer verbessert hab) wodurch die sogar einigermaßen flüssig lief.
Das mit den Büschen gab's afaik schon in Wachenröder's Script.

@V-King: Das Zelda Script baut auf meinem Secret of Mana KS Betading auf, ja^^ Hatte damals nachdem mir ein Festplattencrash 10h Arbeit vernichtete, keine Motivation mehr, aber hab dann das Ganze für Zelda umgebaut/ erweitert. (auch weil mein Pixelscrolling mit draufging und ich das für mein Zeldascript sowieso nicht nutzen kann).


PS: hier nochmal eine Liste aller mir bekannten Bugs, falls ich welche vergessen hab, sagt pls bescheid^^

bekannte Bugs:
- wenn man beim Aufheben in eine Richtung drückt, läuft Link ungewollt weiter in diese Richtung
- man kann die Pflöcke (rechts neben dem Haus) hochheben als wären es Büsche
- ebenso die Tür
- wenn man die Wirbelattacke aufläd, muss man warten bis das schwert anfängt zu blinken, wenn man zu früh loslässt, funktioniert die Wirbelattacke danach einmal nicht
- der Gegner verschwindet manchmal, wenn man getroffen wird
- der Gegner kann einen im Haus attackieren
- beim Screenwechsel (PanScreen) kommt es zu Anzeigeproblemen des Gegnersprites

Wie geil, du hast es echt noch fertig gestellt^^
Ich interessiere mich zwar weniger für die Technik, aber dieses Spielgefühl, das durch das Pixel AKS erzeugt wird, hat echt einen schönen einzigartigen Flair.

Zitat:

---

Zitat von Dr.BonesCadavre

Wie geil, du hast es echt noch fertig gestellt^^
Ich interessiere mich zwar weniger für die Technik, aber dieses Spielgefühl, das durch das Pixel AKS erzeugt wird, hat echt einen schönen einzigartigen Flair.

---

Jep, wirlklich spitze.
Das meiste wurde schon gepostet, was ich zu bemängeln habe (bzw. alles wurde schon von meinen Vorredner gesagt).

Dennis

PS: Die Steuerung ist Laptop User hassend:
Ich habe keinen Num block, also drücke ich NUM und ein teil meiner tasten wird zu einem Virtuellem Num Block:
jkluio789 wird : 123456789

So war es für mich etwas kompliziert [0] bzw. einfügen zu benutzen und dazu noch [ENTER].

Da fällt mir ein, das kann man doch in der Keydatei ändern, oder?

@Dennis: Die Tastenbelegung könnte man ändern, wenn man weiß, wie der Keypatch funktionert. An Laptopuser hab ich gar nicht gedacht, sry ich spiel alle Makergames mit Numblock, da ich lieber mit der linken Hand die Pfeiltasten bediene, wie bei einem Joypad. Eigentlich würde ich auch davon abraten, das Script mit der Tastatur zu spielen, bei manchen Tastas gibt's da nähmlich Probleme mit dem Schräglaufen, da nicht so viele Tasten gleichzeitig angesprochen werden können, außerdem steuert sich's mit Joypad natürlich auch um Längen besser.

@FF I Weißmagier: Thx, ich werd mal versuchen die Fehler zu reproduzieren. Welchen Busch konntest du nach dem Zerhacken nicht betreten? War das ein Bestimmter, weißt du das noch?

Noch ein paar Bugs:
- Der Gegner "erscheint" nur im Haus, wenn man ihn vorher
auf der Map gesehen hat und ihn dann nicht kalt gemacht hat,
auserdem muss man so die Mitte des Hauses bereten.
also: wenn man das Haus verlässt und sofort wieder betritt, erscheint der
gegner nicht. sollte man nach verlassen des Hauses ihn nur kurz sehen
(zb. oberen Bildschirmecke ) erscheint er, wenn man die Mitte des
Hauses betritt.
- wenn man den Gegner gekillt hat, und auf die Stelle wo er gestorben
ist von oben einen Busch wirft, dann wir nochmal die Animation
gezeigt, wo der Gegner stibt. (geht nur von oben)
- wenn man den Wirbelschlag macht und dabei die Tasten trückt,
führt Link erst alle nach dem Schlag aus.
zB. wenn man bei dem Wirbelschlag hoch, runter, links, rechts, "0"
drückt, guckt Link erst in alle Richtungen und zieht anschließend
kurz das Schwert.
- habe es auch mal geschafft, dass Link das Schwert immer gezogen
hatte, und beim Drücken der "0"-Taste ging kurz das Schwert weg
und dan hat er geschlagen und danach sofort wieder gezogen.
(habs 3x geschafft weis nur nicht wie)

viel Glück beim entbuggen

üH

Ich muss sagen ich bin beeindruckt. Ist auf jeden Fall besser als mein KS...
Dafür braucht meins nicht so ´nen guten Rechner.

Zitat:

---

Zitat von Gruz

Seltsam. Ich hab 2.8 GHz und 512 MB, aber das Teil lässt sich sowenig spielen wie ne saure Gurke mit Schlagsahne. o0

---

Dann mach die Pornos im Hintergrund aus :D
Ansonsten sehr geil, besonders mit der Joypadbelegung.. das werde ich nachher gleich mal testen ^^

Schöne Features, schöne Screens, schöne Vorraussetzungen und vorallem aus der schönen alten Zeit. Es wird noch was zu zocken geben, schön. Werde gleich mal zocken. :) Werde Bugs dann selbst beseitigen. ;)

Zitat:

---

Zitat von Christianjunck

Werde Bugs dann selbst beseitigen. ;)

---

Viel Spaß^^ Bei einigen kleineren Bug mag das ja gehen, aber bei den meisten muss man schon wissen wie das Script aufgebaut ist, um nicht einen Bug durch den nächsten zu ersetzen. Aber wenn du dir das zutraust, why not.. aber sei mir nicht bös, wenn ich nicht glaube, dass du das schaffst.

Sag aba bescheid, falls du erfolgreich warst^^

Vielleicht werde ich das Script auch selber mal entschlacken, aber momentan sieht's etwas duster aus, da ich gar keinen Maker draufhab..

@FF1 White Mage: Öhm akso^^ jap, das hab ich erstmal einfach gelöst, indem man halt diagonal laufen muss um in die Lücken zu flutschen^^ Dürfte aber eigentlich problemlos funktionieren, besonders mit 'nem Gamepad.

Respekt, Respekt.

Ich habs jetzt nur kurz angestestet, dabei kamen keinen schwerwiegenden Fehler. Lediglich bei dem Großen Bereich mit den Büschen ist link, wenn man das schwert geschwungen hat und daraufhin weiterhin festhielt, nicht auf das Feld vor ohm gegangen, wo zueben ein Busch zerstört wurde... Desweiteren gehen die Büsche mit gezogener Klinger nicht weg, wenn man gegen sie latscht (das war nen Feature von A Link to the Past, afair)

Ansonsten wirklich gut, von der Performence her. Link bewegt sich nur etwas langsam, genau wie der Gegner. Aber das kann unter umständen an meinem Laptop liegen...

Hab nen Intel Pentium M 1,6 Ghz (also mit Centrino Tech.), ner 64 MB Grafikkarte... ehm... irgendwas... ATI Readon Mobile...
und 512 MB Arbeitsspeicher...

Beim Drehschwung fiehl es auf, dass es etwas langsam lief.
Ich hab allerdings mal ein Jump'n Run Skript erstellt, mit Pixel Bewegungen und recht aufwändig animiert und das lief ohne weitere Probleme...
Und ich denke das Skript war vom Rechnen-Aufwand nicht viel weniger schwerlastig als dieses Zelda-Skript...
Also ich schätze es dürfte eigentlich nicht langsam laufen... oder ist die Drehattacke absichtlich etwas langsamer?

(ich meine... normalerweise ist da ja kein Slowdown-Effekt, sondern ein stocken... von daher... )

Ich hatte auch mal im Kopf gehabt, so ein Skript zu probieren (da ich RM2k-treu bin und auch mit den Patches nicht so vertraut bin natürlich ohne Diagonale Bewegung...), was mich dann immer zögern ließ, ist die Anzeige der Sprites, die sich durch die Map bewegen. Genauer gesagt ist es problematisch, wenn diese Sprites so nah zusammen stehen, dass sie sich überlappen. Sie können ja einmal so übereinandern stehen und einmal umgekehrt... Um da immer eine richtige Anzeige zu haben muss man zwangsläufig die Picture ID der Sprites ändern (oder alternativ das Sprite in zwei Grafiken aufteilen, wobei die obere hälfte ne Höhere Picture ID hat... aber 2 Pictures pro Figur? Mir wäre das zu aufwändig...)

Sigh... alles wäre soviel einfacher, wenn man Variablen für die Picture ID angeben könnte...

Könnte das mal irgendwer zurechthacken? XD Das wäre mit die größte Errungenschaft für alle Extrem-Skripter (schätz ich mal)

Wie auch immer... beim Zelda-Skript fällt das Problem ja zum Glück nicht zur last, da man nie wirklich die Möglichkeit hat die Sprites nach genug ran zu bekommen, damit sie sich (langzeitig) überlappen... zumindest von unten, denn da kommt der Fehler (ich habs genau gesehen, als ich GameOver ging... ganz kurz überlappen sie sich etwas und Links Mütze verschwand unter dem Schatten des Gegners XD)
Allerdings hat Zelda auch große Gegner und spätestens hier brauch man ne Lösung für das Problem Oo

Dennoch: Respekt. Wenn ich mich recht erinnere, gehörst du sicherlich zu den besten Skriptern, die ich hier so im Maker-Bereich zu sehen bekam, Ryo Saeba.

Saubere Arbeit ^^

C ya

Lachsen

Edit: Zur Performance: Die Drehattacke scheint tatsächlich einfach so so langsam zu sein, also nicht aus performenced Gründen. Also ist die Performence, so wie ich das sehe, einwandfrei :A

Ehrlichgesagt habe ich Zelda III schon lange nicht mehr gespielt und hab bei den Animationsgeschwindigkeiten meist einfach nur grob geschätzt. Die Wirbelattacke schneller ablaufen zu lassen wäre kein Ding, einfach die entsprechenden Waits (hab da afair immer ein 0.1 drinnen) verkürzen.
Freut mich dass es auf einem 1,6GHz Rechner gut läuft^^

Bei dem großen Feld kann es daran liegen dass Link wie gesagt nicht wie im Original reinflutscht, sondern man sich da diagonal bewegen muss um reinzuflutschen, dann sollte es aber ohne Probleme gehen.

Das mit dem Gedrückthalten und Büsche/ Gegner plätten hab ich nicht mehr eingebaut, wollte ich noch zusammen mit Rennen und von Vorsprüngen runterspringen aber am Ende hat die Motivation leider dazu gefehlt, da ich da kein Spiel draus mache und am Ende nur zeigen wollte was mit dem 2k/2k3 möglich ist.

Zitat:

---

Ich hatte auch mal im Kopf gehabt, so ein Skript zu probieren (da ich RM2k-treu bin und auch mit den Patches nicht so vertraut bin natürlich ohne Diagonale Bewegung...), was mich dann immer zögern ließ, ist die Anzeige der Sprites, die sich durch die Map bewegen. Genauer gesagt ist es problematisch, wenn diese Sprites so nah zusammen stehen, dass sie sich überlappen. Sie können ja einmal so übereinandern stehen und einmal umgekehrt... Um da immer eine richtige Anzeige zu haben muss man zwangsläufig die Picture ID der Sprites ändern (oder alternativ das Sprite in zwei Grafiken aufteilen, wobei die obere hälfte ne Höhere Picture ID hat... aber 2 Pictures pro Figur? Mir wäre das zu aufwändig...)

Sigh... alles wäre soviel einfacher, wenn man Variablen für die Picture ID angeben könnte...

---

Du sprichst mir wirklich aus der Seele^^ Ich habe mir auch schon über dieses Problem Gedanken gemacht und sah nur die Möglichkeit die ganzen nötigen CE's zu duplizieren mit dem einzigen Unterschied, dass beim Duplikat eine andere Pic-ID zur Anzeige verwendet wird. Bei den zig Show und Move Pic Befehlen eine unglaubliche Arbeit, die ich mir wohl nur gemacht hätte, wenn ich mehr als einen Gegner eingebaut hätte.
So eine durch Variablen einfach änderbare Pic-ID Sache würde den Maker zusammen mit einem aufgehobenen Piclimit relativ mächtig machen.. ich war am verzweifeln als ich vor einiger Zeit für mein RTS-Interface eine Rahmenauswahl (also dass man mehrere Einheiten per pixelgenau per Maus veränderbaren Rahmen umschließen und somit auswählen kann) scriptete, da hab ich mir das sooo sehr gewünscht xD

achja, thx für das Lob^^

Nochmal Respectomondo!

Aber bei mir klappt das nur wenn ich meinen Screen mit F4 und dann F5 verkleinere sonst ruckelt es immer!

o.O Das Teil steckt voller Bugs. Was für welche?
Hier mal so eine kleine Auswahl:

- Man kann das Schwert nicht benutzen.
- Man kann aus den violetten Dingens Büsche reusziehen.
- Link läuft plötzlich einfach geradeaus und bleibt nicht mehr stehen.

So, die anderen 347'384'723 hab ich vergessen.
Sonst wäre es super, aber die vielen Bugs ;_;

Zitat:

---

Zitat von Neo Zunami

- Man kann das Schwert nicht benutzen.

---

Das stimmt nicht.

Zitat:

---

Zitat von Neo Zunami

- Man kann aus den violetten Dingens Büsche reusziehen.
- Link läuft plötzlich einfach geradeaus und bleibt nicht mehr stehen.

---

Du erzählst mir nichts neues^^ Schon die Bugliste gelesen?

Ich habs auch mal angetestet. Natürlich musste ich es vorher ein wenig "optimieren", damit es auf meinem 800 Mhz-Rechner überhaupt funktioniert. Die Idee, statt Events auf Bilder und deren Screen-Berechnung zu setzen ist zwar nicht neu, aber bisher hat es kaum jemand für den RPG-Maker wirklich durchgesetzt.
Die Qualität von Spielen lässt sich dadurch erhöhen, aber leider steigt auch der Arbeitsaufwand enorm. ;)
Ich kenne mich zwar mit Technik in Bezug mit dem RPG-Maker gut aus, aber trotzdem brauchte ich fast eine ganze halbe Stunde, um das System ganz zu durchblicken!! Ich glaube kaum, dass ein Durchschnittsmaker dieses System wirklich verwenden kann, trotzdem ist es eine äußerst gute Innovationsquelle!
Ich will deine Arbeit nicht schlecht machen (versteh mich net falsch... ;) ); ich finds richtig gut, dass es mal jemand durchgezogen hat!
Ich wäre dafür vermutlich zu faul... :D :D :D

Mit Respekt,
G.V.H.

WOW, echt GOIL.... DOCh so hohe system anforderungen hab ich nicht, und bei mir ruckelts mächtig... trotzdem sehr gut gemacht... ich trau mich nichtmal mir dass im maker anzuschauen, weil dass zuviel technik ist.

Aber respekt http://www.multimediaxis.de/images/s.../hell_yeah.gif

wenn man so ein ganzes spiel machen würde, und es nicht so ruckeln würde.... dann wird es bestimmt ein HAMMER game, leider wie gesagt ruckelts bei schlecheteren Rechnern....

Mann das ist geil, mach weiterso TOP

eins hat mir nur nicht gefallen..... und zwar, manchmal kann man zwischen büschen nicht durchlaufen, weil die Kollisionsabfrage zu ungenau ist.... obwohl man theoretisch vorbei laugen könnte geht dass net...

MFG FabiF.de

MFG FabiF.de

Zitat:

---

Zitat von Venoran

Ich habs auch mal angetestet. Natürlich musste ich es vorher ein wenig "optimieren", damit es auf meinem 800 Mhz-Rechner überhaupt funktioniert.

---

Du hast durchgeblickt o.O toll, zeigt mir dass da vielleicht doch ein erkennbares System ist xD respekt.
Darf man fragen wie du es optimiert hast?

Zitat:

---

Zitat von FabiF.de

eins hat mir nur nicht gefallen..... und zwar, manchmal kann man zwischen büschen nicht durchlaufen, weil die Kollisionsabfrage zu ungenau ist.... obwohl man theoretisch vorbei laugen könnte geht dass net...

---

hmmm die Kollisionsabfrage mit der Umgebung ist eigentlich das einzige auf das ich so richtig stolz sein kann, da sie bugfrei und ohne Probleme funktioniert und dazu noch pixelgenau ist. Du must diech wie schon OFT gesagt diagonal bewegen, wenn du nicht genau in die Lücke reinpasst. Probier's mal aus, es geht und ist keinesfalls ungenau..

Hosasa, ein echt geniales System, ich habe es mir bisher nur im maker angesehen, da ich es interessanter fnide, wie es gelöst ist.
Ich schau es mir aber später auch mal als Spiel an.

einige Sachen sind imo echt klasse gelöst, wie ich es sehe.

Du hast nur etwas wirr für Aussenstehende geproggt.
Hat ne Weile gedauert, bis ich durchgestiegen bin. Maybe werde ich damit auch ein wenig rumspielen und basteln, ^mal schauen.

Von mir ein respekt an das, was du geschaffen hast.

Zitat:

---

Zitat von Ryo Saeba 1000

Du hast durchgeblickt o.O toll, zeigt mir dass da vielleicht doch ein erkennbares System ist xD respekt.
Darf man fragen wie du es optimiert hast?

---

Ist ganz einfach! In wirklichkeit braucht das Skript gar nicht so viel Performance... ;)
Dein Fehler war, dass du vieles einfach 30 bis 40 Mal pro Sekunde berechnest, obwohl ein Mensch weder so schnell reagiert noch sieht. Natürlich ist flüssiges Spielen wichtig, aber man muss es nicht übertreiben.
Was aber am meisten Performance kostet, ist dein Angriffs-Common-Event.
Es ist zwar eine technisch sehr gute Leistung, trotzdem hast du einige umständliche Stellen in deinen Event "Angriff". Ich meine, ein Schlag muss treffen, aber nicht unbedingt als Parallel-Process dauernd berechnet werden.
Berechne lieber, ob der Gegner überhaupt in Reichweite des Schwertes liegt und berechne dann die Trefferzone des Schwertes.
Dir jetzt genau zu erklären, was ich umgeändert habe, würde ziemlich lange dauern...
Deswegen sag ich dir einfach folgendes: Berechne nur das, was du wirklich in diesen Moment brauchst. Um herauszufinden, was man braucht, kann man auch eine 1.0-Berechnung benutzen, die alle anderen Berechnungen aktiviert oder deaktiviert, wenn benötigt. ;)

Mit Respekt, G.V.H.

Hi,
ja gefällt mir sehr gut! Ne nette Umsetzung des gewohnten Zelda Ks!
Ähhm nur eins, ich hab das komplette Teil auf nem 1,2 Gig AMD, 256 SDRam gefahren und habe keinen unterschied zu meinem anderem Rechner finden können, läuft auf beiden einwandfrei und Ruckellos!
Mfg CRZYSheep!

Zitat:

---

Zitat von Venoran

Ist ganz einfach! In wirklichkeit braucht das Skript gar nicht so viel Performance... ;)
Dein Fehler war, dass du vieles einfach 30 bis 40 Mal pro Sekunde berechnest, obwohl ein Mensch weder so schnell reagiert noch sieht. Natürlich ist flüssiges Spielen wichtig, aber man muss es nicht übertreiben.
Was aber am meisten Performance kostet, ist dein Angriffs-Common-Event.
Es ist zwar eine technisch sehr gute Leistung, trotzdem hast du einige umständliche Stellen in deinen Event "Angriff". Ich meine, ein Schlag muss treffen, aber nicht unbedingt als Parallel-Process dauernd berechnet werden.
Berechne lieber, ob der Gegner überhaupt in Reichweite des Schwertes liegt und berechne dann die Trefferzone des Schwertes.
Dir jetzt genau zu erklären, was ich umgeändert habe, würde ziemlich lange dauern...
Deswegen sag ich dir einfach folgendes: Berechne nur das, was du wirklich in diesen Moment brauchst. Um herauszufinden, was man braucht, kann man auch eine 1.0-Berechnung benutzen, die alle anderen Berechnungen aktiviert oder deaktiviert, wenn benötigt. ;)

Mit Respekt, G.V.H.

---

Ähm ja, mein Angriffs CE ist ziemlich derb^^ wenn man sich dagegegen die Wirbelattacke ansieht... dass es als PP Event läuft ist an sich ziemlich nützlich, aber mit den Waits hast du sicher recht, beim Angriffsevent dürfte es ein 0.1 auch tun. Allerdings sehe ich noch nicht, wo du jetzt noch generell was geändert haben sollst, da das Haupt-CE (afair Tastatur) mit einem 0.0 Wait laufen muss, sonst verlangsamt sich die Bewegung von Link zu stark. Ähnliches gilt auch für den Gegner. Wäre aber natürlich toll, wenn du da auch eine Lösung parat hättest.
btw wenn die Steuerung 30 statt 5 mal pro Sekunde abgefragt wid ist sie auch 6mal genauer.. aber man müsste halt sehen, welchen Kompromiss man da eingeht.