Bei der UE3 muss man allerdings sagen, das sie nicht zwangsläufig wegen ihrer Modularität gekauft wird. Sicherlich wird das ein wichtiger Faktor mit sein, aber was man am häufigsten liest sind die Tools die mit der Engine kommen bzw. mit selbiger kompatibel sind. Produktivität steht noch und wird sicherlich auch immer an oberster Stelle stehen.

@traude: Das Frosch/Löwe Beispiel finde ich irgendwie unpassend. In dem Vergleich wäre Löwe vs. xbeliebiges anderes Raubtiert denke ich besser. Denn für gewöhnlich tauscht man afaik nur Module untereinander aus.

_________________
(\__/)
(='.'=)
(")_(")

Aber Du hast sie nicht fertiggestellt. Und da bist Du nicht der einzige. Das Web ist voll von toten Engines.

Ja, man kann, aber ich finde, man sollte nicht. Die Engine sollte eine API bereitstellen, die solche Funktionalität hat. Eine Multi-Schnittstellen-Engine braucht nicht von einem Skript zusammengeklebt zu werden. Sie sollte sollte aus einem Guss sein, sonst besteht die Gefahr, dass sie zu einem fehleranfälligen Zeugs verkommt.

Übrigens: Frösche und Löwen haben auch noch weitere Gemeinsamkeit: zwei Augen, ein Skelett, ein Gehirn, einen Blutkreislauf, je fünf "Finger" und "Zehen", eine Haut, Muskeln,....das wird eine ziemlich lange Liste, obwohl sie verschiedenen Arten angehören. Und Du wirst lachen, auch im Verhalten lassen sich Gemeinsamkeiten feststellen: sie betreiben Brutpflege, zum Beispiel. Es lassen sich also viele Gemeinsamkeiten finden, OBWOHL sie stammesgeschichtlich so weit voneinander entfernt sind, Daher habe ich dieses Beispiel gewählt. Einen Löwen mit einer Hyäne zu vergleichen wäre billig.

@Evil-Devil: Es geht also nicht, meinst Du?

Dann nenne mir bitte ein Beispiel zu deinem Frosch und Löwen in dem man beide gegeneinander austauschen sollte/könnte. Mir will beim besten will keines einfallen.

_________________
(\__/)
(='.'=)
(")_(")

Natürlich nicht, sonnst würde ich noch daran arbeiten, bis ich sterbe. Allgemeine Engines werden nie fertig, da sich ihr Inhalt immer und immer wieder erweitert und es gibt nie einen Punkt, wo man sagen kann das es Version 1 ist. Diese Engines sind unendlich lange Projekte, zu mindestens bis es keiner weiter entwickelt.


Ich glaube wir haben eine unterschiedliche Definition von "aus einem Guss" oder es ist ein Informationsmangel an irgendeiner Stelle aufgetreten.
UE3 nutz Scripte um z.B. Cutscenes und KI zu steuern, dabei gibt es Wegpunkte und ein paar Sensoren als Eingabe und im Script wird dann die Logik des Objektes fest gelegt und entsprechende Ausgabe, in vielen verschiedenen Formen gegeben. Das ist alles aus einem Guss und je nachdem was für ein Verhalten man benötigt weist man das entsprechende Script zu.

Eure Diskussion über Multi-Schnittstellen-Engine verstehe ich auch nicht, denn so wie du es in deinem ersten Post erklärst, wäre es in keiner Programmiersprache, ohne JIT und Codegenerator, realisierbar. Man hat in Programmiersprachen wie Delphi, C/C++ und so weiter eine feste Anzahl an Schnittstellen, jede Schnittstelle kann allerdings mehrere Implementierungen besitzen. Es ist allerdings nicht möglich zu sagen Ich Baue eine Schnittstelle IAffen und während der Laufzeit kommt noch die ITiger hinzu. Das geht nicht, da nirgends ITiger im Code, beim compilieren bekannt war und auch garnicht vom Programmcode verwendet wurde. Ich glaube du meinst was ganz anderes und auf Raten habe ich wenig lust. Stelle doch mal bitte für mich klar, was du meinst.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

@Evil-Devil:

Z.B.: "ich brauche ein vierbeiniges Tier mit zwei Augen und einer Wirbelsäule, das größer als eine Maus ist"
Oder "Ich brauche ein Tier das Blut Muskeln Knochen und Fleisch an sich hat"
Oder "Ich brauche ein Lebewesen, das Brutpflege betreibt"

