Fragen zur Spieleprogrammierung (Verbindung von (C++) Code mit SQL Datenbank)

[smaradey]

Hallo

Ich habe vor ein Spiel zu programmieren.

allgemeine Vorstellung/Hintergrundinformationen:

Ich spreche hierbei von einem Spiel einer etwas größeren Dimension. Also keine App, kein Flash oder anderes Mini-Game.
Es soll sich später mal um ein multiplayerfähiges clientbasiertes Onlinegame handeln.

Ich habe bereits schon 2 kleinere Spiele(2D-Grafik) entwickelt. Und zwar:
ein Kartenspiel (Delphi, keine OOP, naive KI)
und eine abgewandelte Version von Schach. (Java, inkl. OOP, spielbar im Netzwerk/über Internet, intelligente KI)

Jetzt habe ich vor das ganze auf eine neue Stufe zu bringen.

Allgemeine Beschreibung des Spiels: Mehrere Spieler können sich in einer 3D-Welt bewegen und Aktionen durchführen. Also z.B. gegeneinander kämpfen, handeln oder whatever. Vergleichbar sind Spiele wie BF3, GW2 oder ähnliches.

Mir ist natürlich klar, dass ich es nicht schaffen werde so ein komplexes Spiel wie z.B. GW2 komplett alleine zu programmieren.
Ich ziele vor allem darauf ab mir Kenntnisse darüber zu verschaffen, wie ich überhaupt vorgehen müsste, um so ein Ziel zu erreichen, um dann zumindest eine Mini-Version von so einem Spiel zu erstellen. Also ein Spieler kann dann anfangs ruhig als ein Klotz dargestellt werden. Und Kämpfe könnten dann auch erstmal ein simples Schere-Stein-Papier-Match via Chat sein.

Genug Vorspiel^^, hier meine Fragen:

1) Programmiersprachen

• Warum wird z.B. C++ von allen immer als die Sprache angesehen mit der Spiele programmiert werden sollten.
• Inwiefern sollte man wann Java/C#/C/C++ nehmen, um welche Spiele zu erstellen?

2) OOP in Verbindung mit Datenbanken

Ich habe bereits bei Websiten und anderen Spielen gesehen, dass diese über Datenbanken realisiert werden. Also wenn zum Beispiel ein neuer Account angelegt werden soll, dann wird in der SQL-Datenbank ein neuer Eintrag erstellt bei dem dann Dinge, wie Account-Nr, Account-Name, ... eingefügt werden.

Mir ist hierbei insbesondere der Zusammenhang zwischen meinem objekt-orientiert-geschriebenen (C++)-Code und einer entsprechenden Datenbank nicht schlüssig.


Bei meinen bisher entwickelten Spielen habe ich noch keinen Wert darauf gelegt, dass man sein Spiel speichern kann. Im Wesentlichen war es mir wichtig, das ich Spiellogik und Aussehen gestalten konnte. Allerdings ist mir damals schon aufgefallen, dass es bei der Speicherung zu sehr vielen Problematiken kommen kann.
Speziell, das man vergessen könnte Datensätze zu speichern, da man auf Grund der vielen erstellten Objekte durcheinander gekommen sein könnte.

Ich weiß durchaus, dass eine Datenbank an sich nur ein Speicher ist, deren Inhalt ausgelesen und manipuliert werden kann, so wie es einem gerade gefällt und vor allem werden die Änderungen auch direkt gespeichert.
Eine Datenbank ist quasi das, was ich brauche, um effektiv Daten von (mehreren) Spielern live zu bearbeiten - das ist mir bewusst.


Um jetzt auf meine eigentliche Frage zurück zu kommen:

• Wie verbinde ich meinen Code mit einer SQL-Datenbank? (also wie hängt OOP mit Datenbanken zusammen?)

Oder um es anders zu formulieren: Ich kann mir momentan noch nicht genau vorstellen, wie die genaue Referenzierung zwischen einzelnen Objekten und Datenbank-Inhalten gestaltet werden soll.

Also wie läuft das dann ab:

1. Designe ich mein Spiel im objekt-orientierten Stil und setze die Werte der Objekte dann immer den Werten aus der Datenbank gleich, um damit effektiv arbeiten zu können?
2. Oder lässt man den objekt-orientierten Stil, so wie man ihn ohne Datenbanken kennt einfach komplett fallen und arbeitet nur noch direkt an Datenbanken?

Ich hoffe ich konnte das Problem auf den Punkt bringen

3) Verbindung einer Grafik-Engine mit dem Spiel

