Was muss ein Menu-Interface für Games auf einem 16/32-Bit Computer berücksichtigen im besten Fall?
– Joysticks, Keyboard und Maus
Was eine Console?
– GamePads
// vgl. War Heli 1987 – alle Interaktionsmöglichkeiten auch im Game!
Bei dieser Diskussion zum Schweizer Spiel Colonial conquest II (Public Domain) kommt ein Aspekt zum Vorschein, der selbstverständlich in den 80/90er Jahren besonders wichtig war: Artikel in „Heftchen“ zu Games wie PowerPlay. Sie halfen auch Spiele zu verstehen, gerade auch im Bereich der Piraterie – wo wie ein diesem Spiel – die Einleitung fehlte (war ja in der ungekauften Box): Artikel waren die Minimalanleitung für Games (Genre, Story, Gameplay)
Siehe dazu auch die Semiosekaskade von Games >
René, Beat, Larissa, Dave
Was ist eine Veröffentlichung eines Spiels? Welche Arten gibt es? Was kann sie beinhalten? Wie funktioniert sie? Was hat sie für Auswirkungen? Wer ist der Addressat? Gibt es Monetarisierungsmöglichkeiten? Wie reflektieren sie die damalige Gesellschaft und ihre Möglichkeiten? Inwieweit sind die Praktiken der der „Gameszene“ wegweisend gewesen?
| Zeit | Name/Beschrieb | Monetarisierung | Spielmedium | Spielmedium | Ort/Medium | IN CH VORKOMMEN |
|---|---|---|---|---|---|---|
| 1960+ | Source-Code Veröffentlichung Software als SourceCode | Verkauf in Fach-Geschäften per Hand. | Compillierung je nach System | Tapes | Geschäfte/Einzel | |
| 1960+ | Freie Software auf Mainframes | keine bekannt | Mainframes wie PLATO Systems | Nur auf dem Mainframe für Studierende zugänglich | Universität | – |
| 1970+ | Homebrew-Veröffentlichung | „Verkauf“ zu Hause, auf dem Schulhof | Exe | Tapes, Diskette | Siehe GB / Einzelv | |
| 1970+ | Fair-Veröffentlichung | „Verkauf“ an lokalen oder grösseren Fairs | Exe | Tapes, Disketten | Siehe GB / Kleine Gruppen | |
| 1975+ | Retail-Veröffentlichung Games als Cartridges/Disks | Verkauf Retailstores | Exe, Compiliert verkauft | Geschäft,Retail | Linel etc | |
| 1980+ | RadioSendung-Veröffentlichung | Freeware | SourceCode? | Radio | Tessiner Radio | |
| 1980-1992 | Zeitschriften-Listing-Veröffentlichung In Zeitschriften/Computerclubs | Listing Verkauf und Veröffentlichung als Printinhalt | SourceCode bzw. später Codiert | Zeitschrift, Zeitschriftensystem | ||
| 1980+ | School-Veröffentllichungen | Software wird über die Schule veröffentlicht/eingesetzt | Exe | |||
| 1980+ | BBS-Veröffentlichung Uploaden auf BBS meist Freeware/Gitftware/Shareware | Exe | ||||
| 1980+ | Direkte Phoneservices für Game-Download | siehe Gamelab | Exe | Atari VCS | ||
| 1980+ | Games im Internet MUD/Online Games/ (Server-Client) | Internet | Internet | Alle Systeme mit Terminal | Roger Sieber | |
| 1990+ | FTP Veröffentlichungen meist Freeware/Shareware | Exe/SourceCode – Open Source | Internet | Mummentaler Impression89 | ||
| 1993+ | WebOnly-Veröffentlichung ist einfach online als Verweis darauf | Exe | Web | … | ||
| 1993+ | WebPlatforms-Veröffentlichung | MacUpdate | Exe | Web | Impression89 … | |
| 1993+ | Magazine-Addon Diskmagazine Software ist auf Datenträger mit ‚Heftchen‘ Shareware/Freeware | Direkter Verkauf (Bargeld, Checks, Services wie Kagi) | Exe | Magazine CD | Impression89 … | |
| 1996+ | PhoneGame-Veröffentlichung Verkauf über Provider JME | Bitforge | ||||
| 1996+ | Online-Online-Veröffenltichung | JavaApplets/Flash Freeware | Web (VM-Exe) | Web | Impression89 | |
| Platform Steam | Exe | |||||
Die MissingGameMethode ist eine Methode in der zur Erkenntnisgewinnung eine Lücke gesucht wird im System (Intertext) der bestehenden Games (etwa der 90er Jahre) und versucht wird diese Lücke zu erklären&füllen – entweder per Analyse allein oder und – dabei ist die Analyse dann automatisch dabei – in der Kreierung des MissingGame.
Die Frage dahinter ist einfach: Warum gibt es dieses Spiel oder dieses Spiel-Genre nicht? Oder warum ist es so selten? Was hat den Diskurs und/oder die Leute davon abgehalten diese Spiele zu spielen bzw. sie zu kreieren? Die Antwort kann von rein Legal-/Diskurs-/Kulturgründen hin zu Gamekulturgründen bis hin zu Gamemechanikgründen oder Spielmechaniken gehen.
Die Methode legt letztlich den Intertext eines Systems offen und die Reproduktion des Systems oder anders gesagt: es legt die Motivationsmechaniken von Gesellschaften, deren Spielkulturmechaniken und der GameDesignmechaniken bis zum Technologiesystem offen.
Ein MissingGame kann natürlich als gesamtes Missing sein oder nur in einem seiner Teilaspekte wie Grafik, Sound, Spielmechanik.
Das Schwierigste ist erst mal eine Lücke zu finden, da der Diskurs und Systeme ein Faible dafür haben ihr System zu schliessen und es als ’natürlich‘ darzustellen (Normaliisierung). Deswegen sind Lücken schwierig zu finden. Eine der einfachsten Möglichkeiten ist Spiele sich anzuschauen, die es heute gibt, aber davor nicht oder umgekehrt (etwa GameArt). Sich Spiele anzuschauen, die nicht mehr reproduziert werden (keine neuen Versionen oder Abwandlungen mehr entstehen vgl. Pong, Breakout).
Um ein MissingGame zu analysieren muss es natürlich definiert werden. Was ist das Game, was kann es. Es entsteht auch explizit in Abgrenzung zu bestehenden Games. Die Frage ist dabei, was machen gewisse Spiele aus? Worin wäre es entstanden?
Frage an die Entwickler*? Warum wurde sowas nicht entwickelt? Wurde es diskutiert? Was waren die Frontlinien? Argumentationen? (Technologische Machbarkeit und Aufwand inklusive).
GameDesigner* oder GameDev* der alten Tage konnten erst dann anfangen Gamedesign zu betreiben, wenn sie wussten, was überhaupt machbar war und was sie selbst auch implementieren konnten. Und so wurde auch auf dem Amiga in der experimentellen Archäologie eine weitere Gameengine entwickelt. Immer vor dem Hintergrund ein Game zu machen.
Das führte zur CryAEngine-GameEngine zuerst normal mit Sprites. Allerdings ist die Hardware neben Sound und Hardwarescrolling sehr limitiert: nur 8 Sprites.. Darin wurden zwei Spiele programmiert und dann zur extended Version mit Blitter Bobs. Die Entwicklung und das Ausprobiertprojekt ward nun Planet Coward.
Nach langem Kampf mit den Blitter funktionieren auch die „Bobs“ gut. Bobs sind keine eigentlichen Sprites sondern einfach ins Ram-Gerenderte Grafikblöcke, die man* wieder löschen muss. Sprites sehen das Grafikram nie von Nahem. Leider nur kommt man – auch mit einigem an Optimierung – nur auf 8 Hardwarsprites (3 Farben + Transparenz) und weitere 10 16×16 Blitter Bobs (bei dieser Engine). Nicht gerade viel für eine Hardware Release-Date 1985.
Ab 10 Bobs wird es sehr langsam. Die ist vorallem hörbar (Vsync) beim Sound. Bei gegen die 20 ist es dann richtig langsam:
Sind Gamegrafiken/animationen Gebrauchsgrafiken? Zu welcher Grafiksorte gehören sie? Oder anders gefragt – welche Funktion haben sie?
Letztlich sind sie Entertainement-Grafiken und deren Funktionalität, daneben sind sie (Entertainement-)Infografiken schliesslich visualisieren sie die Spielmechanik und ihre Zustände und deren Übergänge. Sie repräsentieren auch verschönert das Management dahinter.
Wenn man einen Schritt weitergeht, dann kann man auch mit Recht behaupten: Es sind Verbrauchsgrafiken und dies nicht nur wegen ihrer Anwendung, ihrer schieren Masse, die ‚verbraucht‘ werden, sondern auch meist in ihrem Inhalt. Da wird viel umgewandelt oder analoger „vernichtet“ im Spiel.
// ToDo: Genauere Kategorisierung (Intertext, Intergrafik, Intergame) und die Nutzung in Games
Die Auflösung – etwa von 320×256 Pixeln beim Amiga – begrenzte auch die Bewegungsmöglichkeiten von Avataren und NPCs (Sprites) in der Geschwindigkeit. Gerade bei niedrigen Geschwindigkeiten scheint es eine Grenze zu geben der Darstellung. Ab dieser Grenze ’sieht‘ es wahrnehmungstechnisch nicht mehr nach stufenloser Bewegung aus, sondern nach ‚Sprung‘ wie im folgenden Prototypen. Hier ist ein möglichst langsames Fahrzeug gesucht worden. 25 Frames pro Sekunden erzeugen ja bekanntlich im Dunklen Animationsrezeption. In der folgenden Bewegung ist das Objekt zwar animiert, aber die Bewegung ist nicht mehr flüssig.
Die Komplexität eines Spiels kann man vereinfacht/grob an der Anzahl der Ifs im Source-Code beurteilen.
Wenn man* Spiele spielt, akzeptiert man* meist auch jede Art von visuellen Regeln (erweiterte Spielmechanik). Denn: Es ist Teil des visuellen MagicCircles und des symbolischen Handelns. Interessanterweise bemerkt man oft zuerst gar nicht, was so seltsam ist. Man akzeptiert es einfach gerade bei 8bit/16Bit Spielen (Argumentation: war halt damals nicht besser möglich, ja aber …) und dennoch da gibt es oft ein – „irgendwas stimmt in diesem Darstellungssystem nicht“ – „Irgendwelche Regeln fallen aus dem ‚Systemrahmen‘. Das heisst, es ist gewöhnungsbedürftig, gerade weil es keine vereinheitlichte Perspektive gibt und vieles eher lokal/temporär oder zumindest symbolisch gehandhabt wird.
Selbstverständlich gibt es auch „klare“ Fälle: Etwa Seitenansicht und Jump&Run oder Seitenansicht und ShootEmUps oder TopDown-ShootEmUps.
Wir bemerken oft die Probleme schon gar nicht mehr, so sind wir uns gewöhnt Spiele (bzw. sozialisiert) zu akzeptieren. Hier im Fall von PacMan. Es ist eine Top Down Ansicht – das Labyrinth und die Interaktion darin (man* geht in 4 Richtungen) – aber !!!! die Geister/Avatar sind eigentlich eine Front-Ansicht! Oder liegen sie flach auf dem Boden? oder sind es „ganz einfach“ Billboard-Sprites, die sich zur Kamera hindrehen oder ist es eine Comic-Darstellung, wo alles möglich und gemixed wird? Vermutlich ist alles zusammen möglich.
