d13 sagt Hallo! 22.01.2017 - 18:23 2
Folgenden Nutzern gefällt das Design: damios, krazun

Hi Leute,
Hier ist der Fhizban - nachdem ich vor ein paar Tagen mein Projekt hier eingestellt habe, möchte ich nun noch einige persönliche Worte dazu zum Besten geben. Achtung - der Text könnte durchaus etwas länger werden.

Eine kleine Geschichtsstunde

Angefangen hat das Projekt bereits vor einigen Jahren, damals noch auf einer pseudo-kommerziellen Engine mit dem Namen BG-World. Die Macher mitsamt ihrer Engine sind längst vom Erdboden verschwunden, was mich auch nicht weiter wundert. Der Code war zwar im Vergleich zu der Vielzahl an Travian/Ikariam/Stämme Clones dort draussen recht gut strukturiert, allerdings so vollgestopft mit Fehlern und extrem schrägen Lösungen das man unter dem Strich sagen musste: Das Ding taugt nix!

Jetzt bin ich selbst nicht der beste Coder und zudem auch kein gelernter Informatiker oder so (Ich komme mehr aus der Design Ecke). Aber der Vorfall hat mich so geärgert, dass ich seitdem an dieser kleinen Engine mit dem abstrusen Namen "d13" herumbastle. Alles was ich in den letzten Jahren gelernt habe, ist hier umgesetzt und alles was ich mir anlernen musste, wurde wegen dieses Projektes getan.

Die Zeiten haben sich geändert. Browsergames waren ja mal ein Riesending. Erst die textbasierten und dann auch viele auf hochglanz polierte kommerzielle Projekte. Die gibt es zwar immernoch, aber die Zeiten sind definitiv vorbei. Heute regieren Mobile Apps und AAA Titel auf Heimcomputern und Konsolen. Das hält mich allerdings nicht davon ab, an d13 zu werkeln - ganz im Gegenteil.

d13 - der robuste Volvo

Natürlich haut die grafische Seite des Projekts jetzt niemanden vom Hocker. Aber es ist immernoch ehrlicher als die vielen mit Unity Standard Assets erstellten Spiele welche derzeit Steam und Co. überfluten. d13 läuft direkt im Browser und wird mit Webtechnologien entwickelt. Das heisst: Hier wird einzig und allein mit Wasser gekocht. Das ist sparsam und reduziert die damit möglichen Spiele auf das wesentliche: Gameplay. Mögliche Spiele? Moment...

Der ganze Sinn hinter d13 ist es, eine Art Editor (= Engine) zu sein, mit dem jeder der möchte - sich seinen Traum vom eigenen Strategie-Browser-Game verwirklichen kann. Und das komplett kostenlos und open-source - wer möchte (und sich auskennt) kann das Projekt selbst umbauen und nach eigenen Wünschen erweitern (sofern Ihr mit meinem etwas abstrusen programmierstil zurechtkommt).

Zu bedenken ist, dass nur und auschließlich Strategspiele wie aus der guten alten Zeit mit d13 umgesetzt werden können. Dazu gehören (allen voran) oGame, aber auch Spiele wie die Stämme, Travian, Ikariam, Grepolis und wie sie alle heissen. Ein nicht unerheblicher Pluspunkt (und ein Manko vieler alter Browsergames) ist das responsive-Design sowie die damit einhergehende Tablet/Mobilfähigkeit des Projekts.

In seiner Grundform ist d13 von jederfrau und jedermann editierbar, ganz ohne programmier-kenntnisse. Ihr benötigt lediglich einen PHP fähigen webserver mit mySQL datenbank sowie einen Text Editor eurer Wahl. Durch das editieren der Datendateien lässt sich bereits zum heutigen Stand eine ganze Menge mit d13 anstellen: Ihr könnt die Truppenwerte verändern und damit auch zahlreiche Taktiken einbauen. Gebäudewerte, Resourcenwerte sowie der Tech-Tree können auf die gleiche Art und Weise angepasst werden.

Wer sich etwas besser auskennt kann das mitgelieferte Demo-Template (mit frei verfügbaren Grafiken von Kenney.nl) komplett umkrempeln und das Spiel wie "eines von den Großen" aussehen lassen. Dazu sind jedoch nicht nur gute CSS und HTML Kentnisse gefragt sondern auch ein gutes Grafikprogramm und jede Menge hochwertiger Grafiken.

Gegenwart und Zukunft

Abschliessend möchte ich noch kurz auf den gegenwärtigen Entwicklungsstand eingehen: d13 ist noch nicht komplett fertig, verfügt jedoch schon über eine beeindruckende Palette von Features. Im Endeffekt kann man jetzt schon ein kleines, vollumfängliches Spiel damit zusammenzimmern - jedoch müsst ihr derzeit noch auf das Landkartensystem, Spionage und einige Komfortfeatures verzichten.

Der Grundstock ist bereits gelegt. Vom registrieren, über den Login, vom Aufbau der ersten eigenen Stadt und dem forschen von Technologien über das ausbilden der eigenen Armee und dem schlagen erster Schlachten bis hin zu einer Rangliste, taktischen Kampffaktoren, Benutzereinstellungen und einem simplem Admin-Menu ist bereits alles vorhanden.

Als nächstes werden das Kartensystem sowie die noch fehlenden Punkte Sabotage und Spionage fertiggestellt. Danach werde ich mich um einige Komfortfunktionen sowie erweiterte Funktionen wie man sie aus Mobile-Spielen kennt kümmern. Dies wird wahrscheinlich so typische dinge wie Achievements, Quests, Daily-Login Rewards und andere Kleinigkeiten umfassen.

d13 soll - trotz der gewissen Altbackenheit eines Volvo Motors - den großen Browsergames, Multiplayer-Mobile-Titlen sowie MMOs in punkto funktionen und umfang in nichts nachstehen. Da ist mein Ziel - eine frei verfügbare Browsergame Engine, welche vor features nur so strotzt!

Danke fürs lesen

euer Fhizban!


Aktualisiert: 23.01.2017 - 07:10
Grund:
22.01.2017 - 22:03
GWRon
In den letzten 60 min online
GWRon
Rang 11

Projekte: 4
Designs: 3
Blogs: 7
Aktivität:
Inaktiv

Ich kenne jetzt den Quellcode nicht, aber wichtig ist die einfache _Erweiterbarkeit_ des Ganzen. Du sprichst ja schon "Spionage" an. Das ist fuer mich ein solches "Extra".

Weiterere Kandidaten sind "Dungeons" oder "Aufträge".

Sind ja auch alles Dinge, die von den - ebenfalls schon angesprochenen - Quests gestartet/beendet/... werden koennen.
 

Auch interessant koennen "Buffs" in verschiedensten Ausfuehrungen sein - Einheitenverstaerkung, Mehr Gold aus allen Minen fuer X Stunden ... 

 

Je dynamischer Dinge sein koennen, desto schwieriger wird es umzusetzen. Je einfacher Du es Dir dabei machst, desto weniger Dynamik erlaubst Du den "Autoren". Bin gespannt, wie Du das umsetzt - vor allem in Hinblick auf "Zusammenklicken" ("addons/bla.php" + registerHook() + registerHUDElement() + ...waere ja zu einfach :-)).

Aber ehrlich? Ich wuerde es genau so machen wie gerade vorgeschlagen: Die Erweiterung der Grundmechanik sollte mit Hilfe von "Addons" realisierbar sein (damit koennen verschiedene Autoren die gleichen Addons auf Deine Engine aufpfropfen und muessen nur die Assets anpassen). Dazu solltest Du eine Basisklasse fuer die Addons schaffen, die von allen Addons zu nutzen ist. Dann kann die Engine die Addons abfragen, fuer was sie sich interessieren, was sie bereitstellen etc. (und alles schoen cachen - man installiert ja addons und deren neue Revisionen nicht dauernd "neu" - uebersieht der geneigte Webentwickler ja leider doch noch haeufig genug).

Dieses Addonprinzip laesst sich dank simpler Hooks in beliebige Funktionen integrieren. Man muss nur fruehzeitig integrieren (hast Du ja vielleicht schon erledigt?). Und wenn Du jedem Addon auch noch die Funktionen fuer eine visuelle "Konfig" mitgibst, sollte es auch fuer die "Mausschubser" einfacher von der Hand gehen.

 

Viel Spass beim Coden/Werkeln/Basteln

bye
Ron

 

GWRon
In den letzten 60 min online
GWRon
Rang 11

