BG-Engine... wie könnte sowas aussehen?

Bei PC-Spielen ein Standard.. die Engine. Sie stellt Karten und Geläde dar, verwaltet Aktionen wie Mausklicks, überprüft Dinge wie Kollisionsabfragen und die Wegfindung.

Grade kommerzielle BGs setzen inzwischen immer mehr auf Grafik und man könnte sagen das die BGs aus der DOS-Zeit hin zu Windows95 wandeln (Alpha und Beta-Versionen, dafür langsam mit guten Grafiken). Was bei Weltraumspielen bestenfalls ein paar Bildchen für Schiffe und Menüs sind bedeutet für Strategiespiele ein aufwendiges Kartensystem, mit massenhaft kleinen Bildchen aus dennen die Spielkarten zusammengesetzt werden. Hinzu kommen onclick-JS Scripte welche die Mausklicke des Users verwalteten und die prüft ob hier und dort etwas gebaut oder bewegt werden kann.

Was ich nun frage ist rein konzeptionell und ich weiss auch beim besten Willen nicht ob sowas jemals umgesetzt werden kann.
Doch wenn es eine BG-Engine geben sollte - eine Engine welche z.B. Isometrische Karten darstellt und berechnet. Eine Engine welche sowohl beim BG "Steinzeit-Wars" wie auch beim 2. WK-BG "Stalingrad" Verwendung finden könnte.

Was muss so eine Engine (auf simplem PHP, HTML und JS basierend) können um "frei" eingesetzt werden zu können. Welche Features sollte sie enthalten? Nur Kartendarstellung? Oder sollte es gar ein BG-CMS System sein welche neben der Kartendarstellung, Dinge wie User und Resourcenverwaltung berechnen können sollte.

Wie sollte soetwas aufgebaut sein? Welche Erfahrungen habt Ihr mit Kartendarstellung gemacht und was muss man beachten um die Systemleistung und den Traffic gering zu halten?

Schreibt einfach mal und sammelt Ideen rund um das Thema...

ich denke mal nicht das es moeglich sein wird sowas zu realisieren...
also ein CMS ist sogut wie unmoeglich dazu sind die spiele einfach viel zu verschieden...
im grunde kannst du nur ein baugeruest erstellen was bestimmte funktionen zur verfuegung stellt wie z.b. wegberechnung, kartendarstellung, allgemeine funktionen, forum, anmeldung, login und im grunde wars das auch...
es macht einfach nicht wirklich sinn ein so extrem komplexes CMS zu bauen womit man unterschiedliche games wie Uga-Agga oder Space-Pioneers einrichten koennte... die spiele sind wie bereits gesagt viel zu komplex um sowas wirklich realisieren zu konnen und im endeffekt ware das CMS dann viel zu uberladen!
wenn es wirklich so einfach ware wurde man es sicherlich heute auch bei "richtigen" spielen machen... ein Frontend wo man bissle was einstellt und raus kommt ein spiel wie WC3 oder C&C
wie allerdings bereits gesagt konnte man allgemeinnuetzliche funktionen bereitstellen und ein portal entwickeln... das spiel selbst mueste denn trotzdem noch individuell entwickelt werden.

sorry fuer die rechtschreibung bin hier im ausland auf dem sziget festival (bereits seit dienstag) und mega durch und bissle angetrunken

mfg
euer OranGe im Fastivalrausch

er hat ne allgemeine engine gemeint kein CMS
ein CMS ist halt nur für ne webseite ok

aber ich glaube er meinte was anderes eher im sinner von schnelles backend auf das per apicalls zugegriffen wird

Ich hatte mir mal sowas überlegt und habe auch ein Konzept verfasst, nur leider habe ich es auf Grund des großen Aufwandes abgebrochen!

Insgesamt wäre ein allgemeines BG-Backend sehr wünschenswert, nur stellt sich die Frage welche Teile verallgemeinert werden können. Für mich kommen folgende Komponenten in Betracht:

