Banner left   Banner center   Banner right

Germanenglish Home · News · Diary · Screenshots · Documentation (Wiki) · Downloads · Guestbook · Forum

Home · Benutzer registrieren · Suchen · Statistik · FAQ · Benutzerliste

Zur Zeit online: keiner ausser dir

 X-Force - Fight For Destiny - Forum —› Verbesserungsvorschläge/Ideen —› Open Source

Seite: << [1] 2 [3] >>

Autor Mitteilung
verfasst am: 19.12.2003, 06:13 · Edited by: AshSerty
Registrierdatum: 10.12.2003, 06:45

 Beiträge: 36
Am allerdringendsden brauchen wir aber ersteinmal noch mehr Betatester.
In Hoffnung auf gute zusammenarbeit...
(die Kritik"Länder/Finanzen/Wochenbilanz-Menüs etc." war echt gut)


Bringt doch einfach jede Beta gleichzeitig als Spiel raus, das mit der ungeraden Zahl ist dann stets die instabile (die man sich ja nicht laden muss aber kann) und das mit der geraden Versionsnummer, ist dann immer die vergleichsweise stabile X-Force Binary dazu!

Solange mir noch irgendwas für das Spiel einfällt, schreib ich das doch gerne oder im Bugtracker, weiter dazu rein. :)

Nur auch mal, etwas wieder komplett über Board zu werfen um was neues konzipieren zu können, auch wenn es schon funktionierte, bleiben ja Sachen des Hauptprogrammierers.
Wenn jetzt Grafiken und Sets erstellt werden, für die jetzige ISO-Engine, dann kann man sie vielleicht später selbst nicht mehr erweitern, wie zu etwas ähnlichem wie z.B der ISO-Landschaftseditor in simcity, der sich auch für Tiefen und Höhenprofile einstellen ließ und damit alle erdenklichen Manipulationen der Umwelt im Spiel erlaubte, nur in einer Ebene zu hantieren wie auf einem Schachbrett, ist doch garnicht nicht mehr zeitgemäß, sowas wünscht ich mir noch. :)


verfasst am: 19.12.2003, 12:48
Registrierdatum: 05.11.2003, 15:19

 Beiträge: 131
Da muß ich dir recht geben, das felht mir auch noch, ich bin auch der Meinung das Höhenunterschiede bei den Karten der Bodeneinsätze unbedingt noch reinmüssen. Würde mich mal interessieren wie die andren darüber denken. Aber meiner Meinung nach sollten wir genau das gleich nach dem nächsten Release in Angriff nehmen, den je länger wir warten, um so schwerer wird es dass dann noch einzubauen...
verfasst am: 19.12.2003, 16:25
Teammember

Registrierdatum: 06.09.2003, 11:47

 Beiträge: 107
Wenn ihr keine Höhenunterschiede einbaut, habt ihr auch keine Entschuldigung mehr um Minipanzer oder sonstige mehrere Tiles grosse Mover wegzulassen!
verfasst am: 19.12.2003, 23:20
Registrierdatum: 10.12.2003, 06:45

 Beiträge: 36
Wenn ihr keine Höhenunterschiede einbaut, habt ihr auch keine Entschuldigung mehr um Minipanzer oder sonstige mehrere Tiles grosse Mover wegzulassen!

Das Problem zu lösen wär aber spannend.

Meiner Meinung nach müsste man dafür die Auflösung der jetzigen Isoengine
1. verdoppeln oder verdreifachen, so das auf einem Feld wo jetzt 10x10Tiles sind, dann, 20x20=400Tiles sind oder 30x30=900Tiles. Das erlaubt nebenbei auch, das die Sichtfelder nicht mehr so stark treppenförmig aussehen.

2. mehrere disese Isoebenen werden dann übereinandergelegt,vielleicht erstmal 3, bei einem höhenunterschied von einem Tile.
Die in der Mitte ist die eigentlich Ebene. Wenn diese Ebene im Spiel beschädigt wird, wird die darunterliegende aufgedeckt. Alle Tiles an dem Rand, der Ebene 2, die nicht mehr entfernt werden um die darunter zu liegenden aufzudecken, werden dann vom Programm gegen schräge Tiles ausgetauscht, die die Ebenen miteinander verbinden!

