GameEngine design

[mike1906]

Hallo Leute.

So, hab mal ne kleine Frage, die es hoffentlich zu vielen Antworten bringen wird. :)

Also, möchte mir jetzt ne GameEngine für 3D Shooter programmieren, und hätte von euch jetzt gerne Tipps was da alles reingehört, bzw. wie der Aufbau von so ner Engine genau ist. Habe schon einige kleine Spiele programmiert, aber da war nie sowas wie ne "Engine" dahinter, sondern das lief einfach... Will jetzt aber eine GameEngine schreiben die ich für einfach für neue Spiele verwenden kann. Dazu noch ein paar Erklärungen, was die GameEngine bieten muss:

* modulare erweiterbarkeit per Dll's oder statischen Libs
* C++ (C++ OHNE STL, also nur Syntax)
* einfaches einbinden meiner eigenen GrafikEngine / Fremdhersteller GrafikEngines

So, das sind mal ein paar Punkte die mir so einfallen. Wie fang ich jetzt am besten an? Was gehört in den Core? Threading? Wie sieht das Ablaufmanagement aus? Kann man Enums mit switch / case verwenden (Geschwindigkeit!!!)? Was sollte ich am Anfang schon beachten? Welche Fehler kann ich am Anfang vermeiden?

Also, schreibt mir hier bitte alles rein was euch zum Thema GameEngine Design einfällt (egal wie unwichtig es euch vielleicht erscheinen mag!)!

[antisteo]

Als erstes solltest du dir die Frage stellen, ob der Shooter Multiplayer-fähig werden soll.
Auf diese Entscheidung kann man dann schon mal ein erstes Analyseklassendiagramm basteln, wie die Entitäten in der Engine zusammenspielen und wie die Menüs mit dem Spielinhalt zusammenspielen.

[Thoran]

Also erstes würde ich mir überlegen, was deine Engine alles können soll für deinen 3D-Shooter. (Eingabe, 3D-Rendering-Umfang, Netzwerk?, Spielelogik)
Dann würde ich mir überlegen, ob du wirklich alles selber machen willst, oder nicht doch Teilfunktionalität aus Dritt-Bibliotheken nimmst.
Wenn du diese beiden Sachen hast, kannst du dir überlegen, wie du es implementieren willst. Dazu solltest du meiner Meinung nach erstmal ein grobes Konzept auf Papier machen. Das hilft ungemein.

Thoran

[grid]

Wie schon oben geschrieben solltest du zuerst mal wissen, was du ganz sicher brauchn wirst. Sicherlich wird im Laufe der Zeit noch das ein oder andere dazukommen. Leider ist Gamedev.net grad down, aber dort gibt es massig gute Artikel. (Leider auch schlechte)

Noch ein paar Sachen die mir so einfallen:
- Warum ohne STL?
- An/Einbindung an eine Skriptsprache (LUA o.ä.). Je früher man das einbaut desto weniger Testcode muss man schreiben. Man kann dann seine Tests einfach per Script oder sogar Konsole eingeben. Leider ist es nicht immer leicht, das gut einzubauen, aber ich finde es lohnt sich z.B. liegt bei mir auch die Konfiguration der Grafik Engine in einem LUA script. Ohne neu kompilieren mal schnell die Auflösung oder die Renderreihenfolge zu ändern ist schon praktisch (Models laden, mit verschiedenn Shadern ausprobieren etc.). Weiß noch nicht, ob ich das später rausnehme, falls mein aktuelles Spiel fertig wird.
- Gamestate Verwaltung Ein Spiel besteht aus mehr als nur rumrennen (Menüs/Karte/Highscore/Intro....). Endliche Automaten find ich dabei ziemlich praktisch. Damit hat man immer schön den Überblick.
- Input Handling Bei mir ist es so, dass ich einen BasisInputManager für den rudimentären Input habe. Jeder Gamestate kann nun einen speziellen InputManager haben. Damit erreiche ich, dass die eigentlichen Input Manager sehr klein und übrsichtlich sind. Ist Geschmackssache, ich finds aber gut so.
- Level- oder Mapformat Wie ist so ein Level aufgebaut. Das bedingt dann auch einigen Verwatungscode (Stichwort Octree/BSP/Portals). Hier kommt es auch darauf an, wie das Spiel aussehen soll (Indoor/Outdoor/gemischt). Das ist eine derSchnittstellen zwischen Spielemechanik, Spielelogik und Grafik. Also ist hier gute Planung wichtig. Das gleiche gilt natürlich auch für andere Spiele Entitäten.
-KI Welche Art(en) von KI willst du haben und welche Informationen benötigt sie? (AI Programming Gems alle teile)
-Physik Engine

