EulerHobeln: Unterschied zwischen den Versionen

Aus II-Wiki
Zur Navigation springen Zur Suche springen
 
(13 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
= EulerHobeln =
+
EulerHobeln ist ein Projekt der II04. Es soll eine Spiele-Platform gebaut werden, die die wichtigsten Schnittstellen standardisiert. Dazu zählt zunächst nur die Netzwerkschnittstelle, welche realisiert, dass verschiedene Spiele mit verschiedenen "Protokollen" auf einer TCP-Verbindung arbeiten können. Das ist das Ziel.
  
Oder auch '''Vektor-Rennen'''. Ein beliebtes Papierspiel für zwischendurch.
+
Erstes zu realisierendes Spiel ist das Vektorrennen. Das so genannte [[EulerHobeln:VRace|VRace]].
 
 
Und wir wären nicht Informatiker, wenn wir nicht probieren würden, es selber zu schreiben.
 
 
 
Eine Anleitung für die wenigen, die dieses Spiel nicht kennen, gibt es [http://www.puzzles-und-games.de/Spiel05.html hier]
 
  
 +
Die Spieleplatform soll mit verschiedenen Sprachen auf vielen Architekturen und Betriebssystemen verwirklicht werden.
 +
__TOC__
 
== Konzept ==
 
== Konzept ==
 
* Multi-Platform
 
* Multi-Platform
* mehrere Sprachen: C++ [evtl. Jan], Delphi [Markus], .NET (u.ä.) [Sebbl], Java [Peter], evtl. MIDP (Mobile Information Device Profile) für Java-fähige Handys
+
* mehrere Sprachen: C++ [Jan], Delphi [Markus], .NET (u.ä.) [Sebbl], Java [Peter], evtl. MIDP (Mobile Information Device Profile) für Java-fähige Handys
* SDL unter C++ als Grafikbibliothek (ein einfaches Canvas reicht eigentlich)
 
* Netzwerkfähig, große Nutzeranzahl (Rooms, Chat, ...)
 
* viele Maps (Auswahl...)
 
* große Maps (größer als dargestellt, scrollen)
 
* Highscore im Internet/Intranet/aufm Server
 
 
 
* SinglePlayer und Multiplayer (SinglePlayer heißt, Handy/Tastatur/Maus rumgeben zum nächsten Spieler..., kein Netzwerk)
 
 
 
'''Zusatz:'''
 
 
 
* Animation, Qualm, Autos, Boxen, Reifenschaden, Slicks und Regenreifen, Motorsetup, Zeitlupen ;)
 
* Computergegner mit vorberechneten Routen
 
* Ganzes Spiel speichern als Demo zum wiederabspielen
 
* Cheats ;)
 
  
 
== Mitarbeiter ==
 
== Mitarbeiter ==
Zeile 29: Zeile 13:
  
 
* Peter
 
* Peter
* Zoddltier (würde gern mitmachen, wenn der Hauptstädter nicht gleich in 2 Tagen alles fertig proggt und Zoddl nichts dabei lernen kann)
+
* Zoddltier
* Imag aka Sebbl (der sich erst mal angucken muss, wie man aufs Netzwerk zugreift... Ziel: .NET-Client für Handy und Smartphone auf Compact Framework)
+
* Imag (Ziel: .NET-Client und Server für PC bzw. für Mobile, Handy und Smartphone auf Compact Framework)
 +
* Omega ([[EulerHobeln:Protokoll|Protokoll]]-Entwicklung, Delphi-Server)
  
 
== Konkrete Ideen ==
 
== Konkrete Ideen ==
=== Strecken ===
+
=== Umsetzung als Java MIDlet ===
Die Strecken werden in sogenannten Maps gespeichert.
 
Dazu entwerfen wir ein neues Dateiformat. Es besteht aus einer Zip-Datei mit folgendem Inhalt:
 
