Dieses Forum nutzt Cookies
Dieses Forum verwendet Cookies, um Ihre Login-Informationen zu speichern, wenn Sie registriert sind, und Ihren letzten Besuch, wenn Sie es nicht sind. Cookies sind kleine Textdokumente, die auf Ihrem Computer gespeichert sind; Die von diesem Forum gesetzten Cookies dürfen nur auf dieser Website verwendet werden und stellen kein Sicherheitsrisiko dar. Cookies auf diesem Forum speichern auch die spezifischen Themen, die Sie gelesen haben und wann Sie zum letzten Mal gelesen haben. Bitte bestätigen Sie, ob Sie diese Cookies akzeptieren oder ablehnen.

Ein Cookie wird in Ihrem Browser unabhängig von der Wahl gespeichert, um zu verhindern, dassIhnen diese Frage erneut gestellt wird. Sie können Ihre Cookie-Einstellungen jederzeit über den Link in der Fußzeile ändern.

Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Interne Repräsentation der Bodenfelder im Kampf
#1
Werte integrale Bestandteile dieser Community, ich hoffe, ihr habt die Feiertage gut überstanden und seid wieder fit, euch eurem Alltag, eurer Arbeit und nicht zuletzt natürlich der Nordlandtrilogie zu widmen.

Ich bin zwar kein erfahrener Programmierer, aber das Programmieren interessiert und fasziniert mich. So weit ich es mitbekommen habe, gibt es hier auch durchaus versierte Programmierer, die schon einige Tools entwickelt oder gar die Nordlandtrilogie selbst "auseinandergenommen" haben.

Deshalb möchte ich euch fragen: Wie wird in den rundenbasierten Kämpfen der Nordlandtrilogie eurer Meinung nach das Spielfeld spielintern repräsentiert? Da das Spielfeld - der Ort des Geschehens - in Felder aufgeteilt ist, stelle ich mir vor, dass diese einfach durchnummeriert und mittels einer Formel in Bezug zueinander gebracht wurden. Oder aber es wurde ein Koordinatensystem erstellt, das über das Spielfeld gelegt wurde. Vielleicht wurde auch eine ganz andere Methode genutzt. Was meint ihr dazu?

Habt ihr euch schonmal mit der Frage auseinander gesetzt?
"Save early and save often!" - Speichere oft und speichere früh! - Ist eine alte Zockerweisheit.
Zitieren
#2
Für das Bright-Eyes-Projekt hatte ich mal versucht zu verstehen, wie die grafische Darstellung des Kampfbildschirms von Schicksalsklinge intern funktioniert (siehe https://github.com/Henne/Bright-Eyes/blo...5.cpp#L296). Das ist natürlich nur eingeschränkt auf Schweif und Riva übertragbar.

Herausgekommen ist jedenfalls, dass das Schlachtfeld maximal 24x24 Felder umfasst, die mit kartesischen Koordinaten (cb_x, cb_y) wie in der angehängten Abbildung bezeichnet werden. Da das Schlachtfeld um 45 Grad gegenüber dem Bildschirmkoordinatensystem (screen_x, screen_y) gedreht ist, um den Eindruck räumlicher Tiefe zu erzeugen, befindet sich ein Objekt oder Kämpfer mit der Position (0,0) auf der "linken" Ecke des Schlachtfelds.


Angehängte Dateien Thumbnail(s)
   
Zitieren
#3
Schick wurde in Borland C++ 3.1 geschrieben. Ohne in den Source-Code geschaut zu haben bin ich ziemlich sicher, dass das Spielfeld einfach als zweidimensionales C-Array implementiert wurde. Wände haben den Wert w1, Ausgänge den Wert w2 usw.
Die Darstellung auf dem Bildschirm ist ein statisches Bitmap, das von der Engine mit Sprites, Markierungen etc. überlagert wird.
Koordinaten und Timestep der Animation der Spielfiguren wird vermutlich in einer listenartigen Datenstruktur gespeichert.

Den Weg von (x1,y1) nach (x2,y2) findest Du mit dem Bresenhäm-Algorithmus.
Die Distanz ist die sogenannte Manhattan-Distanz |x2-x1| + |y2-y1|.
Zitieren
#4
(28.12.2019, 09:55)Rabenaas schrieb: [..] dass das Spielfeld einfach als zweidimensionales C-Array implementiert wurde. [..]

Wahrscheinlich ja, aber man kann es auch als eindimensionales Array ablegen und dann über (y * breite) + x die Zellen referenzieren. Habe ich oft so gemacht, weil das aus unerfindlichen Gründen in meinem Kopf einfacher geht als [x][y]... :silly:

Und da ich das schon bei einigen anderen (auch älteren) Codes gesehen habe, wollte ich das auch mal nennen ;)
Zitieren
#5
Die Bytes im RAM sind ja sowieso eindimensional angeordnet. Die Schreibweise mit mehreren Indices ist also nur syntactic sugar bzw. machst Du die Arbeit für den Compiler. In Sonderfällen ist die "ausführliche" Schreibweise zwar durchaus üblich, aber weil die meisten Leute eher abstraktere Skriptsprachen gewohnt sind, würde ich möglichst mehrere Indices bevorzugen.
Zitieren
#6
Jep, ist oft syntactic sugar. Aber da ich selbst viele Low-Level-Sachen gemacht habe, gefällt mir das mittlerweile besser. Keine Ahnung wieso...
Zitieren
#7
Also, ich will als Fragesteller auch nochmal was dazu sagen: Für mich ist die 2-dimensionale Schreibweise einfacher, bzw. intuitiver. Dennoch hat die andere Variante natürlich ihre Daseinsberechtigung. Ich habe mich immer gefragt, welche der beiden Methoden a) die bessere und b) die verbreitetere ist. Dank eurer Kommentare ist nun klar: Das lässt sich nicht eindeutige beantworten. Und das zu Wissen, ist mir auch schon viel wert.
"Save early and save often!" - Speichere oft und speichere früh! - Ist eine alte Zockerweisheit.
Zitieren
#8
Technisch gesehen übersetzt ein vernünftiger Compiler beides in exakt dieselben Maschinenbefehle. Das tut sich nichts.
Indexnotation ist schon der Standard, zumindest bei C++ und den meisten aktuellen Programmiersprachen. Es gibt aber ein paar Spezialfälle, wenn das nicht möglich ist, z.B. wenn man keine Arrays im Speicher sondern parallele Threads auf GPUs adressiert.
Zitieren
#9
(06.01.2020, 21:35)Rabenaas schrieb: Es gibt aber ein paar Spezialfälle, wenn das nicht möglich ist, z.B. wenn man keine Arrays im Speicher sondern parallele Threads auf GPUs adressiert.

This! :D
Zitieren




Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste