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?