Größere Projekte wie angehen?

Übersicht

Sonstiges

Smalltalk

	M0rgenstern Betreff: Größere Projekte wie angehen?	Mo, Jun 07, 2010 16:23 Antworten mit Zitat
Hey Leute. Ich würde gerne mal von euch wissen, vor allem von denen die schon an größeren Projekten gearbeitet haben, wie ihr sowas angeht, bzw was sinnvoll wäre. Ich frage aus einem bestimmten Grund: Undzwar habe ich gemerkt, dass mein großes Projekt, AleinShooter 2D zusammengehackter Blödsinn ist, von der Struktur und allem her. Ich will jetzt anfangen es neu zu schreiben, diesmal aber anständig und ordentlich. Leider hab ich keine Vorstellung wie ich das anfangen bzw bewerkstelligen soll. Das Problem war einfach beim ersten Durchlauf, dass ich dauernd das Gefühl hatte, dass ich eine bestimmte Sache programmieren musste um eine andere wiederum einfügen zu könne etc. Dann hab ich später gemerkt, dass ich was altes erweitern muss, was sich aber dann mit einer anderen Sache nicht vertragen hat usw. Ich hab einfach das Gefühl, dass alles irgendwie zusammenhängt und aufeinander aufbaut und man nichts "extern" bearbeiten und programmieren kann, sondern immer nur in Abhängigkeit von dem "großen Ganzen". Wenn ich mich an das "PanzerS" Projekt erinnere, an dem ich mit Lastmayday gearbeitet habe, dann seh ich da einfach nen riesen Unterschied. Die Bots konnte man sich auch mal extern angucken, genau so wie die Kollsion etc. Das ganze war Modular (Es gab nen Editor für Panzer, mit entsprechenden Bildern und einer Ini Datei die für jeden Panzer nach dem Scripten erstellt wurde und der Panzer war im Spiel eingebaut). Das war für das ganze Team einfach ne Super Sache. Oder auch die Scriptbaren Objekte wie Straßenlampen etc. Leider hab ich da nie so viel gemacht, weil ich da erst mit BMax angefangen hatte (das erste mal). Und durch den Code blick ich leider auch nicht durch (unkommentiert), weswegen ich mir auch keine Anregungen dort holen kann. Bei dem aktuellen Projekt ist das einfach so ein Problem, dass verschiedene Klassen immer abhängig voneinander sind. Wenn irgendwas nicht stimmt, bricht das ganze Programm ab. Ich kann mir nichts einzeln anschauen etc. Es liegt wohl vor allem an meiner (nicht)Planung. Aber ich hab einfach keine Ahnung, wie ich das ganze so ansetzen könnte, von Anfang an, dass es modular ist und einfach die einzelnen Komponenten viel unabhängiger sind. Ich wäre einfach für ein paar Anregungen oder ähnliches richtig froh. Außerdem hoffe ich, dass mein Wirrwarr verständlich ist, das ich da oben hingeschrieben hab^^ Lg, M0rgenstern

M0rgenstern

Betreff: Größere Projekte wie angehen?

Mo, Jun 07, 2010 16:23
Antworten mit Zitat

Hey Leute.

Ich würde gerne mal von euch wissen, vor allem von denen die schon an größeren Projekten gearbeitet haben, wie ihr sowas angeht, bzw was sinnvoll wäre.
Ich frage aus einem bestimmten Grund:
Undzwar habe ich gemerkt, dass mein großes Projekt, AleinShooter 2D zusammengehackter Blödsinn ist, von der Struktur und allem her.
Ich will jetzt anfangen es neu zu schreiben, diesmal aber anständig und ordentlich.

Leider hab ich keine Vorstellung wie ich das anfangen bzw bewerkstelligen soll.
Das Problem war einfach beim ersten Durchlauf, dass ich dauernd das Gefühl hatte, dass ich eine bestimmte Sache programmieren musste um eine andere wiederum einfügen zu könne etc.
Dann hab ich später gemerkt, dass ich was altes erweitern muss, was sich aber dann mit einer anderen Sache nicht vertragen hat usw.
Ich hab einfach das Gefühl, dass alles irgendwie zusammenhängt und aufeinander aufbaut und man nichts "extern" bearbeiten und programmieren kann, sondern immer nur in Abhängigkeit von dem "großen Ganzen".