....die Liste ist ewig lang...

Grundsätzlich würde ich, wenn du denkst, dass du ungefähr alle Teile mal bedacht hast mit einer GameLoop anfangen. Und dann schrittweiße die einzelnen "Module" mit rein nehmen.

[Schrompf]

Ich würde sagen: fang an. Sobald Du versuchst, tatsächliche Spielmechanik umzusetzen, merkst Du ganz von allein, wo es hängt. Immerhin ist eines der häufigsten Zitate, die in diesem Zusammenhang genannt werden, das hier: "Make games, not engines!"

Und sorry, wenn das böse klingt, aber: allein Deine Ablehnung der STL sagt mir bereits, dass Dir die absoluten Grundlagen fehlen, um auf Deinem aktuellen Kentnissstand eine gebrachbare Softwareplanung aufzustellen. Wenn Du jemals soweit kommst wie z.B. Krishty, DANN hast Du tatsächlich valide Gründe dafür, Teile der STL neu zu schreiben. Bis dahin solltest Du aber alles nutzen, was Du von anderen Leuten fertig kriegen kannst.

[antisteo]

Immerhin ist eines der häufigsten Zitate, die in diesem Zusammenhang genannt werden, das hier: "Make games, not engines!"

Man könnte natürlich das Spiel auch mit einer fertigen GameEngine schreiben (siehe meine Signatur), man wäre schneller und müsste sich nicht um Dinge wie Render-Architektur kümmern (die selber gemacht meistens doof aussieht, weil icht jeder Profi sein kann), aber das war ja eindeutig nicht der Titel des Threads ;)

[Schrompf]

Joa, das wäre meine Empfehlung gewesen: nimm was Fertiges. Allerdings wäre das auch meine Empfehlung an Dich gewesen, Antisteo :-)

Jeder hält die eigene Tech für das Beste. Das ist ganz natürlich. Es braucht allerdings eine gewisse Lernzeit, bevor man merkt, dass das nur für einen selbst gilt, nicht aber für andere Leute.

[Sternmull]

Also ich glaube das du dir mit deinen Anforderungen selber ein Bein stellst. Erweiterbarkeit durch DLLs/Libs klingt so als wolltest du ein Framwork bauen... und das ohne zu wissen was du eigentlich brauchst. Ablehnung der STL kann ich absolut nicht nachvollziehen. Hast du vor deine eigenen Containerklassen etc. zu schreiben? Wozu sollte das gut sein? Du willst ja sicher voran kommen und dich nicht in Details verlieren die dir vorerst nur Zeit rauben und dich nicht weiter bringen. Ebenso dürfte es für den Anfang überflüssig sein die Austauschbarkeit der Grafik-Engine zu gewährleisten. Und wenn du versuchst die Verwendung von Enums, switch-Statements und Threading zu planen bevor du einen Prototypen hast wirst du nicht weit kommen. Das sind Sachen um die man sich erst kümmert wenn tatsächlich Bedarf besteht.

Ich empfehle dir dringend Schrompfs Vorschlag zu folgen und einfach anzufangen. Versuch nicht es gleich perfekt zu machen, dass geht eh nicht. Überleg dir was du als erstes erreichen willst (z.B. durch eine einfache 3D-Welt laufen und ballern können) und arbeite erst mal auf dieses konkrete Ziel hin. Schnapp dir dabei alle Libs und Tools die dir das Leben leichter machen, dich voran bringen und Spaß machen. Versuch keine Framework zu basteln sondern bau dein Spiel (Bzw. den Prototypen mit dem du deine Gameengine testen willst). Dabei wird sich schon zeigen was funktioniert und was nicht. Wenn es halbwegs gut läuft kristallisieren sich die brauchbaren Strukturen dann wahrscheinlich von selbst heraus.

[Chromanoid]

Wie wäre es mit dem UDK? Da hast du eigentlich alles drin was du für Egoshooter brauchst... Die Lizensierung ist auch recht human, wenn man bedenkt wieviel Zeit man in eine eigene Engine investieren würde:

A team creates a game with UDK that they intend to sell. After six months of development, they release the game through digital distribution and they earn $15,000 in the first calendar quarter after release. Their use of UDK during development requires no fee. Upon release they would pay US $99.99 for a Royalty Bearing license. After earning $15,000, they would be required to pay Epic $2,500 ($0 on the first $5,000 in revenue, and $2,500 on the next $10,000 in revenue). On subsequent revenue, they are required to pay the 25% royalty.

Ansonsten gibt es natürlich auch viele andere Engines, die ggf. günstiger sind...

[kimmi]

Ich kann Schrompf und den anderen nur beipflichten: fang erst einmal an. Die ZFXCE entstand auch aus einem recht subtilen und umfangreichen Anforderungs-Katalog, der alles sehr sehr kompliziert, generisch und unhandlich gemacht hat. Resultat des Ganzen? Wir haben bis heute keinen vernünftigen Stand.
Deswegen mein Tipp: fang einfach an, deinen Ego-Shooter zusammenzubauen. Schau dir möglichst viel Middleware und andere Engines an ( es gibt jede Menge sehr guter Libs für diesen Zweck, die OpenSource sind ), wenn du nicht weiter kommt und lerne aus diesen. Du wirst unter Garantie viele Iterationen benötigen, bevor du wirklich ein brauchbares Engine-Gerüst da heraus extrahieren kannst. Aber an diesen Erfahrungen kommt man nicht vorbei.
Auch beim Enginebau gibt es halt keinen Königsweg.

Gruß Kimmi

[Thoran]

Die Ablehnugn der STL hab ich gar nicht gesehen (sollte wohl aufmerksamer lesen). Ich persönlich weiß STL zu schätzen, da ich beim Entwicklen eines Spiels wirklich absolut keinen Bock hab immer wieder aufs neue irgendwelche Standardalgorthmen zu implementieren, wenns diese schon fertig gibt. Dafür nehme ich dann eine evt. Performanceeinbuße in Kauf.

Um nach Schrompfs Vorschlag zu arbeiten, würde ich dir vorschlagen, einfach mal was zum Laden einer 3D-Umgebung zu implementieren, dann ne fertige Figur rein und schauen das du diese mit der Tastatur bewegn kannst. Da hast du den Vorteil das du schnell Ergebnisse siehst. Ist zumindest ein Anfang.

Thoran

[eXile]

Die Ablehnugn der STL hab ich gar nicht gesehen (sollte wohl aufmerksamer lesen).

Wobei ich nicht genau weiß, ob er nun meinte, dass er die Microsoft-STL-Implementierung ablehne, oder ob er den hinter der STL stehenden Standard als solches ablehnt. Letzteres kann ich nicht verstehen, für ersteres kann es in einigen Fällen - wie Schrompf schon sagte - valide Gründe geben.

Wie die anderen schon meinten, stimme ich auch der Einschätzung zu, dass man immer auf ein Ziel hin entwicklen muss. Ansonsten programmiert man im luftleeren Raum herum, und entwickelt womöglich Dinge, die am Ende für gar nichts anwendbar sind.

[mike1906]

Hallo,

danke schonmal für die Antworten.

Ich würde sagen: fang an. Sobald Du versuchst, tatsächliche Spielmechanik umzusetzen, merkst Du ganz von allein, wo es hängt. Immerhin ist eines der häufigsten Zitate, die in diesem Zusammenhang genannt werden, das hier: "Make games, not engines!"

Wenns denn so einfach wäre... auf meiner hd finden sich ~4 gig Müll, den ich irgendwann einmal angefangen habe... ist nicht so das ich neu in der Spieleprogrammierung bin (habe bereits ein komplettes Spiel für Windows (trading card game yugioh - falls es wen interessiert), inklusive Regelwerk, 2D/3D Rendering, Ablauf, etc. programmiert, das aber aus dem Beta Stadium nie rausgekommen ist).
Und bereits da stellte sich gegen Ende des Projekts heraus, das einfach anfangen nicht der richtige Entschluss war.

Habe eben auch schon viele dieser einfach mal losprogrammieren Projekte begonnen (Charakter bewegen, Terrain streaming, Koolisionstests, AnimationTests, Physik Tests, die Liste könnt ich ewig weiterführen, also lass ichs lieber...) aber letztendlich ist es Müll.

Zum Thema "Make games, not engines!": Mein Ziel ist ein Programm CryEngine 2 like - nicht weniger!

... Bis dahin solltest Du aber alles nutzen, was Du von anderen Leuten fertig kriegen kannst.

