Seite 6 von 11

Re: Eigenes Videoformat

Verfasst: Mo 30. Nov 2015, 12:58
von DOSferatu
zatzen hat geschrieben:DOSferatu, deine Soundengine würde mich mal interessieren (gerne mal hören)...
Ja, ich habe in meinem ISM einen 4-stimmingen "Beispielsong", mit dem ich immer arbeite, um die verschiedenen Effekte zu testen. Es ist ein bekanntes Kinderlied...
Der ganze "Song" geht 1 Minute, wird 6x abgespielt. Erst 1 Stimme, dann 2. dazu, dann 3. dazu, dann 4. dazu. Bis dahin alles nur digitale Klangsynthese.
Die 4. Stimme (das Noise, das ich hier als Percussion einsetze) klingt noch etwas sehr nach 80er Spielkonsole. Es fehlt ja noch der eine Effekt, den ich einbauen will - und zwar das, was ich für einen digitalen Klangfilter halte. Ich nehme an, daß es trotzdem wohl nicht besonders toll klingen wird, weil es ein ganz einfacher Additions-/Subtraktions-/Mittelwert Filter wird.
Danach wird es noch 2x abgespielt, dabei wird die 1. Stimme durch ein Sample (ein Entenquaken) ersetzt.
Das ISM supportet 16 Stimmen, die einzeln entweder mit Wellenformen inkl. Hüllkurve - oder - eben mit einem Sample abgespielt werden können.
ALLES in ISM ist 4-bit, am Ende gemischt zu 8bit - ich nehme an, deshalb klingt es wohl auch so "billig".

Ich habe mal einen Screenshoot gemacht von dem Editor, den ich nach der ISM-Unit benannt habe.
(Ich habe es einfach nicht so mit Namen - meine Tools und Spiele haben immer nur so doofe Namen. Eigentlich nur, damit sie nicht überhaupt keinen Namen haben. Ich habe da selten eine gute Idee.)
Der Editor kann in 7 Modi betrieben werden 80x25, 80x50 (Textmode), sowie 80x33, 80x40, 100x50, 128x64 und 160x83 (Grafikmode VESA, Zeichen sind 8x12 Pixel).
Die Fensteranordnung kann in 1, 2 oder 3 Reihen erfolgen, außerdem kann man die Fensterbreite reduzieren, dann werden manche Parameter schmaler dargestellt. Ausgabe/Eingabe kann auf dezimal oder hexadezimal umgestellt werden, Farben sind in 4 Modi einstellbar.
Mausunterstützung ist vorhanden.
Allerdings bezweifle ich, daß jemals irgendwer mit diesem Ding arbeiten will.
Die Funktionsweise unterscheidet sich von der normaler Tracker in einigen wesentlichen Punkten:

1.) Es gibt an sich keine richtigen "Tracks".
ISM spielt einfach ab, was es im Speicher an der entsprechenden Stelle findet. Man kann jede Stimme einfach auf eine Startadresse setzen und sie spielt los. Das heißt: Es ist auch möglich, daß Stimme 3 das gleiche Stück Melodie spielt, das Stimme 2 spielt oder irgendwann spielen wird oder gerade gespielt hat, auch mit anderer Geschwindigkeit, Tonhöhe, Instrument, Lautstärke...
Das bedeutet: Die Fenster stellen nur einen Ausschnitt aus dem gesamten verfügbaren Speicher dar. Sie können nur der Einfachheit halber so eingestellt werden, daß sie den Inhalt einer der Stimmen darstellen.

2. Es gibt Längenparameter.
Weil es Längenparameter gibt, gibt es demzufolge keine "nebeneinanderliegenden" Noten/Töne in den "Tracks" (könnte man höchstens tun, indem man Speicher verschwendet und NOPs in die Zeilen einfügt).

3. Es gibt Hüllkurven, Wellenformen und Filter.
Zusätzlich zu den Samples (eigentlich sind bei ISM Samples das "Zusätzliche") gibt es hier auch die Möglichkeit, sich Instrumente zu "bauen":
- Aus Hüllkurven (Attack-Decay-Sustain-Release, jeweils 16 Werte, die auch nichtlinear definiert sein können (außer bei Sustain)).
- Aus Wellenformen (bis zu 4 aus möglichen 7 Wellenformen können miteinander kombiniert werden, auch mit unterschiedlicher Wellenlänge zueinander, es sind theoretisch damit bis zu 32768 verschiedene Wellenformen möglich - aufgrund der Wiederholungen bei "gespiegelten" Kombinationen natürlich in der Praxis weniger.
- Aus Filtern. Diese sind vorgesehen, derzeit noch nicht implementiert (ich komme einfach zu nichts). Die Filter werden aber wahrscheinlich nicht "der Weisheit letzter Schluß" sein, die sollte man bei ISM eher sparsam einsetzen.
Und ja, das klingt alles irgendwie nach C64-Soundchip (SID) - viele der Ideen sind diesem auch direkt nachempfunden.

4. Man kann das ganze Ding "programmieren."
Zusätzlich zu den "Noten", die den größten Teil der Befehle ausmachen (96 Noten, also 8 Oktaven) gibt es hier noch einige zusätzliche Befehle:
4a: Sprungbefehle. Selbst in meinem ersten eigenen Musikprogramm (auch schon kein "Tracker") gab es Längenbefehle und keine richtigen Tracks. Und es gab Sprungbefehle, Aufrufbefehle (für "Unterprogramme") und Schleifenbefehle (für Wiederholungen). (Das Ding war für bis zu 3-stimmingem PC-Speaker-Sound gewesen, die Stimmen haben schnell hin-und-her gewechselt, so wie z.B. bei Xenon2, bei mir klingts aber irgendwie besser, wahrscheinlich weil schnellere Wechsel.)
4b: Instrumentbefehle. Man kann alles quasi irgendwo per Befehl+Parameter festlegen und bis zur nächsten Änderung wird dann alles so abgespielt.
4c: Spezialbefehle. Zusätzlich zu den "normalen" Befehlen habe ich eine ganze Reihe Spezialbefehle eingebaut. Ich habe neulich mal die Specs/Doku zum MOD-Format gelesen und diese ganzen Effekte hat ISM NICHT!
Aber: Weil ISM zwei Register hat, die eigentlich für Schleifen, bzw verschachtelte Schleifen gedacht waren, sowie einen Stack, der eigentlich nur für die "Unterprogramm"-Aufrufe gedacht war, konnte hier auch noch viel gemacht werden. So wurde aus dem Lowbyte bei einem der Befehle ein ganzer Befehlsvorrat, der quasi ganze Berechnungen und Transfers durchführen kann... - Dammich, man könnte fast 'n eigenes Spiel nur mit dieser Soundgenerationsroutine schreiben... (Vielleicht mach' ich das sogar mal, nur um zu beweisen, daß es geht...)
Das heißt: Mit etwas geschickter "Programmierung" dieses Dings kann man auch Vibrato und ähnliches erzeugen lassen.

Achja, ISM hat auch die Möglichkeit, bestimmte Werte nach "extern" auszugeben, bzw von einer externen Quelle Werte zu erhalten. Sinn des ganzen ist bedingt durch den eigentlichen Zweck von ISM:
Es soll in Spielen verwendet werden, für Musik UND Soundeffekte. Damit das Spiel die Möglichkeit hat, von extern auf einfache Art einen Soundeffekt oder Musik zu starten, ohne dafür irgendwie extra in die Daten oder den Code einzugreifen, kann dies einfach über einen externen "Datenstack" gemacht werden, der der Einfachheit halber ein String ist. Ein anderer "Datenstack" - ebenfalls ein String - gibt Werte aus, die in ISM selbst mit einem Befehl erzeugt werden können. Dies dient dazu, dem externen Programm (Spiel) z.B. mitteilen zu können, ob ein Musikstück oder Soundeffekt zu Ende ist - oder vielleicht einem Demo, wenn z.B. ein Paukenschlag erfolgt, um z.B. auch grafisch darauf zu reagieren.
Desweiteren kann man die 16 Stimmen bis zu 16 "Devices" zuordnen, meist eher weniger, d.h. die ganze Musik wäre z.B. ein Device und die Soundeffekte auch entweder eins - oder für jeden Effekt ein eigenes. Sinn des Ganzen ist, die Lautstärken der Devices einzeln von extern regeln zu können, um z.B. Lautstärke von Musik und Soundeffekten einzeln einstellen zu können oder bei Soundeffekten diese abhängig von einer "gedachten Entfernung" zu machen.
Wahrscheinlich werde ich dazu schon Standard-"Code" mitliefern, damit "wer-auch-immer-das-benutzen-will", ein einfacheres Interface dazu erhält, das sich schon so verhält.

OK, genug davon. (Vielleicht sollte ich mal einen eigenen Thread für diesen Mist aufmachen - sobald Du (Zatzen) Dich beschwerst, wie Off-Topic der Kram ist, den ich hier in Deinem Thread verzapfe...)

Ich habe, für Interessierte, ein ZIP-File auf meinen Webserver hochgeladen:
http://imperial-games.de/z/ism1.zip
Dieses enthält:
* ENTE9.WAV
Der obengenante Song, so wie er von ISM ausgegeben wird (also in voller Lautstärke)
(Also eventuell den Player etwas runterregeln, damit einem nicht die Ohren abfallen.)
* SMACHI01.PCX
Ein Screenshoot von dem "Tracker, der gar kein richtiger Tracker ist", im 80x50 Mode.
* _ISM.TXT
Der aktuelle "offizielle" Beschreibungstext der ISM Unit, inklusive Sampleformat und Anhang mit den
Standardtasten für die Befehle. Ja, das sieht alles schon so halb wie Assemblerprogrammierung aus.

Es gibt auch schon eine Alpha-Version des Textes, der das Fileformat für die gespeicherten Musikdaten beschreibt - aber ich bin noch nicht ganz zufrieden damit, da werde ich eventuell noch einiges ändern. (Momentan gibt ISM einfach alles als bloßen 32kB großen Speicher-Dump aus.)

Und ja, bei diesem Ding (ISM und alles was dazugehört) habe ich mich leider komplett für Englisch entschieden. Vielleicht werde ich aber noch einen deutschen Beschreibungstext erstellen, wenn die Version "entgültig" ist.
zatzen hat geschrieben: Den "sinfonischen" Anspruch definiere ich eher über anspruchsvolle Melodien, weniger darüber,
wie es Synthesizer-bedingt klingt. Auch ein NES kann einigermaßen anspruchsvolle Musik wiedergeben.
Eigentlich sogar ein monophoner PC-Speaker.
Ich weiß. Der Editor läuft derzeit ja so - wird alles mit Speaker (im "Digital-Mode") ausgegeben, derzeit mit 14 kHz.
zatzen hat geschrieben: Ich habe auch mal eine Demo zu deiner Grafikengine gesehen. Das war von der Performance und den
Möglichkeiten auf jeden Fall um Längen besser als mein ZVID, wobei wir ja andere Ziele verfolgen.
Naja, meine Grafikengine ist ja eher für Arcade-Spiele gedacht, weniger, um damit Filme/Videos zu machen. Man könnte sie allerdings auch für Adventures benutzen - eben nur die Sprites. Die Hintergründe wären scrollende Vollgrafiken. Ja, man könnte auch die Hintergründe aus Blöcken zusammenbauen (bzw diese in Blöcke zerschneiden) und hätte dann auch Mehrebenen-Parallaxing. Allerdings wäre die erforderliche Anzahl Blöcke ja erheblich - und sie dürften sich (bis auf einen "Null-Block" mit Vollstransparenz) ja nicht wiederholen. Für so etwas würde ich dann eher eine eigene Routine bauen.
Außerdem wäre bei 2D-Adventures ja noch eine "Wege"-Ebene wichtig, d.h. eine Ebene, die nur definiert, wo die Figur langlaufen kann bzw. welche optische Entfernung der Weg an dieser Stelle hat (damit die Figur entsprechend verkleindrt dargestellt werden kann). Außerdem wäre eine virtuelle Verdeckungsebene ganz brauchbar (so etwas wird auch schon in PLAYBOX von mir benutzt), die dafür sorgt, daß die Figuren auch HINTER einem Baum vorbeigehen können. Das kann man zwar auch auf mehrere Ebenen ausweiten - wird aber meist nicht gebraucht und man soll's ja auch nicht übertreiben.
zatzen hat geschrieben: Hast du schonmal drüber nachgedacht "auf" deine bisherigen Tools, mit denen man schon so viel hat
um ein Spiel zu realisieren, eben eine Art simple Engine zu setzen, um nicht zu sagen soetwas wie einen
"Game Maker"?
Letzteres sicherlich so nicht, aber vielleicht verstehst du was ich meine. Du hast super Tools entwickelt
aber ausser dir benutzt es scheinbar niemand, weil es wahrscheinlich immer noch zu viel Einarbeitung
erfordern würde und man, so wie ich es verstehe, immer noch in Pascal programmieren muss um die
Tools zu verwenden.
Kurze Antwort: Ja.
Lange Antwort: Wahrscheinlich hat jeder, der so etwas macht wie ich hier gerade, auch schon darüber sinniert, das Ganze in einen Game-Maker zu verpacken, mit einer Schleife drum, damit alle Leute damit Spiele bauen können.

Es gab bisher mehrere Gründe, mich dagegen zu entscheiden:
1.) Reine Game-Maker Spiele, die ohne einen Quent Eigenprogrammierung des Spiel-Machers auskommen, sind sich einfach "zu ähnlich". Man kann einfach immer nur das gleiche langweilige Spiel mit den gleichen Daten draus machen, es sieht zwar anders aus - aber die Möglichkeiten sind eben dann leider darauf beschränkt, was der Game-Maker an Optionen vorgibt. Sollen diese Optionen auch noch "idiotenfreundlich" sein (also so, daß wirklich auch jeder absolute Volldepp es versteht), schränkt man die Möglichkeiten noch weiter ein - interessante komplexe Dinge wären also in so einem Spiel nicht mehr möglich.
Und ja, es mag auch ein paar weniger mit Game-Makern gemachte Spiele geben, denen man es nicht sofort ansieht und wo man die große Mühe beim Eigenanteil des Spiel-Machers erkennen kann. Aber die meisten mit Game-Makern gemachten Spiele sehen nach "zu faul, etwas richtiges zu machen" aus und öden mich an.

2.) Ich entwickle überhaupt nicht gern solche "GUI-Oberflächen". Ich mache es manchmal, weil es nötig ist oder weil das Erstellen der Daten (Sprites, Levels, usw...) sonst in einen unerträglichen Aufwand für den Ersteller (und sogar mich) ausarten würde. Aber jede solche Oberfläche ist wieder mehr Aufwand für mich, der Zeit kostet und der mich von dem Ziel, endlich mal ein Spiel herauszubringen, wieder einen Schritt entfernt.
Ich habe sogar neulich angefangen, das ganze DIng namens "ELEMENTS", womit ich die GUI von diesem TheGame3 fabriziert habe, nochmals aufzubügeln, damit noch mehr in das GUI-Skript ausgelagert werden kann (und noch weniger fixer Programmcode notwendig ist, der all das macht, was die GUI nicht selber kann). Grund ist: Der benötigte Teil vom GUI-Skript kann einzeln nachgeladen/wieder entladen werden, solange man ihn braucht. EXE-Programmcode liegt die ganze Zeit im Speicher rum und belegt dauerhaft Platz.

3.) Entweder man beschränkt sich beim Game-Maker auf ein bestimmtes Genre. Das wäre dann natürlich leider öde, weil einem wieder die Möglichkeiten fehlen. Überraschungen? Fehlanzeige. Ein 2D-Arcade-Spiel, in das man eine 3D-Rennspiel-Sequenz oder eine Point&Click Adventure-Sequenz einbaut? Fehlanzeige.
- oder -
man unterstützt so viele Genres wie möglich, so daß quasi "möglich ist alles" entsteht. Damit schleppt man aber immer einen Overhead von zwar theoretisch unterstützen, aber in der Praxis nie alle gebrauchten Features im Code mit herum, was dann wieder viel Speicher belegt und wieder den Speicher für Grafiken und Sounds einschränkt.

4.) Ein Game-Maker als ein komplettes Einzelwerk ist gegenüber Editoren für einzelne Teile eines Spiels auch immer im Nachteil, weil: Jeder Editor selbst belegt schon Speicher (und Performance). D.h. JEDER Editor kann nur maximal soviel Daten (Grafik/Sound/Level/Code) erstellen wie
Verfügbarer_Speicher MINUS Speicher_den_Editor_für_eigene_Daten_und_Code_braucht.
Außerdem wäre so ein "Allround-Maker" dann auch so, daß der Programmcode, der für Entwicklung/Darstellung von Levels/Sprites u.ä. zuständig wäre, auch dann im Speicher herumliegen würde, wenn man gerade Sounds machen will und dann weniger Speicher für die Sounds/Samples hätte.

Und: im Spiel SELBST braucht man den Editor schonmal gar nicht - somit ist es besser, die einzelnen Teile mit einzelnen Editoren zu entwickeln und am Ende zusammenzuführen - und für das Spiel ist immer noch genug Platz, um eventuellen Code (für das Spiel einzubauen) oder die einzelnen Teile (Grafik, Sounds, Levels, Spielskript) einzeln nachzuladen, d.h. in den Speicher aus-/einzublenden).
Und ja, das ginge, wenn man es wie Norton Commander 5 macht: Eine NC.EXE, die entweder die NCMAIN.EXE (den Commander selbst) ODER entsprechend andere Programme aufruft - um den durch den Commander belegten Speicher freizugeben, wenn dieser gerade nicht angezeigt wird.

Prinzipiell gibt es aber für alle Dinge, die ich erstelle, auch immer gleich die passenden Lader und Darstellungs-Subroutinen in Units dazu, so daß die Hauptschleife, die man "um das ganze herum" programmieren müßte, dann eigentlich doch recht einfach ausfallen sollte.
Ich fände es irgendwie blöd, wenn dann die Schrift und das Menü (so vorhanden) bei allen so mit "Maker" gemachten Spielen immer gleich aussehen (nicht mal dem Spiel-Thema angepaßt werden könnten) oder man nicht mal die Möglichkeit hätte, ein Titelbild, Zwischensequenzen oder ein paar Gags einzubauen (weil der Maker dafür keine - oder nur Standard-Optionen - hätte).

5.) Wie ich schon öfter aus Bemerkungen, wie Du Dir vorstellst, der ideale Maker zu sein hätte, entnommen habe, stellst Du Dir eine Art "generelles Beschreibungs-Skript" vor, das in etwa beschreibt, was das Spiel so können soll und den Rest soll der ganze Maker allein herausfinden/kreieren.
So etwas gibt es nicht - und wenn, wäre es das ödeste Spiel das Jahrhunderts. Wieso? Weil man von einer Maschine nunmal einfach keinerlei Kreativität erwarten kann. Das einzig Kreative, was eine Maschine zustandebringt - und das auch noch nicht einmal besonders gut - ist ein Zufallsgenerator (eher Pseudo-Zufallsgenerator).

So etwas wäre nur möglich (und selbst dann eher schlecht) , wenn man dem ganzen Ding Millarden von Grafiken, Sounds, Levels, eventuellen Figurenverhaltens u.ä. vorgibt (d.h. das müßten der/die Programmierer des Makers alles schon selbst bereitstellen - dafür bräuchte man die Einwohner einer ganze Stadt von Designern) - und selbst dann wäre das von der Maschine daraus errechnete Ergebnis nur schlecht bis bestenfalls (mit viel Glück und Spucke, und wenn der Zufallsgenerator 'n guten Startwert hatte) mittelmäßig im Vergleich zu einem wirklich von einem Menschen mit Einfällen und Witz und Charme erstellten Spiel.

Desweiteren wäre natürlich jedes derartige Skript wieder ein Hemmschuh für die Performance, da dieses ja auch wieder von einem mitlaufenden aufwendigen Skriptinterpreter, der vage Vorstellungen in konkrete Ergbnisse umsetzt, ausgeführt werden müßte. (Computer können nicht "fast 0" oder "ein bißchen 1".)
zatzen hat geschrieben: Vielleicht geht so ein Vorschlag gegen deine Ideale, aber ich habe genau soetwas vor, dass ich meine
Engine mittels Daten und Definitionen in Textdateien füttern kann.
Ok, eine Sache sehe ich hier aber: Im Gegensatz zu dir mache ich diese Textdatei-Parameter Engine
auch allein schon für mich, weil ich mir das angenehmer vorstelle als alles zu programmieren.
Das ist es, was ich mit dem unter 5.) Gesagten meine.
Das Problem wäre: IRGENDWER MÜßTE dann aber trotzdem an irgendeiner Stelle mal programmieren, denn alleine aus einem menschenlesbaren Text wird eben nichts, was der Computer ausführen kann.
Ich weiß, das sieht beim Holodeck der Enterprise so aus, als wäre das möglich. Per Spracheingabe einen Befehl ans Holodeck, das Ding erstellt das Gewünschte und fügt für alles, was nicht explizit erwähnt wurde, etwas brauchbares ein.
Aber erstens spielt das in über 300 Jahren und zweitens (wenn es das dann mal irgendwann so gibt - es ist ja eine Science-Fiction-Serie) haben sicher auch ganze Armeen von Programmierern am internen Computer der Enterprise herumgebaut und ihn mit allem bekannten Wissen des Universums geladen, damit so etwas möglich ist.

Und natürlich ist es klar, daß der Aufwand für einen Ersteller direkt proportional geringer wird, wenn ein ganzer Haufen anderer Leute vorher schon die ganze entscheidende Arbeit geleistet hat. (Im Sinne von: "Fangt schonmal an, ich setze am Ende meinen Namen drunter.")
zatzen hat geschrieben: Ich rechne ja auch eigentlich gar nicht damit dass noch jemand ausser mir dann diese Engine benutzt um eigene Spiele zu machen, dazu leben wir 20 Jahre zu spät, es gibt heute andere Tools für junge Leute die mal eben ein Spiel machen wollen. Von daher macht es für dich keinen Sinn deine Tools in einen Game-Maker zu gießen, wenn du auch der einzige bist der sie verwenden wird.
Wie gesagt: Sinn würde es schon machen - mir würde aber eher eine Variante vorschweben, in der der Entwickler des Spiels auch (außer eine simple Idee in eine Textdatei zu schreiben) etwas mehr Eigeninitiative mitbringen müßte, d.h. sich wenigstens ein wenig mit Computern auskennen usw.

Und "mal eben ein Spiel machen" ist genau das, was ich nicht so mag/will. "Mal eben gemachte" Spiele sehen auch genauso aus und spielen sich genauso. Dazu wäre mir die Zeit und der Aufwand zu schade, um am Ende nur so ein "schnell hingerotztes irgendwas" zu haben, das dann unter Kategorie Spiel läuft, weil sich irgendwas von selbst bewegt.

Mein "Maker" - wenn und falls ich JEMALS mal einen bauen sollte - würde NICHT irgendein fertiges "Run-Time-Modul" besitzen, das "alles enthält, was jemals irgendein Spiel gebrauchen könnte und dazu dann ein angehängtes oder einzelnes Skript für das Spiel - sondern, es würde eine EXE erstellen (bzw einen Source, der compiliert eine EXE ergibt), die enthält, was gebraucht wird. die Units nutzt, die nötig sind, eine entsprechende Hauptschleife generiert und die erforderlichen Daten für Steuerung, Grafik, Sound und ggf. Menüs in einem Datenfile enthalten würde, ggf. auch an die EXE gelinkt.
Allerdings müßte natürlich trotzdem irgend jemand Sprites und Hintergründe pixeln (oder meinetwegen zeichnen und einscannen - was ich bei dem einen Spiel sogar vielleicht vorhabe, damit es wie witzige Comicgrafik aussieht), jemand die Musiken und Soundeffekte erstellen - und es müßte auch jemand die Bewegungen der Spielfigur, sowie (falls es n Arcade-Shooter oder sowas wird) der Gegner und Geschosse ebenfalls deklarieren - also "programmieren". Und wenn es nicht in direkter Programmiersprache ist, dann zumindest in irgendeiner Beschreibungssprache/Skript, die das ausreichend definiert. (z.B. eben mein GameSys2 - eigentlich wollte/sollte ich dazu mal ein "Hochsprachen-Frontend" machen - aber ich komme einfach zu nichts. Derzeit sieht die Sprache von GameSys2 Assembler ähnlicher als jeder Hochsprache.

Und ja, mein GameSys2 ist genau dafür gedacht, Spielfigurenbewegung/-verhalten zu programmieren, es erleichtert die ganze Sache immens (enthält bereits vollständig eigene Kollisionsabfragen und Möglichkeiten, darauf zu reagieren - kann insgesamt über 2000 aktive Figuren gleichzeitig verwalten, enthält auch gleichzeitig eine eigene autmatische Speicherverwaltung dazu.
Und ja, mein Arcade01 stellt Sprites und Levels quasi von alleine dar, in verschiedenen Auflösungen, Sprites auch skaliert, gedreht, gespiegelt - hab das alles schon erwähnt.
Und ja, mein ISM füllt die Soundpuffer für die Soundkarte komplett selbständig den gemixten Daten aus insgesamt bis zu 16 Stimmen für Musik und Soundeffekte. (D.h. der Soundkarte muß man nur noch sagen: Da Puffer, spiel ab mit Frequenz X, benutze falls nötig DMA Y, schmeiße IRQ Z, wenn fertig.)

Aber: Jemand muß in GameSys2 "programmieren". Jemand muß die Levels, Levelkacheln ("Blöcke") und Sprites pixeln. Jemand muß die Musiken und Soundeffekte entwickeln. Ohne Daten stehen die Figuren nur rum, sind schwarze Kästchen vor schwarzem Level und die Musik und Effekte sind eine tote Mittellinie.
zatzen hat geschrieben: Wobei ich deine Tools für so gut halte dass ich mir denken könnte, dass manche Liebhaber von Pascal und DOS sie gerne verwenden würden.
Mich eingeschlossen, wenn meine einzige Motivation zu programmieren nicht die wäre, eben hier mein
ZVID zu verwenden und auch Musik per Samples wiederzugeben... Und eben eine eigene Engine, konkret
auf eine relativ simple Form von Spiel zurechtgeschnitten.
Ich weiß zwar nicht, was Du mit "relativ simple Form von Spiel" meinst...
Naja, mein "Anspruch", wenn man das so nennen kann, war immer, Spiele in der Art, wie sie so bis ca. 1995 auf Konsolen und PC waren (mal von den 3D-Sachen abgesehen), zu bauen, weil das auch zu den Dingen gehört, die ich gern spiele/gespielt habe.
zatzen hat geschrieben: Ich bin da vielleicht auch ein schlechter Kunde, denn ich erfinde gerne das Rad neu, auch wenn es andere
schon besser gemacht haben.
So geht es mir ja auch. Ich will wissen, was ich tue, wissen, was ich benutze usw.
Bei fertigen Bibliotheken muß ich mich immer darauf verlassen, was diese machen und können - außerdem kann ich nicht mehr "eingreifen", um vielleicht noch andere Dinge als "den Standard" damit zu machen. Mein eigenes Zeug kann ich immer noch bei Bedarf erweitern - naja, und so weiter.
Außerdem macht mir die Entwicklung der ganzen internen Sachen am meisten Spaß. Irgend etwas aus einem fertigen Baukasten zusammenzubauen hat mich nie irgendwie fasziniert. Das mag auch einer der Gründe sein, wieso ich der Programmierung unter Windows (und ja, ich habe es auch schon versucht) kaum etwas abgewinnen kann (mal abgesehen davon, daß Programme unter Windows scheinbar immer nur riesig und langsam sein können).
zatzen hat geschrieben: Vor 20 Jahren hätte ich aber sofort gerne Grafikroutinen blind übernommen, die Transparenz erlauben. Das habe ich mir aber jetzt selbst erarbeitet, leider nur noch nicht richtig in einem Spiel ausgeschöpft.
Naja, die Transparenz meiner Routinen ist an sich nichts besonderes. Wie bei fast allen Dingen, die performen sollen aber trotzdem was hermachen, arbeite ich auch hier mit Tabellen.
zatzen hat geschrieben: Eventuell könnte ich aber, wenn es mal so weit ist, ein paar gute Routinen für die XMS Nutzung gebrauchen.
Da habe ich etwas fertiges da. Ich werde nur noch mal irgendwann eine kleine Erweiterung zum Standard einbauen. Standardmäßig supportet HIMEM.SYS offenbar immer nur eine gerade Anzahl Bytes zu kopieren die Adresse im XMS kann ungerade sein). D.h. wenn man z.B. 27 Bytes kopieren will, muß man 28 kopieren und eins wegschmeißen, egal in welche Richtung (XMS->HEAP oder HEAP->XMS).
XMS verwende ich aber weiterhin nur als Speicher - ich kann nichts direkt daraus nutzen. Um es zu nutzen, muß ich immer den genutzen Teil in den HEAP (also Speicher unter 1MB) kopieren. Klar, weil ja RealMode.

Bisher habe ich das mit ungeraden Anzahlen immer extern gelöst, wo es nötig war. Aber eigentlich ist so etwas Blödsinn - so etwas hat natürlich gefälligst direkt in der Unit zu erfolgen.

Die Unit ist übrigens quasi vollständig in Assembler geschrieben, nur die Procedure-Header sind eben in Pascal, so daß man es einfach ganz normal in Pascal nutzen kann.
zatzen hat geschrieben: Ich hatte früher schon einmal sozusagen eine ganze simple Game-Engine gemacht...
Ja, sieht stark nach Kotzman II aus.
(Ich fand die Tastenbelegung immer 'n bißchen nervtötend. Kann man das mal ändern? Außerdem ist der Einstieg in Level 1 recht dusselig gelöst, mit diesem "Spielstand laden" und so... Das geht doch sicher besser... Ansonsten gefällt mir das Game aber recht gut. Auch so bißchen mit Story und so.)

Aber z.B. für ein Game wie z.B ein Kotzman III wäre alles, was ich hier an Units und Entwickungstools schon habe, geradezu schon ideal. Ich hätte zwar noch nichts da für eventuelle Zwischensequenzen, aber hab mal gehört, daß dafür ein Entwickler eine Engine namens ZVID entwickelt hat...
(Könnt man sogar so mit Kotzman und Saugi machen - entweder für einen Spieler, der die Figuren dann im Wechsel steuert, jede Figur mit ihren Fähigkeiten, oder im 2-Spieler-Mode spielt einer Kotzman und einer Saugi... - und manche Stellen im Level wären dann nur mit Zusammenarbeit der beiden möglich...
Wieso muß ich selber auf sowas kommen?)

Achja, Entschuldigung, daß ich mich erst jetzt gemeldet habe. Ich habe gerade Urlaub und programmiere hier wie ein Wahnsinniger. Will die Zeit nutzen, weil ich sonst immer kaum zu etwas komme. So ein kurzes Wochenende reicht oft einfach nicht aus.

Re: Eigenes Videoformat

Verfasst: Mo 30. Nov 2015, 16:56
von DOSferatu
Kleiner Nachtrag:
Ich habe jetzt einen kleinen "Starter", der zu Kotzman und Kotzman II kompatibel ist, geschrieben und mit dem man die Tasten für das Spiel (also Links/Rechts/Springen/Kotzen) frei definieren kann. An-/ausschalten kann man das im Spiel mit F12.
(An der Kotzman.exe bzw Kotzman2.exe habe ich natürlich nichts verändert.)
Ich habe es getestet - funktioniert. Jetzt kann ich endlich mit Cursortasten, ALT und CTRL spielen - bin aber immer noch schlecht. Andauernd geht mir die Kotze aus. Und dann steht man vor 'ner Wand und Tank ist leer. Die Viecher sind auch leider sehr schnell, Überspringen um Kotze zu sparen funktioniert leider nicht, die erwischen einen trotzdem.
Ich hab im Netz auf Youtube mal einen Walkthrough gefunden - ich frage mich, wie der das geschafft hat, das Spiel durchzuspielen. Ich finds recht schwer. (Ich meine jetzt Kotzman II.)

Re: Eigenes Videoformat

Verfasst: Mo 30. Nov 2015, 17:53
von zatzen
Also, ich schreibe erstmal noch etwas zu meiner Idee wegen der Game-Engine.

Es soll ja auch gar kein idiotensicherer Game-Maker werden.
Ich erwähnte das nur, weil wenn man mal auf Youtube nach
selbstgemachten Spielen sucht, dann kommen meistens so Spiele
mit 100 MB Platzbedarf für QuadCore Prozessoren und einem Level
wo eine kleine Kugel rumhüpft.
Es gibt da viele Möglichkeiten und Angebote ein Spiel zu machen,
und wenn ich nicht programmieren könnte und aber ein Spiel machen
wollte wäre irgendeines dieser modernen Tools meine Wahl.
Aber es ist umgekehrt, ich will nur deswegen ein Spiel machen, weil
ich programmieren kann...

Auch bei den Textdateien haben wir uns falsch verstanden. Ich will da keineswegs
so rangehen dass man da in Prosa eine Geschichte reinschreibt aus der der Computer
dann wie von Zauberhand ein Spiel macht.
Vielmehr sollen diese Dateien, von denen es reichlich und strukturiert welche geben soll,
Definitionsdateien sein. Dass ich sie als "Textdateien" betitele soll nur heissen, dass es
ASCII Dateien sein sollen, und da der ZVID Converter (also der der aus rohen Grafikdaten
ZVID komprimierte macht) ein Freepascal 32 Bit Programm ist das unter Windows läuft,
ist es naheliegend für die Definitionen .TXT zu verwenden - okay, man könnte sie auch
.DEF nennen und Windows mitteilen dass es diese mit dem Editor öffnen soll.
Aber so würde ich eben die ganzen Entwicklungstools für das Spiel wahrscheinlich
in Freepascal schreiben, und auch dann quasi einen Compiler, der zwar keine
EXE Datei speziell für das Spiel kompiliert, aber z.B. alle Daten mit den Definitionen
zusammen in eine Datei kompiliert.
Die Engine wäre dann gewissermaßen ein Player, aber kein langsamer Interpreter.
Die Mühe, einen Interpreter zu schreiben, mache ich mir nicht.

Ich würde die Engine vielmehr für mich machen, um überhaupt einmal ein neues
Spiel hinzubekommen. Es ist für mich strukturierter wenn ich das Coden der Engine
und die Erschaffung der Spieledaten (Sprites, Samples, Hintergründe) und die
Definitionen oder Scripts (die ich lieber als Parameter halten würde, aber man
muss sehen ob das geht) trenne.
Eine GUI kommt für mich nicht in Frage, das wäre ja hinterher mehr Aufwand
als die Engine selbst. Aber daher eben dann alles in Text bzw. Definitionsdateien
definieren.

Technisch wären die Spiele dann alle gleich, das stimmt schon.
Das stört mich aber wenig, da ich ersteinmal ja nur ein Spiel überhaupt erschaffen will.
Und dann könnte es doch ohne weiteres einen zweiten oder dritten Teil geben.

Überraschungen würde ich in Form der Charaktere und Figuren einbauen, ich bin nicht
derjenige der ein Spiel erschaffen will das besonders schwer zu durchzuspielen ist,
sondern ich ziele mehr auf Unterhaltung ab und man würde eher alles mögliche
ausprobieren und erkunden können als immer nur linear über alle Hürden und Gefahren
hinweg rasen zu müssen.
Soetwas hatte ich als 7jähriger als Vision als ich Nintendo spielte, habe mir daraufhin
Zelda angeschafft - man konnte da zwar in alle Himmelsrichtungen gehen, aber es
war trotzdem wieder nur das gleiche - terrorisierender Schwierigkeitsgrad der einen
ganz meschugge machen konnte. Sowas muss ich nicht haben.
Also kurz gesagt: Prinzipiell wie ein Adventure, nur mit deutlich mehr Eigenleben,
dass alles wuselt und lebt auch wenn man mal nicht klickt. Also quasi mehr Echtzeit
und weniger nach dem Prinzip "jede Handlung einzeln anschieben". Und mehr oder
weniger 2D genügt mir da, auch bei den meisten Adventures kommt die Skalierung eher
selten zum Tragen. Musst mich hier verstehen, ich will ZVID auch für Sprites anwenden
weil es einfach schön ist wenn ein kompletter Sprite-Satz nur 1KB groß ist.

Seit einigen Jahren schwebt mir das einfach vor, dass ich ein Spieleformat habe
wie ein Modul, so dass man es auch allgemein als Dateiformat beschreiben könnte.
Sicherlich nicht jedermann's und auch nicht deine Sache, und möglicherweise wird
mein Versuch scheitern, andererseits, wenn ich richtig liege und soetwas machbar
ist, könnte das betont strukturierte Vorgehen die Sache erleichtern und beschleunigen.
Bis jetzt "kapiere" ich jedenfalls nicht, warum das nicht gehen sollte. In einem Spiel
habe ich Objekte, und diese Objekte kann ich mit Parametern deklarieren... uswusf...

Nochmal weiter technisch, vielleicht genügt es wenn man bei der Definition von
begehbaren Bereichen auch ein 8x8 Pixel Raster nimmt. Oder wenigstens 4x4.

Wie auch immer... Wenn du die SCUMM Engine auch als etwas betrachtest, was immer
gleich aussieht, dann kann ich damit leben. Ich kann auch gut nachvollziehen dass einem
gerade im Action Bereich schnell langweilig wird wenn es technisch immer das gleiche
Spiel ist, also immer die gleichen Abläufe nur mit anderen Grafiken. Aber bei Spielen
wie Adventures kommt es ja gerade auf die Grafiken an und auf die Story die damit
erzählt wird, und dass seit Ende der 80er immer nur von der fast gleichen Engine
Sprites von A nach B bewegt werden stört niemanden.

Re: Eigenes Videoformat

Verfasst: Mo 30. Nov 2015, 18:19
von zatzen
Hehe, ja Kotzman II.
Derjenige der da spielt bin ich. Vielleicht merkt man bei Spielen von sich selbst nicht, dass die eigentlich
schwierig sind und schraubt dann das Nadelöhr so eng dass man sich kaum noch Fehler erlauben kann.
Im Video ist das aber die richtige Geschwindigkeit.

Die komische Tastaturberbelegung kommt aus einer "Empfehlung" von dem Buch "Spiele programmieren mit QBasic"...
Da hat man sich auf die Tastaturstatusbytes berufen weil es innerhalb QBasic wohl nicht so einfach war den Status
der einzelnen Tasten des gesamten Keyboards abzufragen.
Ich wusste damals sehr wenig und konnte auch keine transparenten Sprites darstellen, und ich habe auch nichts
mit Puffer gemacht: Alle Sprites haben einen schwarzen Rahmen und bewegen sich immer nur einen Pixel, so dass
sie nichts ausser schwarz hinter sich zurücklassen. Allein deswegen würde ich gern mal ein komplettes Spiel neu
machen. Aber auch, weil diese 08/15 Gänge-Jump&Runs irgendwie nicht so super sind.

Da sieht man mal wieder welch tolle Möglichkeiten man mit DOS hat...
Klar kann es sowas wie Tasten abfangen(?) auf in Windows geben, aber da muss man sich wahrscheinlich
erstmal durch die dicke Bürokratiewand hämmern.
Den Starter kannst du mir gerne zukommen lassen, interessant wäre natürlich auch der Code.
Ansonsten, wie ich schon schrieb, spiele ich selten, auch meine eigenen Sachen, und ich hab
mich an die Steuerung bei Kotzman gewöhnt.
Naja, ein bisschen komisch, diese Gestalten Kotzman und Saugi kommen aus so Zeichnungen die
ich vielleicht so mit 12 angefangen habe in der Schule aus Langeweile zu zeichnen.
Das ganze Spiel ist unüberlegt und eher drauf los programmiert, weil ich damals eher schnelle
Ergebnisse wollte als ein gut durchdachtes Dingen - aber irgendwie ging es auch nicht anders,
erstmal hatte ich nur QBasic unterm Arsch und einfach zu wenig Erfahrung.

Eine kleine Sache kann ich aber erzählen:
Bei den Cutscenes ging BASIC damals der Speicher aus.
Zu viel Programmcode.
Da musste ich mir was einfallen lassen und habe die Cutscene in einem neuen Programm geschrieben,
Grafik- und Textausgabebefehle in Codes verpackt, auch die, die eine Datei neu laden (so eine Szene musste
man ja auch über mehrere Grafikdateien verteilen) das ganze in einen String gespeichert und den
dann im Spiel geladen und als Steuerung genommen. FRA hab ich's glaub ich genannt (Frankus Animation).

Re: Eigenes Videoformat

Verfasst: Mo 30. Nov 2015, 18:51
von zatzen
Ich hab noch eine Frage an dich (ich bekomm grad richtig Lust langsam mal in die Gänge zu kommen mit dem Spiel):
Wie machst du das mit dem Hotspot bei Sprites?

Der VGA-Puffer zählt ja von oberster Linie und Pixel null bis unten rechts 63999.

ZVID ist genauso angelegt.

Ich habe einfach zu lange nichts mit Sprites programmiert bzw. zuletzt einfach nur gesehen dass Y einen
bestimmten Wert nicht überschreitet (Level war nur eine Ebene am Boden), und Kollisionen habe ich einfach
z.B. bei Kotzman II, da alle Objekte gleich groß waren, durch den absoluten Abstand voneinander bestimmt.

Re: Eigenes Videoformat

Verfasst: Mo 30. Nov 2015, 20:45
von zatzen
Zu ISM:

Was ich bisher gehört habe klingt charmant, die 4 Bit Soundqualität wirkt sich doch gar nicht so schlimm aus.

Wenn ich den Screenshot vom Editor richtig verstehe, dann programmiert man die Musik regelrecht mit allen
Mögichkeiten wie bedingten Sprüngen und das alles für jeden der Kanäle unabhängig. So gesehen macht das
viel Sinn und führt zu kompakten Daten. Aber man muss eben vorher schon genau wissen, was man überhaupt
programmieren will, bei "normalen" Trackern, wo die Patterns einfach wie bei einer Spieluhr durchlaufen, kann
man sehr einfach und schnell auch improvisieren. Ist mit ISM nach einiger Übung wohl auch möglich - aber so
hat jeder seine Gewohnheiten. ISM taugt demnach aber ebenso für eine direkte, "dumme" Konvertierung von
Tracker-Daten, aber man könnte auch versuchen einen intelligenten Compiler dafür zu schaffen. Was aber,
denke ich, gar nicht so in deinem Sinne wäre. Zumal man die vollen Möglichkeiten von ISM ja auch nur durch
die direkte Programmierung im Programm selbst ausschöpft.

Meine eigene Idee und dass ich monatelang an einem Patternformat herumgedoktert habe, was letztlich sogar
eine sehr effiziente Komprimierung hevorbrachte, davon habe ich ersteinmal Abstand genommen, da ich ZVID
den Hauptanteil des konventionellen RAM geben und jeglichen Digi-Sound aus dem XMS holen will. Und da wäre
eine komplexe Mischtechnik von Samples mit verschiedenen Tonhöhen zu rechenintensiv, ich werde da eher
soetwas wie einen Mehrspur-Sequencer von jeweils u.a. auch längeren Samples machen.

Re: Eigenes Videoformat

Verfasst: Di 1. Dez 2015, 11:06
von DOSferatu
Ich antworte mal ingesamt dazu:
zatzen hat geschrieben:Also, ich schreibe erstmal noch etwas zu meiner Idee wegen der Game-Engine.

Es soll ja auch gar kein idiotensicherer Game-Maker werden.
Ich erwähnte das nur, weil wenn man mal auf Youtube nach
selbstgemachten Spielen sucht, dann kommen meistens so Spiele
mit 100 MB Platzbedarf für QuadCore Prozessoren und einem Level
wo eine kleine Kugel rumhüpft.
Ja, genau sowas finde ich auch immer Mist. Leute, die dann auch noch stolz
darauf sind, ohne die geringste Mühe und Aufwand, mit Zeug, das andere
Leute denen schon vorgekaut haben, irgendwas schnell zusammenzubauen,
was das 10000-fache der Leistung abfordert, die eigentlich nötig wäre
und soviel Speicher braucht, daß Leute wie Du darin einen 20-minütigen
Film unterbringen könnten - und die da grad mal 'ne kleine Kugel hüpfen lassen...
zatzen hat geschrieben: Es gibt da viele Möglichkeiten und Angebote ein Spiel zu machen,
und wenn ich nicht programmieren könnte und aber ein Spiel machen
wollte wäre irgendeines dieser modernen Tools meine Wahl.
Aber es ist umgekehrt, ich will nur deswegen ein Spiel machen, weil
ich programmieren kann...
Ja, mir geht es ja auch um die Herausforderung. Irgendwie gilt für mich auch
"Der Weg ist das Ziel". Das Machen und dabei Lernen und besser werden ist
viel interessanter als am Ende irgendein "Produkt" zu haben. Klingt vielleicht
komisch.
Aber es ist nunmal so: Es gibt so viele Spiele auf der Welt, daß ich
genau weiß: NIEMAND hat auf ein Spiel von mir gewartet oder wird es jemals
tun. Und selbst WENN irgendwer das Zeug mal spielen würde, würden sie's
nach 10 Minuten wieder wegtun - im Sinne von: "OK, hab ich das auch mal
gesehen".
zatzen hat geschrieben: Auch bei den Textdateien haben wir uns falsch verstanden. Ich will da keineswegs
so rangehen dass man da in Prosa eine Geschichte reinschreibt aus der der Computer
dann wie von Zauberhand ein Spiel macht.
Vielmehr sollen diese Dateien, von denen es reichlich und strukturiert welche geben soll,
Definitionsdateien sein. Dass ich sie als "Textdateien" betitele soll nur heissen, dass es
ASCII Dateien sein sollen, und da der ZVID Converter (also der der aus rohen Grafikdaten
ZVID komprimierte macht) ein Freepascal 32 Bit Programm ist das unter Windows läuft,
ist es naheliegend für die Definitionen .TXT zu verwenden - okay, man könnte sie auch
.DEF nennen und Windows mitteilen dass es diese mit dem Editor öffnen soll.
Ja OK, das klingt schon eher brauchbar. Ich selbst bin der Meinung, daß man es sich
damit unnötig kompliziert macht - da braucht man wieder einen Parser... Wenn man
gleich die richtigen Daten liefern würde, könnte man sich das sparen.
Ich sehe es mal so: Jede Programmiersprache/Skriptsprache/Markupsprache, was auch
immer - ist ja ebenfalls solche eine Beschreibungssprache.
Und ich sag's ganz einfach mal so: Die Sprache, die GameSys2 z.B. benutzt, definiert
das Verhalten der verschiedenen Figurentypen. Die Sprache wird in einen Bytecode
gewandelt, der dann von einem Interpreter ausgeführt wird. Der Bytecode ist aber schon
sehr Maschinencode-ähnlich und der Interpreter ist in Assembler (Realmode mit 32-bit-
Befehlen) geschrieben und erstaunlich schnell...
zatzen hat geschrieben: Aber so würde ich eben die ganzen Entwicklungstools für das Spiel wahrscheinlich
in Freepascal schreiben, und auch dann quasi einen Compiler, der zwar keine
EXE Datei speziell für das Spiel kompiliert, aber z.B. alle Daten mit den Definitionen
zusammen in eine Datei kompiliert.
Ja, ich benutze ja auch öfter solche Skripte, um mir die Sachen etwas zu vereinfachen,
aber ich versuche dabei, den Aufwand für die Skriptanalyse gering zu halten - weil
das ja nur ein Nebenprodukt ist, das im Spiel selbst gar keine Verwendung findet.
Und Spielfiguren und Levels würde ich höchst ungern in ASCII beschreiben wollen -
ich bin zwar sonst auch ein totaler Nerd - aber da ist mir ein grafischer Editor inzwischen
doch etwas lieber - sonst artet das Ganze einfach zu sehr in Arbeit aus.
Und ja - es gab WIRKLICH mal Zeiten, damals mit BASIC aufm KC85/4, da habe ich
Levels auf Kästchenpapier vorentwickelt und dann zeilenweise mit Zahlen in Datenzeilen
einzeln eingegeben - und auch zu C64-Zeiten hatte ich anfangs noch keine Editoren
und habe Sprites wirklich von Hand als Ziffernfolgen eingegeben.
Aber seitdem ich meine ganzen Units habe und auf PC arbeite, schäme ich mich nicht,
mir inzwischen für so etwas grafische Editoren zu bauen - auch im Hinblick darauf,
daß ja VIELLEICHT DOCH irgendwer mal mit mir zusammen an einem Projekt arbeiten
könnte - und dann würde ich auch anderen Leuten für die Entwicklung schon etwas
besseres als einen Hexeditor zumuten wollen...
zatzen hat geschrieben: Die Engine wäre dann gewissermaßen ein Player, aber kein langsamer Interpreter.
Die Mühe, einen Interpreter zu schreiben, mache ich mir nicht.
Naja, so ganz habe ich es immer noch nicht verstanden.
Geht es nur um eine "Sprache" (oder meinetwegen "steno-artigen Code"), die das
Verhalten der Figuren beschreibt oder um alles?
Ich meine: Das Verhalten beweglicher Objekte im Spiel würde ich ebenfalls immer
mit irgendeinem - wie auch immer gearteten - Skript bewerkstelligen. Ich würde dazu
aber etwas "allgemeiner" Vorgehen - das minimiert Aufwand und Speicher:
Es gibt keine Wertigkeit zwischen "Hintergrundobjekten", Spielfiguren, Feinden, Schüssen,
Boni usw. Alles würde durch die gleichen Routinen animiert und durch andere - aber ebenfalls
gleiche - Routinen dargestellt werden. Die Objekte erhalten dann lediglich einen Typ, der
definiert (bzw vereinfacht), wie bei Kollisionen zu reagieren ist - z.B. gar nicht (bei Hintergrund-
Objekten) oder per Explosion einer der Figuren etc.)
zatzen hat geschrieben: Ich würde die Engine vielmehr für mich machen, um überhaupt einmal ein neues
Spiel hinzubekommen. Es ist für mich strukturierter wenn ich das Coden der Engine
und die Erschaffung der Spieledaten (Sprites, Samples, Hintergründe) und die
Definitionen oder Scripts (die ich lieber als Parameter halten würde, aber man
muss sehen ob das geht) trenne.
Naja, wie gesagt: Das trenne ich ja ebenfalls. Inzwischen baue ich so größere Sachen eher
modular auf, d.h. die einzelnen Bereiche sind voneinander getrennt und höchsten durch eine
Art "interne Softwareschnittstellen" verbunden.
zatzen hat geschrieben: Eine GUI kommt für mich nicht in Frage, das wäre ja hinterher mehr Aufwand
als die Engine selbst. Aber daher eben dann alles in Text bzw. Definitionsdateien
definieren.
Naja, die Eingabe der Befehle für das Figurenverhalten für GameSys2 erfolgt z.B. über so
ein Textfile. Da kann ich einen beliebigen Editor nehmen. (Ich nehme z.B. den von Pascal,
weil der ja sowieso schon da ist. Damit schreibt man eben den "Quelltext". Ein Kommandozeilen-
Tool (GS2ASM) compiliert/"assembliert" das Ganze dann zu GS2-Bytecode. Und nur der wird dann
auch im Spiel verwendet.
Meine Sprites werden auch in einem speziellen Format für die Verwendung im Spiel gespeichert.
Außerdem kann man bis zu 16 verschiedene "Segmente" definieren, die Sprites enthalten. So
kann man z.B. nur Segmente "einblenden", die auch wirklich gerade gebraucht werden - also
z.B. Nachladen von HDD, oder ein-/ausblenden aus XMS.
zatzen hat geschrieben: Technisch wären die Spiele dann alle gleich, das stimmt schon.
Das stört mich aber wenig, da ich ersteinmal ja nur ein Spiel überhaupt erschaffen will.
Und dann könnte es doch ohne weiteres einen zweiten oder dritten Teil geben.
Naja, es kommt darauf an, wie viele Features man ermöglicht.
zatzen hat geschrieben: Überraschungen würde ich in Form der Charaktere und Figuren einbauen, ich bin nicht
derjenige der ein Spiel erschaffen will das besonders schwer zu durchzuspielen ist,
sondern ich ziele mehr auf Unterhaltung ab und man würde eher alles mögliche
ausprobieren und erkunden können als immer nur linear über alle Hürden und Gefahren
hinweg rasen zu müssen.
Ach, auch in normalen 2D-Arcade-Spielen kann man Zeug mit viel "Erkunden" bauen.
(Man denke nur an Turrican...)
Wie linear/nichtlinear man das Ganze werden lassen will, entscheidet man am Ende ja
selbst. Levels müssen nicht "schlauchförmig" angelegt sein.
Man sollte beim Versuch, das "tollste Spiel des Jahrhunderts" machen zu wollen, nur ab
und zu einen Schritt zurückgehen, um sich das ganze (bildlich gesprochen) mal von etwas
weiter weg zu betrachten und zu überlegen: Ist das für eine Einzelperson zu realisieren?
Wie viele Jahre braucht man, selbst bei täglicher harter Arbeit daran, um quasi ein
"besonderes" Spiel zu machen?
Ich meine damit: Wenn ich sehe, was für einen Aufwand das Bauen von Levels, das
Erzeugen von Grafiken (Sprites und Levelelemente), das Komponieren selbst auch nur
EINER Musik - usw. erfordert, muß man sich genau überlegen, ob man bei all der Arbeit,
die das allein schon macht, noch Zeit und Ressourcen für solche "zusätzlichen Dinge" hat.
Es wäre natürlich toll, wenn es so wäre!

Mein persönliches Credo (kann jeder anders sehen) dazu ist: Erst einmal muß das Ganze
Ding selbst richtig funktionieren und aussehen und laufen wie gedacht - Sonder-Modi und
zusätzliche Gags kann man dann immer noch einbauen.
zatzen hat geschrieben: Soetwas hatte ich als 7jähriger als Vision als ich Nintendo spielte, habe mir daraufhin
Zelda angeschafft - man konnte da zwar in alle Himmelsrichtungen gehen, aber es
war trotzdem wieder nur das gleiche - terrorisierender Schwierigkeitsgrad der einen
ganz meschugge machen konnte. Sowas muss ich nicht haben.
Ja, diese Rollenspiele sind auch nicht so meins. Ich habe Zelda und ähnliches damals
auch mal gespielt (hatte sich so ergeben) - aber irgendwie kommt da bei mir auf Dauer
kein Spaß auf.
zatzen hat geschrieben: Also kurz gesagt: Prinzipiell wie ein Adventure, nur mit deutlich mehr Eigenleben,
dass alles wuselt und lebt auch wenn man mal nicht klickt. Also quasi mehr Echtzeit
und weniger nach dem Prinzip "jede Handlung einzeln anschieben". Und mehr oder
weniger 2D genügt mir da, auch bei den meisten Adventures kommt die Skalierung eher
selten zum Tragen. Musst mich hier verstehen, ich will ZVID auch für Sprites anwenden
weil es einfach schön ist wenn ein kompletter Sprite-Satz nur 1KB groß ist.
Ja, kommt auf die Spritegröße/Farbtiefe an, nicht wahr?

Zusätzlich zu den Spriteformaten, die ich derzeit nutze (8-Bit und 4-Bit, beide
palettenfähig) hatte ich letztens schon wieder neue Ideen, die von einem meiner
Bildformate stammen und eigentlich für einen mehrfarbigen Zeichensatz gedacht waren.
Das Ganze geht dann schon eher in die Richtung GIF.
Das Problem, das ich dabei sehe, ist, daß ich dadurch die Fähigkeiten der Sprites leider
einschränken muß: Skalieren, spiegeln und drehen in 90° Schritten ginge immer noch,
aber drehen in 256 Schritten (so wie meine derzeiten Sprites), sowie Dithern müßte ich
dann weglassen - weil ich sie dazu wieder zur Anzeige vollständig entpacken müßte - und
dann wäre ja der Effekt, daß sie so wenig Speicher verbrauchen weg. Allerdings gibt es
ja durchaus viele Situationen, wo Sprites eben sowieso NICHT gedreht werden müßten,
und für diese wäre das dann ideal.
Achja, ich habe so viele Ideen - wenn ich nur mehr Zeit hätte...
Auf der Arbeit mache ich am Computer total stumpfsinnige Dinge mit langsamen
Programmen - zu Hause programmiere ich in Maschinencode...
zatzen hat geschrieben: Seit einigen Jahren schwebt mir das einfach vor, dass ich ein Spieleformat habe
wie ein Modul, so dass man es auch allgemein als Dateiformat beschreiben könnte.
Sicherlich nicht jedermann's und auch nicht deine Sache, und möglicherweise wird
mein Versuch scheitern, andererseits, wenn ich richtig liege und soetwas machbar
ist, könnte das betont strukturierte Vorgehen die Sache erleichtern und beschleunigen.
Bis jetzt "kapiere" ich jedenfalls nicht, warum das nicht gehen sollte. In einem Spiel
habe ich Objekte, und diese Objekte kann ich mit Parametern deklarieren... uswusf...
Ja, prinzipiell ist es das, was jeder macht/machen würde, der schon eine Weile Spiele
programmiert. Und es ist auch sehr ähnlich zu dem, was ICH so mache.
Die Verwaltung/Steuerung/Speichermanagement der Figuren unterscheidet sich intern
nicht wesentlich von einer interaktiven Datenbankverwaltung - und genau so
funktionieren meine Figuren ja auch.
zatzen hat geschrieben: Nochmal weiter technisch, vielleicht genügt es wenn man bei der Definition von
begehbaren Bereichen auch ein 8x8 Pixel Raster nimmt. Oder wenigstens 4x4.
Selbstverständlich. Und außerdem muß das ja nicht in 8-Bit erfolgen. Geht es nur
um "begehbar/nicht begehbar", würde ja auch schon 1 bit reichen. Das Ganze dann
nochmal auf einen 8x8 Pixel Bereich - schon sind wir bei 320x200er Auflösung bei
nur 1000 Rasterkästchen (zu je 1 Bit), also 125 Byte. Das ist ja quasi nix...
zatzen hat geschrieben: Wie auch immer... Wenn du die SCUMM Engine auch als etwas betrachtest, was immer
gleich aussieht, dann kann ich damit leben.
Naja, die Macher der Scumm-Engine haben es trotzdem hinbekommen, daß das
"Interface" NICHT immer gleich aussehen muß. Daß man auch mit einer ODER mehreren
Figuren Spielen kann - und sie haben die Engine abwärtskompatibel immer erweitert.
Ich liebe z.B. dieses iMuse System - gerade bei Monkey Island 2 auf Mélêe Island, zu
Anfang in Woodtick (diesem Dorf aus Schiffswracks) wo sich die laufende Musik jeweils
der jeweiligen Lokation anpaßt mit weichem Übergang... Das ist faszinierend.

zatzen hat geschrieben: Ich kann auch gut nachvollziehen dass einem gerade im Action Bereich schnell langweilig
wird wenn es technisch immer das gleiche Spiel ist, also immer die gleichen Abläufe
nur mit anderen Grafiken.
Ja, natürlich - genau so ist es. Ich beziehe mich aber vor allem auf die in letzter Zeit
wie Pilze aus dem Boden schießenden "Game-Maker" Spiele die im Internet auftauchen:
Nichtmal die Grafiken dafür werden selbst erstellt, sondern aus einem Pool von fertigen
Grafiken genommen. Quasi alles in dieser Zelda-Optik - nur halt jeweils mit anderer,
oft sehr dünnsinniger "Story" dazu... Und meistens dann auch noch fehlerhaft geskriptet,
so daß man, wenn man sich WIRKLICH mal auf so ein Spiel einläßt, nach einer Weile
frustriert ist, weil man feststeckt, es nicht weitergeht oder irgendein logischer Fehler
in der Story ist, die verhindert, daß man weiterkommt.
Also: Selbst WENN man einen Game-Maker benutzt, sollte man da trotzdem mit ein WENIG
technischem und logischem Verständnis an die Sache herangehen... Und es ist - durch die
schiere Fülle deratiger Spiele, die seit einigen Jahren ds Netz füllen, schier unmöglich
geworden, die guten von dem ganzen Schrott zu unterscheiden. Und: Hier ist nicht nur
das Spielprinzip immer sehr gleich oder ähnlich (und die Menüs ja sowieso) - sondern hier
sind sogar die Grafiken irgendwo... "zusammengeklaut" bzw aus vorgefertigen Elementen
genutzt.
Und ja, auch mit so etwas KANN man ja durchaus etwas Gutes zustandebringen - nur:
Wenn alles andere (Engine, Grafik, Sounds, Steuerung, Menüs, Optionen) schon von anderen
vorprogrammiert sind - dann ist die STORY das einzige, worin sich diese Games unterscheiden.
Und wenn selbst diese dann totaler Mist ist oder unlogisch oder unlösbar - was soll ich dann
davon halten?
zatzen hat geschrieben: Aber bei Spielen wie Adventures kommt es ja gerade auf die Grafiken an und auf die
Story die damit erzählt wird, und dass seit Ende der 80er immer nur von der fast gleichen
Engine Sprites von A nach B bewegt werden stört niemanden.
Naja, daß Adventures Grafiken haben, ist auch nicht immer schon seit Anfang so. Die ersten
Adventures waren reine Textadventures. Später kamen dann Grafiken dazu, die zumindest
die jeweiligen Orte als Bild angezeigt haben. (Textadventures und diese mit Orten waren oft
wie ein "Raster" aufgebaut, mit Nord/Süd/Ost/West, ggf. manchmal noch mit Oben/Unten.)
Die Point&Click Adventures, die eine Weiterführung der obengenannten Idee sind, also, daß
man die Texte nicht mehr eingibt, sondern aus Befehlen und angeklickten Gegenständen /
Personen zusammensetzt - das war dann eine Erfindung von Ron Gilbert & Co., die,
angefangen mit Maniac Mansion, immer weitere solcher Spiele mit dieser Engine gemacht
haben. Und: Wie man sieht: Wenn man es gut macht, ist es kein Problem.

Es geht ja auch überhaupt nicht darum, daß immer die gleiche Engine genutzt wird - weder
bei Actionspielen, noch bei anderen. Es geht nur darum, daß außerhalb einer Engine auch
noch andere Dinge existieren, wodurch sich die Spiele eben unterscheiden. Generaisierte
Game-Maker schränken diese Möglichkeiten eben nur etwas ein - das ist es nur, was ich
damit sagen will. Und - auch wenn das nicht so sein MUß - sie verleiten leider oft dazu,
daß uninspirierte Leute, die sich scheuen, auch etwas eigene Arbeit in ein Spiel zu stecken,
mit solchen Makern einen riesigen Berg von totalem Mist produzieren.
Das ist leider ganz natürlich. Denn Leute, die über die eigene Arbeit reflektieren müssen,
die auch mal nachdenken müssen, ob etwas storymäßig oder technisch überhaupt Sinn macht,
werden die besseren Spiele bauen. - Natürlich mal ganz abgesehen von den von Dir und mir
erwähnten Ressourcenkiller-Spielen, die mit der Prämisse "Hauptsache funktioniert irgendwie"
zusammengemurkst wurden (die "kleine hüpfende Kugel braucht Quadcore mit 2 GB Speicher" -
Spiele)
zatzen hat geschrieben:Hehe, ja Kotzman II.
Derjenige der da spielt bin ich. Vielleicht merkt man bei Spielen von sich selbst nicht, dass die eigentlich
schwierig sind und schraubt dann das Nadelöhr so eng dass man sich kaum noch Fehler erlauben kann.
Im Video ist das aber die richtige Geschwindigkeit.
Ja, so geht es mir bei XPYDERZ. Ich selbst finde das Ding ziemlich einfach - habe schon überlegt, ob man da nicht etwas am Schwierigkeitsgrad drehen sollte. Aber andere Leute - und zwar solche, die in 3D-Kriegsballerspielen die totalen Helden sind - haben sich mit diesem einfachen 2D-Dings schwergetan. Das fand ich schon merkwürdig.
zatzen hat geschrieben: Die komische Tastaturberbelegung kommt aus einer "Empfehlung" von dem Buch "Spiele programmieren mit QBasic"...
Da hat man sich auf die Tastaturstatusbytes berufen weil es innerhalb QBasic wohl nicht so einfach war den Status der einzelnen Tasten des gesamten Keyboards abzufragen.
Ja, mein erstes PC-Spiel hat auch viel mit diesem Statusbyte gemacht - und weil ich gesehen hatte: Aha, Shift-Tasten und dann noch Tasten, die kein "Zweit-Byte" erzeugen (wie Enter und Space), da hatte ich gleich den Gedanken, wie das wohl programmiert war - und hatte recht. Daher konnte ich da auch relativ einfach eine freie Tastenbelegung "drumherum bauen" - intern werden an das Spiel ja die originalen Tasten gemeldet.

zatzen hat geschrieben: Ich wusste damals sehr wenig und konnte auch keine transparenten Sprites darstellen, und ich habe auch nichts mit Puffer gemacht: Alle Sprites haben einen schwarzen Rahmen und bewegen sich immer nur einen Pixel, so dass sie nichts ausser schwarz hinter sich zurücklassen. Allein deswegen würde ich gern mal ein komplettes Spiel neu machen. Aber auch, weil diese 08/15 Gänge-Jump&Runs irgendwie nicht so super sind.
Ja, wie gesagt. Falls Du mal das TGAME.EXE, was ich vor einer Weile hochgeladen habe, gesehen hast - das verwendet meine Sprites, meine Level-Engine (beides Unit ARCADE01) und meine Spielfigursteuerung nebst automatischer Kollisionsabfrage (Unit GS2 = GameSys2)
Vielleicht lade ich die aktuelle Version davon nochmal hoch. Arcade01 erlaubt ja auch mehrere Level-Ebenen. Ich habe da jetzt einen Umschalter eingebaut, der auf 2 Ebenen schaltet - so daß die Wolken auf der Hintergrundebene dargestellt werden (und langsamer scrollen als die Spielebene)-
zatzen hat geschrieben: Da sieht man mal wieder welch tolle Möglichkeiten man mit DOS hat...
Klar kann es sowas wie Tasten abfangen(?) auf in Windows geben, aber da muss man sich wahrscheinlich
erstmal durch die dicke Bürokratiewand hämmern.
Naja, in Windows gibts dafür Bibliotheken und Treiber. Da geht das sicher auch irgendwie. Aber wie Du schon sagtest: Auch mir machts keinen Spaß, mich durch einen Wust von einzubindenden APIs zu wühlen und immer nur "zu benutzen, ohne zu wissen, wie es wirklich funktioniert". Und am Ende sind es dann immer schon Programme mit 1 MB, die im Prinzip kaum mehr können, als "Hallo Welt" auszugeben...
zatzen hat geschrieben: Den Starter kannst du mir gerne zukommen lassen, interessant wäre natürlich auch der Code.
Naja, der "Code" ist quasi 100% Pascal, ich habe da auch eine meiner Units benutzt, da müßte ich das dann mal direkt in das Programm tun.
Meine Art, Sourcecode zu schreiben, gefällt aber nicht jedem - ich neige dazu, vieles auf eine Zeile zu
schreiben und ich rücke auch nicht IMMER alles ein und so. Der Starter war nur ein kleines Ding, das ich mal schnell in einer Stunde oder so zusammengepfriemelt habe.
zatzen hat geschrieben: Ansonsten, wie ich schon schrieb, spiele ich selten, auch meine eigenen Sachen, und ich hab
mich an die Steuerung bei Kotzman gewöhnt.
Ja, ich komme da immer etwas durcheinander.
zatzen hat geschrieben: Naja, ein bisschen komisch, diese Gestalten Kotzman und Saugi kommen aus so Zeichnungen die
ich vielleicht so mit 12 angefangen habe in der Schule aus Langeweile zu zeichnen.
Ja, ich dachte mir schon sowas. Die Spiele sind ja auch schon recht alt.
zatzen hat geschrieben: Das ganze Spiel ist unüberlegt und eher drauf los programmiert, weil ich damals eher schnelle
Ergebnisse wollte als ein gut durchdachtes Dingen - aber irgendwie ging es auch nicht anders,
erstmal hatte ich nur QBasic unterm Arsch und einfach zu wenig Erfahrung.
Ach, da solltest Du mal MEINE ersten Spiele sehen... Wenn ich daran denke, fällt mir nur ein: Auweia...
zatzen hat geschrieben: Eine kleine Sache kann ich aber erzählen:
Bei den Cutscenes ging BASIC damals der Speicher aus.
Zu viel Programmcode.
Da musste ich mir was einfallen lassen und habe die Cutscene in einem neuen Programm geschrieben,
Grafik- und Textausgabebefehle in Codes verpackt, auch die, die eine Datei neu laden (so eine Szene musste man ja auch über mehrere Grafikdateien verteilen) das ganze in einen String gespeichert und den
dann im Spiel geladen und als Steuerung genommen. FRA hab ich's glaub ich genannt (Frankus Animation).
Ja, so etwas ist doch ziemlich gut. Und auf diese Art lernt man gleich, wie man es "gleich richtig hätte machen sollen". Eine Animation sollte ja auch nicht "hardcoded" ins Programm getackert werden, sondern immer eher aus abgespielten Daten bestehen.
zatzen hat geschrieben:Ich hab noch eine Frage an dich (ich bekomm grad richtig Lust langsam mal in die Gänge zu kommen mit dem Spiel):
Wie machst du das mit dem Hotspot bei Sprites?

Der VGA-Puffer zählt ja von oberster Linie und Pixel null bis unten rechts 63999.

ZVID ist genauso angelegt.

Ich habe einfach zu lange nichts mit Sprites programmiert bzw. zuletzt einfach nur gesehen dass Y einen
bestimmten Wert nicht überschreitet (Level war nur eine Ebene am Boden), und Kollisionen habe ich einfach
z.B. bei Kotzman II, da alle Objekte gleich groß waren, durch den absoluten Abstand voneinander bestimmt.
Ja, dazu muß ich sagen, daß ich da einen anderen Ansatz verfolge.
Also:
1.) Es gibt keinen "Bildschirm" oder so. Es gibt nur ein Level und es gibt eine Routine, die einen Ausschnitt des Levels auf dem Bildschirm darstellt. Das liegt bei mir daran, daß meine Levels generell scrollen.
2.) WEIL meine Levels scrollen, wird ständig das komplette Bild aktualisiert! D.h. hier ist eine schnelle "zeichne das Level auf den Bildschirm" Routine notwendig, damit das auch schnell genug passiert.