Wenn ich mich an das "PanzerS" Projekt erinnere, an dem ich mit Lastmayday gearbeitet habe, dann seh ich da einfach nen riesen Unterschied. Die Bots konnte man sich auch mal extern angucken, genau so wie die Kollsion etc.
Das ganze war Modular (Es gab nen Editor für Panzer, mit entsprechenden Bildern und einer Ini Datei die für jeden Panzer nach dem Scripten erstellt wurde und der Panzer war im Spiel eingebaut). Das war für das ganze Team einfach ne Super Sache. Oder auch die Scriptbaren Objekte wie Straßenlampen etc.
Leider hab ich da nie so viel gemacht, weil ich da erst mit BMax angefangen hatte (das erste mal). Und durch den Code blick ich leider auch nicht durch (unkommentiert), weswegen ich mir auch keine Anregungen dort holen kann.

Bei dem aktuellen Projekt ist das einfach so ein Problem, dass verschiedene Klassen immer abhängig voneinander sind. Wenn irgendwas nicht stimmt, bricht das ganze Programm ab. Ich kann mir nichts einzeln anschauen etc.
Es liegt wohl vor allem an meiner (nicht)Planung. Aber ich hab einfach keine Ahnung, wie ich das ganze so ansetzen könnte, von Anfang an, dass es modular ist und einfach die einzelnen Komponenten viel unabhängiger sind.

Ich wäre einfach für ein paar Anregungen oder ähnliches richtig froh.
Außerdem hoffe ich, dass mein Wirrwarr verständlich ist, das ich da oben hingeschrieben hab^^

Lg, M0rgenstern

	Xeres Moderator	Mo, Jun 07, 2010 17:55 Antworten mit Zitat
1. Beginnst du mit einer Idee für ein Spiel Du machst ein Konzeptpapier; schreiben, malen, Mindmap - am besten alles drei. 2. Aus dem was du möchtest, machst du dir Notizen, wie du es umsetzt - Datenstrukur, Aufbau, welche Eigenschaften verschiedene Objekte brauchen. Setz dir in Sachen Features klare Grenzen die du als erstes erreichen möchtest, bevor du das Spiel erweiterst. 3. Gegeben falls erstellst du Testprogramm das ein Objekt beinhaltet und deren Funktionen/Methoden auf Tauglichkeit Prüft. Da kannst du feststellen, ob deine Umsetzung gut funktioniert oder zu kompliziert ist. 4. Du fängst mit dem Eigentlichen Spiel an, und schreibst so, dass du Ressourcen auf ihre Existenz prüfst und am besten jeden Schritt in eine Datei/Logfile speicherst. Widme dich einem Objekt nach dem anderen; wenn möglich sollte man das Spiel immer starten und begutachten können, nur eben mit eingeschränkter Funktionalität oder Platzhaltern. Gut möglich, das man auch in der Letzten Phase noch mal die Idee hat, es ganz anders zu machen. Dann kann man a) seine Erkenntnisse gut dokumentieren und gleich neu anfangen oder b) seine Erkenntnisse gut dokumentieren und den bestehenden Code fertig machen. Lernen tut man dabei immer weiter, es hängt praktisch nur von dem Hang zum Perfektionismus ab, wann genau man aufhört Sachen noch mal umkrempeln zu wollen.
Win10 Prof.(x64)/Ubuntu 16.04\|CPU 4x3Ghz (Intel i5-4590S)\|RAM 8 GB\|GeForce GTX 960 Wie man Fragen richtig stellt \|\| "Es geht nicht" \|\| Video-Tutorial: Sinus & Cosinus THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld)

Xeres

Moderator

Mo, Jun 07, 2010 17:55
Antworten mit Zitat

1. Beginnst du mit einer Idee für ein Spiel
Du machst ein Konzeptpapier; schreiben, malen, Mindmap - am besten alles drei.
2. Aus dem was du möchtest, machst du dir Notizen, wie du es umsetzt - Datenstrukur, Aufbau, welche Eigenschaften verschiedene Objekte brauchen. Setz dir in Sachen Features klare Grenzen die du als erstes erreichen möchtest, bevor du das Spiel erweiterst.
3. Gegeben falls erstellst du Testprogramm das ein Objekt beinhaltet und deren Funktionen/Methoden auf Tauglichkeit Prüft. Da kannst du feststellen, ob deine Umsetzung gut funktioniert oder zu kompliziert ist.
4. Du fängst mit dem Eigentlichen Spiel an, und schreibst so, dass du Ressourcen auf ihre Existenz prüfst und am besten jeden Schritt in eine Datei/Logfile speicherst. Widme dich einem Objekt nach dem anderen; wenn möglich sollte man das Spiel immer starten und begutachten können, nur eben mit eingeschränkter Funktionalität oder Platzhaltern.
Gut möglich, das man auch in der Letzten Phase noch mal die Idee hat, es ganz anders zu machen. Dann kann man a) seine Erkenntnisse gut dokumentieren und gleich neu anfangen oder b) seine Erkenntnisse gut dokumentieren und den bestehenden Code fertig machen. Lernen tut man dabei immer weiter, es hängt praktisch nur von dem Hang zum Perfektionismus ab, wann genau man aufhört Sachen noch mal umkrempeln zu wollen.

