Turrican News, Facts and Rumours

Welcome to Turrican SETA! Here you can find the latest news, rumours, downloads and collected facts about Turrican. If you think you know anything that should be mentioned here, please contact me.
   
 

Mein Zeug (Imperial Games)

Imperial Games
02.07.06
Ich habe mich entschlossen, hier mal einen neuen Thread aufzumachen. Ich neige oft dazu, Informationen recht genau abzufassen, was aber dazu führt, daß meine Texte sehr lang werden. Nicht jeder mag lange Texte und noch weniger Leute mögen die Art wie ich schreibe.

Deswegen gibts jetzt eben diesen Thread - und wann immer ich längere Ausführungen speziell zu meinem Kram (Spiele, Tools, etc) habe, werde ich sie eben hierhin verschieben und allenfalls im *eigentlichen* Thread einen kurzen Hinweis lassen. Auf die Art können die wenigen Leute, die es interessiert, mal einen Blick hierhin riskieren und für die vielen, denen meine langen Ausführungen zum Hals raushängen ist es jetzt leichter, sie zu überlesen.

Imperial Games
02.07.06
Antwort 1 auf "Was ist euch wichtig bei einem Map-/Leveleditor?"
- - - - - - - - - - -

Es ist wieder ein elendig langer Text geworden, von dem ich nicht glaube, daß er jeden interessiert. Daher habe ich diesen neuen Thread eröffnet.

Es heißt, daß man jederzeit zwischen Spiel und Editor umschalten KÖNNTE - rein technisch ist das wirklich überhaupt kein Problem.
Ich werd's nur wohl nicht auf die Art machen, weil es ja in der Praxis nicht sinnvoll ist, während des Spiels plötzlich rumzueditieren.

Aber, ja - prinzipiell ist das so.
(Und ja, im Moment läufts auch WIRKLICH so ab - wenn ich mitten im Spiel bin, kann ich einfach den Editor anwählen und in dem Level im aktuellen Spielstatus rumeditieren... - und wenn ich wollte, könnte ich dann genau ab diesem Punkt weiterzocken...)

Aber Dinge wie DAS sind es, warum sich der Release eben so verzögert:

- Für ne idiotensichere Version sollten solche Dinge meiner Meinung nach eben einfach NICHT gehen! (Und ich habe schlechte Erfahrungen damit gemacht, Versionen von irgendwas herauszugeben, die NICHT idiotensicher sind... - es findet sich *grundsätzlich* ein Idiot für jedes Loch...)

- Und einiges an den Menüs ist auch noch nicht so, wie ich es haben will (und da, wo es hingehört). Problem ist eben, daß es wirklich so ca. 450 einstellbare Werte gibt, von denen ich auch theoretisch JEDEN EINZELNEN irgendwo einstellbar machen könnte - grad so Multiplayer-Zocker stehen ja drauf, ein wenig "an den Werten zu drehen", um die Herausforderung zu erhöhen...

- Aber Hauptgrund für die Verzögerung ist eben, daß ich zwischenzeitlich auch noch mit anderen Dingen beschäftigt war/bin. Wer weiß, ob da überhaupt nochmal was kommt. Das Problem ist eben: SO TOLL ist das Spiel nicht. Es ist nur das umfangreichste und am weiten fortgeschrittenste meiner "Spiel"-Projekte. Aber andererseits mache ich (mit langen, LAAAANGEN Pausen) schon seit Oktober 2001 dran herum - wobei ich sagen muß, daß sich das endgültige Spielprinzip bereits ca. 1 Monat nach Beginn des Codings nicht mehr verändert hat! (Und dann später nur noch 2 neue Waffensysteme eingefügt wurden.) ALLES ANDERE war nur noch Arbeit an anderen Dingen: Menüsystem, teilweise Steuerung, später überarbeitete Engine. Und vor allem
(das aufwendigste) : Das ganze Protokoll für den Multiplayer-Part. (Ja, irgendwer war so unvorsichtig mich drauf hinzuweisen, daß man das Ganze ja auch INTERNET-fähig machen könnte. Und wer Coder kennt, weiß, daß die nur drauf warten, daß irgendwer was in dieser Art sagt...)
- - - - - - - -
Zurück zum Thema:

Naja - "Edi und Spiel zusammenmatschen" funktioniert halt genau dann, wenn Edi und Spiel von demselben Typen gecodet werden...
Da mein Menüsystem in einer Art (selbstentwickeltem) Mini-Skript gebaut ist, konnte ich eben die ganzen für den Editor erforderlichen Menüs aus der EXE quasi "auslagern",
(sondern mußte lediglich ein paar universelle Funktionen in die EXE integrieren) so daß dem ganzen Ding also nichtmal wirklich viel vom Bedienkomfort abgeht... ABER:
Der Xpyderz-Editor ist nicht so gut (und umfangreich) wie der andere, weil er ja erstens nur auf das eine Spiel beschränkt ist und weil er zweitens eben schon etwas "freaky" ist.

Bin eben kein Windows-Fan - Bei mir sind meist keine der üblichen Windows-Hotkeys belegt, sondern wenn es überhaupt "Standards" gibt, orientieren sie sich wohl eher an den DOS-typischen SAA-Oberflächen (was z.B. die ganzen Texteditoren der Compiler/Interpreter so hatten).

Und - leider - zum Thema Mausbedienung:
Xpyderz hat außerdem eine mausfreie Bedienung, da Maus für das Spiel selber weder erforderlich noch auch nur ansatzweise sinnvoll ist. Vielleicht ändert sich das auch nochmal - aber eigentlich will ich's nicht einbauen.

(Das heißt im Klartext: Der Xpyderz-Editor ist so wenig windowsmäßig, wie man sich's überhaupt vorstellen kann. Wäre er noch ein klein wenig weniger windowsmäßig, liefe er wahrscheinlich nichtmal mehr auf 'nem DOS-Rechner...)

Aber angesichts dessen, daß Xpyderz-Levels nicht nur pattern-"BASIERT" sind, sondern a) nur mit seinen "Standard"Patterns arbeitet und b) damit genau diesen rudimentären Oldschool-Klotz-Effekt beabsichtigt, der dadurch entsteht, führt das c) eben sowieso dazu, daß das Bauen von Levels da sowieso weniger eine "künstlerische" Angelegenheit wird, sondern sich nahezu ausschließlich am Zocken orientiert - also die Levels diesem Zweck völlig unterordnet! (Da ist wirklich nichts mit "Landschaften"...)
Ich hab da eine wirklich niedliche potente kleine Engine gebaut, die es mir jetzt erlaubt, 16-farbige Patterns zu haben (16 aus 256 Farben), was den für 1 Pattern erforderlichen Speicher auf 512 Bytes beschränkt...

Hauptsächlich soll es dabei halt um das Zocken an sich gehen - und eben darum, sich herausfordernde (Multiplayer) Levels bauen zu können, damit man nicht auf ein paar wenige "interne" Standard-Levels angewiesen ist, an denen man sich bald satt spielt. (Naja. Außerdem gibts ja auch noch den Random Level Generator.)
Er ist auch eher eine "Zusatzfunktion für Freaks" - und eine Zeitlang habe ich auch darüber nachgedacht, ihn in der "User-Version" gänzlich wegzulassen.

Also - zum "richtig dran austoben" ist der Xpyderz-Editor wohl eher nicht geeignet, dachte nur, daß manche seiner Features eben einen Tip in dem Thread hier wert sind.

Und auch mein anderer Editor ist eben... nunja. Er ist erstmal KEIN Turrican-Editor (und bis dato auch nicht Turrican-geeignet), weil er ja auf meine eigene Engine abzielt. Und er ist eben - so wie alles, was ich code - DOS-Kram, d.h. für 'n DOS-Freak bedient sich das Ding wahrscheinlich völlig OK (aber JA - DER hat sogar Mausbedienung), Windows-User müßten sich wahrscheinlich umgewöhnen. (Naja. Es gibt noch mehr auf der Welt als Windows. Das sollte imo sowieso nicht zum "Maß aller Dinge" werden. Wenn's schon so weit ist, daß sich die Qualität eines Programms an seiner Windows-Ähnlichkeit mißt - dann ist das nichts, was ich bewußt supporte.)
- - - - - - - -