Während ich bei 2D-Spielen einfach ein Bild erstellt habe und dies dann ziemlich einfach in meinem Fenster anzeigen lassen konnte, stellen sich mir bei einem 3D-Spiel ganz andere Probleme.

Ich habe vor mein Spiel mit einer Grafik-Engine darstellen zu lassen. Dabei habe ich bisher herausgefunden, dass eine Grafik-Engine im Wesentlichen die Objekte für mich rendert, so dass z.B. Sonneneinstrahlung/ Wind usw. berücksichtigt werden können. Es handelt sich quasi um eine Schnittstelle auf die ich zugreifen kann.

Mein Frage:

• Wie verbinde ich eine Grafik-Engine mit meinem Code?
• Wie kann ich Gegenstände in Bezug auf Gestalt, Position in der Welt via meinem Code verändern?

4) Netzwerkfähigkeit / allgemeine Spielmodellierung

Im Wesentlichen weiß ich, dass es immer genau einen Host gibt und mehrere Clients.

Der Host besitzt also die Spiellogik und die Datenbank.

Die Clients müssen dann entsprechend der Spiellogik handeln, die vom Host vorgegeben wurde. Die Clients besitzen dann die Datei zum Starten des Spiels, Texturen, 3D-Objekte, Musik usw.

Meine Fragen:

• Muss ein Client die komplette Spiellogik enthalten oder enthält er wirklich nur die Startdatei? Wie sieht es dann z.B. bezüglich der Steuerung aus?
• Wie wird so eine Host-Client - Modell erstellt?
• Inwiefern muss ich Ports freigeben und wann?
• Was sollte ein typischer Host/Client alles besitzen?

5) Sicherheit, Datenschutz

Ich habe leider viel zu oft erlebt, wie schnell es geht, dass Server abgeschossen werden.
Oder das Leute permanent im Spiel cheaten.

Meine Fragen:

• Wie schütze ich meinen Server auf dem dann später das Spiel läuft, so dass das Server nicht überlastet wird und dann down geht? (z.B. auf Grund von zu viele Paketversendungen, DOS-Angriffe, Spam-Bots)
• Wie schütze ich mein Spiel vor Einflüssen von Drittprogrammen, wie der Cheat-Engine? ( so dass sich kein Spieler einen Vorteil cheaten kann?)
• Wie schütze ich Login-Daten von Usern, so dass sie nicht von Dritten oder allgemein ausgelesen werden können?

6) Verbindung von Website und Spiel / Realisierung von Registrierungen neuer Accounts

Im Endeffekt soll das Spiel dann später über eine Website erreichbar sein. Ein Account kann dann via der Website erstellt werden und muss dann in der Spieledatenbank auftauchen.

• Werden solche Registrierungen dann über 2 Datenbanken gehandlet, also eine für die Website und den Website-Bereich und dann eine weitere separate Datenbank für das Spiel?
• Oder existiert nur eine einzige Datenbank, die dann Website und Spiel vereint?

(Ich vermute 2 Datenbanken)


abschließende Bemerkungen:

Danke für das Durchlesen und jede kommende Antwort! Ich bin über jeden Link zu einem entsprechenden Tutorial oder jeglicher helfenden Website dankbar.

Ich hoffe ich konnte meine Probleme auf den Punkt bringen und verständlich darstellen

Liebe Grüße

 

[Tumbleweed]

zu 1)
Hat sich nunmal über viele Jahre hinweg etabliert und ist objektorientiert verwendbar, was für Spiele sehr nützlich ist.

Ob du Java, C# oder C++ nimmst ist in erster Linie Geschmackssache. Es gibt Engines und Frameworks für alle 3. Zu C kann ich dir nichts sagen, aber wie gesagt, ich stelle mir Spieleprogrammierung ohne OO sehr anstrengend vor.

zu 2)
In Java stellst du Datenbankverbindungen hauptsächlich per JDBC her. Dann steht es dir offen, ob du direkt SQL statements verfasst und ausführst oder ob du ein ORM-Framework wie z.B. Hibernate verwendest. Für Spiele würde ich aus Performance-Gründen zu ersterem raten.

Und du schreibst nicht ständig in die Datenbank, das wäre nicht sonderlich performant. Es hängt natürlich vom Spiel ab, aber für gewöhnlich passiert viel im Arbeitsspeicher und nur gelegentlich werden einige Daten persistiert, sei es in Intervallen oder nur beim Beenden/Speichern.

