spiele patchen ...



  • wie schaff ich es am besten, ein spiel so zu machen, dass es aus mehreren modulen besteht, die jederzeit erzänzt/entfernt/ausgetauscht werden können ...
    das spiel soll nach jedem patchen/modden zusammengesetzt werden.

    ich bin sicher nicht der einzige zu sein, den/die es interessiert ... 😃



  • du hast nen core und daneben viele kleine dateien die die spiellogik als scripte enthalten 😉

    alternativ funzen auch dlls 🙂



  • Ich würde dir empfehlen DLLs zu benutzen, da scriptparsing meißtens sehr aufwendig ist. Guck dir mal im bcb-tutorial.c-plusplus.net das Kapitel Objekte aus DLLs exportieren an. Das is zwar für den BCB aber funktioniert im Grunde mit jedem Compiler gleich. Dann baust du dir einmal eine abstrakte Basisklasse z.B. TLogic oder sowas uund implementierst sie in mehreren DLLs immer unterschiedlich. TLogic ist dann sozusagen die Schnitstele mit der du auf die DLLs zugreifst. Dann musst du nur noch bestimmen welche DLLs du lädst. (z.B LoadLibrary) ich würde sie jedoch einmal laden und geladen lassen, da das schneller ist und außerdem sobald du die DLL wieder entlädst wird wahrscheinlich das Objekt zerstört (hab ich nie ausprobiert 😉 ). Wie diese Schnitstelle(n) aussehen ist dir überlassen, ich würds mir jedoch sehr gut überlegen, weils du nacher nicht mehr ändern kannst. So hab ich mal was gescrieben. Wenns irgendwelche unklarheiten gibt kann ich dir ja mal ein beispiel zuschicken. Musst mir nur sagen welchen Compiler du verwendest (bzw. Welche IDE)



  • Für dlls braucht man keine abstrakte Basisklasse. Du kannst ja z.B. auch C Funktionen anbieten.

    Bye, TGGC (Der Held bei Dir!)



  • hm das hab ich noch vergessen zu erwähnen!

    das spiel läuft auf windows, mac os und linux.
    und soweit ich weiss funktionieren dlls nur unter windows ... oder isses falsch? 😕

    otze schrieb:

    du hast nen core und daneben viele kleine dateien die die spiellogik als scripte enthalten 😉

    ja, ich dachte auch in die richtung ... aber wie realisiert man das?



  • core=grafikengine+scriptparser+archivloader.
    scripte sind in nem archiv drin.
    der scriptparser muss so erweitert werden, dass er die objekte direkt der grafikengine übergeben kann.
    als scriptsprachenbasis würde ich sowas wie python nehmen(boost hat doch auch eine lib die python parsen kann oder?naja das müsste halt erweitert werden).

    ansonsten verweise ich dich mal auf folgenden monsterartikel:
    scripting tutorial

    achja, die standardlektüre falls man was eigenes haben will:
    Das Drachenbuch
    ist aber ziemlich harter tobak



  • wenn du scripten willst, schau dir mal lua an



  • Warum bricht eigentlich nur zwischen Torvalds und Gates Krieg aus und nie zwischen Lua und Python?!? 😕

    🤡



  • Sgt. Nukem schrieb:

    Warum bricht eigentlich nur zwischen Torvalds und Gates Krieg aus und nie zwischen Lua und Python?!? 😕

    🤡

    Weil es sowieso selbstverständlich ist, das python besser ist. 😉
    Würde ich jedefalls empfehlen wenns um scripting geht (und sonst auch 😉 )

    @ topic: dlls gibt es unter Linux sehr wohl, nur heissen sie dort .so (shared object). Ich bin sicher etwas vergleichbares gibts auch unter mac, wäre sonst schon ziemlich rückständig.

    Ansonsten kannst du ja auch auf binärpatches zurückgreifen.



  • danke für die links.

    ChockoCookie schrieb:

    @ topic: dlls gibt es unter Linux sehr wohl, nur heissen sie dort .so (shared object). Ich bin sicher etwas vergleichbares gibts auch unter mac, wäre sonst schon ziemlich rückständig.

    braucht man zum kompillieren einer solchen bibliothek auf einem anderen betriebssystem den code zu ändern?

    ChockoCookie schrieb:

    Ansonsten kannst du ja auch auf binärpatches zurückgreifen.

    sry ... was soll das heissen/wie funktioniert das ca? 😕



  • zu 1: Du musst die Funktionen zum Laden der .so anpassen und unter Windows brauchst du eine eigene direktive mit der du extern aufrufbare Funktionen in der dll kennzeichnest. Schau mal hier
    das dürfte die meisten deiner Fragen beantworten.

    zu 2: Das heist nur: du hast EXEalt und EXEneu und speicherst die Unterschiede zwischen den beiden in eine Datei, die dann an den User geht. Dort wird das ganze an EXEalt angebracht (vorzugsweise von einem Installationsprogramm) und ergiebt somit EXEneu. Ist aber nicht wonach du gesucht hast und bringt auch bei EXEn nichts, weil die meistens eh so klein sind, das man sie vollständig austauschen kann. Ist eher interessant, wenn sich an den Spieldaten (Level, etc.) was ändert. Unter Linux geht das mit diff und patch.



  • Du musst die Funktionen zum Laden der .so anpassen und unter Windows brauchst du eine eigene direktive mit der du extern aufrufbare Funktionen in der dll kennzeichnest. Schau mal hier
    das dürfte die meisten deiner Fragen beantworten.

    hm ... von MacOs ist da aber nicht die rede ... ich würde nur ungern drauf verzichten. óÒ
    ansonsten ein wirklich gutes beispiel.

    Das heist nur: du hast EXEalt und EXEneu und speicherst die Unterschiede zwischen den beiden in eine Datei, die dann an den User geht. Dort wird das ganze an EXEalt angebracht (vorzugsweise von einem Installationsprogramm) und ergiebt somit EXEneu. Ist aber nicht wonach du gesucht hast und bringt auch bei EXEn nichts, weil die meistens eh so klein sind, das man sie vollständig austauschen kann. Ist eher interessant, wenn sich an den Spieldaten (Level, etc.) was ändert. Unter Linux geht das mit diff und patch.

    alles klar ... thx.
    find ich interessant ... kennt jemand vielleicht nen (beispiel/opensource)code dafür? 🙄



  • diff und patch sind selbstverständlich opensource, da von linux.
    http://www.fsf.org/software/patch/patch.html
    http://www.gnu.org/software/diffutils/diffutils.html



  • sieht klasse aus. aber löst die sache nicht komplett ...
    ist nur für die exe/engine gut. das spiel lässt sich so aber nicht modden. (sry, hab ich vergessen zu erwähnen) 😞



  • dann musste dir wohl ne scriptsprache an land ziehen



  • ChockoCookie schrieb:

    diff und patch sind selbstverständlich opensource, da von linux.

    diff und patch sind IMO schon älter als Linux, unter GNU/ Linux verwendet man meist die GNU-Versionen davon.

    Für Binär-Patches dürften außerdem xdelta und Co. wesentlich besser geeignet sein als diff und patch, da diese darauf ausgelegt sind, auf Plaintext zu operieren und nicht auf Binaries.


Log in to reply