Ich wollte hier *keinesfalls* (auch wenn sich's vielleicht so anhört) "Werbung" für meine Software machen. Sie ist altmodisch, DOSenkram und auch sonst hier wohl nicht von Interesse - dachte nur, ich könnte evtl. meine Erfahrungen zum Thema beitragen.

Entschuldigung, daß es wieder so lang geworden ist.
Bronko
02.07.06
Stichwort -> Sinnlos während des Spielens zu editieren

Glaub mir, während des Spieles zu editieren, das klingt wie ein weit entfernter Traum für mich...
Ich habe mich schon mit vielen Editoren rumgeschlagen, und es geht eine Menge Zeit drauf, dauernd beim Testspielen kleine Unschönheiten zu finden, sie im Editor zu korrigieren, und wieder zu der Levelstelle zu gehen. Natürlich kann man oft den Levelstart verlegen, aber dann landet man an der Stelle nicht im authentischen Zustand. (Was nun mehr für Single Player Sachen wichtig ist...)

Tatsache ist aber auch für ein reines Multiplayerspiel, dass man am besten Fehler findet, während man im Level spielt.

Mit der Option tust Du jedem Levelbastler einen Gefallen, glaubs mir!


Stichwort -> lieber Idiotensicher

Ich halte es für weniger sinnvoll, Editoren komplett idiotensicher zu gestalten. Es klingt zwar hart, aber ist der Editor zu idotensicher, kommen mehr idiotische Level daraus!
(Doom Editoren verlangen zum Beispiel alle noch Verständinis über den Aufbau mit Sektoren, usw. )
Wenn der Editor nämlich wenigstens etwas verlangt, sich in das Spiel und seinen Aufbau hereinzuversetzen, dann werden mehr Level von wenigstens halbwegs Interessierten gestaltet, die sich etwas Mühe geben, und nicht von irgendwelchen Leuten, die schnell 1000 Monster und die Superwaffe zusammenklicken...
(Ok, Doom beweist, dass auch weniger idiotensichere Editoren zu solchen miesen Welten führen, aber ich will garnicht wissen, was geschehen wäre, wenn die Editoren tatsächlich idiotensicher wären!)


- Typische Windows-Hotkeys & co.

Wenn der Editor für Windows geschrieben wurde, und sich mit der Maus bedienen lässt, sollte man wirklich nicht die Hotkeys ändern, mehr wollte ich nicht sagen. Es macht doch kaum Sinn, wenn jedes Programm andere Hotkeys nutzt. Es mag ein Windows Standard sein, aber es ist nunmal Standard.
Ansich sollte es aber garnicht um Windows gehen. Ich will Windows nicht schönreden, aber das unterstellst Du ja jedem nur zu gerne...

Wenn der Editor nicht auf die Maus ausgelegt ist, und er sich trotzdem gut bedienen lässt, dann braucht er eben keine Maus.
Da Du ihn aber möglichst idiotensicher gestalten willst, solltest Du die Nutzer doch nicht mit einer bösartigen Keyboardbelegung verwirren. (Ich glaube sogar, dass die Keyboardsteuerung viel verwirrender für manch einen ist, als die nützliche Option, beim Spielen zu editieren...)
Die Windowsfähigkeit des Editores bedeutet für mich zumindest, inwieweit er in der miesen Windows-Dosumgebung funktioniert. Wie man ihn bedient hat da doch garnichts mit zu tun.


Wie auch immer, lass die hilfreichen Optionen besser in Deinen Editoren. Du kannst ja auch einen "Profimodus", und einen "Anfängermodus" anbieten.
Ich hasse Editoren, mit denen man die Spielengine nicht ausreizen kann. Ein Editor sollte es möglich machen, schnell komplexe Welten zu gestalten. Dazu gehört es, dass jede Option ohne Umwege nutzbar ist. Der kürzeste Weg ist es mit Sicherheit, beim Spielen was zu ändern!


Imperial Games
04.07.06
Zitat (Bronko) "Glaub mir, während des Spieles zu editieren, das klingt wie ein weit entfernter Traum für mich..."

Mag ja alles sein - aber während des Zockens zu editieren ist auch der feuchte Traum jeden CHEATERs...


Zitat (Bronko) "Ich habe mich schon mit vielen Editoren rumgeschlagen, und es geht eine Menge Zeit drauf, dauernd beim Testspielen kleine Unschönheiten zu finden, sie im Editor zu korrigieren, und wieder zu der Levelstelle zu gehen..."

Problem dabei ist, daß man ja während des Spiels das Level VERÄNDERT und damit z.B. die originalen Einsatz-Positionen nicht mehr stimmen. Ja - da könnt man dann so Speicheroptionen einführen usw... Aber darum gehts nicht. Ich hatte schon an so eine "Probespielen" Option im Editor gedacht, aber es verträgt sich nur unzureichend mit dem restlichen Programmstruktur.
Und - übrigens - wie sollte man z.B. ein MULTIPLAYER-Level probespielen? (Ja, in Xpyderz gibts sogar die Option mit mehreren Leuten auf einem Rechner im "Split Screen" zu zocken.)
Hatte wie gesagt mit dem Gedanken gespielt, muß mir aber noch überlegen, ob ich es in der Form zulasse.


Zitat (Bronko) "Tatsache ist aber auch für ein reines Multiplayerspiel, dass man am besten Fehler findet, während man im Level spielt."

Speziell bei Xpyderz ist das sowieso nicht SO das Problem, ein "spielbares" Level zu bauen - es ist nicht gerade sehr komplex.
Und Xpyderz ist kein reines Multiplayerspiel - sondern es ist Single- UND Multiplayer.


Zitat (Bronko) "Mit der Option tust Du jedem Levelbastler einen Gefallen, glaubs mir!"

Mir selber aber eher nicht. Und der eingebaute Xpyderz-Editor ist WIRKLICH nur so'n "Gimmick" - werde keinesfalls das ganze Xpyderz-System danach ausrichten. Xpyderz ist n Arcade-Game mit integriertem Level-Editor - kein Editor mit integriertem Spiel...


Zitat (Bronko) " [Stichwort -> lieber Idiotensicher]
Ich halte es für weniger sinnvoll, Editoren komplett idiotensicher zu gestalten. Es klingt zwar hart, aber ist der Editor zu idotensicher, kommen mehr idiotische Level daraus!"

Ich kenne das Problem. Aber das war nicht gemeint. Siehe unten.


Zitat (Bronko) "(Doom Editoren verlangen zum Beispiel alle noch Verständinis über den Aufbau mit Sektoren, usw. )"

Ich weiß... Problem ist WIRKLICH, daß ich manchmal so Leute treffe, die dann sagen: "Yeah! Da kann ich ja Levels bauen..." Und ich freue mich schon. - (Ja, endlich mal einen gefunden, der mal sinnvoll an einer Spielentwicklung teilnehmen will.) Und der nächste Satz zieht mich wieder runter, da kommt dann gleich "... da kann man ja alles voll Superwaffen klatschen und das Level aus Verschiebeblöcken bauen..." - Und ich denke dann wieder: Mist, doch nichts mit sinnvoller Entwicklung - nur wieder einer, der Idiotenlevels bauen will. Glaubs mir, ich weiß GANZ GENAU, wovon Du redest...


Zitat (Bronko) "Wenn der Editor nämlich wenigstens etwas verlangt, sich in das Spiel und seinen Aufbau hereinzuversetzen, dann werden mehr Level von wenigstens halbwegs Interessierten gestaltet, die sich etwas Mühe geben, und nicht von irgendwelchen Leuten, die schnell 1000 Monster und die Superwaffe zusammenklicken..."

Ja, wie gesagt, ich kenne diese Art Deppen - ABER vor denen ist man nie sicher. Du hast mich hier ein wenig mißverstanden. Gemeint war hier nicht idiotensicherer Bedienkomfort, sondern idiotensichere Programmsicherheit. Im Sinne dessen, daß Mister Normalodepp und "Computer-interessieren-mich-nur-so-weit-ich-sie-werfen-kann" es nicht durch versehentliche oder absichtliche Fehleingaben/Fehlbedienung schaffen kann, das System/die Engine abstürzen oder fehlfunktionieren zu lassen. Oder daß irgendeine Kombination gewählter Menü-Optionen Ergebnisse hervorruft, die den Normal-User verwirren.


Zitat (Bronko) "[ Typische Windows-Hotkeys & co.]

Wenn der Editor für Windows geschrieben wurde, und sich mit der Maus
bedienen lässt, sollte man wirklich nicht die Hotkeys ändern, mehr wollte
ich nicht sagen. Es macht doch kaum Sinn, wenn jedes Programm andere
Hotkeys nutzt."

Das sehe ich 100%ig so wie Du. - Windows-Programme -> Windows-Bedienung.

Aber: Was kein Windows-Programm ist, muß sich auch nicht so verhalten wie eins. Und wenn ein Programm von sich aus keine Windows-Elemente hat, muß man nicht etxra deswegen welche einbauen.
Ich persönlich finde manche Sachen in Windows etwas umständlich gelöst und bei einem Level-Editor, bei dessen Hotkeys etc. man ja nicht darauf zu achten hat sich mit den "restlichen Systemkeys" nicht ins Gehege zu kommen (weil es ja kein "restliches System" gibt), kann man eben verschiedene Dinge auch anders lösen.
Wobei ich aber sagen muß, daß mein Level-Editor durchaus auch Pulldowns und Balken hat. Aber er ist mehr drauf ausgelegt, möglichst viel Funktionalität auf den Screen zu kriegen, als darauf, möglichst "windowsig" zu sein. Bin kein Freund von Unter-Unter-Untermenüs - nicht weil ichs nicht programmieren könnte (das ist eher kein Problem), sondern weil sich sowas meiner Meinung nach sehr zäh bedient.



Zitat (Bronko) "Ansich sollte es aber garnicht um Windows gehen. Ich will Windows nicht schönreden, aber das unterstellst Du ja jedem nur zu gerne..."

Stimmt nicht - und habe ich auch an dieser Stelle nicht getan. Wollte damit nur sagen, daß ich die Qualität/Bedienbarkeit eines Programms nicht danach einschätze, wie Windows-ähnlich es aussieht oder sich bedient.
(ICH z.B. finde, daß Windows sich bedient wie ein russischer Flugzeugträger...)


Zitat (Bronko) "Wenn der Editor nicht auf die Maus ausgelegt ist, und er sich trotzdem gut bedienen lässt, dann braucht er eben keine Maus."

"Gut bedienen" ist Ansichtssache. Ich selbst habe fast nie den Maustreiber überhaupt geladen, weil ich sowieso kaum jemals für irgend etwas die Maus einsetze.
Und bei Xpyderz ist es so: Das Spiel selbst braucht keine Maus. Um die paar Menüs zu bedienen, ist eine Maus wirklich kaum je erforderlich. Und NUR für den Leveleditor (der bei Xpyderz reine Nebensache ist) werd ich keine Mausabfrage einbauen.


Zitat (Bronko) "Da Du ihn aber möglichst idiotensicher gestalten willst, solltest Du die Nutzer doch nicht mit einer bösartigen Keyboardbelegung verwirren."

Wer Keyboards bösartig findet, soll sowieso kein Xpyderz zocken... Und (siehe oben) "Idiotensicherheit" war hier eher im Sinne von "Absturzsicherheit trotz idiotischer Eingaben" gemeint, nicht, daß Idioten es problemlos bedienen können. Idioten gehören nicht zu meiner Klientel.

Zitat (Bronko) "
(Ich glaube sogar, dass die Keyboardsteuerung viel verwirrender für manch einen ist, als die nützliche Option, beim Spielen zu editieren...)




Zitat (Bronko) "Die Windowsfähigkeit des Editores bedeutet für mich zumindest, inwieweit er in der miesen Windows-Dosumgebung funktioniert."

Damit hat mein Zeug generell nie Probleme. Das liegt an zwei Dingen.
Erstens: Ich code in reinem "Real Address Mode" (also 16bit-Mode), der i.d.R. keine großen Probleme macht.
Zweitens: Ich code - trotz vieler abstrakter Hardwarespielerei - recht "ordentlich" und tue keine "illegalen" Sachen, wenn sie mir keinen Vorteil bringen.
Drittens: Ich lasse den Kram auch bei anderen Leuten auf ihren Win-Rechnern probelaufen und habe auch schonmal interne Bugfixes/Workarounds eingebaut. (Aber Lauffähigkeit unter Windows ist für mich sekundär. Sollten solche Dinge das Programm verlangsamen, verzichte ich darauf.)


Zitat (Bronko) "Wie man ihn bedient hat da doch garnichts mit zu tun."

Richtig. Aber es gibt Leute, die kriegen von allem, was irgendwie anders als Windows ist, einen Kulturschock und verfallen dann in eine katatonische Starre, liegen sabbernd mit weit aufgerissenen Augen in der Ecke und sind völlig entsetzt, daß es so böse Nicht-Windows-Programme gibt.
(Ja, das war eine sarkastische Übertreibung.) Auf derart von MS verhaltensprogrammierte Leute kann (und will) ich leider keine Rücksicht nehmen, das wollt ich damit halt sagen.
Wer so viel "User" und so wenig "Freak" ist, daß ihn alles erschreckt, was mal nicht wie Windows ist, kann mit meinem Kram sowieso NICHTS anfangen - aber es ist auch äußerst zweifelhaft, daß ihn dann sowas wie mein Kram überhaupt interessiert.


Zitat (Bronko) "Wie auch immer, lass die hilfreichen Optionen besser in Deinen Editoren. Du kannst ja auch einen "Profimodus", und einen "Anfängermodus" anbieten."

Du wirst vielleicht lachen - aber ich hatte vor Jahren in der Tat mal so eine Idee. (So einen 5 stufigen "Expert" Mode, wo Stufe 1 dann wirklich so ist, daß zu jedem Ding n großes Hilfefenster aufgeht und alles mit riesigen iconifizierten Buttons geht und Stufe 5 dann ein hotkey-/textverseuchtes Teil ist, das zwar gar nichts mehr erklärt und keine Sicherheitsabfragen mehr hat - aber dafür eben ultraschnelle Bedienbarkeit...
Aber bin davon abgekommen - weil solche Dinge einfach zuviel Platz brauchen. Ich bin der Meinung, sobald man als "Entwickler" tätig wird und nicht nur als Zocker, sollte ein gewisses Grundintelligenzlevel vorausgesetzt werden dürfen...
Imperial Games
04.07.06
Zitat (Bronko) "Ich hasse Editoren, mit denen man die Spielengine nicht ausreizen kann."

Ich dagegen würde mir Editoren wünschen, die mir aufzeigen, wenn ich gerade in Begriff bin, irgendetwas zu tun, das die Engine bis an die Grenze belastet und die Framerate runterdrehen würde.
Und die vielleicht sogar "raten", was ich vorhabe und mir eine - an diese Engine angepaßte - Alternative vorschlagen, die im Ergebnis dasselbe bewirkt, aber wesentlich bessere Performance liefert. - SOWAS finde ICH cool.


Zitat (Bronko) "Ein Editor sollte es möglich machen, schnell komplexe Welten zu gestalten."

Naja. Er sollte aber jedem auf die Pfoten kloppen, der Schwachsinns-Levels baut...

Ich gebe mal ein Beispiel:
Habe eine Engine gebaut, die 4 Ebenen darstellt. OPTIMIERT ist sie (natürlich) darauf, daß Ebene 1 die Spiel-Ebene ist und die anderen die Hintergrund-Ebenen.
Er supportet auch Transparenz und Halbtransparenz - auch durch mehrere Ebenen hindurch - aber sowas kostet natürlich etwas Performance, weil die Engine das natürlich als den AUSNAHME-Fall definiert und dementsprechend behandelt.

* Ein DEPP würde nun ein Unterwasser-Level so gestalten, daß er einfach Ebene #0 mit einem halbtransparenten blauen Block füllt, und Ebene #1 zur Spielebene erklärt. Damit würde er einen Performanceverlust von ca. 30% bis 50% erreichen und es kommentieren mit "Ach, mir doch egal, ich hab ja 1,4 GHz..."
* Ein Nicht-Depp würde stattdessen die Palettenanpassung benutzen, die ich extra für diese Zwecke eingebaut habe.
* Ein Ober-Depp würde erwarten, daß der Programmierer in die Engine eine KI einbaut, die selber erkennt, wenn er so ne Kacke gebaut hat und das selber fixt. (Aber bin schon drauf und dran, so "Optimize" Funktion einzubauen...)

Anderes Beispiel - gesucht ist eine Möglichkeit, so "ganz nahe" Objekte einzufügen, sozusagen eine "Ebene Minus 1".
* Ein Depp würde das so machen, daß er eben eine fast leere Ebene 0 dafür nehmen würde, Ebene 1 als Spielebene benutzen und damit ca. 20% - 25% Performanceverlust erleiden.
* Ein Nicht-Depp würde stattdessen entweder Sprites dafür benutzen oder die neu geplante Spezial-Option für speziell so eine "Minus 1" Ebene.

Drittes Beispiel - gesucht ist eine Möglichkeit, ein Feature in das Spiel einzubauen, was die Engine von sich aus nicht bietet.
* Mensch A baut es trotzdem ein, so gut es geht - und schafft damit für die Engine leider einen "Worst Case" - weil er nicht weiß, wie er's anders machen soll. Kann man ihm aber verzeihen.
* Mensch B dagegen kennt den Coder der Engine (und das wär bei mir sowieso die Regel) und schlägt vor, das Feature gleich in die Engine einzubauen. - Würde vielleicht trotzdem Performance kosten, könnte aber Overkill vermeiden und wäre damit auf jeden Fall die intelligentere Lösung.

Viertes Beispiel - gesucht ist eine Möglichkeit, ein Feature in das Spiel einzubauen, das nur an einer einzigen Stelle in einem einzigen Level benutzt werden soll.
* Der Idiot wird sich an diesem einen Feature festbeißen und keine andere Gestaltungsmöglichkeit finden, sondern lieber drauf bestehen, die Engine 30% langsamer zu machen, nur damit an der einen Stelle ein 20 Pixel großer Effekt erscheinen kann.
* Der Nicht-Idiot wird dank seiner Kreativität auch irgendeine andere Möglichkeit finden, darzustellen was er ausdrücken will und nicht endgültige Lauffähigkeit/Spielbarkeit absolut JEDER seiner Tageslaunen unterordnen.


Das ist das Problem - man kann als Programmierer entweder seine Zeit darauf verwenden, eine Engine zu bauen, die schnell und potent ist und viele Features bietet.
Oder man muß eben dieselbe Zeit darin investieren, daß man 'ne Engine baut, die all den Mist, den jemand ohne Ahnung und Interesse für "Interna" so anrichtet, ständig workaroundet.

Für Performanceverlust, der nur auf Faulheit der Entwickler zurückzuführen ist und definitiv vermeidbar wäre, habe ich keinerlei Verständnis.
Anders ausgedrückt: Wenn dasselbe Spiel auch schon auf 'nem Rechner, der nur 20% der Ressourcen braucht, laufen KÖNNTE, aber nur deswegen nicht tut, weil die Levelbastler aus Desinteresse oder Bequemlichkeit ständig für die Engine "Worst-Case-Szenarios" schaffen (die mit einem Tick mehr Entwicklungsaufwand vermeidbar wären) - dann sind das nicht die Leute, die für mein Zeug Levels bauen sollen. Damit kann ich nichts anfangen.


Zitat (Bronko) "Dazu gehört es, dass jede Option ohne Umwege nutzbar ist. Der kürzeste Weg ist es mit Sicherheit, beim Spielen was zu ändern!"

Eigentlich nicht. Wie gesagt - es gibt Level-Typen, die sich während des Spielens selbst verändern. Die von Xpyderz gehören dazu. Wenn man nun ein Level halb durchgespielt hat und dann im halb durchgespielten Level etwas ändert - wie soll denn das auf den Grundzustand "umgerechnet" werden?
- Denn geändert werden muß es ja im "Grundzustand" des Levels! Das heißt, er müßte es zurück auf das Grundlevel beziehen und dann ausgehend vom Grundlevel wieder bis dahin, wo man grade war, "virtuell spielen" (ist zwar möglich - aber ein geändertes Level erzeugt beim Zocken geänderte Ergebnisse, so daß sich eben NICHT dieselbe Situation ergäbe.
Beispiel: Die Spinnen reagieren natürlich auf das Level. Andere Levelgestaltung heißt, daß sie andere Wege nehmen würden. Spinnen können auch die Teleporter benutzen...
Xpyderz hat verschiebbare Klötze und die Figuren sind durch ihre Startposition definiert. Wenn der Klotz verschoben ist, ist er eben nicht mehr an seiner Startposition. Wenn ich jetzt nach dem Verschieben an die Stelle, wo der Klotz war, einen anderen setze - wie soll er das im Grundlevel denn berücksichtigen?

Ich bin mir nicht sicher, ob das Problem hier deutlich wird - aber in Xpyderz kann (und wird) ein halb durchgespieltes Level eben anders aussehen als ein Level bei Spielstart. Xpyderz ist aber auch sowieso KEIN Turrican.
(Wobei in Turrican Levels sich zweifellos ebenfalls ändern, während man sie durchspielt. Aber hier betriffts wohl eher nur, daß die Einsatzpunkte von "Figuren" (also Boni und Spielfiguren/Figurenformationen) während des Spiels deaktiviert werden - solche Dinge lassen sich leichter editorseitig berücksichtigen.)

Was den "anderen" Editor betrifft (der Nicht-Xpyderz-Editor) :
Dieser ist für mehrere Spiele gedacht, die die gleiche Level-Engine, aber unterschiedliche Spiel-Engines benutzen können.
"Spielbarkeit im Editor" würde hier bedeuten, Figuren per Skript steuerbar zu machen. Ist zwar 'ne Idee - aber eine, die einen vergleichsweise gigantischen Performanceverlust mit sich bringt und die keine Dinge wie tausende Figuren, die sich auch im Offscreen bewegen (wie in Xpyderz) zulassen würden, außer mit 'ner entsprechenden Maschine.
Ginge zwar - aber der Preis dafür ist für mich persönlich inakzeptabel. Wenn es von mir überhaupt jemals skriptgesteuerte Figuren geben sollte, wäre das ein relativ einfaches, lineares Skript - es wäre kein so aufgeblasenes (und fehlertolerantes) Ding wie Javascript oder PHP, sondern eher so'ne Art erweiterte Mnemonic-Sprache, die dann intern (vor Spielbeginn - aber wahrscheinlich auch nicht vom Spiel selbst, sondern extern!) in "Tokens" ungewandelt würde. Damit könnten die meisten aber sowieso nichts anfangen - die wollen ja lange Klartextbefehle, aufwendige Syntax und am besten noch ne halbe GUI integrierbar, sowie, daß das Skript sich während des Spiels noch selbst verändern kann. Und daß man nur wegen solcher
Kinkerlitzchen die Performanceschraube so anzieht, könnt ich nie einsehen.

(Außerdem wären alle Spiele "gleich" - jede Spieloption gäbe es dann entweder für ALLE oder KEIN Spiel mit dieser Engine - es ist aber nicht immer sinnvoll, Engines einzubauen, die Optionen anbieten, die nie benutzt werden...)

Mit anderen Worten: Wenn ich WOLLTE, könnte ich auch ein idiotensicheres und idiotengeeignetes "2D-Game-Maker"-System programmieren, mit dem es total billig und ohne IRGENDEIN Wissen möglich wäre, so Games zu bauen - diese hätten dann aber Systemanforderungen, die - gemessen an den Fähigkeiten/Gamefeatures - viel zu hoch wären und die für 2D-Spiele für mich generell nie im Leben einzusehen wären. Daher wirds so etwas von mir auch nicht geben. Ich will nämlich nicht. Idioten werden von mir einfach nicht supportet.
Bronko
04.07.06
Mit Engine ausreizen meinte ich nicht, dass der Rechner in die Knie geht, sondern, dass man mit dem Editor auch prima alles hinkrigt, was der Programmierer in den "Originallevels" geschrieben hat. Und vielleicht etwas mehr.
Bei Doom2 kann man mit Editoren etwas bauen, dass wie eine Brücke aussieht und AUCH VERHÄLT (Man kann unten durch, und oben rüber), aber doch keine ist. Da werden Wände mit Texturen im Mittelteil hintereinander gesetzt, dass es so aussieht, als schweben Balken in der Luft. Diese Wände schweben Enginegesehen wirklich in der Luft, weil sie nicht in den Sektor eindefiniert werden, in dem die Brücke steht. Unter diesen Wänden ist ein unsichtbarer Lift, der mittels das Übertreten von Sektorengrenzen hoch und runterfährt, der Sound findet irgendwo woaders statt (Mitten im Nichts steht noch ein Teil des unsichtbarer-Lift-Sektors, der fährt dann auch immer mit hoch und runter), so das man nix hört. Sowas finde ich cool!
Schön wenn das mit einem Editor geht. Ein Idiotensicherer Edi hätte mir gesagt, dass da illegale Sektoren sind, und im schlimmsten Fall das Wad unter den Umständen nicht gespeichert/exportiert...
(Wie ich den 4D-SportsDriving aka Stunts Editor dafür HASSE)
Puh, das liegt an Dir, solche Erklärungen zu posten, die eher indirekt zum Thema gehören steckt wohl an...

Die neuen Argumente gegen das Feature (Im Level ändern) vertehe ich eher.

Und vonwegen "Idioten werden nicht supportet": Super, genau das habe ich doch gesagt! Dein erstes Arguement gegen das Feature war neben der Sinnlosigkeit nämlich, dass es eben diese Idioten verwirren würde...
Und deshalb ein so klasse Feature (Wenn es denn für die Engine möglich ist) auszulassen , das wäre regelrecht Verschwendung.



Imperial Games
04.07.06
Naja. Problem ist, daß "Spiel-integriert" halt bedeutet, daß die Leute, die gerade genügend Intelligenz ansammeln konnten, um das Game zu zocken, auch evtl aus Versehn "Level Editor" ausprobieren.
Will sagen, daß SPIELE halt schon idiotensicher sein müssen - weil gezockt wird leider oft auch von ziemlich depperten Typen. (Und TOOLS müssen es dann eben auch sein, wenn sie in diesen Spielen enthalten sind...)

Zu "4D Stunts" - das war wohl der Grund, warum ein Kumpel dafür einen eigenen Editor gecodet hat.
(Ich glaub, da gabs aber mehrere Standalone Edis von verschiedenen Freaks.)

Robert
05.07.06
Einfach das Spiel in zwei Varianten ausliefern. Unter Umständen eh sinnvoll, da ein Spiel ohne Editorfunktion schneller sein könnte.
Imperial Games
05.07.06
Nö, auf die Geschwindigkeit hats es nicht den geringsten Einfluß - aber (natürlich) auf den Speicherverbrauch der EXE.
Habe mir sowieso überlegt, daß ich mehrere EXEn compiliere - z.B. braucht ja jemand, der es nur Singleplayer spielen will, oder der es per Netzwerkkarte spielt, diesen ganzen PPP-Kram fürs serielle Modem nicht...
Auf die Art könnt man eben etwas Speicher rausfummeln, da wo's knapp wird.

Hatte ja schonmal erwähnt, daß ich auf ne ziemlich ALTE Art hier bastle - mein Zeugs ist alles Real Mode und das heißt natürlich auch, daß es mit dem Speicher < 1MB auskommen muß. (Ja, ich weiß - XMS... Aber in Xpyderz will ich kein XMS benutzen.)
Es gibt halt *manche* Windows-Versionen, die im DOS-Fenster recht wenig Speicher frei haben (glaub manche Win 9x Version konnte man mit Ach und Krach auf 505 kB kriegen - das reicht definitiv NIE IM LEBEN für das normale Xpyderz!)
Andererseits gibts (muß man ja gerechterweise auch mal erwähnen) auch Win-Versionen, die mehr <640kB (also Heap) -Speicher zur Verfügung stellen als es das echte DOS je gekonnt hätte (nämlich die - technisch maximal möglichen - 638,75 kB (klar, IVT und BIOS seg kann man ja nicht "ausblenden") - also quasi so, als würd das System selber 0 Bytes brauchen...

Aber wollt da halt wie gesagt sowieso mehrere EXEn compilieren, um bei Speicherknappheit eben bestimmte Optionen wegzulassen.
Ich bin ein großer Freund des "reduziert spielen können ist immer noch besser als GAR NICHT spielen können".
Will sagen:
Wenn ein Spiel z.B. mit 800x600 oder 640x480 auf nem Rechner unspielbar ruckelt, warum nicht ne 320x240 Variante einbauen?

Ich habe mal ein Demo gesehen, das testet vorher, wieviel RAM man hat und wenn man zu wenig hat, dreht es die Auflösung der verwendeten Texturen beim Laden runter - so hat man zwar gröbere Texturen, aber das finde ich besser als dieses "geht nich - ham wa nich" Verhalten...

(Oder anders ausgedrückt: Was bei mir "Mindestanforderung" bedeutet, ist ein Rechner, den man auch schon vor knapp 20 Jahren hätte haben können.)

Es kann eben durchaus passieren, daß ich mal ein Arcade-Spiel für Truecolor (24 bzw 32bit) und hohe Auflösung code (wenn ich jemanden finde, der sich im Ernst den Aufwand geben würde, dafür auch Patterns zu bauen, die WIRKLICH auch 24bit und Hi-Res BRAUCHEN!
(Und wenn es nur deswegen wäre, um zu beweisen, daß ich nicht deswegen normalerweise kein so Schicki-Micki-Zeugs mache, weil ich es nicht KÖNNTE, sondern weil ich mich bewußt dafür entschieden habe, es nicht zu tun... - aber nur das alleine wäre eigentlich nicht Grund genug, ein Game zu coden - da würds auch ein Demo tun...)
Aber selbst WENN ich so'n Game machen würde, würd es Low-Res Optionen haben, im Sinne dessen, daß man nicht nur 1024x768x24bit, sondern eben auch jede Kombination aus 1024/800/640/320er Auflösung und 32/24/16/15/8 Bit Farbtiefe haben kann.
(Und ehrlich gesagt hab ich wirklich schonmal testweise für Xpyderz einen CGA-Mode gecodet. Ja, genau - das ist dieses 4-farbige...)
- - - - - - - - - - -

Aber wie schon gesagt - habe ja oben dargelegt, warum "Editieren während Spielen" bei Xpyderz nicht sinnvoll ist - obwohl technisch möglich.
Der Editor ist jetzt auch nicht WIRKLICH SOOO "idiotensicher" - und man kann auch Dinge damit tun, die eigentlich im Spiel nicht viel Sinn machen würden (aber eher wenige). Aber Dinge, die das Spiel zum Absturz bringen, werden damit nicht möglich sein und solange ich keine Notwendigkeit dafür sehe (und ich kann mir nicht vorstellen, welche das sein sollte), wird das auch so bleiben.
Also es ist schon so - der Editor ist nichts für kleine Kinder, man muß sich schon damit beschäftigen wollen, wenn man Levels baut.

Er bedient sich halt meiner Meinung nach ganz OK - wenn man mit dem Keyboard einigermaßen umgehen kann, sollte es keine Schwierigkeit darstellen. (Wenn nicht, kann man sowieso kein Xpyderz zocken.)
Man fährt halt mit den Cursortasten im Feld rum (SHIFT für schneller) und mit CTRL setzt man eben die Klötze.
ALT (oder F9) ruft das zum jeweiligen Mode passende Menü auf. Man kann halt die Klötze zwar hoch/runterschalten (F11/F12 oder Bild hoch/runter), aber man kann sie eben auch aus ner 8x8 "Klotzmatrix" in nem Menü aussuchen.
Es gibt in Xpyderz sowieso nur 64 verschiedene Klötze mit fest definierten Funktionen - das wird sich auch zu keinem späteren Zeitpunkt mehr ändern. - Die zwei restlichen Bit codieren bestimmte Funktionen. ("Geheimgänge", "verschiebbarer Klotz", "Teleportsperre" usw)

Wie bereits mal erwähnt - EIGENTLICH hatte ich das mal irgendwann als Langeweile-Projekt gemacht - aber manche Projekte neigen eben zum Wachstum und entwickeln ein Eigenleben.
GENERELL bin ich eigentlich kein Freund davon, Editoren in Spiele einzubauen - weil sie dem eigentlichen Spiel Ressouren klauen und Möglichkeiten nehmen. Aber in diesem speziellen Fall war es gestalterisch/technisch möglich, da ich einen großen Teil des Editors in das geskriptete Menü auslagern konnte (nur die jeweils aktuelle Menüseite steht im RAM), so daß das Problem nicht SO gravierend war.
Für andere Arcade Games, wenn ich noch weitere mache, werden die Editoren wohl generell immer extern sein - bzw. es eher EINEN externer "Universal-Editor" geben.
- - - - - - - - - - -

Man muß eben immer dran denken: Spiele entwickeln <> Spiele spielen - das eine hat mit dem anderen nur über sieben Ecken zu tun und Development wird IMMER komplexer sein und mehr Verständnis für "Interna" erfordern als pure Anwendung/Zocken. Das ist auch hier nicht anders.
Ich ahne ohnehin, daß es 99% Idiotenlevels geben wird (alles voller Superwaffen und nun rennen wir mal mit Dauerfeuer durch) und kaum 1% von Levels, die man auch wirklich ernsthaft spielen kann und will. Aber damit muß man dann leider leben. EIGENTLICH will ich ja Xpyderz bei Release auch mit ein paar schon integrierten Levels ausstatten, hatte gehofft, daß man dafür Leute finden könnte. Aber das erste, was so Leute sagen ist: "Heh, geil, Levels fürn Spiel bauen..." und man denkt noch 'Gut, endlich jemanden gefunden' und das zweite ist dann aber gleich "...kann man ja alles voller Bomben und Superwaffen stellen..." und man denkt nur 'Schade - doch nicht.'

Ich mach mir da auch keine Illusionen, jemand Gleichgesinnte für Game Development zu finden. Hatte das ja schonmal ausgeführt.
Gibt da mehrere Sorten Leute, mit denen ich z.B. NICHTS anfangen könnte (hatte dergleichen schonmal irgendwo geschrieben) :

1) Der Spieler ohne Ahnung
Findet Games gut, würde wahnsinnig gerne Development machen, aber hat nicht auch nur die GERINGSTE Ahnung, wie ein Computer funktioniert und findet alleine grade mal den Netzschalter. Nichts für ungut, aber man hat dann einfach wirklich nicht die Zeit, den Leuten mal eben in nem 10-Minuten-Crashkurs (mehr Geduld haben die dann auch nicht) all das beizubringen, was man dazu eventuell wissen müßte.

2) Der "oberflächliche" Typ
Wenn man dem nicht eine intuitive Benutzeroberfläche zur Verfügung stellt, die quasi alles selber macht und so hightech, daß sie mindestens gedankengesteuert ist, können und wollen die nix machen. In deren Entwicklungs-GUI hat dann grundsätzlich mehr Zeit und Aufwand zu stecken als in das ganze restliche Game insgesamt.

3) Der verspielte Idiot
Siehe oben. Jemand, der da nie vorhat, mal irgendwas ernsthaft brauchbares abzuliefern, sondern eben nur so Deppenlevels.

4) Der versnobte Künstler
Jemand, der einen ständig wegen der Beschränkungen der Engine nervt und sich nie im Leben herablassen würde, seine wertvollen Kunstwerke etwa auf 256 oder auf 16 von 256 Farben zu beschränken. (Es gibt andere Leute, die schaffen sowas - und schaffen mit 256 oder sogar 16 Farben bessere Grafik als diese eingebildeten Schnösel, die eben unterhalb 16Mio Farben gar nicht erst anfangen, überhaupt IRGENDWAS designen zu wollen...)

5) Der "Flausen im Kopf" Typ
Will prinzipiell ALLES machen, hat prinzipiell aber auch alle 3 Tage Lust auf was anderes. Und das schlimmste ist: Hat, wenn es dann mal konkret werden soll, generell NIE Zeit.

