Yet Another Comuptergame

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

• 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.

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?