Win10 Prof.(x64)/Ubuntu 16.04|CPU 4x3Ghz (Intel i5-4590S)|RAM 8 GB|GeForce GTX 960
Wie man Fragen richtig stellt || "Es geht nicht" || Video-Tutorial: Sinus & Cosinus
THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld)

	Blitzjockey	Mo, Jun 07, 2010 18:34 Antworten mit Zitat
Ja, ist schon verständlich, Dein Problem. Also, was Du brauchst ist eigentlich die Grundlage in Object Orientiert Programmieren. Früher hat programmieren so angefangen, wie wir allen angefangen haben: Man hat ein Programm geschrieben das angefangen hat bei A, seine Arbeit gemacht hat bis Z, und da hat es aufgehört, es sei denn, es würde (schön mit Goto) nach A zurück geschickt. Wie Du selber schon gemerkt hast, das geht. Aber so bald Fehler auftauchen, und man was ändern muss, muss man meistens das ganze Programm neu schreiben. Als mögliche Lösung hat man irgendwann ein Konzept entwickelt, wobei ein Programm in viele kleine Programme aufgeteilt wird, alles einzelne Funktionen. Die Funktionen sollten (bzw müssen) alle selbständig sein. Sollte es in 1 Funktion ein Fehler geben, kann man konkret diese Fehler lösen, der Rest von dem Programm bekommt gar nicht mit das sich was geändert hat. Das ist so die (gánz grobe) grundlage von Object Orientiert Programmieren. Oder, um es genauer zu sagen, statt 1 Programm, scheibt man viele kleinere Objecten, die alle zusammen arbeiten. Als analogie: In den Anfänge hat man ein Programm geschrieben das ein Schachbrett mit Schachstücken dargestellt hat. Jede bewegung einer Schachstuck hat eine änderung im ganzen Programm nach sich gezogen. Es geht, ist aber recht viel Arbeit, und man kann jetzt nicht ein einzelnes Schachstück rausholen um es in ein anderes Programm zu benutzen. Der OOP-lösung wäre das man alle einzelne Schachstücken frei von einander Programmiert, und sie dann, um Hauptprogramm, mit einander kommunizieren lässt. Dabei gibt's ein paar Grundsätze den man einhalten muss, was aber ein eigenes Fachgebiet ist. Leider ist BlitzBasic3D dabei etwas beschränkt. Zum Beispeil ist eine der Grundsätze das jedes "Schachstück" all seine Daten selbst verwaltet. z.b. Seine Position. Die andere Schachstücken haben damit im Anfang nichts am Hut, es sei denn sie brauchen die Daten im Spiel, dann müssen sie das gute Stück darum bitten die Daten frei zu geben. Das 'verheimlichen' von Daren ist bei B3D nicht möglich, so auf anhieb. Es gibt ein paar Lösungen dazu, die sind aber Freiwillig, die müsstest Du selbst handhaben. Hier ist einen kleinen (aber schon etwas fortgeschrittene) handout bezüglich dieses OOP. Allerdings auf English: Applied Object Oriented Programming Als Hinweis (Zusätzl. zu den von Xeres) könnte ich noch das zufügen: Nimm zum Beispeil Deine Alien. Du kannst Deine Alien als Type deklarieren. In dem Fall muss jeder Einheit von dieser Type (Invader.Alien = New Alien kreiert genau 1 Einheit vom Typ Alien), selbst alle seine Daten aufbewaren. Du kannst im B3D direkt auf Typ\X-position zugreifen im Spiel ("alte" Methode). Oder Du schreibst für diesen Alien-typen eine Funktion Abfrage_X_Position. Hierbei schreibst Du eine Funktion die anschliessend den X-Position von Dein Alien zurück gibt. Hört sich komisch an, das wäre ja genau das gleiche wie direkt darauf zugreifen. Aber solltest Du im weiteren Verlauf auf einmal sehen "he, X-Position ist nicht schön, ich nenne es um in X-Pos) dann brauchst Du nur in Deine Funktion Abfrage_X_Position dies zu ändern. So lange wie die Funktionsname sich nicht ändert, interessiert es den Rest Deines Programm nicht was da passiert, hauptsache, sie bekommen die richtige Information zurück. Wenn Du alle Funktionen die Bezug haben auf 1 "Objekt" zusammen hältst, am liebsten in ein separates ".bb"-file, und diese durch "include" in Dein Hauptprogramm unterbringst, kommst Du das ganz schon näher. Du könntest zum Beispeil in so'n .BB-file auch ein Globale Variabele programmieren. Die benutzt Du aber nicht direkt, sonder, wie bei den Alien, über Funktionen. Dabei müsstest Du aber die Include direkt am anfang vom Programm machen, nicht nach dem Main. Auf jedem Fall, auch da würdest Du wieder die Daten vom Programm trennen: Solltest Du mit den Daten was anderes machen, im verlauf vom Spiel eine andere Berechnungsmethode benutzen, dann kannst Du einfach die Funktion umschreiben, anstatt im ganzen Spiel die gleiche Berechnung zu ändern zu müssen. Tut mir leid wenn's vielleicht etwas unverständlich geworden ist... Ich werde mal schauen, vielleicht schreibe ich es später noch mal neu. Ich kann aber, als "fortgeschrittene Ansatz" den Tutorial den ich oben gelinkt habe, empfehlen. Und der IDEal-entwicklungs-Umgebung, sofern Du den noch nicht benutzt, herzlich empfehlen. Lg, BlitzJ.

