[Einsteiger Hilfe] Ich will Spiele entwickeln - Was nun?

[hanakulare]

---------------------------

[Chromanoid]

Ich würde es vorziehen ein eher sprachagnostisches Tutorial anzubieten indem in jeder Sprache BeiSpiele mit Code zu sehen sind. Flash/AS3 sollte man gerade beim Anfangen außerdem auf keinen Fall vergessen. Dass Java generell langsamer ist als C# wage ich zu bezweifeln. Außerdem sollte der Leser als erstes auf Autorensysteme und Engines gestoßen werden. Wie man programmiert ist für den Anfang ja erst mal zweitrangig und teilweise noch nicht mal nötig. Ich glaube nur die wenigsten Spiele könnten einen Preis für saubere Programmierung gewinnen.

[rüp]

Tut mir leid, aber dieses Vorhaben hier solltest du nochmal ganz stark überdenken. Ich möchte jetzt nicht auf einzelne Punkte eingehen (z.B. deine so genannten "SPS" analysieren), sondern nur folgendes sagen: Tutorials können (und sollten) immer nur einzelne Aspekte beleuchten, da der Aufbau eines jeden Spiels unterschiedlich ist. Von daher solltest du lieber nicht nur nach Tutorials suchen, sondern allgemeine Programmierbücher lesen. Und das Spieleprogrammieren ganz klein anfangen. Beispielsweise erst mal ein kleines Spiel ohne Menü machen ...

[hanakulare]

-------------------------

[rüp]

Das sind doch eigentlich Fragen, die Google und Co. klären könnten, oder hast du spezifischere Verständnisprobleme?

[hanakulare]

--------------------

[Tiles]

Es gibt kein kleines Tutorial um ein kleines Spiel zu entwickeln. Dazu ist die Spieleentwicklung an sich zu komplex. Ein Spiel ist ein multimediales Vieh. Bestehend aus Grafik, Spielelogik, Programmierung, Musik und Sound Effekte und noch so einiges mehr. Und jeder Teilbereich ist mehrere Semester Studium wert. Das was du hier mal eben im Vorbeigehen als kleines Tutorial haben willst erarbeitet man sich normalerweise in Monaten und Jahren. Monate und Jahre an Erfahrung lassen sich aber nicht auf drei Zeilen in einem Forenthread komprimieren. Und in einem Forum kann man eigentlich eh nur Detailfragen beantworten. Jedes Stichwort ist meist ein eigenes Tutorial wert.

Was es gibt sind Kickstart Tutorials für den schnellen Einstieg. Du suchst dir eine Sprache oder ein Toolkit aus, schaust was es für Einsteigertutorials dafür gibt, und legst damit los. Die Dinger kratzen aber in der Regel nur die Oberfläche und behandeln meist nur einen Teilbereich wie die Sprache. Und sind meist nur für ein bestimmtes Genre gut. Der Rest ist eben dieses selber erarbeiten.

Zuerst mal musst du dich entscheiden was du überhaupt machen willst. Programmieren oder ein Spiel entwickeln. Wenns dir um das Programmieren geht und du gern in Code wühlst ist wohl eine der Sprachen plus Engine die erste Wahl. Wenn du so schnell und bequem wie möglich ein Spiel entwickeln willst solltest du dich bei den Toolkits umschauen.

[Artificial Mind]

Ich möchte dir auch nochmal einen gut gemeinten Tipp zur äußeren Form geben:
Wenn du einen Textabschnitt rot, fett, unterstrichen und doppelt so groß machst, dann kannste du nahezu sicher sein, genau den gegenteiligen Effekt zu bewirken, den du eigentlich im Sinn hattest.

[Chromanoid]

Hier mal ein paar Tutorial Links:
Stencyl (Hat umfangreiche Hilfen in StencylWorks integriert): http://www.stencyl.com
Java + Slick: http://www.programmierkurs-java.de/ (einfach die HQ Videos durcharbeiten) http://slick.cokeandcode.com/wiki/doku.php
Einführung in XNA/C#: http://create.msdn.com/en-US/education/ ... ng_started
AS3/Flash und FlashPunk/Flixel (2D Engines): http://flashpunk.net/tutorials/ http://flixel.org/help.html

