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.
   
 

sourcecode?

conner
15.08.05
hi

hat wer den quellcode von t2002/t4 oder gar den von den original turrican's?
ich würde gern mal sehen wie die engine der turri-figur funzt.

thx
Imperial Games
15.08.05
[Teil 1/4]

Engine? Du meinst, wie man so Figur steuert oder was?
Naja. Würd sagen, man hat zwei Koordinaten, die man alles machen läßt.
Der Turrican-Sprite ist ja nur, weil viele Menschen es nicht mögen, wenn
nur Rechtecke durch die Gegend geschoben werden.
(Soll sogar Menschen geben, die denken, mit dem Erwerb einer Grafikkarte
plus Monitor, die 1600x1200Pixel bei 16Mio Farben darstellen können,
erwerben sie gleichzeitig die Berechtigung, sich über jedes existierende
oder noch geschaffene Programm/Spiel mit niedrigerer Auflösung/Farbtiefe
aufregen zu dürfen... - aber das ist ein anderes Thema.)

Also, was genau willst Du denn wissen:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1) Wer hat den Quelltext?
t2002/t4 würd mal sagen, die die's geproggt haben. Pekaro afaik.
Diese Leute sind hier im Board vertreten. Kommt drauf an, ob sie a) Dir den
Source geben wollen und b) Du was damit anfangen kannst. Denn es gibt ja
nicht nur EINE Programmiersprache, sondern eher hunderte. Und wenn Du Glück
hast, ist es in einer der Sprachen gecodet, die Du kannst.

Original Turrican: Kommt drauf an, auf welchem System. Auf den meisten
Systemen war's wohl Manfred Trenz. (www.denarisoftware.de) Auch hier kommts
natürlich drauf an, ob er Dir die Sourcen gibt - und natürlich, für welches
System. Ich würde mal schätzen, die meisten Original-Turrican-Versionen sind
in reinem Assembler gecodet. Natürlich für das jeweilige System. Wenn Du also
mit C64-Assembler (MOS6510), Amiga-Assembler (680x0), NES-Assembler (Z80?),
Spectrum ZX80-Assembler (Z80), etc. was anfangen kannst, wär das schon
hilfreich.

PC-Turrican: Sun-Project. Keine Ahnung, was die heute machen oder wo sie zu
finden sind. Aber da Turrican II (PC) meines Wissens sogar auf nem 286er noch
lief, könnte das ebenfalls Assembler sein (x86).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2) Wie die Bewegungen animiert werden?
Nun - das ist wie ne Art "Daumenkino" - d.h. die einzelnen Sprite-Phasen
müssen einzeln "gemalt" werden und werden dann nacheinander in einer "Schleife"
abgespielt - je nachdem, was die Figur gerade macht. (z.B. die Lauf-Animation,
wenn er eben läuft...) Bei symmetrischen Figuren (und Menschen sind nunmal,
zumindest, wenn so weit verkleinert, ziemlich symmetrisch), kann man in der
umgekehrten Bewegungsrichtung die Figur natürlich spiegeln.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
3) Wie man eine Figur durch ein Level bewegt?
Naja. Man weiß ja, wieviele "Ticks" pro Bewegung benutzt werden - meistens
wird dies auf dem PC NICHT mit der Bildfrequenz synchronisiert - denn die
ist nicht auf jedem Monitor/jeder Grafikkarte für die entsprechenden
Auflösungen dieselbe - (kann man aber, wenn man weiß wie, natürlich einstellen
- und hoffen, daß der Monitor das abkann...)
320x200 wird heutzutage z.B. auf CRTs mit 70 Hz dargestellt, früher 60 Hz.
Auf Laptops wird imo generell mit 60 Hz gearbeitet - das hat technische
Gründe, die mit der TFT-Technik zusammenhängen.
Also: Nehmen wir mal an, man steuert mit 50 Ticks pro Sekunde. Dann weiß man,
daß die Figur, wenn sie sich pro "Tick" um einen Pixel bewegen würde (und
ein Bildschirm wäre z.B. 320 Pixel breit) 6,4 Sekunden brauchen würde, um
von links nach rechts zu kommen (vorausgesetzt, das Bild "scrollt" nicht -
dazu komme ich aber noch). Dann weiß man schon, daß das zu langsam ist und
muß also um entsprechend mehr Pixel bewegen.
Dazu hat man, wie gesagt, zwei Koordinaten, deren Reichweite aber eben so
groß ist wie das ganze Level breit/hoch ist, evtl mit simulierten
Nachkommastellen (um z.B. sowas wie "beschleunigen/abbremsen" oder die
"Sinuskurve" beim Springen noch etwas "weicher" darstellen zu können).
Und das Level scrollt man eben so, daß man - ausgehend davon, daß die
Spielfigur der Mittelpunkt ist, immer das Level "um sie herum" darstellt,
mit der Figur drin (zusammen mit den anderen Figuren).
Wichtig bei Turrican und vielen anderen Seitenansicht-Arcade-Spielen:
Die Figur ist nicht der absolute Mittelpunkt, sondern es wird erst
angefangen, das Bild auf die Figur zu "zentrieren", wenn sie sich außerhalb
eines gedachten Rechtecks in der Bildmitte bewegt. So kann die Figur ein
kurzes Stück hin- und herlaufen, ohne daß das Bild gleich anfängt zu scrollen.
Das bringt wohl mehr "Ruhe" ins Spiel und wird auch gern vom Spieler benutzt,
um z.B. für Sprünge oder Schüsse den exakten Abstand einzunehmen, der eben
manchmal größer ist als ein "halber Screen" (und sonst würde man ja evtl
nicht mehr sehen, wohin man springt/schießt.)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4) Sprünge?
Naja. Damals auf dem C64, als ich gerade mal in Assembler angefangen hatte,
habe ich Sprünge so realisiert: Ich habe eine (interne) Variable hochgezählt,
und wenn sie einen bestimmten Wert (glaub 4 oder 5) erreicht habe, habe ich
den "Sprung-addierer" um 1 hochgezählt.
Dieser Sprung-Addierer ist eine Variable, die ich zum Sprung-Anfang auf -3
oder -4 gestellt hatte. (In Assembler gibts natürlich keine negativen Zahlen,
halt auf 252 oder 253).
Dann habe ich diesen Addierer pro "Frame" zu der Figur-Y-Koordinate (also
der "Zeile") addiert. D.h. immer wenn jemand einen Sprung initialisiert
hat (durch "hoch" drücken - viele Spiele benutzen auch einen "Sprung" Knopf,
was ich nicht verstehe - Turrican benutzt "hoch") und
a) es war noch kein Sprung aktiv - und
b) die Figur hatte gerade "festen Boden" unter den Füßen
habe ich a) den Zähler für die interne Variable eingeschaltet, c) den Sprung-
Addierer auf -4 gestellt und c) die Y-Addition für Sprung eingeschaltet.
Abgeschaltet wurde die Y-Addition automatisch, sobald die Figur festen Boden
unter den Füßen hatte.
(Anmerkung: Der Addierer wird automatisch irgendwann positiv - das ist die
Stelle, wo oben (0) die Figur die "Umkehr-Bewegung" macht.)

Desweiteren hab ich denselben Mechanismus auch benutzt, um die Figur "fallen"
zu lassen, wenn sie keinen festen Boden unter den Füßen hatte. Will sagen:
Den Addierer auf 1 gestellt, den "Internen Wert" wieder auf Zählen gestellt
und Y-Addieren aktiviert.

Mann, ich war damals klein und doof und 15 Jahre alt oder so...

Natürlich geht das besser, wenn man einfach einen größeren Addierer nimmt:
Man hat einfach einen WORD-Addierer, und den erhöht man immer um 64, dann
wird das High-Byte ja auch alle 4 Ticks um 1 erhöht.

Wer natürlich reale Sinuskurven benutzen will - sowas kann man ja mit Sinus-
Tabellen lösen - ist aber imo nicht im Geringsten nötig. Das was ICH da
benutze, entspricht wohl eher einer (simplen, aber "eleganten" Umsetzung
der "Kreisformel").

Achja: Man kann: a) Größere Addierer wählen, b) braucht keine "Sub-Addierer",
wenn man den Spielfiguren-Koordinaten selbst "Nachkommastellen" gibt. Diese
Nachkommastellen dienen nur der "Genauigkeit" und werden bei der Bildschirm-
Darstellung nicht benutzt - denn diese erfolgt (aus naheliegenden Gründen)
natürlich auf ganze Pixel gerundet.

(Falls jetzt unglaublicherweise diese Frage kommt: Diese naheliegenden Gründe
sind, daß es keine halben Pixel gibt...)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
5) Realisierung von Schüssen?
Naja. Ein Schuß ist eine "eigenständige Figur". Die startet man einfach
relativ zur Spielerkoordinate.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
6) Bewegung durchs Level, Test, wo man aneckt und wo man durchkommt?
Entweder man definiert zu den Level-Blöcken eine "Block-Map", die das
"blocken" enthält oder man definiert, welcher Farbwert "blockt" und welcher
"durchläßt" (z.B, daß alles, was man sieht, auch blockt, und alles, was den
Hintergrund durchläßt, auch für Figuren durchlässig ist. Natürlich ginge
das nicht in Turrican, weil der ja auch "vor Mauern entlang" laufen kann.

Man sollte sich eins klarmachen: Man hat nur 2 Koordinaten (X und Y sozusagen)
der Spielfigur, aber die ist natürlich nicht nur ein PUNKT, sondern eine
ganze Figur. Wer ein Korinthenkacker ist, kann jetzt den Figuren-Sprite
nehmen und eine pixelgenaue Kollisionsabfrage mit diesen Levelklötzen machen,
und wenn ein Pixel der Figur nicht mehr durchpaßt, dann einfach nicht
weitergehen. (Oder weiteranimieren, aber ohne sich weiterzubewegen, so daß

die Figur an einer Wand "auf der Stelle geht". Oder noch besser: Zusätzliche
Animationsphasen einbauen, wo die Figur die Hände gegen die Wand stemmt und
auf der Stelle geht und dabei Staub aufwirbelt mit angestrengtem Gesicht und
hervortretenden Adern auf der Stirn...)
Imperial Games
15.08.05
[Teil 2/4]

Aber wer kein Korinthenkacker ist, wird die Figur als ein "Rechteck" annehmen,
das sich "um die Figur-Koordinaten herum" befindet und die 4 Eckpunkte und
vielleicht noch zwei an der Mitte testen.

Dieses Testen passiert folgendermaßen: Man berechnet "virtuelle Punkte", wo
die Figur hinwill - d.h. man addiert die Werte, die man normal zur Figuren-
koordinate addieren würde, in Wirklichkeit zu dem 4 bis 6 Testpunkten. Für
diese testet man, ob sie sich schon "innerhalb" eines "blockenden" Klotzes
oder des blockenden Bereichs eines Klotzes befinden und wenn keiner der
Punkte das tut, setzt man die wirkliche Koordinate auf den Zielpunkt.
(Btw: man kann auch noch zusätzlich die Koordinate selber als Testpunkt
benutzen, diese befindet sich jedoch meist "in" der Figur.)

Achja, Korinthenkacker, die zweite: Das ist eventuell aber wichtig. Wenn
man mit variablen Geschwindigkeiten arbeitet, also die Figur beim Loslaufen
fürn Sekundenbruchteil erstmal von 0 auf "Fullspeed" beschleunigt - und beim
Abbremsen von "Fullspeed" auf 0 runterbremst, sollte man diesen Test (letzter
Abschnitt) in einer Schleife machen, die die aktuelle Geschwindigkeit von
"Fullspeed" auf 0 runterzählt und solange sie noch nicht 0 ist und der Test
"versagt" (also "blockt") das immer wiederholen. Damit die 1-3 Pixel oder
sowas, die die Figur sonst aus der vollen Geschwindigkeit heraus nicht
erreichen könnte, dann mit langsamerer Geschwindigkeit erreicht werden kann.

Wieso ist die Rechteck-Methode besser?
Erstens, weil sie viel schneller ist und ihre Genauigkeit dicke ausreicht.
Zweitens, weil die Animationsphasen nur "für den Spieler" sind, um "schöner
auszusehen" und nicht reversibel dann wieder für die Spielsteuerung eingesetzt
werden sollte.
Warum nicht? Naja - bei ungünstiger Wahl der Animationsphasen und des Level-
Aufbaus - und wenn man sowohl Level als auch Figur pixelgenau abfragt
(statt wie oben beschrieben: Level pixelgenau, Figur als Rechteck) - kann
man unter Umständen die Figur so im Level "verkeilen", daß man sie nicht mehr
loskriegt.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
7) Kollisionsabfrage zwischen den verschiedenen Figuren?
Das ist ne Wissenschaft für sich und jeder hat hierzu seine "eigene Religion".
Also will ich Dir keinesfalls meine aufdrängen.
Es ist so: Bei Turrican wird nur kollidiert, was sich gerade auf dem
Bildschirm befindet. Schüsse und Figuren "verschwinden", sobald sie sich
außerhalb des sichtbaren Screens befinden. (Der Turrican-Typ aka Bren McGuire
natürlich nicht - weil der Screen ja "mitscrollt"...)
Das sind wahrscheinlich kaum jemals mehr als 40 Objekte (ich denke, es sind
viel weniger) so daß hier wohl die "jedes mit jedem" Methode noch funzen
könnte. Achja: Figuren haben bestimmte Figuren-Typen! Will sagen: Sind zwei
Figuren beides "Feinde" oder "Schüsse", kann hier natürlich der Test komplett
entfallen!
Die Kollisionsabfrage geschieht da wieder mit Rechtecken oder Kreisen, die
"um die Figuren herum" gedacht sind.
Kollisionsabfrage mit Rechtecken: Es sollte, wenn man nich völlig dusslig
ist ein ein wenig Ahnung von Mathe hat, nicht schwer sein, festzustellen,
ob zwei Rechtecke sich "übereinander" befinden. Das einfachste ist eigentlich
imo:
Man nimmt von beiden Rechtecken den Mittelpunkt (das ist sowieso meist auch
die "Figuren-Koordinate"). Dann hat man ja die Breite und Höhe jedes
Rechtecks. Die teilt man durch 2 (oder man hat gleich nur die Strecken für
ein "halbes Rechteck" gespeichert - denn man braucht, wenn man die genaue
Mitte nimmt, eigentlich nur die).
Dann addiert man die "halben Breiten" beider Rechtecke der zu testenden
Figuren und ebenfalls die "halben Höhen". Auf die Art hat man jetzt zwei
Werte. X-Mindestabstand (Breite) und Y-Mindestabstand (Höhe).
Und dann zieht man die X-Koordinate einer Figur von der X-Koordinate der
anderen Figur ab (und bildet den Betrag dieses Abstands).
Den testet man, ob er kleiner als der X-Mindestabstand ist. Und nur, wenn
das der Fall ist, macht man dasselbe für Y. Wenn beide Abstände kleiner als
ihre Mindestabstände sind, haben die Figuren kollidiert.