Blitzjockey

Mo, Jun 07, 2010 18:34
Antworten mit Zitat

Ja, ist schon verständlich, Dein Problem.

Also, was Du brauchst ist eigentlich die Grundlage in Object Orientiert Programmieren.

Früher hat programmieren so angefangen, wie wir allen angefangen haben: Man hat ein Programm geschrieben das angefangen hat bei A, seine Arbeit gemacht hat bis Z, und da hat es aufgehört, es sei denn, es würde (schön mit Goto) nach A zurück geschickt.

Wie Du selber schon gemerkt hast, das geht. Aber so bald Fehler auftauchen, und man was ändern muss, muss man meistens das ganze Programm neu schreiben.

Als mögliche Lösung hat man irgendwann ein Konzept entwickelt, wobei ein Programm in viele kleine Programme aufgeteilt wird, alles einzelne Funktionen. Die Funktionen sollten (bzw müssen) alle selbständig sein. Sollte es in 1 Funktion ein Fehler geben, kann man konkret diese Fehler lösen, der Rest von dem Programm bekommt gar nicht mit das sich was geändert hat.

Das ist so die (gánz grobe) grundlage von Object Orientiert Programmieren. Oder, um es genauer zu sagen, statt 1 Programm, scheibt man viele kleinere Objecten, die alle zusammen arbeiten.
Als analogie: In den Anfänge hat man ein Programm geschrieben das ein Schachbrett mit Schachstücken dargestellt hat. Jede bewegung einer Schachstuck hat eine änderung im ganzen Programm nach sich gezogen. Es geht, ist aber recht viel Arbeit, und man kann jetzt nicht ein einzelnes Schachstück rausholen um es in ein anderes Programm zu benutzen.
Der OOP-lösung wäre das man alle einzelne Schachstücken frei von einander Programmiert, und sie dann, um Hauptprogramm, mit einander kommunizieren lässt.

Dabei gibt's ein paar Grundsätze den man einhalten muss, was aber ein eigenes Fachgebiet ist.

Leider ist BlitzBasic3D dabei etwas beschränkt. Zum Beispeil ist eine der Grundsätze das jedes "Schachstück" all seine Daten selbst verwaltet. z.b. Seine Position. Die andere Schachstücken haben damit im Anfang nichts am Hut, es sei denn sie brauchen die Daten im Spiel, dann müssen sie das gute Stück darum bitten die Daten frei zu geben.
Das 'verheimlichen' von Daren ist bei B3D nicht möglich, so auf anhieb. Es gibt ein paar Lösungen dazu, die sind aber Freiwillig, die müsstest Du selbst handhaben.

Hier ist einen kleinen (aber schon etwas fortgeschrittene) handout bezüglich dieses OOP. Allerdings auf English: Applied Object Oriented Programming

Als Hinweis (Zusätzl. zu den von Xeres) könnte ich noch das zufügen:

Nimm zum Beispeil Deine Alien. Du kannst Deine Alien als Type deklarieren. In dem Fall muss jeder Einheit von dieser Type (Invader.Alien = New Alien kreiert genau 1 Einheit vom Typ Alien), selbst alle seine Daten aufbewaren. Du kannst im B3D direkt auf Typ\X-position zugreifen im Spiel ("alte" Methode).
Oder Du schreibst für diesen Alien-typen eine Funktion Abfrage_X_Position. Hierbei schreibst Du eine Funktion die anschliessend den X-Position von Dein Alien zurück gibt. Hört sich komisch an, das wäre ja genau das gleiche wie direkt darauf zugreifen.
Aber solltest Du im weiteren Verlauf auf einmal sehen "he, X-Position ist nicht schön, ich nenne es um in X-Pos) dann brauchst Du nur in Deine Funktion Abfrage_X_Position dies zu ändern. So lange wie die Funktionsname sich nicht ändert, interessiert es den Rest Deines Programm nicht was da passiert, hauptsache, sie bekommen die richtige Information zurück.