[rüp]

also meine hauptfragen sind eigentlich: was hat es sich genau mit einer engine zu tun und wie stehen engines im zusammenhang mit OpgenGL und DirectX.

Wie schon gesagt, ein Internetsuchdienst sollte dir hier eigentlich weiterhelfen. Wie genau hast du bis zu diesem Zeitpunkt recherchiert, und warum sind die Erklärungen, die du bisher gefunden hast, nicht ausreichend?

[Zudomon]

Es gibt kein kleines Tutorial um ein kleines Spiel zu entwickeln. Dazu ist die Spieleentwicklung an sich zu komplex.

Aber das wäre doch mal was... gleich neben einem kleinen Tutorial, wie man eine Zeitmaschine basteln kann... mal abgesehen von der Portal-Gun :lol:
So ein Helikopter um schnell von A nach B zu kommen wäre auch genial... vielleicht gibs dazu ja auch noch das ein oder andere Mini-Tutorial ;)

[Chromanoid]

Es gibt kein kleines Tutorial um ein kleines Spiel zu entwickeln. Dazu ist die Spieleentwicklung an sich zu komplex.

Aber das wäre doch mal was... gleich neben einem kleinen Tutorial, wie man eine Zeitmaschine basteln kann... mal abgesehen von der Portal-Gun :lol:
So ein Helikopter um schnell von A nach B zu kommen wäre auch genial... vielleicht gibs dazu ja auch noch das ein oder andere Mini-Tutorial ;)

Also für Helikopter gibt's da was... http://www.innovator.mosquito.net.nz/mbbs2/index.asp :D
An für sich finde ich ein allgemeines Spieleentwicklungstutorial eigentlich nicht schlecht. Es gibt schließlich auch genügend Bücher darüber. Allerdings würde ich darin eher allgemeine Grundlagen, weitere Quellen und Recherchemethoden erläutern.

[Tiles]

Puh. Schon an den allgemeinen Grundlagen würdest du dir wohl nen Wolf tippen. Leg los :P

[Chromanoid]

Naja wenn die Leute erst mal programmieren können, dann sollte das ja nicht so viel sein... Wichtig wäre mir vor allem die Leute auf entsprechende Informationsquellen und weitere Tutorials zu stoßen. Naja wenn ich mal reich bin, dann mache ich das mal :D. Also drückt mir die Daumen :D :D.

[antisteo]

Write Games, not Engines.

Anfänger wollen ihre Spielidee verwirklichen und keine Engine schreiben. Außerdem habe ich die Erfahrung gemacht, dass zu sehre Verallgemeinerung (Plattformunabhängig, 2D oder 3D) zu sehr verwirrt für den Anfang.
Also wäre es optimaler, wenn ein Einsteiger ein Autorensystem/Game Builder vor die Nase gesetzt bekommt und daran entscheiden kann, ob Spieleentwicklung etwas für ihn ist. Allein ein RPG Maker ist schon komplex genug, dass man nicht auf Anhieb ein Super-Tolles Spiel damit machen könnte.
(und die Wahl des Autorensystems sollte natürlich sehr intelligent getroffen werden. Am besten wäre ja eins im Browser, das läuft überall und senkt die Hemmschwelle des "einfach mal probieren")

Denkbar wäre auch, zu Lernzwecken ein solches Autorensystem zu entwickeln (bzw. ein vorhandenes OpenSource-welches um interaktive Tutorials zu erweitern)

[IlikeMyLife]

Write Games, not Engines.

Anfänger wollen ihre Spielidee verwirklichen und keine Engine schreiben.

Write Games, not Engines? << Ich bin eigentlich davon ausgegangen, dass ich mir die Engine dafür anlege, um diverse funktionen für Grafik, Sound etc. aus meinem eigentlichen Projekt-Quellcode raus halten zu können.

Bitte um korrektur falls ich mal wieder verständnisschwierigkeiten habe

[Tiles]