Methode für gedachte Kreise um die Figuren herum:
Man hat von jeder Figur den Kreis-Radius. Diese addiert man. Und dann
quadriert man das Ergebnis (multipliziert es mit sich selbst) und hat
den Mindestabstand (zum Quadrat).
Dann berechnet man wieder X- und Y-Abstand, indem man die X-Koordinaten und
Y-Koordinaten wieder voneinander abzieht. (Betrag bildet entfällt diesmal.)
Beide Werte quadriert man - und dann addiert man sie zueinander.
Ist das Ergebnis kleiner als der Mindestabstand (zum Quadrat), haben beide
Figuren kollidiert, ansonsten nicht.
Nachteil: Man muß multiplizieren. Multiplikation/Division ist langsamer als
Addition/Subtraktion.
Erklärung: Anwendung des Satzes des Pythagoras - nur zieht man keine Wurzel,
sondern quadriert lieber den Mindestabstand. Denn wenn a<b gilt auch a²<b²
und Wurzel(a)<Wurzel(b). Nur dauert Wurzelziehen noch länger als Quadrieren.

Man kann auch mit Ellipsen arbeiten, das macht das ganze ein wenig komplexer,
aber ich denke, Kreise sind auch ausreichend, für Leute, denen Rechtecke oder
Quadrate zu billig sind.
Wofür Kreis-Kollisionen z.B. gut sind, ist sowas wie die Kollisionsabfrage
bei einer Explosion - und der Feststellung, ob Figuren sich im
Explosionsradius befinden. (Wenn ja, kann man ja immer noch die Wurzel ziehen
- oder mit einer Tabelle arbeiten - um herauszufinden, wie weit vom
Explosions-Zentrum entfernt die Figur war - also wieviel Schaden sie nimmt
(also wieviele "Hitpoints" sie abgezogen kriegt).

Wichtig: Wenn man um eine Figur ein Kollisions-Rechteck bildet, sollte man
bedenken, daß sich, wenn sich eine Figur "dreht" (also das Sprite "rotiert")
das Rechteck quasi "mitdrehen" muß.

Anmerkung: In XPYDERZ benutze ich ein Verfahren, das die obengenannten
Methoden mit einer weiteren kombiniert. Denn ich erlaube a) 1600 bewegliche
Objekte gleichzeitig und b) auch außerhalb des sichtbaren Screens im ganzen
Level. Natürlich kann man nicht die (theoretische) Kollision von 1600x1600
Figuren abfragen (wären 1280000, also 1,28 Millionen Kollisions-Tests).
Daher habe ich dazu ne eigene Methode entwickelt, kann das gerne mal
erklären, das würde hier aber wohl zu weit führen...

Anmerkung: "Endbosse" brauchen oft zwei verschiedene Kollisionsabfragen.
Einmal für den "ganzen Endboß" - denn man will ja nicht, daß der Spieler
"in den Endboß reinrennen" kann, ohne daß was passiert.
Und einmal für "die verwundbare Stelle" - denn oft ist nicht der ganze
Endboß zu treffen, sondern nur eine oder mehrere Stellen, die verwundbar
sind. (Manchmal muß man diese auch in einer bestimmten Reihenfolge
nacheinander ausschalten. Oder zumindest, alle ausschalten, damit der
Endboß hinüber ist.) Man kann dieses Problem natürlich auch einfach lösen,
indem man die "Hit-Zone" des Bosses einfach als eigenständige Figur
definiert und diese datentechnisch mit dem restlichen Boß verbindet.
(Wenn diese Figur = tot, dann Boß = tot.)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Hitpoints?
Jede Figur hat eine bestimmte Anzahl Hitpoints - also "wieviel Schaden kann
sie nehmen, bevor sie explodiert und gelöscht wird (zusammen natürlich mit
"Score"-Zugewinn für den Spieler). Bei Score (Punkte) gibts die Methode,
daß nur eine erledigte Figur Punkte bringt - oder daß auch jeder Treffer
Punkte bringt (manchmal bei Bossen) - oder eben beides.
Zu beachten ist hier, daß auch der Spieler - genau wie jeder andere -
ebenfalls "Hitpoints" hat. Sowie natürlich, daß Spieler-Schüsse keine
Hitpoints haben - sondern eher "austeilen".
Schüsse der Feinde unterscheiden sich von Feinden selbst eigentlich nur
dadurch, daß Feinde von Spieler-Schüssen getroffen werden können, während
dies auf Feind-Schüsse oft nicht zutrifft.
Hier wieder die Anmerkung, daß dies eine gute Gelegenheit ist, Figuren
verschiedene "Typen" zuzuweisen:
Spieler, Spielerschuß, Feind, Feindschuß, (Boß), Bonus.
Imperial Games
15.08.05
Nerv. Der Smiley ist natürlich keiner, sondern ne 8 und ne Klammer.

