Womit soll der Robot-Clone erstellt werden? Mit einer Programmiersprache, einem Maker oder ganz anders? Und wer würde sich für diese Aufgabe bereit erklären (wenn möglich, mehr als einer) ?
Programmiersprache oder Maker?
2005-12-11 18:32 #1
2005-12-21 15:14 #2
Jemand hat für "nichts von alledem" votiert. Wer war's und was schlägt derjenige stattdessen vor? 😃
2005-12-21 16:48 #3
Ich hab' zwar nicht dagegen gevoted, würde Euch aber zumindest auch Java vorschlagen wollen. Damit wäre man auch gleich plattformneutral. Und für ein Gemeinschaftsprojekt ist ein objektorientierter Ansatz ohnehin flexibler. Allerdings müsste man sich dann auch ersteinmal über die Klassenhierarchien unterhalten...
2005-12-21 22:28 #4
Ja, klingt nicht unlogisch 😃
Wenn ich heute gezwungen wäre das Programmieren zu erlernen, würde ich das objektorientierte Programmieren auch dem prozedualen/modularen Programmieren vorziehen.
Und wenn die Klassenhierarchie stimmt, dann ist sogar gleichzeitiges Arbeiten und testen möglich. So dass, man den einzelnen Programmierern bestimmte Ziele setzen kann. Und die "Produkte" dann später nur noch zusammenfügen muss. Und während der eine zum Beispiel an dem Soundobjekt arbeitet, können alle anderen Programmierer die auf dieses zugreifen müssen, mit einem Platzhalterobjekt (das dem vorher gemeinschaftlichen Konzept entspricht) arbeiten.
Den Versuch das ganze bildlich und den Unterschied der beiden Programmierarten zu erklären, lasse ich lieber 😃
Wenn ich heute gezwungen wäre das Programmieren zu erlernen, würde ich das objektorientierte Programmieren auch dem prozedualen/modularen Programmieren vorziehen.
Und wenn die Klassenhierarchie stimmt, dann ist sogar gleichzeitiges Arbeiten und testen möglich. So dass, man den einzelnen Programmierern bestimmte Ziele setzen kann. Und die "Produkte" dann später nur noch zusammenfügen muss. Und während der eine zum Beispiel an dem Soundobjekt arbeitet, können alle anderen Programmierer die auf dieses zugreifen müssen, mit einem Platzhalterobjekt (das dem vorher gemeinschaftlichen Konzept entspricht) arbeiten.
Den Versuch das ganze bildlich und den Unterschied der beiden Programmierarten zu erklären, lasse ich lieber 😃
2005-12-22 13:58 #5
Nur damit ich nicht missverstanden werde: Mit objektorientiert meinte ich nicht die Aufteilung in verschiedene Module (Sound, Eingabe, Darstellung etc.) sondern eine elementare Abstraktion der Dinge im Spiele (animierte Figuren, Dinge zum Mitnehmen, Dinge für Interaktion etc.) sowie ein Regelwerk für die Interaktionen. Das hätte den immensen Vorteil, dass man später einzelne Dinge mit umfassender Funktionalität erweitern kann, ohne dass die Engine angefasst wird.Quote:
Und während der eine zum Beispiel an dem Soundobjekt arbeitet,...
Das wäre eine Entkopplung der Engine-Schreiber, welche sich um Dinge wie das Bewegen der Figuren oder das Erkennen von Kollissionen kümmern müssen. Was für eine Figur von der Engine bewegt wird, muss erstmal egal sein.
Dafür kann jemand, basierend auf der Interface-Definition einer Figur, völlig neue Wesen erschaffen. Ich würde sogar die Bewegungs-KI in eine eigene Hierarchieebene packen und nicht bei der eigentlichen Figur implementieren. Damit könnte man recht leicht verschiedene Viecher erschaffen, oder mehrere Helden, die man abwechselnd steuern kann.
Nur: Um eine solche, skalierbare Hierarchie zu definieren, die ja dauerhaft für alle Seiten verbindlich ist, muss man ganz tief in die Gedankenkiste absteigen. Denn wenn man hier einen Fehler macht, hat man später ganz, ganz große Probleme...
Ach so, falls es niemand erkannt hat: Die Hauptproblematik für einen solchen, skalierbaren, objektorientierten Ansatz sind die zugehörigen Objekt-Grafiken, welche keine OO-Sprache direkt unterstützt. Wenn man gekapselte Ein-Datei-Objekte anbieten möchte, käme man um irgend eine Art von Tool nicht herum, mit welchem man Code und Grafik zusammenbinden kann...
2005-12-26 18:02 #6
Hallo,
ich hab für "nichts von all dem" gestimmt.
Mein Vorschlag wäre Java oder Python.
Entwerder Java weil's schön objektorientiert und plattformunabhängig ist. Oder Python, dass die gleichen Vorteile bietet und leicht zu Programmieren ist. Außerdem hab ich das auch schon mal in der Uni für OpenGL-Programmierung genommen. Die Einarbeitungszeit war ziemlich kurz und das Ergebnis dafür recht gut.
Gruß
Fred
ich hab für "nichts von all dem" gestimmt.
Mein Vorschlag wäre Java oder Python.
Entwerder Java weil's schön objektorientiert und plattformunabhängig ist. Oder Python, dass die gleichen Vorteile bietet und leicht zu Programmieren ist. Außerdem hab ich das auch schon mal in der Uni für OpenGL-Programmierung genommen. Die Einarbeitungszeit war ziemlich kurz und das Ergebnis dafür recht gut.
Gruß
Fred
2005-12-29 12:11 #7
Wenn man Sound und Grafikfunktionen aber in je eine Klasse packen würde, könnte man doch aber verhindern, das bestimmte Klassen Zugriff auf die Befehle haben, oder (mittels "friend" glaube ich)?
Denn es macht für mich keinen grossen Sinn, wenn jemand während des Schreibens eines Spielobjektes einfach auf diese "lowlevel" Funktionen zugreift, weil er etwas bestimmtes erreichen will, das man beim Entwerfen der Hierarchie übersehen hat. Dieser Zugriff könnte dann nämlich den Ablauf einer/iger Funktionen stören, die z.B. festlegen welche Grafiken in welcher Reihenfolge (oder überhaupt) gezeichnet werden.
Trennung von "KI" und Objektdefinition ist eine gute Idee. ( Würde es aber nicht unbedingt KI nennen, eher Controller 😃 ) Dann wären in dem Controllerinterface Funktionen um etwa zu überprüfen, wohin das Objekt als nächstes gehen soll. Beim NPCs wären das Wegfindungsroutinen, beim vom Spieler gesteuerten Objekt Auswertungen von Maus- und Tastaturereignissen. Also wäre on-the-fly Spielfigur wechseln realisierbar.
(Ähnliche Funktion fürs Inventar? Roboter haben ein Mini-Inventar. Spielergesteuerte Figuren können jeweils auch ein "persönliches" Inventar haben???)
Hm, die Grafiken mit 256 Farben aus einer Palette, in einem Bytearray speichern. So könnten Farbänderungen (Lichtverhältnisse, Ein/Ausblenden) mittels Modifikation der Palette realisiert werden. Wenn man C++ als Programmiersprache nimmt, kann man als Bildformat XPM nehmen (Bildpunkte werden als C Quellcode mittels eines Char Arrays gespeichert).
Aber besser gefiele mir, wenn man für die Spielobjekte eine Skriptsprache nehmen würde. Am besten eine Objektorientierte (JewelScript ist (fast) wie C++ / für LUA gibt es auch eine Technik um Klassen + Vererbung zu realisieren). Dann braucht die Engine nur noch ein Interface bereitstellen.
So, jetzt aber mal ne andere Frage 😉 Die Ideen kamen doch jetzt zum größten Teil von dir, Andreas. Aber wenn die Community annähernd das alles realisieren würde, dann wäre doch dein Roboteditor hinfällig? Naja, bis aus die Verwendung von einigen Grafiken, Sounds und so. Das kann aber nicht Sinn der ganzen Sache sein, oder? Bei einer einzelnen Person die die Programmierarbeiten an einem Clone macht (evt. noch eine zweite für Grafik, Szenen, Story) ist die Chance doch eher gering, das er eine universelle Engine herbeizaubert. Aber wenn sich viele Leute jetzt hinsetzten und Ideen diskutieren und herum Planen, dann wird unweigerlich solch eine universelle Robotengine (wenn auch nur erstmal theoretisch) entstehen.
Als Beispiel möchte ich mal die freie Creatures Engine nennen. Erst wollten die Leutchen nur eine Creatures 3 Engine schreiben, die z.B. höhere Auflösungen + Farbtiefe unterstützt, ein paar Geschwindigkeitsverbesserungen vornehmen und leichtere Programmierung eigener Objekte einbauen. Als ich nun vor einer Woche mal wieder dort vorbei geschaut habe, musste ich feststellen, das man dort jetzt an einer universellen Engine bastelt, die alle Versionen der Creatures Reihe unterstützen soll.
Denn es macht für mich keinen grossen Sinn, wenn jemand während des Schreibens eines Spielobjektes einfach auf diese "lowlevel" Funktionen zugreift, weil er etwas bestimmtes erreichen will, das man beim Entwerfen der Hierarchie übersehen hat. Dieser Zugriff könnte dann nämlich den Ablauf einer/iger Funktionen stören, die z.B. festlegen welche Grafiken in welcher Reihenfolge (oder überhaupt) gezeichnet werden.
Trennung von "KI" und Objektdefinition ist eine gute Idee. ( Würde es aber nicht unbedingt KI nennen, eher Controller 😃 ) Dann wären in dem Controllerinterface Funktionen um etwa zu überprüfen, wohin das Objekt als nächstes gehen soll. Beim NPCs wären das Wegfindungsroutinen, beim vom Spieler gesteuerten Objekt Auswertungen von Maus- und Tastaturereignissen. Also wäre on-the-fly Spielfigur wechseln realisierbar.
(Ähnliche Funktion fürs Inventar? Roboter haben ein Mini-Inventar. Spielergesteuerte Figuren können jeweils auch ein "persönliches" Inventar haben???)
Hm, die Grafiken mit 256 Farben aus einer Palette, in einem Bytearray speichern. So könnten Farbänderungen (Lichtverhältnisse, Ein/Ausblenden) mittels Modifikation der Palette realisiert werden. Wenn man C++ als Programmiersprache nimmt, kann man als Bildformat XPM nehmen (Bildpunkte werden als C Quellcode mittels eines Char Arrays gespeichert).
Aber besser gefiele mir, wenn man für die Spielobjekte eine Skriptsprache nehmen würde. Am besten eine Objektorientierte (JewelScript ist (fast) wie C++ / für LUA gibt es auch eine Technik um Klassen + Vererbung zu realisieren). Dann braucht die Engine nur noch ein Interface bereitstellen.
So, jetzt aber mal ne andere Frage 😉 Die Ideen kamen doch jetzt zum größten Teil von dir, Andreas. Aber wenn die Community annähernd das alles realisieren würde, dann wäre doch dein Roboteditor hinfällig? Naja, bis aus die Verwendung von einigen Grafiken, Sounds und so. Das kann aber nicht Sinn der ganzen Sache sein, oder? Bei einer einzelnen Person die die Programmierarbeiten an einem Clone macht (evt. noch eine zweite für Grafik, Szenen, Story) ist die Chance doch eher gering, das er eine universelle Engine herbeizaubert. Aber wenn sich viele Leute jetzt hinsetzten und Ideen diskutieren und herum Planen, dann wird unweigerlich solch eine universelle Robotengine (wenn auch nur erstmal theoretisch) entstehen.
Als Beispiel möchte ich mal die freie Creatures Engine nennen. Erst wollten die Leutchen nur eine Creatures 3 Engine schreiben, die z.B. höhere Auflösungen + Farbtiefe unterstützt, ein paar Geschwindigkeitsverbesserungen vornehmen und leichtere Programmierung eigener Objekte einbauen. Als ich nun vor einer Woche mal wieder dort vorbei geschaut habe, musste ich feststellen, das man dort jetzt an einer universellen Engine bastelt, die alle Versionen der Creatures Reihe unterstützen soll.
2006-06-08 10:32 #8
Hallo,
Wie ich schon mehrmals hier im Forum (z.B. bei meinem eigenen Robot-Klon usw.) angemerkt habe, kann ich Lazarus (www.lazarus.freepascal.org/ ) sehr empfehlen.
Lazarus ist eine auf Free Pascal basierende RAD-Entwicklungsumgebung. RAD (Rapid Application Development) heißt, dass man sehr leicht GUI-Anwendungen programmieren kann. Man hat quasi bereits sein Formular, in das man leicht irgendwelche Bilder oder Buttons oder sonstige Steuerelemente per Drag&Drop draufziehen kann und mit einem Klick gelangt man direkt in die speziellen Events der Steuerelemente (z.B. das Klick-Ereignis bei einem Button) und kann den Code hierfür bearbeiten. Im Prinzip so, wie man es von Delphi oder Visual Basic gewohnt ist.
Free Pascal ist ein freier Open Source Kompiler für Pascal, der quasi auf allen Plattformen läuft, also plattformunabhängig ist. Lazarus enthält dazu das LCL, eine Library für alle grafischen Funktionen. Unterstützt werden dabei alle gängigen Widget-Systeme wie z.B. Win32, GTK, GTK2, Qt, Carbon, usw. (manche davon sind noch in der Entwicklung, aber die wichtigsten wie GTK und Win32 sind nutzbar). Ein mit Lazarus entwickeltes Programm ist also direkt lauffähig auf allen wichtigen Plattformen, was heutzutage recht wichtig ist.
Außerdem ist Free Pascal eine sehr mächtige und schöne Programmiersprache.
Für komplexere Spiele gibt es natürlich auch OpenGL, welches leicht in Lazarus benutzt werden kann.
Guckt euch das System einfach mal an. Guckt euch vielleicht auch mein kleinen Robot-Klon an, der als Demonstration von Lazarus dient (www.az2000.de/projects/robot2/ ).
Auf der Seite von Lazarus findet ihr Versionen sowohl für Windows, Linux (unter Gentoo (www.gentoo.org ) ist die Installation aber noch einfacher: einfach 'emerge lazarus' eintippen) als auch für Mac OS X (hierfür ist ein wenig Vorarbeit nötig, da noch ein paar weitere Libs benötigt werden; eine genaue Beschreibung gibt es im Wiki). Der Code bei meinem Klon sollte direkt unter allen Plattformen ohne weitere Anpassung laufen.
Viele Grüße,
Albert
Wie ich schon mehrmals hier im Forum (z.B. bei meinem eigenen Robot-Klon usw.) angemerkt habe, kann ich Lazarus (www.lazarus.freepascal.org/ ) sehr empfehlen.
Lazarus ist eine auf Free Pascal basierende RAD-Entwicklungsumgebung. RAD (Rapid Application Development) heißt, dass man sehr leicht GUI-Anwendungen programmieren kann. Man hat quasi bereits sein Formular, in das man leicht irgendwelche Bilder oder Buttons oder sonstige Steuerelemente per Drag&Drop draufziehen kann und mit einem Klick gelangt man direkt in die speziellen Events der Steuerelemente (z.B. das Klick-Ereignis bei einem Button) und kann den Code hierfür bearbeiten. Im Prinzip so, wie man es von Delphi oder Visual Basic gewohnt ist.
Free Pascal ist ein freier Open Source Kompiler für Pascal, der quasi auf allen Plattformen läuft, also plattformunabhängig ist. Lazarus enthält dazu das LCL, eine Library für alle grafischen Funktionen. Unterstützt werden dabei alle gängigen Widget-Systeme wie z.B. Win32, GTK, GTK2, Qt, Carbon, usw. (manche davon sind noch in der Entwicklung, aber die wichtigsten wie GTK und Win32 sind nutzbar). Ein mit Lazarus entwickeltes Programm ist also direkt lauffähig auf allen wichtigen Plattformen, was heutzutage recht wichtig ist.
Außerdem ist Free Pascal eine sehr mächtige und schöne Programmiersprache.
Für komplexere Spiele gibt es natürlich auch OpenGL, welches leicht in Lazarus benutzt werden kann.
Guckt euch das System einfach mal an. Guckt euch vielleicht auch mein kleinen Robot-Klon an, der als Demonstration von Lazarus dient (www.az2000.de/projects/robot2/ ).
Auf der Seite von Lazarus findet ihr Versionen sowohl für Windows, Linux (unter Gentoo (www.gentoo.org ) ist die Installation aber noch einfacher: einfach 'emerge lazarus' eintippen) als auch für Mac OS X (hierfür ist ein wenig Vorarbeit nötig, da noch ein paar weitere Libs benötigt werden; eine genaue Beschreibung gibt es im Wiki). Der Code bei meinem Klon sollte direkt unter allen Plattformen ohne weitere Anpassung laufen.
Viele Grüße,
Albert
2006-06-09 05:29 #9
Ich stimme nicht ab, weil's mir letztlich egal ist. Ich werde nicht aktiv an der eigentlichen Programmieung teilnehmen. 😫
IMHO verderben zu viele "Köche den Brei". Letztlich müsste einer hier federführend sein, eine Vorlage schaffen, die dann von anderen geprüft, erweitert und korrigiert werden könnte. Die federführende Person muss dann halt alle Änderung freigeben. Java wäre auch mein Vorschlag, schon wg. Plattformunabhängigkeit.
Viel Spaß dabei! Hoffentlich kommt wirklich etwas 'raus. 😀
Gruss,
____________
_/_lachmann
/
IMHO verderben zu viele "Köche den Brei". Letztlich müsste einer hier federführend sein, eine Vorlage schaffen, die dann von anderen geprüft, erweitert und korrigiert werden könnte. Die federführende Person muss dann halt alle Änderung freigeben. Java wäre auch mein Vorschlag, schon wg. Plattformunabhängigkeit.
Viel Spaß dabei! Hoffentlich kommt wirklich etwas 'raus. 😀
Gruss,
____________
_/_lachmann
/
Gruß,
_________
_/_
/lachmann
2006-06-15 17:59 #10
(FirstPost 😉 )
Einmal meine 2 cent:
Ich finde OO ist für ein Spiel wie Kanonen auf Spatzen.
Erstmal ist OO ein Resourcenfresser, hatte mal irgendwo ein Beispiel gesehen wo ein HelloWorld als OO für Win32 auf die Spitze getrieben wurde mit ca 70 Zeilen Code, dann kann man auch Prozedural vernünftig programmieren und zum Schluss sind OO Programme meist um die 20% langsamer als wie Prozedurale.
Ich hab für FB gevoted weil FB auf Win und Linux läuft, es für ein Basic relativ flott ist und weil keiner der mitmachen will erst teure Software kaufen muss. Überdies kann fast jeder Basic und keiner muss erst eine neue Programmiersprache lernen wenn er mitmachen will.
Einmal meine 2 cent:
Ich finde OO ist für ein Spiel wie Kanonen auf Spatzen.
Erstmal ist OO ein Resourcenfresser, hatte mal irgendwo ein Beispiel gesehen wo ein HelloWorld als OO für Win32 auf die Spitze getrieben wurde mit ca 70 Zeilen Code, dann kann man auch Prozedural vernünftig programmieren und zum Schluss sind OO Programme meist um die 20% langsamer als wie Prozedurale.
Ich hab für FB gevoted weil FB auf Win und Linux läuft, es für ein Basic relativ flott ist und weil keiner der mitmachen will erst teure Software kaufen muss. Überdies kann fast jeder Basic und keiner muss erst eine neue Programmiersprache lernen wenn er mitmachen will.
2006-06-15 19:02 #11
Nochmal willkommen im Forum, muss trotzdem gleich 'mal ein wenig kontern...😉
Das mit der Performance will ich auch nicht so pauschal stehen lassen. Sicher hat jeder schon bemerkt, dass insbesondere die ganzen MFC-Anwendungen, die mit der C++-Basis ja ebenfalls einen OO-Ansatz verfolgen, in der Regel langsamer und fetter daher kommen, als äquivalente aber prozedural implementierte Applikationen.
Aber das muss wirklich nicht so sein! Teuer bezüglich der Performance sind bei den OO-Sprachen das ständige Gebrauchen von dynamischen Objekten wie z.B. Strings. Wenn die Performance kritisch ist, muss man das eben lassen.
Nur 'mal als Vergleich: Das Windows-Robot verfolgt einen komplett objektorientierten Ansatz, was die Schnittstellen-Definition betrifft. Da aber zur Laufzeit fast nirgends dynamische Objekte zum Einsatz kommen, verliert man dadurch auch keinerlei Performance.
Technisch gesehen arbeitet die Windows-Version sogar ziemlich ähnlich wie die DOS-Version. Nur verwendet sie statt üblen Type-Casts, Funktions-Tabellen und sonstigem pseudo-OO-Krempel eben saubere Objekt-Schnittstellen. Das bisserl Overhead durch virtuelle Methoden nehme ich da gerne in Kauf.
Tja, und bezüglich der Performance kommt man wohl um Java nicht herum. Ich hab' da 'mal sehr intensive Tests durchgeführt und war ziemlich sprachlos, als die Java-Routinen regelmäßig meinen nativen, prozeduralen C-Code abgehängt haben. Und zwar plattformneutral mit dem gleichen Binary auf Windows, Linux, Solaris und Mac...
Ansonsten sollte man den Begriff "Performance" 'mal genau spezifizieren. Erfahrungsgemäss sind bei 2D-Spielen lediglich die Zeichen-Routinen kritisch, vor allem dann, wenn sich viel bewegt. In allen anderen Teilen der Programmierung ist die Performance meist völlig zu vernachlässigen.
Nur 'mal so... 😉
So gerne ich mich aus der Diskussion auch raushalten würde, aber das kann ich so pauschal wirklich nicht stehen lassen. Denn insbesondere bei einem solch offenem System wie einem Spiel, wo während der Implementation sicher massig Ideen reinfließen werden, ist es wahnsinnig wichtig, dass gleich zu Beginn die Schnittstellen sauber definiert werden. Und da hilft ein OO-Ansatz nun einmal ungemein. Diesbezüglich nehme ich hier eine genau entgegengesetzte Position ein und sage, dass man gerade bei einer neu zu implementierenden Spiel-Engine auf einen OO-Ansatz aufsetzen sollte. Und sei es nur zur Schnittstellen-Spezifikation.Quote:
Ich finde OO ist für ein Spiel wie Kanonen auf Spatzen.
Erstmal ist OO ein Resourcenfresser, ... und zum Schluss sind OO Programme meist um die 20% langsamer als wie Prozedurale.
Das mit der Performance will ich auch nicht so pauschal stehen lassen. Sicher hat jeder schon bemerkt, dass insbesondere die ganzen MFC-Anwendungen, die mit der C++-Basis ja ebenfalls einen OO-Ansatz verfolgen, in der Regel langsamer und fetter daher kommen, als äquivalente aber prozedural implementierte Applikationen.
Aber das muss wirklich nicht so sein! Teuer bezüglich der Performance sind bei den OO-Sprachen das ständige Gebrauchen von dynamischen Objekten wie z.B. Strings. Wenn die Performance kritisch ist, muss man das eben lassen.
Nur 'mal als Vergleich: Das Windows-Robot verfolgt einen komplett objektorientierten Ansatz, was die Schnittstellen-Definition betrifft. Da aber zur Laufzeit fast nirgends dynamische Objekte zum Einsatz kommen, verliert man dadurch auch keinerlei Performance.
Technisch gesehen arbeitet die Windows-Version sogar ziemlich ähnlich wie die DOS-Version. Nur verwendet sie statt üblen Type-Casts, Funktions-Tabellen und sonstigem pseudo-OO-Krempel eben saubere Objekt-Schnittstellen. Das bisserl Overhead durch virtuelle Methoden nehme ich da gerne in Kauf.
Tja, und bezüglich der Performance kommt man wohl um Java nicht herum. Ich hab' da 'mal sehr intensive Tests durchgeführt und war ziemlich sprachlos, als die Java-Routinen regelmäßig meinen nativen, prozeduralen C-Code abgehängt haben. Und zwar plattformneutral mit dem gleichen Binary auf Windows, Linux, Solaris und Mac...
Ansonsten sollte man den Begriff "Performance" 'mal genau spezifizieren. Erfahrungsgemäss sind bei 2D-Spielen lediglich die Zeichen-Routinen kritisch, vor allem dann, wenn sich viel bewegt. In allen anderen Teilen der Programmierung ist die Performance meist völlig zu vernachlässigen.
Nur 'mal so... 😉