Ganz ganz früher war Engine und Spiel so eng verzahnt dass man die passende Engine zum Spiel gleich mitentwickeln musste. Da hast du quasi gleich dein Malprogramm mitentwickelt wenn du ein paar Grafiken brauchtest. Da gabs noch nicht so viel was man einfach nehmen konnte. Die Zeiten sind aber seit einer ganzen Weile vorbei. Heute ist die Spieleentwicklung weitestgehenst von der Engineentwicklung getrennt. Die Engines werden nun hauptsächlich einfach lizensiert. Selbst für AAA Titel. Siehe UDK. Und selbst auf dem Hobbysektor gibts inzwischen einige nette Engines und Entwicklertools das deutlich besser ist als das was man selber machen könnte.

Der Punkt bei write games, not engines ist, dass du als Lone Wolf niemals auf das Qualitätslevel kommen kannst wie die grossen Firmen. An Engines wie der Cry Engine, UDK oder Unity werkeln dutzendköpfige Teams Vollzeit über Jahre. Und sie werden immer topaktuell gehalten und ständig verbessert. Wenn du also ein Spiel entwickeln willst macht es einfach keinen Sinn das Rad noch mal neu erfinden zu wollen. Die Energie und Zeit die du da verpulverst kannst du in dein Spiel stecken. Und es sieht erst noch besser aus.

[joeydee]

Der andere Punkt bei "write games, not engines" ist außerdem: du kannst eigentlich noch gar nicht wissen, was in eine Engine gehört, wenn du noch kein Spiel entwickelt hast. Ohne konkrete Erfahrung eine Grenze ziehen zu wollen was allgemein und wiederverwendbar und was spezifisch angelegt werden soll und wie alles zu verknüpfen ist, ist sehr schwierig bis unmöglich. Man neigt dazu, alles zu verallgemeinern (Sammler-Prinzip: das könnte man ja vielleicht irgendwann irgendwie (noch schlimmer: irgendwer) mal gebrauchen).

Verwirklicht man dagegen erstmal eine konkrete Spielidee as simple as possible (Toolkit oder komplett selbstprogrammiert ist dabei egal), ist es einfacher, daraus eine Idee für eine sinnvolle Klassensammlung abzuleiten, die man wirklich gebrauchen und beim nächsten Versuch leicht erweitern kann. Man lernt nicht nur was in eine Engine gehört, sondern auch das wie und warum. Aber wie gesagt, dieses Rad ist ja jetzt schon oft genug erfunden worden, deshalb sollte man auf alle Fälle den Blick über den Tellerrand wagen und existierende Engines/Toolkits (Tutorials, Dokus, Beispiele etc.) wenigstens anschauen, um zu lernen welche Herangehensweisen an typisch wiederkehrende Aufgaben es grundsätzlich gibt und was für einen selbst Sinn machen kann.

Aber zur eigentlichen Frage, ganz kurz und oberflächlich aber dafür hoffentlich anfängergerecht beantwortet:
- OpenGL, D3D: bringen schnelle Grafik auf den Bildschirm
- Statt Engine könnte man auch Bibliothek(en-Sammlung) sagen. Kurz, alles was man bei dem einem Spiel braucht und beim nächsten evtl. wieder gebrauchen könnte. Die folgenden Aufzählungen sind beispielhaft und können separat oder streng verzahnt aufauchen; Grenzen können nicht immer klar gezogen werden und sind von Engine zu Engine unterschiedlich.
Grafik-Bibliothek: verwaltet Texturen, Modelle etc. (idealerweise inkl. Laden von Platte) sowie die darzustellende Szene und sagt OGL oder D3D, wann, wie und wo sie was darzustellen haben. Ggf. auch gleich Sound.
Physik-Bibliothek: zwischen Verwaltung und Ausgabe wird noch die physikalische Welt simuliert.
Game-Bibliothek: zusätzlich wird noch künstliche Intelligenz (suchen, verfolgen, ausweichen, Entscheidungen treffen,...), ggf. noch rudimentäre Spiellogik wie Schießen, Treffen, Einsammeln etc. ausgeführt (letzteres verzahnt sich teilweise mit der Physik)
Netzwerk-Bibliothek: bietet u.a. Zeuch für Multiplayer
UI-Bibliothek: bietet grafisch anpassbare 2D-Elemente für Menüs, HUDs etc.
...ist beliebig fortzuführen