[Teil 3/4]
Bosse können ein "extra" Typ sein, weil sie selbst meistens dem Spieler
keine "Hitpoints abziehen", sondern ihn bei Berührung gleich killen.
Zu Feinden/Feindschüssen sollten evtl. zwei Arten von Hitpoints definiert
werden, nämlich:
a) Wieviele Hitpoints haben sie selbst?
b) Wieviele Hitpoints ziehen sie bei Berührung ab?
Für "Bosse" kann man natürlch auch einfach für "abziehen" einen "beliebigen
hohen Wert größer als die Maximalanzahl Spieler-Hitpoints" definieren.
Achja: Dieses b) braucht man natürlich nicht für jede Figur einzeln
definieren. Denn pro Figuren-Typ (also die "Art" der Figur) ist das ja
immer das gleiche. (D.h. alle "Walker" verursachen den gleichen Schaden. Und
alle haben bei Beginn die gleiche Anzahl Hitpoints, die dann bei a)
eingetragen wird. DIESER Eintrag muß allerdings für jede Figur getrennt
erfolgen, denn er ist veränderlich und bei jeder Figur anders (je nachdem,
wie oftsie schon getroffen wurde).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
9) "Spawning" (Auftauchen) der Figuren
Wenn die Figuren sich nicht im gesamten Level verteilt befinden (wie in
XPYDERZ), "spawnen" sie an bestimmten Stellen im Level. D.h. sie werden erst
"gebildet", wenn sie sich in den sichtbaren Screen hinein bewegen würden.
Das bedeutet, daß so Figuren im Level definierte "Startpunkte" bekommen,
die aktiviert werden, sobald der sichtbare Screen-Ausschnitt nah genug an
sie heran kommt. (D.h. die Bereiche direkt um den Screen herum werden auf
Spawn-Points getestet beim Scrollen.)
Hier gibt es mehrere Methoden:
a) Figuren tauchen jedesmal wieder auf, wenn man an diese Stelle kommt.
b) (wie bei Turrican) Figuren tauchen nur einmal an dieser Stelle auf.
c) Figuren tauchen nur wieder auf, wenn man ein Leben verloren hat und wieder
an diese Stelle kommt.
d) Figuren tauchen an der Stelle nur auf, wenn man sie noch nicht erschossen
hat oder (wenn Bonusgegenstand) noch nicht aufgesammelt hat.

Um a) zu realisieren, muß man lediglich beachten, daß Figuren nur spawnen
dürfen als Folge einer BEWEGUNG des Screen-Ausschnitts (da ansonsten ja
aus demselben Spawn-Punkt unendlich viele Figuren kommen würden).
Um b) zu realisieren, reicht es, den Spawn-Punkt nach einmaligem Auslösen
dieser Figur zu löschen.
Um c) zu realisieren braucht so ein Spawn-Punkt ein "Flag", für "ausgelöst".
Dieses Flag (irgendein Bit setzen) setzt man nach Verlust eines Lebens -
oder nach Verlust aller "Credits" wieder zurück.
Man kann c) auch wie b) behandeln - dann braucht man das "Flag" nicht, muß
aber nach Credits-/Leben-Verlust das Level neu laden.
Um d) zu realisieren, hat jede Figur eine "Nummer", die sie mit sich
"herumträgt" (datentechnisch gesehen). Diese Nummer ist die Nummer des
Spawn-Punkts. Wenn die Figur erschossen/aufgesammelt wird, wird der Spawn-
Punkt gelöscht. Auch hier muß dafür gesorgt werden, daß nur bei "Bewegung"
des Screenausschnitts gespawnt wird, da ansonsten der Punkt bei stehendem
Screen hunderte Figuren auswirft, bis man eine von ihnen killt. (Kann man
natürlich auch NUTZEN, um genau diesen Effekt zu erzielen, wenn man auf
sowas steht...)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10) "Spawning" des Turrican nach Verlust eines Lebens:
Im Gegensatz zu anderen Spielen, wird dies bei Turrican anders gelöst.
Andere Spiele haben 3 Methoden:
a) Nach Verlust eines Lebens fängt man immer wieder am Anfang des Levels an.
Bei riesigen Levels ist sowas echt frustrierend, daher wurde davon später
Abstand genommen, gibt aber ein paar ältere Spiele, die das noch haben.
b) Nach Verlust eines Lebens fängt man an einigen festgelegten Stellen an,
die letzte oder weiteste, die man passiert hat, gilt als der Spawn-Punkt.
Dies wird manchmal auch so gelöst, daß man erst so ein "Schild"/"Fähnchen"/
"Schaltet" drücken/umballern muß, um diesen Punkt als neuen Respawn-Punkt
zu aktivieren.
c) (wie in Turrican) Die letzte Stelle, an der die Figur für längere Zeit
(halbe Sekunde oder sowas) stillgestanden hat, ist der neue Respawn-Punkt.
Auf die Art fängt man immer relativ genau da an, wo man gestorben ist.

Wieso ist das so wichtig, das zu beachten?
Naja - gerade in so komplexen Levels kann es sonst passieren, daß man z.B.
einfach an irgendeine Stelle in das Level reingeschmissen wird, wo man
gleich wieder stirbt. Ebenfalls: Wenn man als letzte Aktion vor seinem Tod
in einen Abgrund gesprungen ist, ist es vielleicht nicht gerade günstig,
an der selben Stelle (fallend in den Abgrund) respawnt zu werden - da kann
man auch gleich "Game Over" auswählen...

Manche Spiele lösen dieses Problem dadurch, indem man kurz nach Verlust eines
Lebens für 1 bis 2 Sekunden "unverwundbar" ist (und "durchsichtig" ist oder
blinkt - oder so schnell blinkt, daß man aussieht wie durchsichtig...)
damit man nicht gleich, wenn man wieder unvorbereitet ins Kampfgetümmel
fällt, wieder den Löffel abgibt und seine Garderobenmarke wiederkriegt...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Zwei Anmerkungen am Schluß dieses - wieder mal viel zu langen und
nervtötenden Artikels:

(1) Tutorial:
Ich schreibe sowieso andauernd Tutorials für Leute á la "wie kann man...",
"wie realisiert man..." und "wie funktioniert..." - z.B. über Assembler,
über Grafik/Grafikkarten, über "Binäre Bäume" im 3D und manche so kleine
Softwarelösungen für Leute im Coding-Board, die ihre Informatik-Hausaufgaben
scheint's nich selber machen wollen und deswegen ein Coder-Forum belästigen...

Ich sags mal so: Wahrscheinlich werd ich nochmal irgendwann ein Tutorial
"Wie schreibt man ein 2D-Spiel?" bauen - mit praktischen Beispielen - wo
ich obengenanntes und vieles andere mehr noch mal genauer erkläre.

(2) Game Engine:
Ich code viel lieber Engines als daß ich fertige Spiele realisiere. Grund:
Engines sind für mich eine Programmier-Herausforderung, Spiele bauen ist nur
"User"-Kram, also eher "Handwerk", der mich als Coder nur untergeordnet
interessiert. Das könnte dazu führen, daß ich eines Tages mit einer Engine,
die Mehr-Ebenen-Levels, Scrolling und "Sprites" (also "Spielfiguren")
ermöglicht, Abfragen von Keyboard, Maus, Joystick und diversen anderen
Steuereinheiten (SNES-/PSX-Pad am LPT aka "Druckerport") beinhaltet, eine
Sound Engine hat, usw. usf... - baue, Zusammen mit nem Level-Editor und einer
"Skript-Sprache" zur Steuerung von Spielfiguren, die "Kollisionsabfragen"
mit Level oder Figuren gleich als "Event" anbietet (daß man das also nicht
mehr selber machen muß, sondern nur noch "reagieren" muß)...
Wenn mich echt mal der Kleister packt, mach ich eben wahrscheinlich mal so
eine Art "virtuelle Spielkonsole", auf der sich dann der größte Teil dieses
ganzen 2D-Krams verwirklichen ließe.

Anmerkung: Ich sagte "vielleicht". Problem ist oft folgendes: Wenn ich jetzt
sagen würde:
a) Ich will ein 2D-Spiel machen.
b) Ich mache ALLES, was Coding erfordert, selber.
c) Wer mitmachen will, sollte eines der folgenden Dinge wollen:
- Grafik/Texturen/Level-Klötze "malen"
- Sprites/Animationsphasen "malen"
- Levels bauen
- Musiken erstellen auf einer normalen "Tracker"-artigen Oberfläche
(Musiker wissen, was ich meine)

Dann passiert mir jedesmal eines oder mehrere der folgenden Dinge:

- Etliche Leute sind total begeistert und wollen alle mitmachen.

- Keiner weiß aber genau, was er eigentlich machen will oder kann.

- Sie sehen, daß man "nur" 256 Farben hat und finden es zuwenig (obwohl sie
noch nie ne Grafik mit 257 Farben oder mehr erstellt haben und es kaum
jemals auf 64 Farben bringen) und sagen: Zu altmodisch, kein Interesse.

- Sie sehen die Grafikauflösungen, mit denen ich arbeite und sagen: Zu
altmodisch, kein Interesse.

- Sie sehen, daß ich in DOS code und sagen: Zu altmodisch, kein Interesse.
(btw: Obwohl mein Zeug erfahrungsgemäß problemlos in Windows läuft.)

- Sie sehen, daß meine Editoren nicht haargenau wie ihr Windows XP aussieht
und sagen: Mit sowas kann ich nicht arbeiten, kein Interesse.

- Sie haben überhaupt keine Ahnung von Computerspielen und denken, wenn es
fünf Stunden dauert, ein Spiel durchzuspielen, dauerts höchstens zehn Stunden,
eins zu entwickeln - merken nach kurzer Zeit, daß es nicht so ist und
haben kein Interesse mehr.


Imperial Games
15.08.05
[Teil 4/4]
- Sie sehen, daß ich 2D-Spiele nicht realisiere, indem ich 3D dazu
"mißbrauche", und daß das Teil von den grafischen Effekten nicht ganz (...)
mit einem "Half Life 2" mithalten kann - und sagen, daß sie nur mitmachen
würden, wenn das Ding besser werden würde, als alle Spiele, die es derzeit
gibt - um bekannt und berühmt zu werden.

- Die erste Frage, die sie haben ist, wieviel Geld man damit verdienen kann
und erst die zweite, um welche Art von Spiel es sich handelt. Und ohne feste
Zusage eines Verdienstes fangen sie überhaupt nicht erst an. - Ein Spiel aus
Spaß an Computerspielen oder aus Spaß an der Spieleentwicklung oder weil sie
"sowas einfach mal selber machen wollen", ist für diese Leute undenkbar - sie
haben außer Geld in ihrem Leben keine weitere Motivation. Und sobald sie
merken, daß ich ihnen sowas nicht bieten kann, ist das Interesse weg.

- Sie verlieren das Interesse nach allein nach zwei Tagen, weil es extrem
viele Leute gibt, die man mit ner "fixen Idee" schnell begeistern kann, aber
die viel zu viele andere Interessen haben, um sich mindestens die für ein
kleines Spiel nötigen 2 - 3 Monate lang mal jede Woche ein paar Stunden
um das Spiel zu kümmern. (Denn die Programmierung, die viel länger dauert -
und von der ich aber auch viel schon fertig habe, würde ICH ja machen...)

Dies alles sind Gründe, wieso ich nicht mehr danach frage, ob Leute Lust
hätten, mit mir zusammen ein Spiel zu entwickeln. Denn, trotz aller
Beteuerungen - und auch wenn ich denen diese Liste vorlege und die sagen:
"Das wirst Du bei MIR nicht erleben - ICH meine das total ernst." - erlebe
ich GENAU DAS immer wieder und wieder. Und das hat MEIN Interesse an einer
Zusammenarbeit mit anderen Leuten an einem Spiel ziemlich minimiert.


Manchmal passiert es sogar, daß Leute ZU MIR kommen und sagen: "Hallo, ich
hab da grad so'n Spiel gesehen, hab tausend Ideen fürn eigenes Spiel. Du
bist doch Coder - laß uns mal zusammen ein Spiel machen..."

- Wenn sie gut sind, wissen sie wenigstens, welche Art von Spiel sie machen
wollen. (Ist das nicht gegeben, ignoriere ich die Frage einfach.)

- Sie haben tausende von Ideen - und erwarten natürlich auch gleich, daß ich
mich mal ransetze, eine Engine baue, um davon gleich mal den größten Teil
zu verwirklichen, noch bevor sie selbst überhaupt einen einzigen Pixel
gesetzt oder ein einziges Byte bewegt haben.