Wenn Du alle Funktionen die Bezug haben auf 1 "Objekt" zusammen hältst, am liebsten in ein separates ".bb"-file, und diese durch "include" in Dein Hauptprogramm unterbringst, kommst Du das ganz schon näher.

Du könntest zum Beispeil in so'n .BB-file auch ein Globale Variabele programmieren. Die benutzt Du aber nicht direkt, sonder, wie bei den Alien, über Funktionen. Dabei müsstest Du aber die Include direkt am anfang vom Programm machen, nicht nach dem Main.

Auf jedem Fall, auch da würdest Du wieder die Daten vom Programm trennen: Solltest Du mit den Daten was anderes machen, im verlauf vom Spiel eine andere Berechnungsmethode benutzen, dann kannst Du einfach die Funktion umschreiben, anstatt im ganzen Spiel die gleiche Berechnung zu ändern zu müssen.

Tut mir leid wenn's vielleicht etwas unverständlich geworden ist... Ich werde mal schauen, vielleicht schreibe ich es später noch mal neu. Ich kann aber, als "fortgeschrittene Ansatz" den Tutorial den ich oben gelinkt habe, empfehlen.

Und der IDEal-entwicklungs-Umgebung, sofern Du den noch nicht benutzt, herzlich empfehlen.

Lg,
BlitzJ.

	M0rgenstern	Mo, Jun 07, 2010 20:19 Antworten mit Zitat
@ Xeres: Das was du sagst ist alles sehr einleuchtend. Nur Punkt 3 verstehe ich nicht ganz. Also da weiß ich nicht genau was du meinst, bzw was genau ich mir darunter vorzustellen habe. Zu Punkt 4: Das mit der eingeschränkten Funktionalität ist einfach mein Problem. Dazu müsste das ganze total modular sein. Verschiedene Objekte im Spiel müssten, wenn sie bestimmte Daten etc nicht bekommen eine "Übersprungshandlung" einleiten. Und ich weiß einfach nicht, wie ich das bewerkstelligen sollte das ganze so modular zu machen. Das sind auch schon so Sachen in der Hauptschleife: Ich habe 3 oder 4 For-Schleifen. Eine, die die Gegner updated, eine für die Map, eine für die Spieler und eine für Schüsse. Damit gehe ich die Listen der Klassen durch. Wenn ich jetzt aber z.b. eine Kollision überprüfen will, dann muss ich die For-Schleifen von zwei Klassen ineinander verschachteln. Ich bin mir einfach nicht sicher, ob man das so machen muss, bzw ob es da keine bessere Möglichkeit gibt etc. Das wird bei vielen Objekten und vielen Klassen auch einfach total langsam. Muss man das wirklich so machen oder gibt es da andere Möglichkeiten etc.? Es kommt mir einfach seltsam vor. Was auch einfach problematisch ist, ist die zyklische Abhängigkeit von Klassen: Meine Klasse TEnemy hat z.B. ein Attribut, Zielpunkt:TWaypoint. Es KENNT somit ein Objekt vom Typ TWaypoint. Also muss ich die Klassendatei Waypoints.bmx in die Datei Enemy.bmx importieren mit "Import". Dann habe ich aber, als Childklasse von TWaypoint, die TStartpoint Klasse. Diese wiederrum erstellt Objekte der Klasse TEnemy. Also müsste ich hier die Enemy.bmx importieren... Das führt dann aber zu zyklischem Importieren. Ich hoffe, ihr versteht worauf ich hinaus will: Ich hab eine ein so stark verzahnte Klassenabhängigkeit, und ich weiß nicht wirklich wie ichs umgehen soll @Blitzjockey: Ich weiß jetzt nicht genau, wie du darauf kommst, dass ich immernoch B3D nutze. Ich nutze inzwischen BMax und arbeite inzwischen etnsprechend objektorientiert mit Klassenmethoden etc. Dementsprechend nutze ich auch "Import" was halt zu Fehlern geführt hat mit meiner alten Struktur. Ich hätte, um die Klassen zufrieden zu stellen, einen zyklischen Import vornehmen müssen, was ja nicht geht. Den Link werde ich mir später mal richtig durchlesen, habs jetzt nur überflogen, scheint aber richtig gut zu sein. Die Sache mit den Gib_Variable (und was ich ausm Info unterricht für Delphi entsprechend kenne auch Setze_Variable) Methoden ist eigentlich einleuchtend. Damit werde ich bestimmt in Zukunft arbeiten, danke. Aber ganz ehrlich: Objektorientiert arbeiten tu ich schon und ich nutze Ideal, aber nicht für BMax. Da nutze ich BLIDE. Lg, M0rgenstern

