wobo hat geschrieben:Mensch, schreibst Du viel Text. Jetzt ist mein Kopf voller Gegenpositionen und Befürwortungen zu Deinen Ausführungen, dass ich fast gar nicht mehr weiß, was ich zu Deinem Game XPYDERZ schreiben wollte:
Ja, ich bin bekannt dafür, viel und ausführlich zu schreiben, um zu vermeiden, falsch verstanden zu werden (was leider trotzdem oft noch passiert).
wobo hat geschrieben:Eines vorweg: Ich konnte das Spiel nur ein paar Minuten antesten und so vielleicht einen ersten, oberflächlichen Eindruck bekommen. Wie schon geschrieben, gibt mein derzeit schnellster DOS-PC (p75) immer nach ca. 10 Min. den Geist auf.
Normalerweise braucht man auch nur maximal 10 Minuten, um das Standardlevel durchzuspielen, wenn man etwas geübt hat...
wobo hat geschrieben:1. Auf dem p75 scrollt Dein Game wirklich flüssig und mühelos in alle Richtungen, auch dann, wenn am Screen ordentlich was los ist (was eigentlich dauernd der Fall ist). DAß alles, wirklich alles selbt gemacht ist, ist auch noch extra Respekt wert. Ich denke, ich kann wirklich einschätzen, was es für Arbeit ist, wenn jemand Low-Level-Programmierung, Game-Programmierung, Grafiken und Game-/Leveldesign komplett selbst macht.
Danke für die Blumen.
wobo hat geschrieben:Außerdem ist die Top-Down / Bird's-Eye-Perspektive ohnehin ein Pluspunkt bei mir. Ich wollte selber immer mal ein Game aus dieser Perspektive schreiben.
Und ich wäre froh, wenn ich mal jemanden hätte, der mit mir zusammen mal ein Spiel machen wollen würde. Der müßte nichtmal programmieren können - es gibt ja auch noch so Aufgaben wie Levels bauen, Grafiken erstellen, etc...
Übrigens sind 2D Vogelperspektive-Spiele leichter zu machen.
Bei Seitenansicht muß man für die Figuren auch noch die ganzen Dinge wie Springen und Herunterfallen berücksichtigen - und damit es nicht seltsam aussieht, eben auch mit Beschleunigung/Verzögerung arbeiten...
wobo hat geschrieben:Auch noch positiv ist, dass ich überhaupt keinen Fehler feststellen konnte. Ich denke da nur deswegen daran, weil selbst gemachte Software auf anderen Rechner gern abstürzt. Bei Dir konnte ich derartiges überhaupt bemerken. Dass das ganze PrePreRelease nur ganze 460 kb RAM verbraucht, hat mich auch noch ordentlich in Erstaunen verbracht.
Ja, leider braucht die Vollversion dann wirklich so um die 610 kB - was daran liegt, daß da dann der Leveleditor und der Multiplayer (vollständiger TCP/IP Stack) enthalten ist. Das hab ich in der PrePreRelease auskommentiert. Allerdings will ich die Vollversion dann in 4 Arten installierbar machen:
- Mini (ohne Leveleditor, ohne Multiplayer)
- Multiplayer (ohne Leveleditor, mit Multiplayer)
- Developer (mit Leveleditor, ohne Multiplayer)
- Complete (mit Leveleditor, mit Multiplayer)
Die Leute, die wenig Speicher haben, können dann z.B. zum Levels bauen die Developer nehmen und zum Multiplayer eben diese. Single Player geht natürlich in allen Versionen...
wobo hat geschrieben:2. Dennoch bin ich mit dem Game nicht so richtig "warm" geworden:
a) Das mag vielleicht schon daran liegen, dass ich eine natürliche Abneigung gegen Panzer habe und deswegen wohl auch noch nie ein Spiel mit Schwerpunkt Panzer gerne gespielt habe. Mir wäre es wohl lieber gewesen, Du hättest ein (wenn auch doof aussehendes) Männchen/Weibchen in TopDown gezeichnet...
Ich hatte schonmal erklärt, warum ich einen Panzer benutzt habe. Daß es nichts mit Kriegsspielen zu tun hat. Daß er eher wie ein Spielzeugpanzer aussieht. Und daß Figuren von oben eben irgendwie kaum noch als solche zu erkennen sind. Außerdem ist ne Figur mit 'ner Waffe - im Prinzip auch nichts anderes als 'n bewaffneter Panzer.
Es ist halt ein kleines doofes Ballerspiel und man sollte sich nicht über eine eventuelle "Story" dahinter soviel Gedanken machen.
wobo hat geschrieben:b) Jedenfalls bin auch mit der Steuerung nicht so klar gekommen. Bei der Standard-Steuerung dreht sich der Panzer stufenlos in die letztlich gewünschte Himmelsrichtung. Das verwirrt mich aber immer, dass ich dann versuche, mit neuen Pfeiltastendrücken der Drehung nachzuhelfen. Mir wäre es lieber gewesen, die 8 Himmelsrichtung würden direkt, also ohne Drehung angesprungen.
Bei der Alternativsteuerung (MicroMachine) dagegen hätte ich mir mehr als die 8 Himmelsrichtungen zur Fortbewegung gewünscht. jetzt kann der Panzer in 45-Grad-Schritten fortbewegt werden. Hier hätte ich mir wohl 22.5-Grad-Schritte gewünscht.
Du scheinst da irgendwas falsch verstanden zu haben:
ARCADE:
Die Standard-Steuerung ("Arcade") steuert so, daß man die 8 Himmelsrichtungen hat, je nachdem, welche Cursortasten man drückt (oben+links zusammen geht halt nach schräg oben links).
Außerdem fährt der Panzer SOFORT in die Richtung, in der man steuert, lediglich die Schußrichtung zieht dann noch nach (zusammen mit dem Panzersprite). Man kann sogar ALT gedrückt halten, dann kann man woanders hin fahren als man schießt.
CRUISE:
Die Alternativ-Steuerung ("Cruise") steuert so, daß man mit hoch/runter vor und zurück fährt und mit links/rechts den Panzer in 256 Stufen drehen kann. (Daß es bei Dir so aussieht, als wären es nur 22,5°, liegt wohl eher an der geringen Framerate.) Man fährt dann immer in die genaue Richtung, wohin man sich dreht. Wenn man hier ALT gedrückt hält, kann man statt sich zu drehen, nach links und rechts "gleiten" (in Doom nennt sich das "Strafe Mode").
wobo hat geschrieben:Mein Wunsch also wäre eine Easy-8-Himmelsrichtungen-Direkt - Steuerung und eine fein aufgelöste Alternativ-Steuerung ...
Also eigentlich ist das doch schon so... Die Direkt-Steurung hat 8 Himmelsrichtungen, nur daß sich wenn man die Richtung drückt, sich die Figur (Panzer) erst noch dahin dreht. Ich wollte so ein "dahinschnipsen" in die Richtung vermeiden, das fand ich zu doof.
wobo hat geschrieben:Meine fehlenden Steuerungsfähigkeiten sind aber auch meiner fehlenden Game-Erfahrung geschuldet. Ich "game" allenfalls 2 Mal/Jahr...
Ich spiele auch selbst recht selten mal irgend etwas. Bin auch ein wahnsinnig schlechter Spieler. (Mal abgesehen davon, daß ich ja auch alt bin.)
wobo hat geschrieben:c) Ansonsten noch: Ich habe mal versucht einen Mode 160x200x256 hardwaremäßig hinzubekommen, was fehlgeschlagen war. Bei Dir hab ich den Eindruck, dass Du den 160x200-Mode eher software-seitig einstellst/behandelst, da ja die sprites alle noch 320x200 sein dürften. Jedenfalls kann ich beim Umschalten von 320x200 auf 160x200 keinen Geschwindigkeitsvorteil feststellen: Beim p75 flutscht ohnehin alles, beim 486dx40vl ist beides (gefühlt) gleich langsam. Wäre es nicht möglich, dass Du für den Hintergrund 80x200 nimmst. Im ModeX könntest Du dann alle 4 Bitplanes (=4 pixel) auf einmal beschreiben und das quasi linear. Das wäre natürlich sehr Low-Res, aber das ist halt der Preis für langsame PCs (wie meine).
Also, das hast Du falsch verstanden.
Ich BENUTZE das HARDWAREMÄßIGE 160x200 für das Level! (d.h. mit verlinkten Planes 0+1 und 2+3) D.h. das Level braucht dann nur noch die halbe Zeit, um sich aufzubauen, weil es eben halb soviele Pixel sind. Ichbenutze also für den LowRes Mode jeweils 2 BitPlanes gleichzeitig. Mit 4 Bit Planes gleichzeitig wäre rein technisch auch möglich gewesen - aber das sah dann einfach schon zu häßlich aus.
Die Sprites dagegen werden weiterhin im 4-Plane Mode gezeichnet. (Level und Sprites werden ja von unterschiedlichen Subroutinen dargestellt).
Ich hätte es auch noch so machen können, daß die Spriteroutine ebenfalls auch noch den LowRes Mode unterstützt - wollte ich aber nicht, ebenfalls aus ästhetischen Gründen.
Manche verstehen diesen planebasierten Hardware-Lowres falsch. Man erzeugt damit keine Auflösung von 160x200, sondern man kann mehrere der Planes gleichzeitig mit einem einzigen Befehl ansprechen - was bei ModeX dazu führt, daß man mehrere nebeneinanderliegende Pixel mit nur einem Schreibzugriff setzt.
(Für die Figuren setze ich die Plane eben für jede Spalte neu. Das Level und die Figuren werden nicht gleichzeitig erzeugt - erst wird das Level geschrieben und dann die Figuren draufgesetzt. Würde man es wirklich so machen, daß man die Figuren während des Levelzeichnens gleich mitgeneriert, würde das zwar weniger Grafikkartenzugriffe erfordern (weil die Levelpixel "unter" den Figuren nicht mit übertragen werden würden - würde aber so eine komplexe Routine und einen derartigen Rechenaufwand erfordern, daß die durch die Wenigerbelastung der Grafikkarte freigewordene Rechenzeit von der CPU gleich wieder mehrfach aufgefressen werden würde.)
(Übrigens: Ich KANN auch auch einen echten 160x200 Pixel Mode erzeugen - technisch kein Problem- dann wäre aber ALLES 160x200 - auch die Schrift... - das muß ja nicht sein..)
Alternativ könnte man natürlich auch das Bild verkleinern. Meine Ausgaberoutine für die Levels/Sprites läßt das ohne weiteres zu. Also daß das Bild zwar in voller Auflösung ist, aber eben mit 160x100 Pixeln, in der Bildmitte dargestellt und die Sprites und Levelblöcke nur 1/4 so groß. Für den "lokal Multiplayer" wird das sowieso so gemacht - weil da nämlich mit Splitscreen gespielt werden kann.
Also quasi wäre das dann eine Option, wo man (wie bei Doom & Co) mit der +/- Taste (und/oder im Menü) die Bildgröße verkleinern kann. Allerdings habe ich die Darstellungsroutine auf "Stufen" beschränkt, also geht nur 1/2, 1/4, 1/8 usw. Der Grund dafür ist: Ich hatte die Routine schon so, daß es stufenlos ging - aber für Nicht-2er-Potenzen sieht so etwas einfach bescheiden aus, weil dann beim Scrollen die Pixel so flimmern (erscheinen/verschwinden etc.) und davon bekommt man ja irgendwann Augenkrebs.
Daß es übrigens auf einem 486er DX40 nicht so performt, liegt wohl weniger an der CPU als vielmehr an der langsamen Grafikkarte. Ich weiß - es ist eine steinkalte Schande, aber es ist eben so.
wobo hat geschrieben:Wie gesagt, nimm' Dir meine Kritik bitte nicht zu sehr zu Herzen, da ich a) kein Gamer und b) ein furchtbar viel schlechterer Programmierer bin.
Ich habe mit Kritik überhaupt kein Problem.
Und ich weiß, daß dieses Xpyderz nicht perfekt ist. Es war halt ein Versuch meinerseits, ein Fullscreen + scrollendes kleines Ballerspiel zu bauen. Es ist nicht der Weisheit letzter Schluß und sollte es auch nie sein.