zu 3)
Ob dein bestehender Code halbwegs sinnvoll mit einer Engine verbunden werden kann, hängt davon ab, wie modular die bestehende Architektur ist. Da du eher unerfahren wirkst, wird das vermutlich nichts. Du wirst zwar hier und da Logik-Schnipsel übernehmen können, aber in erster Linie wirst du Engine-konformen Code neu schreiben müssen. Je nach Engine wird sogar nur geskriptet (z.B. UDK).

zu 4)
Alles kann, nichts muss. Bei der Unreal-Engine geschieht, wenn ich mich recht erinnere, sowohl auf Client als auch auf dem Server einiges und es wird zwischendurch nur abgeglichen (replizieren der Geschehnisse), ob alle "Spielzüge" quasi "legal" waren. Der Server ist dabei natürlich Chef.
Umso mehr du auf dem Server halten kannst, umso sicherer ist das natürlich, aber es erhöht die Abhängigkeit der Clients, d.h. wenn der Server nicht gut genug performt, warten die Clients (lag).

zu 5)
Hab ich quasi in 4 schon erläutert. Und IT-Sicherheit ist eine Wissenschaft für sich. Da hilft nur lernen lernen lernen. Google z.B. mal OWASP.

zu 6)
Geht sowohl als auch.

Viel Spaß mit den Stichwörtern.

 

[andy_0]

1) C++ ist eine sehr schnelle Sprache und sehr mächtig. Man kann die Aufgaben durch die relative Hardwarenähe Effizienz lösen. "Entkoppelte" Sprachen wie Java und .NET Sprachen (z.B. C#) sind zwar architekturunabhängig, was aber seinen Preis hat. Durch die Zwischensprache, in die diese Sprachen zuerst kompilieren, wird es viel langsamer. In Java kann man außerdem die Ressourcenverwaltung kaum/nicht selber steuern, weswegen Java auch so viel RAM frisst.
2) OOP hat gar nichts mit einer SQL Datenbank zu tun. Es gibt zwar OOP Datenbanken, aber das ist etwas sehr spezielles. Damit kann man z.B. OOP Typen aus OOP Sprachen direkt in der Datenbank speichern. Sowas ist aber eher "Spielerei" mit SQL macht man nichts falsch. Ob man aber wirklich Zugriff auf eine SQL Datenbank benötigt, lasse ich mal dahin gestellt. Spiele speichern häufig in Textdateien oder ähnliches.
In einer Datenbank arbeitet man übrigens "nie", sie dient nur zur Datenspeicherung (z.B. für einen Onlineshop die Kunden, die Artikel die verkauft werden, Preise, wer die Artikel liefert und die ganzen Verknüpfungen z.B. welcher Kunde was, wann gekauft hat etc.) und die Abfrage dieser Daten.
OOP hat auch nichts mit der Leistungsfähigkeit einer Anwendung zu tun. Mit OOP kann man gewisse Sachen gut umsetzen, teilweise sehr komplexe Anwendungen halbwegs strukturieren. Es ist aber nicht notwendig, man kann auch rein strukturiert (wie Skriptsprachen) vorgehen. Man kann mit OOP Sprachen auch nur strukturiert d.h. ohne OOP vorgehen.
4) Es gibt viele Arten etwas zu bauen. Man könnte z.B. in die Startdatei nur einen Launcher initialisieren, welcher anschließen einen grundlegenden Client über das Netzwerk lädt. Dieser Client könnte dann "komplett" sein oder nur eine Schnittstelle für einen Server, wo die gesamte Logik abläuft (Client/Server Anwendung mit quasi only server side processing). Man kann es so bauen, man kann aber auch alles gleich in einen Client bauen (Client Anwendung).
5) Solch ein Schutz hängt davon ab, was du schützen willst. Vor Überlastung verwendet man z.B. sog. Load Balancer, vor Cheating hilft nur guter Code, der eben keine "Schwachstellen" hat. Der Schutz von Dateien vor Dritter ist generell so eingestzt, dass nur derjenige Zugriff auf die Daten hat, die er zwingend benötigt. Greifst du maschinell auf Dateien zu, dann sollte man das möglichst stark limitieren und spezielle Angriffsverktoren wie z.B. SQL Injection verhindern.
6) Das kommt drauf an wie du das bauen möchtest und wie stark verzahnt alles sein soll. Du kannst zwei Datenbanken verwenden, was für 5) sehr sinnvoll erscheint. Du kannst aber trotz allem die Logindaten für die Webseite auf Basis der Spieleaccounts in der Spieledatenbank realisieren.

Viele deiner Fragen sind sehr genereller Natur. Da im Detail zu antworten, wäre sehr müßig. Ich empfehle dir da dringend dich mehr zu informieren, für jeder der Fragen kann man ganze Bücher schreiben (oder lesen ).

 