M0rgenstern

Mo, Jun 07, 2010 20:19
Antworten mit Zitat

@ Xeres:
Das was du sagst ist alles sehr einleuchtend.
Nur Punkt 3 verstehe ich nicht ganz. Also da weiß ich nicht genau was du meinst, bzw was genau ich mir darunter vorzustellen habe.
Zu Punkt 4: Das mit der eingeschränkten Funktionalität ist einfach mein Problem. Dazu müsste das ganze total modular sein. Verschiedene Objekte im Spiel müssten, wenn sie bestimmte Daten etc nicht bekommen eine "Übersprungshandlung" einleiten. Und ich weiß einfach nicht, wie ich das bewerkstelligen sollte das ganze so modular zu machen.

Das sind auch schon so Sachen in der Hauptschleife: Ich habe 3 oder 4 For-Schleifen. Eine, die die Gegner updated, eine für die Map, eine für die Spieler und eine für Schüsse. Damit gehe ich die Listen der Klassen durch. Wenn ich jetzt aber z.b. eine Kollision überprüfen will, dann muss ich die For-Schleifen von zwei Klassen ineinander verschachteln.
Ich bin mir einfach nicht sicher, ob man das so machen muss, bzw ob es da keine bessere Möglichkeit gibt etc. Das wird bei vielen Objekten und vielen Klassen auch einfach total langsam. Muss man das wirklich so machen oder gibt es da andere Möglichkeiten etc.? Es kommt mir einfach seltsam vor.

Was auch einfach problematisch ist, ist die zyklische Abhängigkeit von Klassen:
Meine Klasse TEnemy hat z.B. ein Attribut, Zielpunkt:TWaypoint. Es KENNT somit ein Objekt vom Typ TWaypoint. Also muss ich die Klassendatei Waypoints.bmx in die Datei Enemy.bmx importieren mit "Import".
Dann habe ich aber, als Childklasse von TWaypoint, die TStartpoint Klasse. Diese wiederrum erstellt Objekte der Klasse TEnemy. Also müsste ich hier die Enemy.bmx importieren... Das führt dann aber zu zyklischem Importieren.
Ich hoffe, ihr versteht worauf ich hinaus will: Ich hab eine ein so stark verzahnte Klassenabhängigkeit, und ich weiß nicht wirklich wie ichs umgehen soll

@Blitzjockey:
Ich weiß jetzt nicht genau, wie du darauf kommst, dass ich immernoch B3D nutze. Ich nutze inzwischen BMax und arbeite inzwischen etnsprechend objektorientiert mit Klassenmethoden etc.
Dementsprechend nutze ich auch "Import" was halt zu Fehlern geführt hat mit meiner alten Struktur. Ich hätte, um die Klassen zufrieden zu stellen, einen zyklischen Import vornehmen müssen, was ja nicht geht.
Den Link werde ich mir später mal richtig durchlesen, habs jetzt nur überflogen, scheint aber richtig gut zu sein.
Die Sache mit den Gib_Variable (und was ich ausm Info unterricht für Delphi entsprechend kenne auch Setze_Variable) Methoden ist eigentlich einleuchtend. Damit werde ich bestimmt in Zukunft arbeiten, danke.
Aber ganz ehrlich: Objektorientiert arbeiten tu ich schon Wink

und ich nutze Ideal, aber nicht für BMax. Da nutze ich BLIDE.

Lg, M0rgenstern

	Xeres Moderator	Mo, Jun 07, 2010 21:07 Antworten mit Zitat
Zu 3: Du hast eine Vorstellung davon, was du machen möchtest, bist dir aber nicht sicher wie. Dann schreibst du die benötigten Objekte und die nötigsten Funktionen um Objekte zu Erstellen und zu verwenden. Du testest aus, ob alles so funktioniert wie es soll, ob die Struktur leicht erweiterbar ist, ob es schnell genug läuft - was auch immer das Kriterium sein soll. Das irgendwo Objekte überlappen kann man nicht 100% ausschließen - manchmal muss man einfach ein Minimum an Code fertig schreiben bevor die Gesamtheit funktioniert. Wenn du Geschwindigkeitsprobleme bekommst, kannst du das vielleicht durch zusätzliche Bedingungen begrenzen - oder musst nochmal an deinem grundlegendem Konzept feilen. Schreib gleich von Anfang an Debug Funktionen, die den Ablauf mit zeichnen, welche Funktion aufgerufen wurde, ggf. wie viel Zeit gebraucht wurde. Ist auch toll wenn es kein Problem gibt und die Logdatei regelmäßig berichtet das alles toll läuft. Zitat: Was auch einfach problematisch ist, ist die zyklische Abhängigkeit von Klassen Warum bindest du Klassen denn auch zyklisch ein? Eine Hauptdatei in die alle Codeteile Includiert werden und gut ist?
Win10 Prof.(x64)/Ubuntu 16.04\|CPU 4x3Ghz (Intel i5-4590S)\|RAM 8 GB\|GeForce GTX 960 Wie man Fragen richtig stellt \|\| "Es geht nicht" \|\| Video-Tutorial: Sinus & Cosinus THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld)