* einer XML-Datei zur Beschreibung der Strecke (Name, Spieleranzahl, Rundenlänge, Credits, ...)
 
* die Strecke als Bild, voraussichtlich PNG, weil die Kompression verlustfrei ist
 
* die Metainformationen zur Strecke ebenfalls als Bild, selbe Größe, wobei die Pixelfarben die verschieden Streckenfunktionen repräsentieren
 
* ''optional:'' Ein Thumbnail der Strecke zur Verwendung außerhalb des eigentlichen Spiels
 
* ''optional:'' Eine XML mit berechneten Waypoint-Daten für eventuelle KIs
 
* ''optional:'' Eine XML mit einer Farbtabelle für das Funktions-PNG, wenn abweichend von der Standardimplementierung
 
* ''optional:'' weitere Addons (Sounds, Animationen, Texte,.....)
 
 
 
==== Offene Fragen ====
 
Wie stellen wir Brücken, Sprünge über Strecken usw. dar? Da sind dann 2 Metainfos pro Pixel... (Diskussionsbedarf!!!)
 
 
 
=== KI ===
 
Das ist was für Herrn Filzhuth. Ich dachte da so an Tiefensuche oder sowas.
 
 
 
Der Algorithmus muss nicht ins Spiel integriert werden, weil man zu jeder Map Waypoints speichern könnte. Ideen?
 
 
 
=== Umsetzung als MIDlet ===
 
 
MIDlets sind Java-Applikationen für Mobile Devices.
 
MIDlets sind Java-Applikationen für Mobile Devices.
 
Dafür gibts es sogar 3D-Implementierungen.
 
Dafür gibts es sogar 3D-Implementierungen.
Zeile 58: Zeile 24:
 
Aber es ist nicht wirklich vergleichbar, deswegen schieb ich das mal auf die lange Bank.
 
Aber es ist nicht wirklich vergleichbar, deswegen schieb ich das mal auf die lange Bank.
  
=== Java-Client ===
+
=== .NET-Umsetzung ===
Es gibt schon einen.
+
Mit der Umsetzung als Client und Server auf dem .NET Framework ist begonnen worden. Beide sind noch konsolenbasiert. Im nächsten Schritt werden beide erst mal eine GUI bekommen.
Mit dem will ich das Netzwerk-Protokoll entwerfen.
 
  
Mit der neusten SWT (Grafik-lib von Java) kann man sogar OpenGL einbinden, was ich aber nicht vorhabe.
+
Hierbei handelt es sich erstmal nur um die [[EulerHobeln:Protokoll|Protokoll]]-Implementierungen.
  
'''Warum sollte es einen Java-Client geben, wenn die SDL auch auf allen Platformen läuft?'''
+
Sebbl macht dazu selber eine [[EulerHobeln:NET-Architektur|Dokumentation]] über seine Konzepte und Fortschritte.
  
Mhm, gute Frage. Ich hab Lust das in Java zu schreiben. Im Endeffekt ist mir nur das Applet eingefallen, also als Webapplikation. K.A.
+
=== Java-Client ===
 +
Weiteres unter [[EulerHobeln:Java]]
  
Außerdem interessiert mich der Vergleich bei beiden Systeme in Hinsicht auf die Implementierung. Also als Feldstudie.
+
=== C++-Client ===
 
+
Weiteres unter [[EulerHobeln:Cpp]]
Was der Existierende kann, steht [[Diskussion:EulerHobeln|hier]].
 
  
 
=== Netzwerk Layout ===
 
=== Netzwerk Layout ===
Wenn die Zeit da ist, würde das wie bei der HalfLife-Engine (oder verleichbaren) machen.
 
Jeder Client kann dann als Listenserver arbeiten, im P2P-Mode.
 
Oder über einen dezidierten Server (dedicated server).
 
 
 
Protokoll erster Wahl ist TCP. Wir haben (überhaupt) keinen hohen Echtzeitanspruch, so dass UDP nicht notwendig ist. (Das freut die FEM-Leute)
 