[Yuuri]

Ich hab zwar schon ein wenig auf deinen Post geantwortet... Aber dann alles gelöscht, aus einem Grund: Befasse dich erstmal mit simplen Tutorials über Programmierung (speziell OOP, Datenbanken, Netzwerktechnik u.ä. von dir Gefragtes). Viele deiner Fragen sind einfach durch simple Tutorials und ein wenig Erfahrung schnell beantwortet und diese werden auch in Spieletutorials erklärt (zwar etwas stumpf aber man sollte den Sinn und die Arbeitsweise dahinter erkennen können). Statt hier alles aufzurollen wäre es wohl besser, wenn du entsprechende Vorkenntnis besitzt, bevor wir hier alles drölf mal von vorn erklären.

 

[New_Escaflowne]

Ich kann mich Yuuri nur anschließen.

Meiner Meinung nach denkst du im Moment noch in zu großen Dimensionen bei deinem Spiel ohne grundlegende Kenntnisse zu haben. Befass dich erstmal einzeln mit den verschiedenen Themen.

Einige Anmerkungen:
Für Datenbanken mit C++ dürfte ODBC möglich sein und wahrscheinlich gibt es auch Frameworks wie in Java.
Befass dich erstmal damit, wie man eine Datenbank strukturiert und modelliert und dann mach ein Beispielprojekt, um das Arbeiten mit der DB zu üben.

Netzwerkprogrammierung:
Befasse dich mit den Grundlagen von verteiltem Programmieren (Client-Server-Modell, ISO/OSI bzw. TCP/IP-Modell) und mach Beispiele.

Sicherheit:
Verschlüsselung, nur Hashes mit Salt speichern, Zugriff limitieren etc. Gute Sicherheit als Laie ist praktisch unmöglich.

 

[Mortal]

1) Nimm Java, .Net oder irgend eine Skriptsprache die sind einfacher zu Debuggen und du wirst insgesamt schneller Fortschritte erzielen ... die Leistung reicht auch für alles was nicht AAA ist.
2) Stell das erstmal hinten an - programmiere ein Echtzeit 2D Spiel, bisher hast du ja nur Zug basiertes programmiert bei Echtzeitspielen wirst du eine Menge lernen und die Frage wird sich dir so nicht mehr stellen.

Die Restlichen Fragen brauchst du dir im Prinzip zunächst garnicht Stellen, vieles davon wird sich aus der Erfahrung deines ersten Echtzeitspiels ergeben ... abgesehen vielleicht von dem Sicherheitsaspekt aber wie bereits geschrieben das ist ein großer Brocken...

 

[Krik]

Junge, Junge, das ist mal ein umfangreicher Post!

Ich gehe die Fragen mal von oben nach unten durch.

1) Programmiersprachen

• Warum wird z.B. C++ von allen immer als die Sprache angesehen mit der Spiele programmiert werden sollten.
• Inwiefern sollte man wann Java/C#/C/C++ nehmen, um welche Spiele zu erstellen?

Grafikengines müssen sehr effizient und flexibel sein. Um das zu erreichen, eignen sich eigentlich nur recht Hardware-nahe Sprachen, die wiederum gewisse Abstrakstionsfähigkeiten bieten müssen. C++ hat das alles. Andere Sprachen ermöglichen das bisher nur mit gewissen Abstrichen. C beispielsweise bietet keine Objektorientierung, wäre aber ansonsten genauso geeignet. Java hingegen bietet die erforderliche Flexibilität, kommt aber in Sachen Geschwindigkeit nicht so gut hinterher aufgrund der fehlenden Hardware-Nähe.
Weiterhin sind die deutliche Mehrheit aller für Spiele relevanten Bibliotheken in C++ geschrieben und für den Einsatz mit C++ designt. Mit anderen Sprachen ist ein Zugriff darauf auch möglich, erfordert aber oft den Einsatz von Wrappern oder Verrenkungen.
Und auch weil sich dieses Ökosystem um C++ herum entwickelt hat, greift man üblicherweise zu dieser Sprache.

Andere Sprachen werden als "Hilfssprachen" eingesetzt. ZB Unity bietet eine C#-Schnittstelle an, um die Spiellogik schreiben zu können. Oft werden aber Skriptsprachen wie LUA oder auch eigene Entwicklungen dafür verwendet. Der Hauptgrund für die letzteren dürfte sein, dass diese Sprachen relativ leicht zu erlernen sind. Wichtig für die "Hilfssprachen" sind eine hohe Abstraktraktionsfähigkeit. Im Prinzip kann man hier aber auch wieder C++ nehmen. Das ist aber auch deutlich komplexer - etwas, was hier oft einfach nicht benötigt wird.

