Spiele und Spieleentwicklung - ein Kindheitstraum

Interessante Beiträge lieber Sethanas !

Ich freue mich sehr, dass du den rank gefunden hast und wieder mehr in dir ruhst. Ich erinnere mich noch an deine Beiträge vor Jahren in diesem forum und wie ich Mühe hatte dass es hier im forum nicht zu sehr ausgeartet ist. Umso mehr freue ich mich denn neuen "alten" Sethanas hier wieder im Forum begrüssen zu dürfen!

Sehr schön, dass du mir programmieren anfangen hast. Dass mache ich im Moment leider nicht mehr so. Habe ich aber etwas früher. Dies, da ich mit Computern aufgewachsen bin und mit Programmieren. Da mein Vater, als Teilchenphysiker, schon seit dem frühen 60er Jahren erst in der Physik dann bei Banken mit grossen mainframe computern gearbeitet hat und später im Management von Software Entwicklung gearbeitet hat...

Ich selber bin aber kein guter Programmierer sondern eher mal etwas aus Neugier. Ich bin besser in der physischen Welt unterwegs und bin deshalb auch Produktentwickler geworden (mit CAD etc)...

Gruss und viel Spass hier!

Hallo Sethanas. Ich bin gerade neu hier, und finde deinen Beitrag, und muss denken - da hat jemand teilweise eine ganz ähnliche Geschichte erlebt wie ich. Ich bin auch in den 80ern und 90ern grossgeworden, und habe schon als Kind auf dem Computer (8088er Schneider Euro PC) mit Basic angefangen zu programmieren. Ich hab's mir einfach selbst beigebracht, mit den Beispielprogrammen, dem fetten MS-DOS Handbuch für GW-BASIC (ja, das muss in Grossbuchstaben... ), und auch so Zeitschriften-Programmen, auch für C64. Ich habe einfach immer weiter experimentiert, und habe zum Glück ein paar Programme von damals sogar noch gerettet, aber es waren echt nur Experimente und merkwürdiger Crap. Später wurde ich besser, und wollte es richtig lernen, wurde aber nicht richtig gefördert und hatte keinen Plan, nicht die richtigen Materialien und keinen eigenen PC, und musste erstmal Jahre mit der Schule und dann Erkrankung kämpfen.

Dann habe ich nach der Schule auch ernsthaft angefangen, C/C++ und Assembler zu lernen, als ich an alles dafür aus dem Netz gekommen bin, bin dann aber leider erkrankt. Damals wie heute habe ich die Vision, mit der Fähigkeit noch mal durchzustarten...wenn man das als Kind gelernt hat, dann bleibt der Skill ein Leben lang, und mir macht eigentlich kaum etwas mehr Freude, als das Programmieren.

Die Krankheit hatte mich dann voll rausgeballert, aber über die Jahre bin ich immer wieder dahin zurück und habe mir das erhalten und immer weiter trainiert. Ich plane auch definitiv noch, und arbeite auch oft dafür, zu programmieren und mit den Produkten Geld zu verdienen, aber dafür muss ich erst richtig ranklotzen. Ich habe eigentlich noch nie etwas ganz durchgezogen, sondern immer nur privat Plugins und kleine Tools gemacht und experimentiert und die Software anderer studiert...mein Zustand hat mich all die Jahrzehnte halt immer wieder daran gehindert, so dass ich eigentlich alles was ich angefangen hatte abgebrochen habe, konnte nicht weiter dran arbeiten, oder wurde vom Leben abgelenkt. Nach langer Pause, sieht dann immer alles anders aus, hat man dazugelernt, würde man es anders machen. Dafür bin ich glaube ich wirklich ziemlich gut geworden, und bin auch immer noch an den alten Träumen dran. Will Audio Software, Spiele und auch Computerkunst machen, habe auch alle nötigen Skills und das Wissen dazu. Ich bin halt so, ich lerne immer erst wie man es richtig macht, sonst glaube ich nicht an das Ergebnis. Wenn ich es komplett verstehen kann, kann ich es auch machen. Jedes Projekt beginnt bei mir mit Bleistift und Papier, wird geplant und definiert. Auch das ist etwas, was man lernen muss, worin ich immer besser werde.