Protokoll erster Wahl ist TCP. Wir haben (überhaupt) keinen hohen Echtzeitanspruch, so dass UDP nicht notwendig ist. (Das freut die FEM-Leute)
  
Ein nettes Detail wäre, das man vom Server nicht vorhandene Maps nachladen kann. Die Version sollte per Checksumme verifiziert werden. (Server schickt Chksum, Client hasht selber und vergleicht...)
+
Das Protokoll hat Omega entwickelt (Danke, dafür!). Dokumentation findet man [[EulerHobeln:Protokoll|hier]].
  
'''Hier muss ich nochmal was zu sagen:'''
+
Es wird z.B. wie bei Yahoo-Games eine Lobby mit einem Mainchat geben, wo alle Spieler zuerst landen. Dort sieht man die Auswahl der Spiele, die der Server anbietet. Bei VRace z.B. gibt es dort dann mehrere Spieltische. Dort kann man joinen oder auch selber einen neuen Tisch erstellen.
  
Der Client soll SinglePlayerfähig sein. Also alle Kontrollstrukturen beinhalten. Der Server soll nur die Infos verarbeiten, kontrollieren und weitergeben. Aber er ist nur Kontrollinstanz, nicht entscheidende Instanz. D.h. der Client berechnet selber wo er hin muss.
+
Die Spiele selber nutzen das O2Megaprotokoll als Netzwerkinterface und können darauf ihr eigenes Protokoll verwirklichen.
  
Man könnte für Handys diese Berechnung dem Server überlassen, aber nur, wenn die Handys keinen Singleplayer-Mode haben. Weil im SinglePlayer brauch man das wieder.
+
'''Für später:'''
  
==== Diskussion ====
+
Ein nettes Detail wäre, das man vom Server nicht vorhandene Maps nachladen kann. Die Version sollte per Checksumme verifiziert werden. (Server schickt Chksum, Client hasht selber und vergleicht...)
'''Sollte es z.B. wie bei Yahoo-Games einen Raum mit Spiel-Tischen und einem Mainchat geben ODER wie bei vielen MP-Games bestimmt der Server die Map?'''
 
:Erstmal nicht, also nur Server mit laufender Map -- [[Benutzer:Omega|Omega]] 18:28, 6. Jan 2006 (CET)
 
  
 
=== Spiel Layout ===
 
=== Spiel Layout ===
Das klassische Spiel soll implmentiert werden. Es können aber noch weitere Spiel-Modes erfunden werden. Hier sind kreative Ideen gefragt.
+
Da EulerHobeln nun nicht mehr allein das VRace beinhaltet, können hier Ideen für zu implementierende Spiele zusammengetragen werden.
 +
 
 +
Zum VRace:
 +
Das klassische Spiel soll implementiert werden. Es können aber noch weitere Spiel-Modes erfunden werden. Hier sind kreative Ideen gefragt.
  
 
=== Demo Feature ===
 
=== Demo Feature ===
Zeile 99: Zeile 61:
 
=== Intro ===
 
=== Intro ===
 
Querdenker Entertaiment? Ideen?
 
Querdenker Entertaiment? Ideen?
 +
 +
== Versionskontrolle ==
 +
Wir nehmen hier SVN. Bis jetzt gibt es nur Logins für Entwickler. Anonymous-Zugang gibts vielleicht später.
 +
 +
SVN-Root: https://svn.theweblords.de/repos/eulerhobeln
 +
WebSVN: https://svn.theweblords.de/websvn
 +
 +
Logins gibts bei mir.
 +
 +
[[Benutzer:Petronios|Petronios]] 00:48, 18. Jan 2006 (CET)
 +
 +
[[Kategorie: EulerHobeln]]

Aktuelle Version vom 3. April 2006, 08:06 Uhr

