Tricky Features: Unterschied zwischen den Versionen

Aus Das Sopra Wiki
← Zum vorherigen Versionsunterschied
VisuellWikitext
Greitschus (Diskussion | Beiträge)
Bürokraten, sopra, sopra17, sopra18, sopradozenten, soprapre17, sopra|sopra, sopra|soprapre17, Administratoren
2.329 Bearbeitungen
Dietsch (Diskussion | Beiträge)
Bürokraten, sopra, sopra17, sopradozenten, soprapre17, Administratoren
2.877 Bearbeitungen
Keine Bearbeitungszusammenfassung
 
(19 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Stub}}
{{Stub}}


Es gibt eine Reihe von Features die sich (auch wenn es teilweise aufs erste nicht unbedingt so erscheinen mag) in der Umsetzung durchaus als etwas knifflig erweisen. Allerdings bedeutet das nicht dass ihr diese Sachen zwangsweise vermeiden sollt!
Die meisten Spiele lassen sich in eine Menge von grundlegenden Systemen wie Grafik, Pathfinding, etc. zerlegen. Jedes dieser Systeme kann unterschiedlich komplex ausgeprägt sein (z.B. [https://en.wikipedia.org/wiki/Dwarf_Fortress Dwarf Fortress] mit sehr einfacher Grafik und sehr komplexen Mechaniken oder [https://en.wikipedia.org/wiki/The_Vanishing_of_Ethan_Carter The Vanishing of Ethan Carter] mit sehr komplexer Grafik aber fast ohne Spielmechanik). Um eine Hilfestellung für die Ausarbeitung der Spielidee zu geben, sind in der folgenden Tabelle gängige Systeme und deren Ausprägung gegen ihre Komplexität (wie schwierig ist das Feature technisch umzusetzen, z.B. effizientes Pathfinding zwischen sich auf Umlaufbahnen bewegenden Planeten unter Berücksichtigung des Treibstoffverbrauchs benötigt einen komplexen Algorithmus) und/oder den damit verbundenen Aufwand (wie viel Arbeit muss man in die reine Umsetzung investieren z.B. für ein 2D Spiel in Isometrie benötigt man Sprites für jedes Objekt in jeder der acht Ausrichtungen für jede Animation was extrem viel Zeit kosten kann) aufgetragen.
<br/>
Je nachdem was für eine Art von Spiel ihr umsetzen wollt und wie ein entsprechendes Feature genau aussehen bzw. implementiert werden soll, kann der Schwierigkeitsgrad extrem variieren.
<br/><br/>
=> Es ist sehr wichtig, dass ihr '''genau''' abklärt inwiefern ihr Features die in folgenden Themenbereichen liegen umsetzen wollt und dass ihr deren Implementierung sowie Integration in das Spiel gut plant.
<br/><br/>
''Im Nachfolgenden handelt es sich lediglich um '''Hinweise''' die bedacht werden sollten, es besteht '''kein Anspruch auf Vollständigkeit'''!''


== Allgemeines ==
{| class="wikitable"
=== Netzwerk ===
|+
Da die Implementierung von Netzwerkfunktionalität für Multiplayer-Unterstützung nicht ganz trivial umzusetzen ist wird sie gern als optionales Feature für die spätere Entwicklung angedacht. Das Problem hierbei ist, dass Netzwerkfunktionalität einen entscheidenden Einfluss auf die gesamte Architektur hat. Wenn Netzwerkfunktionalität geplant ist sollte diese daher von vornherein als festes Feature eingeplant werden. <br/>
! colspan="2" rowspan="2" |Feature
Wenn man sich dafür entscheided Netzwerkfunktionalität zu implementieren, sollte man wissen dass es für das XNA Framework zwei grundlegend verschiedene Möglichkeiten gibt:
! colspan="5" |Komplexität/Aufwand
* Man kann die Netzwerk-Funktionalitäten Nutzen die das XNA-Framework zur Verfügung stellt. Hierzu sollte man folgende [http://blogs.msdn.com/xna/archive/2007/11/16/xna-framework-networking-and-live-requirements.aspx Fakten zu XNA Framework Networking and LIVE Requirements] kennen und findet dann alle weiteren Informationen, sowie auch Tutorials, in den [http://msdn.microsoft.com/en-us/library/bb975801.aspx Networking Seiten zu XNA 3.0 in der MSDN]. Auch der Education Catalog des XNA Creators Club verfügt über eine [http://creators.xna.com/en-US/education/catalog/?contenttype=0&devarea=19&sort=1 Sektion mit Samples zu Networking].
|-
* Wenn man die Einschränkungen der ersten Möglichkeit nicht hinnehmen will und/oder nicht mit ''Xbox LIVE'' bzw. ''Games for Windows® - LIVE'' arbeiten möchte, so kann man mit [[.NET]] eigene Netzwerkfunktionalität programmieren oder versuchen eine .NET Network-Library zu integrieren. Auch wenn man bei dieser Alternative mehr flexibilität erreichen kann ist das definitiv die schwerere Variante. Mögliche Einstiegspunkte in das Thema:
!Niedrig
** Der [http://msdn.microsoft.com/de-de/library/system.net.sockets.aspx System.Net.Sockets - Namespace des .NET Frameworks 3.5]
!
** Die [http://code.google.com/p/lidgren-network/ Lidgren networking library] und ein [http://www.ziggyware.com/readarticle.php?article_id=168 rudimentäres Tutorial zu deren Nutzung in XNA 2.0] (sollte kompatibel zu XNA 3.0 sein)
!Bewältigbar
{{BA|Greitschus|Ziggyware not existing!}}
!
!Hoch
|-
| colspan="2" |Steuerung
|Direkte Steuerung
|
|Indirekte Steuerung
|
|
|-
| rowspan="2" |Grafik
|[https://en.wikipedia.org/wiki/Isometric_video_game_graphics 2D]
|Plan/Seitenansicht
| TopDown
|Animationen, Isometrie
|Isometrie mit Animationen
|Isometrie mit Ebenen
|-
|3D
|
|"Pappaufsteller", z.B. [https://en.wikipedia.org/wiki/Doom_engine DOOM], Isometrie mit Ebenen
|Einfache Animationen
|
|Objektanimationen und Eyecandy
|-
| colspan="2" |KI
| MicroKI (lokale state machine)
|
|[https://en.wikipedia.org/wiki/Decision_tree Decision Trees], Glaubwürdige KI
|
|Experimentelles, z.B. [[HallOfFame#Steam Revolution|Steam Revolution]]
'Regie' führende KI, z.B. [https://www.gamedeveloper.com/design/the-perfect-organism-the-ai-of-alien-isolation Alien Isolation]
|-
| colspan="2" |Multiplayer
|Singleplayer
|Splitscreen
|
|Echtzeit Multiplayer auf perfektem Netzwerk
|Echtzeit Multiplayer auf realistischem Netzwerk
|-
| colspan="2" |Spielmechanik
|Mühle
|
|Klassische Echtzeitstrategie, z.B. Warcraft
|
|Spiele mit komplexem Balancing, z.B. DoTa, League of Legends, Magic: The Gathering
Spiele mit vielen Systemen, die komplexe Abhängigkeiten haben, z.B. Dwarf Fortress, Rim World, Oxygen not Included
|-
| colspan="2" |Pathfinding
|2D ohne dynamisches Pathfinding/Kollisionsvermeidung
|
|
|
|Ressourcenabhäniges Pathfinding zwischen sich bewegenden Objekten, z.B. [[HallOfFame#Solar Explorer|Solar Explorer]]
|-
| colspan="2" |Assets
|Prozedural generierte geometrische Formen<ref>Prozedural generierte Assets können allerdings sehr aufwendig sein, z.B. .kkrieger, Spore, etc. </ref>  (Linien, Vierecke, etc.), z.B. Captain Forever
|
|
|
|Immersive Simulations oder Open-World Games, z.B. Skyrim, Fallout 3, The Witcher 3, etc.
|}


== Level im Freien ==
<references />
=== Weite Sicht ===
''...TBA...''
=== Großes Terrain ===
''...TBA...''
=== Schwindelerregende Höhen ===
''...TBA...''
 
== Level in Räumen/Tunneln/Labyrinthen ==
=== Leveldesign ===
''...TBA...''
=== Kollisionserkennung ===
''...TBA...''

Aktuelle Version vom 19. Oktober 2021, 10:13 Uhr



Die meisten Spiele lassen sich in eine Menge von grundlegenden Systemen wie Grafik, Pathfinding, etc. zerlegen. Jedes dieser Systeme kann unterschiedlich komplex ausgeprägt sein (z.B. Dwarf Fortress mit sehr einfacher Grafik und sehr komplexen Mechaniken oder The Vanishing of Ethan Carter mit sehr komplexer Grafik aber fast ohne Spielmechanik). Um eine Hilfestellung für die Ausarbeitung der Spielidee zu geben, sind in der folgenden Tabelle gängige Systeme und deren Ausprägung gegen ihre Komplexität (wie schwierig ist das Feature technisch umzusetzen, z.B. effizientes Pathfinding zwischen sich auf Umlaufbahnen bewegenden Planeten unter Berücksichtigung des Treibstoffverbrauchs benötigt einen komplexen Algorithmus) und/oder den damit verbundenen Aufwand (wie viel Arbeit muss man in die reine Umsetzung investieren z.B. für ein 2D Spiel in Isometrie benötigt man Sprites für jedes Objekt in jeder der acht Ausrichtungen für jede Animation was extrem viel Zeit kosten kann) aufgetragen.

Feature Komplexität/Aufwand
Niedrig Bewältigbar Hoch
Steuerung Direkte Steuerung Indirekte Steuerung
Grafik 2D Plan/Seitenansicht TopDown Animationen, Isometrie Isometrie mit Animationen Isometrie mit Ebenen
3D "Pappaufsteller", z.B. DOOM, Isometrie mit Ebenen Einfache Animationen Objektanimationen und Eyecandy
KI MicroKI (lokale state machine) Decision Trees, Glaubwürdige KI Experimentelles, z.B. Steam Revolution

'Regie' führende KI, z.B. Alien Isolation

Multiplayer Singleplayer Splitscreen Echtzeit Multiplayer auf perfektem Netzwerk Echtzeit Multiplayer auf realistischem Netzwerk
Spielmechanik Mühle Klassische Echtzeitstrategie, z.B. Warcraft Spiele mit komplexem Balancing, z.B. DoTa, League of Legends, Magic: The Gathering

Spiele mit vielen Systemen, die komplexe Abhängigkeiten haben, z.B. Dwarf Fortress, Rim World, Oxygen not Included

Pathfinding 2D ohne dynamisches Pathfinding/Kollisionsvermeidung Ressourcenabhäniges Pathfinding zwischen sich bewegenden Objekten, z.B. Solar Explorer
Assets Prozedural generierte geometrische Formen[1] (Linien, Vierecke, etc.), z.B. Captain Forever Immersive Simulations oder Open-World Games, z.B. Skyrim, Fallout 3, The Witcher 3, etc.
  1. ↑ Prozedural generierte Assets können allerdings sehr aufwendig sein, z.B. .kkrieger, Spore, etc.
Abgerufen von „https://sopranium.de/index.php?title=Tricky_Features&oldid=10315“