Kleiner Exkurs:
Und ja, in alten Spielen hat man das nicht so gemacht - und auf dem C64 erst recht nicht, weil das die Power nicht ausreichte. Da hat man es so gemacht, daß man die Scrollregister benutzt (die den Bildschirm um 0-7 Pixel verschieben können - gibts beim PC übrigens auch!) und dann das Level "rüberkopiert" und zwar so, daß der Rasterstrahl "nichts davon mitbekommt" (also immer "vor dem Rasterstrahl her - oder mit 2 Bildschirmen) und nur die neue Spalte/Zeile oder beides außen anfügt. Kleiner Nachteil: Wenn man irgendwelche beweglichen Objekte auf dem Bildschirm hatte, die keine Sprites waren - auf C64 wurden für Schüsse oft auch "Zeichen" genommen (die meisten Spiele auf C64 sind mit verändertem Zeichensatz, nicht mit Vollgrafik) und mußte diese dann gesondert berücksichtigen.


3.) Sprites werden dann also im Bezug auf das (verschobene) Level dargestellt. Bei scrollenden Levels zentriere ich den Levelausschnitt auf die Hauptfigur - natürlich so, daß bei den Levelrändern die Grenze ist. Man kann hier auch eine "lose Zentrierung" machen - sieht man bei Mario ganz gut - da wird ein "inneres Rechteck" genommen und erst wenn die Figur dieses verläßt, wird gescrollt... naja und so weiter.

4.) Nun zu den Hotspots:
Sprites haben bei mir generell nur zwei Koordinaten. Und das Sprite wird dann an diese Koordinaten dargestellt - VERSCHOBEN UM DEN HOTSPOT.
Wie geht das? Nun - ein Sprite ist ein Image, also ein Bild, das irgendwo im Speicher liegt, mit Breite/Höhe/Farbtiefe, was auch immer - und es gibt eine Routine, die es darstellt. Um ein Sprite darzustellen, greift die Routine erstmal NICHT direkt auf das Image zu, sondern auf einen Datensatz, der das Image beschreibt, dieser besteht aus:

* OFFSET
Das ist die Position, wo das Image des Sprites im Speicher liegt, d.h. wo der erste Pixel anfängt.
* WIDTH (Breite)
Das ist die Breite des Images.
* HEIGHT (Höhe)
Das ist die Höhe des Images.
(Ja, jedes Sprite ist erstmal ein "Rechteck", ich erkläre noch, die man die "rund" macht.)
* HOTSPOT-X
Das gibt an, welchen Abstand von der linken Kante des Rechtecks der Hotspot hat.
* HOTSPOT-Y
Das gibt an, welchen Abstand von der oberen Kante des Rechtecks der Hotspot hat.
(Anders ausgedrückt: HOTSPOT-X und HOTSPOT-Y sind zwei Koordinaten, in einem gedachten Koordinatensystem, das über das Sprite-Rechteck gelegt ist, mit der linken oberen Ecke als Nullpunkt.)
* FLAGS
Das gibt verschiedene Daten zur Darstellung an, das kann man, muß man aber nicht haben. Bei meinen Sprite-Images hat es z.B.:
Ein Bit, das angibt, ob das Image ein 4-Bit oder 8-Bit-Image ist.
Ein Bit, das angibt, ob das Image eine interne Palette mitbringt oder nicht.
Ein Bit, das angibt, ob das Image außer der "Volltransparenz" auch noch "Teiltransparenz-Pixel" enthält.
(Eigentlich wäre das nicht wichtig - aber so habe ich zwei Vorteile: 1.) Dementsprechend kann die Subroutinen-Schleife zur Darstellung gewählt werden - d.h. wenn keine Teiltransparenzpixel enthalten sind, braucht nicht die Routine ausgeführt werden, die darauf testet! 2.) Ich kann in diesem Fall die Teiltransparenz-Pixel, die ja bei Darstellung mit Teiltransparenz gar keine eigene Farbe haben, zusätzlich mit Vollfarben nutzen.)
Drei Bits, die angeben, ob das Image X-gespiegelt, Y-gespiegelt oder 90°-gedreht im Speicher liegt.
(Das ist deshalb wichtig, weil ich damit mehrere Images an dieselbe Stelle legen kann - oder ein Sprite drehen kann, damit es besser in "freie Löcher" im Sprite-Image-Raster paßt. - Bedingt durch die besondere Art wie ich Spriteimages speichere.)
Zwei Bits sind noch nicht belegt - reserviert für andere Farbtiefen oder andere Optionen.

Wie wird so ein SpriteImage dargestellt?
Die Routine erhält den Befehl, das Image an Position X;Y im Bild darzustellen. Also nimmt sie das Image, subtrahiert von der Position X den HOTSPOT-X und von der Position Y den HOTSPOT-Y und dann stellt sie das Image dar.
Im "Normalfall" ist dieser Hotspot also im Schwerpunkt (in der Mitte) des Images. Ich finde aber eine Option, diesen selbst zu bestimmen besser. Nehmen wir die Geschütztürme von Xpyderz. Diese sind rund, haben aber ein Kanonenrohr. Also wäre die Mitte ja nicht genau in der Mitte des runden Teils, sondern irgendwo in Richtung Kanonenrohr, weil die Mitte des Rechtecks um dieses Konstrukt ja da wäre. Es ist aber praktischer, die Mitte genau in die Mitte des Turms zu setzen, dann kann man diesen genau auf diese Koordinaten setzen um um diese drehen.

(wieder kleiner Exkurs:
Ganz so einfach ist es in meinem Fall nicht, wegen der ganzen Optionen. Also in Wirklichkeit: Wenn die X-Mirror/Y-Mirror/Turn90° Flags gesetzt sind, werden die Adder für die Pixeldarstellungsschleife natürlich entsprechend invertiert/getauscht. Außerdem können meine Sprites ja auch in 256 Winkeln gedreht werden, d.h. da errechne ich die 4 Eckpunkte (eigentlich 3) des gedrehten Rechtecks. (Ja, natürlich mit Sinustabellen! Bin ja nicht bescheuert und benutze hier Sinusfunktionen für Spritedarstellung, das wäre ja langsam.)
Und dann pixle ich das Sprite senkrecht (es ginge auch waagerecht, aber für Mode-X ist senkrecht effizienter, weil man dann nicht so oft die Plane wechseln muß).
D.h. entsprechend dem Winkel ergeben sich so Adder (Addierwerte), um die ich die Position im Image erhöhe/vermindere und immer dann pixle ich den Pixel, den ich an der momentanen Position finde.
Auf diese Art kann skaliert UND gedreht werden.)


Wie werden Rechteck-Sprites tigerförmig?
Als man Michelangelo mal fragte, wie er se schafft, aus so einem Marmorquader so etwas wie einen Tiger zu machen, sagte er: "Es ist ganz einfach: Ich schaue mir erst diesen Marmorblock an - und dann haue ich alles weg, was nicht nach Tiger aussieht."
Genauso macht man es mit Sprites. Man definiert einfach eine "Farbe", d.h. einen Bytewert, der als "transparent" gelten soll. Und immer wenn man beim Pixeln der Punkte, aus denen das Sprite besteht, auf einen mit diesem "Farbwert" trifft, pixelt man einfach nicht! - Fertig.
Natürlich wäre man schön blöd, nur um immer gleich große Sprite-Rechtecke zu haben, selbst um einen winzigen Sprite ein riesiges Rechteck voller "leerer Pixel" zu definieren. Das geht zwar, ist aber schlecht für die Abarbeitung, da viele sinnlose Vergleiche stattfinden.
Besser ist hier, das Rechteck um das Image so eng wie möglich zu definieren, also daß der oberste, linkeste, rechteste und unterste Pixel des Images direkt auf den Kanten des Rechtecks sind und nur den ganzen Rest dann mit "leeren Pixeln" (also mit Bytes/Nybbles etc der "Transparenzfarbe") zu füllen.
Und ja, dadurch hat man eine Farbe weniger für das Image.

Reden wir also noch von Paletten:
Es gibt einmal die normale Farbpalette, nehmen wir als Beispiel eine VGA-Palette mit 256 Farben (natürlich selbst durch schönere Farben geändert, klar!)
Jetzt KANN man ein Image ohne eigene Palette definieren - das bedeutet: Jeder Pixel hat einen Wert zwischen 0 und 255 und wenn man den Pixelwert in den Videospeicher legt, erscheint dort diese Farbe.
Dazu braucht man dann 8-Bit-Sprites.
Man kann aber auch zusätzlich für jedes Sprite Paletten-Nummern definieren! Diese Paletten bestehen aus Bytes, die dann erst der Index auf die richtige Farbe sind.
Zwei Beispiele, wieso das nützlich ist:
1.) Man nehme ein Sprite-Image (oder mehrere), die eine Person darstellen, in verschiedenen Bewegungsphasen. Person hat blaugelben Pullover, braune Hose, weiße Schuhe, blonde Haare, hellrosa Haut. Mit einer solchen Palette, die den Bytes einfach andere Farben zuordnet, kann man daraus eine schwarzhaarige Person mit brauner Haut, grüner Hose, rotweißem Pullover und blauen Schuhen machen...
Man kann den Pullover dann auch einfarbig machen, indem man einfach beiden "Farben" (Bytes) in der Palette den gleichen Wert zuordnet.
2.) Hat man 4-Bit-Sprites (wie ich sie oft und gern benutze, da sie den Platz für ein Image halbieren!), so ist eine Palette sowieso das beste Mittel. In diesem Fall kann man einfach 16 Farben irgendwo aus der 256-Farb-Palette definieren, die dieses Image haben soll (und auch hier sind mehrere Paletten durchaus möglich, um es in verschiedenen Farbkombinationen zu haben). D.h. man erhält bei der Pixelsuche zunächst erst einmal einen 4bit-Wert, verweist mit diesem auf eine 16-Byte große Tabelle (Palette) und das Byte, das aus dieser dann geholt wird, ist die Farbe, die dieser Pixel erhält.
Ein Beispiel: Die kleinen farbigen Spinnen in XPYDERZ verwenden diese Technik: Es sind nur 4 Bewegungsphasen EINER Spinne, aber es gibt 8 verschiedene Farbpaletten dafür...

Achja: Ich habe schon zu Zeiten von Xpyderz ein Programm geschrieben, das aus einem Bild die entsprechenden Images "ausschneidet" und im Sprite-Format abspeichert. Gleiche Images oder welche, die gespiegelt/gedreht aufeinander passen würden - oder solche, die nur andersfarbig sind, aber ebenfalls aufeinanderpassen, werden dabei (auf Wunsch) als nur ein einzelnes Images gespeichert - eben mit den bekannten Flags.

Ich habe mich immer bewußt dafür entschieden, daß die Paletteninformationen NICHT Teil der Definition der Sprite-Images ist - um hier möglichst frei entscheiden zu können.
Wir kennen doch diese Szene: Der Held/das Raumschiff ballert auf den Endgegner und immer, wenn der "wunde Punkt" des Endgegners getroffen wird, blinkt der ganze Gegner kurz weiß auf. Will man dafür wirklich eine weiße Version des Gegners pixeln? (zumal diese ja oft recht groß sind, daher viel Platz verbrauchen).

Ja, ich weiß, das ist sehr viel Gelaber auf einmal. Ich entwickle ja auch schon seit Jahren an 2D-Spielen herum. XPYDERZ ist eines der Ergebnisse dieser Bemühungen.
Anfangs hatte Xpyderz übrigens viele Dinge nicht, die später dazukamen:
a) zu Anfang wurden die Images von Xpyderz direkt in Pascal dargestellt und recht ineffizient gepixelt.
b) zu Anfang hatten die Images keine Paletten, jedes Image wurde extra gespeichert.
c) zu Anfang hatten auch die Levelblocks keine Paletten, ein Block brauchte 1 kByte.
d) und das alles, obwohl zu Anfang das ganze Spiel noch 16-farbig war, also nur die ersten 16 Farben der VGA-Palette benutzt hat.
e) es gab noch keine "Kollisionsmatrix" - aber bei bis zu 1600 beweglichen Objekten im Level (die auch aufeinander reagieren können, wenn sie Off-Screen sind!) überstieg die Abfrage "Kollision alles mit allem prüfen" bei weitem jede mögliche Rechnerleistung.
alles von a) bis e) wurde inzwischen bereinigt. Die Sprites sind jetzt alle WIRKLICH 16-farbig - aber eben 16 aus 256 Farben pro Sprite. Gleiche Images, die nur unterschiedliche Färbung haben, werden nicht mehr doppelt gespeichert. Die Blocks brauchen jetzt nur noch 0,5 kByte an Speicher, plus 16 Bytes für die jeweilige Palette. Alles performt mehr, sieht besser aus und braucht zusätzlich auch nur noch den halben Speicher - das kommt davon, wenn man sich über all diesen "technischen Kram" ein wenig Gedanken macht.

XPYDERZ hat eines noch nicht: Es nutzt nicht GameSys2 (das gab es damals noch gar nicht) - die ganzen Bewegungsabläufe und Reaktionen sind alle quasi "hardcoded", d.h. sind direkt in Pascal programmiert - da will ich auch gar nicht absprechen, daß da bestimmt einiges doppelt gemacht ist, was nicht sein müßte. Besser wäre hier natürlich ebenfalls der Einsatz von Routinen wie GameSys2 gewesen, der typenbasiert auf verschiedene Ereignisse mit Tabellen reagieren kann - das verringert den Aufwand, minimiert Fehler und vor allem: Es können neue Figuren/Waffen/Boni/etc hinzugefügt oder vorhandene geändert werden - ohne etwas am Programmcode der *.EXE zu ändern!

Und ja, ich weiß: Alles, was ich da so habe, sieht schon verdammt nach "daraus könnte man einen Game-Maker bauen" aus. Mich stört nur der Aspekt dabei, daß das Ganze dann dazu führt, daß "weil es ja geht", sich keiner mehr Gedanken darüber macht, wie es "am besten geht", sondern so unperformante Sachen damit macht. Also wieder Zeug, das zuviel Speicher braucht (weil zu faul, Farben auf Paletten zu reduzieren), Kollision bei alles auf alles testen (obwohl gar nicht nötig, weil ja Typisierungen und Kollisionsmatrix vorhanden) und so weiter. Und daß man aus Faulheit/Unvermögen selbst mit recht effizienten Mitteln immer noch ineffizienten ressourcenvernichtenden Müll produzieren kann, ist kein Geheimnis. Aber ich will nicht die Mitschuld daran tragen...

So ist es genau mit dem neuen ISM (die "Musik-Unit") :
Eigentlich, auf Grund von immenser Speicherersparnis, ist sie hauptsächlich darauf ausgelegt, digitale Klangsynthese zu betreiben, indem sie quasi wie ein "SID" benutzt wird - und in Ausnahmefällen dann auch die zusätzlich vorhandene Option genutzt wird, sparsam Samples einzusetzen. Aber ich fürchte, in Wirklichkeit wird es wieder dazu kommen, daß die Musiken/Effekte aus Bequemlichkeit ausschließlich aus riesigen, sekundenlangen Samples zusammengebaut wird, so daß für Grafik und Code kaum noch Speicher bleibt oder ständig zeitraubende XMS-Copy-Akrobatik betrieben werden müßte.

D.h.: Ja, ich habe hier schon recht "brauchbare" Dinge über die Jahre zusammengezimmert. Leider wird man sich aber auch auf deren spezielle Funktionsweise etwas einlassen müssen, um damit dann WIRKLICH etwas Tolles zustandezubringen! Was nützen effiziente "Hacks", wenn sie dann keiner nutzt, sondern alles nur "ungepackt auf die Maschine schmeißt"?
Und ja, es wäre auch möglich, zusätzlich noch Programme dem "Daten-Compiler" vorzuschalten, die solche Sachen automatisch "effizienter macht". Aber erstens wäre das wieder ein gewaltiger Aufwand meinerseits, der nur dazu dient, daß Entwickler NOCH fauler werden und NOCH weniger lernen bei dem, was sie tun und zweitens kann selbst der beste automatisch arbeitende Code nicht wirklich einen schlauen Menschen ersetzen, der sich da auch manuell um Effizienz bemüht.