EulerHobeln ist ein Projekt der II04. Es soll eine Spiele-Platform gebaut werden, die die wichtigsten Schnittstellen standardisiert. Dazu zählt zunächst nur die Netzwerkschnittstelle, welche realisiert, dass verschiedene Spiele mit verschiedenen "Protokollen" auf einer TCP-Verbindung arbeiten können. Das ist das Ziel.

Erstes zu realisierendes Spiel ist das Vektorrennen. Das so genannte VRace.

Die Spieleplatform soll mit verschiedenen Sprachen auf vielen Architekturen und Betriebssystemen verwirklicht werden.

Konzept

  • Multi-Platform
  • mehrere Sprachen: C++ [Jan], Delphi [Markus], .NET (u.ä.) [Sebbl], Java [Peter], evtl. MIDP (Mobile Information Device Profile) für Java-fähige Handys

Mitarbeiter

(selber eintragen)

  • Peter
  • Zoddltier
  • Imag (Ziel: .NET-Client und Server für PC bzw. für Mobile, Handy und Smartphone auf Compact Framework)
  • Omega (Protokoll-Entwicklung, Delphi-Server)

Konkrete Ideen

Umsetzung als Java MIDlet

MIDlets sind Java-Applikationen für Mobile Devices. Dafür gibts es sogar 3D-Implementierungen.

Aber es ist nicht wirklich vergleichbar, deswegen schieb ich das mal auf die lange Bank.

.NET-Umsetzung

Mit der Umsetzung als Client und Server auf dem .NET Framework ist begonnen worden. Beide sind noch konsolenbasiert. Im nächsten Schritt werden beide erst mal eine GUI bekommen.

Hierbei handelt es sich erstmal nur um die Protokoll-Implementierungen.

Sebbl macht dazu selber eine Dokumentation über seine Konzepte und Fortschritte.

Java-Client

Weiteres unter EulerHobeln:Java

C++-Client

Weiteres unter EulerHobeln:Cpp

Netzwerk Layout

Protokoll erster Wahl ist TCP. Wir haben (überhaupt) keinen hohen Echtzeitanspruch, so dass UDP nicht notwendig ist. (Das freut die FEM-Leute)

Das Protokoll hat Omega entwickelt (Danke, dafür!). Dokumentation findet man hier.

Es wird z.B. wie bei Yahoo-Games eine Lobby mit einem Mainchat geben, wo alle Spieler zuerst landen. Dort sieht man die Auswahl der Spiele, die der Server anbietet. Bei VRace z.B. gibt es dort dann mehrere Spieltische. Dort kann man joinen oder auch selber einen neuen Tisch erstellen.

Die Spiele selber nutzen das O2Megaprotokoll als Netzwerkinterface und können darauf ihr eigenes Protokoll verwirklichen.

Für später:

Ein nettes Detail wäre, das man vom Server nicht vorhandene Maps nachladen kann. Die Version sollte per Checksumme verifiziert werden. (Server schickt Chksum, Client hasht selber und vergleicht...)

Spiel Layout

Da EulerHobeln nun nicht mehr allein das VRace beinhaltet, können hier Ideen für zu implementierende Spiele zusammengetragen werden.

Zum VRace: Das klassische Spiel soll implementiert werden. Es können aber noch weitere Spiel-Modes erfunden werden. Hier sind kreative Ideen gefragt.

Demo Feature

Das wird auch erst ab Version 2 machbar sein. Wär aber interessant ein Konzept zu entwerfen, wie man sowas speichert.

Intro

Querdenker Entertaiment? Ideen?

Versionskontrolle

Wir nehmen hier SVN. Bis jetzt gibt es nur Logins für Entwickler. Anonymous-Zugang gibts vielleicht später.

SVN-Root: https://svn.theweblords.de/repos/eulerhobeln WebSVN: https://svn.theweblords.de/websvn

Logins gibts bei mir.

Petronios 00:48, 18. Jan 2006 (CET)