Folgende Anforderung kann nur der Frosch erfüllen: "Ich brauche ein Tier, das Eier legt"
Dieses ist nur für den Löwen: " Ich brauche einen Carnivoren".

Es kommt eben auf die Anforderung an.

Auch beim Zeichnen gibt es verschiedene Wege, wie man etwas Zeichnen kann, und auch da sind die Anforderungen unterschiedlich. Was mir grade einfällt: es gibt ganz verschiedene Möglichkeiten, Schatten zu erzeugen. Ich kann jetzt einfach "Schatten" vorgeben, oder aber genauer "Schatten durch Projektion", oder "schnelle Schatten".


Nein, nicht während der Laufzeit. Ich meine, dass die Engine erweiterbar ist. Wenn ein neuer Effekt erfunden wird, dann muss ich nicht meine ganze Engine umdrehen sondern hänge diesen Effekt einfach dazu.
Oder ich baue eine neue Subengine ein, die etwas zur Verfügung stellt, was derzeitige Engines noch nicht können, weil eine neue Technik erfunden wurde.

Es nutzt nichts, über bestimmte Engines zu diskutieren, das bringt uns in keiner Weise weiter, denn das könnte ein sehr langer Thread werden.

Es ist NICHT die Frage, wie es nicht geht, sondern die Frage, wie es geht. Und insbesondere ist die Frage auch, wie man erreichen kann, dass Leute mitmachen wollen. Denn einer allein kann so ein Projekt nicht in Angriff nehmen. Dazu muss man diesen Leuten etwas bieten, denn nur sagen: ich brauche, und jetzt macht mal, und im Übrigen muss ich jetzt gehen, das ist ein bissel wenig.

Ahh, jetzt verstehe ich was du meinst.

Konkrete Features wären z.B. folgende.
Thema:Zeit
-Timer(in bestimmten abständen ein event auslösen)
-TimeSpan(festhalten von Zeitabständen in Microsekunden bis Jahre)
-Time(aktuelle Zeit in Microsekunden genauigkeit bis Stunden(UTC))
-Date(aktuelles Datum in Tagen bis Jahren(UTC))
-TimeZone(GMT Zone,Sommerzeitinformationen(start-ende,anzahl der Minuten die die Uhr um gestellt wird))
Das braucht man alles um die korrekte Uhrzeit und Datum fest zu stellen, das macht jedes Betriebssystem jedes mal, wenn sich die Uhrzeit auf dem Desktop oder sonnst wo ändert. TimeZone ist übrigens von einem Ort abhängig, also z.B. Deutschland Berlin oder Deutschland Bonn(In der regel die Hauptstadt bzw. bei sehr großen Ländern einfach die größten Städte in der nächsten Zeitzone). Die Informationen sind alle verfügbar die Datenbank, die alle gcc basierten Systeme nutzen, um das zu lösen heisst ZoneInfo. Windows hat eine eigene Datenbank, die allerdings oh wunderts exakt die gleichen Einträge hat, nur nicht ganz so aktuell ist. Java nutzt 2 Möglichkeiten, eine interne Lösung die über ein extra Tool sich die Zeitinformationen über das Netz holt und eine bibliothek die die ZoneInfo Datenbank in passende Binärform compiliert und dann auslesbar ist. Mono nutzt die gleiche Lösung und .Net sowie Windows nutzen die Windows API. Die Location, welche die absolute Minimalinformation ist, die man benötigt ist ein großes Problem, deswegen gibt es da ca 5-6 verschiedene backends die alle durchlaufen werden bis ein Ergebnis da ist, wobei das letzte der DefaultWert von ZoneInfo ist, NewYork.