Projekte: 4
Designs: 3
Blogs: 7
Aktivität:
Inaktiv
23.01.2017 - 07:15
Ersteller
Fhizban

Moin Ron,
Danke für das ausführliche Feedback, freut mich!

Also was die Plugins und Hooks angeht muss ich dich leider enttäuschen. Mir sind diese Dinge aus Forensoftware bekannt, aber ich habe mich dagegen entschieden. Das Vorbild Projekt BG-World hatte dieses Feature auch nicht. Stattdessen wird es eine fixe Anzahl an Features geben, welche man jeweils mit einem Boolean an und ausschalten kann. Im Endeffekt wird aber jeder Nutzer alles zur Verfügung stehende nutzen wollen.

Natürlich kann es das später mal geben ,Programmiertechnisch wäre es nicht so schlimm. Würde jedoch einen nicht unerheblichen Umbau bedeuten. Bedenke das ich das Ding derzeit komplett allein entwickle.

Den Rest der erwähnten Features gibt es schon oder es ist im Bau: Templates werden gecached, datendateien werden gecached und so weiter.

Dungeons, Aufträge, Quests und so weiter stehen auf der To-Do-Liste. Genauso wie die angesprochenen, Zeitbasierten Buffs.

Der nächste Eintrag wird mal die vorhandenen Features grob umreissen, scheint mir ein gutes Thema!

-Fhiz

Ersteller
Fhizban
23.01.2017 - 09:50
GWRon
In den letzten 60 min online
GWRon
Rang 11

Projekte: 4
Designs: 3
Blogs: 7
Aktivität:
Inaktiv

Gibt es einen Grund fuer das "dagegen entschieden"? 

Ich frage rein aus programmiertechnischer Sicht. Gerade mit Skriptsprachen ist es ja ein leichtes, einfach an allen geeigneten Stellen Ereignisse auszuloesen - Ereignisse die abgefangen (keine weitere Bearbeitung durch Folgecode oder andere "Mithoerer") oder abgehoert (eigenes Zeug zusaetzlich machen) werden koennen.
Der Vorteil ist ja, dass am Ende das Ergebnis eh gecached wird (also wenn man bei PHP den APC oderaehnliches nutzt). Sprich es kommt nicht zu grossen Performanceverlusten. Wenn, dann entstuenden die durch das erhoehte DB-Query-Aufkommen - aber auch das wuerde ja bei Bedarf gecached werden koennen oder eh nur als Reaktion erfolgen ("Besuche Dungeon X").

Ein weiterer Vorteil waere es, dass Du selbst deine Basisfeatures ueber diese Methodik ins Spiel bekommen wuerdest - sprich nahezu alles wuerde zu einem "Modul" werden und nur das Kernsystem ist fix. Dieses Kernsystem kuemmert sich um API / REST SOAP, Auth, Modulverwaltung, GUI ... . Wenn das durch "Verflechtungen" nicht moeglich sein sollte, ist das Grundkonzept schon auf "unsauberen Beinen" (ist nicht so schlimm wie es sich anhoert - aber bei groesseren Projekten wirklich ein Hindernis).

Das dies bei Forensoftware eingefuehrt worden ist, hat seinen Grund: immer mussten Addons auf neue Forenversionen aktualisiert werden, man musste die Quellcodes patchen um seinen "spezial-bbcode" wieder reinzubekommen, um "adsense posts" als Post 2 zu haben und was weiss ich nicht noch alles. Die Hooks sind aehnlich einer API relativ "konstant" und damit ein fixer Ansatzpunkt fuer Erweiterungen.

 

Aber wie gesagt, ich wuerde gerne Deine Gruende lesen, warum Du dich dagegen entschieden hast - vielleicht geben die mir ja auch zu denken.

PS: Ich denke viele Projekte hier sind an sich "Ein-Mann-Projekte" - geht mir bei "unserem" Spiel ja auch so - da bin ich Maedchen-Fuer-Alles und die Schuetzenhilfe besteht im Fuellen der Datenbanken, Testen + Bugs-Melden (sehr wichtig) und Ausdiskutieren von Ideen (am Wichtigsten). Solange aber alles "Hobby" ist, und man nicht davon leben muss - sollte die Experimentierfreude nicht zu kurz kommen. Dinge wie Addons zu ermoeglichen, ist das was Entwicklern - wie wir sie sind oder sein wollen - auch Spass bringen sollte.

 

