Kurzbeschreibung

Hierbei handelt es sich um einen Action-"Soulslike" in Third Person. Man spielt einen humanoiden Character. Der Spieler nutzt die Waffen an seinem linken und rechten Arm um verschiedene Arten von Gegnern auszuschalten. Jedoch werden die Arme das Spielcharacters mit jedem Angriff schwächer und müssen sich erst wieder erholen. Oder überhitzen in bestimmten Fällen und werden dadurch für eine Zeit unbrauchbar.

Status
subtle true colour Grey title Action

Status
subtle true colour Grey title SOULSLIKE

Status
subtle true colour Grey title MYSTERY

Motivationsnarration

Du wachst auf in einer verlassenen Krankenstation. Neben dir scheinen noch andere Patienten dort zu sein. Sie sind aber nicht bei Bewusstsein. Du bist alleine. Dein Körper, insbesondere deine Arme, scheinen modifiziert zu sein und ermöglichen es dir Waffen auszurüsten. Auf deiner Suche nach einem Weg nach draußen stellt sich heraus, dass die Krankenstation ein versteckter Raum ist. Außerhalb davon scheint es weiter nach oben zu gehen. Hier und da finden sich zurückgelassene Nachrichten von Kameraden. Es scheint so, als dass vor wenigen Monaten eine Evakuation stattgefunden hat und man versucht sobald wie möglich für dich zurückzukommen. Es braucht nicht lange, um den Grund der Evakuation herauszufinden. Nicht weiter fern lauern zwielichtige Gestalten, die dir nichts Gutes wollen. Du hast keine Erinnerungen daran, was mit dir passiert ist und wer diese Gestalten sind. Du willst erstmal nur raus.

Ideenfindung

Inspiration

Beim ersten Brainstorming kamen uns Spiele in den Kopf wie "Dark Souls", "Sekiro", "Elden Ring", oder "Horizon Zero Dawn" und "Nier: Automata", oder sogar sowas wie "Howl's Moving Castle".

Es sollte eine Art verlorene Welt sein, evtl. eine schwebende, überwucherte Insel, aber doch sehr modern im Cyberpunk Stil.

Außerdem sollte das Spiel in Third Person sein, man soll durch die Welt laufen, viel Action erleben und zwischendurch herausfinden können, was denn überhaupt passiert ist. Warum wird der Spieler von Allem angegriffen, obwohl es so aussieht, als wäre der Ort mal friedlich bewohnt? 

Auch von Musik haben wir uns inspirieren lassen. darunter sowas wie die Soundtracks von "Made in Abyss" oder "Death Stranding". Auch die vorher genannten Spiele galten für uns als Inspiration. Man sollte das Gefühlt haben, dass man dort so gut wie alleine ist. Es sollte für den Spieler mysteriös sein, unwissend wer oder wo er ist und was passiert ist. Dabei kam noch sowas wie "Dead Space" in den Kopf.

Ideenentwicklung

Aus unserer Inspiration hat sich einiges entwickelt. Der Spieler sollte aus Anfangs aus Relikten bestehen, humanoid mit der Möglichkeit, spezifische Relikte als Waffen auszurüsten. Bei dieser Idee sind wir teilweise geblieben, indem der Spieler einen Hammer- und einen Speer-arm hat, die in Zukunft auch weiter ausbaubar, zerstörbar oder ersetzbar sind.

Die Idee der Relikte brachte uns zu der Idee, den Spieler in einem Sarg-ähnlichen Raum aufwachen zu lassen, als wäre er selbst ein Relikt, ein Wächter, der diesen Ort beschützt und nur aufwacht, wenn nötig. Der Spieler sollte aufwachen, nach draußen wandern, und sehen. dass er tatsächlich benötigt wird, da das Zuhause von Gegnern angegriffen wurde.

Das Konzept für den Spielercharakter hat sich zwischendurch mehrfach verändert, von Cyborg zu humanoidem Schleimwesen, dass sich mit Relikten ausrüsten kann, wieder zurück zu einem Cyborg, was am Ende auch größtenteils so blieb.

Der Charakter wacht stattdessen in einer versteckten Forschungsstation auf, es wird etwas getriggert, wodurch er aus seinem Koma erwacht, und sieht, dass er der Einzige ist, der bis zur Evakuierung genug fertiggestellt wurde, um überhaupt aufwachen zu können.

