Das inset sieht schon sehr nach senkrecht aus 
Aber wieso? Horizontal gab es doch auch schon erfolgreich?
Hallo Besucher, der Thread wurde 29k mal aufgerufen und enthält 155 Antworten
letzter Beitrag von TheRealWanderer am
F64PGC2017: Fußball (Coder gesucht)
-
-
Hmm, dann wird das Bild bei mir gedreht angezeigt
EDIT: Es wird tatsächlich gedreht angezeigt
Also alles gut
-
Also ich wäre eher dafür, dass (wenn es tatsächlich zustandekommt) das Fußballspiel senkrecht gespielt wird.
Der letzte Screen ist nur dafür gemacht, dass man das komplette Feld als Chars auf dem C64 sehen kann, um die KI zu testen. Das hat mit der endgültigen Spiel-Optik noch nichts zu tun. Der eingeblendete (Hochkant-stehende) helle Bereich könnte (natürlich gedreht) der sichtbare Screen des Spielfeldes sein. Damit kann man testen, wie viele Spieler (je nach Ausschnitt) gleichzeitig sichtbar sein könnten.
Das eigentliche Spiel soll immer noch so dargestellt werden, wie in meinem ersten Mockup oder meinetwegen auch Sensible Soccer – wenn es denn überhaupt zu einer Realisierung kommt.
Hier nochmal zum einfacheren Weiterverarbeiten:
-
Ich würde dem Spieler und der KI verschiedene Standard Spieleraufstellungen die es im Fussball so gibt zur Auswahl geben (4-4-2, 5-4-1, 4-3-3...). So verteilen sich dann die Spieler schon mal relativ vernünftig (und realistisch) auf dem Feld. Die KI kann einen gewissen Radius (oder leichter Quadrat) um den Spieler berücksichtigen ab wann der Spieler auf einen ankommenden Ball reagiert, oder einem Ball führenden Mitspieler folgt etc. Die Spieler als Chars darzustellen ist meiner Meinung nach aufwendiger wie ein Sprite Multiplexer.
-
Ich denke die 2 wichtigsten Faktoren sind:
1. Ballbesitz. Bei eigenem Ballbesitz auf Angriffsmodus schalten. Die Spieler bewegen sich generell zum gegnerischen Tor hin. Spieler ohne Ball entfernen sich vom Gegner, um anspielbar zu sein.
2. Ballposition. Ist die Mannschaft nicht im Ballbesitz und der Ball in der gegnerischen Hälfte, versuchen einzelne Spieler den gegnerischen Spieler, der den Ball hat, unter Druck zu setzen. Ist der Ball in der eigenen Hälfte, versucht man den eigenen Strafraum abzusichern.
So ungefähr denk ich mir das (als ungeübter Couchfussballer).
-
Was die KI angeht, würde ich den Ansatz von Sensible Soccer als Basis nehmen: Das Spielfeld wird in viele kleine Rechtecke aufgeteilt (bei SS sind es glaube ich 35) und für jeden Feldspieler sind 35 Positionen vordefiniert - je nachdem, wo sich der Ball gerade befindet, weiß die KI so immer, wo sich ein bestimmter Spieler aufhalten soll bzw. wo er sich hinbewegen muss. Auf diese Weise entsteht bei vergleichsweise wenig CPU-Aufwand eine relativ natürliche Verteilung der Mannschaft auf dem Feld - die beispielsweise schnelle Konter ermöglicht, bei denen man auf eine lückenhafte Abwehr trifft. Man könnte das noch verfeinern, in dem zwischen "Ballbesitz" und "kein Ballbesitz" unterscheidet, was SS nicht macht - das wären dann 70 vordefinierte Positionen, bei praktisch gleich CPU-Aufwand.
Die Spieler in Ballnähe würden dann von "aktiver" KI übernommen, sich also an deutlich komplexeren Regeln orientieren.
Die Spieler als Chars darzustellen ist meiner Meinung nach aufwendiger wie ein Sprite Multiplexer.
In dem von Retrofan und mir angeführten Beispiel fällt das Scrolling und der Sprite-Multiplexer weg, der komplette CPU-Verbrauch der Grafik-Engine reduziert sich auf das Schreiben von 40 Bytes um die 20 Feldspieler zu positionieren, sowie zwei oder drei Bytes für den (Sprite-)Ball. Das ist natürlich deutlich weniger Aufwand als ein scrollendes Spielfeld mit Sprite-Multiplexer.
Der Gedanke war, so etwas als Gerüst zu benutzen um den Verbrauch von KI-Routinen testen zu können. Ich persönlich habe nämlich den Verdacht, dass man bei den KI-Berechnungen vergleichsweise schnell an die Grenzen des machbaren kommt.
-
Was die KI angeht, würde ich den Ansatz von Sensible Soccer als Basis nehmen: Das Spielfeld wird in viele kleine Rechtecke aufgeteilt (bei SS sind es glaube ich 35) und für jeden Feldspieler sind 35 Positionen vordefiniert - je nachdem, wo sich der Ball gerade befindet, weiß die KI so immer, wo sich ein bestimmter Spieler aufhalten soll bzw. wo er sich hinbewegen muss.
Interessant, woher hast du diese Infos? -
Ich persönlich habe nämlich den Verdacht, dass man bei den KI-Berechnungen vergleichsweise schnell an die Grenzen des machbaren kommt.
Ich kann das auch ganz schlecht abschätzen. Man kann aber wahrscheinlich nach und nach den Aufwand verringern, weil der Spieler ja in seinem Bildausschnitt im Schnitt nur ca. 1/3 der Spielfiguren sieht. Wie intelligent der Rest ist, bekommt er nur mit, wenn sie ins Bild kommen. Es kann also sein, dass man nach 1.000 KI-gegen-KI Testspielen mit ein paar Positions-Tabellen hinkommt (quasi eingefrorene KI). Oder man reduziert den Takt der Berechnungen. Für rund 15 der 22 Spieler ist es vollkommen egal, ob ihre Position 1 mal pro Frame oder 1 mal pro Sekunde (Faktor 1:60) berechnet wird. Und es gibt noch haufenweise weitere Stellschrauben. Man kann also nach und nach den Aufwand verringern (nachdem es erstmal läuft), bis man genügend Performance hat, Scrolling, Animationen und Sprite-Multiplexer zu integrieren.
Denn, die KI ist sehr wichtig – aber sie nützt natürlich nichts, wenn wir nachher ein Fußball-Text-Adventure bekommen. Ich bin auf jeden Fall gespannt, ob und was bei den KI-Tests herauskommt. Man wird bei einer 1-Mhz-Kiste sicherlich Kompromisse eingehen müssen – der C64 ist halt kein Amiga.
-
Ich würde dem Spieler und der KI verschiedene Standard Spieleraufstellungen die es im Fussball so gibt zur Auswahl geben (4-4-2, 5-4-1, 4-3-3...). So verteilen sich dann die Spieler schon mal relativ vernünftig (und realistisch) auf dem Feld.
Was die KI angeht, würde ich den Ansatz von Sensible Soccer als Basis nehmen: Das Spielfeld wird in viele kleine Rechtecke aufgeteilt (bei SS sind es glaube ich 35) und für jeden Feldspieler sind 35 Positionen vordefiniert - je nachdem, wo sich der Ball gerade befindet, weiß die KI so immer, wo sich ein bestimmter Spieler aufhalten soll bzw. wo er sich hinbewegen muss.
Kombiniert wäre das folgendes:
35 Rechtecke entsprechen einem 5 x 7 Raster und eine mögliche Standard-Aufstellung habe ich hier mal in die Felder hineingesetzt. Die Spieler laufen (in meiner Vorstellung) immer in definiertem Abstand zum Ball (2. Bild: Position zum Ball gehalten, bis auf die Spieler, die an Feld-Ränder stoßen). Man könnte evtl. überlegen, ob sie das im Angriffsfall nur in Tor-Richtung tun und ihre Positionen zur Seitenlinie halten (und sich im Verteidigungsfall etwas stärker in Ball-Richtung orientieren.
Die Sensible-Soccer-Idee, einfach für jede der 35 möglichen Ballpositionen die groben Positionen der 11 oder 22 Spieler (damit wäre Angriff und Verteidigung ja inbegriffen) in einer Tabelle abzulegen, wäre vielleicht sogar noch einfacher, weil man nur in der Tabelle nachschauen müsste statt irgendwas zu berechnen. Und für unterschiedliche Mannschaften könnte man die Tabellen etwas modifizieren.
Das wäre auf jeden Fall mit recht wenigen Berechnungen verbunden. Es geht hierbei ja auch erstmal nur darum, dass wirklich 11 Spieler je Mannschaft verwaltet werden (und zu jeder Zeit irgendwo definiert laufen) und nicht einfach bei Bedarf stumpf ein neuer Spieler erzeugt wird, wie andere C64-Soccer-Games das tun. Richtig spannend wird die Gegner-KI, sobald die Spieler im Bild sind – wobei, das dürfte auch kein Hexenwerk sein. Der dem Ball nächste Gegner wird den ballführenden Spieler angreifen, die anderen decken ihre Gegenspieler (wie gut sie das tun, wird über den Schwierigkeitsgrad entschieden).
Aber das ganze bleibt natürlich reine Theorie – wenn sich nicht bald (mehr oder weniger) verbindlich ein Programmierer (oder ein Team) meldet, der (bzw. das) Spaß daran hat, die Sache mit Leben zu füllen. @Korodny, @daybyter, Interesse? Oder sonst wer, der noch eine Herausforderung für die kommende Winterzeit sucht?
-
Interesse schon...die Zeit fehlt halt...
Müsste mal schauen, ob ich meinen Shooter Code in ein 8-Wege Scrolling umbauen könnte. Dann müsste man das Spielfeld in Tiles aufteilen, die man schnell einfügen kann, wenn es scrollt.
Ist echt nicht so ohne...
Als Amiga Code könnte man das evtl einfach als riesen Bitmap machen, die vielleicht sogar einfach in C gescrollt werden kann? (hab ich noch wenig Erfahrung mit). Das wär vermutlich viel einfacher.
<EDIT Syshack>Leeren Spoiler entfernt
-
Hast Du mal versucht einen Teil Deines 1. Mockups in Chars zu wandeln, damit man daraus Tiles basteln könnte?
-
JTR/Protovision hat mich kürzlich auf diesen thread aufmerksam gemacht.
Wie hier bereits erwähnt wurde, dürfte die KI das Entscheidende sein. Ebenso die Darstellung + handling der Tiefrnfimension. Für scrolling+multiplexer sollte sich eine Lösung finden die genug Zeit fürs Wesentliche lässt.
Auf jeden Fall ist es eine echte Kampfansage, ein besseres Fußballspiel als Micropose Soccer zu entwickeln -
Mein Vorschlag an der Stelle wäre, dass man eine KI erstmal in C schreibt, damit sie verständlicher ist und auch leichter zu ändern.
-
Schreib doch eine KI in C, die die KI in Assembler selbstänig programmierren kann, so dass am Ende ein Soccer Spiel rauskommt. Du spielst dann und wenn es nicht gefällt muss die KI es besser machen.
-
Na wenn Du den Assembler-Teil mal weglässt, dann sind heute Neuronale Netze ja gar nicht mal sooo weit von dem selbst lernen weg (Stichwort Deep-Learning). Es gibt ja so eine Roboter-Fussball WM- Würde mich nicht wundern, wenn die schon so etwas einsetzen. Für den cevi ist das aber vielleicht eher weniger gemacht (Speicher und CPU-Leistung halt).
Ich sag ja nicht, dass es am Ende nicht Assembler werden soll. Aber zum Experimentieren find ich ne Hochsprache halt angenehmer (bin alt und bequem).
-
Hast Du mal versucht einen Teil Deines 1. Mockups in Chars zu wandeln, damit man daraus Tiles basteln könnte?
Noch nicht. Es fehlen ja auch noch Sachen, wie z.B. die Tore. Ich mache das sonst aber auch so, dass ich ganze Screens liefere und der Programmierer dann mit einem Konverter die ganzen doppelten Blöcke rauswirft und aus dem Rest in einen Zeichensatz generiert. Bekäme er nur den Zeichensatz, müsste der Programmierer daraus ja erst ein Spielfeld bauen und die korrekten Farben setzen, daher ist erstere Lösung für beide Parteien einfacher. Aber einen Mini-Zeichensatz für Testzwecke kann ich mal bauen.
JTR/Protovision hat mich kürzlich auf diesen thread aufmerksam gemacht.
Das ist ja cool.
Wie hier bereits erwähnt wurde, dürfte die KI das Entscheidende sein.
Wobei wir ja schon festgestellt haben, dass sich die globale KI, die auch die nicht sichtbaren Figuren steuert, notfalls auf ein paar Tabellen (à la Sensible Soccer) zusammenkürzen lässt. Konzentrieren sollte man sich daher auf die KI, die bei Angriff und Verteidigung nah am Ball (und damit im Bild) ist.
Auf jeden Fall ist es eine echte Kampfansage, ein besseres Fußballspiel als Micropose Soccer zu entwickeln
Ein Kinderspiel wird es auf jeden Fall nicht, ein gutes Fußballspiel zu entwickeln. Aber wie sagte schon Kennedy: Wir machen es nicht, weil es leicht ist, sondern weil es schwer ist!
Es kommen halt viele Sachen zusammen: Multiwege-Scrolling, Sprite-Multiplexer, Border-Nutzung (Scores), Verwaltung von 22 Spielern, KI zumindest für die sichtbaren Spieler, Steuerung/Ballhandling der Nicht-KI-Figur, Ball-Physik, Torwart-KI/Steuerung .... Der Programmierer benötigt meines Erachtens eine Menge Skills.Ich finde aber, Microprose Soccer ließe sich schlagen. Der Screen wird dank Score-Anzeige künstlich verkleinert, der sichtbare Feld-Ausschnitt ist recht eng gewählt. Die Spieler bewegen sich ruckelig, das Ballhandling sieht auch eher grob aus. Die Möglichkeiten des Sprite-Multiplexers werden durch Verwendung von 2 Sprites je Spieler (und 3 für den Ball) verschenkt. Kombinationsfußball kann man damit weitgehend vergessen.
Mein Vorschlag an der Stelle wäre, dass man eine KI erstmal in C schreibt, damit sie verständlicher ist und auch leichter zu ändern.
ALeX hat viele Routinen unserer gemeinsamen Entwicklungen auch erstmal in PHP geschrieben, um zu gucken, wie man das am Besten macht. Und zum Schluss wurde es dann in Assembler implementiert. Ich glaube, bei komplexen Sachen macht es wirklich Sinn, eine (beliebige) Hochsprache zu benutzen.
-
Bei so etwas stelle ich mir immer als haarigstes Problem vor, dass die KI ja auf den Multiplexer Rücksicht nehmen muss. Ist ja schön, wenn die KI meint, alle Spieler in einer Reihe aufzustellen, aber der Multiplexer dann zusammenklappt
Da scheint mir das Einteilen in Sektoren und dann eher "einfach" die Spieler den Sektoren zuzuordnen, als am ehesten machbar. Könnte auf jeden Fall ein Vorzeigeprojekt werden!
-
Da scheint mir das Einteilen in Sektoren und dann eher "einfach" die Spieler den Sektoren zuzuordnen, als am ehesten machbar. Könnte auf jeden Fall ein Vorzeigeprojekt werden!
Das entspricht ja durchaus dem üblichen Spielfluss. Es laufen bei einem professionellen Fußballspiel (im Gegensatz zum Bolzen auf dem Schulhof) ja nicht alle Spieler ohne Sinn und Verstand auf den Ball zu. Jeder Spieler hat eine Aufgabe, muss seine Position verteidigen, sich (bei Ballbesitz seiner Mannschaft) freilaufen oder (bei Ballbesitz des Gegners) einen Gegenspieler decken. Das kommt uns beim Multiplexer zugute. Je nach gewähltem Bildausschnitt muss man nur 1/3 (6 bis 7) bis max. die Hälfte der Spieler (beim großen Ausschnitt von Sensible Soccer) darstellen.
Bei den nicht sichtbaren Spielern gleichen sich die Kräfte der Gegenspieler aus, d.h. das Freilaufen der einen wird durch das Manndecken der anderen ausgeglichen – man kann also mehr oder weniger feste Positionen (innerhalb der groben Sektoren) annehmen. Spieler besserer Mannschaften stehen, sobald sie in Kamera-Nähe kommen in Ballführungs-Situation freier und in Verteidingungs-Situation enger am Gegner.
Kommt es zu der Situation, dass das virtuelle Kamera-Bild (also der gezeigte Bildausschnitt) Gefahr läuft, zu viele Spieler pro Scanzeile darstellen zu müssen, muss halt ein Spieler entgegen sinnvoller Taktiken in eine Richtung (notfalls aus dem Bild heraus) laufen, die das Problem verhindert. Am Besten, man behält immer einen Puffer, sodass es zu der Situation gar nicht erst kommen kann.
Ich glaube, ich habe bei meinem Ausschnitt durchaus darauf geachtet, dass nicht zu viele Spieler im Bild sein können, trotzdem aber genügend Anspiel-Positionen sichtbar sind. Der Ausschnitt liegt zwischen Microprose-Soccer (zu eng für gezielte Pässe) und Sensible Soccer (evtl. zu viele und zu kleine Sprites für den C64).
-
Der Ausschnitt liegt zwischen Microprose-Soccer (zu eng für gezielte Pässe)
Einwurf, euer Ehren.
Das braucht man nicht unbedingt gezielt sehen. Bei einer Mannschaftssportart weiss man eigentlich quasi-blind, wo die eigenen Mitspieler der anderen Abteilung sich in einer gegebenen Spielsituation etwa aufhalten sollten. Das gehört im Grunde zum unterhaltenden Spielwitz dazu. Das hat bei Microprose Soccer lediglich die Einschränkung, dass man das Spielsystem vorher nicht wählen kann (anders als z.B. beim Nachfolger Sensible Soccer, oder bei Kick Off).(Leider hat Microprose Soccer natürlich auch die dumme Eigenart, das Aufnehmen blinder Pässe und Flanken durch Grätschen zu erleichtern, weswegen die Spiele häufig zu exzessiven Grätschorgien degenerieren.)
-
Einwurf
Wortwitz.
Das braucht man nicht unbedingt gezielt sehen. Bei einer Mannschaftssportart weiss man eigentlich quasi-blind, wo die eigenen Mitspieler der anderen Abteilung sich in einer gegebenen Spielsituation etwa aufhalten sollten.
Schon – aber man weiß natürlich nicht, ob der Spieler auch freisteht. Deswegen ist es nicht so verkehrt, etwas mehr vom Spielfeld zu sehen – oder aber man hat (zusätzlich) so einen "Radar", wie ich ihn angedacht habe, also Marker am Bildrand, die anzeigen, wo sich nähere Spieler außerhalb des Ausschnitts aufhalten.
weswegen die Spiele häufig zu exzessiven Grätschorgien degenerieren.
Es bleibt natürlich nicht aus, dass man erst nach Probespielen sehen wird, ob sich spielfremde Taktiken durchsetzen, um zum Ziel zu gelangen. Da muss man dann notfalls gegensteuern.
