Archiv der Kategorie: design

Tiles-based-Design und Pixeln (Erfahrungsbericht – Amiga)

Bild des Block-Editoren der cryAGameEngine. Visuelles zu Planet Coward Version 0.5

Tiles – Nutzung

Tiles werden aus verschiedensten Gründen verwendet. Hier kurz einige davon:
– Tiles sind eine sehr sparsame Datenverwaltung (visuelle Referenzliste)
– Tiles lassen sich sehr gut einbauen ins Gameplay (Wand, Gang)
– Tiles lassen sich platzsparend abspeichern als Felder oder als Ascii-Strings
– Tiles sind einfach implementierbar (bzw. sind Teil des Hardwaresystems oder Fontsystem)
– Tiles lassen sich bei gutem Design gut kombinieren
– Das einzelne Tile ist einfach erstellbar – Veränderungen sind instant in allen Levels. 
– Tiles eigenen sich gut im LevelDesign
– Es lassen sich schnell grosse Welten kreieren (TileWorldEditor)
– Es gibt viel informelles Wissen mit aktivem 20 Jahren Tiledesign
– Aber: Tiles sind auch sehr schnell erkennbar und haben klare Kannten (bei ‚unpassendem Design)

Tiles: Seamless (Kachelbar)

Tiles müssen um ihre Möglichkeit maximal zu nutzen seamless sein – quasi kachelbar. Dies ist eine schwierige Aufgabe – gerade vor dem Hintergrund, dass Tiles immer begrenzt sind in ihrer Anzahl (im obigen Fall 256 Tiles a 16×16). Das heisst der Charakter von Tiles „viereckig zu sein“ muss gebrochen werden mit verschiedensten Techniken.

Weiterlesen

Ausstellung: Erfahrbarmachung von Tilebasierung

Eventuell einen Setzkasten und einen Raster anbieten. Die Leute müssen anschliessend Levels gestalten, die nicht generisch sondern einzigartig aussieht. Wieviele Tiles brauchenn sie dazu. Eventuell absichtlich schlecht verbindbare Tiiles kreieren so, dass selbst welche gezeichnet werden müssen. Eventuell sogar nur freie Felder und eine Beschränkung.

Perfektes Tiledesign im Einsatz:

// Wann erkennt man Objekte als Zusammensetzung und Wiederholung? Ab wann nervt es? Techniken im Gamedesign und der Kunst
// Thema: Nachhaltiges Design – Wiederverwenden von Teilen
// Size-Designing

Demoscene und/vs GameDesign 0.1 [Wird überarbeitet]

BereichDemosceneDemo-&GameDesignGameDesign
Entwickler*
Motivation
SeizeCoding (vorallem am Anfang 8Bit)
Zeigen, was möglich ist
Challenge / Konkurrenz
Community
Community um einen Computer herum (Idenität)
Kontrolle
Freizeitbeschäftigung unter Kollegen
Credits
SeizeCoding
SeizeDesigning
SeizeCoding (vorallem am Anfang 8Bit)
SeizeDesidning (bis heute)
Identitätsstiftend und Challenge gegen andere Platformen (Bsp. Atari ST vs Amiga)

Produktinterne MotivationVisuelle, technische Finesse, Tricks
Challenge „Wie geht das?“, „Könnte ich das auch?“
Echtzeitberechnung
Visuals, StorytellingSpielmechanik (Challenges)
Interaktion
Echt- und NIchtechtzeit
Genutze TechnikenVisuell, AuditivInteraktion, Taktil
Visuelle EffekteMassiv
KollisionenMeist keine ausser vielleicht PhysikdemoKollisionen extrem wichtig für die Spielmechanik
Darstellung wie gemacht Flackereffekte, AufbauMeistens kein Metalayer eher verborgen, seltene Ausnamen
ZufallMeist nicht vorhandenÖfters genutzt
InteraktionMeist nicht vorhandenHochinteraktiv, Inhalt abhängig vom Spieler
OutputsDemos, Megademos, DiskmagsGames
ArchivierungOnline (pouet.net, Demozoo.org etc)
Videos (Linearisierung)
Zines
keine
EventsParties am Wochenende meist
International
Arbeit, Treffen
wenige für Entwickler
heute GDC

// Muss stetig aktualisiert werden
// Abgleich mit Interviews / Interviews nachfragen