Wie ein grösserer SpielTile, diese Schrägen nun betreten kann um die Ebenen zu wechseln, scheint ein physikalischen Wunder zu sein ist es aber nicht. Dafür nimmt man einfach zwischen den 3 Hauptebenen, einfach noch ein paar virtuelle, die der Minipanzer oder was auch immer, wechselt. Er hängt dabei also kurz in der Luft, weil er ja nicht wirklich abwärtsfährt, sondern nur auf bestimmt Positionsfelder, einer Treppe, gebeamt wird! Das kann man grafisch aber bestimmt kompensieren.

Deswegen muss man ja auch die Auflösung der Isoenginge massiv erweitern, er soll ja nicht stolpern! Ich kann mir gut vorstellen, das wenn man dieses Konzept weiterverfolgt, man irgendwann mal echte Kämpfe in X-Force simulieren kann, die eine Mondlandschaft hinterlassen, nach einem nervenaufreibenen Taktikgefecht, mit Deckungen die erst im Spiel entstehen oder unvorgesehen verschwinden, so das man eigentlich nie weiß was kommt! :)
verfasst am: 20.12.2003, 13:49
Registrierdatum: 05.11.2003, 15:19

 Beiträge: 131
Ich mag die Idee, solche Höhenunterschiede gleich variabel zu machen, das also Raketen einen Krater hinterlassen können. Ich glaube das gabs dann so noch nie, oder? Also nicht nur Berge abtragen, sondern gleich eine halbe Etage tiefer...
Bei dem Rest verstehe ich nur Bahnhof...
verfasst am: 20.12.2003, 17:03
Teammember

Registrierdatum: 06.09.2003, 11:47

 Beiträge: 107
Zitat: AshSerty
Wie ein grösserer SpielTile, diese Schrägen nun betreten kann um die Ebenen zu wechseln, scheint ein physikalischen Wunder zu sein ist es aber nicht. Dafür nimmt man einfach zwischen den 3 Hauptebenen, einfach noch ein paar virtuelle, die der Minipanzer oder was auch immer, wechselt. Er hängt dabei also kurz in der Luft, weil er ja nicht wirklich abwärtsfährt, sondern nur auf bestimmt Positionsfelder, einer Treppe, gebeamt wird! Das kann man grafisch aber bestimmt kompensieren.
Ich glaube, das Problem besteht vielmehr in der Neigung des Panzers, ohne welche das Ganze ziemlich billig aussieht. Und Neigung mit Sprites...naja, entweder das Sprite verzerrt darstellen, was übel aussieht, oder dann entsprechend geneigte Sprites erstellen, was ein ziemlicher Aufwand ist.
Zitat: Daniel
Ich mag die Idee, solche Höhenunterschiede gleich variabel zu machen, das also Raketen einen Krater hinterlassen können. Ich glaube das gabs dann so noch nie, oder? Also nicht nur Berge abtragen, sondern gleich eine halbe Etage tiefer...
Bei dem Rest verstehe ich nur Bahnhof...

Ich weiss ganz bestimmt, dass sowas schon in einigen Spielen vorgekommen ist, aber peinlicherweise ist mir nach 5 Minuten überlegen kein einziger Titel eingefallen...
verfasst am: 20.12.2003, 17:31 · Edited by: Pirate
Grafiker

Registrierdatum: 24.08.2003, 15:20

 Beiträge: 66
Sacht mal Jungs, was hat das alles mit Open Source zu tun ?
Das Thema "Höhenunterschiede" selbst verdient eigentlich 'nen eigenen Thread.

Soweit ich mich erinnere, hab' ich ganz zu Anfang als ich zum Projekt dazu gestoßen bin (das muss so vor 3 Jahren gewesen sein ;) ), beim Chef mal angefragt, wie es denn mit mehreren Ebenen im Bodenkampf aussieht. Als Antwort bekam ich sowas wie: Hmm, iss schwierig, gibs erstmal nicht. Punkt, aus. Ich weiß nicht, ob er mitlerweile Fortschritte erzielt hat, oder ob er überhaupt vorhat, sowas noch einzubauen. Sicher wäre es schöner, aber man sollte die Kirche auch mal im Dorf lassen. Erstens ist X-Force ein reines Hobby-Projekt, dass neben der Arbeit entwickelt wird und zweitens haben wir genau einen Coder, der so schon alle Hände voll zu tun hat und spielerisch würden die Höhenunterschiede auch nicht sooo viel bringen, dass das Fehlen ein K.O.-Kriterium wäre. Wir versuchen schließlich, mit den vorhandenen Mitteln, die Bodenkämpfe so gut wie möglich zu gestalten.
Wenn jetzt einer schreit, "na dann macht doch Open Source, dann könntet ihr mehr Programmierer haben, die sich auch um sowas kümmern", dem sag ich schon im Voraus nochmal, dass JEDER - auch ohne Open Source - die Möglichkeit hat, sich an der Entwicklung zu beteiligen. Und wenn einer meint, dass er einen tollen Mapeditor hat, mit dem man Karten bauen kann, die sich per Zufallsgenerator beliebig zusammensetzen lassen und auch Höhenunterschiede ermöglichen, dann "Herzlich willkommen im Team".

Vielleicht sollte Jim sich zum Thema Höhenunterschiede einfach mal zu Wort melden und sich zu seinen Plänen äußern.
verfasst am: 24.12.2003, 08:42 · Edited by: AshSerty
Registrierdatum: 10.12.2003, 06:45

 Beiträge: 36
Ich weiss ganz bestimmt, dass sowas schon in einigen Spielen vorgekommen ist, aber peinlicherweise ist mir nach 5 Minuten überlegen kein einziger Titel eingefallen...

Populous war doch früher, Anno 1989, schon so, kennt das keiner mehr?


Egal wie sich die Landschaft in den Höhen und Tiefen veränderte, die Einheiten passten sich immer an und liefen über die Berge und Täler, sogar flüssig animiert obwohl es ja garkeine echte 3D Engine war.

Man konnte das Land spalten, so das Abgründe zur Falle wurden, es mit einem blubbernden Sumpf überziehen oder es verbrennen wenn Bäume drauf standen. Es gab nichts was man nicht verändern konnte.

In Teil 3 ja dann noch schicker!
Gast
verfasst am: 10.01.2004, 19:13
Zitat: Jim_Raynor
Als nächstes kommt noch dazu, dass ich den ganzen Code alleine geschrieben habe. Das bedeutet, dass es so gut wie gar keine Dokumentation darüber gibt. Und leider muss ich mich immer wieder dabei erwischen, dass ich irgendwas nicht mehr ganz kapiere, wieso ich es vor 2 oder mehr Jahren so rum gecodet habe. *Schande über mich*


Das liegt warscheinlich daran das man je länger man mit einem Programm arbeitet immer besser wird und immer geschicktere Lösungen findet um ein Problem zu lösen.
So geht mir das jedenfalls auch meistens so wenn ich mir ein Programm anschaue ,was ich vor (sehr) langer Zeit geschrieben habe.
verfasst am: 14.01.2004, 15:31
Registrierdatum: 09.01.2004, 11:03

 Beiträge: 106
@Jim :ich vermute mal das du Kampffeld in der Bodenmission in einem 2Dimensionalem Array darstellst indem du dann die Bitmaps darauflegst um den Höhenunterschied darzustellen könntest du es doch einfach in ein 3Dimensionales erweitern und dann immer der Betreffenden Höhe entsprechend den Wert zuorden
z.B. in der Deklaration
var Feld : array[0..10,0..10,0..5] of Integer
Um dann die Höhe zu ändern könntest du sagen das die Bitmap immer auf den Arrays dargestellt werden soll und dann die Werte in der entsprechenden Situation ändern über die Trefferabfrage zum Beispiel.
Und dann müstest du nur noch das entsprechende Array ändern:
Feld [1,1,1] := 0;
Feld[1,1,0] := 1

Damit währe dann die Höhe an dieser Stelle gesenkt.(Obwohl du warscheinlich die Idee erstmal ehh nicht umsetzen wirst)
Hochachtungsvoll Firzen
verfasst am: 14.01.2004, 15:38
Registrierdatum: 05.01.2004, 21:22

 Beiträge: 23
Ich galube das das nur mehr fehler einbringen wird...