Thema:Globalisierung
-String(ein oder mehrere Unicode kompatible Formate nutzen ala UTF-8, welches alle anderen Unicode Formate darstellen kann und das kleinste gemeinsame von Unicode ist sowie auch als ASCII prima nutzbar ist, es ist speicherschonender als die anderen Formate aber auch das langsamste, da man im 1Byte Align arbeiten muss, statt wie bei UTF-32 in 4Byte)
-Location(TimeZone ist immer von einem Ort abhängig, LänderCode, Ländername, Stadtname,GPS Koordinaten von Stadt)
-Language(Information zur Formatierung von Wärung,Zeiteinheiten,...)
-Localization(suchen eines Strings in der Lokalisierungsdatenbank zu einem gegebenen String und Sprache(Übersetzung))
Jedes System, wo gcc läuft ist die Bibliothek GetText verfügbar und löst alle diese Probleme unter Windows gibt es wieder eine weitere eigene Lösung die aber wieder Inkonsistent und veraltet ist. Die Information die man braucht ist Language hiebei gibt es eine tolle ISO wie bei Zeit und entsprechend auch Sprachcodes ala DE,EN,ES,.. . Schade das sich Windows nicht an Standards hällt aber man kann ja mit ein bischen Tipparbeit die Windows Sprachcodes in ISO umwandeln.

Thema:Threading
-Thread
-Condition
-Mutex
-Finalizer(dieser spezielle destruktor, für Threads, muss aufgerufen werden, bevor das Programm beenden darf und somit sicher stellt, das IOs wieder frei gegeben werden)

Thema:Garbage Collection
-SmartPointer(klasse mit einem pointer auf ein Objekt)
-Object(referenzzähler, referenzliste)
GC reduziert pointer basierte Bugs, verhindert vollständig Memoryleaks und erhöht die Effizienz von Speichernutzung durch Instanzen.

Thema:Reflection oder auch RTTI genannt.
-IReflectable
Hierzu gibt es echt ne menge unterschiedlicher Ansätze und der Geschmack geht hier ein bisschen auseinander.
Wichtig wäre auf jeden Fall Typensicherheit und die erreicht man in C++ nur durch Templates. Andere Sprachen realisieren ihre Typensicherheit durch RTTI, Paradox xD. Reflection stellt dabei nicht ein Abbild von einer Klasse zur Laufzeit bereit, sondern eine Logische Repräsentation, welche auch auf völlig andere Informationen raus laufen kann, als in den Variablen aktuell stehen. Daher nutzt man üblicherweise auch Getter und Setter, da man nicht einfach nur Variablen durch schleift.

Thema:Serialisierung
-ISerialization
Dies schleift alle nötigen Variablen eines Objektes durch ein Stream. Wobei nötigen dadurch definiert wird, dass die Erzeugung eines Objektes mit gleichen Informationsumfang gemeint ist. Hier zählen dann z.B. zwischenvariablen, Handler und ähnliche dinge nicht mehr rein sondern alles was in den Konstruktor rein Gehämmert wird. Echt praktisch, wenn man Netzwerkkommunikation auf Klassenebene führen will oder Savegames und ähnliches machen will.

Thema:Mathe
-INumber
-IMatrix
-IVektor(auch Vektoren sind Matrizen nur mit größe 1xN oder Nx1)
-IQuaternion
Math::Space
-IVolume(Hüllen)
-IBoundingVolume
-IRay

Thema:Collection
-Tree(BinaryTree(N=2),QuadTree(N=4),OctrTee(N=8),BalancedTree(N=?))
-Graph(Gewichtet und Ungewichtet)
-Array(feste Länge, nicht änderbar)
-List(dynamischer array)
-Hashtable
-Table(feste Länge und Breite)
-Queue
Alles über Templates, damit es wiederverwendbar bleibt.

Thema:Systemkern
-Exceptions(einige Basis Exceptions wie NotSupported, ArgumentOutOfRange,ArgumentException)
-Logger(man möchte nicht alles auf die Console packen und anders rum auch)
-Console(iostream was bei c++ cout und cin wäre)
-Callback(einfaches aufrufen einer fremden Methode)
-Event(eine Klasse definiert Events und andere Können an diese Angebunden werden, stirbt eine von beiden wird alles sauber aufgeräumt)

Thema:Graphic
-IContext
-IImage
-IColor
-IFont
-I3DContext
-IMesh
-IGPUProgram(können z.B. GLSL Shader sein)
-IVertexAttributeBuffer(Vertice,Normalen, Color und so weiter ... was da drin ist ist egal es wird nur mit einem Vertex assoziiert)
-IIndexBuffer
-IMaterial
-ITexture
-IFrameBuffer

Thema: GUI
-GUI(verwaltet alle Forms)
-Form(ein Fenster, kann ein Context und Widgets fassen)
-IWidget
-Basis Widgets

Thema: Audio
-ISound
-ISoundBuffer
-Adapter für Sound