6) Der Ungeduldige
Denkt, ein Computerspiel, das man in zwei Stunden durchspielt, bräuchte auch nur zwei Stunden, um es zu entwickeln. Sobald er merkt, daß es nicht so ist, ist mit ihm nichts mehr anzufangen.

7) Der "Mein Name steht drunter" Typ
Ähnelt dem Typ 5 - ist jemand, der unbedingt an 'nem Projekt beteiligt sein will - aber nicht die geringste konkrete Vorstellung hat, was er da machen will. Hauptsache, er kann sagen, er hat "irgendwie dran mitgemacht".

Die Computernutte
Jemand, der nie im Leben irgendwas machen würde, einfach, weil er sich für irgendein Projekt begeistern könnte - sondern der sich nur mit "Computer & related Stuff" beschäftigt, weil es da in bestimmten Bereichen 'ne Menge Kohle zu verdienen gibt. Solche Leute fangen gar nicht erst an, überhaupt irgendeinen Handschlag zu machen, solange man ihnen nicht fast schon vertraglich garantiert, daß das Ding a) zum Verkauf hergestellt wird und b) auch ein Hit wird.
So Leute rechnen dann damit, daß man, wenn man's NICHT verkauft - oder wenn man's zwar verkaufen wollte, aber nicht so viele Leute kaufen, wie man dachte, ihnen einen Differenzbetrag aus eigener Tasche bezahlt.