und das spiel eher zurück bringen wird nah ja wer es will...
Firezen
verfasst am: 14.01.2004, 19:53
Es dürfte eigentlich das Spiel nicht zurückwerfen.
Denn die eigentliche Basis des Bodeneinsatzes müsste eigentlich erhalten bleiben(es sei denn ich hätte im Tutorial aus dem ich Delphi gelernt habe jeden zweiten Satz nicht gelesen).
Es würde nur den ablauf einwenig mehr verlangsamen weil man immer überprüfen müsste welche Ebene wo denn genutzt wird das nimmt wahrscheinlich so 100khz in Anspruch.
Aber man könnte es ja ehh einfach ausschalten.
verfasst am: 14.01.2004, 22:25
Registrierdatum: 03.01.2004, 13:02

 Beiträge: 161
Ich glaub das problem der Höhe is weniger das Problem... Aber damit würde noch einiges einhergehen, z.B. müssteste für die Zuweisung des Bitmaps dann auch die 4 angrenzenden Felder anschaun, um zu wissen, obs da jetzt runter geht oder hoch. Desweiteren brauchste dann etwa 8-Mal mehr Bodentexturen, die dann die verschiedenen Neigungen (nach hinten, nach vorn, rechts, links, links hinten, rechts hinten etc) auch verdeutlichen.
Ok, diese Neigungs-bitmaps könnte man umgehn, indem man die normalen Bilder mit einer Matrix (ihr wisst schon, des fette Teil aus der Schule, mit dem man Vektoren drehen kann) verzerrt, aber zusammen mit der Berücksichtigung der umgebenden Felder hätten wir dann unter Umständen das problem der Rechenleistung... Hast vielleicht schonmal versucht, im Echtzeitmodus zu scrollen, wenn grad drei deiner Soldaten rumlaufen ;)
Rundenbasiert wär das wieder weniger das Problem, aber wenn man was umsetzt, muss mans schon in beiden Modi tun...
Firezen
verfasst am: 15.01.2004, 13:21
Ohh ich dachte das im Echzeitmodus läge an meinem Rechner
ich hab nur den standart Pentium 3.
Aber das Problem mit dem überprüfen dürfte nicht so schwer zu lösen sein.
Ich lass mir da noch ne nette Lösung einfallen (schaff ich auch manchmal).
Gruß Firzen
Firezen
verfasst am: 15.01.2004, 13:42
So mir ist was eingefallen (schnell nicht):
Man muss nur die Senkungsprozedur ändern:
var

var Feld : array[0..10,0..10,0..5] of Integer

//das ist da um zu bestimmen wo nun wie gesenkt wird
//man muss vorher aber für die schrägen noch weitere
//Werte einsetzen z.B. 2 für rechts oder so

Feld [x,y,1] := 0;
Feld[x,y,0] := 1
Feld(x+1,y,0) := 2 //rechts
Feld(x+1,y+1,0) := 3 //rechtoben
Feld(x,y+1,0) := 4 //oben
Feld(x-1,y+1,0) := 5 //obenlinks
Feld(x-1,y,0) := 6 //links
Feld(x-1,y-1,0) := 7 //linksunten
Feld(x,y-1,0) := 8 //unten
Feld(x+1,y-1,0) := 9 //untenrechtsFeld [x,y,1] := 0;
Feld[x,y,0] := 1
Feld(x+1,y,0) := 2 //rechts
Feld(x+1,y+1,0) := 3 //rechtoben
Feld(x,y+1,0) := 4 //oben
Feld(x-1,y+1,0) := 5 //obenlinks
Feld(x-1,y,0) := 6 //links
Feld(x-1,y-1,0) := 7 //linksunten
Feld(x,y-1,0) := 8 //unten
Feld(x+1,y-1,0) := 9 //untenrechts


So das wars ich hoffe mein Vorschlag wird irgendwann mal umgesetzt damit die ganze Tipp und Denkarbeit nicht umsonst war.
verfasst am: 15.01.2004, 14:38
Programmierer

Registrierdatum: 23.08.2003, 19:16

 Beiträge: 2261
Zitat: SoongJr
Hast vielleicht schonmal versucht, im Echtzeitmodus zu scrollen, wenn grad drei deiner Soldaten rumlaufen ;)
Rundenbasiert wär das wieder weniger das Problem, aber wenn man was umsetzt, muss mans schon in beiden Modi tun...

Da gab es ein Problem mit meiner Timer Funktion. Siehe ein Tagebuch Eintrag. Mittlerweile müsste es ziemlich flüssig laufen. Lasst euch einfach mal von der nächsten Version überraschen.