Für eigene "kleine" Projekte kannst du aber ohne Probleme Sprachen verwenden, die du schon kennst. C++ lernt man leider nicht "mal eben so". Man kann es jahrelang lernen, und dann immer noch Wege finden, wie man etwas effizienter umsetzen kann.

2) OOP in Verbindung mit Datenbanken

• Wie verbinde ich meinen Code mit einer SQL-Datenbank? (also wie hängt OOP mit Datenbanken zusammen?)

1. Designe ich mein Spiel im objekt-orientierten Stil und setze die Werte der Objekte dann immer den Werten aus der Datenbank gleich, um damit effektiv arbeiten zu können?
2. Oder lässt man den objekt-orientierten Stil, so wie man ihn ohne Datenbanken kennt einfach komplett fallen und arbeitet nur noch direkt an Datenbanken?

Ich kenne es so, dass man Value Objects verwendet. Das sind eigentlich nur Objekte, die Parameter vorhalten, aber keine wesentliche Logik enthalten. An diesen Value Objekts hängt irgendeine Form von Persistenzmodul, dass sich darum kümmert, dass Änderungen an diesen Daten mit der Datenbank abgeglichen werden. Dafür gibt es einige Frameworks, die sich nur darum kümmern. Beispiele sind JDBC, ODBC und natürlich Eigenentwicklungen. Teils können die Frameworks auch automatisch je nach DB-Schema passende Value Objects erstellen und umgekehrt.
Auf der anderen Seite hängt deine Spiellogik ebenfalls an diesen Daten (ist ja klar).

Eine wesentliche (wenn nicht die wesentlichste) Frage ist allerdings, wie man die Datenänderungen zwischen Client und Server synchronisiert. Die Leitung ist ja nicht unendlich dick. Man muss schon genau schauen, was man wirklich übertragen will.

3) Verbindung einer Grafik-Engine mit dem Spiel

• Wie verbinde ich eine Grafik-Engine mit meinem Code?
• Wie kann ich Gegenstände in Bezug auf Gestalt, Position in der Welt via meinem Code verändern?

Eine Grafik-Engine liegt normalerweise als Bibliothek vor, d. h. da gibt es eine API, auf die du zugreifen kannst und über die du Anweisungen an die Engine schicken und den Status und ggfs. Zwischenergebnisse abrufen kannst.

Es ist dabei durchaus normal, dass die Grafik-Engine in einem anderen Thread als die Spiellogik läuft. Ein gewichtiger Punkt ist also, wie man die Kommunikation zwischen den Threads realisiert. Bei den fortgeschrittenen Engines ist da aber normalerweise schon was bei, sodass man daran keinen Gedanken verschwenden muss.

Allgemein ist es so, dass du Game Objects bzw. Entitys hast, die für etwas Sichtbares stehen. Sie beinhalten einmal die Darstellung (also was der Spieler am Ende davon auf dem Bildschirm sieht) als auch die damit verbundene Logik (Methoden zur Beeinflussung und natürlich Eigenschaften). Die Grundlage für Entitys sind die Value Objects, von denen ich weiter oben geschrieben habe.

Meist ist es so, dass der Grafik-Engine alle benötigten Daten (Polygone, Texturen, Shader, Position, Ausrichtung und anderes) übergeben wird. Diese "merkt" sich die Engine und füttert entsprechend automatisiert die Grafikkarte damit. Wenn sich irgendetwas ändert, dann muss man die Engine über die Änderung informieren, damit das geänderte Entity ab dem nächsten Frame auch entsprechend dargestellt wird. Und ja, bei vielen Objekten kann das Informieren eine Heidenarbeit sein. Es gibt normalerweise eine Reihe von Objekten und Funktionen, die einem dabei helfen. Ein Beispiel wären Quaternion-Objekte, die die Ausrichtung von etwas definieren. Denen sagt man nur so was wie: "X-Achse +20°, Y-Achse -30°", dann rechnet das Ding das auf die vorhandene Ausrichtung drauf und schließlich so um, dass die Engine damit etwas anfangen kann.

4) Netzwerkfähigkeit / allgemeine Spielmodellierung

• Muss ein Client die komplette Spiellogik enthalten oder enthält er wirklich nur die Startdatei? Wie sieht es dann z.B. bezüglich der Steuerung aus?
• Wie wird so eine Host-Client - Modell erstellt?
• Inwiefern muss ich Ports freigeben und wann?
• Was sollte ein typischer Host/Client alles besitzen?