9) Der High-End-Typ
Solange nicht irgendwas ultramodern ist und auf dem neuesten System nicht nur läuft - sondern dieses auch automatisch zur unteren Mindestanforderung hat, will dieser Typ nichts mit "dem altmodischen Scheiß" zu tun haben. Meistens fehlt es so Leuten allerdings an wirklicher Fachkenntnis, um beurteilen zu können, wovon sie da eigentlich reden. (Das sind dieselben Typen, die sich 'n dickeres Auto mit dickerem Motor als der Nachbar kaufen. Nicht weil sie irgendeine Ahnung von Motoren haben oder sowas - sondern einfach nur, um der fetteste Hecht im Viertel zu sein.)
Für so jemanden machen ja schon die meisten anderen Entwickler nichts, womit sie was anfangen können. - Aber speziell ICH mit meinem DOS-Kram und Support für kleine Systeme bin ja für solche Leute der absolute Antichrist.

10) Der Kindergarten-Typ (oder -Tante)
Mag ausschließlich peacige und Kindergarten-Designs, hauptsache knuffelig und aussehend wie für Kinder von 3 Jahren an. Solche Spiele interessieren mich nicht - und so jemanden könnt ich nicht für ein cooles Arcade Game gebrauchen...

11) Der Realismus-Typ
Meistens das Gegenteil vom Typ 10: Wenn es nicht fotorealistisch aussieht, wollen die nichts damit zu tun haben.
Imperial Games
05.07.06
11) Der Realismus-Typ
Meistens das Gegenteil vom Typ 10: Wenn es nicht fotorealistisch aussieht, wollen die nichts damit zu tun haben.
Und wenn schon fotorealistisch, dann müssen es auch gleich reale Waffen (mit den korrekten Parametern), reale Kriegsfahrzeuge, reale Kriegsszenarien und all so'n Scheiß sein. Hat mich nie interessiert, find ich fürn Arcade Game auch sowieso daneben (weil Thema verfehlt).