- Nach einer Woche (!!), die sie sich dann nicht melden und ICH SIE anrufe,
kommen so Aussagen wie "ja, ich bin da immer noch dran - bin nur zur Zeit
gerade so im Streß..."

- Nach zwei Wochen fühlen DIE sich von MIR belästigt, wenn ich sie mal nach
IHREM Projekt frage, das ich für SIE angefangen habe - und wegen denen ich
meine eigenen Projekte so lange liegenlasse! So daß ich sie am Ende nötigen
muß, sich für ihr eigenes Projekt zu interessieren.
(Will sagen: Wenn mir jemand ein Projekt vorschlägt, erwarte ich eigentlich,
daß ER sich mindestens - und eigentlich noch MEHR - dafür interessiert als
ich - und nicht umgekehrt!)

Das alles führt dazu, daß ich es heutzutage nicht mehr ernst nehme, wenn mir
irgendjemand damit kommt, daß er gerne ein Spiel machen will und (weil er
weiß, daß ich programmiere), jemanden sucht, der die Programmierung macht
und er selbst will einen Teil der Grafik/Levels machen.
(Wie gesagt: Ist nicht so, daß ich keine Grafik hinkriege - würde auch einen
Teil der Grafik, der Levels oder des Sounds selber machen. Aber zur
"Zusammenarbeit" an einem Spiel gehört MEHR, als zum Schluß seinen Namen mit
drunterzusetzen...)

Denn auch hier: Sobald ich den Leuten sage: "Ich mach sowas nicht mehr, weil
Leute erst zu mir kommen, und sich dann nachher belästigt fühlen, wenn ich
mal nachfrage." - Kommt eben auch immer: "Also ICH bin da anders..."
Ja - manche SIND in der Tat anders: Sie fühlen sich nicht belästigt - sondern
sind stattdessen plötzlich monatelang nicht erreichbar.

Deswegen:
Sobald ich mal meine anderen Projekte beendet (oder zumindest in einem für
mich zufriedenstellenden Stadium) habe, könnte ich EVENTUELL darüber
nachdenken, so eine "universelle Game Engine" zu bauen.
Btw: Das bedeutet nicht, daß man da nicht trotz dieser Engine noch
monatelange Entwicklungsarbeit für ein Spiel brauchen würde - mit anderen
Worten: Es gibt da keinen "Button" [ Create Arcade-Game ], wo das ganze Teil
ein Spiel für einen schreibt, mit Levels, Figuren, etc...
Im Sinne von:
All works done by: Imperial Games
Mouse 1x clicked by: [insert your name here]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Auch zum Tutorial: Es kommt, wann es kommt, wenn es kommt, und ob es
überhaupt kommt, werd ich mal sehen.
Auch die hier gemachten Aussagen dürfen einem ja schon weiterhelfen.
D.h. 2D-Spielfiguren haben also so ne Art "Daten-Record", in dem wichtige
Daten liegen:
- der Figuren-Typ (durchnumeriert, z.B. Spieler=0, Feind1=1, Feind2=2, bla...)
- die Koordinaten (X/Y, also Spalte/Zeile).
- die momentanen Hitpoints
- Nummer der Animationsphase
- Geschwindigkeit in X/Y-Richtung (*)
- Zusatzdaten für die Bewegung, wie z.B. (für Sprünge, etc.) momentane
Fallgeschwindigkeit
- Zusatzdaten, optional pro Spielfigur (z.B. ob und wie sie mit anderen
Figuren verbunden ist...)

(*) Diese zwei Werte können auch ersetzt sein durch 2 andere Werte, nämlich:
- Bewegungs-Winkel,
- Bewegungs-Geschwindigkeit.

Achja: Wenn eine Figur nach einem Fall festen Boden unter den Füßen hat (also
der Fall/Sprung beendet wird - also die Fallgeschwindigkeit wieder =0 wird)
kann man vorher anhand der Fallgeschwindigkeit prüfen, ob und wenn ja,
wieviele Hitpoints die Figur verliert (durch Fall aus großer Höhe).
Das "Tödliche" an so nem Fall ist ja nicht die Höhe selbst, sondern die
Endgeschwindigkeit...
Für den Turrican-Helden ist dies natürlich irrelevant, da er Sprünge und Fälle
aus gigantischen Höhen schadlos übersteht. Das ist nicht unrealistisch. Das
liegt am Turrican-Spezialanzug.

Für jeden Typ gibts dann auch nochmal eine Tabelle, die für jeden Typ so
Daten enthält wie:

- Start-Hitpoints
- Hitpoints abziehen
- X-/Y- Mindestabstand (für Kollisionsabfrage) - also Größe des Kollisions-
Rechtecks - wenn mit Kreisen oder Quadraten gearbeitet, braucht man natürlich
nur einen statt 2 Werten.
- "Typ des Typs" (würde ich "bit-codieren", zwecks "Kombination" bei Kollision)
damit ist gemeint: Ist dieser Typ eine Spielerfigur, ein Feind,
ein Spielerschuß, ein Feindschuß, ein Bonus, ein Boß...
- evtl andere Daten.