Ein Client enthält normalerweise die komplette Spiellogik, auch dann wenn der Server der eigentliche "Spielleiter" ist. Man macht das, damit der Client die Zeit zwischen der Client/Server-Synchronisierung überbrücken durch Interpolation überbrücken kann. Das bewirkt, dass der Spieler einen scheinbar flüssigen Spielablauf sieht, obwohl das im Hintergrund nicht unbedingt so ist.

Die Interpolation, also die Voraussage wie sich das Spielgeschehen in der nächsten Zeit (meist ein paar hundert Millisekunden) entwickelt, ist normalerweise ein recht gutes Mittel, um Lags glatt zu bügeln. Es bringt aber zwei Probleme mit sich: Erstens ist eine Interpolation generell ungenau. Keiner kann die Zukunft vorhersagen. So kann es zum "Springen" oder "Teleportieren" von zB Spielfiguren kommen. Zweitens hat man das Problem, dass es bei anhaltender mangelhafter Verbindung zu zunehmender Desynchronisation von Client und Server sowie zwischen den verschiedenen Clients kommen kann. Dagegen kann man nicht wirklich was tun.

Die Frage nach dem Client-Host-Modell verstehe ich nicht. Die bauen eine Verbindung zueinander auf und unterhalten sich über ein eigenes Protokoll, das auf TCP oder UDP aufsetzt. Fertig. Da ist nichts besonderes.

Ein typischer dedizierter Host enthält: Spiellogik, Datenbank. Ein typischer Client enthält: Spiellogik, grafisches Frontend, Datenbank.
Eigentlich stellt ein Client einen erweiterten Host dar, da er zusätzlich noch eine grafische Oberfläche hat.
Andererseits stellt ein Host einen modifizierten Client dar, da er sich zusätzlich noch um die Koordination vieler Clients kümmert.
Wie rum man das angeht, hängt von den Anforderungen ab.

Deine Fragen nach dem Netzwerk sagen mir, dass dir noch einiges Wissen darüber fehlt. Nicht immer ist ein Client-Server-Modell das Mittel der Wahl. Manchmal eignet sich zB ein Peer-to-Peer-Netz besser (zB wenn der Host aussteigt und ein anderer automatisch übernehmen soll).

5) Sicherheit, Datenschutz

• Wie schütze ich meinen Server auf dem dann später das Spiel läuft, so dass das Server nicht überlastet wird und dann down geht? (z.B. auf Grund von zu viele Paketversendungen, DOS-Angriffe, Spam-Bots)
• Wie schütze ich mein Spiel vor Einflüssen von Drittprogrammen, wie der Cheat-Engine? ( so dass sich kein Spieler einen Vorteil cheaten kann?)
• Wie schütze ich Login-Daten von Usern, so dass sie nicht von Dritten oder allgemein ausgelesen werden können?

Man kann einen Spieleserver nicht effektiv vor DOS-Attacken schützen. Entweder ist er direkt im Internet erreichbar und damit direkt angreifbar oder man setzt ihn zB hinter einen Router oder Load Balancer. Damit verlagert man allerdings das Problem nur, da dann der Router oder der Load Balancer der Schwachpunkt ist.

Gegen Cheat-Programme kann man nur die Spiellogik und die Daten schützen, indem man sie auf dem Server ablaufen lässt und jede Eingabe von Clients auf Plausibilität prüft. Eine Plausibilitätsprüfung kann beispielsweise sein, ob sich ein Spieler in einem gewissen Zeitintervall merkwürdig verhält, zB in Bruchteilen von Sekunden zig mal die Laufrichtung verändert (was kein menschlicher Spieler schafft). Auch wird gern auf automatisierte, wiederkehrende Verhaltensweisen geprüft. Bei einem Bot kann zwischen Spielaktionen immer dieselbe Zeit vergehen. So genau ist kein menschlicher Spieler. Man lässt quasi permanent einen Turing-Test laufen.
Was man nicht schützen kann, sind alle Informationen, die dem Client-Programm bekannt sind. Hat man zB eine Karte mit Fog-of-War und sind dem Programm die Positionen der verdeckten Gegner(einheiten) bekannt, so kann man sie immer auslesen. Bei solchen Sachen wird gerne auf verschlüsselte Speicherinhalte gesetzt. Aber auch hier verlagert sich das Problem nur: Die Schlüssel zum Entschlüsseln sind dem Client ja bekannt, also kann man sie ebenfalls auslesen. Es erhöht nur den Aufwand für potentielle Cheater, verhindert aber sonst nix.