12) Der 90er-Jahre-Typ
Für den muß alles wie "Techno" klingen und wie "Techno" aussehen. Die meisten 90er-Designs finde ich gruselig und häßlich - aber für manche Leute ist das leider die einzige Art Design, die sie sich vorstellen können. Das muß nichts schlechtes sein - es paßt nur nicht zu dem Stil, der mir so vorschwebt.

Das sind halt alles so Leute, mit denen ich so wahnsinnig wenig anfangen könnte. Besser wären halt Typen, die...
- irgendeine Beschränkung, die man aus gutem Grund (Speed, Speicher, etc) macht, technisch verstehen würden
- die darin keine Einschränkung, sondern eher eine künstlerische Herausforderung sehen
- die sich für ein Projekt begeistern können, und zwar auch für längere Zeit (so daß nicht immer nur ich derjenige bin, der andere "antreiben" muß, sondern ALLE sich immer mal wieder gegenseitig mit neuer Begeisterung anstecken, wenn einer mal n Durchhänger hat...)
- die NICHT 9 von 10 mal, wo man sie anruft/mailt, weil man irgendwas will, gerade zufällig keine Zeit haben und dann nur immer zufällig zu dem einen Termin im Jahr Zeit haben, an dem ICH mal ne wichtige Besorgung machen muß... - sondern eben wirklich wissen, akzeptieren und abkönnen, daß so'n Projekt definitiv einen Teil ihrer Freizeit kostet.
- die von sich aus NIEMALS dieses leidige Geld-Thema zur Sprache bringen, weil sie Freeware/Public Domain unterstützenswert finden und sie es machen, um die Welt um ein geiles Spiel zu bereichern und nicht ihr Portemonaie um ein paar Scheine.
- die zwar auch wirklich MAL 'ne witzige Idee haben - aber die eben damit klarkommen, daß, wenn man ein ERNSTES Spiel machen will, nicht alle 2 Sekunden blöde Gags reingehören.

Aber wenn man das so schreibt, liest es sich wie eine Regel-/Bedingungsliste - soll es keinesfalls sein.
Ich hab nur mittlerweile schon so viel in mancher Hinsicht erlebt, daß ich einfach keine Lust mehr drauf habe, daß z.B. Leute mit IHREN Projekten und IHREN Ideen ZU MIR kommen, ich mich bereiterkläre, den Coding-Part zu übernehmen und am Ende mit ALLEM alleine dastehen soll...
Oder Leute, die zwar viele Flausen, aber null Ahnung haben und die einen, wenn man ihnen 19-mal erklärt hat, warum ein Level nur 4000 Blocks breit werden kann, einen zum 20.Mal fragen und es immer noch nicht verstehen.
Man muß ja nicht gleich coden können - dafür bin ich ja da - aber so ohne jedes Verständnis/Interesse für IRGENDWAS, was computer-related ist, hats auch keinen Sinn, Computergames entwickeln zu wollen.
Sowas GINGE zwar - wenn ich 'ne große Firma wäre, mir so "Kunst machen ist OK, aber dieses Computer Dingens faß ich nicht an" Typen leisten könnte und 'ne Amme für die, die denen schonend alles beibringt, was nötig ist, um ihre Kunst mit 'nem Game zu kombinieren. Und 'ne Privatsekretärin, die denen Kaffee kocht...
Aber ich bin nur 'ne Einzelperson mit Freizeitprojekten. Im Moment habe ich (außer Xpyderz, wenn mir grad mal danach ist) keine privaten Game-Projekte am Laufen.

Aber WENN, würd ich z.B. gerne mal sowas in der Art wie R-Type oder Super Probotector machen. (Leider gibts auf PC zu wenig derartiges.)
Aber ich hab mich damit abgefunden, daß ich nie im Leben jemanden finden werde, der da irgendwie meinen Geschmack und meine Präferenzen teilt. Ich versuch' auch mittlerweile nicht mehr, so jemanden zu finden. Die ganzen Leute, die sich früher mal für sowas interessiert haben (muß es ja mal gegeben haben), sind alle entweder ausgestorben oder wurden reprogrammiert...

Aber das ist eigentlich schon wieder 'n viel zu langer Text. Nur gut, daß er sowieso in meinem Laberthread steht.
Imperial Games
05.07.06
Anmerkung:
Der Text enthält wieder einen "Smiley" - der gehört dort selbstredend nicht hin - wie in keinen meiner Texte an irgendeine Stelle so'n Ding gehört.
Es ist natürlich eine 8 und eine Klammer.

Und: zu 1) Die ZEIT (die 10 Minuten) hätte man eigentlich schon.
Aber man schaffts nicht in 10 Minuten. Und wenn man eben wirklich die Zeit kriegen würde, um es ausführlich zu erklären, würde man aber Monate allein damit verbringen.

Robert
05.07.06

Nö, auf die Geschwindigkeit hats es nicht den geringsten Einfluß - aber (natürlich) auf den Speicherverbrauch der EXE.