Solange ich unter Windows programmiere kommen bei mir nur libs von Microsoft in meine Projekte. Das war schon anno 2000 so, das bleibt auch 2010+ so!


Mir gehts hier nicht um irgendwelche Basisarbeit, das Stadium hab ich hinter mir, mir gehts hier darum, eine komplette GameEngine auf die Beine zu stellen die ich modular erweitern kann

Erweiterbarkeit durch DLLs/Libs klingt so als wolltest du ein Framwork bauen...

ja, ein Framework wird dabei auch entstehen!

... und das ohne zu wissen was du eigentlich brauchst.

so siehts aus!

Also, mir gehts hier um Techniken die in einer GameEngine sind, Scenegraph und so sachen, also was da alles im Hintergrund läuft (und was nicht) und wie ich meine RenderEngine, KI, Koolision, Physik, etc. am besten in einem GameEngine-Projekt (Framework, Editor, dlls, whatever) verbinden kann.

Hoffe das ganze kommt jetzt nicht zu "böse" rüber, sollte es zumindest nicht!

[Aramis]

Mein Ziel ist ein Programm CryEngine 2 like - nicht weniger!

Die CryEngine 2 zieht einen Großteil ihres Potentials aus der exzellenten Editorumgebung (Sandbox). Alleine in die duerften 50k Arbeitsstunden und mehr geflossen sein. Da wuerde ich mich ggf. schon mal fragen ob dieses Ziel praktisch zu erreichen ist. Ganz davon abgesehen dass Crytek meines Wissens durchaus ThirdParty-Code nutzt der *nicht* von Microsoft stammt.

[Alexander Kornrumpf]

Solange ich unter Windows programmiere kommen bei mir nur libs von Microsoft in meine Projekte.

???

Die STL die beim MS Compiler dabei ist, ist doch von Microsoft. Die willst du ja auch nicht. Und dann auch nicht die ganzen einschlägigen Libraries von anderen Anbietern? Warum nur?

[The_Real_Black]

Ich bin ein bischen geneugt ihn Troll zu nennen...

Solange ich unter Windows programmiere kommen bei mir nur libs von Microsoft in meine Projekte. Das war schon anno 2000 so, das bleibt auch 2010+ so! ... Mein Ziel ist ein Programm CryEngine 2 like - nicht weniger!
...
Habe eben auch schon viele dieser einfach mal losprogrammieren Projekte begonnen (Charakter bewegen, Terrain streaming, Koolisionstests, AnimationTests, Physik Tests, die Liste könnt ich ewig weiterführen, also lass ichs lieber...) aber letztendlich ist es Müll.
...
Mir gehts hier nicht um irgendwelche Basisarbeit, das Stadium hab ich hinter mir, mir gehts hier darum, eine komplette GameEngine auf die Beine zu stellen die ich modular erweitern kann
...
Also, mir gehts hier um Techniken die in einer GameEngine sind, Scenegraph und so sachen, also was da alles im Hintergrund läuft (und was nicht) und wie ich meine RenderEngine, KI, Koolision, Physik, etc. am besten in einem GameEngine-Projekt (Framework, Editor, dlls, whatever) verbinden kann.

1. Wieso? Nichts gegen MS ich bin auch ein Fan von ihnen, aber wieso will man nur MS Klassen verwenden? Und CryEngine kommt etwas Trollig rüber. Man kennt ja diese Threads ja von Developia...
2. Wenn du sauber Klassen orientiert arbeitetst solltest du keine Probleme mit der Modularität bekommen. Wenn man die Einzelteile bereits hat wieso sollten sie Müll sein? Versuche die Teile zusammen zu setzen uns gleiche sie aneinander an.
3. Eine Engine entwickeln ist eine Basisarbeit auf welche dann alle anderen Teile aufbauen. Ohne Basisarbeit kann man nichts verbessern. Modular siehe OOP wenn man so flexibel alles austauschen will muss man das Klassenkonzept verstanden haben. Wenn du Plugins schreiben willst ist dies aber ein anderer Ansatz.
4. Das Rendern und andere Ansätze gibt es bereits in fertigen MS Frameworks zB XNA, dort hat man bereits viel den Entwicklern abgenommen.