Zitat: SoongJr
Ok, diese Neigungs-bitmaps könnte man umgehn, indem man die normalen Bilder mit einer Matrix (ihr wisst schon, des fette Teil aus der Schule, mit dem man Vektoren drehen kann) verzerrt


Beim Verzerren sollten man aber beachten, dass die Beleuchtung an den geneigten Kanten geändert werden muss, damit es halbwegs realistisch aussieht. Also würde das verzerren entfallen, und es müssten alle Grafiken erstellt werden.

Desweiteren müssen die Soldaten und Aliens dann auch entsprechend der Neigung hoch und runterlaufen. Weiter kommt dazu, dass sich der Pfadfindings-Algorhytmus auf die dritte Dimension ausbaut. Und der ist bisher das Rechenintensivste. (Schicke mal einen Soldaten von einem Ende zum anderen Ende der Karte, wenn es eine große Karte mit 15 Aliens ist)

Allem in allem ist die Idee gut und ich denke auch öfter über Lösungsmöglichkeiten nach. Nur bisher ist mir noch nicht der Durchbruch gekommen, dass ich sagen könnte, so mache ich es jetzt und so wird es auch funktionieren. Dafür ist die ganze Sache zu Komplex.
verfasst am: 15.01.2004, 15:20 · Edited by: Firzen
Registrierdatum: 09.01.2004, 11:03

 Beiträge: 106
Kannst du mir dann vielleicht die unit/procedure dazu schicken.
Damit ich auch selbst über passensere Lösungsmöglichkeiten nachdenken kann.
Das lesen sollte kein Problem darstellen
(hab 3 Jahre Turbo Pascal geschrieben da macht Delphi keine Schwierigkeiten.)
Das hoch und runterlaufen könnte man aber über das erhöhen und senken von Bitmaps machen (jedenfalls grundsätzlich)
Allerdings müsste man dann noch eine Überprüfung des passenden Feldes einbauen,was aber kein Problem darstellen.
Das pathfinding dürfte ja nicht mehr Probleme machen ,da
die xyKoordinaten ja gleich bleiben.Man würde ja nur die Angezeigte Höhe ändern.
Nebenbei an die Leute die die Sounds machen (bitte nicht als Kritik auffassen) eine Titelmusik wäre schön.
verfasst am: 15.01.2004, 15:37
Registrierdatum: 03.01.2004, 13:02

 Beiträge: 161
Pathfinding wär nurn Problem, wennde einbeziehen willst, dass der Soldat für Steigungen mehr ZE braucht... Dann müsste der Pathfinder ZE-optimiert werden und des wär sicher sehr schwer (bzw rechenlastig)
Ich glaub auch nicht, dass es da ein problem mit der Höhe geben würde, bzw dass sich ein solches lösen lassen würde...

Ein anderer Aspekt is sicherlich, dass du noch so einige Vorschläge zu verarbeiten hast denk ich mal ;)
verfasst am: 15.01.2004, 20:26
Registrierdatum: 05.11.2003, 15:19

 Beiträge: 131
@Firzen
Ich verstehe nicht ganz wieso du einen dreidimensionalen Array brauchst, nur für die Höhe, um den dan Int zu machen, und die meißten werte auf null zu setzen.
Wäre nicht besser (Feld x,y,a), wobei x,y die Koordinaten des Feldes sind, in a=0 zum Beispiel wird die mittlere Höhe gespeichert, in a=1 die Neigung, in a=2 welcher art von Untergrund (Asphalt, wiese, usw), in a=3 welches Schrittgeräusch dazu gehört, usw. Dann hast du nur soviele Variablen im Array, wei du auch wirklich brauchst....
verfasst am: 15.01.2004, 20:28
Registrierdatum: 05.11.2003, 15:19

 Beiträge: 131
Wobei ich gerade noch merke das selbst a=3 aus diesem Beispiel überflüssig ist, weil es sich aus a=2 mit ergibt....

Seite: << [1] 2 [3] >>




Du musst dich registrieren um auf dieses Thema zu antworten.
Login :: » Name » Passwort

Ladezeit (sec.): 0.013 · Powered by miniBB 1.6 with parts of 1.7 © 2001-2003