Ein Spiel, nicht Dein Spiel
Imperial Games
06.07.06
Ja, und welches Spiel in zwei Varianten ausliefern?

Robert
06.07.06
Jedes mit Edit-Funktionalität.
Imperial Games
18.07.06
Was ja mein Spiel einschließt - und damit die mein Spiel betreffende Erläuterung durchaus rechtfertigt - neben der Tatsache, daß es im Ansatz (und dem betreffenden Thread) ohnehin um mein Spiel ging.

Robert
18.07.06
Aber andere Spiele nicht ausschließt. In dem Thread ging's nicht um Dein Spiel, der war allgemeinerer Natur.
Imperial Games
01.09.06
Damit nicht jemand sagt, ich würd mich um die Antwort drücken, schreib ich
die, bevor ich was neues poste:

An DIESER Stelle ging's in dem Thread genau um mein Spiel - da ich im
Zusammenhang mit meinem Spiel von im Spiel eingebauten Editoren geredet
habe, sowie darüber, wieso es genau in meinem Spiel genau diese Probleme
damit geben kann.
Daß ein Spiel ohne Editorfunktion schneller sein könnte als eines mit,
wäre nur dann der Fall, wenn der Programmier n Idiot wäre... Der
Speicherverbrauch schlägt hier eher zu Buche - Spiel- und
Editorfunktionalität wird jeder einigermaßen gescheite Coder trotzdem
voneinander trennen, selbst wenn sie in ein- und dasselbe Programm
integriert sind.

An dieser Stelle mal eine Anmerkung:
Mich (als Singletask-System-Coder/Benutzer) betriffts ja nicht, da ich
ohnehin keine Wahl habe, aber:

Wenn man schon ein MULTITASKFÄHIGES System benutzt, wäre es da nicht eher
die bessere Idee, Spiel und Editor komplett getrennt (als zwei Programme)
zu gestalten und dabei lediglich dem Editor Zugriff auf dieselben
Speicherbereiche und Files zu geben, die auch das Spiel benutzt? Dann
könnt man gleich zwischen Spiel- und Editorfenster wechseln und während
des Editierens probezocken - allerdings ohne das Endprodukt
notwendigerweise mit einem platz- und geschwindigkeitsverbrauchenden
Editor zu belasten...
Weiß ja nicht, inwiefern heutige Multitask-Systene sowas können oder
inwiefern man als Coder solche Dinge einbauen kann. Aber wenn's NICHT
ginge, würde ich das Multitasking ehrlich gesagt fürn Arsch finden...

Ist halt nur so'ne Idee von mir... (Warum muß erst 'n Singletask-Entwickler
auf sowas kommen?)

Imperial Games
01.09.06
Der folgende Text bezieht sich auf das Thema "Preise von Windows Vista"
[Teil 1/2]
----------------------------------------------------------------------------
Achtung! Der hier folgende Text ist nicht für jeden interessant. Jeder, der
Klicki-Bunti als den Hauptgrund, einen Computer zu benutzen ansieht, dem
sich alles andere unterzuordnen hat, sollte den folgenden Text aus zwei
Gründen besser nicht lesen:
1) Er wird wahrscheinlich nicht verstehen, wovon darin überhaupt die Rede ist.
2) Zu den Teilen, die er grade noch versteht, fallen ihm hunderte von der
Werbeindustrie anerzogene "Reflexe" ein, die er dann 1:1 herunterbeten will.
(Funktioniert so ähnlich wie beim Pawlow-Hund...) Daß das meiste davon
auf Userverständnis-Niveau zurechtgestutzte Pseudo-Wahrheiten mit dem
Wahrheitsgehalt einer "Bild-Zeitung"-Titelseite sind, kann man den Leuten
sowieso hundertmal erzählen und beweisen und sie glauben's einem trotzdem
nicht.
Daher - Wer zu o.g. Gruppe gehört: Geht wieder spielen, das hier ist
wirklich nichts für Euch, glaubts mir einfach...
----------------------------------------------------------------------------
Hier also der Text:

Ja, das ist recht häufig das Problem bei der (Er)findung von Argumenten:
Wo keins vorhanden ist, wird eins konstruiert. So lange es irgendwie
zumindest "logisch klingt", fällt Otto-Normal-Bürger drauf rein. Und wo
das nicht reicht, kann man einfach ein klein wenig "Computer-Kauderwelsch"
einbauen - erfahrungsgemäß überliest Normalotto diese Wörter einfach und
versucht, aus dem Rest einen sinnvollen Zusammenhang zu bilden - was auch
gelingt. Nur sagt der dann etwas anderes aus als wenn man das "schwere
Wort" mit einbaut - oft sogar das Gegenteil. (Und - ob man's glaubt oder
nicht: Genau das ist auch beabsichtigt.)

Das liegt nicht daran, daß Otto Bürger dämlich wäre (OK, manchmal vielleicht
schon...), sondern eher daran, daß sich nicht jeder für den Kram so
interessiert - weil manche Leute auch noch andere Interessen haben. Und
dieses "aus teilweise vorhandenen/bekannten/verständlichen Informationen
auf den Rest schließen" ist eine normale Gehirnfunktion, die eben hier nur
ausgenutzt wird, um die Leute zu verwirren.

Weitere Methode: Man betrachtet eine "Innovation" und preist nur deren
Vorzüge. Man sagt NICHT, daß es keine Nachteile hätte, aber genauso auch
nicht, daß welche existieren. Auf die Art kann keiner sagen, man hätte
gelogen. Man hat nur selektiv weggelassen. Bei Otto Normal bewirkt das aber
den Eindruck, es gäbe keinen Nachteil. (Daß genau das beabsichtigt ist,
gehört zu dem Teil der Wahrheit, der selektiv weggelassen wird...)

Beispiel:
---------
Hier die Vorteile von im "Baukastensystem" zusammengebauten Programmen:
(Hierbei ist gemeint: Fertigbauteile in Kombination mit "Skripten")
v1 - Kompatibilität
v2 - Portabilität
v3 - Senkung der Entwicklungskosten

Hier die (normalerweise verschwiegenen) Nachteile davon:
n1 - Performanceverlust (deutsch: langsamer)
n2 - Erhöhung der Anzahl Fehlerquellen und -kombinationen (deutsch: instabiler)
n3 - Beschränkung auf Features, für die es Fertigbauteile gibt

Erklärung der Vorteile:
v1 - Kompatibilität stimmt. Solche Programme sind viel kompatibler
zueinander, da sie eigentlich die gleichen Bausteine benutzen...
ABER:
a) Firmen ist es aber oft gar nicht recht, zu Produkten der Konkurrenz
kompatibel zu sein - also finden sie schon Mittel und Wege, um das zu
vermeiden. (Glaubt mir keiner? - Man schaue sich mal die Unzahl verschiedener
Formate an, die es alleine für Files gibt, die im Prinzip alle dasselbe
tun...)

b) Firmen machen ihre Software, wenn man Glück hat, abwärtskompatibel, aber
sie wird in den wenigsten Fällen mal AUFWÄRTS-kompatibel sein, selbst wo
dies technisch möglich wäre. Spätestens, wenn man einen Datenblock, der von
einer Folgeversion erstellt wurde, erhält, stellt man fest, daß man
eigentlich sowieso gezwungen ist, ständig die neuere Version nachzukaufen.

-> Ergo: "Kompatibilität" muß hier so verstanden werden, daß Kompatibilität
MÖGLICH wäre - nicht, daß sie auch wirklich genutzt wird.
<Sarkasmus>
Wenn ich eine Atombombe bauen müßte, die nie benutzt werden, sondern
lediglich zur ABSCHRECKUNG eingesetzt werden soll, würde ich da kein
milliardenteures Drecksding, sondern 'ne Attrappe bauen und die Milliarden
für irgend etwas Sinnvolles einsetzen...
</Sarkasmus>


v2 - Portabilität stimmt. Man kann denselben Quelltext damit auf
verschiedene Systeme compilieren und sie laufen überall.
ABER:
a) Man behandelt damit alle Systeme so, als gäbe es nur ein einziges
Universalsystem - ohne die jeweiligen Vorteile/Nachteile bestimmter Systeme
zu berücksichtigen und evtl Vorteile für den User zu nutzen und Nachteile
zu umgehen. Wenn man alle Systeme wie ein einziges behandeln will - warum
baut man dann nicht gleich nur ein einziges System und läßt es mit nur
einem Betriebssystem laufen? (Ja, richtig: Man will vortäuschen, der
Endverbraucher hätte irgendeine Wahl...)

b) Die Portabilität IST ein Vorteil - für den Hersteller/Entwickler. Dem
IBM-PC-Benutzer ist wichtig, daß er 'n Programm für seinen IBM-PC bekommt -
nicht, ob das Ding auch noch für die Playstation umsetzbar wäre. Mich würde
mal interessieren, was der Benutzer denken würde, wenn man ihm sagte: "Mit
einer anderen Programmierdoktrin als der 'systemfern+portabel'-Variante
könnte dieses Programm fünfmal so schnell sein. Sie mußten sich nur deswegen
einen neuen PC kaufen, weil wir das Ding ohne großen Aufwand für uns auch
noch auf ner Konsole oder 'nem Handy umsetzen wollten..."


v3 - Senkung der Entwicklungskosten stimmt. Natürlich dauert es nicht so
lange, in systemfernen Skripten zu programmieren und auf Fertigbausteine
zurückzugreifen - da man mit den Systemen selbst dabei nie etwas zu tun hat
UND da man gleich für mind. 5 Systeme gleichzeitig entwickelt. (Da man dazu
keine Kenntnis von Systeminterna braucht - es gibt da Leute, die haben noch
nie eine Binärzahl gesehen - sind auch die Leute, die man braucht, nicht
ganz so teuer... - ich drücke das jetzt mal bewußt recht vorsichtig aus.)

Objektiv gesehen ist das natürlich ein Vorteil. Ein Vorteil für die
Herstellerseite. Denn er kann bei gleichen oder höheren Verkaufspreisen
trotzdem seine Entwicklungspreise senken und somit seine Gewinnspanne
erhöhen. Glaube aber kaum, daß den User die Gewinnspanne des Herstellers
interessiert...

-> Ergo1: Subjektiv (aus Sicht des Users) ändert sich fast nichts. Er bezahlt
das gleiche (oder etwas mehr) für dasselbe Programm (oft nur für eine neue
Version, die von Funktionalität her kaum von der Vorgängerversion
unterscheidbar ist) - ABER es kommen noch Kosten hinzu, nämlich die, die
der User für ständig neue Hardware aufwenden muß - was dem Softwarehersteller
natürlich letztendlich egal sein kann, ist ja nicht sein Geld - er kann
dafür Entwicklungskosten senken...