Thema: KI
-IAgent(besteht aus IBehavior und IBehaviorModel)
-IBehavior(implementiert die logik)
-IBehaviorModel(implementiert notwendige physikalische dinge wie position, richtung, max-geschwindigkeit,geschwindigkeit)
-IStatemachine

Thema: Database
Hier ist es wirklich einfach, ODBC ist ein Schnittstellen Standard um Datenbanken jeglicher Art an zu binden, also kann man die API so ziemlich übernehmen.

Thema: Security
-sha(von 1 bis 512 hoch wäre sinnvoll)
-md5(backward kompatibilität zu alten Systemen)

Thema: Netzwerk
-SSH(schlicht weg Sicherheit)
-HTTP(mitlerweile sehr beliebt um News von Webseiten als XML file zu laden und dann über XSL in Gameinterne Form zu bringen)
-Torrent(seit geraumer Zeit in Nutzung(Update, komplette Clientdownloads wie AION, alle Blizzar Produkte, ...), für Dateitransfers mit hohen Durchsatz und Dateivalidierung, sowie möglichkeit auf Unterbrechung und fortsetzen)
-IRC(sehr nützlich um in Spielen den Chat zu lösen, da wirklich alles bedient wird und erweiterbar ist es auch)
-ISocket(TCP/IP beide Protokoll(und UDP) sind zu unterschiedlich für sinnvolle abstrahierung)
-IDatagramSocket(UDP)

Thema: InputDevices
-IInputDevice(liste von buttons,name)
-IAnalogButton(wert als von bis, maxValue,minValue)
-IDigitalButton(wert als true oder false)
-IButton(name,wert,typ,event)
-IActionSet(ein InputDevice,eine Liste mit Button und Event, damit man keymapping machen kann)
Man kann jeglichen Controller,Joystick,Keyboard,Mouse als Digitale oder Analoge Button interpretieren, wobei z.B. Sticks in 2 Button aufgeteilt werden(x,y), bzw. 3 wenn noch der Stick drückbar ist. Am Sony PS3 Controller findet man ~26 Analog- und Digital-Button, wenn man mit dem SDK arbeitet. 6 Analogbutton sind schon alleine Beschleunigung und Axenausrichtung. Man kann auch Grenzwerte festlegen, dann kann ein Analoger Button als Digitaler Button simuliert werden. Keyboards kann man als 4Byte Unicode Analogbutton führen und Sondertasten, sofern man diese überhaupt erfassen kann sind Digitale Button.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Nein, so weit bin ich noch lange nicht. Ich meine Schnittstelle in ihrer allgemeinsten Form, in Deiner Diktion wäre das also ISchnittstelle.

Naja das ist ja sprachabhängig. Delphi sagt Interface mit Namenskonvention I[NAME].
C/C++ kennen keine Interfaces, da diese sprache keine benötigt, man hat mehrfachvererbung.
Einige erzeugen deswegen künstlich sowas wie ein Interface und jeder nennt wie er lustig ist, da ja sowas nicht benötigt wird und daher auch nicht definiert ist. Ich nenne meine Abstrakten Klassen, die auch als Schnittstellen gedacht sind in C/C++ halt I[Name], da ich das von ObjektPascal noch so kenne.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich meine kein Pascal-Interface, denn die benutze ich nicht. Ich verwende
1. ganz normale Pascal Units (da gibt es einen Interface-Abschnitt)
2. Abstrakte Pascal Objekte

Es ist nicht nötig, für Matrizen ein Interface vorzusehen. Ich meine es so: Eine Engine hat Sub-Engines, deren Zahl unbegrenzt ist. Eine SubEngine ist ein (teilweise) abstraktes Pascal-Objekt, das dafür zuständig ist, dass ein Prozess durchgeführt wird. Ein abgeleitetes Objekt implementiert dann eine konkrete Subengine, indem es
1. die abstrakten Methoden implementiert
2. zusätzliche Methoden hinzufügt.

Dadurch dass die SubEngines eine gemeinsame Basis haben (Auch die MainEngine wird aus der Abstrakten Subengine hergeleitet), können sie eine Kommunikation aufnehmen. Ein paar Feinheiten von mir persönlich sind auch noch dabei. aber die verrate ich nicht.