Ich glaube du machst das richtig mit C und C++, und sammelst erstmal viel Erfahrung. Tetris ist ein Klassiker, leicht programmiert, eine schöne Übung, ich glaube ich habe auch mal eins gemacht, fand's aber immer langweilig, Dinge zu machen, die's schon gibt... Also C++ ist eigentlich vom Stil nicht so verschieden von C, wenn man es ähnlich benutzt...aber wenn du einmal die Denkart "OOP" also Objektorientiertes Coden gelernt hast, dann willst du nicht mehr zurück. Auch moderne (Skript)Sprachen wie Python, Lua, Javascript etc. ermöglichen OOP, C selbst ist nicht so stark darin und wird deswegen auch immer seltener eingesetzt, ausser im lowlevel Bereich. Du kannst ja auch C++ einfach wie C programmieren, so habe ich es auch gemacht - die Objekte erlauben wirklich einen extrem viel strukturierteren Aufbau der Programme und auch einen schlüssigeren Codestil und Umgang mit Daten und Schnittstellen. Wenn ich C++ nutze, baller ich auch nicht alles voll mit Templates oder Objektvererbungen, sondern nutze nur so viel wie gerade nötig um das Program schlank und effizient aufzubauen.

Was für Frameworks benutzt du denn? Für die Spieleentwicklung tendiere ich wirklich (auch der Natur der Spiele, die ich im Sinn habe entsprechend) zu der Godot Engine, falls dir das was sagt... Ist kein "gamemaker", sondern ein ernstes Tool, nur falls du es nicht kennst und die screeshots siehst. Man coded quasi in einer GUI mit Python in einer graphischen Oberfläche, kann aber auch extern bearbeiten, C module nutzen, auch wenn man will ein C modul nutzen was das ganze Spiel umsetzt mit den Methoden der Engine... Ein ziemlich cooles Projekt, Opensource MIT. Ich denke auch mittlerweile so, effizienz ala ASM und C(++) ist cool, aber bullshit wo's nicht nötig ist...und abseits des Lernprozesses, ist es immer besser mit der fundierten Arbeit anderer weiterzuarbeiten, wenn sie stabil ist, als alles selbst machen zu müssen. Früher dachte ich da ganz anders.

Also das lernen an sich, habe ich jetzt ohne diese tollen Bücher und so gemacht. Teils hatte ich anfang der 2000er welche aus dem Netz, aber danach wusste ich die Basics, und bin immer nur noch nach einfachen Tutorials/Referenzen zu den Sprachen gegangen bzw. habe mir mit Suchmaschinen meinen Weg durchgehangelt. Ich glaube derzeit sind Bots wie ChatGPT auch eine coole Sache, aber nicht zum Coden (lern lieber selbst, die Dinger machen nur Murks), sondern zum Lernen. Aber was mir am meisten noch geholfen hat, ist einmal die Open Source Szene, also aktiv Code lesen, versuchen Bugs zu fixen oder sonstwie mitzuarbeiten an Code von anderen, und ausserdem der aktive Austausch im Netz und das Beschäftigen auch mit den Problemen anderer - das ist absolut win-win wenn du jemandem bei etwas helfen kannst, und zum Dank dafür endlich wieder etwas neues richtig verstehen gelernt hast, oder durch die Inspiration eine gute Lösung für eine eigenes Problem endlich richtig verstanden hast. So habe ich glaube ich am meisten gelernt, auch schon ganz früher als ich nach der Schule angefangen habe, ernsthaft lernen zu wollen.

Hey soviel dazu, wir können uns gerne ein bisschen austauschen, vielleicht kann ich dir auch mit manchen Sachen ein bisschen helfen. Ich selbst bin im Moment aber echt noch im Stressmodus und warte auf ruhigere Zeiten, damit ich mich auf meine aktuellen ernst gemeinten Projekte endlich richtig vertiefen kann, oder auch mal was mit anderen arbeiten kann. Das ist auch inspirierend, mit anderen arbeiten, aber ich hatte noch nicht das Glück jemanden zu haben, der mir genug eigene Planung zugetraut hatte, dass das funktioniert hat, und mit Diagnose und ohne Portfolio kriegt man nur Möglichkeiten, wo die Diagnose nicht stört oder irgendwie dazugehört.

Also ich finde, diese mächtigen Sprachen wie C++, mit den krassen Abstraktionsmöglichkeiten...muss man eben genauso verwenden, wie die Struktur logisch hergibt. Ich sehe viel Code, gerade auch in Open Source Projekten, da denke ich nur, nä das machen die sich aber künstlich kompliziert, da steigen die selbst nach ner Pause so schnell nicht mehr durch. Das ist dann Code, kryptischer Code, der ist halt zu abstrakt und dadurch zu kompliziert.

C selbst, wird denke ich fast nur noch systemnah genutzt, oder da wo extrem auf Sicherheit, Stabilität, Langzeitkompatibilität, Hardwarenähe usw. geachtet wird (Treiber, Industrie, Science, Banken, Militär). Spiele, ja gut, wenn das halt extrem kompakt und schnell sein soll.