Ich sage es mal so: Die Dinge, die ich hier baue, baue ich natürlich auch in erster Linie zur Benutzung durch mich selbst - aber ich hätte auch kein Problem damit, mal mit jemand anderem zusammen an so Projekten zu arbeiten - daher ist das Ganze auch oft etwas "benutzerfreundlicher" gestaltet, als es nur für mich selbst sein müßte. Nichtsdestotrotz bedeutet Spieleentwicklung aber trotzdem noch Arbeit (auch wenn es Spaß macht!) - und wer das überhaupt nicht verstehen kann und will, wird mit meinen Tools und Units wohl eher keine Freude haben.

Gute Computerspiele haben immer einen Vorteil, der gleichzeitig ein Nachteil ist:
Der Vorteil:
In einem guten Computerspiel merkt man gar nicht, wie komplex das alles intern ist - es sieht alles ganz einfach und geschmeidig aus! Für den Spieler soll es das ja auch! Das macht ein gutes Spiel ja aus - daß man nicht mehr daran denkt, daß da eigentlich bloß ein blöder binärer Rechenknecht namens CPU im Hintergrund nichts anderes tut als die ganze Zeit langweilige Zahlen durch die Gegend zu schieben.

Der Nachteil:
Für "zukünftige Entwickler" - also Leute, die das alles sehen und daraufhin mal selbst ein Spiel programmieren wollen, ist das aber eher ein Nachteil: Weil eben alles so "einfach und geschmeidig" aussieht, entsteht dadurch der Eindruck, daß Programmieren und Spiele-Entwicklung etwas total einfaches ist. Im Sinne von: Ich tu den Sprite dahin und schon macht er, was er soll. Der macht von selbst Geräusche und wenn er explodiert, macht's von selber BUMM! Und wenn der sich durchs Level bewegt, schiebt sich das Level so schön über's Bild... das ist ja alles ganz easy... Naja, irgendwer muß aber die ganze Grafik pixeln/konvertieren. Irgendwer muß die Subroutinen schreiben, die die Grafik darstellt und die Sounds und Musiken abspielt - oder dafür sorgen, daß Geräusche genau dann passieren wenn nötig. Irgendwer muß dafür sorgen, daß wenn man "links drückt" die Figur diesen "Linksbefehl" erhält und ihre Koordinaten anpaßt. - Aber wenn man so ein schönes buntes lautes Spiel sieht - welcher Gamer denkt da schon an KOORDINATEN? Tja - als ENTWICKLER muß man das dann aber leider!
Ich sage es mal so: Ich habe in Foren schon Beiträge von Leuten gelesen, die Fragen stellen wie: "Ich will auch mal sowas wie World-of-Warcraft programmieren - nur etwas besser. Was für Programmiersprache brauch ich dafür? Und achja, ich bin nicht besonders gut in Mathe, wäre ganz gut, wenn man dafür nicht soviel Mathe braucht. Ich habe gerade 3 Monate Ferien und würde das gerne bis zum Ende der Ferien fertig haben." --- Solche Fragen verblüffen Leute wie mich immer dermaßen, daß ich da gar nicht weiß, was oder wie ich antworten soll - wo soll man da überhaupt anfangen???
zatzen hat geschrieben:Zu ISM:

Was ich bisher gehört habe klingt charmant, die 4 Bit Soundqualität wirkt sich doch gar nicht so schlimm aus.
Schön, das von jemandem zu hören, der sich mit Sound schon etwas mehr beschäftigt hat als ich. Ich sehe das alles eher von der stumpfen mathematischen Seite und versuche nur immer, dafür zu sorgen, daß die Werte exakt sind. An mir ist wahrlich kein Komponist verlorengegangen.
zatzen hat geschrieben: Wenn ich den Screenshot vom Editor richtig verstehe, dann programmiert man die Musik regelrecht mit allen Mögichkeiten wie bedingten Sprüngen und das alles für jeden der Kanäle unabhängig. So gesehen macht das viel Sinn und führt zu kompakten Daten.
Das ist korrekt.
Auch mein erstes "Musik-Programm" auf PC folgte bereits diesem Paradigma (nur waren die Stimmen noch unabhängig voneinander, man konnte also nicht "in eine andere Stimme springen).
Das Ganze entstand, weil das einzige andere Musikprogramm, das ich jemals gesehen und auch selbst benutzt habe, dieser MVM von einem Stefan Konrath war, der das für C64 gebaut hatte. Auch dieser hatte schon Längenparameter für die einzelnen Noten. "Zu überspringende Nullen/Leerräume" kann man sich einfach nicht leisten auf einem System, in dem Code, Grafikdaten und Sounddaten zusammen in maximal 64 kByte passen müssen!
Von MOD und Ähnlichem hatte ich damals noch nie etwas gesehen oder gehört!
zatzen hat geschrieben: Aber man muss eben vorher schon genau wissen, was man überhaupt programmieren will, bei "normalen" Trackern, wo die Patterns einfach wie bei einer Spieluhr durchlaufen, kann man sehr einfach und schnell auch improvisieren. Ist mit ISM nach einiger Übung wohl auch möglich - aber so hat jeder seine Gewohnheiten.
Naja, es ist ja jederzeit möglich, Zeilen einzufügen oder zu entfernen, die Längen zu ändern usw.
Man muß das ganze Ding ja nicht von oben nach unten wie einen Text beschreiben, ohne die Möglichkeit zu haben, da später etwas zu ändern. Man kann alles auch jederzeit überschreiben usw.
zatzen hat geschrieben: ISM taugt demnach aber ebenso für eine direkte, "dumme" Konvertierung von Tracker-Daten, aber man könnte auch versuchen einen intelligenten Compiler dafür zu schaffen. Was aber, denke ich, gar nicht so in deinem Sinne wäre.
Ich habe ehrlich gesagt schon darüber nachgedacht, einen Konverter zu schreiben, der MOD (oder DMF oder was auch immer) in das ISM-Format konvertiert.
An DMF gefällt mir übrigens die Idee mit diesem Statusbyte außerordentlich. (Erinnert an die Van-Jacobsen-TCP/IP-Header Compression.) Bitweise auf eventuell folgende Daten zu verweisen (wenn 0, folgen keine) und auch mit einem Längenbyte - das ist schon einerseits sehr speichersparend und läßt andererseits trotzdem alle Möglichkeiten offen!
ISM kann da viel weniger - ich kann nicht einfach einer Note so viele Effekte gleichzeitig zuweisen.
Aber weil ich sowieso kaum musikalisches Talent besitze, wüßte ich auch gar nicht, wann und wozu ich diese alle einsetzen sollte.
zatzen hat geschrieben: Zumal man die vollen Möglichkeiten von ISM ja auch nur durch die direkte Programmierung im Programm selbst ausschöpft.
Ja, das stimmt - andere Formate haben z.B. diese "Kommunikation mit der Außenwelt" nirgends vorgesehen, ebenfalls auch keine "Entscheidungen" oder Schleifen.
Gerade Schleifen oder "Subroutinen" müßte dieser "Compiler" dann bei anderen Formaten erkennen, um es effizient umzusetzen. D.h. z.B. wenn Wiederholungen auftreten, das Ganze in eine Schleife zu verpacken.
Die Soubroutinen-Funktionen dagegen wären schon ein gutes Mittel, um die Patterns eines MOD-Files einzeln aufzurufen - d.h. am Anfang würde einfach der Sequenzer stehen.
Es gibt ja in ISM sogar eine Funktion, abhängig von der X- oder Y-Variable an eine bestimmte Stelle zu springen - UND man kann jeden Sprung durch einen Präfix-Befehl in einen CALL (also Aufruf mit Rücksprung) verwandeln. ISM hat SPEED-Befehle und die fehlenden Längenparameter in einem MOD würden sich durch das Abzählen der leeren Räume ergeben. So gesehen wäre ein Konverter MOD-zu-ISM technisch nicht so unwahrscheinlich - allerdings müßten Dinge wie das Vibrato und ähnliches natürlich entsprechend nachgebaut werden. Eigens für solche Effekte habe ich den "Hold" (HLD) Befehl eingebaut, der einen schon gespielten/angespielten Ton nochmals aufnimmt und mit den gleichen Werten - bzw eben einigen geänderten Werten - weiterspielen kann.
Der große Nachteil, den ich hier schlicht sehe, ist, daß sich alle Tracker natürlich 100%ig auf Samples stützen, so daß ich einen Klotz von Samples mitzuschleppen hätte - wo ich doch eigentlich auf Klangsynthese setzen will und Samples eher die Ausnahme sein sollen.
zatzen hat geschrieben: Meine eigene Idee und dass ich monatelang an einem Patternformat herumgedoktert habe, was letztlich sogar eine sehr effiziente Komprimierung hevorbrachte, davon habe ich ersteinmal Abstand genommen, da ich ZVID den Hauptanteil des konventionellen RAM geben und jeglichen Digi-Sound aus dem XMS holen will. Und da wäre eine komplexe Mischtechnik von Samples mit verschiedenen Tonhöhen zu rechenintensiv, ich werde da eher soetwas wie einen Mehrspur-Sequencer von jeweils u.a. auch längeren Samples machen.
Naja, OK, jeder wie er will. Das erfordert natürlich entsprechend viel XMS und jeder der nicht genug XMS hat, kann das alles dann nur ohne Sound genießen.
Ich selbst versuche da immer eher im Rahmen der "normalen DOS-Kiste" zu bleiben und da im 0-16 MB Bereich zu agieren - eher 1-4 MB XMS.

Aber es kommt natürlich auch ganz darauf an, welche Art von Spiel Dir GENAU vorschwebt. Deinen Äußerungen zufolge hast Du da bisher eher vage Vorstellungen, daß es "wie 2D Arcade, aber irgendwie mehr mit Adventure-Anteilen" sein soll.

Meine ganz persönliche Ansicht dazu ist:
Ein 2D-Point&Click Adventure hätte für mich programmiererisch einen komplett anderen Ansatz als ein Jump'n'Run / Shoot'em'up oder Kombi (wie Turrican).

Ein Adventure hätte bei mir Vollgrafiken, mit davorlaufenden Sprites. "Hinter" der Vollgrafik (also irgendwo im Speicher) gäbe es dann einen virtuellen Bereich, der verschiedene markierbare Objekte in der Grafik, sowie Wege und "Verdeckungen" klassifiziert. Objekte und Personen (die ja auch nur interaktiv-Objekte sind) wären durchnummeriert, Orte hätten der Vollständigkeit halber ebenfalls eine Nummer. Das Ganze wäre nur die ANZEIGE. D.h. Anklicken eines Befehls oder Objekts würde dann in eine Datenbank laufen, die diese Kombination sucht und dann eine entsprechende Reaktion erzeugt.

Zur Erklärung:
Es gäbe eine Art Datenbank, die für alle möglichen Aktionen eine Reaktion enthält:
BEFEHL [RAUM] OBJEKT1 [OBJEKT2 / AUSWAHLNR] -> REAKTION

BEFEHL = so etwas wie GEHE SCHAU NIMM GIB BENUTZE REDE ZIEHE DRÜCKE ÖFFNE SCHLIEßE
(Das Ganze könnte man auch etwas reduzieren, wie es bei neueren Adventures gemacht wird.)

[RAUM] = Optional. Entweder 0 (für keinen) oder Raumnummer, wenn die Aktion an einen bestimmten Standort gebunden ist. KANN man machen, MUß man nicht. Meist ergibt es sich von allein, weil das OBJEKT sich nur an diesem Standord befindet)

OBJEKT1 - das (erste) Objekt, das zum Befehl gehört.

[OBJEKT2] - optional. Für Sachen wir BENUTZE oder GIB wäre noch ein zweites Objekt entweder optional oder ganz sicher nötig. BENUTZEN kann man auch nur EIN Objekt. Aber wenn man zwei Objekte benutzt (das Objekt hätte ein Flag, das es nur zusammen mit anderen benutzbar ist), würde dann BENUTZE X mit ... erscheinen und man müßte ein zweites Objekt angeben (aus Inventar oder aus dem Bild - für die Datenbank egal wo es herkommt)

[AUSWAHLNR] würde ANSTELLE von Objekt2 stehen - für REDE könnte OBJEKT1 die Person sein, das würde automatisch eine Liste mit möglichen Fragen oder Antworten angeben, aus der man eine auswählen kann (evtl würde diese dann aus der Liste für spätere Versuche entfernt....) - und die Reaktion wäre dann bezogen auf REDE PERSONX, SPRUCHY
REAKTION wäre dann ein Beschreibungsskript, das eine oder mehrere Reaktionen ermöglicht.
Beispiel: Ein Objekt ins Inventar hinzufügen/entfernen, Eine neue Antwortliste für eine Person aktivieren (oder aus der bestehenden bestimmte Antworten entfernen) und natürlich auch Ausgabe von Sounds oder Animationen von Grafiken. Das Bild hätte außerdem eine "Briefmarken"-Option. D.h. es gäbe von dem Bild eine Grund-Grafik und dann für zu ändernde Stellen so "Sprite-Sticker", die man "draufkleben" würde, um z.B. eine Tür geöffnet oder geschlossen zu sehen oder ein Gegenstand, der später weg ist oder verbogen oder kaputt oder was auch immer.
Würde keine REAKTION definiert sein (man kann zwar für alle SINNLOSEN Aktionen auch einzeln eine Reaktion bauen - aber es macht eben auch viel Arbeit) - also gibt es keine Reaktion, würde eine Anzahl von Sprüchen wie "Das funktioniert so nicht." oder "Das macht keinen Sinn." ausgegeben werden.

D.h. ich habe schon eine SEHR GENAUE Vorstellung davon, wie ich ein Adventure programmieren würde. Das Problem ist natürlich, daß das Ganze auch sehr arbeitsintensiv ist und daß ich leider diesen JOB am Hacken habe, so daß meine ganzen Fähigkeiten und Kreativität nicht genutzt werden können und ich stattdessen den ganzen Tag eher stumpfsinnige Dinge tue, die meine Intelligenz beleidigen.

Zur Zeit habe ich Urlaub - nur deshalb finde ich überhaupt die Zeit, so eine lange Mail zu schreiben.

So, jetzt hast Du wieder eine sehr lange Mail von mir zu lesen...

Re: Eigenes Videoformat

Verfasst: Di 1. Dez 2015, 15:26
von zatzen
Ich merke gerade dass so eine Diskussion hier nicht nur dazu dient, dir meine Vorstellungen zu erklären,
sondern dass ich auch selbst überhaupt auf neue Ideen komme, da diese noch lange nicht so weit sind,
dass ich überhaupt wüsste womit ich konkret anfangen müsste.

Ein Produkt habe ich eigentlich ganz gerne am Ende, aber ich habe dabei gern auch im Hinterkopf, wie
alles aufgebaut ist und funktioniert, und ZVID war für mich auch zu einem Teil so attraktiv weil manche
kleinere Bildelemente damit so wenig speicher belegen können, dass man diese in einem HEX-Editor
noch übersichtlich nachlesen kann. Das wird ein "Gamer" wohl nicht verstehen, und vielleicht auch
mancher Programmierer nicht.
Es ist ein bisschen so als wenn man sich als Elektroniker am Schluss nochmal gerne eine eher simple
Platine ansieht. Bzw. ist es einfach "spannend", was der Compiler aus einer redundanten Grafikdatei
macht, die zuerst über mehrere KB geht und dann, im günstigsten Fall, vielleicht in ein paar hundert
Byte passt und die man per Hex-Editor Einblick auch per Hand decodieren könnte - theoretisch.

Was die Definitionen in Textdateien angeht - zuletzt habe ich die Parameter der Spielfiguren etc.
in Arrays gehalten. Und so dachte ich, man könnte ein paar Typen von Spielfiguren, Gegenständen
etc. per Arrays verwalten, und deren Ausgangswerte in den Definitionsdateien konfigurieren.
Wenn wir uns ersteinmal auf humanoide Charaktere beschränken, dann könnte man diesen verschiedene
Persönlichkeitsmerkmale geben, wie sie auf dieses oder jenes reagieren, und bei mir sollte jeder auch
ein bisschen sprechen können, natürlich nicht so viel wie bei Talkie Adventures, es muss ja alles in den
XMS passen.
Wie ich es genau angehe weiss ich noch nicht, aber normalerweise denke ich nicht in Dimensionen die
nicht realisierbar sind.
Wie ich schon sagte, es soll kein Spiel werden mit großem Anspruch an Geschicklichkeit und
Schwierigkeitsgrad, sondern eher soetwas dass sich immer wieder andere Konsequenzen ergeben
je nachdem was man tut oder nicht tut, und ein klassisches Game-Over muss es gar nicht geben.
Inspirierend dazu sind einige Spiele, Adventures wie Monkey Island, aber auch Lemmings (weil ein
stetiger Handlungsfluss besteht) und auch Worms, weil es dort manchmal zu irrwitzigen Kettenreaktionen
kommt. Sierras Incredible Machine dürfte wohl im Prinzip auch parametrisch funktionieren.
Also wäre es ein Spiel, was auch ohne Eingriff des Spielers läuft, und aber im Idealfall sensibel auf
Eingriffe des Spielers reagiert. Butterfly Effect quasi.
Ich hatte schon befürchtet dass dann soetwas wie "The Sims" rauskommt, aber ich denke bei mir würde
das schon anders werden.
Du beschreibst in GameSys2 das Verhalten der Figurentypen, ich würde das lieber parametrisch regeln,
also "Charaktereigenschaften" aus denen sich je nach Situation eine bestimmte Reaktion ergibt. Dabei
nimmt mir die Engine längere Definitionen oder Scripts ab, indem sie bei bestimmten Ereignissen jeweils
die Charaktereigenschaften auswertet und eine Reaktion bestimmt. Das kann auch etwas ganz simples sein
wie ob eine Figur beim Erreichen einer Wand umkehrt oder stehen bleibt. Aber die Charaktereigenschaften
könnten sich auch ändern, und das macht das ganze vielleicht sogar interessanter als etwas das "hardgecodet" ist.
Dazu musst du wissen dass ich ganz früher oft als einzige Parameter einer Feind-Figur nur x und y hatte,
und dann wohl noch eine Variable ob der Feind noch existierte.

Allein für Diskussionen der Figuren hatte auch daran gedacht, gewisse Begriffe in den Raum zu werfen,
also ausgehend von einer Figur, auf die andere dann reagieren oder nicht. Nur eine unausgegorene Idee,
beispielsweise Begriffe als DWORD in ein Datenfeld zu schmeissen, so dass jemand auf einmal von, was
weiss ich, Geld erzählt, dann vermerke ich die vier Bytes "GELD" als 32 Bit ID in so einem Datenfeld.
Naja nur ein Ansatz.
Ich schätze diese ganzen Interaktionen werden den Hauptteil des Spiels ausmachen, der Rest ist dann eher
nur noch "Mechanik".
Es soll in dem Sinne keine Feinde oder Waffen geben, vielleicht allemal eine Bombe die hochgehen kann.
Es soll ja mehr in Richtung Adventure gehen als in Richtung Arcade, aber eben doch etwas anders.
Ich überlege ja auch deswegen noch so lange, damit es sich auch lohnt
und ich am Ende wirklich etwas habe, was es so noch nicht gegeben hat.

Was einen grafischen Editor angeht weiss ich gar nicht was ich jetzt übersichticher finde. Eigentlich doch
eher die Variante mit zig Text (bzw. DEF) Dateien, anstatt dass ich bei einer GUI durch etliche Seiten
Parameter blättern muss. Solche Textdateien könnten so aussehen:
LEVEL01.TXT
CHAR01.TXT
CHAR02.TXT
CHAR03.TXT
CHAR04.TXT
Damit könnte man in LEVEL01.TXT (neben allen anderen Grunddefinitionen) vermerken wieviel
Charaktere man hat und in den folgenden Dateien die Charaktere parametrisieren. Klar, alles
ganz simpel, aber mein Ziel ist dabei eben auch, dass so eine Definitionsdatei nicht mehr als sagen
wir mal 30 Zeilen hat, der Übersicht halber. Natürlich müsste man diese Dateien auch in Verzeichnissen
ablegen.

Das tollste Spiel des Jahrhunderts wäre ja ein falscher Ansatz.
Es sollte ja klar sein dass ich das nicht erwarten kann. Aber je nachdem wie es wird finden es manche
vielleicht ganz witzig. Für mich selbst wäre es allerdings das tollste was ich je programmiert habe, wobei
ich hier den Begriff "toll" eben nüchtern sehen und vielleicht eher durch ausgefeilt oder ähnliches ersetzen würde.
Mein geplantes Spiel wäre ja ein Baukasten-System und schon interessant sobald ich einen Charakter in ein
leeres (bis auf den Boden) Level setze.
Jedenfalls aus meiner Sicht, weil da eben was passieren würde.
Klar dauert das alles lange zu bauen, aber ich habe mittlerweile die Vermutung, dass dir das Programmieren
nicht so schwer zu schaffen macht wie mir.
Mir wird je nachdem irgendwie richtig schwindlig wenn ich ne Zeit lang programmiere, Grafiken machen ist
zwar ne sau Arbeit, aber dabei raucht mir nicht der Kopf.

Was Musik angeht, da hab ich über 20 Jahre Erfahrung und könnte mit dir zusammenarbeiten, allerdings
bevorzuge ich ja einen Tracker mit Leerzeilen, ansonsten ist mein "Repertoire" breit gefächert, und
manches was du von mir gehört hast, gerade aus meiner Anfangszeit um 1994, ist nicht repräsentativ.

...also hast du jetzt quasi Echtzeit-Huffman Dekompression für die Sprites?
Dann wäre mein ZVID hinfällig, es sei denn es wäre trotzdem schneller.
Müsste man dann mal vergleichen.
ZVID speichert ja, wenn man will, direkt alle Sprites einer Animation in einer Datei und macht dazu einen
einzigen Palettenbereich, und auch redundante Blöcke, die also bei jedem Sprite gleich sind, werden nur
einmal gespeichert. Wenn also bei einer Animation nur der Mund bewegt wird werden im Idealfall pro Sprite
(wo das so ist) vielleicht gerade mal 15 Byte gespeichert.

Deine Erläuterungen zu den Sprites und den Hotspots muss ich mir nochmal
in Ruhe durchlesen wenn es soweit ist.

Ich kann abschliessend nochmal sagen dass meine Game-Engine mit dem Spiel selbst wachsen soll.
Heisst, sagen wir mal, ich habe einen Sprite-Animation. Dann will ich die auf dem Bildschirm hin und her
wandern lassen, also programmiere ich diese Mögichkeit in die Engine usw.
Ich schätze aber, ich muss es doch anders angehen, da eben dieses grafische, woran man spontan denkt,
dass ein Spiel damit beginnen sollte, eben nicht der Ausgangspunkt oder die erste Grundlage sein sollte.
Ich muss mich hier in aller Ruhe hinsetzen und erstmal ein mehr oder weniger vollständiges
Gesamtkonzept erstellen, und dann beginnen zu programmieren.
Oder auch, wenn es der richtige erste Ansatz ist, eine Figur zu schaffen, d.h. die Sprites dafür und den Sound,
diese definieren und die Engine so ausstatten, dass diese Figur zum Leben erweckt wird.

Danke für deine Erläuterungen zu Point&Click Adventures!
Sehr aufschlussreich. Tatsächlich soll es schon eher in diese Richtung gehen und weniger in die Richtung Jump&Run.
Ich muss mir dazu auch einfach nochmal diverse Spielformate ansehen.

Re: Eigenes Videoformat

Verfasst: Di 1. Dez 2015, 15:39
von zatzen
Ein Nachtrag, der einem als Anfänger vielleicht nicht ganz einleuchtet:

Ich gehe richtig in der Annahme, dass man seine Programme so auslegen sollte,
dass Grafik und Ton eben nur die *Anzeige* sind, und dass das Programm oder
Spiel also auch quasi "blind" funktionieren muss. Oder?

Re: Eigenes Videoformat

Verfasst: Mi 2. Dez 2015, 13:32
von DOSferatu
zatzen hat geschrieben:Ich merke gerade dass so eine Diskussion hier nicht nur dazu dient, dir meine Vorstellungen zu erklären,
sondern dass ich auch selbst überhaupt auf neue Ideen komme, da diese noch lange nicht so weit sind,
dass ich überhaupt wüsste womit ich konkret anfangen müsste.
Ja, das scheint mir aber ganz normal zu sein, daß wenn sich zwei Leute über das gleiche Thema unterhalten (Spieleprogrammierung/-entwicklung), sich dabei solche gegenseitigen Effekte ergeben.
zatzen hat geschrieben: Ein Produkt habe ich eigentlich ganz gerne am Ende,
Es ist ja nicht so, daß ich kein Produkt am Ende haben wollen würde - oder nicht schlußendlich darauf hinarbeiten würde. Es ist nur so, daß das Endprodukt mir nicht das Wichtigste am ganzen Entstehungsprozeß ist. Ich bin keine Firma, die irgendetwas braucht, das sie verkaufen kann - und abgesehen davon ist Zeug, das ich entwickle, sowieso nichts, wofür man heutzutage noch Geld verlangenm würde oder könnte - wo nicht einmal noch Systeme aktiv genutzt werden, auf denen das Zeug läuft.
zatzen hat geschrieben: aber ich habe dabei gern auch im Hinterkopf, wie alles aufgebaut ist und funktioniert, und ZVID war für mich auch zu einem Teil so attraktiv weil manche kleinere Bildelemente damit so wenig speicher belegen können, dass man diese in einem HEX-Editor noch übersichtlich nachlesen kann. Das wird ein "Gamer" wohl nicht verstehen, und vielleicht auch mancher Programmierer nicht.
Also ich verstehe es schon - immerhin muß man sich ja auch selbst gepackte/verschlüsselte Daten mal ansehen, um zu sehen, ob der Packer/Verschlüsseler auch korrekt arbeitet.
zatzen hat geschrieben: Es ist ein bisschen so als wenn man sich als Elektroniker am Schluss nochmal gerne eine eher simple
Platine ansieht. Bzw. ist es einfach "spannend", was der Compiler aus einer redundanten Grafikdatei
macht, die zuerst über mehrere KB geht und dann, im günstigsten Fall, vielleicht in ein paar hundert
Byte passt und die man per Hex-Editor Einblick auch per Hand decodieren könnte - theoretisch.
Ja, und es wirklich schade, daß sich heutzutage so wenige Leute noch umsolche Dinge bemühen. Eher wird da gleich "Systemanforderung: 2GB" draufgeschrieben, so daß das Spiel vielleicht auf Disk(CD/DVD/wasauchimmer) gepackt mit Installer ausgeliefert wird - aber auf Festplatte (und beim Spielen: im RAM) liegen dann ungepackte 32-Bit-Vollgrafiken herum, weil man zu faul ist, hier geeignete Maßnahmen zu ergreifen - und TROTZDEM ist dann alles noch langsam und ruckelig, weil selbst diese ungepackten Grafiken scheinbar noch mit ineffizienten Routinen dargestellt werden.