bye
Ron

GWRon
In den letzten 60 min online
GWRon
Rang 11

Projekte: 4
Designs: 3
Blogs: 7
Aktivität:
Inaktiv
23.01.2017 - 11:45
Ersteller
Fhizban

Du hast den Grund schon selbst genannt: Das Projekt steht auf unsauberen Beinen.

Kein Wunder: Ich bin weder gelernter Anwendungsentwickler noch sonstwas.

d13 wurde in den letzten vier Jahren im ON/OFF modus auf basis meines jeweligen Entwicklungsstandes begonnen und bis heute weiterentwickelt. Da sind eine große Menge verflechtungen die diesem Ansatz im Wege stehen.

Ich finde deinen Vorschlag echt super, aber "not for this project". Vielleicht in der Zukunft bei einer Version "d14" einmal.

Schau, auf makewebgames.com sind viele Fach-Informatiker und Anwendungsentwickler (auch wenn das board heute tot ist). Dort gibt es eine Rubrik mit "other Engines" da findest du 4-5 DUTZEND projekte die genau das bieten was du ansprichst: Plugins und so weiter.

Die wurden von profi's geschrieben. Man nehme Composer, Laravel, memcache, fat-free-framework und werfe alles zusammen in einen Topf und poste es auf Github.

Nur....kein einziges dieser Projekte hat ein funktionierendes Kampfsystem, geschweige denn sind es "fertige" Projekte.

Und das ist der Unterschied: d13 ist weit davon entfernt perfekt zu sein, aber es läuft. Und genau bei dem Konzept bleibe ich.

PS: Schau dir mal den Code an und sag mir wie ich das jetzt noch mit den Addons gebacken bekomme, du wirst mir zustimmen das das für <dieses> Projekt keinen Sinn macht (sourceforge.net/p/d13).

Ersteller
Fhizban
23.01.2017 - 12:16
GWRon
In den letzten 60 min online
GWRon
Rang 11

Projekte: 4
Designs: 3
Blogs: 7
Aktivität:
Inaktiv

Ich bin auch "oldschool" und benutze eher wenig frameworks und Composer.

Und ja -- "alter Code" kann manchmal echt eine fiese Sache werden. Hat schon einen Grund, dass TVTower seit 13-14 Jahren in Entwicklung ist. Da habe ich schon einiges neugeschrieben, weil es den geplanten Funktionen im Wege stand.

 

Wie man Addons umsetzen kann: Nehmen wir an Du hast eine Funktion "GetUnitStats()" die einen Array mit Angriffswerten, Verteidigung... fuellt.

Innerhalb dieser Funktion gibst Du den Array einfach an alle interessierten Addons weiter - die bearbeiten den Array nach ihren Wuenschen und Regeln und fertig. Das ganze kann man natuerlich fuer "absolute Werte" machen und auch fuer "Modifikatoren". Es gibt also Einstiegsmoeglichkeiten "Angriff = Angriff * x" oder "Angriff = Angriff + x".

Den Addonsupport schreibst Du im Kernsystem (was immer geladen wird) - also so, dass Du dann ueberall etwas nutzen koenntest wie
Hooks::Run("units:getunitstats", $unit);

Das System wuerde dann an alle Dinge, die sich fuer "units:getunitstats" interessieren ("registriert haben") die entsprechend dort definierte Funktion mit dem Parameter "$unit" aufrufen.

Gibt es kein Addon was sich dafuer interessiert, passiert auch nix. Dementsprechend kannst Du an den beliebigen Stellen schon diese "Run"-Sache einfuehren. Wie gesagt: mit einem Opcode-Cache (APC oder so) sollte es eigentlich keine Performanceprobleme geben. Hatte das mal fuer ein (Multi-Client) CMS so umgesetzt - und lief prima und erlaubte die besagten Addons (die fuer jeden Client einzeln zu buchen waren).

 

Musst Du nicht umsetzen - aber drueber nachdenken schadet nicht.

 

bye
Ron

 

GWRon
In den letzten 60 min online
GWRon
Rang 11

Projekte: 4
Designs: 3
Blogs: 7
Aktivität:
Inaktiv