Yet Another Comuptergame: Unterschied zwischen den Versionen

Aus Hacksaar Wiki
Zur Navigation springen Zur Suche springen
K
(And in the end there will be cars.)
 
(18 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
'''Yet Another Computergame'''
 
'''Yet Another Computergame'''
  
hier gehts darum, ein computerspiel zu entwickeln.
+
stand: 7.5.13
 +
autor: rob
  
an dieser stelle sind die angaben erstmal sehr krude und zu unkonkret für ein go oder einen projektplan. es geht jetzt mal darum, eine realisierbare idee zu entwickeln und sich für eine technik/toolchain (engine(s), sprache(n), tools, etc.) zu entscheiden.
+
hier gehts darum, ein indie computerspiel zu entwickeln.
 +
 
 +
an dieser stelle sind die angaben erstmal sehr krude und zu unkonkret für ein go oder gar einen projektplan. es geht jetzt erst mal darum, eine realisierbare idee zu entwickeln und sich für eine technik/toolchain (engine(s), sprache(n), tools, etc.) zu entscheiden.
 +
 
 +
 
 +
== idee ==
 +
 
 +
* status quo:
 +
* story-basierter adventure/rpg/shooter mix
 +
* open world
 +
* 3d ego-perspektive
 +
* (spaghetti-)western setting
 +
* story sollte seriös, tiefgehend und niveauvoll sein, mit (evtl. augenzwinkerndem, subtilen, surrealem und/oder morbidem) humor
 +
* spieler kann/muss mehrere charaktere spielen, u.a. auch einen hund
 +
* wenn möglich, auch auf mobilen devices spielbar, entweder als stand-alone oder konezptionell ins gameplay eingebunden (z.b. mit dem handy kann man etwas tun, was man an der konsole oder am pc nicht tun kann und es ist auch noch ortsabhängig, z.b. gegenstände ablegen/aufnehmen)
 +
 
 +
 
 +
== news ==
 +
 
 +
* wir gehen so vor, dass wir jetzt erstmal ein paar engines "evaluieren". (recherchieren und anschauen, wie die so funktionieren und damit etwas rumspielen, gegen die weiter unten bei "engine(s)" beschriebene ideal-vorstellung prüfen)
 +
* jmonkeyengine in kombi mit blender ist gerade hot
 +
* koordination zunächst jeweis an den hackMI's.
 +
* parallel fangen wir langsam mit dem storywriting an.
 +
* hot ist auch gerade die frage, wollen wir kanonisch beim wildwest-setting bleiben oder bauen wir ausserweltliche elemente ein (z.b. retrofuturismus in form von steampunk)? das beträfe gleichermassen story, ästhetik und content.
  
  
 
== todo's ==
 
== todo's ==
  
idee finden
+
* idee/konzept entwickeln
technik evaluieren
+
* arbeitstitel finden (das kind braucht ja irgendwann auch mal einen namen, ne)
gamedesign entwickeln / evtl. story entwickeln
+
* technik evaluieren (genauer: wir fangen mal mit jmonkeyengine an und sehen, wie weit wir damit kommen)
grafik erstellen
+
* story entwickeln
musik machen
+
* gamedesign entwickeln
 +
* grafik erstellen
 +
* musik machen
  
  
 
== rollen im projekt ==
 
== rollen im projekt ==
  
projektmanagement (vision, koordination, antrieb)
+
* projektmanagement (vision, koordination, antrieb)
gamedesign (gameplay, rätsel)
+
* gamedesign (gameplay, rätsel)
storywriting (setting, plot, charakter)
+
* storywriting (setting, plot, charakter, dialog)
coding
+
* voice-actors
visual-art (2d/3d, animation)
+
* visual-art (2d/3d, animation)
audio-art
+
* audio-art
testing
+
* testing
 +
* coding
 +
 
 +
== zusätzliche Infos ==
 +
http://de.slideshare.net/josezagal1/game-design-patterns-workshop-fdg2012-opening-remarks
 +
 
 +
== angepeilte ästhetik ==
  
 +
'''optisch'''
  
== idee ==
+
* das feeling soll open-world widerpsiegeln, also: weitläufig, offen, überwiegend karge wüstenlandschaft, detaillierte kleine dörfchen und städchen, aber auch wald-szenerie und blühende und spektakuläre naturparks
 +
* tendenz in richtung "Call of Juarez: Bound in Blood"
 +
* landschaftlich in richtung albert bierstadt (ein deutscher, nach usa emigrierter maler von romantisch überhöhten landschaftsmotiven)
 +
* um sich von beidem einen optischen eindruck zu verschaffen, bitte eine internet-bildersuche bemühen
 +
 
 +
'''akustisch'''
  
momentane tendenz:
+
* wüstenmässig, karg, leer
story-basierter adventure/rpg/shooter mix
+
* windgeräusche, hawk-cries, slide-gitarre, leichte synth-pads, etc.
3d ego-perspektive
+
* selbstgemachte musik, darf ruhig etwas rohen, semi-amateurhaften charme haben
western setting
+
* musikstücke sollen der dramaturgischen situation angepasst sein
spieler kann/muss mehrere charaktere spielen (maniac mansion), z.b. auch einen hund
+
* sprache des spiels deutsch oder englisch? (sollen voice-actors englisch sprechen, egal mit welchem akzent; oder deutsch, u.u. sogar absichtlich mit deutschem akzent)
mit mobiler komponente (ingress)
 
  
  
 
== technik-evaluation ==
 
== technik-evaluation ==
  
momentane tendenz: für die ouya; ne game engine wäre schön; alt. 3d engine; haupt-sprache: scala;
+
* aktuelle tendenz: jmonkey
 +
* vorherige tendenz: blender
 +
* vorherige tendenz: mit hilfe von unity3d für die ouya entwickeln
 +
wir haben folgende optionen:
 +
* entweder eine game-engine benutzen
 +
* oder ein arsenal an engines/libs zusammenschnüren (grafik, audio, 2d-gui, speedtree etc.)
 +
* oder modding
 +
 
 +
 
 +
== engine(s) ==
 +
 
 +
wir müssen sicherlich kompromisse eingehen, aber ideal und traumhaft wäre eine
 +
# feature-mässig aktuelle,
 +
# production-grade,
 +
# linux-devel-platform,
 +
# multi-target-platform,
 +
# free,
 +
# open
 +
# game-engine
 +
# mit scala als main-language
 +
 
 +
 
 +
* hier ein paar listen zum durchgehen:
 +
* http://www.textureszone.com/tutorials/4-applications-reviews/68-19-free-3d-game-engines-to-create-your-own-3d-games-.html
 +
* http://www.worldofleveldesign.com/categories/level_design_tutorials/recommended-game-engines.php
 +
* http://en.wikipedia.org/wiki/List_of_game_engines
 +
* http://www.moddb.com/engines
 +
 
 +
 
  
 
=== unity 3d game engine ===
 
=== unity 3d game engine ===
pro: featurereiche game engine mit vielen target-plattformern (u.a. auch die ouya)
+
* pro: featurereiche game engine mit vielen target-plattformern (u.a. auch die ouya); non-commercial-option (siehe freeware games wie z.b. slender oder blackwell asylum, uvm);
con: c#, js und boo unter monodevelop auf windows - andere sprachen/develplattform gibt's nicht
+
* con: c#, js und boo unter monodevelop auf windows - andere sprachen/devel-platform gibt's nicht
  
=== fmod audio engine ===
+
=== jmonkey ===  
sieht gut aus. mal ausprobieren.
+
* pro: erster eindruck: wtf! wow! könnte alle anforderungen erfüllen, denn läuft auf jvm.
 +
http://www.youtube.com/watch?v=Ar1QhVFyZRY
  
 
=== blender (als 3d engine) ===
 
=== blender (als 3d engine) ===
pro: frei und brauchbar
+
* pro: frei und brauchbar
con: ausschliesslich python-scritable;
+
* unser wissensstand: kann schon ganz schön was, aber wie gut geht lod und openworld-terrain damit zu realisieren?
  
 
=== shiva3d engine ===
 
=== shiva3d engine ===
 +
* pro: fett (jedoch noch nicht ausprobiert)
 +
* con: kost kohle, mind. 170 EU
  
 
=== irrlicht engine ===
 
=== irrlicht engine ===
 +
* pro: frei (zlib), wird aktiv entwickelt
 +
* con: screenshots auf der website irgendwie wenig überzeugend
  
 
=== doom3 engine ===
 
=== doom3 engine ===
 +
* pro: frei (GPL)
 +
* con: outdated
  
=== unreal3 engine (?) ===
+
=== udk ===
 +
* pro: non-commercial option
  
 
=== sauerbraten engine ===
 
=== sauerbraten engine ===
 +
* pro: frei
 +
 +
=== chrome engine ===
 +
* pro: ist interessant, denn call of juarez ist (bereits) ein optisch sehr opulenter western egoshooter.
 +
* con: jedoch bekommt man von techland nicht einfach so ne non-commercial version vom chromeed und dem sdk.
 +
 +
=== fmod audio engine ===
 +
* "hört sich" gut an. mal ausprobieren.
 +
 +
 +
== content ==
 +
 +
content:
 +
 +
wir brauchen ein arsenal von 3d models:
 +
 +
* personen m/w im western-look: cowboy, cowgirl, banker, citizens, old-timers, farmers, rich land-owners, whores, undertaker, mexicans, indians, chinese', quacks
 +
* gebäude wie saloon, wohnhäuser (mit porch, aussendach, kellereingang), shops/stores, holzbaracken, scheunen, pferdekoppel/stall, friedhof, cornfields, sherrif's office/jail, kirche, zirkus, doctor, bahnhöfe, minen, wasserstation
 +
* tiere wie pferde, hunde, vögel (aasgeier, kanarienvogel, adler), eidechsen, fliegen, mäuse, büffel, hühner, schweine, flughunde, fledermäuse, schlangen
 +
* transportmittel: kutschen, eisenbahn, pioneer wagons
 +
* lanschaftsdetails wie katkeen, gräser, büsche, tumbleweed, cattle skull, railroad-tracks, wagon-wheels, haystacks, fireplace (schwenker), obligatorisches windrad (water pumping windmill), fässer, kisten, pferdetränken, wasserrohre, särge, wege aus brettern
 +
* misc.: stühle, laternen, betten, kommoden, spiegel, schränke, kisten mit schloss, waffen, muni
 +
 +
 +
== wild-west history ==
 +
 +
* http://en.wikipedia.org/wiki/Timeline_of_the_American_Old_West
 +
* http://www.infoplease.com/timelines/slavery.html
 +
* gegen ende der wild-west ära gab's auch autos. (http://www.fordification.com/timeline.htm) ...Vielleicht ein einzelnes, Verbreitung fanden die erst so in den 1890ern und da liest man auf der Wikiseite zum Wild West nur noch, dass irgendwer natürlichen Todes gestorben ist, der früher im Wilden Westen mal jemand war.
 +
* "Chinese and Japanese who came to Montana in the late 19th and early 20th centuries" (http://mansfieldfdn.org/publications-and-outreach-2/publications/from-the-far-east-to-the-old-west-chinese-and-japanese-settlers-in-montana/)
 +
 +
 +
== big picture of implementation: aufbau genereller, tragender strukturen und interaktionen dazwischen ==
 +
 +
=== world ===
 +
 +
die welt soll aus einem riesen areal bestehen (einer landscape) welches eine quadratisch rechteckige form hat und in das alle räumliche geometrie (incl. audio-nodes) platziert ist.
 +
die welt besteht nicht aus einzelnen levels / geometry-szenen.
 +
es soll so sein, dass der spieler sich nahtlos zwischen aussen und innenräumen bewegen kann.
 +
das erfordert - zusätzlich zu culling, geometry batching und lod - ein gutes mem-mgmnt-system zum laden/entladen von "krempel", abhängig vom pov.
 +
idealerweise fallem dem spieler diese vorgänge nicht auf.
 +
es gibt entweder eine begrenzung des areals - z.b. durch unüberwindbare bergketten - oder die welt ist eine torusförmige, d.h. läuft der spieler quasi rechts aus dem bild, kommt er links wieder herein. diese entscheidung steht noch aus.
 +
 +
Alternativ könnte man die Welt auch prozedural generieren.
 +
 +
 +
=== scene-graph ("SG") ===
 +
 +
zunächst gibt es einen SG, mit der die engine ihren kram verwaltet.
 +
models werden aus einem 3d-modeller (z.b. blender) exportiert incl. all ihrer assets (models, textures, materials, shaders, sounds, etc.).
 +
irgendwo - entweder im 3d-modeller selbst, oder in einem tool der engine - wird die komplette welt grafisch zusammengesetzt: landscape, npcs, häuser, innenräume, spatial audio-nodes, etc.
 +
 +
 +
=== in-game-objects graph ("IGOG") ===
 +
 +
parallel zum SG wird ein IGOG aufgebaut.
 +
 +
wir unterscheiden zwei kategorisch unterschiedliche typen von nodes und definieren sie namentlich als "statisch" und "dynamisch".
 +
ein node repräsentiert also entweder ein statisches objekt oder ein dynamisches objekt.
 +
 +
die unterscheidung besteht darin, dass statische objekte lediglich für den SG relevant sind (z.b. skydome oder ein gebäude), wogegen dynamische objekte für das gameplay relevant sind.
 +
letztere tragen daher eine auswahl aus verschiedensten attributen, die zusammengenommen einen zustand repräsentieren.
 +
 +
 +
=== wer arbeitet auf dem IGOG? ===
 +
 +
=== das mem-mgmnt ===
 +
 +
es sorgt dafür, dass sich lediglich in einer bestimmten (performanceabhängig festzulegenden, relativ zum pov kugelförmigen) umgebung die daten SG-relevanter nodes (die aus aus einem storage kommen, zb hdd/ssd) im ram befinden.
 +
culling, geobatching, lod - entweder selbst implementiert oder hoffentlich bereits brauchbar in jme vorhanden (todo: rausfinden) - sorgt für den transport der viewport-relevanten daten in den ram der graka.
 +
 +
=== das gameplay ===
 +
 +
abstrakt gesehen besteht das spiel aus teils vorgegebenen, teils bedingten manipulationen gameplay-relevanter attribute der IGOG nodes.
 +
bedingungen sind z.b. räumlicher abstand, user-interaktion (knöpfchen drücken), zeit (in-game oder echt), collision-detection.
 +
eine aufgabe ist es, anhand der anforderungen an die spielmechanik - welche die gamedesignerin wiederum anhand der vorgabe des flusses/des ablaufs der story quasi generiert - die gameplay-attribute so zu gruppieren, gewissermassen auf fach-ebene zu bündeln (fachebene meint hier also die storyebene) und mit wetebereichen und konkreten startwerten zu besetzen, dass sie schlussendlich programmiertechnisch ideal handhabbar werden.
 +
 +
=== interaktion zwischen IGOG und SG ===
 +
 +
hier wird demnach die interaktion zwischen SG und IGOG deutlich. eine weitere aufgabe (nämlich die der coder) ist es, auch sie ideal zu systematisieren.
 +
 +
anmerkung: attribute der IGOG-nodes können durchaus für beide aspekte - sowohl mem-mgmnt als auch gameplay - relavant sein, z.b. x,y,z koordinaten.
 +
 +
eine weitere aufgabe ist folgende frage zu überdenken: nach welcher methode (u.u. mit welchen tools) wird der IGOG parallel zum SG erstellt und gepflegt?

Aktuelle Version vom 27. Juni 2013, 11:29 Uhr

Yet Another Computergame

stand: 7.5.13 autor: rob

hier gehts darum, ein indie computerspiel zu entwickeln.

an dieser stelle sind die angaben erstmal sehr krude und zu unkonkret für ein go oder gar einen projektplan. es geht jetzt erst mal darum, eine realisierbare idee zu entwickeln und sich für eine technik/toolchain (engine(s), sprache(n), tools, etc.) zu entscheiden.


idee

  • status quo:
  • story-basierter adventure/rpg/shooter mix
  • open world
  • 3d ego-perspektive
  • (spaghetti-)western setting
  • story sollte seriös, tiefgehend und niveauvoll sein, mit (evtl. augenzwinkerndem, subtilen, surrealem und/oder morbidem) humor
  • spieler kann/muss mehrere charaktere spielen, u.a. auch einen hund
  • wenn möglich, auch auf mobilen devices spielbar, entweder als stand-alone oder konezptionell ins gameplay eingebunden (z.b. mit dem handy kann man etwas tun, was man an der konsole oder am pc nicht tun kann und es ist auch noch ortsabhängig, z.b. gegenstände ablegen/aufnehmen)


news

  • wir gehen so vor, dass wir jetzt erstmal ein paar engines "evaluieren". (recherchieren und anschauen, wie die so funktionieren und damit etwas rumspielen, gegen die weiter unten bei "engine(s)" beschriebene ideal-vorstellung prüfen)
  • jmonkeyengine in kombi mit blender ist gerade hot
  • koordination zunächst jeweis an den hackMI's.
  • parallel fangen wir langsam mit dem storywriting an.
  • hot ist auch gerade die frage, wollen wir kanonisch beim wildwest-setting bleiben oder bauen wir ausserweltliche elemente ein (z.b. retrofuturismus in form von steampunk)? das beträfe gleichermassen story, ästhetik und content.


todo's

  • idee/konzept entwickeln
  • arbeitstitel finden (das kind braucht ja irgendwann auch mal einen namen, ne)
  • technik evaluieren (genauer: wir fangen mal mit jmonkeyengine an und sehen, wie weit wir damit kommen)
  • story entwickeln
  • gamedesign entwickeln
  • grafik erstellen
  • musik machen


rollen im projekt

  • projektmanagement (vision, koordination, antrieb)
  • gamedesign (gameplay, rätsel)
  • storywriting (setting, plot, charakter, dialog)
  • voice-actors
  • visual-art (2d/3d, animation)
  • audio-art
  • testing
  • coding

zusätzliche Infos

http://de.slideshare.net/josezagal1/game-design-patterns-workshop-fdg2012-opening-remarks

angepeilte ästhetik

optisch

  • das feeling soll open-world widerpsiegeln, also: weitläufig, offen, überwiegend karge wüstenlandschaft, detaillierte kleine dörfchen und städchen, aber auch wald-szenerie und blühende und spektakuläre naturparks
  • tendenz in richtung "Call of Juarez: Bound in Blood"
  • landschaftlich in richtung albert bierstadt (ein deutscher, nach usa emigrierter maler von romantisch überhöhten landschaftsmotiven)
  • um sich von beidem einen optischen eindruck zu verschaffen, bitte eine internet-bildersuche bemühen

akustisch

  • wüstenmässig, karg, leer
  • windgeräusche, hawk-cries, slide-gitarre, leichte synth-pads, etc.
  • selbstgemachte musik, darf ruhig etwas rohen, semi-amateurhaften charme haben
  • musikstücke sollen der dramaturgischen situation angepasst sein
  • sprache des spiels deutsch oder englisch? (sollen voice-actors englisch sprechen, egal mit welchem akzent; oder deutsch, u.u. sogar absichtlich mit deutschem akzent)


technik-evaluation

  • aktuelle tendenz: jmonkey
  • vorherige tendenz: blender
  • vorherige tendenz: mit hilfe von unity3d für die ouya entwickeln

wir haben folgende optionen:

  • entweder eine game-engine benutzen
  • oder ein arsenal an engines/libs zusammenschnüren (grafik, audio, 2d-gui, speedtree etc.)
  • oder modding


engine(s)

wir müssen sicherlich kompromisse eingehen, aber ideal und traumhaft wäre eine

  1. feature-mässig aktuelle,
  2. production-grade,
  3. linux-devel-platform,
  4. multi-target-platform,
  5. free,
  6. open
  7. game-engine
  8. mit scala als main-language



unity 3d game engine

  • pro: featurereiche game engine mit vielen target-plattformern (u.a. auch die ouya); non-commercial-option (siehe freeware games wie z.b. slender oder blackwell asylum, uvm);
  • con: c#, js und boo unter monodevelop auf windows - andere sprachen/devel-platform gibt's nicht

jmonkey

  • pro: erster eindruck: wtf! wow! könnte alle anforderungen erfüllen, denn läuft auf jvm.

http://www.youtube.com/watch?v=Ar1QhVFyZRY

blender (als 3d engine)

  • pro: frei und brauchbar
  • unser wissensstand: kann schon ganz schön was, aber wie gut geht lod und openworld-terrain damit zu realisieren?

shiva3d engine

  • pro: fett (jedoch noch nicht ausprobiert)
  • con: kost kohle, mind. 170 EU

irrlicht engine

  • pro: frei (zlib), wird aktiv entwickelt
  • con: screenshots auf der website irgendwie wenig überzeugend

doom3 engine

  • pro: frei (GPL)
  • con: outdated

udk

  • pro: non-commercial option

sauerbraten engine

  • pro: frei

chrome engine

  • pro: ist interessant, denn call of juarez ist (bereits) ein optisch sehr opulenter western egoshooter.
  • con: jedoch bekommt man von techland nicht einfach so ne non-commercial version vom chromeed und dem sdk.

fmod audio engine

  • "hört sich" gut an. mal ausprobieren.


content

content:

wir brauchen ein arsenal von 3d models:

  • personen m/w im western-look: cowboy, cowgirl, banker, citizens, old-timers, farmers, rich land-owners, whores, undertaker, mexicans, indians, chinese', quacks
  • gebäude wie saloon, wohnhäuser (mit porch, aussendach, kellereingang), shops/stores, holzbaracken, scheunen, pferdekoppel/stall, friedhof, cornfields, sherrif's office/jail, kirche, zirkus, doctor, bahnhöfe, minen, wasserstation
  • tiere wie pferde, hunde, vögel (aasgeier, kanarienvogel, adler), eidechsen, fliegen, mäuse, büffel, hühner, schweine, flughunde, fledermäuse, schlangen
  • transportmittel: kutschen, eisenbahn, pioneer wagons
  • lanschaftsdetails wie katkeen, gräser, büsche, tumbleweed, cattle skull, railroad-tracks, wagon-wheels, haystacks, fireplace (schwenker), obligatorisches windrad (water pumping windmill), fässer, kisten, pferdetränken, wasserrohre, särge, wege aus brettern
  • misc.: stühle, laternen, betten, kommoden, spiegel, schränke, kisten mit schloss, waffen, muni


wild-west history


big picture of implementation: aufbau genereller, tragender strukturen und interaktionen dazwischen

world

die welt soll aus einem riesen areal bestehen (einer landscape) welches eine quadratisch rechteckige form hat und in das alle räumliche geometrie (incl. audio-nodes) platziert ist. die welt besteht nicht aus einzelnen levels / geometry-szenen. es soll so sein, dass der spieler sich nahtlos zwischen aussen und innenräumen bewegen kann. das erfordert - zusätzlich zu culling, geometry batching und lod - ein gutes mem-mgmnt-system zum laden/entladen von "krempel", abhängig vom pov. idealerweise fallem dem spieler diese vorgänge nicht auf. es gibt entweder eine begrenzung des areals - z.b. durch unüberwindbare bergketten - oder die welt ist eine torusförmige, d.h. läuft der spieler quasi rechts aus dem bild, kommt er links wieder herein. diese entscheidung steht noch aus.

Alternativ könnte man die Welt auch prozedural generieren.


scene-graph ("SG")

zunächst gibt es einen SG, mit der die engine ihren kram verwaltet. models werden aus einem 3d-modeller (z.b. blender) exportiert incl. all ihrer assets (models, textures, materials, shaders, sounds, etc.). irgendwo - entweder im 3d-modeller selbst, oder in einem tool der engine - wird die komplette welt grafisch zusammengesetzt: landscape, npcs, häuser, innenräume, spatial audio-nodes, etc.


in-game-objects graph ("IGOG")

parallel zum SG wird ein IGOG aufgebaut.

wir unterscheiden zwei kategorisch unterschiedliche typen von nodes und definieren sie namentlich als "statisch" und "dynamisch". ein node repräsentiert also entweder ein statisches objekt oder ein dynamisches objekt.

die unterscheidung besteht darin, dass statische objekte lediglich für den SG relevant sind (z.b. skydome oder ein gebäude), wogegen dynamische objekte für das gameplay relevant sind. letztere tragen daher eine auswahl aus verschiedensten attributen, die zusammengenommen einen zustand repräsentieren.


wer arbeitet auf dem IGOG?

das mem-mgmnt

es sorgt dafür, dass sich lediglich in einer bestimmten (performanceabhängig festzulegenden, relativ zum pov kugelförmigen) umgebung die daten SG-relevanter nodes (die aus aus einem storage kommen, zb hdd/ssd) im ram befinden. culling, geobatching, lod - entweder selbst implementiert oder hoffentlich bereits brauchbar in jme vorhanden (todo: rausfinden) - sorgt für den transport der viewport-relevanten daten in den ram der graka.

das gameplay

abstrakt gesehen besteht das spiel aus teils vorgegebenen, teils bedingten manipulationen gameplay-relevanter attribute der IGOG nodes. bedingungen sind z.b. räumlicher abstand, user-interaktion (knöpfchen drücken), zeit (in-game oder echt), collision-detection. eine aufgabe ist es, anhand der anforderungen an die spielmechanik - welche die gamedesignerin wiederum anhand der vorgabe des flusses/des ablaufs der story quasi generiert - die gameplay-attribute so zu gruppieren, gewissermassen auf fach-ebene zu bündeln (fachebene meint hier also die storyebene) und mit wetebereichen und konkreten startwerten zu besetzen, dass sie schlussendlich programmiertechnisch ideal handhabbar werden.

interaktion zwischen IGOG und SG

hier wird demnach die interaktion zwischen SG und IGOG deutlich. eine weitere aufgabe (nämlich die der coder) ist es, auch sie ideal zu systematisieren.

anmerkung: attribute der IGOG-nodes können durchaus für beide aspekte - sowohl mem-mgmnt als auch gameplay - relavant sein, z.b. x,y,z koordinaten.

eine weitere aufgabe ist folgende frage zu überdenken: nach welcher methode (u.u. mit welchen tools) wird der IGOG parallel zum SG erstellt und gepflegt?