Login-Daten sollten generell nur auf dem Server verarbeitet werden. Oft gibt es dafür spezialisierte Login-Server. Der Client meldet sich da an (Username, gehashtes Passwort) und der Login-Server schaut in einer Datenbank nach, ob das so passt. War der Login korrekt, dann informiert der Login-Server den eigentlichen Spielserver über den authentifizierten Spieler und leitet den Spieler dort hin um. Wichtig ist, dass der Client (und auch sonst niemand) in den Authentifikationsprozess eingreifen und damit manipulieren kann. Der Zugang zu den Login-Daten sollte gut geschützt sein (Trennung Login-Server <-> DB-Server <-> Spielserver, verschlüsselte Verbindungen, Richtlinien für Passwörter, usw.).

Eigentlich ist das Ganze ein Kapitel für sich, auf das sich Leute spezialisieren.

6) Verbindung von Website und Spiel / Realisierung von Registrierungen neuer Accounts

• Werden solche Registrierungen dann über 2 Datenbanken gehandlet, also eine für die Website und den Website-Bereich und dann eine weitere separate Datenbank für das Spiel?
• Oder existiert nur eine einzige Datenbank, die dann Website und Spiel vereint?

Es existieren normalerweise mehrere Datenbanken, die ggfs. untereinander synchronisiert werden, wenn sich was überschneidet. Ein Spielserver hat Zugriff auf vllt. Profildaten aber normalerweise nicht auf Login-Daten. Ein Login-Server weiß normalerweise nichts von den Spieldaten, oder was jemand auf einer Webseite so macht, usw.
Das übliche Sicherheitskonzept ist, dass jeder Teil nur so viel weiß, was für seine Arbeit braucht. Es ist daher wichtig, die Zuständigkeiten genau zu trennen und Rechte einzuschränken. Praktisch bedeutet das, dass man mehrere Server für die verschiedenen Aufgaben hat, die sich zwar untereinander austauschen aber nicht beeinflussen können.


Puh, ziemlich langer Post.

 

[smaradey]

Hallo,

vielen Dank für die zahlreichen und ausführlichen Antworten - mir ist inzwischen einiges klarer geworden

Ich habe mir jetzt einen Plan erstellt, wie ich weiter vorgehen will:

• C++ Tutorials machen
• SQL Tutorials machen
• simples Chatprogramm erstellen (C++)
• Netzwerkbasiertes Spiel erstellen (Host-Client) (C++, SQL)
• Netzwerkbasiertes 2D Echtzeit-Game programmieren (C++, SQL)
• Netzwerkbasiertes 3D Echtzeit-Game programmieren (C++, SQL, Grafikengine)

Bezüglich Grafikengines:
Gibt es Engines, die einsteigerfreundlicher sind als andere?
Oder könnte ich gleich mit der CryEngine anfangen? (ich vermute mal nicht )


Ich hoffe das ist noch genug Step-By-Step gedacht.
Habt ihr evtl. Ratschläge oder andere Ideen bzgl. meiner Vorgehensweise?

 

[Mortal]

Ich würde dir weiterhin empfehlen Java zu benutzen. Solltest du irgendwann in 5+ Jahren mal auf einem Level sein wo du die Vorzüge von C++ nutzen kannst dann kannst du immer noch umsteigen bzw. gibt es da dann nicht mehr viel umzusteigen weil du an dem Punkt programmieren kannst und die ganzen Details mit denen man sich in C++ rumschlagen muss nicht mehr so verwirrend sein werden.

Eine Engine würde ich im ersten Schritt auch nicht benutzen sondern direkt auf OpenGL zugreifen, für die ersten 2D Spiele reicht das und man bekommt direkt ein besseres Verständnis dafür was Engines eigentlich machen im Hintergrund.

Außerdem würde ich Netzwerk und SQL erstmal ausblenden für das erste Projekt... es werden genug andere Herausforderungen auf dich warten

 

[Yuuri]

Ich würde dir weiterhin empfehlen Java zu benutzen. Solltest du irgendwann in 5+ Jahren mal auf einem Level sein wo du die Vorzüge von C++ nutzen kannst dann kannst du immer noch umsteigen bzw. gibt es da dann nicht mehr viel umzusteigen weil du an dem Punkt programmieren kannst und die ganzen Details mit denen man sich in C++ rumschlagen muss nicht mehr so verwirrend sein werden.