Ein Beispiel: Ich bin ja froh, daß Daedalic Entertainment (bzw alle Entwickler, die unter diesem Publisher laufen) eingesprungen sind, um die große Lücke zu füllen, die Lucas Arts hinterlassen haben - und das daher wieder neue 2D-Point&Click-Adventures gibt. Die Adventures sind auch wirklich schön, Musik, Graik, Story - alles wunderbar. Aber diese hundsbeschissene (verzeih das harte Wort) Engine, die die da benutzen und die mit jedem neuen Spiel schlechter und unperformanter zu werden scheint, reicht scheinbar nicht einmal mehr aus, um auf einem 2,8 GHz Rechner mit 2 GB RAM die 2D-Inhalte eines Adventures darzustellen oder zu scrollen! Was hat DAS noch mit Programmierung zu tun?
Selbst ICH würde - selbst in dieser Auflösung! - da schon bessere Ergebnisse liefern können - und ICH programmiere unter DOS und im RealMode!
zatzen hat geschrieben: Was die Definitionen in Textdateien angeht - zuletzt habe ich die Parameter der Spielfiguren etc.
in Arrays gehalten. Und so dachte ich, man könnte ein paar Typen von Spielfiguren, Gegenständen
etc. per Arrays verwalten, und deren Ausgangswerte in den Definitionsdateien konfigurieren.
Das ist sehr vernünftig.
Auch alles in Xpyderz funktioniert so - wenn auch mit etwas anderen Ergebnissen als das, was Du Dir wohl für Deine Spiele vorstellst. Ich habe da bestimmte feste Werte, dann auch bestimmte "Toleranzen" eingebaut. (Toleranz-Werte sind solche, wo dann per Zufallsgenerator ein Wert innerhalb des Toleranzbereichs ausgesucht wird - so habe ich z.B. das Verhalten der kleinen Spinnen etwas variabler gestaltet, damit nicht alles immer so aussieht wie "fest programmiert". Und auch die Geschosse der Waffen haben z.B. solche Werte. (Wie gesagt: Es gibt keine Wertigkeit, ob etwas eine Spielfigur, Gegner, Projektil oder Bonus oder einfach Hintergrundanimation ist. Es genügt EIN Wert, der einem Objekt dann einem "Typ" gibt, alles andere (Bewegungen, Reaktionen und nicht zuletzt auch die Darstellung) kann von den absolut gleichen Subroutinen vorgenommen werden.
zatzen hat geschrieben: Wenn wir uns ersteinmal auf humanoide Charaktere beschränken, dann könnte man diesen verschiedene
Persönlichkeitsmerkmale geben, wie sie auf dieses oder jenes reagieren, und bei mir sollte jeder auch
ein bisschen sprechen können, natürlich nicht so viel wie bei Talkie Adventures, es muss ja alles in den
XMS passen.
Wie ich es genau angehe weiss ich noch nicht, aber normalerweise denke ich nicht in Dimensionen die
nicht realisierbar sind.
1.) Es ist völlig unwichtig, ob Charaktere humanoid sind, um ihnen ein Verhalten zu geben.
2.) Das, was Dir vorschwebt, bezeichnet man in der Informatik unter dem Sammelbegriff KI (Künstliche Intelligenz).
3.) Humanoide Charaktere sind gleich mal das schwierigste, wenn man KI programmieren will. Erstens, weil die Spieler auch humanoid sind - ist es natürlich, weil gleiche Spezies, auch besonders schwer, jemandem da einen "sich normal verhaltenden Menschen" vorzuspielen. Will damit sagen: Wenn man da mit Bakterien anfängt und sich von da aus hocharbeitet, wäre das ganze viel einfacher.
Man könnte z.B. Mäuse oder Ameisen, Hasen, Spinnen, Schlangen nehmen, denen ein Verhaltensmuster einprogrammieren (und ja: auch Tiere kommunizieren miteinander).
Menschliche Kommunikation und menschliches Verhalten glaubwürdig nachzubilden ist die absolute Königsdisziplin in der Künstlichen Intelligenz - selbst ganze Armeen von Teams renommierter Wissenschaftler arbeiten daran seit Jahrzehnten (mit eher sehr mittelmäßigen Erfolgen).
Will sagen: Deine Aussage: "normalerweise denke ich nicht in Dimensionen die nicht realisierbar sind" müßtest Du dann mal etwas weiter ausführen, denn sonst entsteht bei mir wirklich der Eindruck des obengesagten.
Und: Auch solche Lernmatrizen (d.h. Dinge, die dafür sorgen, daß sich Verhalten aufgrund von Erfahruingen ändert) wären Teil einer KI. Und selbst EIN Objekt, das nur mit "leblosen" (festen) anderen Objekten interagiert, mit so etwas zu programmieren und zu verwalten, erfordert schon einen immensen Speicher-/Rechenpower-Aufwand um wenigstens ansatzweise so etwas wie ganz primitives "Verstehen" zu simulieren - und MEHRERE solcher (humanoide!) Objekte, die auch noch miteinander interagieren... Wenn das ganze da auch nur ansatzweise natürlich wirken soll, mußt Du die Systemanforderungen für den Nutzer wohl sehr weit ausdehnen. Die wenigsten werden es sich leisten können, sich die dafür nötige Rechnerfarm zu mieten...
Und ja, ich hatte früher, als ich "Max Headroom" gesehen hatte, auch mal gedacht: Müßte doch zu machen sein, so etwas auch selbst zu programmieren... Was war ich naiv damals....
Ich finde es auch schade, daß es bis heute scheinbar nichts im Netz gibt, wo jemand so etwas mal - und wenn auch nur als Scherzprogramm - versucht hätte.

Nein, die Leute nehmen lieber Game-Maker oder Flash und bauen damit uninspirierten Murks...
Das wirklich Blöde daran, daß jetzt (gegenüber früher) ALLE Leute "Computer" (oder computerähnliche Geräte) haben, ist, daß der Anteil an Leuten, die Lust auf richtige Herausforderungen haben und richtige Programme schreiben wollen an der Weltbevölkerung zwar immer noch der gleiche ist - es aber inzwischen einen viel größeren Anteil an "USERN" gibt, die überhaupt kein Maschinenverständnis haben/haben wollen, aber trotzdem "irgendwas damit bauen wollen" - und es deshalb immer schwerer wird, zwischen dem ganzen Abfall, der so produziert wird, die paar Perlen zu finden, die wirklich mal mit einer guten Idee, durchdachtem Ansatz und sauberer Programmiererung einherkommen.
zatzen hat geschrieben: Wie ich schon sagte, es soll kein Spiel werden mit großem Anspruch an Geschicklichkeit und
Schwierigkeitsgrad, sondern eher soetwas dass sich immer wieder andere Konsequenzen ergeben
je nachdem was man tut oder nicht tut, und ein klassisches Game-Over muss es gar nicht geben.
Ja, ich verstehe schon, worum es geht. Aber: Wenn das ganze ein "alles ist möglich" Spiel wird - ohne auf ein Endziel hinzuarbeiten, dann:
a) IST es wie Sims
b) wenn zustätzlicher Anspruch auf "automatisches natürliches Verhalten" - wird es ein riesiger Aufwand und jahre- bis jahrzehntelange Programmierung/Forschung brauchen, um das zu realisieren - alles nur, damit ein Spieler dann auf EINIGE der Personen Einfluß nehmen kann, damit sich da etwas in eine andere Richtung entwickelt.

Und es gibt da leider keinen "dritten Weg". Es gibt nur diese zwei Möglichkeiten:
1.) Es gibt ein ZIel, das mit dem Spiel verfolgt wird. Dann ist es wie eins der "klassischen Spiele":
Adventure: Ende der Story erreichen.
Arcade: Durch alle Levels durchkommen (alte Arcade: mit möglichst viel Score für Siegerliste).
Denkspiel: Alle Rätsel lösen.
Sportspiel/Rennspiel: Der beste werden (Platz 1 erreichen)
usw.


2.) Es gibt kein Ziel, das verfolgt wird, sondern es geht um das Verhalten und Interaktion.
Dann ist es wie Sims.

Erklärung für diese rigorose Einteilung:
Es gibt nicht "ein bißchen fertig werden" oder "ein bißchen das Level schaffen" oder "ein bißchen auf Platz 1 sein" oder "ein bißchen das Rätsel lösen".

ICH persönlich könnte mich für Sims und alles was wie Sims ist, noch nie so begeistern. Nicht zu wissen, "was man machen soll", sondern so "vor sich hin spielen" - das ist scheinbar wirklich eher etwas, das Mädchen gern machen (daher spielen auch wesentlich mehr Mädchen als Jungs Dinge wie Sims). Mich würde das auf Dauer eher langweilen.
Liegt wohl daran, daß männliche Spieler eher auch gern mal ein Erfolgserlebnis haben - das "ich gebe mir so viel Mühe und werde immer besser - und es wird dann auch mal belohnt" Prinzip. So etwas vermeidet Frustration.
zatzen hat geschrieben: Inspirierend dazu sind einige Spiele, Adventures wie Monkey Island, aber auch Lemmings (weil ein
stetiger Handlungsfluss besteht) und auch Worms, weil es dort manchmal zu irrwitzigen Kettenreaktionen
kommt. Sierras Incredible Machine dürfte wohl im Prinzip auch parametrisch funktionieren.
Ja, aber in all diesen genannten Spielen arbeitet der Spieler trotzdem auf ein Endziel hin.
Und: Es "dürfte" nicht nur - ich bin mir sicher, es IST parametrisch.
In quasi ALLEN ernstzunehmenden Spielen (außer vielleicht dem allerersten BASIC-Spiel, das man irgendwann mal zum Testen geschrieben hat), werden die teilnehmenden Objekte (und Subjekte) wohl mit Parametern versorgt - das ist schon so, seit es überhaupt Computerspiele gibt (und eigentlich gilt das sogar für "Nicht-Computerspiele").
Bei Computern sind Parameter sogar zwingend notwendig, da alles, was Computer können, das Berechnen /Umformen/Schieben von Zahlen ist. Dem Computer muß ALLES mit Zahlen erklärt werden, alles andere versteht der nicht!
Eine Spielfigur soll da hin? Ein Mensch zeigt mit dem Finger auf eine Stelle, wer weiß, was er sich dabei denkt - ist wohl bei jedem Menschen anders.
Für den Computer heißt das: Gib mir 2 Koordinaten, dann weiß ich, was du meinst! Und Koordinaten sind Zahlen.

Der Mensch sagt: Ich will das da rot, und das da grün mit ein bißchen ins gelbliche haben.
Für den Computer heißt das: Ich bin eine Maschine, ich habe keine Ahnung von Ästhetik oder Farben - gib mir 3 Werte für die Rot-/Grün-/Blau-Anteile und ich schicke das an die Grafikkarte, die wandelt das dann in IRGENDEINE Farbe um, die du vielleicht schön findest und die mich nicht interessiert, für mich (Computer) sind das nur 3 Zahlen, die für mich genauso "schön" wie 3 andere Zahlen sind...

Der Mensch sagt: Spiel mal die Töne da, die so klingen wie Vogelgezwitscher einer Lerche.
Für den Computer heißt das: Ich weiß nicht, was eine Lerche ist, ich kenne nur Nullen und Einsen. Ich weiß nicht mal, wie eine Null oder Eins für dich aussieht, Mensch. Für mich ist das Strom aus und Strom an. Du willst Töne machen? Gib mir Zahlen für eine Frequenz, für eine Amplitude und eine Wellenform - oder wenn ich keinen Chip habe, der das zu Daten macht, mußt du mir sogar einzelne Stücke der Welle geben - und ich schicke das dann an einen von dir gegebenen Ausgang (Port) raus. Wenn da ein Lautsprecher dranhängt, kommen Töne raus, wenn es die richtigen ZAHLEN waren, auch die richtigen Töne. Für mich (Computer) klingt das weder schön noch häßlich. Es klingt gar nicht, es sind nur Zahlen.

Der Computer weiß nicht einmal, was ein A ist. Der Mensch hat mal gesagt: Wenn im Speicher eine 65 steht und dieses Speichersegment an eine Schriftausgabeeinheit geht, dann sollen die Punkte so zusammengesetzt werden, daß es für einen Menschen einem A ähnelt. Und ein Punkt ist für einen Drucker ein Impuls und für einen Bildschirm 1-3 verschieden starke Impulse (je nach Farbe).

Und: Alle Zahlen sehen für den Computer gleich aus. Er kann auch Zahlen, die eigentlich für Töne gedacht waren, an den Ausgang für Bildausgabe schicken oder Zahlen, die Koordinaten oder Texte beschreiben sollten, als Töne ausgeben. Für den Computer ist das nicht einmal falsch. Der Mensch bewertet dann, ob es gut aussieht, gut klingt, richtig ist.
zatzen hat geschrieben: Also wäre es ein Spiel, was auch ohne Eingriff des Spielers läuft, und aber im Idealfall sensibel auf
Eingriffe des Spielers reagiert. Butterfly Effect quasi.
Ich hatte schon befürchtet dass dann soetwas wie "The Sims" rauskommt, aber ich denke bei mir würde
das schon anders werden.
Ja, solche Dinge gibt es auch schon. Und ja: ich wollte selber mal so etwas programmieren. Engine, Anzeige und Grafiken dafür sind schon fertig. Es sollte eine Erweiterung von Conway's "Game of Life" werden, auch mit möglichen Eingriffen des Spielers.
Bis jetzt bildet es nur das normale "Game of Life" in Grafik ab - in Auflösungen 320x200, 640x480, 800x600 und 1024x768. Das Level ist standardmäßig 128x128 Felder groß und alle Elemente sind parametrisiert.
Ich bin sicher, daß Du "Game of Life" kennst - falls nicht: Unter welchem Stein hast Du die letzten 30 Jahre gepennt? (Eigentlich trifft JEDER, der sich mit Computern beschäftigt, irgendwann mal auf dieses Konzept.) Google hilft.

Kurze Erklärung: Game of Life beschreibt einen "selbstentwickelnden Organismus" (oder auch mehrere), nach den folgenden einfachen Regeln:
Es gibt ein quadratisch gerastertes Feld, jedes Feld kann entweder leer oder mit einer Zelle belegt sein. Jedes Feld hat somit 8 Nachbarn (gerade und schräg). Hat ein leeres Feld genau 3 Nachbarn, entsteht auf diesem eine neue Zelle. Hat ein mit einer Zelle belegtes Feld 2 oder 3 Nachbarn, bleibt diese Zelle am Leben, ansonsten (bei 0,1,2,4,5,6,7,8 Nachbarn) stirbt sie im nächsten Zug (Feld wird wieder leer).
Diese einfachen Regeln genügen schon, um aus teilweise recht einfachen "Figuren aus Zellen" komplexe Gebilde entstehen zu lassen, sogar solche, die sich "bewegen" oder "fortpflanzen".
Man kann die Parameter (also Anzahl Zellen, um Zellen entstehen oder leben zu lassen) auch beliebig ändern, aber die o.g. Konstellation ist die ursprüngliche und auch bekannteste.

So - das ganze Ding hab ich programmiert - allerdings sind diese "Zellen" bei mir Kohlköpfe. Das eigentlich lustige ist, daß die Kohlköpfe bei mir auch verschiedene Farben haben können und daß bei Entstehung neuer Kohlköpfe der neue Kohlkopf eine Mischfarbe erhält, die sich nach einer Tabelle aus den bestehenden Farben der 3 an der Neuentstehung beteiligen Kohlköpfe ergibt. Funktioniert ganz gut, sieht auch schick aus.
Der Plan war nun (Grafiken wie gesagt schon vorhanden), auch Hasen einzubringen, die in dieses "Öko-System" eingreifen, d.h. Kohl fressen und sich auch vermehren können, falls sie nicht verhungern(intern können Objekte Geschlecht/Geschwindigkeit/andere Parameter erhalten). Desweiteren soll es Schlangen geben, die dann wieder auf genügend Hasen angewiesen sind. Die Bewegung der Schlangen ist dabei so ähnlich wie in diesem Spiel "Snake" - die Schlange wird länger, wenn sie Hasen frißt, wird sie zu lang, hat sich keinen Platz mehr oder ringelt sich aus Versehen selbst irgendwo ein usw.
Es gibt dann auch noch andere Pflanzen und Ameisen, Spinnen, Raupen, die Schmetterlinge werden, etc. Die Schlangen vermehren sich durch Eier, diese dürfen dann nicht von anderen Tieren zerstört werden...
Und auch die anderen Objekte sind/wären parametrisiert.

Das "Spiel" - wenn man es so nennen kann - bestünde nun darin: Jeder Spieler hat zu Anfang eine bestimmte Anzahl Objekte/Subjekte, die er in seine Ecke des Spielfelds einbringen kann - er muß auch nicht alle einbringen, kann sich ein paar Reserve für später lassen. Und: Jeder Spieler hat eine bestimmte Farbe.
Gewonnen hat der Spieler, der nach einer bestimmten Zeit das meiste "Leben" in seiner eigenen Farbe auf dem Spielfeld hat. Das Ganze wäre dann auch ein "eher beobachten und manchmal eingreifen" Spiel, so daß der Spieler nicht direkt interaktiv wirkt, sondern eher als ein Deus-Ex-Machina.

Aber ich habe das ganze Ding dann doch nicht umgesetzt - ich habe einfach zu viele Ideen und zu wenig Zeit, diese umzusetzen. Ich werde immer älter und müder und schaffe nicht mehr alles. Und außerdem habe ich einen Job, der mich quasi kaputtmacht - abends bin ich dann ausgelaugt und am Wochenende bin ich dann meistens auch müde. Was so ein stumpfsinniger Job mit einem kreativen Gehirn anrichtet, DAS sollte wirklich mal wissenschaftlich untersucht werden - aber es ist ja gesellschaftlich GEWOLLT, daß alle Leute quasi ganztägig mit ihrem "Überleben" beschäftigt sind, um nicht am Ende noch auf irgendwelche Ideen zu kommen. IDEEN sind für die westliche Gesellschaft gefährlich - denn Veränderungen sind nicht vorgesehen! Oh, es SIEHT SO AUS, als wenn sich andauernd alles ändert! Aber in Wirklichkeit ändern sich nur die Sachen, die es zu kaufen gibt - alles andere bleibt gleich. In den 70ern war's ein Kofferradio, heute ist es ein Smartphone, was JEDER UNBEDINGT HABEN MUß.
Es ist wie in einem dummen Spiel: Veränderung der Grafik ändert nichts an einem dummen Spielprinzip. Es fällt dummen Leuten dann nur weniger auf.

Zurück zu dem Computerspielen.
Und, um auf Deine Aussage zurückzukommen:
"Ich hatte schon befürchtet dass dann soetwas wie "The Sims" rauskommt, aber ich denke bei mir würde das schon anders werden."
Was läßt Dich das glauben?
zatzen hat geschrieben: Du beschreibst in GameSys2 das Verhalten der Figurentypen, ich würde das lieber parametrisch regeln,
also "Charaktereigenschaften" aus denen sich je nach Situation eine bestimmte Reaktion ergibt.
Naja, das ist ein fließender Übergang. Ab wann ist es parametrisch, ab wann programmiert? Prinzipiell ist Programmierung auch immer parametrisch und es geht nur darum, daß ich mit GameSys2 dem Entwickler die Wahl offen lasse, ob festprogrammiert oder parametrisch.
Auch GameSys2 hat übrigens ein "Interface" zu einem "externen Segment", so wie ISM.
Es wäre also auch durchaus möglich (und so wird es wohl auch intelligenterweise gemacht werden), wenn man Spielfiguren bestimmte Werte vorgibt:
* Hitpoints (wieviele Treffer halten sie aus bevor ... was auch immer)
* Grundgeschwindigkeit
* Wenn Geschwindigkeitsänderung?
* Warum?
* Um welchen Wert? (und absolut/relativ?)
* Wann passiert Richtungsänderung?
* Warum passiert Richtungsänderung?
* Wohin?
* Wann erzeugt Figur eine andere Figur?
* Warum erzeugt Figur eine andere Figur?
* Wo?
* Welche?
* Wann Umwandlung in andere Figur?
* Warum?
* In welche?

Und so weiter. Solche Parameter nennt man in der Programmierung FLAGS. Die bekannteste Form ist das binäre Flag (ja/nein), aber es gibt auch solche mit mehr als 2 Zuständen.
Und ja - so etwas wird und wurde auch gemacht und ja, damit braucht man nur ein "generelles Objekt" definieren und gibt diesem Objekt diese ganzen Parameter und hätte das, was man will.

Ich könnte das auch in GameSys2 so machen und es wäre auch technisch möglich, das so zu programmieren, ich selbst würde es lediglich aus praktischen Gründen nicht machen.

Ich erkläre mal, wieso:
Ja - es würde dem Entwickler erheblich die Arbeit erleichtern, mit einem parametrisierten "kann eigentlich alles" Objekt (bzw mehreren/vielen) zu arbeiten.
Aber mir geht es ja nicht nur darum, es mir (dem Entwickler) leicht zu machen, sondern auch dem Endanwender nicht zuviel zuzumuten.
Erklärung: Bei parametrisierten Objekten muß jedes Objekt alle möglichen Parameter berücksichtigen, selbst solche, die es selbst - aufgrund seines Typs - nie benötigen wird. Das erfordert Speicher (der dann mit Nullen gefüllt wird) und Rechenzeit (Bearbeitung/Prüfung von Dingen, die sich nie ändern).

Mein Plan sieht ja große Levels, gefüllt mit Figuren, vor. Wenn ich 2000 Figuren habe, gibt es davon etliche, die nur Bonusgegenstände sind. Sie "liegen/schweben" nur herum. Bewegen sich nicht, reagieren auf nichts. Müssen nicht einmal darauf reagieren, wenn sie eingesammelt werden - denn diese Reaktion kann auch von der "einsammelnden Figur" erfolgen.

So ein einfacher Bonusgegenstand hätte aber auch eine theoretische Geschwindigkeit (0) und RIchtung (undefiniert bei Geschwindigkeit 0) und Hitpoints (0) und Gründen für Änderung und Erzeugen von anderen Objekten (0) oder eigene Änderung (0)... Er würde ständig prüfen, ob er mit Schüssen, feindlichen Figuren, Hintergrundanimation kollidiert ist, um dann festzustellen, als Reaktion ist 0 definiert.

Denn, davon ausgehend, daß alles ein Objekt ist, das erst durch seine Parameter definiert ist, würde die "Objektsteuerschleife" für jedes Objekt (ohne zu "wissen", welches Objekt es ist, da es ja alle Objekte gleich behandelt) alle möglichen Dinge durchführen, egal, ob für dieses Objekt gebraucht oder nicht.

NATÜRLICH geht das auch und würde auch funktionieren. So etwas nennt man objektorientierte Programmierung (OOP). Weil sie dadurch (siehe oben) natürlich langsamer ist und mehr Speicher braucht als die lineare Programmierung, bin ich (persönlich) kein Freund von OOP, weil ich (aber das kann jeder anders machen!) mir selbst auf die Fahnen geschrieben habe! Performance+Speichersparen, also "ressourcenschonende Entwicklung".

GameSys2 ist so angelegt, daß beim Starten eines FigurenTyps auch gleichzeitig Speicher für eine Figur dieses Typs in einem "allgemeinen Stack" reserviert wird - und zwar genau so viel, wie für diesen Typ benötigt wird - das legt der Programmierer fest. Ein stehender/hängender Bonus braucht also (abgesehen von seinen Koordinaten und Image) außer seinem "Wert" gar keine weiteren Daten - daher werden diese auch nicht angelegt.
Die "Schleife" für einen Bonus besteht ausschließlich aus einer Schleife mit einem "LEAVE"-Befehl und einem Rücksprung auf diesen LEAVE. Man könnte sogar diese noch entfernen, aber der Bonus muß ja irgendwie "aktiv" sein, damit man ihn "deaktivieren" kann, sobald er aufgesammelt wurde - und er braucht wenigstens die paar Bytes (Koordinaten/Image), um angezeigt werden zu können. In Xpyderz hatte ich das alles noch "generalisierter" gemacht, da gab es dann viele Objekte, die im reservierten Array nur Nullen (oder unberücksichtigte Werte) stehen hatten und wo ich dann noch Arrays für Anzeigeparameter und interne Parameter getrennt hatte. Das hatte mich immer schon gestört, daher habe ich dies bei GameSys2 abgeschafft.
Ein weiteres Beispiel ist ein "Projektil". Ein normaler kleiner "Schuß" wie bei Xpyderz, der nichts weiter kann als durch die Gegend fliegen und beim Treffen auf eine Wand zu verschwinden muß nicht noch alle anderen eventuell einem "generalisierten Objekt" möglichen Operationen durchtesten.

Außerdem ist man so jederzeit in der Lage, zusätzliche Dinge einzubauen, die EINES der Objekte (Figuren) können soll. Bei der generalisiert-parametrisierten Vorgehensweise wäre so etwas zwar ebenfalls möglich, dann müßte man eben ein zusätzliches Parameterfeld erschaffen. Dieses würde bei dem Objekt, das diesen Parameter benötigt, benutzt und von allen anderen "übersprungen" (ignoriert) werden.

Und ja - es wäre auch möglich, mit diesen generalisierten Parametern TROTZDEM Code (auch GS2-Code) erzeugen zu lassen, der dann für jeden Figurentyp nur das berücksichtigt, was an Parametern gebraucht wird. Durchaus machbar- benötigt aber einen weiteren Parser - der für jeden Objekt-Tyo automatisch einen möglichst guten Code erzeugt, der nur das Benötigte berücksichtigt - das widerspräche dem ursprünglichen Paradigma, würde aber Code/Speicher sparen.
zatzen hat geschrieben: Dabei nimmt mir die Engine längere Definitionen oder Scripts ab, indem sie bei bestimmten Ereignissen jeweils die Charaktereigenschaften auswertet und eine Reaktion bestimmt. Das kann auch etwas ganz simples sein wie ob eine Figur beim Erreichen einer Wand umkehrt oder stehen bleibt. Aber die Charaktereigenschaften könnten sich auch ändern, und das macht das ganze vielleicht sogar interessanter als etwas das "hardgecodet" ist.
Das stimmt. Man kann zwar auch in "hardgecodete" Sachen eingreifen - (indem man manche Sachen als "Variable" statt "Konstante" definiert) - aber dort dann eben nur im Rahmen der Möglichkeiten, die der Code vorgibt. Festcodierte Sachen bedeuten ja nicht automatisch, daß überhaupt keine variable Struktur vorhanden sein kann.
"Völlig freie" Strukturen sind mir aber zu "gefährlich", da man dann quasi "außenherum" viele Tests machen müßte, um festzustellen, ob die Parameter sich noch in verarbeitbaren (anzeigbaren/berechenbaren) Grenzen befinden - weil das alles ja schließlich auf einer nicht-selbst-denkenden Maschine (Computer) ausgeführt werden muß und man bei "völlig freien" Strukturen davon ausgehen muß, daß von den vielen ungeplanten Zuständen auch solche dabei sein könnten, die z.B. das Spiel unspielbar machen oder sich in Endlosschleifen aufhängen oder ähnliches sein könnten.

Früher[tm] hatte ich auch schon so Ideen für "alles-ist-möglich" Spiele - und ich will gar nicht absprechen, daß der Gedanke faszinierend ist - aber ich sehe bei mir selbst, was es für eine harte Arbeit ist, allein schon ein "einiges-ist-möglich"-Spiel zu bauen, und dann noch für einen allein, der ja nicht nur die Programmierung, sondern auch Grafiken und Sounds allein machen muß.

Ich werde immer älter - das letzte größere Projekt, das ich rausgebracht habe, ist schon Jahre her. Ich habe mittlerweile so lange herumentwickelt, daß Microsoft und die Hardwareindustrie inzwischen beschlossen haben, die Abwärtskompatibilität zu den Systemen, unter denen ich entwickle, vollständig einzustellen. Und bei einem SPIEL wäre es mir eventuell ganz genehm, wenn außer mir noch irgendwer anders auf der großen Welt die Möglichkeit bekäme, das auch mal zu spielen, bevor ich tot umfalle oder Computer irgendwann nichtmal mehr zum Binärsystem kompatibel sind.

Anders ausgedrückt: Von vielen Ideen, die ich früher gern noch umgesetzt habe, habe ich mich inzwischen verabschiedet - nicht, weil sie schlecht gewesen wären, sondern weil deren Umsetzung mich weitere Jahre gekostet hätte. Und vieles "zu-kompliziert-gedachte" habe ich inzwischen auf einfachere Wege gebracht. GameSys2 müßte eigentlich GameSys5 heißen, so oft, wie ich da in Zwischenstufen schon "eingespart"/"vereinfacht" habe.

Irgendwann neigt man als Computerfreak leider dazu, ZU kompliziert zu denken und dabei aus den Augen zu verlieren, daß z.B. einfache Werte zwar Speicher sparen würden, der aber durch den komplizierten Code, der zu ihrer Ausführung benötigt wird, belegt sein würde - und zusätzlich die Rechenzeit kosten würde. Ich habe für die serielle Schnittstelle bitbasierte mit Befehlen und Fehlerkorrektur und vielen Features (wie intern 64 Streams plus Befehlsstream) Übertragungsprotokolle entwickelt, die auch im Test großartig funktioniert haben, die ich aber nie in ein Spiel hätte einbauen können, da sie einen derartigen Speicher/Rechenzeitverbrauch hatten, nur um Werte fehlerfrei über den "COM-Port" zu kriegen, daß ich kaum noch Platz und Zeit gehabt hätte, um Grafiken und Sprites zu speichern und anzuzeigen.

Und ja, ich weiß: XMS klingt immer nach einem guten Argument für "es ist ja genug Speicher da - klatschen wir doch alles ins XMS!". Im RealMode kann man aber nur indirekt auf XMS zugreifen - da gibt man an HIMEM.SYS intern Befehle, um aus XMS einen Teil des Speichers in den Heap zu kopieren - oder umgekehrt. Bearbeiten/nutzen kann man das Zeug aber weiterhin nur im Heap (unter 1 MB, bzw im Normalfall unter 640 kB). Und zwar, weil es im RealMode nur Segmente bis maximal $FFFF gibt und man damit (selbst wenn GateA20 offen) nur maximal 1 MB + 65520 (64k-16) Bytes direkt ansprechen könnte - wobei natürlich die Benutzung von Speicher über 640kB mit Vorsicht anzugehen ist - da liegen ja auch noch andere Dinge drin...

Und dieses hin- und her-kopieren vom/zum XMS kostet übrigens auch Rechenzeit! Diese ist nicht Null! Und es muß auch im Heap noch etwas frei sein, um die aus dem XMS geholten Sachen abzulegen. Im XMS selbst kann man vom RealMode aus nichts darstellen/ausführen. (Dazu wäre eher der als "Flat/4G" bekannt gewordene "Hack" nötig.)
Und: Tests unter Windows haben ergeben, daß Windows und DOSbox sich mit dem HIMEM.SYS-Support etwas schwertun. Es funktioniert zwar, ist aber um vieles langsamer als unter reinem DOS. Ich weiß nicht, wieso. Aber wahrscheinlich, weil Windows ja (aufgrund Multitasking) mit dynamischer Speicherfreigabe arbeitet.

Ich will damit sagen: Ich weiß, daß es sehr viele Dinge gibt, die machbar sind, und die auch ICH machen könnte: Ich könnte auch Grafiken und Sprites in Truecolor (16,7Mio Farben) anzeigen. Ich könnte auch 16bit Sound generieren. Ich könnte auch 60000 statt nur 2000 Figuren gleichzeitig steuern. Aber: Ich habe derzeit über die letzten 20 Jahre Units entwickelt und weiterentwickelt, die genau das können, was ich eigentlich mal vorhatte.
Und: Ich habe mich, aufgrund dessen, auch mal irgendwann mit irgend etwas "fertig werden" zu wollen, inzwischen von "technisch möglich" auf "in endlicher Zeit machbar" beschränkt. Ich weiß, daß ich damit nur das realisieren kann, was eben mein Plan vorsieht - und nicht mehr! Aber immerhin wäre das schon mehr als dieses "gar nichts", was viele andere Leute machen können und es wäre auch mehr als dieses leidige "gar nichts", was auch seit Jahren von mir kommt.

In den letzten Jahren habe ich nur Tools und Engines gebaut - doch eigentlich nenne ich mein Label ja Imperial Games - weil es mir ja in erster Linie immer am Ende um Spieleentwicklung ging. Und dem "Games"-Teil werde ich inzwischen leider kaum noch gerecht - und mich stört das.
zatzen hat geschrieben:Dazu musst du wissen dass ich ganz früher oft als einzige Parameter einer Feind-Figur nur x und y hatte, und dann wohl noch eine Variable ob der Feind noch existierte.
Je nach Komplexität einer Feind-Figur kann das allein ja auch schon ausreichen. Allerdings gehe ich mal davon aus, daß zumindest irgendwelche Geschwindigkeitswerte (und wenn auch als Konstanten im Code) sicher irgendwo existiert haben müssen, falls es ein beweglicher Feind war.
zatzen hat geschrieben: Allein für Diskussionen der Figuren hatte auch daran gedacht, gewisse Begriffe in den Raum zu werfen,
also ausgehend von einer Figur, auf die andere dann reagieren oder nicht. Nur eine unausgegorene Idee,
beispielsweise Begriffe als DWORD in ein Datenfeld zu schmeissen, so dass jemand auf einmal von, was
weiss ich, Geld erzählt, dann vermerke ich die vier Bytes "GELD" als 32 Bit ID in so einem Datenfeld.
Naja nur ein Ansatz.
Das erfordert schon wieder parsen und geht in Richtung KI.
Für einfachere Anwendungen zu einer Art auf Begriffen basierenden Pseudo-Kommunikation, suche mal im Netz nach "ELIZA", "ELIZA Programme" oder "ELIZA Chat".
zatzen hat geschrieben: Ich schätze diese ganzen Interaktionen werden den Hauptteil des Spiels ausmachen, der Rest ist dann eher
nur noch "Mechanik".
Es soll in dem Sinne keine Feinde oder Waffen geben, vielleicht allemal eine Bombe die hochgehen kann.
Es soll ja mehr in Richtung Adventure gehen als in Richtung Arcade, aber eben doch etwas anders.
Ja, es ist eben schwer, für ein "Spiel/Nichtspiel" das "Arcade/Nichtarcade/Adventure/Nichtadventure" mit/ohne Feinden und beliebiger Anzahl nicht fest definierter Parameter irgendwelche Ideen oder Vorgehensweisen zu entwickeln. Weil, wenn ALLES variabel ist, dann hat man ein (wie der Mathematiker sagen würde) "Gleichungssystem mit unendlich vielen Gleichnungen und unendlich vielen Variablen".

Es ist schwer, daraufhin wirklich einen brauchbaren Ansatz zu entwickeln - ICH würde mir so etwas nicht antun wollen. Aber jeder entwickelt eben so, wie er es am besten findet.

Meine (ganz persönliche) Meinung dazu ist knallhart, aufgrund folgender gegebener Zustände:
Ein Computer ist ein beschränktes System - mit beschränktem Speicher, beschränkter Rechenzeit und beschränkten Fähigkeiten.
Ein Mensch ist ebenfalls ein beschränktes System - mit beschränkter Lebenszeit und beschränkten Fähigkeiten.
Ein wie-auch-immer-geartetes Endergebnis muß daher immer Beschränkungen unterliegen - das liegt in der Natur der Sache.
Es ist richtig, daß ein Ganzes mehr sein kann als die Summe seiner Teile. Aber: alles, was man nicht selbst einprogrammiert, muß der Computer daraus errechnen. Alles, was nicht-maschinell wirken soll, muß entweder der Mensch vorher einprogrammiert haben (damit eine Kreativität drin ist) oder von einem guten Zufallsgenerator zusammenkombiniert werden (damit es nach Kreativität AUSSIEHT).

Meine (persönliche) Ansicht dazu ist, daß ich eingesehen habe, daß sowohl Maschine als auch ich technischen und biologischen Beschränkungen unterlegen bin und ich mich demzufolge entschieden habe, mit endlichen Ressourcen in endlicher Zeit irgendwann etwas fertiges zu machen, das vielleicht nicht zu 100% "etwas absolut neues und einzigartiges" sein wird, aber dabei so gut, daß ich mir damit trotzdem einen Traum erfüllen und vielleicht ein wenig stolz darauf sein kann.
zatzen hat geschrieben:Ich überlege ja auch deswegen noch so lange, damit es sich auch lohnt und ich am Ende wirklich etwas habe, was es so noch nicht gegeben hat.
Ich will Dich in Deinem Vorhaben keinesfalls entmutigen - aber die Spiele, die wirklich etwas sind, das es so noch nicht gegeben hat, sind wirklich rar gesät - alles andere sind nur Variationen desselben Themas.
Tennis: Pong
Raumschiffshooter: Asteroids
Jump'n'run: Mario
Rollenspiel: Zelda
Massenfiguren_spiel: Lemmings
Egoshooter: Wolfenstein/Doom
Adventure: Dinge wie Zorg (Textadventure), als Point/Click Adventure: Mainac Mansion
Beat'em'up: Street Fighter oder noch ältere "Karate-"Spiele
Leben-Simulator-Spiele: Populous, Siedler, Sims...
Sportspiele/Puzzlespiele/Simulationen: Eigentlich gar nichts - es sind nur grafische (spieltechnische) Umsetzungen der realen Vorlagen mit Anspruch auf immer mehr Realitätsnähe - also nichts wirklich "neues").

Es gab auch selbst schon Kombinationen.
Beispielsweise gibt es ein wie Ego-Shooter gemachtes/gesteuertes 3D-Adventure, das aber trotzdem Point&Click war namens "Normality" und es gab auch schon Adventures mit Prügeleinlagen und Jump'n'run.

Wenn man sich mal alleine die "Tomb-Raider" Serie ansieht: Das ist: 3D, Jump'n'run, Shooter, Puzzle und Adventure... - Da fragt man sich schon: Verdammt, was will man eigentlich NOCH?

All diese Dinge sind quasi "Prototypen" eines Spiels oder Spielprinzips, von denen es immer wieder neue, andere Arten gegeben hat mit demselben Hintergrund - und selbst Kombinationen von all dem hat es schon gegeben.

Achja - und als ein Beispiel für Spiele mit "freier Welt" und Personen, die sich zumindest den Anschein geben, frei zu agieren, könnte man noch Dinge wie "Grand Theft Auto" nennen - was aber trotzdem eine Story hat und dadurch interessant wird.

Ich sage es mal ganz offen: Gehe ich durch die reale Welt, kommuniziere (wenn überhaupt) mit realen Menschen - mit all ihren Interessen und Bedürfnissen und Fähigkeiten und all dem - ist das total öde und langweilig, OBWOHL es quasi 100%ig interaktiv ist und alle Menschen 100% eigengesteuert sind usw. Das ganze echte Leben hat ja quasi auch "kein richtiges Ziel" - es ist eben "einfach da" und man sieht irgendwie zu, daß man etwas daraus macht, um wenigstens selbst ein Ziel zu haben.

DAS wäre dann das, was Dein "Spiel" werden würde - nur OHNE Ziel. Also quasi noch öder als das reale Leben. Wenn die einzelnen Figuren/Objekte ohne Ziel/Bedürfnis programmiert werden, gäbe es überhaupt keine "Angriffsfläche" zwischen den einzelnen Charakteren und überhaupt keinen Bedarf für sie, miteinander oder mit- (oder gegen-) den Spieler zu interagieren. D.h. es gäbe für keinen der Charaktere überhaupt keinen Grund, sich mit irgend einem der anderen Charaktere in irgend einer Form zu beschäfigen/auseinanderzusetzen.
Will man solche Bedürfnisse aber HABEN - DAMIT eben so ein Grund besteht, MUß man sie einprogrammieren - und wenn es per Zufallsgenerator ist, dann auch so. Denn eine Maschine wie unsere Computer entwickeln von selbst keine Bedürfnisse und kein Ziel.
Und sollten die Figuren überhaupt kein Ziel haben, sondern nur so "vor sich hinmachen, bis der Spieler ihnen etwas anderes sagt", dann ist es wie Sims, Siedler, Lemmings.
zatzen hat geschrieben: Was einen grafischen Editor angeht weiss ich gar nicht was ich jetzt übersichticher finde. Eigentlich doch
eher die Variante mit zig Text (bzw. DEF) Dateien, anstatt dass ich bei einer GUI durch etliche Seiten
Parameter blättern muss. Solche Textdateien könnten so aussehen:
LEVEL01.TXT
CHAR01.TXT
CHAR02.TXT
CHAR03.TXT
CHAR04.TXT
Damit könnte man in LEVEL01.TXT (neben allen anderen Grunddefinitionen) vermerken wieviel
Charaktere man hat und in den folgenden Dateien die Charaktere parametrisieren. Klar, alles
ganz simpel, aber mein Ziel ist dabei eben auch, dass so eine Definitionsdatei nicht mehr als sagen
wir mal 30 Zeilen hat, der Übersicht halber. Natürlich müsste man diese Dateien auch in Verzeichnissen
ablegen.
Ja, ich habe ja mich ja oben schon ausführlich dazu geäußert. Es klingt nach objektorientierter Programmierung.

Die Waffen in Xpyderz funktionieren nach einem ähnlichen Prinzip, allerdings im begrenzten Rahmen möglicher auswählbarer Fähigkeiten. (D.h. sie haben Flags, ob sie an Wänden "bouncen" (reflektieren) können oder nicht und wieviele Bounces sie maximal aufnehmen können. Sie haben Flags, ob wenn auf eine Wand eingeschlagen und nicht (mehr "bounced"), ob sie sich dann in andere Geschosse teilen - und in wieviele. Sie haben auch Flags, ob mit einem Schuß eins oder mehrere Geschosse gleichzeitig abgefeuert werden und wenn, in welchem Winkel sie dabei gestreut werden. Sie haben Flags, die die "Rapid Fire" Rate einstellen, d.h. nach wievielen Spiel-Ticks frühestens die nächste abgefeuert wird. Dann gibt es noch Flags für max. Anzahl Waffen die der Spieler von diesem Typ haben kann und ob sie einen Timeout haben und falls ja, wieviele Ticks. Und schlußendlich haben die Waffen auch "Hitpoints", aber nicht, wieviel sie selbst aushalten, sondern wieviel Schadem sie pro Treffer anrichten.

Das ist schon sehr parametrisiert - daher war es für mich auch leicht, neue Waffen in Xpyderz hinzuzufügen. Achja, es gab auch noch ein Flag für diesen "Flitterschleier", den Waffen hinter sich herziehen können beim Fliegen, den nutzen z.B. nur die Raketen (Homing-Missiles).

Allerdings habe ich trotzdem die Steuerung von Waffen von der Spielfigur trotzdem von unterschiedlichen Subroutinen machen lassen, denn sämtliche dieser Waffenparameter braucht die Spielfigur ja überhaupt nicht - wozu also ein Werte-Arsenal mitschleppen? Wozu die Werte prüfen? Die Spielfigur hat wieder andere Werte, die für Schußprojektile nicht brauchbar sind.
zatzen hat geschrieben:Das tollste Spiel des Jahrhunderts wäre ja ein falscher Ansatz.
Es sollte ja klar sein dass ich das nicht erwarten kann. Aber je nachdem wie es wird finden es manche
vielleicht ganz witzig. Für mich selbst wäre es allerdings das tollste was ich je programmiert habe, wobei
ich hier den Begriff "toll" eben nüchtern sehen und vielleicht eher durch ausgefeilt oder ähnliches ersetzen würde.
Mein geplantes Spiel wäre ja ein Baukasten-System und schon interessant sobald ich einen Charakter in ein
leeres (bis auf den Boden) Level setze.
Jedenfalls aus meiner Sicht, weil da eben was passieren würde.
Und das ist genau das, was ich oben meinte. Ohne daß der Charakter irgendeinen "Bedarf" hätte, würde gar nichts passieren. Er würde nicht einmal loslaufen. Er wüßte nicht, in welche Richtung, er hätte auch gar keinen Grund, überhaupt loszulaufen.
MENSCHEN (und auch Tiere, was weiß ich) haben von sich aus Ideen und Bedürnisse.
Bedürfnisse, die zu Aktionen führen wie "Ich hole mir jetzt eine Scheibe Brot, weil ich Hunger habe."
Ideen wie "Ich programmiere jetzt ein Computerspiel - ohne besonderen Grund, sondern einfach nur, weil ich subjektiv gesehen Computerspiele cool finde."
Bedürfnisse wie "Ich programmiere jetzt ein Computerspiel, weil ich beruflicher Spieleprogrammierer bin und das Geld dafür brauche, um mein Bedürfnis nach Nahrung und warmer Unterkunft zu befriedigen."

Computerspielfiguren haben aber keinen Hunger, denen ist nicht kalt, die wollen sich auch nicht fortpflanzen oder, weil die Bits heute besonders frisch und grün aussehen, einfach mal durch den Speicher spazieren gehen. Wenn man sie nicht mit irgend einem Ziel programmiert, tun sie gar nichts.
Der Grund dafür ist ganz einfach: Computer funktionieren so. Die tun nichts "von sich aus". Die bekommen eine Eingabe, verarbeiten diese und geben eine Ausgabe aus. Bis sie eine neue Eingabe erhalten, tun sie gar nichts. Die "im Hintergrund laufenden Prozesse" sind auch nur irgendwann vom Menschen eingegeben worden mit dem Befehl: "Tue das so lange im Hintergrund, bis ich dir etwas anderes befehle."
Und ein Programm ist immer ein fortlaufend abgearbeiteter Prozeß - auch dann, wenn dieser eine Dauerschleife ist.
zatzen hat geschrieben:Klar dauert das alles lange zu bauen, aber ich habe mittlerweile die Vermutung, dass dir das Programmieren nicht so schwer zu schaffen macht wie mir.
Mir wird je nachdem irgendwie richtig schwindlig wenn ich ne Zeit lang programmiere, Grafiken machen ist zwar ne sau Arbeit, aber dabei raucht mir nicht der Kopf.
Um zu programmieren, muß ich mich ebenfalls konzentrieren können. Das mag der Grund sein, wieso ich nach 8 Stunden auf Arbeit mit hirnerweichender Tätigkeit, Sitzen im Neonlicht auf unbequemen Stühlen in einem lauten Großraumbüro zu Hause nicht mehr die Kraft - und schon gar nicht die Konzentration - aufbringen kann, noch etwas Großartiges zu programmieren. Gerade bei Dingen in Assembler werden einem Fehler selten "einfach so verziehen" - oft ist das Ergebnis einfach ein Systemabsturz. Zum Glück bootet System+DOS zusammen bei mir in ca. 20 Sekunden und nicht wie Windows in 10 Minuten.
zatzen hat geschrieben: Was Musik angeht, da hab ich über 20 Jahre Erfahrung und könnte mit dir zusammenarbeiten, allerdings
bevorzuge ich ja einen Tracker mit Leerzeilen, ansonsten ist mein "Repertoire" breit gefächert, und
manches was du von mir gehört hast, gerade aus meiner Anfangszeit um 1994, ist nicht repräsentativ.
Ich hatte ursprünglich sogar mal die Idee, ISM um eine "Trackeransicht" zu erweitern, die die Eingabe im "Trackerdesign" ermöglicht - habe mich wieder dagegen entschieden, aus diesen Gründen:
1.) Der eigentliche Zweck, speichersparend zu entwickeln wird damit ausgehebelt.
Es geht nicht um die Leerzeilen, die ich ja intern einfach mit Längenbefehlen ersetzen könnte. Es geht darum, daß z.B. die ganzen Schleifen-/Sprung-/Unter"programm"-Aufruf-befehle, die ich eigens entwickelt habe, um Wiederholungen zu vermeiden, so gar nicht genutzt werden würden.
2.) Noch wichtiger: Die "Kommunikation mit der Außenwelt"-Befehle gehören nicht zu einem normalen Tracker - in einem Spiel würde ich diese aber zwingend gebrauchen!
3.) Leute, die an die Trackernutzung gewöhnt sind und alles wie Tracker nutzen würden, würden auch die ganzen Hüllkurven-/Wellenform-/Filter-Befehle "links liegenlassen" und alles samplebasiert entwickeln - was ebenfalls völlig dem Paradigma widerspricht, eine speichersparende Methode für Musik zu nutzen - die zudem auch ruhig nach SNES oder C64 klingen darf und soll.
4.) Es wäre wieder ein zusätzlicher Aufwand, eine weitere Ansicht, wieder mit den ganzen Eingabemöglichkeiten umzusetzen - kostet noch mehr Zeit und bringt mich selbst dem "Spiel" kein Stück näher.
5.) Die zusätzliche Ansicht würde wieder Programmspeicher belegen - Speicher, der z.B. dann wieder nicht für Samples zur Verfügung stehen könnte.
6.) Ich denke darüber nach, EVENTUELL ja einen externen Konverter zu schreiben, der das MOD-Fileformat (und vielleicht auch andere Formate) in das ISM konvertiert. Allerdings müßte dann in ISM vieles "softwaremäßig" umgesetzt werden, was manche dieser Tracker als Befehl/Option schon eingebaut haben. Allerdings muß ich das leider hintanstellen, weil ich einfach zu überhaupt nichts mehr komme.
zatzen hat geschrieben: ...also hast du jetzt quasi Echtzeit-Huffman Dekompression für die Sprites?
Dann wäre mein ZVID hinfällig, es sei denn es wäre trotzdem schneller. Müsste man dann mal vergleichen.
Das HABE ich noch gar nicht. Das war eine Idee. Und ob es eine LZW-Kompression wäre, kann ich nicht beurteilen.
Ich habe damals mal ein Bildformat entwickelt, das u.a. für das große XPYDERZ-Logo im Spiel benutzt wird. Dieses speichert senkrecht in 8bit oder 4bit Sequenzen palettenbezogene Pixel, hat aber zusätzlich noch Werte, die definieren: "Jetzt mal X Bytes überspringen" (nicht zeichnen, also die transparenten "Löcher") oder auch "Jetzt mal X Bytes Y zeichnen", also wenn alle folgenden mit gleicher Farbe sind.
Die Senkrechte Speicherung rührt wieder von Mode-X her - außerdem wollte ich es auch mal für große Zeichensätze haben und da ist senkrechte Speicherung praktischer, da bei einem Proportional-Zeichensatz die Zeichenhöhe konstant, die Zeichenbreite jedoch variabel ist.
Alle Spalten haben in dem oben erwähnten Bildformat einen Offset-Wert, d.h. ab wo im Bildfile/Bildspeicher die Spalte startet - somit hat man den Vorteil, wenn das Logo/Bild nur halb zu sehen ist, trotzdem nicht den "Code" der ganzen anderen Spalten vorher zu decodieren zu müssen um zu wissen, wo man mit Zeichnen beginnen kann. Das gab mir aber auch die Möglichkeit, Spalten, die doppelt auftreten, nur 1x speichern zu müssen, denn diese würden einfach mit gleichem Offset in die Spaltenoffsetliste eingetragen werden.
So! Nun habe ich neulich eine Idee gehabt, wie ich einen lustigen Zeichensatz, der quasi wie aus "Bildchen" besteht, möglichst so speichern kann, daß ich nicht pro Zeichen 1 kB oder so brauche und hatte folgenden Ansatz:
Es hatte mich immer schon gestört, daß ich immer nur einn Vielfaches/Teiler von 8 Bits für die Farben benutzen kann - oft sind 4 Farben zu wenig und 16 Farben schon zu viel - oder 16 Farben zuwenig, aber es werden nie im Leben 256 Farben gebraucht. Für 8 Farben oder 32 Farben bräuchte man aber 3 oder 5 Bits - was ein echt beschissener Teiler ist, wenn man immer von Grenzen mit ganzen Bytes ausgehen will.
Aber: Da ich inzwischen Assembler programmiere und mir die "Schieberei" und "Maskerei" nichts mehr ausmacht, habe ich so gedacht, daß man einfach so ein Format entwickeln könnte, das wie folgt funktioniert. Nehmen wir an, ein Sprite hat 21 Farben plus natürlich Transparenz.
Dann speichert man das Sprite z.B. als 5-Bit-Sprite ab, diese werden nacheinander aus einem "Bit-Strom" ausgelesen. Ist das Ergebnis = 0 (also %00000 binär), geht man von Transparenz aus (ist einfacher, in Assembler kann man leicht auf 0 testen) und überspringt den Pixel. Ist Ergebnis <=21, dann folgt eine Farbe, die so wie sie ist gezeichnet wird. die Werte 22-31 wären nun unbenutzt... aber nein! Man definiert z.B. daß die Werte 22-31 bedeuten, daß der folgende Wert 3 bis 12 mal wiederholt wird. (Wieso 3 bis 12? Naja, 1x wiederholen ist Blödsinn. und 2x wiederholen braucht genauso viele 5erBits, als würde man den Wert auch gleich 2x schreiben). Folgt aber dem Wert 22-31 NOCH ein Wert 22-31, so würde sich die Anzahl der Wiederholungen aus den beiden Werten additiv zusammensetzen, d.h. es wären dann nicht die 10 Werte 3-12, sondern die 100 Werte 3-112.
Allerdings würde ich eine weitere Teilung vornehmen, z.B., daß der Initial-Wert nur 22-30 wäre, dann gäbe es 3-11 Wiederholungen im ersten "Durchgang" und alle weiteren wären dann aber wieder mit 22-31 codiert.
Dann wäre der Wert 31 anders belegt: Ihm würde ein ganzes Byte (oder 5er bit) oder mehrere folgen, deren obere Bits =0 wären und die sich zu einem Offset zusammensetzen würden. Sobald das obere Bit=1 wäre, wäre die "Kette" zu Ende und die unteren Bits würden angeben, wieviele der Punkte an anderer Stelle auszulesen sind, für Wiederholungen. Würde man nicht nur 31, sondern z.B. 29, 30 und 31 nehmen, würden diese dann angeben, ob die folgenden "Bytes" als 5, 6, oder 7 Bit gelesen werden sollen.... oder auch 4,5,6... je nachdem.
DAS wäre dann schon sehr ähnlich zu GIF und auch sehr ähnlich zu den Internet-UDP-ARP-Paketen, mit der zu einer URL die zugehörige IP-Adresse abgefragt wird.
Und man könnte, obwohl ein Sprite vielleicht 21+1 Farben hat, trotzdem auch mit 6-Bit arbeiten, falls viele Wiederholungen/Leerräume/Verweise drin wären, würde sich das am Ende evtl rentieren.
Achja, ein "Wiederholungs-Befehl", gefolgt von 0 würde natürlich bedeuten: Soviele Pixel überspringen.

Und ja, das klingt alles sehr kompliziert - ist es auch, aber nur für den ERSTELLER! Das erstellende Programm würde dann mehrere Kombinationen ausprobieren, also im Falle der 21+1 Farben zuerst:
5bit, Grenze bei 32 (also ohne Verweise, nur mit Wiederholungen), dann
5bit, Grenze bei 31 (also mit Verweisen mit nur einer Bitanzahl)
5bit, Grenze bei 30.... usw
5bit, Grenze bei 22 (also ohne Wiederholungen, nur mit Verweisen)
Dann das Ganze noch mit 6, 7, 8bit (mehr dann wohl nicht, macht kaum noch Sinn).
Und alle Endergebnisse gegeneinander vergleichen - denn welches wirklich gute Ergebnisse erbringt, hängt natürlich von den Sprite-Daten ab und dann das benutzen, was den wenigsten Speicher belegt.
Natürlich hätte so ein Sprite auch einen Header, aus Offset, Breite, Höhe, HotspotXY, Flags, dazu kämen noch Flag für Anzahl Bits, Anzahl Farben und Grenze für Verweise, sowie, der Einfachheit halber (bei kleinen Sprites dann weglassen) eine Tabelle mit den Startoffsets für die einzelnen Spalten, diese Offsets wären aber bitbasiert, d.h. die unteren 3 Bits des Offsets würden angeben, ab welchem Bit der Strom gelesen werden muß. Dies wäre nur nötig bei Sprites, die nur "halb zu sehen" sind und die nicht sichtbare Seite (die außerhalb des Bildschirms ist), die "vordere" wäre.
Auch bei so einem Sprite wäre Skalierung weiterhin möglich, ebenfalls auch Spiegelung, sowie das Sprite in alle 4 Hauptrichtungen zu zeichnen. Eine Drehung um andere Werte als 90° hingegen (genau wie das Dithern) wäre ein wahnwitziger Rechenaufwand - denn aus gepackten Daten einen "Nachbarpixel" zu ermitteln, dürfte derartig ausarten, daß damit die Speicherersparnis für die Sprites kaum noch zu rechtfertigen wäre. Bei solchen Drehungen werden ja die Pixel auch "quergelesen" usw.
Da meine Sprites sowieso nie einzeln stehen, sondern immer als Teil einer großen "Grafik" gelesen werden, könnte man hier sogar noch einen Schritt weitergehen und die Verweise für "zu packende Daten, die bereits an anderer Stelle vorkommen" sogar außerhalb eines Sprite-Images erlauben - allerdings mit schlechter werdender "Wartbarkeit" von Sprites - da man diese dann ja nicht mehr nach Bedarf einzeln "ein-/ausblenden" könnte ais dem nutzbaren Speicher.
All das ist natürlich noch nicht mit einem einzigen Bit irgendwo programmtechnisch umgesetzt worden, sondern existiert bisher ausschließlich in meinem Kopf.
zatzen hat geschrieben: ZVID speichert ja, wenn man will, direkt alle Sprites einer Animation in einer Datei und macht dazu einen
einzigen Palettenbereich, und auch redundante Blöcke, die also bei jedem Sprite gleich sind, werden nur
einmal gespeichert. Wenn also bei einer Animation nur der Mund bewegt wird werden im Idealfall pro Sprite (wo das so ist) vielleicht gerade mal 15 Byte gespeichert.
"Zusammengehörige Sprites" werden auch bei mir (und auch jetzt schon) immer in einem einzelnen File gespeichert. Derzeit verschwenden meine Sprites sogar etwas Speicher - das wird durch die Anordnung aber weitestgehend vermieden und wenn ich noch einen 4-Bit-Offset irgendwo einbaue, wäre auch das vermieden.

Derzeit funktionieren meine Sprites so, daß sie alle auf einem "Band" landen, das genau 256 Byte breit und beliebig hoch sein kann. Sie können (derzeit) nur an /16 teilbaren X-Koordinaten auf diesem Band landen, die Y-Koordinate ist natürlich egal.
Wieso diese komische Speicherung?
Nun, ich definiere das "Segment" (Segmente im Real-Mode definieren ja einen /16 teilbaren Speicheroffset) für die Sprites einfach an SPRITESEGMENT, d.h. da belege ich Speicher für die Sprites, d.h. für das "Band", die Grafik, die 256*Y groß ist)
Wenn nun jedes Sprites in dieses "Band" an 16er-X-Adressen getan wird, hat also jedes Sprite genau einen "Segment+16er-Offset", also quasi ein neues Segment als Anfangsadresse. Also ist der Offset des Sprites, bezogen auf das neue Segment, für den Punkt 0;0 auch genau 0.
Dadurch, daß aber das "Band" 256 Bytes breit ist, ist auch der Abstand zwischen 2 Sprite-Zeilen IMMER genau 256, egal, wie breit oder schmal das Sprite ist! Man liest ja sowieso nur bis zur Sprite-Breite - da ist es egal, ob rechts (oder "links") davon noch andere Sprites liegen!
Das gute an ASM ist, daß es da so schöne 16-Bit-Register gibt, die man auch in 2 8bit-Register teilen kann, und BX (das in BH und BL teilbar ist) ist zusätzlich auch noch fähig, als Indexregister benutzt zu werden. Wenn man nun BL auf die gewünschte X-Koordinate innerhalb des Sprites und BH auf die Y-Koordinate im Sprite setzt (und z.B. das Segment für das Sprite vorher einem Segmentregister wie z.B. ES zuweist), kann man mit ES:BX direkt den Farbwert für den Spritepixel auslesen.
Für 4-Bit-Sprites ist das Ganze ein wenig komplizierter (da werden Befehle wie SHR AL,4 und AND AL,$F gegeneinander getauscht usw.)

Für die obengenannten neuen gepackten Sprites wäre die Speicherung dann natürlich eine ganz andere, und wie bereits erwähnt, würden die Möglichkeiten des Drehens (um andere als 90°) und Dithern entfallen.
Derzeit versuche ich aber, mit den vorhandenen Spriteroutinen erst einmal wieder etwas auf die Beine zu stellen, ich entwickle so viel und nutze es dann kaum...
zatzen hat geschrieben:Deine Erläuterungen zu den Sprites und den Hotspots muss ich mir nochmal in Ruhe durchlesen wenn es soweit ist.
Kein Problem.
zatzen hat geschrieben: Ich kann abschliessend nochmal sagen dass meine Game-Engine mit dem Spiel selbst wachsen soll.
Heisst, sagen wir mal, ich habe einen Sprite-Animation. Dann will ich die auf dem Bildschirm hin und her
wandern lassen, also programmiere ich diese Mögichkeit in die Engine usw.
Ich schätze aber, ich muss es doch anders angehen, da eben dieses grafische, woran man spontan denkt,
dass ein Spiel damit beginnen sollte, eben nicht der Ausgangspunkt oder die erste Grundlage sein sollte.
Ich muss mich hier in aller Ruhe hinsetzen und erstmal ein mehr oder weniger vollständiges
Gesamtkonzept erstellen, und dann beginnen zu programmieren.
Oder auch, wenn es der richtige erste Ansatz ist, eine Figur zu schaffen, d.h. die Sprites dafür und den Sound, diese definieren und die Engine so ausstatten, dass diese Figur zum Leben erweckt wird.
Naja, ich sage es mal so: Für einen Ansatz mit "völlig frei agierenden" Objekten wäre aber mein Ansatz (Sprites und Hintergrund sind einzelne unabhängige Dinge) wohl die bessere Wahl gegenüber Deinem Ansatz (Sprites/bewegliche Teile als Teil einer Gesamtanimation). ZVID, wenn es so ist, wie ich es verstanden habe, wäre wohl eher die bessere Wahl für Zwischensequenzen.
zatzen hat geschrieben:Danke für deine Erläuterungen zu Point&Click Adventures! Sehr aufschlussreich.
Tja, wenn ich die Zeit hätte, würd ich ein Adventure bauen. Programmiererisch wäre es eher weniger ein Problem für mich. Aber die ganzen Grafiken, Texte, Sounds... Wer soll das alles machen?
zatzen hat geschrieben:Tatsächlich soll es schon eher in diese Richtung gehen und weniger in die Richtung Jump&Run.
Naja, wie gesagt, es geht wahrscheinlich rein technisch nur nicht "alles auf einmal". Einen Wechsel zwischen Adventure und Arcade - so etwas hatte ich mir selbst schonmal vorgestellt. Aber ein Adventure lebt von Überraschungen - ein Computer kann keine "überraschenden Wendungen" selbst generieren. Das ist zu kompliziert für einen blöden Rechenknecht.
zatzen hat geschrieben:Ich muss mir dazu auch einfach nochmal diverse Spielformate ansehen.
Diesen Satz verstehe ich nicht so ganz. Geht es darum, Spiele anzusehen/zu spielen und den Aufbau zu analysieren?

Re: Eigenes Videoformat

Verfasst: Mi 2. Dez 2015, 14:16
von DOSferatu
zatzen hat geschrieben: Ein Nachtrag, der einem als Anfänger vielleicht nicht ganz einleuchtet:

Ich gehe richtig in der Annahme, dass man seine Programme so auslegen sollte,
dass Grafik und Ton eben nur die *Anzeige* sind, und dass das Programm oder
Spiel also auch quasi "blind" funktionieren muss. Oder?
Richtig erkannt! Genau so ist es!
Für den Computer sind das alles schließlich nur "Daten". Daten sind für den Computer viel einfacher in Zahlenform zu verwalten, als wenn er z.B. auch noch Grafiken analysieren müßte - die zwar technisch auch aus Zahlen bestehen, aber komplexer angeordnet sind.

Ein Gegenbeispiel aus der Welt des C64:
95% der Spiele auf dem C64 - und nahezu 100% der scrollenden Spiele (von ganz wenigen Ausnahmen abgesehen!) sind nicht Vollgrafik, sondern Textmode! Das liegt daran, daß man auf dem C64 die Textzeichen nach Belieben ändern kann - und auch daran, daß es den "Multicolor-Mode" auch für den Textmode gibt. Multicolor bedeutet hier: zwei Bits werden immer zu einem "Langpixel" zusammengefaßt: 00=Hintergrundfarbe 01=feste Farbe1, 10=feste Farbe2, 11=Zeichenfarbe.
Somit kann jedes Zeichen 3 von 16 verschiedenen Farben plus eine von 8 Farben haben. (Das ist so, weil die Zeichen entweder Farbe 0-7 haben können, dann sind sie "monochrom", d.h. sie haben "normale Pixel", 8x8, in Farbe 0-7 oder Hintergrundfarbe. Wenn sie "Farbe 8-15" haben, haben sie AUCH Farbe 0-7 und das oberste Bit schaltet Multicolor ein (wenn zusätzlich das allgemeine Multicolor-Bit im VIC gesetzt ist). Ohne Multicolor-Mode haben Zeichen Farben 0-15 mit Hintergrundfarbe.
Diese Zeichen werden nicht mehr als Zeichen benutzt, sondern als Bestandteile von Grafikelementen, sie werden quasi zu größeren Dingen zusammengesetzt und ergeben so die Elemente, aus denen ein scrollendes Level besteht.

Das wird so gemacht, weil der C64 - ich gehe mal die Beispiele im PAL-Mode - mit 984248.4 Hz getaktet ist (knapp 1MHz). Der Bildschirm wird mit 50 Hz (50x pro Sekunde) aufgebaut, somit 19704 Takte PRO BILD bleiben, um das ganze Bildzu refreshen. Ein Vollgrafik-Bild braucht auf auf dem C64 genau 10000 Bytes, selbst wenn man obenoder unten 40 Zeilen für die Anzeige ließe wären es noch 8000 Bytes. Ein normaler C64 Befehl benötigt zwischen 2 und 6 Takten, im Schnitt eher 4-5 Takte. Ein Vollgrafikbild umzukopieren wäre also niemals in 1/50 Sekunde machbar. Ein Bild das nur aus "Zeichen" besteht, hat 2000 Bytes (1000 Zeichen, 1000 Farbbytes), zieht man vielleicht noch 40 Zeilen (5 Zeichenzeilen) für eine Anzeige ab, sind es noch 1600 Bytes. Manche alten Spiele kopieren auch nichtmal den FARB-RAM mit, sondern lassen alles quasi "4-farbig", brauchen dann 800 oder noch weniger Bytes pro Bild kopieren - das ist auch für den C64 machbar.

So - und nun zum Beispiel, das ich damit verdeulichen will:
Weil die Bildelemente ja aus Zeichen zusammengesetzt sind und Zeichen ja quasi alle eine Nummer haben, ist es für eine Figur oder ein Geschoß möglich, ein Zeichen aus der gewünschten Position im Bild auszulesen und anhand seiner Nummer festzustellen, ob es "feindlich", "durchgängig" oder "fest" ist oder was auch immer - je nach Definition.

Das ist eines der wenigen Beispiele, wo - quasi eher aus praktischen Gründen - die Werte im "Grafikpuffer" (also dem Speicherbereich, auf den man den Grafikchip zur Anzeige "umgebogen" hat) gleichzeitig direkt als Daten zur Aktion/Reaktion herangezogen werden.

Anmerkung: Die Sprites beim C64 agieren komplett unabhängig zur restlichen Grafik - eine Grafik kann "auch unter einem Sprite wegscrollen" - selbst wenn der Bildschirm "gelöscht" wird (also Zeichen alle auf Leerzeichen...) interessiert das den Sprite recht wenig. Diese werden einzeln an-/ausgeschaltet, an Bildschirmkoordinaten gesetzt (die auch außerhalb oder teilweise außerhalb des sichtbaren Bildbereichs sein können), sie erhalten ihre Farben und Farbmodi aus komplett anderen Registern. Lediglich ihr "Aussehen" wird im normalen Speicher festgelegt - an einer /64 teilbaren Adresse stehen 63 Bytes (3 Bytes nebeneinander, 21 Zeilen), die das Spriteimage beschreiben. (Man kann aber natürlich von Spriteposition auf Bildschirmposition umrechnen.)

Es gibt zwar auch Register im VIC (Grafikchip des C64), der bei Kollisionen von Sprites mit dem Hintergrund reagieren kann - ABER - selbst in sehr alten Spielen wurde das kaum genutzt, da sich so ja im Hintergrund nur "Leere" hätte befinden dürfen, d.h. bei jeder Wolke am Himmel, vor der die Figur entlanggesprungen wäre, hätte der IRQ schon ausgelöst. Auch die Sprite-Sprite-Kollisionen wurden später eher durch die bekannte "Abstandsvergleich" Methode ermittelt. Grund ist, daß man später auch größere Figuren gebaut hat, indem man kleine Sprites zusammengesetzt hat - sowie das als "Sprite-Multiplexing" bekannt gewordene Verfahren, bei dem durch einen Trick mit den Rasterstrahlverhalten mehr als die eigentlich vorhandenen 8 Sprites des C64 auf dem Bildschirm dargestellt wurden. Beide Verfahren erzeugen natürlich coole Effekte - sind aber nicht mehr geeignet für die hardwaremäßige Sprite-Sprite-Kollisionserkennung.

Ja, ich programmiere schon sehr lange...

Re: Eigenes Videoformat

Verfasst: Mi 2. Dez 2015, 14:31
von zatzen
Wirklich menschliches Verhalten zu programmieren habe ich ja auch nicht vor.
Klar kann ich auch andere Charaktere realisieren als Menschen, aber mir kam da nur der Gedanken
wegen dem Sprechen. Eine Art simple KI könnte es aber werden, mit extrem zwanghaften Verhalten
der Charaktere, mehr wie Roboter.
An eine richtige KI die einen Menschen nachahmen soll, daran denke ich nicht im Traum.

Für Sims kann ich mich auch nicht wirklich begeistern. Aber deshalb, weil da alles nur so angedeutet
ist und die Figuren eher alle nur in ihrem Status wachsen, sonst aber irgendwie nicht viel passiert.

Ich habe mir mein Endziel in dem geplanten Spiel noch nicht gesetzt, bin mir nur schonmal gewiss,
dass es diese Fülle an halbwegs intelligenten, oder auch doof und gestört umherlaufenden, Charakteren
haben soll.
Diese könnten ja auch eine Hürde darstellen die es schwieriger macht, ans Ende des Levels zu kommen.
Oder man muss zusehen dass alle ans Ziel kommen, womit das ganze schon eher wie ein etwas
komplexeres Lemmings wäre.


So ein Spielprinzip wie "Game of Live" interessiert mich weniger und deshalb kannte ich es bisher nicht.
Das ist irgendwie bei mir so ein Phänomen, dass ich nur das kenne was ich faszinierend finde.
Dieses Spiel mag ja programmiertechnisch höchst anspruchsvoll sein, ist aber nicht mein Ding,
da pflanze ich mir lieber wirklich Tomaten oder irgendwas an.
Ich habe auch nie "Creatures" angerührt, obwohl es vor ca. 20 Jahren in aller Munde war. Solche
Lebenssimulationen in die man viel Zeit investieren muss fesseln mich einfach nicht, und so auch
Sims nicht. Wenn ich kreativ werde, dann lieber in echt, zum Beispiel eben Programmieren, oder
Musik machen, oder Lautsprecher bauen...
Aber nicht an einer Simulation hängen und eine virtuelle Figur aufpäppeln.
Ok, aber technisch gesehen sicherlich passend zum Thema, nur würde ich etwas anderes draus machen,
und ich erwarte aber auch gar nicht dass jemand den Klamauk den man mit meinem Konzept realisieren
könnte zu würdigen weiss.
Jedenfalls habe ich so die Nase voll von Spielen wo es um verlieren oder gewinnen geht, dass für mich
der Schwierigkeitgrad nicht das Maß aller Dinge ist. Ich habe auch jeglichen Ehrgeiz gegenüber
Wettbewerben verloren, und will und brauche diese falsche Art von Stolz nicht. Also ganz einfach, wenn
man mit mir ein Spiel spielt, macht es für mich keinen Unterschied ob ich verliere oder gewinne. Es sei
denn, das Spiel macht mir auch so Spass, ohne Aussicht darauf wie es ausgeht, dann kann Gewinnen
ein i-Tüpfelchen sein.

Nochmal wegen Sims:
Befürchtet hatte ich eine starke Ähnlichkeit weil die Charaktere da auch parallel existieren und "leben".
Anders werden wird es aber dadurch, dass meine Charaktere viel aktiver wären und es nicht um die
gleichen Themen geht wie soziale Kontakte oder berufliche Qualifikationen. Vielmehr würden bei mir
irgendwelche bescheurten Freaks (teilweise Amok) herumlaufen, vielleicht ähnlich als wären es Feinde,
und vielleicht sind es manchmal Feinde, aber das hängt alles von den Definitionen ab. Das ganze
erfordert eine gute Überlegung, aber für unmöglich halte ich es nicht.
Du kannst dir auf Youtube mein "TS und Besen kloppen sich in Prag" ansehen, das ist total simpel und
habe ich mal an einem Nachmittag gemacht, aber es gibt ungefähr die Mentalität wieder die ich in
meinem Spiel haben will, wenn auch nicht die ganze Zeit immer nur Krach und Bumm, sonder sehr
viel dynamischer, vor allem auch was die Handlungen angeht.


Zum Thema Flags:
Da kämen bei mir z.B. Dinge rein wie
- wie schnell langweilt er sich (wie lange kann er einfach nur rumstehen)
- wann erzeugt welches Objekt (z.B. Bombe)
- auf welche Gesprächsthemen reagiert er wie
...
Naja das wird alles noch, ist ja sehr vage formuliert und
gerade die letzten beiden muss man sicher noch anders machen.


Ich schreibe später gerne weiter!
Bis dann...

Re: Eigenes Videoformat

Verfasst: Fr 4. Dez 2015, 10:11
von DOSferatu
zatzen hat geschrieben:Wirklich menschliches Verhalten zu programmieren habe ich ja auch nicht vor.
Klar kann ich auch andere Charaktere realisieren als Menschen, aber mir kam da nur der Gedanken
wegen dem Sprechen. Eine Art simple KI könnte es aber werden, mit extrem zwanghaften Verhalten
der Charaktere, mehr wie Roboter.
An eine richtige KI die einen Menschen nachahmen soll, daran denke ich nicht im Traum.
Ja, aber gerade und besonders Sprechen wäre ja kompliziert. Eine auch nur einigermaßen gescheit wirkende Kommunikation zu entwickeln wäre schon eine Höllenarbeit. Es sei denn, man verzichetet auf sämtliche Grammatik und läßt die Figuren reden wie Zombies. Sollen Spielfiguren untereinander kommunizieren, wäre hier wohl eine Art "Meta-Sprache" besser - eine für Maschinen verständlichere Sprache - da sonst jede Figur beim "sprechen" zunächst Routinen bräuchte, die aus dem gewollten Inhalt einen "deutsch-verständlichen" Satz macht - und für die andere Figur, die das "hört"/"liest", bräuchte es einen umfassenden Parser, der die ganze Grammatik analysiert und so den Inhalt wieder in für Computer brauchbare Daten umwandelt - so daß sie darauf reagieren kann.
zatzen hat geschrieben: Für Sims kann ich mich auch nicht wirklich begeistern. Aber deshalb, weil da alles nur so angedeutet
ist und die Figuren eher alle nur in ihrem Status wachsen, sonst aber irgendwie nicht viel passiert.
Naja, wie ich bereits erwähnte: Computerfiguren haben keine eigenen Bedürfnisse und keinen eigenen Antrieb. Alles was danach AUSSIEHT, ist programmiert. Alles, was an Bedarf und Antrieb nicht programmiert wird, ist nicht vorhanden. "Von allein" tun Figuren gar nichts. Eine Figur ist ja nur ein (mehr oder weniger umfangreicher) Datensatz. Und dieser ändert seinen Status nicht, wenn keine Einwirkung "von außen" geschieht. Ob diese Einwirkung durch Steuerdaten eines Spielers, durch einen Zufallsgenerator, einen zeitlichen Ablauf (der alle X Millisekunden irgendetwas ändert) oder ein Skript erfolgt, ist dabei egal - aber "von selbst" passiert erstmal nichts.
zatzen hat geschrieben: Ich habe mir mein Endziel in dem geplanten Spiel noch nicht gesetzt, bin mir nur schonmal gewiss,
dass es diese Fülle an halbwegs intelligenten, oder auch doof und gestört umherlaufenden, Charakteren
haben soll.
Naja - aber wer soll das spielen? Ich meine: Was macht der Spieler dabei?
zatzen hat geschrieben: Diese könnten ja auch eine Hürde darstellen die es schwieriger macht, ans Ende des Levels zu kommen.
Oder man muss zusehen dass alle ans Ziel kommen, womit das ganze schon eher wie ein etwas
komplexeres Lemmings wäre.
Ja, wie ich schon sagte: Es ist schwer, im (Computer-)Spielebereich irgendetwas "komplett neues, noch nie dagewesenes" zu machen - weil eben sehr viel schon dagewesen ist.
In einem der Foren, in denen ich XPYDERZ erwähnte, haben auch Leute Vergleiche mit anderen Spielen gezogen - Spiele, die ich nie gespielt oder gesehen oder auch nur deren Namen gehört hatte, und trotzdem besteht wohl Ähnlichkeit zwischen XPYDERZ und einigen anderen Spielen, selbst was das Spielprinzip oder sogar einzelne Grafikelemente angeht. Nur hatte ich bei XPYDERZ ohnehin nie den Anspruch, "etwas völlig neues" zu machen - vielmehr war es damals eigentlich eine Art "Experiment" gewesen, das irgendwann "interessant genug" geworden war, um ein Spiel daraus zu machen.
zatzen hat geschrieben: So ein Spielprinzip wie "Game of Live" interessiert mich weniger und deshalb kannte ich es bisher nicht.
Dieses Spiel mag ja programmiertechnisch höchst anspruchsvoll sein, ist aber nicht mein Ding,
da pflanze ich mir lieber wirklich Tomaten oder irgendwas an.
Naja, "Conway's Game of Life" ist ja auch kein Spiel, sondern quasi eine Simulation mit mathematischem Ansatz. Conway selbst hat das auch nicht auf einem Computer erfunden, sondern hat es auf einem Go-Spielbrett mit den bekannten Go-Steinen entwickelt. Er hatte sich damals selbst nicht vorgestellt, daß bestimmte "Elemente" sich derart "entwickeln" können mit diesen einfachen Regeln.
Das Ganze auf einem Computer umzusetzen ist eigentlich nur ein Mittel, um es bequemer zu machen, teils hunderte / tausende von Spielsteinen ("Zellen") korrekt agieren zu lassen. Auf so einem Spielbrett, manuell, entstehen dabei ja auch schonmal Fehler.
zatzen hat geschrieben:Das ist irgendwie bei mir so ein Phänomen, dass ich nur das kenne was ich faszinierend finde.
Naja, bei mir funktioniert das nicht so wirklich. Ich WÜRDE GERN nur Dinge kennen, die ich faszinierend finde - aber bedingt durch Einflüsse aus meiner Lebens-Umwelt lerne ich leider auch Dinge kennen, die mich nerven, von deren Existenz ich aber trotzdem erfahre.
Ein Beispiel: Ich wäre z.B. auch froh, wenn manche (viele) Dinge der von TV Sendern selbstgemachten Shows/Events nie überhaupt den kognitiven Bereich meines Hirns erreicht hätten - so daß Dinge wie "Big Brother", und diese ganzen Kuppelshows, Scripted Reality, Castingshows, Talkshows und ähnlicher Dreck überhaupt nicht mein Bewußtsein erreicht hätten. Ich schaue so ein Zeug überhaupt nicht - aber es wird eben trotzdem darüber geredet, es wird andererorts thematisiert... Natürlich ist TV nicht "die Welt" - und seit einigen Jahren sehe ich fast überhaupt nicht mehr fern - aber es ist ja auch nur ein Beispiel.

Andere Beispiele sind dieser ganze Krieg/Terrorismus/religiöser Fanatismus - alles nur Dinge, an denen man sieht, wie dumm der größte Teil der Menschheit ist: Selbst Leute, die selbst nicht mitmachen, tolerieren oder gutheißen viele sehr dumme Dinge. Daß Menschen im Durchschnitt recht dämlich sind, ist ja kein Geheimnis - aber andauernd (in Zeitungen, TV, aber auch persönlich auf Arbeit usw) das alles mitzukriegen und immer wieder daran erinnert zu werden "von Idioten umzingelt" zu sein... Das sind auch Dinge, die ich eigentlich auch nicht "andauernd wissen will".

Es gibt im Gehirn leider keine "F8-Taste", um Dinge "ungesehen", "ungelesen", "ungehört" zu machen - der ganze Müll und Ballast ist immer wieder da und stürzt auf mich ein. Im Urlaub habe ich es jetzt endlich mal geschafft, von der Arbeit komplett abzuschalten. Ein normales Wochenende reicht dafür bei mir schon nicht mehr aus - ich bin immer nur genervt und gestreßt...
zatzen hat geschrieben: Ich habe auch nie "Creatures" angerührt, obwohl es vor ca. 20 Jahren in aller Munde war. Solche
Lebenssimulationen in die man viel Zeit investieren muss fesseln mich einfach nicht, und so auch
Sims nicht. Wenn ich kreativ werde, dann lieber in echt, zum Beispiel eben Programmieren, oder
Musik machen, oder Lautsprecher bauen...
Naja, wie gesagt - "Game if Life" ist kein wirkliches Spiel, eher eine selbstlaufende Simulation. Ich hatte damals nur die Idee, diese Simulation etwas weiterzuführen und durch ein Eingreifen von außen etwas interessanter zu machen.
Und die Art "Figuren, die miteinander kommunizieren und herumlaufen und agieren - mit gegebener Möglichkeit eines Spielers, gelegentlich einzugreifen" - also das, was Du in einem Deiner letzten Postings als ungefähre Annäherung an Deine Spielidee umrissen hast - hat mich eben an dieses "erweiterte Game of Life" erinnert.
Ich sage es mal so: Jedes Brettspiel, das mit Würfeln gespielt wird, ist teilweise eine Simulation. Hat ein Spieler mehrere Figuren, bleibt ihm wenigstens noch die Möglichkeit (innerhalb gegebener Regeln), zu bestimmen, WELCHE seiner Figuren er zieht. Ansonsten sind die Spieler ja dem Würfel komplett ausgeliefert und machen einfach nur auf dem Brett nach, was der Würfel anzeigt.
zatzen hat geschrieben: Aber nicht an einer Simulation hängen und eine virtuelle Figur aufpäppeln.
Ok, aber technisch gesehen sicherlich passend zum Thema, nur würde ich etwas anderes draus machen,
und ich erwarte aber auch gar nicht dass jemand den Klamauk den man mit meinem Konzept realisieren
könnte zu würdigen weiss.
Naja, ich versuche die ganze Zeit zu verstehen, was genau der Inhalt des Spiels sein soll. Wenn es der Computer nicht nur "mit sich selbst spielen" soll, muß es ja irgendwelche Aktionen geben, die der Spieler dabei tut.
zatzen hat geschrieben: Jedenfalls habe ich so die Nase voll von Spielen wo es um verlieren oder gewinnen geht, dass für mich
der Schwierigkeitgrad nicht das Maß aller Dinge ist. Ich habe auch jeglichen Ehrgeiz gegenüber
Wettbewerben verloren, und will und brauche diese falsche Art von Stolz nicht.
Ach, so eng sehe ich das nicht. Und - es geht ja nicht um Score oder um "wer die meisten Abschüsse hat" oder "wer als erster über die Ziellinie fährt".
Es geht schlichtweg darum, ob es überhaupt ein Ziel gibt, das der Spieler in diesem Spiel verfolgen soll oder nicht. Ohne Ziel "vor sich hin spielen", so etwas gibt es auch - das ist dann eben so etwas wie "Sims", so es kein wirkliches Ende gibt, sondern man nur immer an den Figuren und wasweißich, Einrichtung (keine Ahnung, nie selbst gespielt) herumdoktort und wo es kein "besser" oder "schlechter" gibt, sondern "einfach nur machen".
Und das ist es, was ich meine: Es gibt da (meiner Meinung nach) nur zwei Wege:
Entweder es GIBT ein Ziel - oder - es GIBT KEINS.
Gibt es ein Ziel, ist es quasi immer ein "Wettbewerb". Das muß ja nicht mit/gegen andere Spieler sein. Es kann auch gegen den Computer (Computerfiguren/-elemente) oder gegen die Zeit gehen oder darum, ein Rätsel auf die richtige Art zu lösen.
Gibt es kein Ziel, ist das Ganze eher so ein "mal gucken was passiert" Spiel und das ist dann wie Sims oder ähnliche Simulationsspiele. Aber selbst bei Siedler (ebenfalls nie gespielt) oder so haben die Macher es so gemacht, daß es langfristigere Teilziele/Teilerfolge gibt, indem man es sich leisten kann, größere Städte zu bauen, mehr Menschen anzusiedeln, deren Lebensstandard zu erhöhen...
Das liegt einfach daran, daß es wohl nur ganz wenige Menschen auf der Welt gibt, die bei einem Spiel quasi "überhaupt nichts wollen" - also weder Punkte erzielen, Dinge sammeln, weiterkommen wollen oder sonst irgendwas.
Fast alle Leute fänden es total langweilig, wenn man überhaupt nicht weiß, was in dem Spiel zu machen ist, um dann irgendeinen wie auch immer gearteten Effekt damit zu erzielen, über den man sich freut. Die meisten Leute würden so etwas nicht mehr als Spiel bezeichnen, weil da "nichts zu spielen" ist.
zatzen hat geschrieben:Also ganz einfach, wenn man mit mir ein Spiel spielt, macht es für mich keinen Unterschied ob ich verliere oder gewinne. Es sei denn, das Spiel macht mir auch so Spass, ohne Aussicht darauf wie es ausgeht, dann kann Gewinnen ein i-Tüpfelchen sein.
Naja, das mag ja sein. Aber es muß ja trotzdem "in irgendeine Richtung gehen". Selbst bei "Mensch-ärgere-dich-nicht" zieht man ja die Figuren "vorwärts, dem Ziel entgegen" und nicht rückwärts oder kreuz und quer. Und das, was Du beschreibst, klingt eher nach "wir ziehen Figuren vorwärts, rückwärts, egal um wieviele Felder, weil es gar kein Zielfeld gibt und das, was an dem Spiel den Spaß ausmacht, ist der Vorgang an sich - in diesem Fall: Plastikmännchen auf einer bunten Pappe hin-und-herzuschieben".

Aber, ich sage es mal so: Das mag möglich sein - aber ohne die geringste Herausforderung macht fast
keinem irgendein Spiel Spaß. Der Spaß ergibt sich daraus, eine Herausforderung zu meistern und dafür belohnt zu werden. Das klingt sehr einfach und "pawlowisch", aber genau das ist es, was ein Spiel normalerweise ausmacht. Und wenn es weder eine Herausforderung noch ein Erfolgserlebnis gibt, wird es wohl niemand spielen wollen (weil es ja nichts zum Spielen gibt) - und genaugenommen fällt so etwas dann selbst im weiteren Sinne nicht mehr in die Kategorie "Spiel".
Wenn man nur beobachtet ist es eine Animation / ein Film. Wenn man eingreifen kann, ist es ein Spiel. Wenn man wie ein Zufallsgenerator eingreifen kann, d.h. man tut etwas ohne zu wissen, was das bewirkt, dann ist es auch kein Spiel, sondern eher ein Demo.
zatzen hat geschrieben:Nochmal wegen Sims:
Befürchtet hatte ich eine starke Ähnlichkeit weil die Charaktere da auch parallel existieren und "leben".
Anders werden wird es aber dadurch, dass meine Charaktere viel aktiver wären und es nicht um die
gleichen Themen geht wie soziale Kontakte oder berufliche Qualifikationen. Vielmehr würden bei mir
irgendwelche bescheurten Freaks (teilweise Amok) herumlaufen, vielleicht ähnlich als wären es Feinde,
und vielleicht sind es manchmal Feinde, aber das hängt alles von den Definitionen ab. Das ganze
erfordert eine gute Überlegung, aber für unmöglich halte ich es nicht.
Fast nichts ist unmöglich auf dem Computer umzusetzen.
Aber: Das mag alles sein - dann ist es aber trotzdem wie Sims oder eben eine beliebige andere Lebenssimulation. Die Art/Qualität/Menge der möglichen Aktionen ändert ja nicht das Genre an sich. Das allererste Mario ist ein Jump'n'run und das allerneuste Giana Sisters ist immer noch ein Jump'n'run.
Es wäre also wie ein "Sims deluxe", aber es wäre auch nichts anderes als das.
zatzen hat geschrieben: Du kannst dir auf Youtube mein "TS und Besen kloppen sich in Prag" ansehen, das ist total simpel und
habe ich mal an einem Nachmittag gemacht, aber es gibt ungefähr die Mentalität wieder die ich in
meinem Spiel haben will, wenn auch nicht die ganze Zeit immer nur Krach und Bumm, sonder sehr
viel dynamischer, vor allem auch was die Handlungen angeht.
Naja, sieht aus wie "Street Fighter in doof"... Wüßte jetzt nicht, ob das etwas wäre, das ich spielen würde.
zatzen hat geschrieben: Zum Thema Flags:
Da kämen bei mir z.B. Dinge rein wie
- wie schnell langweilt er sich (wie lange kann er einfach nur rumstehen)
- wann erzeugt welches Objekt (z.B. Bombe)
- auf welche Gesprächsthemen reagiert er wie
...
Naja das wird alles noch, ist ja sehr vage formuliert und
gerade die letzten beiden muss man sicher noch anders machen.
Ja, ich verstehe schon, was Du meinst. Klingt aber trotzdem alles mehr nach "Computer spielt mit sich selbst" als nach "Mensch darf mitspielen".
zatzen hat geschrieben:Ich schreibe später gerne weiter!
Bis dann...
Kein Problem. Ich lese fleißig mit und versuche nachzuvollziehen/zu analysieren.

Schlußendlich kann ich dazu sagen:
Insgesamt liest sich das alles nicht wirklich so, als könnten wir an einem gemeinsamen Spielprojekt arbeiten, da unsere Vorstellungen, was ein Spiel ausmachen sollte, wirklich so grundverschieden sind, daß man daraus einfach nichts "zusammenpassendes" machen könnte.

Ich - weil Programmierer - denke da immer eher mathematisch und für mich ist alles immer "ergebnisorientiert". Ein Ergebnis muß dabei kein Spielende oder höchster Score sein, es kann auch eine Reihe von Zwischenerfolgen in einem Spiel sein - und wenn's ein Adventure ist, in dem es witzige Momente gibt und es nur darum geht, die Story weiterzuführen.

Aber mein Verstädnis und Verstand reicht einfach nicht aus, mir etwas vorzustellen, was einerseits ein Spiel, das keine Simulation/Demo ist sein soll und andererseits aber gar keine Richtung/Verlauf/Ziel hat. Das ist zu abstrakt für mich. Ich meine: Was nützen Parameter, wenn diese "egal" sind, d.h. keine Wertigkeit besitzen? Was nützt es, wenn ein Spieler eingreifen kann, wenn er gar keinen Grund dazu hat?
Selbst in einem Adventure, selbst im kleinsten Denk- oder Geschicklichkeitsspiel gibt es irgend etwas, "wozu das Spiel da ist" und was der Spieler dann lösen/erledigen will/soll. Alles andere ist für mich Simulation/Demo/Film.

Ich akzeptiere vollends, daß es so etwas geben kann oder möglich sein kann und ich nur zu dumm bin, um es zu verstehen - aber ich wüßte nicht, an welcher Stelle in das vorgestellte Konzept hier noch ein Spieler hineinpaßt.

Ich sage mal so: Ich verstehe Konzepte wie "Der Weg ist das Ziel". So geht es mir ja z.B. auch beim Programmieren: Nicht das Endprodukt ist das wichtigste, sondern der Spaß am Fertigungsprozeß. Aber: Auch der Fertigungsprozeß (wie "Prozeß" ja schon sagt) ist ein Weg - etwas mit einer Richtung - von "nichts" über "unfertig", "halbfertig" zu "fertig". Man weiß, was schon getan ist, was noch getan werden muß und evtl auch, ob an "schon getanen" Dingen noch etwas "besser getan" werden könnte. Man "de-programmiert" nicht, also man hat nicht ein fertiges Ding und baut es auseinander, bis nichts da ist. So etwas gibt es zwar auch, ist eben Destruktion, das Gegenteil von Konstruktion - aber diese hat ebenfalls eine Richtung an deren Ende etwas fertig (oder eben fertig kaputt) ist.

Man kann auf so einem Weg auch Abzweigungen beschreiten - und OH VERDAMMT, wie viele Abzweigungen ich schon beim Programmieren beschritten habe auf dem Weg zum Ergebnis, kann ich gar nicht mehr zählen. Aber ich weiß trotzdem noch, was ich am Ende haben will. Aber das "Der Weg ist das Ziel" Konzept beinhaltet nicht, sich ohne Richtung auf der Stelle zu drehen und zu warten, daß etwas passiert (und, was Computer angeht, passiert da ja bekanntlich von allein gar nichts).

Und auch bei Spielen, wo "der Weg das Ziel" ist - und bei vielen Adventures ist es das (denn das Ende ist gar nicht so interessant wie das ganze Spiel an sich, aber das trifft auch auf viele andere Spielgenres zu) - also auch bei "der Weg ist das Ziel" Spielen ist dieser Weg ein fortlaufender Prozeß mit Änderungen und Überraschungen - die man erlebt/gesehen/gelernt hat und nicht mehr "unsehen"/"unerleben"/"unlernen" kann, weil der Mensch die Zeitlinie eben nur in die eine Richtung nehmen kann. Gibt man einem Spieler keinerlei Grund, irgendeine Aktion auszuführen (und wenn es auch nur das Freilegen eines Gags ist oder das Erzeugen irgendeiner anderen Reaktion), wird es für einen Spieler öde. Spieler wollen etwas zu spielen haben.

Du siehst schon: Mir fällt es äußerst schwer, mir ein derartiges Konzept überhaupt irgendwie vorzustellen - das scheint eine Abstraktionsebene zu sein, die mein Verstand einfach nicht überschreiten kann.

Schade daran finde ich jetzt nur, daß ich, bedingt durch Deine älteren Werke, die so in Richtung "storygetriebene Arcade" gingen, noch davon ausgegangen war, daß an Spielen dieser Art und ähnlicher auch weiterhin Interesse bestände, was ja dann eine Zusammenarbeit an einem Spielprojekt ermöglicht hätte. Deine derzeitigen Vorstellungen von einem Spiel hingegen sind für mich einfach technisch nicht umsetzbar, da mir bereits das Verständis dafür fehlt, wie sie überhaupt als Spiel funktionieren sollten - und selbst wenn ich sie so umsetzen könnte, wie ich es bis jetzt verstehe (bzw versuche zu verstehen) würde ich an einem solchen "Spiel" wohl keinerlei Spaß haben.

(Ich habe noch nie ein Spiel programmiert, zu dem ich nicht selbst auch Lust gehabt hätte, es zu spielen. Die Spiele sind nicht immer so geworden wie sie vielleicht sollten, aber "der Plan" sah immer vor, daß es etwas wird, das ich am Ende auch selber spielen würde.)

Das soll nicht heißen, daß ich Dir nicht trotzdem Teile meine Engines/Units zur Verfügung stellen würde/könnte, falls Du so etwas brauchst, um Dein Traumspiel zu verwirklichen - aber auch Du entwickelst ja lieber selbst - darin sind wir uns ähnlich.

Re: Eigenes Videoformat

Verfasst: Sa 5. Dez 2015, 19:56
von zatzen
Ich möchte zwischendrin kurz ein paar Dinge genauer erklären:

Was das Sprechen angeht:
Die Figuren sollen keine komplexe Sprach-KI bekommen, sondern jede Figur soll lediglich
eine handvoll Sätze sprechen können. Den Inhalt oder die Bedeutung die damit sozusagen
in den Raum gestellt wird könnte man flaggen, so dass evtl. dadurch das Spielgeschehen
einen anderen Verlauf nimmt.
Mal ein Beispiel - eine Figur ruft "kommt mal alle her" (das wäre gleichzeitig auch eine
Fähigkeit dieser Figur, dass sie das rufen kann wenn sie z.B. irgendwas findet) und je
nach Typ der anderen Figuren kommen manche, manche aber auch nicht, je nach deren
Parameter bzgl. dieses Flags, wiederum, z.B. könnte man das so machen dass man bei
denen die kommen oder eben nicht dieses "kommt mal alle" Reaktons-Flag drin hat oder nicht.
Der Spieler selbst würde auch die Möglichkeit haben ein gewisses Repertoire zu sprechen
und hätte somit auch einen Einfluss, neben der Möglichkeit irgendwo dran zu hauen etc.

Vom Prinzip her verfolge ich noch das gleiche Spielformat wie damals Kotzman.
Ich habe, neben der steuerbaren Figur, weitere Figuren die sich selbstständig
bewegen. Nichts anderes soll diese "KI" machen, die übrigen Spielfiguren sollen
lediglich etwas lebendiger sein und facettenreichere Dinge tun als immer nur
stumm zwischen zwei Blöcken hin und her zu laufen.

Es würde mir auch nichts ausmachen wenn es auf ein Sims hinausläuft, wobei
ich das nicht glaube. Aber allein schon die andere grafische Darstellung wäre bei
mir ein Argument, mein Projekt umzusetzen, auch wenn es am Ende enntfernt
vergleichbar wäre mit Sims, das wäre mir dann egal.

Im Gegensatz zu dir ist das Programmieren für mich aber mittlerweile nur ein kleines
Hobby verglichen mit meinen anderen, so dass es eine Weile dauern wird bis ich wirklich
in die Gänge komme. Umso überlegter muss meine Idee sein, und umso mehr muss
sie sich, vor allem für mich, lohnen. Es wäre für mich auch keine Katastrophe wenn
ich diese Idee letztlich nicht angehe. Wenn du dir wirklich sicher bist, dass soetwas
nichts werden kann, dann spare ich mir lieber die Zeit.


So viel dann mal für heute,
man könnte sich vielleicht einfach ein Lemmings vorstellen, mit deutlich größeren
Figuren, dafür vielleicht maximal 10, auf mehrere Screens verteilt, und die mit
Lemmings nur das gemeinsam haben dass sie immer etwas tun, aber ohne Einfluss
nicht einfach nur laufen, sondern diverses, eigene Entscheidungen treffen (vorprogrammiert
oder sich im Spielverlauf ändernd), und dass man sie zusätzlich, aber eher indirekt, beeinflussen kann.

Ich möchte mir ersteinmal eine Engine schaffen, die ein solches automatisiertes
"Leben" der Charaktere bewerkstelligt. Inwiefern man dann hinterher daraus ein
forderndes Spiel macht werde ich sehen, und ich halte es nicht für unwahrscheinlich
dass es machbar ist.
Du solltest nicht zu viel erwarten bei dem was ich vor habe. Sehr viel mehr
als eine KI wie bei Feinden eines Jump&Runs müsste es für's erste(!) gar nicht werden.

Und sicherlich unterscheiden wir uns wohl auch stark darin, dass ich immer schon
bei Spielen eigentlich nur darauf aus war, etwas tolles zu sehen oder zu hören.
Die Motivation zum Spielen bei Adventures besteht oder bestand für mich nicht darin,
die Rätsel zu lösen, sondern ich wollte die Rätsel nur lösen um weiter zu kommen und
wieder neue Orte und Schauplätze mit toller Atmosphäre genießen zu können.

Ich lese auch nicht gern, es sei denn etwas technisches. Ich finde es anstrengend
und irgendwie auch unnatürlich, eine Geschichte in einem Buch zu lesen, sich
die Buchstaben wegdenken zu müssen und sich dann im Hinterkopf etwas
vorzustellen. Da bin ich eher einer von den Banausen, die sich lieber Verfilmungen
angucken, auch wenn die Handlung da drin verkürzt oder geändert werden muss.

Re: Eigenes Videoformat

Verfasst: So 6. Dez 2015, 13:22
von DOSferatu
zatzen hat geschrieben:Ich möchte zwischendrin kurz ein paar Dinge genauer erklären:

Was das Sprechen angeht:
Die Figuren sollen keine komplexe Sprach-KI bekommen, sondern jede Figur soll lediglich
eine handvoll Sätze sprechen können. Den Inhalt oder die Bedeutung die damit sozusagen
in den Raum gestellt wird könnte man flaggen, so dass evtl. dadurch das Spielgeschehen
einen anderen Verlauf nimmt.
Ja, so etwas wird in Adventures auch gern benutzt, um den Verlauf zu beeinflussen.
Da gibt es ja auch oft eine Sammlung von Sätzen, die man auswählen kann - weil es einfacher
ist, als wenn der User selbst Sätze eingibt, die dann ein "Eliza-Parser" analysieren müßte.
Aber ich verstehe schon, worauf Du hinauswillst. Es soll eher eine Art vereinfachte "Sprache"
werden, über den die Figuren nicht nur mit dem User, sondern auch untereinander
kommunizieren können.
zatzen hat geschrieben: Mal ein Beispiel - eine Figur ruft "kommt mal alle her" (das wäre gleichzeitig auch eine
Fähigkeit dieser Figur, dass sie das rufen kann wenn sie z.B. irgendwas findet) und je
nach Typ der anderen Figuren kommen manche, manche aber auch nicht, je nach deren
Parameter bzgl. dieses Flags, wiederum, z.B. könnte man das so machen dass man bei
denen die kommen oder eben nicht dieses "kommt mal alle" Reaktons-Flag drin hat oder nicht.
Das erinnert mich an die Mini-Roboter in dem einen Ratchet&Clank-Spiel - die hatten 8 verschiedene Funktionen, konnten per Befehl ausgelöst werden. Auch das "Sammeln" und "Folgen" (also hinterherlaufen) waren so Funktionen.
zatzen hat geschrieben: Der Spieler selbst würde auch die Möglichkeit haben ein gewisses Repertoire zu sprechen
und hätte somit auch einen Einfluss, neben der Möglichkeit irgendwo dran zu hauen etc.
Die Idee an sich ist gut - da sage ich ja auch gar nichts gegen. Aber für ein Spiel wäre das nur ein
interessantes Teilfeature. Um daraus ein Spiel zu machen - bzw, damit diese Fähigkeiten auch
für "einen Zweck"/"eine Aufgabe" genutzt werden, müßte eben noch eine Handlung/Story/Ziel zu
diesem Spiel gehören, da es sonst eher so ein "herumspielen" wäre - das kann Anfangs ganz lustig
sein, aber weiß ich nicht, ob so etwas auch auf Dauer interessant genug wäre. Es wäre eben schade
um die ganze Mühe, wenn es am Ende nichts weiter als das wäre.
zatzen hat geschrieben: Vom Prinzip her verfolge ich noch das gleiche Spielformat wie damals Kotzman.
Ich habe, neben der steuerbaren Figur, weitere Figuren die sich selbstständig
bewegen. Nichts anderes soll diese "KI" machen, die übrigen Spielfiguren sollen
lediglich etwas lebendiger sein und facettenreichere Dinge tun als immer nur
stumm zwischen zwei Blöcken hin und her zu laufen.
Ja, das ist klar. Aber es gibt auch viele neuere Spiele, wo die Figuren nicht nur "hin und her laufen",
sondern umfangreicher animiert werden. Und Interaktion mit Figuren gibt es ja auch - in vielen
neueren (meist eher 3D) Spielen wird das sogar so gemacht, daß es so AUSSIEHT, als hätten
die anderen Charaktere auch eine Art "Bewußtsein" - oder eigenen Plan. Aber alles natürlich in
sehr beschränktem Rahmen, um das Spiel / die Story weiterzubringen.
Ich sag's mal so: Dieser "Alles ist möglich"-Ansatz klingt interessant - so etwas versuchen auch
große Spielefirmen zu verwirklichen, damit das Ganze "natürlicher" wirkt.

Meine (ganz persönliche) Ansicht dazu ist, daß bei einem Spiel eher eine Art "Vereinfachung"
notwendig ist, um das Spiel "spielbar" zu machen. Dein Ansatz geht vom Gegenteil aus - mag
auch funktionieren, ist dann eben viel mehr Arbeit für den Spielemacher - und der Spieler kann/wird
dann möglicherweise gar nicht alles benutzen können, was sich der Macher ausgedacht und
hergestellt hat.
Das Ganze sieht nach sehr viel Mühe aus und Arbeit aus - die sich hoffentlichauch lohnt, d.h. daß
das Spiel, das damit erschaffen wird, auch wirklich diese Möglichkeiten richtig ausnutzt und zu
einem interessanten Gesamterlebnis macht.
zatzen hat geschrieben: Es würde mir auch nichts ausmachen wenn es auf ein Sims hinausläuft, wobei
ich das nicht glaube. Aber allein schon die andere grafische Darstellung wäre bei
mir ein Argument, mein Projekt umzusetzen, auch wenn es am Ende enntfernt
vergleichbar wäre mit Sims, das wäre mir dann egal.
Naja, grafische Darstellung macht meiner Meinung nach kein (gutes) Spiel aus.

Nicht umsonst gibts es inzwischen für Spiele, die außer guter Grafik nichts weiter bieten
können (und bei denen Leute das Spiel "mögen", weil sie auf die Grafik reinfallen),
den Begriff "Grafikblender". Ein unausgereiftes, unzureichendes oder nicht vorhandenes
Spielprinzip kann auch durch die beste Grafik nicht gerettet werden.

Der "Grafikblender"-Begriff kam zu der Zeit auf, als 3D-Spiele immer realistischer wurden
und grafischer Fotorealismus in Spielen wichtiger wurde als eine gute Spielidee. Viele Firmen
haben zu dieser Zeit den Markt mit "Grafikblendern" überschwemmt und eine Weile hat das
auch gut funktioniert, weil es sich verkauft hat wie geschnitten Brot. Inzwischen spielen
viele Leute aber wieder auch gern Spiele im "altmodischen" Stil oder erfreuen sich mehr
an einer guten Idee als an Grafik.
Da gibt es den bekannten Ausspruch:
"Gute Grafik kann ein gutes Spiel besser machen, aber kein schlechtes Spiel gut."

Ich sage das nicht, weil ich eventuell den Ansatz für schlecht halte oder so. Aber FALLS es
so wie Sims wird, nur mit besserer Grafik - dann ist es wie Sims trotzdem wie Sims.
Anders ausgedrückt: Wenn jemand ein Tetris programmiert und drumherum eine 3D-Grafik
mit transparenten Elementen und Glitzer und ellen Effekten die es gibt baut - wird das Spiel
am Ende trotzdem ein Tetris sein und jemand, der sich für Spiele wie Tetris interessiert, wird
es genauso gern spielen wie jedes andere Tetris und jemand, der Tetris noch nie leiden konnte,
wird auch ein supergrafisches Tetris nicht spielen.
Und FALLS es wie Sims wird und jemand Spiele wie Sims nicht spielt, wird auch die beste
Grafik daran nichts ändern.
Es ist bekanntermaßen so: Wenn man ein Spiel erstmalig sieht und sieht/hört die gute Grafik/
Musik, ist man erst einmal davon begeistert. Längerfristig kann aber nur ein gutes Spielprinzip
oder Story oder was auch immer begeistern - also eher der Inhalt.
zatzen hat geschrieben: Im Gegensatz zu dir ist das Programmieren für mich aber mittlerweile nur ein kleines
Hobby verglichen mit meinen anderen, so dass es eine Weile dauern wird bis ich wirklich
in die Gänge komme.
Naja, für mich war es immer ein Hobby - habe das nie beruflich gemacht. Ich hätte nur gern
mehr Zeit und mehr Kraft für mein Hobby. Wenn ich von der Arbeit komme, bin ich oft so
müde und erledigt, daß ich leider keine Konzentration für Programmieren mehr aufbringen
kann. Früher habe ich viel mehr ausgehalten - ich habe auch, wenn ich Urlaub hatte oder
noch früher, in meiner Jugend, wirklich schon tagelang quasi pausenlos am Rechner
programmiert, mein "Rekord" liegt bei einer ca. 80-stündigen Dauersession. Inzwischen bin
ich leider älter geworden und bin froh, wenn ich überhaupt den Job noch schaffe.
zatzen hat geschrieben:Umso überlegter muss meine Idee sein, und umso mehr muss
sie sich, vor allem für mich, lohnen. Es wäre für mich auch keine Katastrophe wenn
ich diese Idee letztlich nicht angehe. Wenn du dir wirklich sicher bist, dass soetwas
nichts werden kann, dann spare ich mir lieber die Zeit.
Ich habe ja nie gesagt, daß "so etwas nichts werden kann" - ich erwähnte nur, daß dieser
Ansatz allein kein Spiel werden kann, ohne eine dazugehörige Spielidee. "Freier agierende
Figuren" ist ja nur ein Feature - zu einem Spiel, bei dem der Spieler auch selbst irgend
etwas tun kann, um das Spiel quasi zu meistern, gehören ja noch andere Aspekte außer
einer solchen Figuren-Engine.
zatzen hat geschrieben:So viel dann mal für heute,
man könnte sich vielleicht einfach ein Lemmings vorstellen, mit deutlich größeren
Figuren, dafür vielleicht maximal 10, auf mehrere Screens verteilt, und die mit
Lemmings nur das gemeinsam haben dass sie immer etwas tun, aber ohne Einfluss
nicht einfach nur laufen, sondern diverses, eigene Entscheidungen treffen (vorprogrammiert
oder sich im Spielverlauf ändernd), und dass man sie zusätzlich, aber eher indirekt, beeinflussen kann.
(Btw: Ich habe auch schon ein Lemmings gesehen mit großen Figuren)
Naja, das Ganze klingt nach Populous oder Siedler. Schau Dir mal die entsprechenden Spiele
an, vielleicht bekommst Du da Anregungen.
Ich meine "etwas tun" ist ein weitläufiger Begriff, genau wie "Entscheidungen treffen". Wie
ich bereits erwähnte, treffen Computer keine Entscheidungen "von sich aus" - es benötigt
immer Daten (egal woher diese stammen. Eine Figur kann in begrenztem Maße Entscheidungen
simulieren - aber zum Treffen einer Entscheidung gehört immer ein Anliegen oder Grund.
Ein MENSCH trifft Entscheidungen auch einfach mal "aus dem Bauch heraus" ohne besonderen
Grund, es wirkt wie Zufall oder Willkür.
Computer tun so etwas bekanntlich nicht. Ich will ja nur darauf hinweisen, daß, damit es
wenigstens so AUSSIEHT, als würden Computerfiguren eigene Entscheidungen treffen, oder etwas
"von selbst" tun, bereits eine Menge Programmierung nötig ist. WIRKLICH eigene Entscheidungen
treffen sie dann aber trotzdem nicht. Ich will nur, daß man sich das klarmacht, bevor man sich
hier eventuell in eine unlösbare Idee verrennt...
zatzen hat geschrieben: Ich möchte mir ersteinmal eine Engine schaffen, die ein solches automatisiertes
"Leben" der Charaktere bewerkstelligt. Inwiefern man dann hinterher daraus ein
forderndes Spiel macht werde ich sehen, und ich halte es nicht für unwahrscheinlich
dass es machbar ist.
Ja, es ist sicher machbar, so etwas in begrenztem Maße zu simulieren.
zatzen hat geschrieben: Du solltest nicht zu viel erwarten bei dem was ich vor habe. Sehr viel mehr
als eine KI wie bei Feinden eines Jump&Runs müsste es für's erste(!) gar nicht werden.
Naja, die Feinde bei Jump'n'run haben ja keine KI, sondern meist nur eine Auswahl vorprogrammierter
Abläufe, die auf bestimmte Positionen der Spielfigur reagieren.
Eine richtige KI zeichnet sich ja durch "Lernen" aus, d.h. es gibt eine wie auch immer gestaltete Lernmatrix (bei komplexem KI sind das neuronale Netze - diese erfordern aber ziemliche Performance) und diese speichert bestimmte Abläufe und Reaktionen darauf, zusammen mit einer Art "Erfolgskoeffizient" über die gesamte Matrix verteilt in sogenannten "Wichtungen" - diese zusammengesetzt ergeben dann bei Abruf das Ergebnis, werden verstärkt bei Erfolg und abgeschwächt bei Mißerfolg, (eine interne Erfolgserkennung/-bewertung ist dafür nötig). Mit dem Terminus "Erfolg" ist hier nur gemeint, ob sich das Matrixresultat vom gewünschten, das Verhalten bedingenden Zustand entfernt oder annähert - auf diese Art lernt die Matrix. Nützlich ist dies, da aufgrund der "Erfahrungen", die die Matrix macht, so auch Reaktionen auf bisher unbekannte Umstände quasi "vorauszusehen" sind, wenn das Netz ausreichend viele Daten erhalten hat - will sagen: mit den richtigen Ein-/Ausgabefeldern, fausreichend großem Netz (das Anliegen betreffend) und genug "Training" wird das Netz immer "besser", d.h. reagiert immer genauer und korrekter.
Für ein Spiel bzw Spielgegner würde das z.B. bedeuten, daß so ein Gegner mit zunehmendem Spielverlauf immer schwerer zu schlagen ist (vorausgesetzt man speichert den Netzinhalt und resettet ihn nicht jedes Mal).
zatzen hat geschrieben: Und sicherlich unterscheiden wir uns wohl auch stark darin, dass ich immer schon
bei Spielen eigentlich nur darauf aus war, etwas tolles zu sehen oder zu hören.
Naja, das würde aber bedeuten, daß Du ebenfalls lieber solche "Grafikblender" spielen
würdest (siehe oben)...
zatzen hat geschrieben: Die Motivation zum Spielen bei Adventures besteht oder bestand für mich nicht darin,
die Rätsel zu lösen, sondern ich wollte die Rätsel nur lösen um weiter zu kommen und
wieder neue Orte und Schauplätze mit toller Atmosphäre genießen zu können.
Ja, das ist für mich zwar auch interessant - die Geschichte weiterzuführen usw.
Aber mir geht es vor allem natürlich um die Rätsel und Aufgaben - das macht Adventures
schließlich aus.
zatzen hat geschrieben: Ich lese auch nicht gern, es sei denn etwas technisches. Ich finde es anstrengend
und irgendwie auch unnatürlich, eine Geschichte in einem Buch zu lesen, sich
die Buchstaben wegdenken zu müssen und sich dann im Hinterkopf etwas
vorzustellen.
Ich stehe auf "unnatürlich". Bin schließlich Computerfreak.
Und eine Geschichte un einem Buch lesen und sich das alles vorstellen zu können, ist
ein Zeichen für eine ausgeprägte Phantasie.
zatzen hat geschrieben: Da bin ich eher einer von den Banausen, die sich lieber Verfilmungen
angucken, auch wenn die Handlung da drin verkürzt oder geändert werden muss.
Ja, mag sein. Jeder hat seine Vorlieben. Ich lese gern UND sehe auch gern Filme.
Meist finde ich aber bei Filmen solche besser, die um des Films willen "erfunden worden" sind
als die Verfilmungen von Büchern. Bücher und Filme sind unterschiedliche Medien, die einander nur
unzureichend entsprechen können. Jedes hat seine eigenen Vor- und Nachteile.

Ich sage es mal so: Spiele, die außer Grafik und Sound nichts weiter zu bieten haben,
können nur sehr kurzfristig für Begeisterung sorgen - zumindest, wenn man wirklich ein Spiel
erwartet. Wenn an einem Spiel nicht auch "irgend etwas zum Spielen" dabei ist, also das Spiel
keine "Essenz", keinen Inhalt hat, sondern quasi nur aus seiner Präsentationsform besteht, würde
ich das Ganze eher als ein Demo bezeichnen.