Die Welt in dem der Spieler erwacht wurde von Gegnern angegriffen, weil sie Informationen zu weit entwickelter und futuristischer Forschung bekommen haben, und diese für sich stehlen wollen.

Für den Design dieser Ideen wurden Referenzen in dem Programm "PureRef" gesammelt und dem Team zur Verfügung gestellt.

Gameplay-Entwicklung:

Während der Ausarbeitung der Kampfmechaniken waren mehrere mühsame Iterationen von verschiedenen Ansätzen notwendig. Wir behielten, dass was uns überzeugte.

• Angefangen damit so schnell, wie möglich etwas auf die Beine zu stellen, was ThirdPerson-Nahkampf andeutet.
• Die Idee testen: "Was ist, wenn der Spieler seinen Arm durch das Angreifen zerstört und dieser sich langsam erholt?" "Was ist, wenn der Arm durch blocken zerstört wird?"
• "Was ist, wenn man geladene Angriffe hat und erst dann der Arm zerstört wird?"
• "Was ist, wenn der Spieler seine Arme manuelle Reparieren muss und sich dafür die Energie mit allen anderen kaputten Armen teilt?"
• Der Spieler sollte noch rechtzeitig seine Angriffsrichtung ändern dürfen.
• Der Spieler sollte seine Angriffe durch ein Ausweichen abbrechen dürfen.
• "Wir brauchen das Springen nicht. Das scheint gerade ein unnötiger Ballast mit seinen eigenen Problemen zu sein."
• Jedes mal wenn der Spieler angreift, sollte dieser dabei automatisch auch ein Stück nach vorne gehen.
• "Was ist, wenn der Spieler einen normalen und einen schweren Angriff hat?"
• "Das die Arme ständig kaputt gehen zerstört den 'Flow'. Was ist, wenn normale Angriffe ihn nicht kaputt machen, sondern nur schwere?"
• aktuellen Stand:
  • "Was ist, wenn der normale Angriffe Energie kostet und jeder nachfolgende Angriff immer schwächer wird, wenn man sich keine Zeit zur Erholung nimmt?"

Kernmechaniken

Angriffsmechanik

Normaler Angriff

• Die normalen Angriffe kosten ein Teil der Energie.
• Die Energie beginnt sich nach einer kurzen Zeit wieder aufzufüllen, wenn gerade keine Angriffe ausgeführt werden.
  
• Der linke und rechte Arm haben jeweils ihren eigenen Energiebalken.
• Jeder Arm macht bei 0% Energy noch 10% des Maximalschadens
• Linker Arm:
  
  • Angriff: frontaler stich (schmale Hitbox)
  • Geschwindigkeit: schnell
  • Schaden: klein-moderat
    
  • Energieverbrauch pro Angriff: ca. 20% von 100%
    
• Rechter Arm:
  
  • Angriff: horizontaler Hammerschlag (breite Hitbox)
  • Geschwindigkeit: langsam
  • Schaden: hoch
    
  • Energieverbrauch pro Angriff: ca. 50% von 100%
    

Schwerer Angriff

• Der schwere Angriff bringt den jeweiligen Arm in einen überhitzten Zustand.
  • Ist der Arm überhitzt, so sinkt die Energieanzeige auf 0% und der Arm kann erstmal nicht mehr genutzt werden.
  • Die Energie muss sich erst vollständig aufladen, damit der Arm wieder nutzbar ist.
• Im Austausch richtet der Arm einmalig den maximal möglichen Schaden an, unabhängig davon, wie niedrig die Energieleiste war.
• linker schwerer Angriff:
  
  • Ein sturm nach vorne mit der Waffe an der Spitze
• rechter schwerer Angriff:
  
  • Ausholen und einen AOE-schmettern nach unten

Ausweichen

• schneller Ausweichsprung in gewünschter Richtung
• Ausweichen verbraucht Stamina
• erlaubt es einen Angriff zu beginn noch abzubrechen

Gameplay

Gegner

• 3 Nahkampftypen der selben Sorte
• Sie sind unterschiedlich groß, schnell, stark und haben unterschiedlich viele Lebenspunkte
• Sollen den Spieler dazu bringen verschiedene Arme zu verwenden