a) Benutzerverwaltung (Anmeldung, Login, Kennwort vergessen und der restliche Trulala)
b) Nachrichtensystem
c) 2 dimensionale Karte (fällt bei Weltraum-Spielen raus, dort dann '3'-dimensionale Karte)
d) Wegfindung für c)
e) Forschungsbaum
f) Allgemeine Rohstoffverwaltung (Ein Warenkorbsystem, dem man Rohstoffe zugeben kann oder wegnehmen)
g) Ein internes Event-Message-System, das Spiel-Ereignisse verteilt (Kämpfe, Forschung fertig, Bau fertig)
h) Ein System für fortlaufend wachsende Rohstoffe (à la OGame)
i) Einheitenverwaltung mit Bau
j) Kampfsystem mit dynamisch austauschbaren Regeln
....

Es gibt genug Komponenten, nur glaube ich es nicht, dass es möglich ist, diese Komponenten zu verschmelzen, dass es ein in sich geschlossenes BG wird. Eher eine lose Komponentensammlung, die jeder Programmierer selbst verknüpfen muss.

Weiterhin sehe ich die Sprache PHP als ungeeignet an. Ich würde eher auf kompilierte Sprachen setzen, da der Umfang des abstrakten Frameworks doch recht groß sein wird.

Ich denke, man kann keine allgemeingültige Browsergameengine machen. Immerhin gibt es auch keine allgemeine PC Spiele Engine. Da gibt es nur Engines für 3D Action Spiele, für Echtzeitstrategiespiele, usw. Ebenso wird es dann wohl engines für Tickbasierte Strategie-BGs, für Ogame Klone, usw geben.

Noch eine Frage zu meinem eigenen Spiel, das jetzt auch zum Download erhältlich ist. (siehe News) Wenn ich das noch um ein paar Funktionen erweiter, so dass man direkt im Admininterface eigene Rassen, Einheiten, usw erstellen kann. Kann man das dann schon als Engine bezeichnen?

Versuchen wir doch mal deine Elemente kurz zu konzeptionieren

a) Benutzerverwaltung (Anmeldung, Login, Kennwort vergessen und der restliche Trulala)

Ich habe mir vor gut einem Jahr mal eine user.class geschrieben welche primär den Login verwaltet. Klasse kurz reinladen und schon hat man einen Login/Logout-System. Es wäre ne Sache von 10 Minuten in die Klasse ein paar Insert/Edit/Delete-Funktionen für die DB reinzuschreiben.
Fazit: Eine User-Klasse zur Verfügung zu stellen wäre ne Sache von nur ner halben Stunde

b) Nachrichtensystem

Ich gehe mal davon aus du meinst Private Messages zwischen den Spielern und kein Newsscript. Auch das ist ne Sache die man in 1-2 Stunden vollständig zusammenbasteln kann. Der Hauptaufwand ist da immernoch das erstellen des HTML-Formulars.
Eine kleine Klasse welche schaut ob neue Nachrichten vorhanden sind und die Nachrichten aus der DB ausliesst bzw. einträgt. Also ebenfalls kein Aufwand.

c) 2 dimensionale Karte (fällt bei Weltraum-Spielen raus, dort dann '3'-dimensionale Karte)

Hier kommt der erste große Schritt - wo sich auch meine Frage primär drauf bezog. Eine Kartenengine. Im Grunde ist es relativ einfach. Man nehme z.B. ein GIF-Bildchen, lese Pixel für Pixel den Farbwert aus und ersetze Ihn durch ein Isometrisches Geländebildchen. Dies macht man nun mit dem Gelände und der Vegetation. Nun muss man ne sparsame Schnittstelle finden wie man Einheiten und Gebäude ausliesst und zeigt sie auf dem selben Wege an. Im Grunde ist dies auch nicht das große Problem und es wird sicher mehr Zeit kosten die ganzen Bilder zu erstellen.
2D Karten.. Kann man genauso managen wie bei den Iso-Karten. Aber ganz ehrlich.. wahrscheinlich ist man dabei besser bedient wenn man die Karte gleich komplett zeichnet.
Hexfeld-Karten. Im Grunde ein ähnliches System nur das man die Felder versetzt darstellen muss.
3D-Karten.. also ganz ehrlich ich kenne keine 3D-Karten in BGs und kann folglich auch keine Aussagen dazu machen.. vielleicht erleutert die einer mal etwas genauer?

