Ne da geb ich dir recht, er ist wirklich noch recht stark, liegt aber daran dass ich an den levels noch nicht wetergearbeitet habe^^ Ich denke der Wizard wird noch nen kleinen buff erhalten, weil ich den archer gerne so lassen würde und ich noch viele weitere gegner einbaun werde

Also je nach freizeit neben dem studium hab ich noch einiges vor: -mehr heroes (mindestens 5) -mehr level (und mehr gegnerklassen) -HUD noch verbessern und optisch ansprechender machen -Skill Tree einbaun, in welcher art und weise weiß ich aber noch nicht^^

nette sache, ich finde bei dir passt das zusammenspiel aus programmierqualität und grafisches können sehr gut, sofern du die grafiken alle selber machst? Wenn ja hoffe ich für dich im besitz von einem CS zu sein, ohne photoshop geht bildbearbeitung heutzutage nicht mehr ;D

Ah ich sehe du hast ne highscore liste eingefügt ;D noch gar nicht bemerkt, sehr nett nur leider koppiert nicht ? ;) Müsst dich halt mal mit der Greenfoot UserInfo Api befassen ;)

noch ein paar kleinigkeiten die mir aufgefallen sind ;) (ja ich weiß bin kritisch) Bei den Hindernissen werden die gegner immer wieder zurückgesetzt was bewirkt das sie sozusagen flimmern oder wie auch immer, auf jeden fall kannst du das verhindern in dem du die wandüberprüfung direkt nach dem move befehl setzt, sodass er direkt zurückgesetzt wird bevor er erneut gezeichnet wurde. Die Geschoße (Pfeile und co.) sind keine Akteure der klasse Smooth Mover, du hast sie schätzungsweise nur mit turnTowards und dem normalen move befehl zur bewegung gebracht, dazu gibt es ne bessere lösung, die klasse Smooth Mover kannst du einfach oben bei "Edit" unter "Import Class" hinzufügen und dann die geschoße als unterklasse dazu machen. Wenn das geschafft ist kannst du sämtliche funktionen aus smooth mover verwenden, darunter hat jeder ateur dann eine genauere Position (normalerweise sind X und Y int werte, bei smooth mover sind es double werte) dadurch bewegt sich jeder unteractor von smooth mover viel flüßiger, da der befehl move dann move(double) lautet und nicht mehr move(int). Auch würde ich nicht den turnTowards befehl verwenden, da er nur einen Int wert für den Winkel liefert, am besten einfach die koordinaten des spielers mit denen der Maus subtrahieren und den winkel (in float oder double) der hypotenuse berechnen. Das ist eine variante, die andere wäre mit einem move_x und move_y zu arbeiten und den Pfeil oder was auch immer mit SetLocation(double,double) zu bewegen, dadurch erreichst du eine höhere genauigkeit der flugbahn ;) Der ganze aufwand sollte eig nur dazu gut sein, dass ein pfeil wirklich dort ankommt, wo ich geklickt habe, und nicht etwas daneben, das führt nämlich dazu, wie mir bei dir aufgefallen ist, das man gegner an gewissen position (also wenn sie in gewissen winkel auf dich stehen) nicht treffen kannst, ohne dich zu bewegen ;) mfg, Pointifix

Wow, vielen Dank für das ganze Feedback :) Also miene grafiken/Animation mache ich selbst (oder meine Freundin, die nicht ganz so grottig zeichnet wie ich^^) Die Animation sind meist ja nur kleine Kreise, die ihre Transparenz und/oder Größe ändern, was in der Masse dann natürlich diesen Effekt eines Schleiers oder Feuerteilchen erzeugt. Was genau meinst du mit der Highscoreliste? In der Form wird sie sowieso nicht erscheinen^^ Das werde ich noch dem Startmenu in irgend einer Weise hinzufügen. Mit der UserInfo api habe ich mich schon beschäftigt, und eigentlich sollte sie funktionieren, oder was meintest du? O.o Zu dem Tipp mit dem "wackeln" beim movement, PERFEKT^^ Hatte nicht daran gedacht, dort auf die Reihenfolge der Methoden zu achten, aber deine Überlegung löst mein Problem, vielen Dank dafür. Zum SmoothMover: Ich habe ja bei den Helden und den Gegnern schon smoothmover als elterklasse eingestellt, werde ich bei den fähigkeiten auch machen^^ hatte bisher nur noch keine gelegenheit dazu. zu deiner überlegung zu den geschossen: Danke für die Information mit dem turnTowards() Befehl, da der nur int zurückgibt, brauche ich hier natürlich einen Ersatz. Deine Überlegung zur Winkelberechung kann ich nachvollziehen und hatte ich selbst schon vor ca einer Woche, nur fehlen mir ein paar Kerninformationen... Wie kann ich einen Winkel aus zwei "Gerade" berechnen, mir fehlt dazu ja eine Sinusfunktion oder ähnliches? Ich meine mich an eine java.maths klasse erinnern zu können, die mir genau das ermöglicht. Hast du dazu vielleicht noch ein paar Infos für mich?^^ Denn die Flugbahn stört mich auch schon seit längerem^^ Vielleicht hat ja SmoothMover eine überarbeitete turnTowards(double,double) methode?^^

und nice score btw :) Ich weiß, man kann noch weiterspielen nachdem der highscore screen erschienen ist, aber mein spiel ist ja auch noch nicht fertig :D (*hust* ich erinnere an "pre pre alpha" *hust*)