Wenn das Ding funktionsfähig ist, übernimmt es einen bestimmten abgegrenzen Engine-Funktionsbereich. Ich kann aber jederzeit so eine Interface-Subengine hinzufügen, wo ich will bzw. eine bestehende SubEngine in zwei Teile zergliedern, wenn es erforderlich ist.

Timer ist eine Globale Funktion, die allen Subengines zur Verfügung stehen muss und muss daher entweder von einer SubEngine namens "Global" oder von der MainEngine selbst übernommen werden.

Renderer ist eine reine Subengine .
Die Koordination der Subengines sollte die MainEngine übernehmen, denn das ist Chefsache.

Dann sind da noch ein paar Pascal-Spezifika, z.B. das ausgiebige RTTI. Ich habe die RTTI-Unit ausgebaut und kann damit ein Script realisieren. Ist aber alles bloß im Konzept oder halb gebaut vorhanden, weil ich nämlich auch, genau wie Du oder irgend jemand anders bei Adam und Eva anfangen muss.

Wenn du das machst, dann musst du das Interface ändern und alle abhängigen Implementationen sind davon auch betroffen.

Das Thema IT Governance guckt da im kleinen um die Ecke. (Bei Sachen wie SOA ist sowas noch schwerwiegender.)

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Hi, Flash.
Ich hab ja gewusst, dass Du einen Fachausdruck einbringen kannst.

Ja klar, man sollte es vermeiden, eine bestehende Schnittstelle zu ändern. Dieses Konzept ist ja auch noch ganz jung. Ich habe schon eine vorsichtige erste Implementierung, aber ich hab noch ein paar Schwachstellen entdeckt und muss es daher noch einmal ändern. Erst wenn ich ganz sicher bin, dass das Ding hieb- und stichfest ist, wäre es möglich, dass ich das Konzept vorstelle.

Ich dachte mir eben, dass das eine Engine attraktiver machen würde, wenn man gewährleistet, dass sie auch jemand benutzen kann, der nicht die allerneueste Grafikkarte hat. Cal3D z.B. hat eine Bone Animation und ein Spring-System und brauchte dafür keine Shader.

Von Benutzern mit unterschiedlichem Level ist es zu einer Multiskalen-Engine nicht mehr weit. Das wäre ein Lern-, und Forschungsobjekt gleichzeitig. Und ich will klein anfangen: Die erste Baby-Engine darf einen Würfel rotieren.

Das ist recht interessant aber hab mit der Thematik dieses Threads leider garnichts zu tun. Du bist auf Engines Entwicklung abgeschweift, dieser Thread handelt aber über Framework. Ich bitte doch wieder auf diese Thematik zurück zu kommen oder die Zusammenhänge zum Thema besser dar zu legen, sonnst hat es keinen Nährwert für diese Unterhaltung.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ok ich klinke mich aus.

Tak, auch nach 3 Seiten und einem Abschweifen zum Engine Design sehe ich beim besten Willen keinen Grund ein Framework zu erstellen. Denn was willst du/ihr machen wenn die Technik voranschreitet? Dann müsste man jenes Framework auch wieder anpassen. Mal davon abgesehen das ich eine Engine auf etwa die selbe Stufe wie ein Framework setzen würde. Beide haben die Aufgabe mit denen von ihnen bereit gestellten Funktionen eine individuelle Funktionalität zu gewährleisten. Also entweder denke ich nicht weit genug oder ich hab irgendwo im Thread eine wichtige Info zum Verständnis überlesen.

_________________
(\__/)
(='.'=)
(")_(")

Es war von Anfang an klar, das es um ein Framework geht und keiner Engine. Spätestens bei der Erwähnung von "Spiele- und Engineentwickler viel Arbeit abgenommen werden soll". Wenn euer beider Interesse in einer Engine liegt, dann empfehle ich doch ein neuen Thread auf zu machen, statt diesen um zu biegen. Damit wäre dann auch wesentlich klarer worum es geht.
Erweitern, wie es jedes Stück Software macht.
Schau dir am besten mal SDL, VCL, .Net, Qt, Spring oder MFC an, das sind klassische Framework und dann Ogre, Panda3D, UE1-3, Source-Engine,Sauerbraten oder CrystalSpace klassische Engine's. Dir sollte dann was auffallen und wenn es so weit ist kannst du ja mal kurz im Englischen Wiki nach Application Framework und Game Engine suchen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004