Mein Tipp beginne mal mit der Graphik und dem Content laden und erweitere diesen Kern dann um Steuerung, Levels, Kollisionserkennung, Aktionen (Jump, Feuern), ... viele viele weitere Teile ... Objektinteraktion (Tür, Schalter), Skripting, Soundsystem... noch viel mehr Teile. Plane immer nur einen Schritt nach dem anderen und setze diesen dann auch um bis er funktioniert(!). Nach einigen Iterationen sollte man eine solide kleine Gaphikengine haben. Natürlich wird man bei diesen System die alten Teile immer wieder anpassen müssen, aber nur so sieht man auch was man nicht bedacht hat.

Wenn man zuerst anfängt alles zu planen wird ma sehr lange (besonders wenn man alleine ist) nichts erreichen und auch keine Fehler in den Ideen finden. Wenn man es aber mal versuchen will sollte man sich ein UML Tool schnappen und darin planen beginnen. Dies würde mich jetzt mal interesieren wie "mike1906" seine Planung beginnen würde. Wie würdest du beginnen? Wie sieht dein erster Ansatz aus?
Beispiel: 3 Klassen für den ersten Schritt: RenderableObjekt, RenderEngine, Kamera.
Wie verschaltest du was? RenderObj.Render() oder Engine.Render(RenderObj)?
Wenn dieser Kern nicht stimmt, kann man alles andere vergessen.

"Ich würde sagen: fang an. Sobald Du versuchst, tatsächliche Spielmechanik umzusetzen, merkst Du ganz von allein, wo es hängt. "
Wenn man es als Iteratives Vorgehen bezeichnet klingt es besser oder? (Planen-Implementieren-Testen-Nächster Schritt so kommt man an sein Ziel)
"Make games, not engines!"
Wenn man keine Idee hat kann man doch mal mit was allgemeinen anfangen. Sobald man zu einer Idee kommt und wenn es nur ein Feature ist kann man auch dies umsetzen versuchen um zu ergründen ob es machbar ist. Eine Spielidee ist eine gute Vorlage, aber ohne eine Idee sollte es niemanden hindern etwas zu Programmieren.

[Chromanoid]

"Ich würde sagen: fang an. Sobald Du versuchst, tatsächliche Spielmechanik umzusetzen, merkst Du ganz von allein, wo es hängt. "
Wenn man es als Iteratives Vorgehen bezeichnet klingt es besser oder? (Planen-Implementieren-Testen-Nächster Schritt so kommt man an sein Ziel)
"Make games, not engines!"

Wie wäre es mit "Emergent Design" :) Und ich stimme natürlich zu: Soweit ich das sehe ist es kein Zufall, dass die meisten "berühmten" Engines zumindest einen Teil eines Spieltitels im Namen haben ;).

[Alexander Kornrumpf]

Wenn ihr weiter so mit BuzzWords um euch werft können wir Bullshit Bingo spielen.

[The_Real_Black]

"Emergent Design" kannte ich noch nicht. nett ^^

Wenn ihr weiter so mit BuzzWords um euch werft können wir Bullshit Bingo spielen.

Iteratives Vorgehen ist jetzt kein BuzzWord sondern eine Vorgehensweise. Wenn man ein Fan von Verfahren ist in denen es RUP-iger (*grins*) oder Extrem vorgeht lernt man nunmal, dass ein Iteratives Vorgehen etwas sinnvolstes ist was man nicht mit planlos daraufhinarbeiten gleichsetzen kann. In einen Studienprojekt gabs auch viel Planung mit meinen Kommilitonen. Es wurde zuerst versucht möglicht alles zu Planen bis man angefangen hat es zu implementieren ab da merkte man wieviel nicht planbar war. Schlieslich hat man die einzelnen Klassen immer wieder umgeplant und implementiert, sprich man ist auf einen iterativen Ansatz umgestiegen damit man das Projekt zu Ende bringen kann.

Wenn mike1906 wirklich eine Engine schreiben will (egal wieso) aber keine Spielidee dahinter hat genausowenig einen Plan was in die Engine muss, dann muss er ja nicht einfach so anfangen sondern kann auch mit einer schrittweisen Planung sich an sein Ziel heranarbeiten. Persönlich halte ich im Hobbybereich nichts von Gesamtplanungen, denn man merkt erst sehr spät wo man sich verplant hat. Dies kostet dann viel Zeit und Nerven die man sich sparen könnte wenn man nur einen Schritt nach dem anderen macht.

PS in irgendeiner ZFX Action sollte man mal die Worte Bingo und Bullshit aufnehmen... Schade gibts schon:
http://www.hjsv.com/games/bingo/bingo-d.html