Bei allen Systemen muss man nun noch Dinge wie onclick-Aktionen mit einbinden welche durch Admins am besten per simpler include-Files bearbeiten lassen. Generell sollte alles per simplen inc-Files einstellen lassen. z.B. das der Farbwert #FF0000 durch ein Waldfeld-Bild ersetzt wird und das auf dem Farbwert #00FF00 (Wasser) z.B. keine Bewegung möglich ist.

d) Wegfindung für c)

Wegfindung ist sicher eines der komplexeren Systeme und ich habe hier auch noch kein Erfahrungen mit gemacht. Ihr?

e) Forschungsbaum

Dies sollte wenn auch als seperate Klasse arbeiten und nur ein Berechungstool darstellen. "Kann ich das Schwert erforschen, wenn ich noch kein Metall bearbeiten kann?" Ergebniss Nein. So in der Art halt simple Prüfungen welche Forschungen frei sind, genauso wie man dem Produktionsmenü sagt: Diese und diese Einheiten anzeigen.

f) Allgemeine Rohstoffverwaltung (Ein Warenkorbsystem, dem man Rohstoffe zugeben kann oder wegnehmen)

Dies ist schon ehr ein elementares System. Wobei man den Admins die Methode "Tick" (=Cronjob) oder Realtime (=fortlaufende Berechung der Produktionen). Tick per Cronjob ist ehr einfach und das Hauptproblem dürfte sein die einzelnen Berechnungen mit Wartezeiten zu trennen um den Server nicht zu überlasten.
Realtime mit einer "bei-Aufruf" Berechnung ist im Grunde auch nicht soo schwer. Man schaue wann letzte Aktuallisierung war und addiere dann pro Sekunde die Sekundenproduktion hinzu. Hier muss man dann wahrscheinlich viele Einstellungsmöglichkeiten bieten um z.B. einen Datenbankkollaps zu vermeiden wenn 4000 Spieler alle 3 Sekunden Ihre Ressourcen aktualliseren.

g) Ein internes Event-Message-System, das Spiel-Ereignisse verteilt (Kämpfe, Forschung fertig, Bau fertig)

Dies vermute ich ehr als schwer umsetzbar.. zumindest allgemein. Hier muss man sich auch ehr das Rohstoffsystem anlehnen.. oder was meint Ihr?

h) Ein System für fortlaufend wachsende Rohstoffe (à la OGame)

Ich spiele kein OGame.. was machen die da?

i) Einheitenverwaltung mit Bau

Wieder Rohstoffsystem...

j) Kampfsystem mit dynamisch austauschbaren Regeln

Hier könnte ich ja meine Wartec-Pläne mal wieder ausgraben. Wenn dann muss man jedenfalls ein umfangreiches Warscript zur Verfügung stellen welche auch mal Dinge wie Munitionsverbrauch, Durchschlagskraft, Panzerung und Co berücksichtigt (z.B. das man mit einem Karabiner keine Sherman-Panzerung durchschlagen kann und sich der Soldat folglich ein feindlichen Soldaten als Ziel sucht und den großen Panzer lieber der PAK überlässt)


... so was meint Ihr?

Zum Punkt j habe ich ein dynamisches Kampfsystem geschrieben, das ich in mehreren Projekten einsetze:

Es lässt alle Einheiten auf einer Seite auf die Einheiten auf andere Einheiten zufällig schießen. Dies ist glaub ich Stand bei den meisten Browsergames.

Der Programmierer muss dann nur noch die Kampfesregeln festlegen:
a) Welcher Spieler schießt gegen wen?
b) Wie stark ist der Verlust an Schild- und Strukturpunkten?
c) Kann der Angreifer noch einen Schuss abfeuern?
d) Wieviele Runden gibt es?
e) Ab wann ist eine Einheit zerstört?

Reingeschoben bekommt das Kampfskript im Prinzip folgendes:
Spieler 1 mit Kampftechnik 3 und 500 Einheiten X und 30 Einheiten Y
kämpft gegen
Spieler 2 mit Kampftechnik 5 und 800 Einheiten X und 130 Einheiten Y

Die obigen Regeln legen dann den Verlauf des Kampfes fest.