-> Ergo2: Systemoptimierung der Software wäre teurer für den Hersteller,
aber günstiger für den User, da der User sein System viel seltener upgraden
müßte, um dieselben Dinge tun zu können.
Aber Normaluser liest nur "Kostensenkung", denkt "hurra, billig" und schon
ist erreicht, was man wollte: Dem User einen Nachteil als Vorteil zu
verkaufen, weil er nicht richtig lesen kann...

Erklärung der Nachteile:

n1 - Performanceverlust. Wodurch kommt dieser zustande? Sind die Bausteine
nicht vernünftig programmiert? Doch, recht oft schon.
ABER:
a) Oft verbrauchen die Schnittstellen ZWISCHEN den Bausteinen wesentlich mehr
Leistung/Ressourcen als die Bausteine SELBST. So traurig und dämlich das
klingt - aber es ist die reine Wahrheit. Will leider immer keiner hören...

b) Es reicht EIN beschissen programmierter Baustein, um das ganze System
runterzuziehen und jedes darauf laufende Programm. Wer's mit dem
Programmieren ernst meint, wird mir zustimmen können, daß man manchmal sein
ganzes schönes Projekt damit kaputtmacht, irgendwelchen Mist "workarounden"
zu müssen, den irgendwer verbockt hat. (Macht'n Riesenspaß, wenn man die
genaue Natur dieses Mists nur durch systematisches Trial-&-Error herausfinden
kann...)

c) Verwendung fehlertoleranter "Skripte" anstelle von Programmcode sorgen
oft dafür, daß das System den überwiegenden Teil der Ressourcen zur
Verarbeitung (Parsen, "korrigieren", etc) der Skripte benutzt und damit
WESENTLICH weniger Leistung für die eigentlichen Aufgaben hat.
(Verwendung "dynamischer" Elemente, sowie von Objektorientierung - und
das in INTERPRETIERTEN SKRIPTEN(!) tragen ihr übriges dazu bei...)

d) a und c sind die "Fixkosten" des Systems - oder anders ausgedrückt:
Sobald ein System mal in irgendeinem Punkt einen schwachen Parameter hat,
verringert das ausschließlich den Anteil der Ressourcen, der für die
Lösung der vom User gestellten Aufgabe aufgewendet werden kann, jedoch
niemals den Anteil, den ein aufgeblasenes mehrfach indirekt verschachteltes
skriptgesteuertes Baukastensystem verbraucht. Der ist fest und gibt auch
automatisch die Minimalvoraussetzungen an. (Diese Mindestvoraussetzungen
bedeuten im allgemeinen: Mit denen läuft grade mal das System, aber der
User braucht sich nicht einbilden, daß noch IRGENDWAS anderes laufen könnte.)
Imperial Games
01.09.06
[Teil 2/2]

e) Kommt neue Hardware heraus, könnte der User hoffen, daß der übrigbleibende
Anteil Systemressourcen sich für ihn mal erhöht, d.h. daß nun endlich mal
das System nicht mehr mit der Lösung seiner eigenen Probleme zu tun hat als
mit denen des Users - ABER: Gleichzeitig kommt ein neues System heraus, das
die nun freiwerdenden Ressourcen gleich wieder verbraucht. Gut geht so etwas,
indem eine weitere Abstraktionsstufe in den Baukasten eingebaut wird. (Die
ist aber lediglich ein lustiges neues Spielzeug für Programmierer. Für den
Normalotto bedeutet es nur, daß der neu gekaufte Rechner mit dem neuen
System im Prinzip genauso lahm ist wie der alte mit dem alten System...)

Anders ausgedrückt: Im Prinzip ist das, was der Normalotto heute mit seinem
Rechner und seinem aktuellen Windows macht und machen will auch nichts
anderes als das, was er schon damals mit seinem Win3.1 damit gemacht hat.
Nur daß er damals dafür nur n 386er gebraucht hat.
Achso, ganz wichtig: Natürlich sind die bunten Bildchen, die er heutzutage
dafür anklicken kann, in TrueColor und die Fehlerjingles kommen in
Dolby-Surround... Es lebe der Fortschritt.


n2 - Erhöhung der Anzahl Fehlerquellen und -kombinationen. Ganz einfache
Logik. Wenn ich mehrere Teilsysteme habe, die alle von unterschiedlichen
Quellen stammen und von denen die Hersteller (Programmierer) gerade mal
ein paar oberflächliche Schnittstellen-Parameter kennen, jedoch nicht den
Furz einer Ahnung von deren Funktionsweise, ergibt sich folgendes Bild:
Für jedes Teilsystem ist jedes andere Teilsystem ein Gebilde, das sich so
darstellt:

Eingabe -> [mysteriöse "BlackBox", die irgendwas macht*] -> Ausgabe

(* = und hoffentlich das, was sie soll)

Aus Konkurrenz- etc. Gründen werden Spezifikationen dazu entweder gar nicht
oder nicht genau genug oder nicht vollständig angegeben.
Beispiel: Sogar MS selbst, das das unter allem liegende OS liefert, muß man
per Gerichtsbeschluß dazu zwingen, wenigstens die Schnittstellen-Specs(!!!)
mal offenzulegen. Man will also keine Sourcecodes oder sowas, sondern
lediglich die Specs der Dinge, die das OS (angeblich) zur Verfügung stellt,
um sie definitionsgemäß (statt durch Trial-&-Error-Ausschlußverfahren
herausgefunden) benutzen zu können...
<Ironie>
"Zur Verfügung stellen" versteht MS dabei so:
"Also, hier habt Ihr zwanzig Löcher, manche sind für Datensteckdosen, manche
für Stromversorgung zwischen 3 und 380 Volt und manche sind Gas- und
Wasseranschlüsse. Ihr könnt ja die Zunge dranhalten, um rauszufinden, was
die machen..."
Fragesteller ausm Publikum: "Ähem, hüstel, was issn da der Vorteil...?"
Antwort: "Alle Löcher haben exakt die gleiche Größe und Form..."
</Ironie>

Das ergibt folgendes Bild für den Fall, daß jedes System entweder fehlerfrei
ist oder maximal EINEN Fehler haben kann:

(*) EIN System kann EINEN Fehler erzeugen.

(*) ZWEI Systeme können theoretisch DREI Arten Fehler erzeugen:
- interner Fehler in System1
- interner Fehler in System2
- Fehler, der sich aus dem Zusammenspiel von Fehlern beider Systeme ergibt
PRAKTISCH gibt es jedoch weitere mögliche Fehler:
- Fehler in System1, der sich aus Vorhandensein von System2 ergibt
- Fehler in System2, der sich aus Vorhandensein von System1 ergibt
(Diese beiden Fehler entstehen schon dadurch, daß das andere System einfach
nur vorhanden ist und korrekt arbeitet.)
Und dann gibt es noch "Ring-Fehler" der Variante:
- Fehler im System1, der zu Fehler in System2 führt, der zu Fehler in System1
führt, der zu Fehler in System2 führt, ... usw.

Achja - wir waren bei ZWEI Systemen...
Bei DREI Systemen sind es THEORETISCH 7 Fehler.

Im Folgenden soll ^ bedeuten "hoch", also in Exponenten setzen.

Die Anzahl theoretisch möglicher Fehler nach DIESER Methode ergibt sich nach
der folgenden Formel: (2 ^ Anzahl_Systeme) - 1.
(Da man alle Fehler aller Systeme entweder für sich alleine stehen können
oder mit anderen kombiniert NEUE Fehler ergeben. Die "Minus 1" steht für
den Fall, wo alle Fehler =0 sind, also kein Fehler auftritt.)

Die PRAKTISCHEN Fehler sind: Anzahl_Systeme * (Anzahl_Systeme-1)
(kann man auch ausdrücken mit Anzahl_Systeme^2 - Anzahl_Systeme)
(Da jedes System das Vorhandensein jedes anderen als Ursache für
Fehlfunktion haben kann.)

Die Anzahl "Ring-Fehler" sind unbegrenzt, da sie nicht nur einen "binären
Baum", sondern quasi ein "Back-Propagation-Netz" ergeben, dessen Größe
theoretisch schon ab drei Teilsystemen gegen unendlich gehen kann...

Achso. Das war noch nicht alles! Wir sind erst bei X Systemen, aber immer
noch bei maximal EINEM MÖGLICHEN FEHLER pro Teilsystem! Es soll ja
Teilsysteme geben, die zu mehreren Fehlern fähig sind...!
Formeln hierfür sind:
Theoretische Fehler: (Mögliche_Fehler ^ Anzahl_Systeme) - 1.
Da "Mögliche_Fehler" = unbekannt, kann hier die Zahl recht groß werden.
Ein Treiber, der 1 MB groß ist, kann z.B. ca. 1 Million Fehler enthalten...
(Es reicht ja, wenn der falsche geladen wird...)

Hinzu kommen dann noch Fehler, die nicht durch die Systeme selbst entstehen,
sondern durch die unsachgemäße Anwendung der Systeme (also Bausteine), die
entweder aus mangelnder Fachkenntnis oder oft (leider) auch aus
unvollständigen und schlecht zu bekommenden Spezifikationen entstehen.

Frage: Wie könnte man diesen Nachteil beheben?
Antwort: Gar nicht.
Optimistische Antwort: Offenlegung der Schnittstellen, Interesse an Dingen,
die ein kleines Stück außerhalb des Skriptes und des eigenen Bausteins
passieren usw. könnte evtl. helfen.
Resultierende Antwort: Also gar nicht.
Frage: Warum?
Antwort: Jeder, der daran glaubt, daß bei der heutigen Art der
Softwareentwicklung das unter "Optimistische Antwort" mal in absehbarer
Zeit passieren wird, wohnt in 'nem Realitätsverzerrungsfeld oder hat die
letzten paar Jahr(zehnt)e unter 'nem großen Stein gepennt...


n3 - Beschränkung auf Features, für die es Fertigbauteile gibt. Will man
irgendetwas neues oder anderes machen, kann man es nicht, wenn man nicht
gerade ein Fertigbauteil-Bastler ist. Ansonsten ist man immer darauf
angewiesen, darauf zu warten, daß einem irgendwer das benötigte Bauteil
programmiert.
Beispiel:
Was ist denn schon dabei, ein Programm zu schreiben, das einen MPEG-Film
anzeigt, wenn man folgendes zur Verfügung hat:
- Libraries für volle Darstellung und Funktionalität von GUI-Elementen
- Libraries, die die Grafikkarte veranlassen, in einem Bildausschnitt
ein Filmframe anzuzeigen
- Libraries, die die Soundkarte veranlassen, ein Soundframe (sample) zu
spielen
- Libraries, die MPEG decodieren
- Libraries, die umständliches Klartext-Skript interpretieren und ausführen
- Einen Rechner, der schnell genug ist, sowas abzukönnen.