zerstörbare Boxen

• Spieler soll von beginn an die Möglichkeiten haben Sachen kaputt zu machen
• eine Möglichkeit seine Angriffe zu testen
• lassen sich wunderbar dazu nutzen um Wege zu und den Spieler dazu zu zwingen seine Angriffe auszuführen
• Die Boxen sind in verschiedene Formen vorhanden um nicht zu eintönig zu wirken.

Interagierbare Objekte

• Türen zu denen man den Schlüssel finden muss
• Ein Turret, dass vom Spieler an und ausgeschaltet werden kann.
  
  • Es greift jeden an, auch den Spieler

Asset-Liste

Visual Assets

• ResearchMegaPack
  • Glücklicherweise gab es während unserer Arbeitszeit diese Assets umsonst beim Unreal Marketplace. Es ist perfekt um eine moderne Untersuchungsumgebung darzustellen und daher ein sehr guter Fund für dieses Projekt.
• Bistrot
  • Da der Anfang des Spiels eher in der wissenschaftlichen Abteilung unserer Welt spielt, sind Bilder, Gläser u.A. sehr nützlich. Dadurch kommt etwas leben in die Map und trägt dazu bei, dass die Welt für Eindringlinge nicht sofort so aussieht, als würden da futuristische Forschung begangen werden.
• BigOffice
  • Auch das Bistrot-Pack trägt gut dazu bei, die Forschung der Bewohner diesen Ortes zu verschleiern. Ohne den richtigen Zugang kommt man nicht sofort an die Dokumente in den Computern, um etwas über die Forschung herauszufinden. Auf dem ersten Blick sieht alles aus wie ein langweiliges Büro
• LPGenericPropSet(s)
  • Free Assets, die wie der Name schon sagt, ziemlich generisch sind. Hier gibt's sowas wie Bücherregale, Boxen, Gläser etc., womit man die Map etwas mehr dekorieren kann. Die meisten Assets wurden ersetzt, als bessere im Angebot gefunden wurden.
• MS_LushPlants
  • Schöne Pflanzen, sowohl grün und lebendig. als auch ausgetrocknet und traurig. Vor allem das zweite zeigt in der ersten Etage der Map, dass es dunkel und verlassen ist, da niemand mehr da war, um sich um die Pflanzen zu kümmern.
• Fertig geriggter Charakter von Unreal Engine - um sich Zeit zu ersparen und schnell, dass Third-Person-Spiel auf die Beine zu stellen
• Gegner - Spinnen aus bereits fertigen Assets - Es sollten zügig Gegner ins Spiel, die nicht erst noch allerlei Animationen brauchen
  

Animationen

• Spielcharakter
  • Bewegung/Locomotion - bereits durch Unreal bereitgestellt. Der Fokus konnte mehr auf die Kampfanimation gelegt werden.
    
  • Hitreaction, Tod - Mixamo - schnell Feedback schaffen
    
  • passende Animationen zu den Kampfmechaniken mussten selbst erstellt und iteriert werden
    
    • 2x Ausweichen
    • 2x eigene linker Angriff (normal und schwer)
      
    • 2x eigene rechter Angriff
• Gegner - bereits fertige Animationen - dem Spiel so schnell wie es nur geht lebhaftere Gegner hinzufügen
  • Bewegung
  • Angriff
  • Hitreaktion & Tod

Sound Assets

• Spielercharakter-Sounds
  • fertige Sounds aus verschiedenen Soundbibliotheken oder selbst mit dem Mund improvisierte Sounds - Es war wichtig jede Animation dadurch Lebhafter zu machen.

• Gegner-Sounds
  
  • fertige Sounds - Auch hier wichtig, die Gegneranimationen zügig lebhafter wirken zu lassen.
• Ambience - am Level-Design und Gegenständen im Level orientiert passende Sound-Effekte aus Bibliotheken heraussuchen

  • Papierknistern

  • abbröckelnde Steine

  • Luftschacht

  • Computergeräusche

  • knarzender Boden

  • blubberndes Wasser

  • Room-Tone/schimmerndes konstantes Hintergrundrauschen

  • flackernde Lichter
    

• Interagierbare Objekte
  • Türen
  • Turret
    • An/Aus
    • Schuss, Treffer

Special Effects

