... verschieben geht ja immer noch. [Tante Edit:] ich habe den Thread jetzt erst einmal aus der Coder-Ecke in den Konsolen-Bereich verschoben, weil sich das Thema etwas anders entwickelt hat, als erwartet – es geht doch mehr um eine Retro-Konsolen-Emulation, als um ein API zur leichten Erstellung von Retro-Games (u.a. für moderne Konsolen und Mobile Devices). (Soll aber nicht heißen, dass das nicht auch diskutiert werden darf). Jetzt aber los:
Im Thread "Eigenes Konsolen-Unternehmen hier in Deutschland?" habe ich eine Idee (mehr ist es leider nicht) formuliert, die nichts mit Hardware, sondern mit Software-Entwicklung zu tun hat, weswegen ich sie dort mal ausgliedern möchte. Um den anderen Thread nicht zu zerreißen, wiederhole ich hier meinen Text und die Antworten darauf. Ich weiß nicht, ob die Idee das Rad zum hundertsten mal erfindet oder ob daran etwas unique oder überhaupt gut ist:
------
Ich denke, Hardware ist überhaupt nicht (mehr) das Problem. Hardware, auf der man Spiele zum Laufen bekommt, gibt es wie Sand am Meer in jedem Haushalt und in jeder Hosentasche. Was wäre denn der Vorteil, wenn man weitere Hardware produzieren würde – selbst wenn das in Deutschland oder zumindest Europa geschehen würde? Man würde doch nur noch mehr Elektroschrott (von morgen) erzeugen. Was ist denn an der vorhandenen Hardware verkehrt? Ich glaube, man hat hier das Bauchgefühl, dass die eigenen Wünsche von der Spiele-Industrie ignoriert werden und man sich in dem Angebot an Software-Titeln nicht (mehr) wiederfindet. Zu viel 3D, zu viel online, zu komplex, zu wenig Spielspaß. Habe ich das evtl. richtig analysiert?
Dann sollte die Antwort auf die Frage, bzw. die Lösung des Problems nicht in der Hardware gesucht werden, sondern eher im Bereich Software-Entwicklung. Es gibt ja eine Menge an aktuellen "Retro-Spielen" auf unterschiedlichen Plattformen (ich selbst stelle ja immer mal wieder zusammen was ich für das iPhone so finde), allerdings müssen sich die Entwickler um den Pixel-Look etc. immer selbst kümmern. Was haltet ihr von der Idee, eine standardisierte Retro-"Hardware" zu definieren und diese dann nicht zu bauen, sondern gleich zu emulieren, sodass (Indy- und Hobby-) Spiele-Entwickler eine technologische Basis haben, auf der sie ihre Projekte realisieren können? Man hätte dann ein SDK für Mac/Linux/Windows zur Verfügung und hätte eine ungewöhnliche, virtuelle Zielplattform mit meinetwegen 200 x 200 Pixeln, 64 festen Farben, Rasterroutinen, soundso vielen Sprites und Tonkanälen etc. (und einfach zu nutzenden Möglichkeiten, diese Fähigkeiten anzusprechen) Und für diese virtuelle Hardware stellt man dann Emulatoren für die unterschiedlichsten echten Hardwares (Settop-Boxen, PCs, Smartphones, Konsolen, Tablets, TV-Sticks ...) zur Verfügung. Gut, das wäre jetzt etwas ganz anderes, als dem Threatstarter vorschwebte – aber evtl. löst es genau das Problem, das er gesehen/gefühlt hat.
Das ist ein interessanter Punkt und wäre vlt. einen eigenen Thread wert. Zudem der wahrscheinlich bisher einzige Lösungsansatz in diesem gesamten Thread für die nur mit Unzulänglichkeiten gespickte Idee einer eigenen Konsole.
Ich denke Deine Analyse des ursprünglichen Problems trifft ins Schwarze. Von der Lösung halte ich aber nichts, denn: Der "Retro"-Anteil diverser modener Spiele beschränkt sich offensichtlich auf einen pixeligen Look und 2D-Grafik, d.h. auf Design-Aspekte. Keiner der Programmierer dürfte aber sonderlich erpicht auf echte Limitierungen sein, wie z.B. eine geringe Auflösung, Maximalzahl Farben, Maximalzahl Sprites etc.
Außerdem dürfte moderne Hardware so etwas wie Rasterroutinen weder ermöglichen noch benötigen; und Sprites werden vermutlich auch rein in Software gemacht.
Ergo: Wenn überhaupt, läuft es auf Software-Libraries hinaus. Aber da gibt es sicher schon etwas.
Grade Limitierungen können den Reiz am Programmieren zumindest für den Hobbiisten erhöhen, da sie eine Herausforderung darstellen. Wir machen regelmäßig Programmierwettbewerbe, und der Kernbestandteil ist es diverse Limits vorzugeben, so z.b maximale Dateigrößen für Grafiken oder eine Limitierung auf eine Taste zum Steuern o.ä.
Wir haben auch schon einen vcs2600-Kontest gemacht,hier waren nur 128 Byte für Variablen / Befehle und 4kb für feststehende Inhalte (GfX etc) als "ROM" erlaubt. Auflösung etc wurden auch vorher festgelet. Die Ergebnisse waren sehr lustig und die Teilnehmer waren insgesamt positiv von den Limitierungen angetan.
Im professionellen Sektor sieht das natürlich wieder ganz anders aus.
Genau das hast du auf jeder Demo-Competition in der Demo-Szene... http://www.sillyventure.eu/comp,en
Eine virtuelle Retro Konsole ist dagegen eine interessante Idee. Zumindest verspricht sie viel eher ein Erfolg zu werden.
Vielleicht können ja mal ein paar Coder was dazu sagen – wie findet ihr die Idee von einer virtuellen Retro-Hardware? Gibt es sowas schon? Ist wirklich eine Emulation der richtige Weg oder würde es mehr Sinn machen, eine Engine als API zu entwickeln, die jeder interessierte verwenden und dann für Zielplattformen kompilieren kann? Gibt es einen "Markt" (nicht im Sinne von Finanzen) dafür? Könnt ihr euch vorstellen, dass Coder sowas nutzen würden oder wollen die lieber ihre Retro-Beschränkungen selber wählen? Könnte man da eine kleine Szene zum Leben erwecken, die Demos und Spiele dafür/damit entwickeln und vielleicht an Compos teilnehmen? Vorteil von Spielen für diese virtuelle Hardware wäre ja, dass sie auf vielen Endgeräten laufen würden (sofern es den Emu bzw. die Engine dafür gibt), egal ob Android-Handy, Pandora, PC/Mac, iPad, gehackte Konsole, Ouya... Man könnte die entstehenden Spiele mit einem Label (made for/with Retro-Engine) auszeichnen und die Spezifikationen kommunizieren ...
Aber selbst, wenn man die Idee gut finden sollte – wer hätte Interesse, so eine Engine oder Emulation zu spezifizieren und vor allem zu entwickeln? (denn ich bin ja nur ein kleiner Retro-Designer, kein Programmierer)