Ich selbst nutze auch moderne c++ features eher nicht und bleibe bei'm Grundgerüst... Aber reines C wäre mir zu umständlich, weil manchmal - machen die features eben Sinn um etwas zu ermöglichen. Ich denke, der beste Code ist der, der so effiezient und einfach ist wie möglich. Eben auch in der Art wie er formuliert ist. STL zum Beispiel turned mich ab. Vieles verwende ich auch wie man es in C verwenden würde. Aber eben die OOP Features bringen's in manchen Belangen, und darauf würde ich nicht verzichten.

C ist halt eine extreme Einschränkung, also ich finde, das macht vieles sehr umständlich. Das kommt sicher auch auf den Bereich an, wo man das nutzt. Was ich programmiere, sind extrem modulare und dynamische Systeme, da brauche ich einfache OOP Verkapselungen um allein den Überblick zu behalten. Das schöne an C++ ist ja auch, dass man nicht alles mitmachen muss, sondern auch an der Basis bleiben kann. C++ ist durchaus auch C kompatibel, denselben Stil kann man da also auch fahren...aber ich nutze trotzdem lieber C++ methoden, um komplexere Sachen auszudrücken. Man muss nicht alles verkapseln, das schöne an C++ ist man kann trotzdem einfach in den Speicher schreiben und lesen. Ich programmiere aber auch in Python, Javascript und Lua, und dann ziemlich ähnlich - mir ist das auch eher einerlei alles, ich nutze in allem denselben Stil für dieselben Aufgaben. Der kommt ja auch vom Durchdenken der Probleme, und nicht durch die Sprachen. Dann ist da nichts bloated, das kommt alles vom Design, nicht von der Sprache. Ich geben aber echt zu, die Limits muss man sich setzen, sonst dreht man durch nach dem 10. Template in der Polymorphie zwischen Zeigerunterscheidungen, so löst man das manchmal besser nicht sondern einfach mit einem "int ID" im agnostischen Datencontainer.

Okay, und dann hast du auch schon Erfahrung mit Arbeit in der Java Industrie? Also Java hatte ich nicht richtig bei'm Wickel, habe aber Programme gesehen... Ich verstehe die Sprache und das geläufige Model in der Arbeit auch nicht, diese ganzen Unternehmen stellen sich auch echt alle ein Bein damit, glaube ich. Und dann sind die Programme meist auch noch ätzend langsam... So geht dann halt OOP ohne strikt genug kontrollierte Schnittstellen ab, und wenn dann mehrere Köche an einem Brei rühren kommt da alles nur noch durcheinander. Wie kommts, dass solche Anwendungen so riesig aufgeblasen sind? Hat mich immer gewundert.

Dein Projekt klingt cool. Ich mag das auch, Programme hardwarenah zu coden, und dann laufen die erstaunlichsten Sachen auf uralten Kisten. Hast du eine bestimmte Vision wo das hingehen soll mit dem Coden, und diesem Tetris game? Schon Ideen, was danach kommen soll, oder wie das weitergeht?

Zitat

Ja - ich geb zu - das war dann vor dem Coden eben "schlechtes Design" auf Papier. Aber du musst bedenken : spätestens ab 1000 Zeilen Quellcode ist ein Programm schon so groß, dass man unmöglich jeden Aspekt davon schon vorher durchplanen könnte.

Entwicklung ist ein Prozess wo vieles im Fluss der Arbeit erst hochkommt.

Also ich denke, der richtige Ansatz ist bei der Programmierung in jedem Fall "teile und herrsche"! Das gilt natürlich für jeden Dialekt und jede Programmierweise.

Ich bleibe da immer auch bewusst mit den Methoden der OOP und der Verkapselung, einfach weil man so den Aufbau des Programmes intuitiv richtig modularisiert. Das liegt auch meiner Methode der Vorplanung. Erst stelle ich mir das Programm als Summe seiner Einzelteile und Funktionen vor, die geplant sind. Dann versuche ich grob, einzelne Untergruppen zu formulieren, immer in Abhängigkeit zu den anderen Gruppen und eben den auszutauschenden Daten sowie der Verwaltung der Daten. Das ergibt dann meist einen wilden Graphen mit verknüpften Blasen, wo die Verknüpfungen die Schnittstellen und Austausch-Tools wiedergeben. Manche Konzepte sind da generell und bieten sich einfach an dabei zu respektieren, etwa model/view/controller-artige Aufbauphilosophien, oder client/server Trennungen im Aufbau von den Programmen.