• Spieler VFX - Playerfeedback und der Charakter wirkt, als wär dieser Teil von der Welt
  
  • Staub aufwirbeln beim Bewegen
  • Kurvenverlauf/Trail bei angriffen
  • Effekte bei Spezialangriffen
  • Blut-Indikator, wenn man getroffen wurde
  • Gegner VFX
    • Blut-Indikator, wenn sie getroffen wurden oder sterben
• Spinnenweben
  • Untermalen, dass Spinnen wohl schon etwas länger hier sind
• flackernde Lichter
  
  • Untermalung von "Es wurde sich schon eine Weile um nichts gekümmert." und Angespanntheit

Unused Assets

Player Model (unfinished prototype)

Im ersten Schritt wurden Silhouetten gezeichnet, die im Team besprochen wurden. Daraufhin ist eine klarere Idee für das Player-Model entstanden, welches dann skizziert wurde und mit Blender in 3D modelliert wird

NPC, Enemy and friendly Info-Bot

Da das Spiel futuristisch sein sollte, wurde mit viel LED und neon-Licht gedacht, sowie viel mit Robotern, da diese in der Zukunft viel Arbeit übernehmen sollten. Freundliche Roboter sind mit blauen Lichtern gekennzeichnet. Gegner wie man es kennt mit Rot.

Level Design

Bei der ersten Iteration der Map hatten wir uns einen Dungeon vorgestellt, wo der Spieler Gegner bekämpft und Rätsel löst. Es sollte erkennbar als Untergrund Burg/Dungeon sein, aber dennoch futuristisch mit LED Lichtern und anderen futuristischen Objekten. 

Hier sollte der Spieler als eine Art Wächter in einem Altar aufwachen, da das Zuhause angegriffen wurde und er benötigt wird.

• Hier ist die initiale Level-Design Skizze für das jetzige Design. Während der Modellierung in Unreal Engine wurde es noch etwas abgeändert, ist aber hauptsächlich gleich geblieben.
• Das untere Level ist eine geheime Forschungsstation, daher im Keller und nur mit Schlüsseln zugänglich

• Das zweite Level wurde erweitert, um mehr Raum für den Kampf gegen Gegner zu haben. Hier werden größere Räume und höhere Decken genutzt. 
• Ein weiterer, jedoch offenerer Teil der Forschungsstation, verkleidet als Empfangsstation und Bürofläche

• Im weiteren Verlauf des Projekts, wurden Kleinigkeiten im Level hinzugefügt, wie z.B. Spinnenweben, da die Gegner Spinnen waren. Es sollte die Gegner lebhafter erscheinen lassen.

Auswertung Test-Sessions

Google Formular Auswertung

Neben Live-Kommentaren haben wir unsere Tester auch noch ein Google-Formular ausfüllen lassen.

*freie Antworten

Anmerkungen und Wünsche der Befragten

"Gameplay war nice. (Dark Souls), aber bei der Lock-On Funktion konnte man nicht zwischen Gegnern wechseln."

"Es fehlt an Sounds, wenn man etwas aufhebt."

"Alles in allem gut. Das Kampfsystem war intuitiv. Die verschiedenen Schadenszahlen waren etwas verwirrend, bis ich den "Attack"-Status gesehen habe und wie er mit jeder Attacke niedriger wird. Die Gegner waren einfach, weil ich mich mit solchen Spielen auskenne. Wäre cool, wenn die Gegner von Weitem angreifen könnten. Nur war die Atmosphäre nicht perfekt, es war zu hell und es gab nicht genug Musik/Ambiente."

"Das Dashen mit dem Turret einbinden. Ich hatte keinen Grund zu dashen."

"Ich habe nicht gewusst, dass man die gelben Blöcke zerstören kann."

"Level-Steaming einbinden"

Live-Testing Beobachtungen

• Die Räume am Anfang haben keine gameplaytechnische Bedeutung, was das erkunden unbedeutend machte.
  
  • Der Spieler sollte für die Erkundung belohnt werden.
