Yet Another Comuptergame: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Rob (Diskussion | Beiträge) 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''' | ||
| − | + | 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 | + | * 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) |
| − | + | * 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''' | ||
| − | + | * 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) | |
| − | mit | ||
== technik-evaluation == | == 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 | ||
| + | # 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/ | + | * 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) === | === blender (als 3d engine) === | ||
| − | pro: frei und brauchbar | + | * 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 === | === 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 | ||
| − | === | + | === 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
- 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
- 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
- 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?