spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hi BlueCobold!

Darüber habe ich auch schon länger nachgedacht, war mir aber nicht sicher, ob die geschützten Markennamen nun in meinem Kontext so relevant sind, da das ja ein Hobbyprojekt ist und außerdem ich keinerlei Intension habe, damit Geld zu verdienen.

Meinst du ich sollte alle Namen, die ich verwende ändern?
Oder reicht es gar einfach auf den Markeninhaber zu verweisen und dass ich kein Geld damit verdienen möchte?

Wäre dankbar für Tipps, wie man damit umgehen kann.
Gruß

Hi!

Habe allen wählbaren Kampfrobotern im Spiel nun einen neuen Namen verpasst, an der sonstigen individuellen Ausprägung werde ich später erst arbeiten, allerdings versuche ich mich ab nun soweit wie möglich von "Battletech" zu entfernen.

Hier bereits einige Bilder über schon jetzt mögliche Bewegungsabläufe, hoffe euch gefallen die Ergebnisse soweit (auch wenn vielleicht noch nicht überall der Sinn ersichtlich ist, aber ich versuche alles demnächst immer verständlicher werden zu lassen.

Die Farben:

Grün, Gras mit Höhenlevel 0
Gelb, Sand mit Höhenlevel 0
Weiß, Schnee mit Höhenlevel 0

Dunkelbraun, Hügel mit Höhenlevel 1
Braun, Hügel mit Höhenlevel 2
Hellbraun, Hügellevel mit Höhenlevel 3
usw.

Blau, für Wasser, analog nur nach unten: -1, -2, -3, -4

Die Spielfigur kann immer nur einen Höhenleven überwinden, das heißt von 0 auf 1 oder 0 auf -1. "Fällt" sie in eine Wassergrub der Stufe -4 kann sie von dort nicht mehr zurück, wenn das Feld vorher > - 2 betrug. Umgekehrt kann sie von Hügel herunterfallen, aber nicht von 0 auf 4 klettern.
Kleine Anmerkung: Da ich die grünen und roten Punkte von Hand eingezeichnet habe, ist nun natürlich ein Fehler drin: Die Spielfigur kommt aus Wasser -2 natürlich nicht mehr auf 0 zurück, sondern kann nur ins hellblaue Feld ziehen, sorry für den Fehler.


So ist die ganze Sache bisher gedacht und es funktioniert soweit. Nächster Schritt wird die Rundenstruktur sein.

Gruß

Jo, ich poste den Code nächste Woche, wenn ich die angesprochenen Ideen drin hab und ich ihn noch ein wenig bereinigt habe. Momentan will ich nur ein wenig mein kleinen Schritte veröffentlichen, auch damit die Leute nachvollziehen können in welcher Reihenfolge ich vorgehe.

Gruß

Hier also der Code und noch ein Bild.

Die Libtcod-Bibliothek funktioniert nicht mit Python 3.0 oder höher, das steht zumindest auf deren Seite.

Der Code ist mitten im Prozess, also seht über Form etc. hinweg, ich bereinige das demnächst. Ansonsten bin ich für Kritik aber offen.

Kann man diesen Tread eigentlich verschieben? ich glaube er ist hier nicht ganz richtig und passt mehr in die andere Rubrik "Vorstellen, Umsetzung etc."

Hallo!

Ich habe heute eine eher mathematisch/physikalische Frage. Und zwar mache ich mir seit 2 Tagen Gedanken darüber, wie man das Sichtfeld auf dem Spielplan simulieren könnte. Ich hätte gerne, dass der Spieler nur einen bestimmten Radius weit schauen kann. Das kann entweder 360° sein oder (mein persönlicher Wunsch) 120°. Nun habe ich ein wenig darüber gelesen und das Raycasting-Prinzip erscheint mir sinnvoll bei der Umsetzung, ich möchte aber keine pseudo 3d-Grafik programmieren. Raycasting kam etwa bei Wolfenstein 3d zum Einsatz.

Nun meine Frage: Was muss ich alles mit einbeziehen um mir das Raycasting Prinzip selbst nach meinen Wünschen zusammen zu programmieren? Ziel ist es, dass bestimmte Höhenlevel das dahinterliegende verbergen und später auch, dass Objekte durch Hindernisse verborgen werden können. Hat jemand eine Idee, wo ich genauere Informationen darüber finde?

Zwar hat die Bibliothek von libtcod, die ich ja benutze, einiges zu FOV zu bieten, allerdings fehlt bei denen die 3. Dimension, nämlich der Einbezug von Höhenlevel. Denn meine Vermutung ist,dass ich das ganze - obwohl ich nur eine 2d Karte habe - in 3d berechnen muss, liege ich da richtig? Ich habe mich in den letzten Tage ein wenig mit Linearer Algebra befasst (musste meine Mathekenntnisse etwas erneuern). Ich habe meine Gedanken mal versucht darzustellen, vielleicht kann der ein oder andere ja mal schauen, ob ich so auf dem richtigen Weg bin.

Punkt 1 befasst sich mit der Draufsicht: tile[x][y].level ist in den auf der Karte festgelegten Feldern der Höhenwert. Der Stützvektor ist denke ich immer durch die Position des Spielers gegeben, die Richtungsvektoren meinen die Strahlen, welche von der Spielerposition ausgesendet werden.
Punkt 2 mit der 3d Sicht, realistisch wäre ja, dass ein feld direkt hinter einem hindernis verborgen ist, etwas, das aber größer ist als das Hindernis selbst und dahinter liegt, ist allerdings wieder sichtbar.

Vielleicht hat jemand eine Idee, wie ich das Problem lösen kann.

Mich würde interessieren, wie euer Feedback so zu meiner Arbeit aussieht, was sagen die erfahreneren Programmierer so zu meiner Planung und der bisherigen Umsetzung? Also ich persönlich habe bis jetzt das erreicht, wie ich es mir vorgestellt habe. Insgesamt ist es glaub ich auch nicht mehr viel Arbeit (relativ betrachtet), da ich aber nun Anfänger bin, muss ich mich mit (wahrscheinlich einfachen) Problemen recht lange herumschlagen

Dann habe ich nochmal die Frage, ob jemand Erfahrungen mit Roguelike-Games hat und zwar im Speziellen mit Field of View. Das mit den Vektoren war Blödsinn. Ich habe jetzt folgende Überlegung:

(1) Erstelle die Karte auf eine Offscreen-Konsole, die Map soll also nicht gleich vollständig auf das Rootfenster gezeichnet werden.
(2) Variablen: Anzahl der Strahlen = 360, Schritte = 3 und Radius = <Was auch immer>
(3) Strahlenrichtung wird über Sinus (und wohl auch Cosinus) berechnet.
(4) "Strahl" meint: Gehe Feld für Feld in die berechnetete Richtung
(5) Prüfe für jedes Feld die Höhe und vergleiche Sie mit der Spielerhöhe.
(6) Höhe des Felder =< Spielerfeld: Feldeigenschaft Visible = True
(7) Ist Höhe eines Feldes höher als Spielerfeld : break, Strahl endet also und das dahinter wird nicht mehr aufgedeckt
===== Jetzt der Teil, wo ich noch nicht ganz durchblicke=====
( Bilde alle Felder mit visible = true auf dem Fenster fov ab (das vorher deklariert wurde)
(9) Blitte fov auf Root
(10) Zentrum der Fov-Berechnung = player.x | player.y, d.h. wenn der Spieler sich bewegt, bewegt sich auch das Field of View

Hoffe, dass ich das die nächsten Tage hinbekomme, ist bis jetzt das schwierigste Thema für mich, davor gings. Ist eigentlich auch nur ein Feature, auf das man theoretisch auch verzichten kann, jetzt interessiert mich aber irgendwie, wies nun geht xD

Hallo!

Mit einigen Unterbrechungen habe ich meine Arbeit etwas fortgeführt. Hier die Neuerungen:

(*) Umstieg auf pygames; die Grafiken werden jetzt nicht mehr durch ASCII-Zeichen repräsentiert, sondern durch Sprites und die in pygames verfügbaren Drawingtools.
(*) Schadensgruppen bei den Einheiten: Beine, Torso, Arme, Kopf; Derzeit ohne Bedeutung, allerdings nimmt die Kampfeinheit Schaden, wenn sie aus einem hohen Bereich herunterfällt; wenn ein Bein zerstört, dann bewegt man sich deutlich langsamer;
(*) Maptiles haben verschiedene Eigenschaften, derzeit noch Höhe, Textur;
(*) Objekte blockieren den Weg; Berge blockieren den Weg
(*) Animierter Laserschuss, der durch Berge blockiert wird;

Nächster Schritt:
(-) Objekte sollen Schuss blockieren
(-) Schaden durch Waffen

Übernächste Schritte:
(--) KI
(--) Verschiedene andere Werte sollen noch integriert werden: Wärme, Pilotenwerte etc.
(--) Schönere Sprites: Derzeit sehr minimalistisch;

Und dann noch Screenshots.

Grüße