• Das man in Räumen Sachen kaputt machen kann kam gut an um das Kämpfen schonmal anzutesten, gut dass man damit schon das Kämpfen testen kann
• "Ich habe den Fahrstuhlschlüssel kaum wahrgenommen"
• "Das Turret hat irgendwie keine Gameplayrelevanz."
• "Mit dem Controller lässt es sich viel besser und intuitiver spielen, als mit Tastatur und Maus."
• "Beim schweren Angriff habe ich nicht gemerkt, dass es ein AOE Angriff ist."
• "Gut, dass die Gegner etwas langsam beim Angreifen sind, auch wenn sie sehr schnell laufen."
• "Kampfsystem ist trocken, zu wenig Kombomöglichkeiten"
• "Die Kombos sind nice!"
• "Beim Lock-On sollte man zwischen Gegnern wechseln können."
• "Die Regenerationsgeschwindigkeit der Arme ist gut."
• "Das Spiel erinnert positiverweise an Hack-and-Slash und das Managen von Gegnern."
• "Spinnen passen glaube ich nicht zum Konzept. Aber sind sicher nur Platzhalter."
• "Sounds beim Aufheben von Schlüsseln wäre gut."
• "Der Hammer ist zu langsam, lieber nur mit Speerangriff."
• "Die Kamera ist etwas buggy."
• "Ist der Character eine Frau? Wo sind die Jiggly Effekte?"
• "Pizza!"
• KI wurde ausgetrickst - so konnten Gegner viel zu einfach erledigt werden.
  • Der Spieler sollte in einer Arena "eingesperrt" sein, damit dieser nicht aus dem geschehen rennen kann.
• "Gegner sind mir zu simpel."

Keine Sensibilisierung für Prototypen

Uns war irgendwo auch bewusst, dass solche Kommentare kommen werden:

• "Wo ist die Story?"
• "Warum sieht es so hässlich aus?"
• "Das soll ein Schlüssel sein?"

Die Tester sind fertige und gepolishte Spiele von erfahreneren Entwicklern mit einem Budget gewöhnt. An diesen wurde man auch bewusst/unbewusst gemessen und bewertet.

Wichtige Erkenntnis

Damit sowas, wie ein UI - Hilftext überhaupt gelesen wird, sollte dieser so knapp wie möglich und schön zu lesen sein.

• "Warum machst du eigentlich nicht XY? Oben links ist eine Hilfstext." "Keine Lust es zu lesen. Es ist mir zu lang."

PERFORMANCE: Frustration und eine Geduldsprobe

• Ein Optionsmenü frühzeitig in der Entwicklung einzubinden, hätte uns erspart miransehen zu müssen, dass unsere Tester mit niedrigen Bildraten spielten.
• Der BUILD für das Testen sollte auch auf schwächeren Geräten getestet werden. Selbst dann, wenn man denkt, dass das wenige was man hat, garantiert laufen müsste.

Zeitmanagement

Lessons Learned

Teamarbeit

Was lief gut:

• In der Gruppe herrschte untereinander eine gelassene und humorvolle Stimmung
• trotz unterschiedlichem Zeitmanagement, konnten wir uns regelmäßig digital zum Meeting treffen
• Gruppenmitglieder waren untereinander offen in der Ideenausgestaltung
• Bei Änderungen in der Projektausgestalltung waren alle an Board

Was lief nicht gut:

• unterschiedliches Zeitmanagement
  • Unterschiedliche Arbeitszeiten der Teammitglieder führte dazu, dass man nicht parallel zusammen am Projekt arbeiten konnten. (Discord)
  • Gemeinsames Arbeiten an einem Ort, war ebenso nicht möglich. Hier spielte es auch eine Rolle, dass wir keine tragbare leistungsstarke Hardware für die Unreal Engine hatten.
  • Man kam nicht so gleichermaßen voran
  • Meeting-Termine waren dadurch schwerer zu finden
• Ein Gruppenmitglied musste mittendrin aussteigen
• Wir hatten am Ende keine gute Pipeline für unseren Workflow, damit die Arbeit einzelner sauber ineinandergreift. 
• Meilensteine blieben oft zu schwamming und man überschätzte sich mit dem einhergehenden Zeitaufwand
• mangelnder Fortschritte führten zu Motivationsdowns
  • Idee fruchtete nicht. Es brauchte mühsame Iterationen