mit highscoreliste meinte ich deinen highscore screen, den hab ich schon bei einem anderen greenfoot scenario gesehen, haste denn abgekuckt? ;) Um Winkelfunktionen in java verwenden zu können, einfach import java.lang.Math; importieren, die funktionsaufrufe kannst du dir hier ankucken: http://docs.oracle.com/javase/6/docs/api/java/lang/Math.html zb.: angle = Math.sin(value); Um Akteure "flüßig" zu bewegen geben ich denen immer 2 werte. Einmal den move_x anteil und einmal den move_y anteil (beides simple double variablen), mit denen kann ich dann einfach (bei Smooth-Mover) setLocation(getExactX()+move_x,getExactY()+move_y); machen um sie zu bewegen, anstatt move() zu verwenden. Naja und um die move_x und move_y anteile zu verändern ganz normale winkel-funktions-mathematik verwenden, meistens sind das eh nur math.sin und math.cos die du brauchst um den x und y anteil zu errechnen. Falls das zu "geschwollen" erklärt war hier ein kleines bsp um bei deiner gegner klasse die bewegung zu errechnen.: double angle = Math.atan2(player_x - getExactX(),player_y - getExactY()); move_x = Math.cos(angle) * speed; move_y = Math.sin(angle) * speed; Wobei angle der winkel zwischen spieler und gegner ist und speed die geschwindigkeit des gegners (also sozusagen die hypotenuse aus move_x und move_y). Sollte was nicht funktionieren von dem was ich geschrieben habe kannst du auch gerne den code mithochladen (einfach bei share das häkchen bei "publish source code" reinmachen) und ich kuck mir das an sofern ich helfen kann ;) mfg, Pointifix

generell, sofern du willst das andere benutzer deinen source code sehen können, würde ich diesen mithochladen, da dir schneller bei problemen geholfen werden kann und vorallen, damit andere neue benutzer aus hochgeladenen scenarien lernen können und sich sachen abkucken können, is ja schließlich ne lernplattform ;)

Ah ok wenn man sich diese funktionen einfach importieren kann dann ist das ja kein problem^^ Und wie setzt du die Rotation wenn du nur mit setLocation() bewegst? drehst du im gleichen act auch immer in richtung gegner (bzw angle) ?

setRotation(angle); //Wobei angle der berechnete winkel von vorhin ist. Die Rotation hat hier keinen einfluss auf die bewegung, nur auf die grafische drehrichtung. Mit Math.atan2() hab ich mich nicht verschrieben, atan2 heist nur das es 2 argumente annimmt, also Math.atan2(double,double); das is das selbe wie Math.atan(double / double); nur das du dir das dividiert sparst.

mhhmm was mir jz eig noch aufgefallen ist, dass, wenn man bedenkt was für eine starke dritte attacke der magier hat, und das er bei jeden normalen schuss den gegner einfrirrt, dann kann man den archer durchaus lassen, also die aufteilung passt

ah ok gut, also es is ein tangens, hab mich nur über die schreibweise gewundert. ja ok mit setRotation(angle) änderst du nur nich die optik, weil du ja nicht move() benutzt. aber drin hast dus schon oder? Sonst würde ich ja auf double genau die bewegung machen, die rotation aber nur auf int genau grafisch darstellen

das ist richtig deshalb verwend ich es nicht gerade gerne, leider gibt es in greenfoot keine mögliche akteure mit double zu drehen, und so einen "Drehalgorythmus" zu schreiben is auch nicht grade das simpelste, aber ich glaube wenn die drehrichtung nicht genau mit der flugrichtung übereinstimmt ist das grafisch zu verkraften, also fast nicht mit dem auge ersichtlich, meiner ansicht nach. SetRotation dürfte die optik schon verändern? also da muss man kein move dran machen damit der akteur dann gedreht wird soweit ich das jz weiß

Es ist ein Arkustangens ;) Bisher ganz nett, hat aber auch noch Potenzial :) Der Bogenschütze ist ziemlich OP... ^^ Verbesserungsvorschläge: - Lass die Gegner nicht immer an der gleichen Stelle spawnen - Gestalte die Wellen abwechslungsreicher - Bessere Weg-Findung der KI, wenn möglich ;)

ja Arkus superhippo sry übersehen. Naja durch den Freeze-Effekt des Magiers finde ich den Bogenschützen jz nicht mehr so OP Joah A* Path-Finding für die gegner wäre schön, is halt aufwändig, da er kein raster verwendet. Bei den Waves geb ich dir recht

Also ich bin gerade dabei die präzision zu überarbeiten. Wenn ich aber bei den cos oder sin funktionen dann mit dem speed multipliziere (bei mir double z.b. 1.4) wird aber int verlangt und er meint "possible loss of precision". Nun könnte ich den speed zum int casten, damit erreiche ich aber mein ergebnis ja nicht^^

genious ;DDDD so viel besser als vorher ;) endlich geht der pfeil dorthin wo man hinklickt und nicht i wo hin^^ um variablen typen zu ändern einfach zb int x = (int)(sin(x)); da sin double liefert zb. die neue animation der 2 ten attacke des archer gefällt mir sehr gut ;)

Thank you^^ Well it takes a time to get deeper into programming, but if you have motivation you will learn something every day, or especially when you fail something and it could have been so easy^^ thats what you rly keep in mind ;)

That one can be found here: http://www.greenfoot.org/scenarios/5719. You only have to visit it first, because the program won't recognize you otherwise.

Wizard is purely OP now :D Btw, sometimes they walk through walls and you can also do it. And the projectiles doesn't move through the right and bottom end of screen. They only slide on the edge.