Xeres

Moderator

Mo, Jun 07, 2010 21:07
Antworten mit Zitat

Zu 3: Du hast eine Vorstellung davon, was du machen möchtest, bist dir aber nicht sicher wie. Dann schreibst du die benötigten Objekte und die nötigsten Funktionen um Objekte zu Erstellen und zu verwenden. Du testest aus, ob alles so funktioniert wie es soll, ob die Struktur leicht erweiterbar ist, ob es schnell genug läuft - was auch immer das Kriterium sein soll.

Das irgendwo Objekte überlappen kann man nicht 100% ausschließen - manchmal muss man einfach ein Minimum an Code fertig schreiben bevor die Gesamtheit funktioniert.
Wenn du Geschwindigkeitsprobleme bekommst, kannst du das vielleicht durch zusätzliche Bedingungen begrenzen - oder musst nochmal an deinem grundlegendem Konzept feilen.
Schreib gleich von Anfang an Debug Funktionen, die den Ablauf mit zeichnen, welche Funktion aufgerufen wurde, ggf. wie viel Zeit gebraucht wurde. Ist auch toll wenn es kein Problem gibt und die Logdatei regelmäßig berichtet das alles toll läuft.
Zitat:

Was auch einfach problematisch ist, ist die zyklische Abhängigkeit von Klassen

Warum bindest du Klassen denn auch zyklisch ein? Wink

Eine Hauptdatei in die alle Codeteile Includiert werden und gut ist?

	M0rgenstern	Mo, Jun 07, 2010 21:10 Antworten mit Zitat
Zitat: Warum bindest du Klassen denn auch zyklisch ein? Wink Eine Hauptdatei in die alle Codeteile Includiert werden und gut ist? Das habe ich einfach versucht, aber dann hat sich z.b. TEnemy beschwert, dass er TWaypoint nicht kennt etc. Deswegen kam ich ja in dieses Import Chaos rein. Werde mir das mit den Debuglogs wohl angewöhnen. Also im Grunde: Einfach ne Struktur anlegen und nur da wo es wirklich nötig ist, Klassen "überlappen" lassen.... Okay... Thx.... Lg, M0rgenstern

M0rgenstern

Mo, Jun 07, 2010 21:10
Antworten mit Zitat

Zitat:

Warum bindest du Klassen denn auch zyklisch ein? Wink
Eine Hauptdatei in die alle Codeteile Includiert werden und gut ist?

Das habe ich einfach versucht, aber dann hat sich z.b. TEnemy beschwert, dass er TWaypoint nicht kennt etc.
Deswegen kam ich ja in dieses Import Chaos rein.
Werde mir das mit den Debuglogs wohl angewöhnen.

Also im Grunde: Einfach ne Struktur anlegen und nur da wo es wirklich nötig ist, Klassen "überlappen" lassen....

Okay...
Thx....

Lg, M0rgenstern

	Noobody	Mo, Jun 07, 2010 21:47 Antworten mit Zitat
M0rgenstern hat Folgendes geschrieben: Also im Grunde: Einfach ne Struktur anlegen und nur da wo es wirklich nötig ist, Klassen "überlappen" lassen.... Aus eigener Erfahrung bezweifle ich, dass das so möglich ist. Klar kann man wirklich unabhängigen Code wie zum Beispiel simple Mathefunktionen per Import auslagern, aber in einem komplexen Spiel hängt doch so ziemlich alles voneinander ab. Man kann keinen Kollisionscode haben, ohne die Kollisionsobjekte zu kennen und man kann auch keine Bilder zeichnen, ohne die Zeichentreiber zu kennen. Da BlitzMax aber weder Prototypen noch Vorwärtsdeklaration kennt, ist man mehr oder weniger gezwungen, externen Code per Include einzubinden. So habe ich es zumindest bisher erlebt - ich bin kein professioneller Softwareentwickler, daher gibt es vielleicht auch schönere Lösungen, die ich nicht kenne.
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Noobody

Mo, Jun 07, 2010 21:47
Antworten mit Zitat

M0rgenstern hat Folgendes geschrieben:

Also im Grunde: Einfach ne Struktur anlegen und nur da wo es wirklich nötig ist, Klassen "überlappen" lassen....