• Die Idee des Spiels blieb viel zu lange schwammig formuliert
  • Dadurch haben wir nicht eine Vorstellung/Vision konsequent verfolgt
  • Es führte zu viel unnötiger Arbeit, was auf die Gemüter ging
  • Gruppenmitglieder hatten untereinander ohne das Wissen des anderen, eine unterschiedliche Vorstellung von der Spielidee/der Thematik
• Videospielentwicklung in einem kleinem Team bedeutete das Gruppenmitglieder mehrere Rollen übernehmen müssen. Dadurch ergaben sich Schwierigkeiten in passender Rollenverteilung, die Zeit und Nerven kostete.
• schlechte Kommunikation - was sollte letzten Endes sein? Sind alle mit dem was entschieden wurde in der Gruppe wirklich zufrieden? Haben wir alle das nahezu selbe Bild vor Augen?
  
• Planningstools, wie Trello wurden nicht zuverlässig gepflegt
• Durch das bisher genannte hat das Enthusiasmus für das Projekt C im Team gelitten.
• Bei gegebenen Anlass wurde nicht untereinander fordernd miteinander kommuniziert und voneinander Ergebnisse eingefordert
  

Projektarbeit

Was lief gut:

• Version-Control Git ließ sich gegen Ende zuverlässig einsetzen
• es ließen sich kostenlose Assets nutzen um Zeit zu sparen
• gelungen Sounds und eigenen Animationen frühzeitig einzubinden um dem Projekt mehr Leben einzuhauchen

Was lief nicht gut:

• Einarbeitung in die Unreal Engine war insgesamt mühsam und mit Frust verbunden
• Viel Lernaufwand für wenig Output
• Videospielentwicklung forderte viele Disziplinen, die Überforderderten
• Das Projekt war entsprechend zu ambitioniert. Gruppenmitglieder waren zu unterschiedlich stark mit Videospielentwicklung vertraut.
• 3D Spieleentwicklung entpuppte sich hier als die falsche Wahl für Anfänger und mit einem Actiongenre zusammen umsomehr. Sollte es ein 3D-Spiel sein, dann wirklich nur ein sehr simples Projekt.

Ausblick [ Nice To Have ]

Ausgepfeilteres Options-Menü

Gameplay:

• Kampfmechaniken: Kombo-Möglichkeiten
  • Abfolgen von...
    • normalen Angriffe für jeden Arm (links, links, links Abschluss) (rechts, rechts Abschluss)
    • schweren Angriffen für jeden Arm
    • normalen Angriffen, wenn beide Arme genutzt werden (links, links, rechts) (rechts, links, rechts)
    • normalen Angriffen mit schweren Angriffen (links, links, schwer rechts) (schwer links, rechts)
  • aufgeladene Angriffe und Angriffe, die durch Timing verstärkt werden
  • Möglichkeiten bieten, den linken und rechten Arm durch einen anderen zu ersetzen und dadurch dem Spieler ein neues Move-Set anzubieten
• Gegner
  • Variationsreicher - fordern für sich oder zusammen mit anderen Gegnervariationen, den Spieler unterschiedlich heraus
  • reagieren passend auf die Angriffs- und Bewegungsmöglichkeiten des Spielers
• Lock-on System muss überarbeitet werden
  • zuverlässig den gewünschten Gegner anvisieren
  • anvisierten Gegner markieren
  • zwischen Gegner wechseln lassen
• Spieler-Progression
  • Kombos und Arme auf natürlichem Wege freischalten
  • Items/Gegenstände finden um sich zu Heilen, Energie wiederherzustellen oder aufzuwerten

Level-Design:

• Konsistentes Thema und überraschend ineinander vernetzt (Aha-Momente a la Dark Souls)
• leitet den Spieler indirekt an seine Fähigkeiten einzusetzen und auszuprobieren
• Räume bringen stets etwas neues ins Spiel
• Bieten einen passenden Anfang und Schluss

geplante Story/Narration durch einbauen von Level-Elementen zur Geltung bringen

• Notizen
• Infomationen Informationen an den Wänden/ GrafittiGraffiti
• Kommentare durch Gegner
• Itembeschreibungen
• Friendly-NPCs (Hilfsroboter, Kameraden)
• Lautsprecherdurchsagen

Atmosphäre zur Geltung bringen

• Mystery, Sci-Fi, nervös machend/schaurige Elemente

Musik, Sound-Effekte und VFX für passenderes und eindeutiges Player-Feedback