Beiträge anzeigen
16
Allgemeine Diskussionen / Re: Projektseminar der Heinrich-Heine-Universität Düsseldorf
« am: 19. Dezember 2011, 21:31:49 »
Dieses "Zusammentragen" kann sich aber auch als fatale Stolperfalle herausstellen, wenn die Kommunikation im Team nicht zu 100% stimmt.
Deshalb fertig man ja normalerweise in der Industrie mehrere Dokumente an, in welchen festgelegt wird, wer was wie zu tun hat, und vor allem: Als was er es am Ende abgiebt.
Gerade AGS ist hierfür allerdings nur begrenzt geeignet, da die das einzige was wirklich vorgefertigt werden kann Grafiken, Texte und Sounds sind. Die eigentliche Programmierung könnte zwar auch, ausgelagert werden, aber das könnte dann beim einbinden in das Projekt zu Problemen führen.
Letztendlich wird der meiste Aufwand selbst dann immer noch bleiben, das ganze Zeug am Ende im Editor zusammen zu schustern. In dieser Hinsicht ist AGS nicht gerade Team-freundlich, auch wenn das natürlich durch die diversen Export-Funktionen besser geworden ist, so dass parralel an mehreren Dingen zugleich gearbeitet werden kann.
Da ich bisher kaum in Teams gearbeitet habe um Videospiele zu entwickeln, kann ich euch ansonsten nur raten, was ich aus meiner Erfahrung und nun mehr fast einem Semester Gamedesign-Studium weiß.
Meine Empfehlung wäre, euch erst einmal genau zu überlegen, was genau ihr da erschaffen wollt und was dementsprechen im Spiel alles vorkommen soll. Diese "Vision" haltet ihr dann schriftlich fest und bestimmt im idealfall jemanden, der überwacht, dass diese Vision dann auch eingehalten wird. Im Anschluss legt ihr fest, wer im Prozess der Entwicklung welche Rolle übernimmt. Normalerweise lässt sich der gesamte Prozess in "Design" und "Development" unterteilen. Grundlegend gibt es dabei 4 (manchmal auch mehr) Abteilungen:
-die Game Design-Abteilung
-die Art-Abteilung
-die Tech-Abteilung
-die Sound-Abteilung
Gerade bei kleineren Projekten gibt es da natürlich diverse Überschneidungen was die besetzung dieser Abteilungen angeht, aber es kann eine Menge bringen, sie zumindest nach diesen Aspekten in der Planung zu trennen.
Diese Abteilungen erstellen dann erst einmal Dokumente, die festlegen, was am Ende Spielinhalt sein wird, sei es in Sachen grafischer Stil, Sounds, Programmcode oder eben Gamedesign (welches meist der umfangreichste Teil ist, erst recht bei eurem Projekt, dass ja sehr viel Hintergrundgeschichte und indirekt oder direkt transportiertes Wissen beinhalten wird).
Außerdem legt das gesamte Team (meist angeleitet von der Tech-Abteilung) einige Format-Richtlinien fest, z.B. in welchen Formaten die einzelnen Abteilungen ihre Ergebnisse abliefern. Das erspart vor allem den Programmieren eine Menge Arbeit, die den ganzen Käse am Ende ja zusammenschrauben dürfen. Und wenn dann das Sound Department mal als MP3 und mal als Midi-Datei Musik abliefert, kann das zu Problemen führen (zum Beispiel hätte man in dem Fall für vielleicht nur sehr wenige MP3s eine .vox-Musikdatei, die enorm viel Speicherplatz frisst - ein wenig Planung und es lässt sich vermeiden).
Sobald diese Design-Dokumente stehen geht es an die eigentliche Umsetung. Hier wird innerhalb der in den Dokumenten vorgegebenen Richtlinien das Spiel entwickelt. Hier zahlt sich die Planung aus, da jeder mithelfen kann, da ihm die Richtlinien ein genaues Ziel vorgeben - und man sich so nur noch um die eigentliche Arbeitsteilung zu kümmern braucht.
Und nun der "eigene Erfahrung"-Part:
Da ihr euch auf die historische Korrektheit fokusieren wollt, würde ich euch empfehlen, zunächst mit dem ausarbeiten der Story und der dargstellten Umgebung (Rheinland im Mittelalter) anzufangen und dann überlegen, wie ihr diese Welt in der Spielmechanik abbilden kann. Was die Darstellung der Welt angeht, ist AGS als Adventure-Engine sicherlich äußerst dankbar. Ihr müsst euch jedoch überlegen, welche Rätsel ihr einbindet (sofern es ein Adventure werden soll), da diese ja demenstprechend extrem logisch aufgebaut sein müssen, da sie eine reale Welt abbilden.
In diesem Sinne wäre es vielleicht sogar eher sinnvoll, auf eine Rätsel-Komponente zu verzichten und den Spieler lediglich durch die Welt laufen zu lassen und ihm als hauptsächliche Interaktionsmöglichkeit den Dialog mit Personen und das Untersuchen von Gegenständen möglich zu machen. Auf diese Weise könnte der Spieler durch die Geschichte reißen, wie auch immer sie aussehen mag, ohne dass ihr krampfhaft versuchen müsst, eine weitere Spielemechanik hinein zu quetschen. Und im Wiederspruch zu euerer Aufgabe steht dies ja ebenfalls keinesfalls.
Ansonsten könnte ich euch noch raten, dass ihr euch vielleicht eine Art externen "Experten" ins Team holt, der euch bei technischen Fragen unterstützen kann, da die Arbeitsgeschwindigkeit schon etwas leiden könnte, wenn man immer erst ein Forum konsultieren muss (zumal Debuging ohne einsicht des kompletten Codes und der Fehlermeldung und allem eh immer etwas happig ist).
Abschließend bleibt mit ebenfalls nur, euch viel Glück zu wünschen und natürlich gerne weiterhin für eventuelle Fragen zur Verfügung zu stehen.
Deshalb fertig man ja normalerweise in der Industrie mehrere Dokumente an, in welchen festgelegt wird, wer was wie zu tun hat, und vor allem: Als was er es am Ende abgiebt.
Gerade AGS ist hierfür allerdings nur begrenzt geeignet, da die das einzige was wirklich vorgefertigt werden kann Grafiken, Texte und Sounds sind. Die eigentliche Programmierung könnte zwar auch, ausgelagert werden, aber das könnte dann beim einbinden in das Projekt zu Problemen führen.
Letztendlich wird der meiste Aufwand selbst dann immer noch bleiben, das ganze Zeug am Ende im Editor zusammen zu schustern. In dieser Hinsicht ist AGS nicht gerade Team-freundlich, auch wenn das natürlich durch die diversen Export-Funktionen besser geworden ist, so dass parralel an mehreren Dingen zugleich gearbeitet werden kann.
Da ich bisher kaum in Teams gearbeitet habe um Videospiele zu entwickeln, kann ich euch ansonsten nur raten, was ich aus meiner Erfahrung und nun mehr fast einem Semester Gamedesign-Studium weiß.
Meine Empfehlung wäre, euch erst einmal genau zu überlegen, was genau ihr da erschaffen wollt und was dementsprechen im Spiel alles vorkommen soll. Diese "Vision" haltet ihr dann schriftlich fest und bestimmt im idealfall jemanden, der überwacht, dass diese Vision dann auch eingehalten wird. Im Anschluss legt ihr fest, wer im Prozess der Entwicklung welche Rolle übernimmt. Normalerweise lässt sich der gesamte Prozess in "Design" und "Development" unterteilen. Grundlegend gibt es dabei 4 (manchmal auch mehr) Abteilungen:
-die Game Design-Abteilung
-die Art-Abteilung
-die Tech-Abteilung
-die Sound-Abteilung
Gerade bei kleineren Projekten gibt es da natürlich diverse Überschneidungen was die besetzung dieser Abteilungen angeht, aber es kann eine Menge bringen, sie zumindest nach diesen Aspekten in der Planung zu trennen.
Diese Abteilungen erstellen dann erst einmal Dokumente, die festlegen, was am Ende Spielinhalt sein wird, sei es in Sachen grafischer Stil, Sounds, Programmcode oder eben Gamedesign (welches meist der umfangreichste Teil ist, erst recht bei eurem Projekt, dass ja sehr viel Hintergrundgeschichte und indirekt oder direkt transportiertes Wissen beinhalten wird).
Außerdem legt das gesamte Team (meist angeleitet von der Tech-Abteilung) einige Format-Richtlinien fest, z.B. in welchen Formaten die einzelnen Abteilungen ihre Ergebnisse abliefern. Das erspart vor allem den Programmieren eine Menge Arbeit, die den ganzen Käse am Ende ja zusammenschrauben dürfen. Und wenn dann das Sound Department mal als MP3 und mal als Midi-Datei Musik abliefert, kann das zu Problemen führen (zum Beispiel hätte man in dem Fall für vielleicht nur sehr wenige MP3s eine .vox-Musikdatei, die enorm viel Speicherplatz frisst - ein wenig Planung und es lässt sich vermeiden).
Sobald diese Design-Dokumente stehen geht es an die eigentliche Umsetung. Hier wird innerhalb der in den Dokumenten vorgegebenen Richtlinien das Spiel entwickelt. Hier zahlt sich die Planung aus, da jeder mithelfen kann, da ihm die Richtlinien ein genaues Ziel vorgeben - und man sich so nur noch um die eigentliche Arbeitsteilung zu kümmern braucht.
Und nun der "eigene Erfahrung"-Part:
Da ihr euch auf die historische Korrektheit fokusieren wollt, würde ich euch empfehlen, zunächst mit dem ausarbeiten der Story und der dargstellten Umgebung (Rheinland im Mittelalter) anzufangen und dann überlegen, wie ihr diese Welt in der Spielmechanik abbilden kann. Was die Darstellung der Welt angeht, ist AGS als Adventure-Engine sicherlich äußerst dankbar. Ihr müsst euch jedoch überlegen, welche Rätsel ihr einbindet (sofern es ein Adventure werden soll), da diese ja demenstprechend extrem logisch aufgebaut sein müssen, da sie eine reale Welt abbilden.
In diesem Sinne wäre es vielleicht sogar eher sinnvoll, auf eine Rätsel-Komponente zu verzichten und den Spieler lediglich durch die Welt laufen zu lassen und ihm als hauptsächliche Interaktionsmöglichkeit den Dialog mit Personen und das Untersuchen von Gegenständen möglich zu machen. Auf diese Weise könnte der Spieler durch die Geschichte reißen, wie auch immer sie aussehen mag, ohne dass ihr krampfhaft versuchen müsst, eine weitere Spielemechanik hinein zu quetschen. Und im Wiederspruch zu euerer Aufgabe steht dies ja ebenfalls keinesfalls.
Ansonsten könnte ich euch noch raten, dass ihr euch vielleicht eine Art externen "Experten" ins Team holt, der euch bei technischen Fragen unterstützen kann, da die Arbeitsgeschwindigkeit schon etwas leiden könnte, wenn man immer erst ein Forum konsultieren muss (zumal Debuging ohne einsicht des kompletten Codes und der Fehlermeldung und allem eh immer etwas happig ist).
Abschließend bleibt mit ebenfalls nur, euch viel Glück zu wünschen und natürlich gerne weiterhin für eventuelle Fragen zur Verfügung zu stehen.