Herausbekommt man dann:
Runde 1:
- Spieler 1 hat noch 350 Einheiten X und 15 Einheiten Y
- Spieler 1 hat noch 650 Einheiten X und 5 Einheiten Y
Runde 2: etc

Die API ist unter folgenden Adressen downloadbar:
http://burnsystems.de/docs/BurnSystems.BGE.Fighting.chm
bzw
http://burnsystems.de/docs/fighting/


Zum Rohstoffsystem von OGame:

Rohstoffe werden fortlaufend produziert. Also wenn es heißt, dass 300 Eisen pro Minute produziert wird, dann hat der User nach 1 Sekunde 5 Eisen, nach 2 Sekunden 10, etc. Dies wird aber logischerweise nicht jede Sekunde verbucht, sondern nur, wenn die jeweilige Website aufgerufen wird (oder eine Aktion stattfindet). Dies ist konträr zum Ticksystem, bei dem Rohstoffe nur alle 15 Minuten aktualisiert werden. (Da fällt mir ein, du hast es ja schon bei f) beschrieben)

Ansonsten würde ich fast vorschlagen den Thread in mehrere Unterbereiche aufzuspalten.

Zu Punkt g)
Da habe ich einen TickEventHandler geschrieben, der Events vom Interface ITickEvent annimmt. Dort steht dann geschrieben, wann, wie oft und in welchem Interval eine beliebige Aktion ausgeführt wird. Der TickeventHandler ruft also ein Interface zu diesen Zeitpunkten auf. So etwas gibt es in jedem BG (mehr oder weniger) und kann damit verallgemeinert werden, da sich die einzelnen Events dort nur registrieren müssen.

Zu Punkt d)
Die Wegfindung lässt sich soweit verallgemeinern, dass der Programmierer nur noch Nodes und Connections festlegen muss.

Zum Thema Engine: Ich habe selbst eine Art "Engine", die komplett konfigurierbar ist durch das Admincenter und den MapEditor. Wenn das ganze noch etwas mehr Einstellungsmöglichkeiten bekommen würde, dann könnte man das auch sehr gut zum Download anbieten (was aber wohl kaum passieren wird, denk ich mal).

Das Spiel bietet z.b. im MapEditor die Erstellung der ganzen Welt an, inkl. aller NPCs und Events auf den einzelnen Tiles, die durch eigene Klassen erstellbar sind (z.b. $script->msg("Hallo"); oder $shop->addItem(5); usw. )

Weitere Informationen zur "Engine": og5.net Blog von wusch: Das Projekt Andechor: Ein Ausblick auf 2005/2006

Hey wusch,
wo habt ihr die grafik snippets her? die sehen sehr cool aus.

Eine engin zu bauen ist eine feine sache, aber andererseits geht es zum beispiel mir so, dass mein Spiel besonders werden soll und nicht wie ein retorten Spiel aus einem Bausatz entstehen soll...
Ich finds cool wenn ich wo nach Scripten suchen kann und das finde was ich brauche, aber einen Baukasten will ich wirklich nicht haben.

soviel zu meiner Meinung
reg4rds
Chojin

Original von Chojin
Hey wusch,
wo habt ihr die grafik snippets her? die sehen sehr cool aus.

Eine engin zu bauen ist eine feine sache, aber andererseits geht es zum beispiel mir so, dass mein Spiel besonders werden soll und nicht wie ein retorten Spiel aus einem Bausatz entstehen soll...
Ich finds cool wenn ich wo nach Scripten suchen kann und das finde was ich brauche, aber einen Baukasten will ich wirklich nicht haben.

soviel zu meiner Meinung
reg4rds
Chojin