Achja: Den sogenannten "Hot-Spot" (also wo befindet sich die "wirkliche
Figuren-Koordinate" innerhalb der "Sprite-Grafik"?) würde ich zusammen mit
den Sprites abspeichern! Dann sagt man einfach nur: Stelle diesen Sprite
an Position X/Y dar und er addiert allein den richtigen "Hot-Spot".
(Btw: Der Hot-Spot sollte im "physikalischen" (nicht grafischen!)
"Schwerpunkt" der Figur liegen. Hauptsächlich wegen Grund 3)
- Grund 1: Wenn eine Figur z.B. "läuft" wird sie mal "höher", mal "niedriger" -
aber die Bewegung an sich ist halt gleichförmig linear - auf die Art spart
man sich lästiges "um-die-Ecke-Programmieren".
- Grund 2: Manche Figuren haben irgendwelche langen Haare, Fortsätze,
Ausleger, Tentakel, Strippen, wasweißich - die nur der Verschönerung dienen,
aber nicht bei der Kollisionsabfrage oder sowas mitwirken sollen. Auf die Art
kann man die "Mitte" selber auf die "Mitte der Figur" zentrieren - ohne
diesen Kram. (weil der Computer "weiß" ja nicht, was davon "wichtig" und was
"Verzierung" ist).
- Grund 3: Wenn man Figuren sich "drehen" lassen will (meine Sprite-Engine
erlaubt Drehen in 256 Winkeln und auch spiegeln) - so kann man diesen
Hot-Spot auch gleichzeitig als "Drehpunkt" benutzen. Denn ein sich drehendes
("rotierendes") Objekt dreht sich nun mal erfahrungsgemäß um seinen
physikalischen Schwerpunkt herum.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Woah, ist das schon wieder n Haufen Text. Naja. Ich hoffe, Du (und die
anderen, die's interessiert) wissen das zu würdigen. Und die, die's nicht
interessiert, sind gescheit genug, einfach wegzulesen, statt sich wieder
sinnlos drüber aufzuregen oder meine Wörter zu zählen.
(Man kann nunmal in nem Forum nicht immer nur etwas schreiben, das
ausnahmslos ALLE interessiert. Dazu sind die Interessen von Menschen einfach
zu verschieden.)

Imperial Games
15.08.05
Was ich noch vergessen habe:
In die Tabelle für die "Typen" kommt natürlich auch noch der Score, den
man mit diesem Typ verdient - entweder für jeden Treffer, fürs Killen oder
getrennt für beides.

RuvF
15.08.05
Wense dich an mich! Gib mir deine E-mailadresse und ich schicks dir
conner
15.08.05
@ Imperial Games

wow!, besten dank für die SCHNELLE und AUSFÜHRLICHE antwort.:) ist schade daß sowas ziemlich selten vorkommt.
ist eine menge input für jemanden (mich) der gerade erst angefangen hat zu proggen, und das auch noch in *hüstel* blitzbasic. zwar hab ich keine konkrete idee für ein spiel, vorerst bin ich dabei die engine für den helden zu schreiben. neben den klassikern wie springen, leitern hochklettern, schräge hügel hochlaufen sollen auch dinge wie z.b. aus dem stand hochspringen und einen vorsprung erklimmen a la flashback, an einem seil hangeln und andere funktionen vorkommen.
turrican gehört zwar nicht zu den games, die ich gerne (schon damals zu c64 und amiga zeiten) spiele, da das gameplay eher uninteressant ist. nur zu turrican gibt’s halt die meisten clone und foren, was jump’n’run betrifft. und wo’s viele clone auf dem pc gibt, das gibt’s auch n menge verschiedenen sourcecode. darum die frage nach dem code (in C oder basic).
ps: da ich hier neu bin, sagt mir dein name nichts. ich würde aber gerne mal ein paar deiner games zocken, wenn ich wüßte *sorry* welche und wo’s die gibt.




@RuvF

is’n scherz, oder....
conner
15.08.05
’ sollte eigentlich ein apostroph sein
Bronko
15.08.05
Dieser mini-Turricanclone wurde in Blitz-Basic geschrieben, das dürfte für dich dann am interessantesten sein. http://www.blitzcoder.com/cgi-bin/showcase/showcase_showentry.pl?id=shezzor06022002174252 :)
Robert
15.08.05
Kleiner Off-Topic-Exkurs: Mit welchem Programm bekommst Du die ’ hin?
Imperial Games
16.08.05
Die werden bei mir auch (natürlich) als ’ angezeigt - weil mein
Browser natürlich nur die "gebräuchlichen" HTML-ASCIIs kann (also bis 255).
Btw: Was fürn Zeichen müßte das eigentlich sein? So'ne Art Apostroph-Ersatz?

@conner:
Oh, bin ja erstaunt: Jemand weiß mal zu würdigen, daß ich mir die Mühe
mache. Die meisten Leute beschweren sich immer eher über meine langen
Texte...
Daß es zu Turrican die meisten Clones und Foren gibt, liegt wohl daran,
daß nicht jeder Deiner Meinung ist ("uninteressantes Gameplay" und so).

PS: Daß Dir mein Name nichts sagt, ist keineswegs schlimm. Den muß man
auch nicht kennen. Meine Games - wenn man sie überhaupt so nennen kann -
sind eher Müll, kaum empfehlenswert. (Und wenn Du das Gameplay von Turrican
schon "uninteressant" findest, wirst Du *meine* Games mindestens ätzend
finden.)

Slayer
16.08.05
@conner:
Nenn' mal bitte ein paar Spiele bei denen du das Gampley interessant findest, und am besten auch gleich warum. So als Vergleich.
Torsten
17.08.05
Als State Machine realisiert man sowas wohl am Einfachsten.

********************
* TURRICAN MODES : *
********************


- TURRICAN_STANDING:

Turrican steht solange, bis er entweder
* die Bloecke unter den Fuessen verliert
-> TURRICAN_FALLING
oder
* der Joystick nach oben gedrueckt wird
-> TURRICAN_JUMPING
oder
* der Joystick nach unten gedrueckt wird
-> TURRICAN_KNEEING

oder falls der Joystick nach links oder rechts gedrueckt wird
* stimmt die gedrueckte Joystickrichtung mit der
Spriterichtung NICHT ueberein, wechselt die Spriterichtung
sonst
-> TURRICAN_RUNNING

- TURRICAN_KNEEING:

Turrican kniet solange, bis er entweder
* die Bloecke unter den Knien verliert
-> TURRICAN_STANDING
oder
* der Joystick nach oben gedrueckt wird
oder
* der Joystick nicht nach unten gedrueckt wird
-> TURRICAN_STANDING

oder falls der Joystick nach links oder rechts gedrueckt wird
* stimmt die gedrueckte Joystickrichtung mit der
Spriterichtung NICHT ueberein, wechselt die Spriterichtung

- TURRICAN_RUNNING:

Turrican rennt solange, bis er entweder
* die Bloecke unter den Fuessen verliert
-> TURRICAN_STANDING
oder
* an Bloecke stoesst
-> TURRICAN_STANDING
oder
* der Joystick nach unten gedrueckt wird
-> TURRICAN_STANDING
oder
* der Joystick nach oben gedrueckt wird
-> TURRICAN_STANDING
oder
* die Joystickrichtung NICHT mit der Spriterichtung
uebereinstimmt
-> TURRICAN_STANDING
oder
* der Joystick losgelassen wird
-> TURRICAN_STANDING

- TURRICAN_JUMPING:

Turrican springt solange, bis er entweder
* die maximale Sprunghoehe ueberschritten hat
-> TURRICAN_FALLING
oder
* gegen einen Block stoesst
-> TURRICAN_FALLING
oder
* falls der Joystick nicht mehr nach oben gedrueckt wird
-> TURRICAN_FALLING

oder falls der Joystick nach links oder rechts gedrueckt wird
* stimmt die Joystickrichtung mit der aktuellen
Spriterichtung ueberein
dann bewegt sich Turrican weiter in diese
Richtung
oder
* ist die Joystickrichtung entgegengesetzt der
Spriterichtung
dann wechselt Turrican die Spriterichtung

- TURRICAN_FALLING:

Turrican faellt solange, bis er entweder
* auf einem Block landet
-> TURRICAN_STANDING
oder
* das Mapende erreicht hat
-> TURRICAN_DYING

oder falls der Joystick nach links oder rechts gedrueckt wird
* stimmt die Joystickrichtung mit der aktuellen
Spriterichtung ueberein
dann bewegt sich Turrican weiter in diese Richtung
oder
* ist die Joystickrichtung entgegengesetzt der
Spriterichtung
dann wechselt Turrican die Spriterichtung

Torsten
17.08.05
Leider ist die Formatierung mit Tabs verlorengegangen,
ich hoffe du kannst aber trotzdem was damit anfangen.
conner
17.08.05
@Slayer

ist ja nicht so daß ich turrican nie gespielt hätte, halt nur verdammt selten. ganauso wie gods, lionheart, ghosts 'n goblins, chuck rock und andere plattform spiele zu amiga zeiten. grafisch, musikalisch und programmiertechnisch waren viele games dieses genres gut. allerdings waren sie doch in einem punkt immer gleich: alles abballern, den endboss töten, zum levelausgang rennen und im nächsten level quasi das ganze wieder von vorne.
richtig laune machten nur shadow of the beast 2 und 3, flashback und another world. warum? weil sie die einzigen jump'n'run games waren, die adventure, bzw. rätselelemente haben.
ansonsten habe ich überwiegend adventures und strategiespiele gezockt. heutzutage spiele ich im jahr vielleicht ein paar tage, und dann auch nur noch echtzeitstrategie.
und warum will ich jetzt ausgerechnet ein plattformspiel programmieren? einfach nur um des proggen's willen und jum'n'run spiele sind halt für den einstieg (nach sidescrolling shootern oder horizontalscrolling shootern) mit die einfachste zu realisierenden projekte.

Mr Return
17.08.05
ps:

http://www.smash-designs.de/

hier hab ich den c64 source von turrican 3 gefunden. ist alles im d64-format und muss wohl via einem c64 emulator mit turbo ass geöffnet werden.
jetzt muss ich erstmal schauen wo ich den assembler wegbekomme und wie der ganze kram dann auf'n c64 funzt.
Imperial Games
18.08.05
Achja, jetzt fällts mir wieder ein:
AEG (einer der Coder von Smash Designs, der auch Turrican 3 für C64 gemacht
hat) hat mal irgendwo geschrieben, daß er nach Beendigung des Projekts
die Sourcen veröffentlichen will.

Allerdings @conner: Das wäre dann natürlich Assembler-Code für C64.
(also MOS6510 CPU).
Weiß nicht, ob Du damit was anfangen kannst.

Zum Thema Spiele:
Adventures (sowas wie Lucas Arts Zeug) finde ich klasse.

Strategiespiele (Echtzeitstrategie vor allem) finde ich sterbenslangweilig.

Das coole an so Spielen wir Turrican ist:
- Trainieren der eigenen Geschicklichkeit, Levels werden ja immer schwerer.
- Suchen von Bonusgegenständen
- Nicht zuletzt natürlich Stil und Design.

Es geht bei "Plattformern" nicht darum, irgendwie eine bahnbrechende "Story"
oder sowas zu erfinden. "Schach" ist schließlich auch nach jahrhunderten
noch beliebt - und hat auch keinerlei Story (bzw immer dieselbe).
Es sind hauptsächlich Geschicklichkeitsspiele.
(Schafft man's, so fix zu reagieren? Schafft man's, auf die Plattform zu
kommen, weil man genau im richtigen Moment abspringt? Kann man sich die
Wege merken, um abzuschätzen, wo man herkommt und wo man sich im Level
befindet? - usw.)

Strategiespiele sind ja so gesehen auch immer gleich: Man spielt irgendein
Kriegsszenario - gewonnen hat, wer am Ende noch Figuren hat.

Am einfachsten zu realisieren sind imo nicht Plattformer/2D-Shooter.
Die sind zwar vergleichsweise einfach - aber wenn Du was noch einfacheres
willst, sind so "one Screen" Spiele (also ohne "Scrolling") noch leichter.
Zum Beispiel Denkspiele wie Tetris oder nen Haufen Artverwandte (der Marke:
Elemente fallen von oben in einen "Container" und müssen irgendwie kombiniert
werden).
Oder Spiele wie z.B. Space Invaders, Block Out (aka Arkanoid), Snake,
Centipede, Donkey Kong...
Donkey Kong ist beispielsweise ein Plattformer, der auch nur (im Original)
"One Screen" ist.

Wenn ICH ein Spiel mache, kommts mir allerdings nicht drauf an, "irgendwas
einfaches" zu machen, nur "damit's fertig wird" - obwohl ich selber sowas
nicht abkann.
Wenn ICH ein Spiel mache, dann will ich, daß es irgendwem mal Spaß macht.
Und das kann man wahrscheinlich nur bei nem Genre einschätzen, das einem
selber Spaß macht. Wieso machste kein Strategiespiel? Btw: Strategiespiele
MÜSSEN nicht immer "isometrisch" oder "3D" sein. Man kann die auch "in
Draufsicht" machen. So waren die früher alle.
(Außerdem kann man auch mit ner gescheiten "2D"-Engine so'ne Art "Pseudo-3D"
ganz ausreichend simulieren.

Imo sollte aber der Grund, ein Spiel zu machen, nicht sein, "weil einem
nichts besseres einfällt"... - aber das muß natürlich jeder selber wissen.)

Slayer
18.08.05

"...halt nur verdammt selten."


Vielleicht ist das ein Grund warum es dir noch so gefällt.


"allerdings waren sie doch in einem punkt immer gleich:..."


Naja, bei Flashback ist das nicht viel anders. Man geht von Bild zu Bild und löst immer die gleichen "Rätsel" und ähnliche Spielesituationen. SotB ist auch nicht abwechslungsreicher. Aber klar, wenn man mehr auf Adventure und Echtzeitstrategie steht ist Turrican nicht unbedingt das Richtige für einen.

Aber das Bonus items suchen könnte man ja etwas als Adventure-Anteil auslegen.


"...mit die einfachste zu realisierenden projekte."


Ein Pong wäre wohl einfacher.

Answer:
Name
Name:
eMail:
Website:
Comment:

Smileys
Please read the forum introduction


Search:

Back