Aus eigener Erfahrung bezweifle ich, dass das so möglich ist. Klar kann man wirklich unabhängigen Code wie zum Beispiel simple Mathefunktionen per Import auslagern, aber in einem komplexen Spiel hängt doch so ziemlich alles voneinander ab. Man kann keinen Kollisionscode haben, ohne die Kollisionsobjekte zu kennen und man kann auch keine Bilder zeichnen, ohne die Zeichentreiber zu kennen.
Da BlitzMax aber weder Prototypen noch Vorwärtsdeklaration kennt, ist man mehr oder weniger gezwungen, externen Code per Include einzubinden.

So habe ich es zumindest bisher erlebt - ich bin kein professioneller Softwareentwickler, daher gibt es vielleicht auch schönere Lösungen, die ich nicht kenne.

Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

	Matthias	Di, Jun 08, 2010 11:07 Antworten mit Zitat
Ich würde dir vorschlagen für jeden Abschnitt. Testprogramme zu machen. Um Erfahrungen zu sammeln. Und erst wenn alle deine Testprogramme fehlerfrei functionieren. Kannst du mit dem eigentlichen Spiel beginnen. Aber nicht versuchen alle deine Testprogramme unter einer Haube zu bekommen. Die Testprogramme sind umsonst und waren nur dazu da Erfahrungen zu sammeln. In dem eigentlichen Spiel programmierst du alles von Grund auf neu, aber kannst diesmal auf deine Erfahrungen zurück greifen. Doch selbst dann heist das nicht das das Spiel auch was wird. Warscheinlich wirst du wenn du Anfänger bist dein Spiel 3-5 neu schreiben müssen. Übung macht den Meister.

Matthias

Di, Jun 08, 2010 11:07
Antworten mit Zitat

Ich würde dir vorschlagen für jeden Abschnitt. Testprogramme zu machen. Um Erfahrungen zu sammeln.

Und erst wenn alle deine Testprogramme fehlerfrei functionieren. Kannst du mit dem eigentlichen Spiel beginnen.

Aber nicht versuchen alle deine Testprogramme unter einer Haube zu bekommen. Die Testprogramme sind umsonst und waren nur dazu da Erfahrungen zu sammeln.

In dem eigentlichen Spiel programmierst du alles von Grund auf neu, aber kannst diesmal auf deine Erfahrungen zurück greifen.

Doch selbst dann heist das nicht das das Spiel auch was wird. Warscheinlich wirst du wenn du Anfänger bist dein Spiel 3-5 neu schreiben müssen.

Übung macht den Meister.

	M0rgenstern	Di, Jun 08, 2010 18:39 Antworten mit Zitat
Hey Matthias, danke. Das mit den Testprogrammen werde ich machen. Vor allem für Dinge, bei denen ich mir nicht sicher bin. @ Noobody: Für die Sache mit der Kollision habe ich wohl ne Lösung gefunden (noch nicht getestet). Ich schreibe eine Funktion, der ich einfach immer zwei Klassenobjekte übergebe. Die Funktion wird dann nach den Bildern fragen und die Kollisionsabfrage machen und einfach einen Wert zurückgeben. Vorher noch mit Pythagoras die Entfernung testen. Dann wäre das auf jeden fall sauber verpackt und ich müsste mir weniger Gedanken darum machen... Vielen Dank für eure Anregungen. Bin jetzt sogar motiviert mir das PanzerS Projekt anzutun und mir zumindest mal dieses Verwischen von Tiles anzueignen. Lg, M0rgenstern

M0rgenstern

Di, Jun 08, 2010 18:39
Antworten mit Zitat

Hey Matthias, danke.
Das mit den Testprogrammen werde ich machen.
Vor allem für Dinge, bei denen ich mir nicht sicher bin.

@ Noobody:
Für die Sache mit der Kollision habe ich wohl ne Lösung gefunden (noch nicht getestet).
Ich schreibe eine Funktion, der ich einfach immer zwei Klassenobjekte übergebe.
Die Funktion wird dann nach den Bildern fragen und die Kollisionsabfrage machen und einfach einen Wert zurückgeben.
Vorher noch mit Pythagoras die Entfernung testen.
Dann wäre das auf jeden fall sauber verpackt und ich müsste mir weniger Gedanken darum machen...

Vielen Dank für eure Anregungen.
Bin jetzt sogar motiviert mir das PanzerS Projekt anzutun und mir zumindest mal dieses Verwischen von Tiles anzueignen.

Lg, M0rgenstern

Übersicht

Sonstiges

Smalltalk

Nach Oben

BlitzBasic Portal

Größere Projekte wie angehen?

Betreff: Größere Projekte wie angehen?