Da schreibt man in dem Skript einfach, wo das Fenster und die Buttons
hinsollen, macht n paar Sprünge auf fertige Subroutinen, ohne verstehen zu
müssen, was die machen und man ist fertig.
a) Da ist man in meinen Augen aber kein Programmierer mehr, sondern ein
Designer.
b) Durch Hinzufügen eines "Makers" zu den obengenannten Dingen kann man
ein Programm herstellen, mit dem jeder, der mit ner Maus Objekte übern
Bildschirm schieben kann, sich dieses Tool alleine zusammenschieben kann -
so daß DIE Art "Programmierer" gar nicht mehr gebraucht würde, denn das
kriegen die meisten User auch alleine hin...

Ein Programmierer wäre jetzt einer, der dem Ding noch IRGENDETWAS EIGENES
hinzufügen könnte, das über ein wenig Text (Marke: "Copyright by 1337 H4x0r")
und der Festlegung von ein paar Button- und Fenster-Koordinaten hinausgeht...

Vielleicht würde der Programmierer z.B. eine schnellere MPEG-Decodier-
Methode finden oder eine schnellere Anzeigemöglichkeit (z.B. indem er beides
kombiniert, dadurch die Schnittstelle wegfällt...) Dann wäre sein Programm
nicht mehr portabel. Aber es würde sich vielleicht vom Einheitsbrei dadurch
abheben, daß es die anderen performancetechnisch bei Weitem abhängt...

Achso, zu dieser "Beschränkung der Features" kommt noch ein weiterer Punkt
dazu, nämlich einer, der mit dem Performanceverlust einhergeht:
Man ist darauf angewiesen, Daten genau in den Formaten zu benutzen und sie
im Zweifel in diese zu wandeln, die der Bastler der Schnittstellen als
sinnvoll empfunden hat. Für den jeweiligen Anwendungsfall müssen sie das
nicht immer sein - und kann dazu führen, daß man mehr Zeit und Aufwand mit
der Datenaufbereitung für die Schnittstelle verbringt als mit der
Erzeugung der Daten. Oft muß man dann an 'ner anderen Stelle sogar den
gleichen Prozeß nochmal vice-versa machen, um die Daten wieder
zurückzuwandeln, d.h. das Ganze passiert nur, um es durch irgendein blödes
Nadelöhr zu kriegen, das man benutzen muß, weil es das einzige ist, was man
dafür zur Verfügung hat...
Beispiel gefällig?
"Binärer Datentransfer auf einem Draht"
vs
"Binärer Datentransfer auf einem Protokoll, dem TCP/IP aufliegt, dem HTTP
aufliegt, dem ein Klartext-Skript-Protokoll aufliegt, das Binärdaten per
Textcode darstellt mit 32bit Pro Byte - alles abgesichert durch mindestens
3 Checksummen (von denen also mind. 2 redundant sind)..."
Sowas gibts nicht? So'n Blödsinn würde keiner machen? Habt Ihr ne Ahnung...
----------------------------------------------------------------------------

Ja, ich weiß. Der Text ist total lang. Und langweilig ist er auch. Deswegen
steht er ja auch extra in diesem Langweil-Thread.
Robert
01.09.06

An DIESER Stelle ging's in dem Thread genau um mein Spiel

Ah so, Du setzt Diskussionen aus anderen Threads hier fort mit der Beschränkung, dass es dann plötzlich exklusiv um Dein Zeugs geht. Das wusste ich nicht. Aber jetzt, da ich es weiß, werde ich mich trotzdem nicht dran halten. Ich mag nämlich Werbung nicht wirklich. Ich bezahl sogar Geld dafür, dass es hier keine Werbung gibt.

Daß ein Spiel ohne Editorfunktion schneller sein könnte als eines mit,
wäre nur dann der Fall, wenn der Programmier n Idiot wäre

Ein gescheiter Editor muß frei rein- und rauszoomen können. Ein 2D-Spiel mit frei rein-/rauszoomen effizient zu implementieren geht je nach Grafikhardware ganz anders als eins ohne.
Und das "wer das und das macht ist ein Idiot" lassen wir das nächste mal weg. Wenn man in Diskussionen Erklärungen durch Beleidigungen ersetzt, verdummen die Diskussionen und durch verdummte Diskussionen verdummen die Diskussionsteilnehmer.

Weiß ja nicht, inwiefern heutige Multitask-Systene sowas können oder
inwiefern man als Coder solche Dinge einbauen kann. Aber wenn's NICHT
ginge, würde ich das Multitasking ehrlich gesagt fürn Arsch finden...

Klar geht das. Ohne einen zweiten Thread geht's aber noch leichter, zumindest wenn man das Spiel sinnvoll aufgebaut hat. Sehe deswegen den Sinn nicht. Macht man einfach eine exe und eine Library. Oder zwei exe und eine Library.

Zum neuen Text - ja, die meisten Leute ziehen sich oft Argumente aus der Nase. Insbesondere Leute, die sehr an ihrer eigenen Weltvorstellung hängen. Wenn Du Dich damit aber auf das beziehst, was ich denke (3D-GUIs?), ist Dein Kommentar unpassend. Dieses Argument nämlich ist eines von dieser Sorte, die intuitiv einleuchtend und absolut simpel erscheinen und sich erst bei näherer Betrachtung als nichtig herausstellen.
Robert
01.09.06
Und weg war es. Du darfst es gerne nochmal ohne Beleidigungen reinsetzen, auf Anfrage schick ich Dir auch den Originaltext zum modifizieren, aber ich lasse sowas nicht mehr stehen.
Robert
01.09.06
Und im Übrigen möchte ich darauf aufmerksam machen, dass dieser Beitrag nur dem Zweck dient, auf die Veränderung aufmerksam zu machen, weil sich sonst die Antwortenzahl in der Übersicht nicht ändern würde.
Bronko
02.09.06
Also jetzt hätte ich gerne die unzensierte Fassung...
Robert
02.09.06
Der zensierte Teil ist nicht weiter spannend, einfach nochmal genau das selbe wie eben schonmal.
Imperial Games
02.09.06
Und wieder ein Forum, aus dem ich mich wahrscheinlich verabschieden muß.
Ich habe mich erklärt - die Leute wollen die Erklärung nicht lesen.
Der Text enthielt keine ungerechtfertigten Beleidigungen.
Das ist nur wieder ein Versuch, Leute auf Plüsch-Peacer-Sprache zu
reduzieren, so daß Dinge, die einen maximal ankotzen, reduziert werden
müssen auf kork- und bastmäßiges "Du, das find ich nich gut, hähm...",
das nicht im Mindesten ausdrückt, was gemeint ist.
Hier mißbraucht nur mal wieder ein Operator seine Allgewalt über die
Daten - das kennt man schon. Oh, das kann man ja schon wieder als
Beleidigung auffassen, daher wird's sicher wieder gelöscht.

Wen der Originaltext interessiert, kann ihn unter (öi, nicht schummeln)
lesen. Ich lasse mich nicht zensieren. Wir leben nicht im Faschismus
und auch nicht im Kommunismus. Wen interessiert, was ich zu sagen
habe, liest es entweder unzensiert oder gar nicht.

Und damit bin ich wieder einen Schritt näher daran, ein eigenes Forum
auf meiner Seite einzurichten, in dem diskutiert werden kann, ohne das
Diskussionsmittel "Löschen des Beitrags, wenn man anderer Meinung ist"
einzusetzen.
Robert
02.09.06
Ich hab die Stelle extra schon in Deinem vorherigen Beitrag angemahnt. Genau damit hast Du schon als Du das erste mal hier im Forum aufgetaucht bist den Karsten weggeekelt, wird höchste Zeit dass das endlich aufhört. Es auf eine andere Seite zu stellen macht's freilich auch nicht besser. Seine Meinung kann man auch ohne Beleidigungen ausdrücken.
Imperial Games
02.09.06
Es gibt nicht nur DICH auf der Welt und andere Leute drücken sich anders
aus.
Aha, ein Karsten darf nicht weggeekelt werden, ein Imperial Games aber
schon. Interessant, das zu wissen.
Jeden ekeln andere Sachen weg - ich z.B. bin immer angeekelt von solchen
Admins.
Wen der Originaltext interessiert, kann ihn sich von mir per eMail
schicken lassen, indem er mir eine Mail schickt, denn der Operator hier
zieht es vor, seine Mittel zu mißbrauchen und meine Einträge zu verändern.
Außerdem findet sich meine Mailadresse auf meiner Seite.
Desweiteren bin ich gelegentlich im euirc unter dem Nick "Xpyder" zu
finden. Wenn man *hier* eben nicht reden kann und jemand trotzdem wissen
will, um was es geht, muß er mich eben anders erreichen.

Es ist schon schlimm, daß es so weit kommen muß, daß man trotz eines
vorhandenen Forums quasi "in den Untergrund" gehen muß, um sich richtig
zu unterhalten, da Einträge der Zensur unterliegen. (Und ich habe
niemanden persönlich angegriffen. Wer sich diese Jacke anzieht, ist
selbst schuld.)

Äußerst erbärmlich, daß Admins sich bisweilen so ein Armutszeugnis
ausstellen.

Robert
02.09.06
Jo, Karsten programmiert halt die interessanteren Sachen
Bronko
02.09.06
Ha, diesmal konnte ichs noch lesen!

Naja, viel neues war es ja nicht.

@Imperial: Hast du den Verlgeich zur Automobilindustrie irgendwo in einer *.txt-Datei Abgespeichert?! So für den Fall, dass einer irgendeine Sache an Windows lobt...
Das kam mitlerweile so oft, dass es genauso wirkt, wie die Zusammenfassung, was in einer vorigen Folge einer Fernsehserie geschah.
Nur dass es nicht zusammengefasst ist.

@Robert: Wo war den da der beleidigende Teil? Hab das jetzt eher überflogen, wenn es ansatzweise nach alten Passagen aussah...
Oder meintest du den Idiotenteil?

Robert
02.09.06
Genau, der Idiotenteil. Der wiederholte und vorher angemäkelte Idiotenteil.

Answer:
Name
Name:
eMail:
Website:
Comment:

Smileys
Please read the forum introduction


Search:

Back