@Rabenaas:
Ja, einer sollte federführend agieren. Ich ringe gerade mit mir, ob ich das machen kann und möchte.
@Hindro:
Die von mir gerade favorisierte Multimedia-Library (mit 2D-Graphik, Sound, Musik, Netzwerk,...) SFML läuft auch (mehr oder weniger) auf Android und iOS. Also wäre das kein Problem und es gäbe keinen Grund, Java zu nutzen
@aeyol und @Hindro->Multiplayer:
Ein realistisches Ziel wäre erstmal eine lauffähige Variante, die genau das Grundspiel umsetzt (ich stelle mir vor, Bright-Eyes immer wieder als Referenz zu nutzen, um herauszufinden, was im Game an welchen Stellen passiert). Dabei sollte man eine gewisse Erweiterbarkeit von Anfang an verfolgen.
Da stelle ich mir vor, man baut z.B. einen Level-Loader, der ein Level entweder aus der SCHICK.DAT laden kann (altes Level) oder aus einer XML/JSON/wasauchimmerfüreinformat-Datei (neues Level). Damit könnte man nebeneinander Original- und Mod-Levels laden.
Das Prinzip sollte sich dann durchziehen, d.h. Original-Bilder können aus SCHICK.DAT geladen werden, Bilder in Mods aus z.B. PNG.
Multiplayer sehe ich dann erst ganz am Ende (weil das ganz viele Fragen stellt, die geklärt werden müssen, und sehr aufwendig ist).
Mein Vorschlag zur Entwicklungsreihenfolge:
Wenn man bei der Entwicklung ein wenig aufpasst und eine vernünftige Architektur aufbaut, kann man nachher bei Schweif und Riva viel bestehendes wieder verwenden (sollte das mal ein Thema sein und sollte Henne auch für Bright-Eyes-Schweif und Bright-Eyes-Riva noch Lust haben
).
Was meint ihr?
Ja, einer sollte federführend agieren. Ich ringe gerade mit mir, ob ich das machen kann und möchte.
@Hindro:
Die von mir gerade favorisierte Multimedia-Library (mit 2D-Graphik, Sound, Musik, Netzwerk,...) SFML läuft auch (mehr oder weniger) auf Android und iOS. Also wäre das kein Problem und es gäbe keinen Grund, Java zu nutzen
@aeyol und @Hindro->Multiplayer:
Ein realistisches Ziel wäre erstmal eine lauffähige Variante, die genau das Grundspiel umsetzt (ich stelle mir vor, Bright-Eyes immer wieder als Referenz zu nutzen, um herauszufinden, was im Game an welchen Stellen passiert). Dabei sollte man eine gewisse Erweiterbarkeit von Anfang an verfolgen.
Da stelle ich mir vor, man baut z.B. einen Level-Loader, der ein Level entweder aus der SCHICK.DAT laden kann (altes Level) oder aus einer XML/JSON/wasauchimmerfüreinformat-Datei (neues Level). Damit könnte man nebeneinander Original- und Mod-Levels laden.
Das Prinzip sollte sich dann durchziehen, d.h. Original-Bilder können aus SCHICK.DAT geladen werden, Bilder in Mods aus z.B. PNG.
Multiplayer sehe ich dann erst ganz am Ende (weil das ganz viele Fragen stellt, die geklärt werden müssen, und sehr aufwendig ist).
Mein Vorschlag zur Entwicklungsreihenfolge:
- Meilenstein: Bisherige Arbeiten (Informationen im Wiki; Hennes Tools wie nltpack) in Loader einarbeiten, damit alle Originaldaten geladen werden können
- Meilenstein: Für die Multimedia-Daten Loader hinzufügen, die PNG, WAV, OGG laden können
- Meilenstein: GUI-Basis (Dialogfenster/Popups, etc.)
- Meilenstein: Main-Screen mit Icons, Heldenportraits etc. aufbauen (dabei bleibt das "Fenster in die Welt", wo also die Stadt-Umgebung oder das Bild des Shops oder oder angezeigt wird, erstmal leer)
- Meilenstein: Charakterbildschirm anzeigen (mit Inventory etc.)
- Meilenstein: Kampfbildschirm anzeigen (noch kein Kampf mit Animationen etc.)
- Meilenstein: Rendern von Shops, Gebäudeinneren, etc.
- Meilenstein: Rendern der Stadt- bzw. Dungeonumgebung
- Meilenstein: Rendern der Reisekarte (kann auch früher, ist eigentlich recht einfach)
- Meilenstein: Reisefunktion zwischen Städten und in Dungeons
- Meilenstein: Generierung oder Kampfberechnung oder Questsystem
Wenn man bei der Entwicklung ein wenig aufpasst und eine vernünftige Architektur aufbaut, kann man nachher bei Schweif und Riva viel bestehendes wieder verwenden (sollte das mal ein Thema sein und sollte Henne auch für Bright-Eyes-Schweif und Bright-Eyes-Riva noch Lust haben
).Was meint ihr?