Und bei manchen Engines wird gleich eine ganze Toolchain mit angeboten, also separate Werkzeuge zum Erstellen, Konvertieren und Vorbereiten von Leveln, Modellen, Texturen, Logiken etc. für die Engine.

Was man für seine eigene Spielidee alles überhaupt braucht, und was davon direkt im Programm statt in einer Bibliothek gelöst wird, darf man selbst entscheiden.

[SebMaster]

Du weißt aber schon dass diese Community ursprünglich mal um die GameDev Bücher vom Stefan Zerbst entstanden ist? Schau mal hier:

http://www.amazon.de/s/ref=ntt_at_ep_sr ... n%20Zerbst

Auch wenn die Bücher in vielen Belangen nicht mehr aktuell sind, sind sie für den Einstieg sehr zu empfehlen!

[CrystalCoder]

Wie SebMaster schon sagte, ist es besser sich das ein oder andere Buch dazu durchzulesen, wenn man gleich ein Spiel entwickeln will.
Tutorials sind ganz gut, wenn man schon einen Kontext für das bestimmte Thema hat und es zuzuordnen weiß.

Für einen Gesamtüberblick fehlt den Tutorials eigentlich immer der Platz. Niemand würde ein "3-5 Bändiges Buch" einfach so als Tutorial veröffentlichen - denn so viel wäre mindestens nötig wenn, man noch keine Programmiererfahrungen hat.
Man müsste sich erstmal einen Überblick verschaffen was alles dazugehört und dann den Rest aus vorhandenen Tutorials zusammensuchen.
Das Problem dabei ist, dass viele Sachen sich stets weiterentwickeln und es wäre extrem schwer, das ganze aktuell zu halten.

Das sind ein Paar Gründe warum es keine derartigen Tutorials gibt.

Mit einem guten Buch für den Einstieg ist der Lernerfolg sehr viel höher und davon mal abgesehen ist es IMO wesentlich angenehmer etwas zu lesen wenn man es als Buch vor sich liegen hat.
Mit gutem Buch meine ich jetzt nicht ein Buch was sich exzessiv damit beschäftigt, wie man das ein oder andere Objekt am Bildschirm anzeigt und animiert,
sondern eins, das sich mit allem befasst, was man dazu wissen muss, ohne erstmal anzufangen eine Grafikengine zu programmieren um diese dann im letzten Kapitel in einem "Spiel" einzusetzen.
Letzteres würde wahrscheinlich in sehr Fällen dazu führen, dass man bei einem Gebiet stehen bleibt und immer wieder von neu anfängt, evtl. sein Ziel aus den Augen verliert und einem dann im schlimmsten Fall die Motivation fehlt.
Der Effekt kann auch auftreten wenn man sich durch die Tutorials wühlt. Man findet einen Haufen Tutorials wie man etwas auf den Bildschirm malt, aber keins (oder zumindest sehr sehr wenige - ich kenne keins), das einem Spieleentwicklung beibringt.

Die Buchreihe von Stefan Zerbst ist da schon eine ganz gute Richtung, wo man am erstem Spielprojekt in Band I schon sieht, dass man auch ein Spiel entwickeln kann ohne "ultratolle Grafik", denn der Vorteil dabei ist, dass man sich nciht gleich übernimmt und noch viel wichtiger: Es wurde fertig!
Ein Buch, das ich gerade lese ist z.B. "Game Coding Complete" von Mike McShaffry. Ein wirklich gutes Buch (soweit ich jetzt gelesen hab - bin auf Seite 200)! Dazu sollte man jedenfalls schonmal Programmieren können. Da wird nicht so viel Wert auf die Grafikengine gelegt, sondern da steht die Gameengine an erster Stelle und wie man eine Codearchitektur schafft die in vielen Spielprojekten Einsatz finden kann (natürlich wird auch ein ganzes Spiel entwickelt, nachdem man darauf hingearbeitet hat).

Das wichtigste beim lernen ist es sich nicht ablenken zu lassen von Spielereien und Techdemos. Beim durcharbeiten von Tutorials passiert das nur allzu schnell.

(Ich hab jetzt keine Lust das korrektur zu lesen also denkt euch eventuelle Tippfehler einfach weg :P)