Das liegt mir am Besten, das dann eben auch mit OOP umzusetzen. Die nächste Stufe ist dann meist schon die genau formulierung der Schnittstellen und Datentypen, das mache ich sogar teils noch auf Papier, alles noch vor der ersten umgesetzten Programmierzeile. Das ist auch Teilen und Herrschen, denn jede Aufgabe ist die Überdenkung dieser spezifischen Objektdefinitionen und Schnittstellen, und jedes nur für sich als einzelne Aufgabe. So teilt dann der vorher visuelle Graph, auch die Arbeit in einzelne Einheiten, das sind die einzelnen Objekte und Methoden der Funktionsgruppen, und die Umsetzung der entsprechenden Schnittstellen zwischen den Gruppen. Eigentlich ein ganz einfaches Modell. Das Vermischen der Ebenen wird halt vermieden, indem jede einzelne Schnittstelle agnostisch gelöst wird, und Datenzugriff etwa auch modularisiert wird, so dass die einzelnen Module, die daran arbeiten, nichts voneinander wissen müssen als was die Schnittstellen definieren. Solch eine Methode musste ich mir aber auch aneignen, da die Projekte, die ich vorhabe, teils hochkomplex und durchmodularisiert sind. In so einem Kontext ist glaube ich reines C zu nutzen - eine ziemlich masochistische Angelegenheit. Könnte man mit C++ ganz so wie du es siehst, aber auch leicht auf noch masochistischere Weise so verkomplizieren, dass man am Ende noch schlimmer dasteht. Also immer schön in kleine Häppchen teilen, wo jedes für sich steht. Und die versuche ich dann immer mit den einfachsten Mitteln meiner Programmiersprache umzusetzen, so stumpf es geht. Ich teste etwa alle Einheiten auch immer für sich, also ausserhalb vom Programmkontext, jedes Modul sollte auch in anderem Kontext einfach so einsetzbar sein. Dadurch vermeidet man auch die Verwirrung ganz immens, und kann auch die Module richtig auf Fehler prüfen, bevor man es in ein Spiel einbaut und dann der Fehler erst bei einem Sonderfall offenbar wird.

Also gründliche Planung, habe ich auch dank meiner vielen erfolglosen Projekte, als das wichtigste Empfunden. Es ist natürlich aber auch legitim, erst Einzelteile aus der gesamten Arbeit herauszunehmen und vorwegzunehmen, etwa weil das spätere Design von der Machbarkeit und den dabei gesammelten Erfahrungen abhängt.

Das mit dem Refaktoring, wenn die Eigenschaften und Schnittstellen kreuz und quer wandern, ist wirklich ein Problem. Ich war so weit nicht, bis jetzt kam noch alles bei mir so hin. Ich denke aber, Refaktorieren ist immer ein Schritt für sich...dafür sollte man sein Programm freezen, dann die nötigen Teile umstrukturieren, und dann erst weiter an anderen Teilen arbeiten. Vermeiden kann man das wohl wirklich nur mit genug Erfahrung und gründlicher Planung.

Das Tetris-Teile Problem hätte ich tatsächlich wohl auch redundant gelöst, einfach um z.B. die möglichkeit komplexerer Formen oder einer Umfärbung offen zu halten. Das muss man halt vorher durchdenken, an welcher Stelle die Farbe gesetzt werden soll, weil die Ebene wiederum die Möglichkeit verschiedener Ausprägungen vorgibt. Also in der Grunddefinition hätte ich denke ich für den Standardsatz tatsächlich eine statische Definition mit Form und einer Farbe, wenn sie für die ganze Form gelten soll. Wenn etwas zusammenfassbar ist, dann sollte es auch. Im spiel in der engine ist es auch eher egal, da läd die Ebene, die den Stein kontrolliert und mit dem Feld abgleicht die Grundform und setzt das dargestellte Modell aus den Daten zusammen - da braucht die Farbe wirklich nur noch in jedem Stein für sich zu existieren, nicht mehr für die ganze Form. Solche Überlegungen halt, sind was mir am meisten den Kopf sprengt, und deswegen mache ich dafür echt 50% der ganzen Arbeit nur auf Papier und im Kopf. Dann hat man später auch viel mehr den Kopf frei für die eigentlichen Algorithmen und die Fehlersicherheit, einfach weil eine gute Stukturierung die richtigen Abläufe so gut vorwegnimmt.

Zitat

Eine ganz einfaches, klassisches Schichtenmodell. Jede Schicht hat keinerlei Ahnung davon, dass es über ihr noch weitere Schichten gibt. Eine Schicht kann nur auf die Schicht direkt darunter zugreifen.