Ich würde eher die Friss-oder-stirb-Methode vorziehen. Lieber erstmal richtiges C++ machen, damit man auch versteht, wie man den Speicher organisieren kann, anstatt eine "verweichlichte" Sprache wie Java/C#/... zu nutzen und keine Ahnung zu haben, wie es im Hintergrund eigentlich abläuft, Speicherlecks entstehen usw.

Gut, zum Sprache lernen wäre Java vielleicht gut. Aber auch nur dafür... Danach lieber aber die Hintergründe beleuchten und C/C++ ausprobieren.

Eine Engine würde ich im ersten Schritt auch nicht benutzen sondern direkt auf OpenGL zugreifen, für die ersten 2D Spiele reicht das und man bekommt direkt ein besseres Verständnis dafür was Engines eigentlich machen im Hintergrund.

Für einfache Sachen würde vielleicht auch schon die SDL reichen. OpenGL kann man natürlich auch gleich mit einbinden oder später machen.

Außerdem würde ich Netzwerk und SQL erstmal ausblenden für das erste Projekt... es werden genug andere Herausforderungen auf dich warten

Für SQL würde ich eher PHP oder ähnliches empfehlen. Macht sich leichter für den Anfang, da du dort nicht mit DataReadern usw. handtieren musst und du dich somit erstmal mit SQL selbst beschäftigen kannst.

 

[Mortal]

Wenn man in den ersten Jahren schon Anfängt sich das Speicherlayout anzugucken und sich zu viel Gedanken um Optimierung und lowlevel Quatsch macht führt das automatisch dazu das man scheiß Code schreibt. Es ist erstmal viel wichtiger das der Code insich schlüssig ist und die ganzen Datenstrukturen sitzen und man weiß wie man seinen Code organisiert bekommt ...
Ich hab mit C++ angefangen und auch einige kleinere 2D Spiele damit programmiert aber von den wirklich wichtigen Dingen die ich dabei gelernt habe sehe ich nichts was ich nicht auch in Java hätte lernen können

 

[F_GXdx]

Nimm dir ne Plattform wie Unity3D, da kannst du gleich C# lernen.

 

[smaradey]

bezüglich SQL: Ok, die Variante über Php finde ich ganz attraktiv.

bezüglich der Programmiersprache: Es wird definitiv C++ sein, da ich es im nächsten Semester so oder so lernen muss.

Mir sind folgende Dinge beim Programmieren bekannt/geläufig:

• Schleifen, Bedingungen
• Arrays, Listen(LinkedList, ArrayList, DubbleLinkedList), Strukturen,
• Binärbäume/ Vielwegbäume,
• Funktionen, Prozeduren, rekursive Funktionen/Prozeduren, wechselseitige Funktionen/Prozeduren,
• Interface,
• OOP (Klasse, abstrakte Klasse, Vererbung, Polymorphie, Datenkapselung),
• Zeiger(Pointer),
• Casting / Boxing,
• Backtracking,
• gängige Sortier-Algorithmen inkl. Komplexität.

Mir ist bewusst, wie ein PC aufgebaut ist und z.B. wie ein Prozessor der 80er Jahre ungefähr funktioniert (Also Latches und Flip-Flops sagen mir schon was)
Des Weiteren weiß ich auch um Teile der Logik bescheid. Also Automatentheorie, Sprachen, Grammatik usw.


Nach meinem Gefühl sehe ich mich jetzt in der Lage mich an C++ zu wagen. Was meint ihr? Sollte ich mir davor noch ein bestimmtes Gebiet besonders zu Herzen nehmen?

LG

 

[antred]

Ich denke, da bist du schon recht gut vorbereitet, um dich an C++ heranzuwagen. Eine Bitte nur ... lerne C++ mit dem aktuellen C++-Standard im Hinterkopf. Lerne wirklich idiomatisches C++ und nicht ein verhunztes Mischmasch von C und C++. Sei nicht ein weiterer C++-Progger, der noch in der vorsteinzeitlichen Prähistorie herumtümpelt sondern lerne die C++ Standard Bibliothek und habe eventuell auch ein Augenmerk auf die boost Libraries ( http://www.boost.org/ ), da so manche der Konstrukte, die dort entstehen / entstanden sind, in den C++ Standard einfließen (oder es bereits getan haben).

Und schlau dich ganz besonders zum Thema RAII ( http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization ) auf und nutze es in deinem Code ausgiebig. Dies ist eine der größten Stärken von C++, die dir in diesem Ausmaß von kaum einer anderen Sprache geboten wird, doch leider gibt es immer noch viel zu viele C++-Programmierer, die keine Ahnung haben, was sich hinter diesem (eigentlich recht trivialen) Konzept verbirgt.