Das werden wir immer wieder gefragt Und im Moment siehts so aus, dass wir recht viel selbst aus spielen (gba/snes) gerippt haben, aber manche Dinge auch selbst gezeichnet haben ( http://80.190.252.208/og5/files/1/btg.pa4.gif - Der Teleporter ist von uns (Ich weiß, dass er Stilmäßig nicht reinpasst, aber animiert sieht das Ding einfach nur geil aus ).

Original von Chojin
Eine engine zu bauen ist eine feine sache, aber andererseits geht es zum beispiel mir so, dass mein Spiel besonders werden soll und nicht wie ein retorten Spiel aus einem Bausatz entstehen soll...
Ich finds cool wenn ich wo nach Scripten suchen kann und das finde was ich brauche, aber einen Baukasten will ich wirklich nicht haben.

Das sehe ich genauso ...

Wenn jeder Hinz und Kunz mit einem Bausatz ein BG erstellen kann ... das ist ja wohl Masse statt Klasse!

Es gibt wahrlich schon genug Spiele wie OGame, mit so einem Bastelkit würdens nur noch mehr.
Wer braucht sowas?
Wer soll die spielen?
Was soll das bringen?

Original von Blabbo

Original von Chojin
Eine engine zu bauen ist eine feine sache, aber andererseits geht es zum beispiel mir so, dass mein Spiel besonders werden soll und nicht wie ein retorten Spiel aus einem Bausatz entstehen soll...
Ich finds cool wenn ich wo nach Scripten suchen kann und das finde was ich brauche, aber einen Baukasten will ich wirklich nicht haben.

Das sehe ich genauso ...

Wenn jeder Hinz und Kunz mit einem Bausatz ein BG erstellen kann ... das ist ja wohl Masse statt Klasse!

Es gibt wahrlich schon genug Spiele wie OGame, mit so einem Bastelkit würdens nur noch mehr.
Wer braucht sowas?
Wer soll die spielen?
Was soll das bringen?

Es wäre insofern schön, weil man so kommerziellen Spielen die User abnehmen könnte, wenn man diese Codes unter die GPL setzt und kommerzielle Nutzung untersagt.

Außerdem kann man sich mit einer umfangreichen Bibliothek um die wirklichen Features eines Browsergames kümmern und nicht erst das 300ste Login-Skript basteln.

Daher würde ich eine BG-Bibliothek begrüßen.
Ob GPL oder LGPL soll erstmal keine Rolle spielen. Ich persönlich würde niemals unter der GPL programmieren, aber das soll ja auch kein Einfluss in die Diskussion finden, was man alles abstrahieren könnte.

Grundsatz 1:
eine aufwendige grafische Gestaltung benötigt zwingend JavaScript einsatz (Immer Reload ist schlechte Usabililty und schränkt ein; Flash und java haben nach mehreren Jahren Durchbruch in BG Szene nicht geschaft)

Grundsatz 2:
eine aufwendige grafische Gestaltung benötigt massives Caching und Logik auf Client- Seite (Grafik- Operationen wie Wegfindung sind extrem; Bandbreitenanforderungen ebenso).

Daraus lässt sich ableiten:
Das ganze muss ein Framework sein, welches AJAX, sonstige Push oder Pull Technologien vereinigt unter einem direkt in Javascript ansprechbaren Framework.

Und so würd ich das ganze definieren:
Schicht 1:
- Erstellen von Datenbankdefinition
- Automatisches Generieren von Datenbank / generischer DB Zugriff. Benötigt für übergeordnete Schichten
=> 500 - 1000 Zeilen; 15 Stunden

Schicht 2.a:
- "Stored-Procedure / Trigger" Ebene.
- Verhindert, dass jemand unberechtigt Daten sehen kann.
- Möglichkeit die Logik streng an die Daten zu kapseln. Ziel: Qualitätssicherung
=> 500 Zeilen; 20 - 30 Stunden

Schicht 2.b:
- Event Handler & Messaging System
- Abbonieren von Views / Stored Procedures, Datensätzen.
- Anbindung dieser an Benutzer / Gruppen. Weiterleitung an die jeweils richtigen Nutzer. Dient dazu, dass einheitlich Notifications oder Zeitgesteuerte Ereignisse ausgelöst werden.
=> 500 Zeilen: 50 - 100 Stunden

Schicht 3:
- Ajax / Push / Pull Kommunikation. Facade zwischen Schicht 2 / Client.
- Sicherung der Datenübertragung. Sehr viel Mapping, Typenumwandlung, ...
=> 200 - 300 Zeilen: 10 Stunden

--- Systemgrenze ---

Client S 4:
- Schnittstelle zu Schicht 2A. Schicht empfängt via Schicht 2A daten. Via 2B werden änderungne dieser an 4 gesendet.
- Aufrechterhalten der Schnittstelle. Bietet Zugriff auf Stored Procedures, Views, Tabellen.
=> 1000 bis 2000 zeilen; 200 Stunden

Client S 5:
- JavaScript Darstellungs- Framework für JavaScript
- übernimmt Darstellung von Tabellen, Views, einzelnen Records
=> 2000 Zeilen; 50 - 100 Stunden

Client S6:
- eigentliches BrowserGame:
=> Ca. 20 bis 30 Stunden Aufwand

Fazit: Du must meines Erachtens die Tabellen auf den Client ziehen. Plus als 2. wichtiges ein Framework haben, welches dir Tabellen darstellt.
dann kannst nur noch sagen: Da seh ich View XY; schon ist die Ressourcen- Anzeige immer aktuell.

Das was du ansprichst wäre dann in S5: Sprich Wrapper für Relationale Daten in Daten im Sinne von Hexagon Maps. Dies ist praktisch kein Aufwand mehr, wenn du erst mal direkten Zugriff auf die Daten hast.

Problem der Sache: Du investierst vorerst schnell mal 500 Stunden. -> Hast du diese zeit? Wenn du das investiert hast, baust du dir jedes BG mit sehr wenig Aufwand in sehr kurzer Zeit. Sind noch std. Wraper für Karten da; so braucht auch das keine Zeit mehr.
Ah ja: Schicht 1 bis 5 können für beliebigste BGs verwendet werden.
Das einzige wass für ein neues BG getan werden muss ist:
- anpassen Tabellendefinition
- Schicht 6 Coden; was kein Aufwand bedeutet

gruss

also ich würde aus der gfanzen Geschichte ne Opensourcesache machen. weil 500 Stunden alleine sind vieeeeel Zeit, und wenn das mehrerer machen, geht das schon eher

Vielleicht ein mehr oder weniger interessanter Link dazu...

http://www.enjoy-dialogs.com/onlinegameengine.htm

als open-source Ding wengistens ein ansatz!?

Da gibts nur ein Problem was die Sache für die meisten BG-Entwickler als ziehmlich nutzlos macht..

Eingesetzte Produkte:

- .NET Framework 1.1
- Microsoft Windows 2003 Server
- Internet Information Server 6
- WebServices
- Microsoft SQL Server 2000

Das sind die aktuell eingesetzten Komponenten. D.h. nicht dass es dabei bleiben muss.
Im Prinzip ist mir egal welche Datenbank oder Dateisystem, welches Betriebssystem oder welches der einzelnen Module eingesetzt wird.
Das Ding sollte / ist schon so flexibel, dass man jederzeit (auch im laufenden Betrieb) einzelne Teile ersetzen, selbst machen oder gar nicht nutzen kann.

Ich wollte jetzt (zumindest hier und jetzt) keine Technologie-Diskussion führen, eigentlich dachte ich es gehe grundsätzlich um das (etwas theoretischen Thema) BG-Engine?

Ich will jetzt nicht meckern, aber ich verstehe eigentlich nicht, was daran jetzt so verkompliziert wird.

Es könnte doch einfach mal jemand anfangen und seine User/Auth-Verwaltung zur Verfügung/Diskussion stellen.

Das wäre doch schonmal der erste wichtige Schritt, das erste Modul.
Ich will hier jetzt niemanden zwingen, seinen Code rauszurücken, aber scheinbar sind ja mehrere Leute interessiert an so einer Gemeinschaftsaktion, und wenn keiner bereit ist, dafür was beizusteuern, dann wirds ja nie was?!

So ein System könnte man ... wäre es mal für alle zugänglich, dann ja diskutieren, Schwächen und Sicherheitslücken ausbügeln und alle hätten nen Lerneffekt und nachher wäre die Basis für die restliche BG-Engine schonmal geschaffen.

Wenn das jetzt Blödsinn war, berichtigt mich

@Blabbo: Ja, im Prinzip hast du vollkommen recht.
Erster Schritt wäre wohl, dass jemand seine tolle Auth.-Funktionen veröffentlicht.

Doch ehrlich gesagt ist, dass auch schon wieder ein alter Hut, den ich in jeder Comput-BILD hinterhergeworfen kriege.

Also braucht es doch schon ein bischen mehr.
Wie wäre es - und jetzt fange ich einfach einbischen an aus der Hüfte zu schiessen - wenn ich Dir nicht nur meine Authentifizierungsfunktionen (samt Passwortverschlüsselung, EMail-Validierung am MX-Host, Loggin-Protokoll, usw.) zur verfügung stellen würde, sondern auch noch die dazu passende Datenbank. Also nicht nur das Script für die jeweiligen STOPs und Tabellen, sondern eine schöne performante Oracle-DB (um auch mal vom MS SQL Server wegzukommen)

Einziger Nachteil - und hier wird es wohl für manchen Kritisch - die Benutzerdaten liegen (wenn auch verschlüsselt) auf meinem Servern oder auf dem Server des jeweiligen Anbieters.

Wer dies nutzen möchte für den könnte dies eine echter Vorteil sein.
Und jetzt war das Beispiel Authentifizierung ja nur eines von vielen, der bereits angesprochenen Themen.
Ich denke da sind gute Ansätze dabei, auch wenn man nicht alles für jedes Spiel nutzen kann, aber so einen kleinsten gemeinsammen Nenner als Ausgangsbasis für neue BGs wäre durchaus sinnvoll.

Original von ChrisM
http://www.enjoy-dialogs.com/onlinegameengine.htm
als open-source Ding wengistens ein ansatz!?

Von Open Source steht auf der Seite doch überhaupt nichts.

Stattdessen aber:

Online.Game.Engine ist funktionell und preislich auf diese Entwicklerteams angepasst.

Wie sieht also das Lizenzmodell aus?

Original von ChrisM
Einziger Nachteil - und hier wird es wohl für manchen Kritisch - die Benutzerdaten liegen (wenn auch verschlüsselt) auf meinem Servern oder auf dem Server des jeweiligen Anbieters.

Also wäre jeder, der das System nutzt, von deinem Server abhängig.
Ich glaube nicht, dass das der Sinn eines solchen BG-Kits sein kann.

Auch auf Oracle sollte imo verzichtet werden.
Schliesslich soll das System für möglichst viele Leute nutzbar sein (soll es doch?!), deswegen halte ich es für das sinnvollste, die gängigsten Systeme zu verwenden, also MySQL.

@BLUESCREEN: Naja, lassen wir auch diesen Satz vielleicht erst einmal aussen vor. Ich möchte das Ding schon als open-source anbieten, oder zumindest in irgendeiner dieser Formen von os. (Das wäre auch mal ein schönes Thema für einen neuen Thread: Welche public license passt zu mir?)

@Blabbo:
... oder meinetwegen auch für MySql, Postgress, Gupta, mSql, ... (fällt mir sonst noch eine ein?) Das wäre hier auch nur eine weitere DataSource für den ganzen Rest.

Dein Einwand das man dann von meinen Server abhängig wäre, stimmt, aber:
erstens soll dies ein reines Service-Angebot sein und zweitens soll die Engine ja auch - siehe oben - zur eigenen Verwendung zur Verfügung stehen. Also kann man sich das Ding runterladen, installieren, (meinetwegen einen fehlenden Lotus Notes-DB-Treiber erstellen) und selbst seinen Chat, sein Forum und natürlich die vielen eigenen Spiele, die man ja betreibt, gegen diese Engine authentifizieren lassen.

Aber Achtung: auch hier wieder nur das Beispiel Anmeldung, Login. Natürlich kann man auch bei seiner eigenen Anmeldung (die man vielleicht schon entwickelt hat) bleiben und nur die Pathfinding-Routingen verwenden oder die Funktionen zur Verwaltung von 2D oder 3D Karten (Hexadezimal, Vierecke, Endlos, oder nicht, oder sonst wie) verwenden.

Nochmal: Ich möchte hier in eine Diskussion einsteigen und nicht meine Lösung präsentieren. Der einzige Grund warum ich hier auf die OGE verwiesen habe ist der eine Diskussionsgrundlage zu bieten. (obwohl die Beiträge in diesem Thread ja auch schon sehr gut waren)

ChrisM man sollte dir aber auch sagen, dass die wenigstens BG-Teams mit Windows-Servern arbeiten.. und die Aussage "(um auch mal vom MS SQL Server wegzukommen)" ist insofern komplett falsch, da die meisten hier MySQL verwenden..

Ich muss dich hier wirklich vorwarnen.. das ganze wird nen Flop wenn du das ganze auf Windows auslegst und dann als Notlösung ne Linux-Version davon rausbringst.

Vielleicht wäre ja auch ein Ansatz denkbar, wie er bspw. unter civ.idc.cs.chalmers.se/projects/gamepatterns/ praktiziert wird.

Eine Sammlung von Browsergame Patterns, also so was wie Best Practices und das angereichert mit ein paar Code-Beispielen.
Dabei würden wir uns aber wohl vom Thema Engine wieder entfernen.

@mudder: Danke für den Hinweis, wäre mir nicht aufgefallen. Nein, Spass beiseite. Das weiss ich natürlich. Und nochmal: Ich möchte hier aber wirklich keine Diskussion anfangen, was besser oder schlechter ist. Die dort vorgestellte Lösung ist die, die ich momentan verwende, ohne damit jetzt gleich die Welt der BG-Programmierung revolutionieren zu wollen.

Mir geht es nicht um das dort vorgestellte konkrete System und dessen Umsetzung, sondern um die Diskussion über was soll eine solche Engine können, was wäre schick, was überhaupt zu machen und nicht wie der Code aussieht oder wer das programmiert und womit.

Schicht 2.b:
- Event Handler & Messaging System
- Abbonieren von Views / Stored Procedures, Datensätzen.
- Anbindung dieser an Benutzer / Gruppen. Weiterleitung an die jeweils richtigen Nutzer. Dient dazu, dass einheitlich Notifications oder Zeitgesteuerte Ereignisse ausgelöst werden.
=> 500 Zeilen: 50 - 100 Stunden

Was hat Event handler mit messaging zu tun?
Event Handler:
Speichert eine "SQL prozedur" (z.B. mine A fertig) und einen Timestamp ( z.B. am 2.9.2005 um 23:34:21).
Beim Aufruf jeder Seite schaut der Event-Handler ob noch gespeicherte prozeduren vorliegen mit einem timestamp <= jetzt, ordnet diese der Zeit nach und führt alle aus der Reihe nach.
Desweiteren kann man eigentlich Objekte serializieren und in der Datenbank speichern, was wohl besser ist als rohen SQL zu speichern.

Original von Hagbard

Beim Aufruf jeder Seite schaut der Event-Handler ob noch gespeicherte prozeduren vorliegen mit einem timestamp <= jetzt, ordnet diese der Zeit nach und führt alle aus der Reihe nach.

Aber vorsicht. Was tun, wenn man dann wirklich nur einmal 1000 User hat, von denen jeder 10 Aufträge einsendet, die abzuarbeiten wären.
Beim (bzw. vor) Ausgeben der Seite können keine 100 Aufträge gleichzeitig abgearbeit werden und im schlimmsten Fall 100 DB-Aufrufe stattfinden.
Hier ist es schon besser, wenn die Abarbeitung und die Benachrichtigung über die Fertigstellung in einem vollkommen separatem Thread (am besten separatem Server) ablaufen.

Original von Hagbard

Desweiteren kann man eigentlich Objekte serializieren und in der Datenbank speichern, was wohl besser ist als rohen SQL zu speichern.
Voll Zustimmung: Gerade weil wir hier ja auch von einer Engine sprechen und sich damit die Struktur der Objekte auch von Projekt zu Projekt unterscheiden würden macht es wohl keinen Sinn mehr mit Platzhalter-Spalten in der DB zu arbeiten. Hier wäre es wirklich besser mit serzialsierten Objekten zu arbeiten. Zur Not könnte man diese dann ja auch im Dateisystem speichern (also auch komplett ohne DB).
Allerdings hat dies auch den Nachteil das Laden und Deserialisieren auch wieder (wertvolle) Zeit kostet.
Deshalb ist dann ein gutes Caching notwendig. Ausserdem muss sich die Engine selbst darum kümmern, wann (in einem separatem Thread) Objekte gespeichert werden und ob sie überhaupt erneut gespeichert werden müssen (Dirty-State)

usw.