Hmm, bei purem C bietet sich das auch an, mit so Schichten zu arbeiten, wo jede für sich eine Art Kernel mit eigenen Funktionen ist. Viele alte Games gehen ja auch von einer Art "Page"-Modell aus, wo die einzelnen Szenen des Games in verschiedenen teils komplett eigenständigen Modulen aufgebaut sind, die nur durch extrem dünnen Austausch miteinander verbunden sind. Also Schichtenmodell - magst du kurz erklären, wie du diese Schichten logisch aufbaust?

Ich habe auch eine Zeit mit dem Gedanken gespielt, nur noch C zu nutzen, würd auch drauf klarkommen - aber die OOP Syntax ist mir dann zu lieb geworden, wirklich Instanzen mit einer Bündelung von Eigenschaften und Methoden auch so im Text zu handhaben, befreit mich eher, als alles maschinell zu sehen, wie es bei klassischem C der Fall ist. Ich denke auch, klassisches C ist dann so mächtig in seiner Einfachheit, dass es ein wirklich gutes Konzept braucht, wie man das nutzen will. Sehe ich auch bei LUA - ist die absolut simpelst aufgebauteste Sprache, aber hat's in sich, das OOP muss man sich da auch erst selbst schnitzen und schärfen, dann zeigt sich da auch die Macht der einfachen Mittel.

Zitat

Nach Cetris? Einen Raumschiffshooter wie Hybris damals. Simpler von der reinen Spiellogik, dafür aber deutlich umfangreicher das Tatsache umzusetzen - vor allem die Grafiken/Sprites selbst anzulegen wird lange dauern :

Das ist ja mal ein korrekter Sound bei diesem Shooter, echt cooles Ding und die Grafik hat's auch. Aber die Musik ist der Hammer! Ich beschäftige mich auch schon lange mit Tracker Music was ja am Amiga angefangen hat, kenne mich auch mit dem Tracken, dem Code für Audio usw. aus. Diese Tracks zu den Games damals waren quasi Meilensteine elektronischer Musik, noch bevor komplett synthetische Musik in den Charts überhaupt ernstgenommen wurde, der erste richtige Techno, der die Massen erreicht hat quasi. Es gab auch tatsächlich in den 90s dance music, auf Amigas gemacht, den Leuten war der schepprige Sound egal, für die Genres hat's gepasst und war fast so gut wie die tausende Mark kostenden damaligen Sampler.

Auch so bestimmte Details in dem vid von dem game haben mich mitgenommen. Zum Beispiel einer der 4 channels wurde teils der Melodie, teils den Explosionen zugeordnet, so dass die Musik manchmal bis auf den Beat aussetzt. Also du wirst nicht nur endlos viele Sprites und Pixelgrafiken brauchen, sondern auch die Sounds und die Tracks dazu. Lass mich wissen, wenn du Hilfe dabei brauchst, wenn du das ganz klassisch mit Trackermodulen selbst lösen willst.

Zitat von Sethanas

ardentglow sorry, dass ich das github-Repository noch nicht freigeschaltet habe, aber ich habe bisher noch keinerlei Erfahrung, was das alles für Auswirkungen hat, wenn ich ein Repository öffentlich schalte.

Deswegen zögere ich derzeit noch bzw. muss noch Zeit finden, mich darüber schlau zu machen.

Deswegen habe ich einen Snapshot vom aktuellen Entwicklungsstand mal auf meinen Webspace hochgeladen.

https://adler-auge.net/downloads/Cetris-main.zip

Da ist allerdings noch keine Installationsanleitung dabei. Aber in der Zip-Datei sollte alles enthalten sein, damit man das zum Laufen bekommt. Auch die SDL3-Bibliothek in der Version 3.2 ist dort zu finden.

Mal sehen, ob das hier jemand zum Laufen bekommt.

Wäre super, wenn das jemand unter Windows kompiliert bekommt. Ich sag nur Cygwin oder MinGW.

Alles anzeigen

Ich schau es mir die Tage mal an, falls ich Zeit finde. Eben kurz reingeschaut - sieht nach sauberem C Code aus, ein bisschen nostalgisch, ich wollte sowas auch mal machen und hatte an sowas geübt. Ziemlich umfangreicher code...

Sethanas

Als Spiele-Begeisterter freut es mich sehr, auf dich hier zu treffen. Ich habe jetzt nicht alles lesen können, aber du übst dich als Programmierer, baust schon ein erstes eigenes Spiel. Beeindruckende Sache.

Ich bin übrigens ein Hobby 3D Artist und war jahrelang Modder, durch das Modding entstand die Liebe zur 3D Kunst. Vom Programmieren hab ich aber nur wenig Ahnung, also oft versucht zu lernen, aber hab dafür kein Händchen. Also Hut ab!