spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Koschi«

z.B. Gut gerüsteter Tank benötigt nicht so viel Healspells wie ein schlecht gerüsteter Tank somit wäre ein Heiler beim Leveln mit nem guten Tank im Nachteil.

Danke für den Hinweis! Das ist natürlich ein gravierendes Problem

Zitat

http://asheron.wikia.com/wiki/Fellowship
If all members of the fellowship are within 5 levels of the founder, XP will be shared equally. If members are all within ten levels of the founder, XP will be shared proportionally.
If all members of the fellowship are level 50 or above, all members will share XP equally, and there will be no limit to the levels of the members involved.

Die Idee klingt insgesamt ganz. Mein "Problem" ist nur, dass ich den greif-mit-dem-Bogen-an-und-dein-Fernkampf-Skill-wird-besser-Ansatz (Dungeon Siege) unbedingt einbauen will und auf ein "klassisches" Exp-Sammeln verzichten will. Denkbar wäre für die Exp-Verteilung den jeweilig aktiven Skill zugrunde zu legen.

Beispiel: Gruppe von 3 Spielern: A (Gründer der Gruppe) ist Nahkämpfer mit Nahkampf-Talent Lvl 17, B ist Fernkämpfer mit Fernkampf-Talent Lvl 22 und C ist Heiler mit Magie-Talent Lvl 11. Entsprechend bekommen A und B die gleiche Menge Erfahrung (A für das Nahkampf-Talent und B für das Fernkampf-Talent) und C etwas weniger (für das Magie-Talent), weil sein Magie-Talent sich um mehr als 5 vom Nahkampf-Talent von A unterscheidet.

Fraglich wäre nur, was (für den "passiven" Spieler) definiert, welches Talent "aktiv" ist. Für Nah- und Fernkampf ließe sich das über die aktuell verwendete Waffe identifizieren (Schwert vs. Bogen); für einen Magier (egal ob jetzt Heiler oder etwas anderes), würde das dann implizieren, dass es extra Magierwaffen gibt (z.B. Zauberstab). Dann würde er aber, um passiv mitleveln zu können, zwingend einen Zauberstab brauchen; d.h. trägt er eine Bogen würde ich dann fälschlicherweise das Fernkampf-Talent verbessern. Noch problematischer sehe ich das bei Hybrid-Builds.

Ich lagere das Problem an der Stelle mal in einen eigenen Thread (im entsprechenden Unterforum) aus, weil es mit der Projektvorstelung nix mehr zu tun hat

Ein Lebenszeichen.
Hallo Leute! Nachdem es hier verdächtig lange kein Lebenszeichen von meinem Projekt gab, habe ich heute beschlossen mal wieder etwas zu posten.
Im Moment gibt es leider nichts neues zu sehen. Allerdings bin ich im Moment (ganz gut) dabei die Codebase umzubauen; u.A. führe ich nahezu flächendeckend Unittests ein.

Inzwischen bin ich dabei angekommen das Gameplay automatisiert zu testen... viel neues ist aber auch da nicht dazu gekommen. Neu ist aber, dass "Blöcke" (Felsen, Kisten, whatever) bewegt werden können um z.B. Schutz vor Geschossen zu bieten.

Insgesamt habe ich momentan 687 Testfälle und ~25k Lines of Code (davon 13.4k Unit tests).

Um mal wieder etwas interessantes zu posten: Inzwischen ist der gesamte Gamecontent (Animationen, Items, Zauber etc.) auf XML-Files umgestellt. Hier mal ein Beispiel eines "Firebow", der eine 10% Chance hat seinem Ziel den "Burn"-Effekt zuzufügen:


Der icon_name bezeichnet dabei die Datei data/gfx/icon/bow.png, die z.B. in der Quickslot-Leiste als Icon angezeigt werden kann. Hinter sprite_name verbirgt sich das entsprechende Frameset das verwendet wird, um den Bogen dann im Spiel wirklich anzuzeigen. Dabei habe ich meine Sprites in Layer unterteilt, so dass ich Waffen und Rüstungen kombinieren kann (das hatte ich vor einiger Zeit schonmal grob vorgestellt, dazu werde ich demnächst hoffentlich nochmal was genaueres posten können - inkl. einiger GIFs).
Der "effect"-Node ist dabei das Interessante: Er verweist auf data/xml/effect/burn.xml und beschreibt was beim Brennen eigentlich passiert:


In diesem Falle wird "Burning" angezeigt, wenn der Spieler sich anschaut welche Effekte gerade auf ihm aktiv sind. Pro Sekunde verliert er 10 Leben solange er brennt... Prinzipiell könnte ein Effekt dauerhaft sein (wie der hier, weil die Dauer fehlt xD) oder eben zeitlich begrenzt, so dass er nach einiger Zeit verschwindet (was hier durchaus sinnvoll wäre ). Zusätzlich sind Boni auf Schutzarten (z.B. Schutz vor Gift) oder andere Dinge wie Maximales Mana möglich, so dass verschiedenste Effekte kombiniert werden können.

Zitat von »Koschi«

Wann wird es mal ein Spielbares Demo geben?

Am liebsten sofort Aber das wird leider noch eine Weile dauern. Sobald ich eine spielbare Demo release, werde ich sie auch auf IndieDB veröffentlichen. Optimal wäre, das Projekt dort zu tracken ;-)

Zitat von »Koschi«

Gibt es den Quellcode mal irgendwo zum anschauen/downloaden

Im Moment ist das erstmal (noch) nicht geplant. Ich könnte mir aber vorstellen irgendwann den Code nachträglich zu veröffentlichen. Im Moment ist der Code aus meiner Sicht noch nicht "publikumsfähig"

Zitat von »Koschi«

bei einigen Sachen würde ich gern mal schauen wie du es umgesetzt hast.

Wenn du Fragen zu konkreten Features oder ähnlichem hast, kann ich meine Herangehensweise auch hier mal posten

Zitat von »Schorsch«

Das ist ja auch nicht unbedingt unnormal. Aber ist natürlich dennoch deine Sache was du wann wie preisgeben möchtest

Ich bin da ein bisschen eitel Wenn ich den Code veröffentliche will ich nicht nur, "dass er gut läuft" sondern mehr noch richtig "Hand und Fuß" hat .. ich finde es gibt schon genug hässlichen Code auf dieser Welt Da muss ich meinen Erguss nicht noch dazuklatschen .. zumindest noch nicht

Zitat von »Koschi«

Aspekte die mich generall interessieren, Map Generierung und Rendern/ KI / das ECS.

Genau das sind die Themen zu denen ich irgendwann noch ein paar Artikel schreiben will

Zitat von »Koschi«

Aber fühl dich nicht genötigt diesen irgenwo hochzuladen wenn du ihn lieber für dich behalten magst

Ich teile gerne meine Ergebnisse

Im Moment überlege ich was ich alles in eine erste Demo reinbauen will. Weite Teile der Implementierungen sind ja schon fertig und geunittestet - was fehlt ist die Integration in den "Gesamtcode". Daher tendiere ich gerade dazu eine erste "Überblicksdemo" zu bauen und irgendwann später (wenn dann das Inventar auf mit Benutzeroberfläche implementiet und getestet ist) eine zweite "tiefer gehende Demo" zu erstellen. Vielleicht schreibe ich den ersten Artikel (über meine ECS-Implementierung) nachdem die erste spielbare Demo steht.

In jedem Fall hört ihr von mir

Nachdem ich mit dem Refactoring weiter Teile des Codes fertig bin, freue ich mich euch mal wieder etwas visuelles zu präsentieren: Sprite Animationen! Ich hab Beine und Oberkörper von einander getrennt und weiter in verschiedene Layer zerlegt, um verschiedene Sprites kombinieren zu können (z.B. Mensch + schwere Rüstung + Bogen). Einer der hübschen Nebeneffekte (er war der Hauptgrund für die Änderung): Bewegen + Angreifen ist nun gleichzeitig möglich!