Das Erste und Beste OpenSource Städtebauspiel von der ganzen Welt...

[SuperNicky]

... beschloss heute, programmiert werden zu wollen. DragonDarkhawk steigt bei nächster Gelegenheit in die Planung ein und verteilt dann Arbeit für alle.
(siehe Pharaoh / Cleopatra ::Pharaoh / Cleopatra official websites closed) (- sorry, aber ich kann das gerade nicht vernünftig verlinken).
Solange es das Spiel noch nicht gibt und auch noch niemand eine Zeile programmiert habt, ist dies der Thread, um nach Herzenslust herumzuspinnen über Wünsche, die ihr an ein deratiges Spiel hättet.

Bislang haben wir einen Wunsch : ein Monumenteneditor muss her, sagt BJ aus HH

[BengJaming]

<H5>Unter diese Umständen verzichte ich auf den Monumente-Editor zugunsten einer Entwicklungsumgebung für neue Kulturen INKLUSIVE der Monumente. :D

Mal ehrlich - in so einem Projekt würd ich auf irgendwelche Editoren a la Sierra verzichten wollen - ist m. E. viel zu aufwendig. Der Clou wäre doch, daß vollkommen eigene Grafiken, Produkte, Götter, Kulturen etc. eingebunden und eingestellt werden können. </H5>

[DragonDarkhawk]

mmmh, jetzt ham wir uns beim Thread-Erstellen überschnitten, hab auch grad einen aufgemacht :D
Kann die einer der Admins mal zusammenführen oderso?

(war zwar 3 Minuten schneller, aber im falschen Forum, unter Pharao ist das auch OT, sorry:roll:)

Diese Nachricht wurde ge&auml;ndert von: DragonDarkhawk, 16.02.04 - 17:15

[tobing]

Hab den anderen Thread auch hierher gestellt und ihn gleich geschlossen, damit es nur hier weitergeht. OK so?

[DragonDarkhawk]

Klaro ;)

[SuperNicky]

Ah, okay ! Also mal zu BJ : Stimmt, man braucht keinen Editor mehr, aber das würde vielleicht eine unfaire Ausgrenzung von nicht - programmierenden Menschen bedeuten.
Also, wenn man Gebäude streng objektorientiert betrachtet, und die Fußgänger als Eigenschaft der Gebäude usw. kommt man wahrscheinlich wirklich mit relativ wenigen Schnittstellendefinitionen aus - aber glaubst du, dass dann da viele Leute etwas mit anfangen könnten ? So ein Editor wäre doch etwas handlicher evtl....

[Manni]

Hallo Entwicklertiehm!

Ich hätte da mal folgende Frage:
Muss man erst die "Technik" klabüsern oder muss erst die Story her? (....im Sinne von: Erst Huhn dann Ei oder wie?!)
Falls es um ein Spielthema/Geschichte geht, könnte ich was zu beitragen.

Könnte man nicht parallel zum "Beste Open Source.............technischer Natur" `nen Zrätt für die fanatischen Phantasten öffnen, in dem dann`ne Spielstory gebacken wird?

MfG
Manni

[Antiope]

<H5>Also mir gefiel die Grafik und die Figuren in Sierra ganz speziell bei DEK, Zeus und Posi, könnte also ruhig so bleiben aber sich mehr alte Kulturen aussuchen zu können (wie zB. Germanen oder auch Kelten) und dafür auch die entsprechenden Götter herumlaufen zu lassen wäre herrlich! Vielleicht auch mal etwas exotischeres für die H.P. Lovecraft Fans (ich glaub da bin ich ziemlich einsam da, oder?) :D

Einen Teuer-Editor würde ich schon wieder begrüßen, damit man auch mal selber dran rumbasteln kann.

Des woa hoit mei Senf dazua! :D

LG

Antiope</H5>

[BengJaming]

Also wenn wirs richtig machen, ist die Story nachher voll flexibel. Richtig interessant wirds doch erst, wenn es eine Engine gibt, die nach Städtebauregeln läuft und die man dann mit verschiedenstem Bestücken kann. Wenn dann einer Lust verspürt, ein Teuer in einer bestimmten Kultur mit bestimmten Regeln und bestimmten Fußgängern und bestimmten was weiß ich zu machen, dann kann er sich das darin bauen - inkl. allem - eben open source - kann also auch auf schon vorhandenes zurückgreifen. Nur die Basis ist dann fest, der Rest wird frei immer weiter dazugebaut. So ganz grob jedenfalls.

[SuperNicky]

Mach doch !

Et ist halt alles eine Frage von wie open und wie sourcig zieht man das auf. Der BJ z.B. scheint ja jeweils für "sehr" zu plädieren, was heißen würde (wenn ich ihn richtig verstehe), es gäbe am Ende einen Haufen Kram, den dann jeder so zusammenbrutzeln kann, wie es ihm beliebt. D.h. die Anzahl der Spielstorys geht gegen n, wobei n die Anzahl der Benutzer ist ... (Oje, ich werd verrückt, ich muss nach Haus !)
Aber phantasiert ruhig (ich bin in der Hinsicht leider nicht so begabt, auch wenn ich noch keine Vulkanierohren habe...)

[BengJaming]

Aber das ist doch die Grundidee bei einem Opensource Projekt - das viele was daran tun können. Und wenn das ganze richtig interessant werden soll, dann gibts eine Entwicklergemeinde für die Funktionalität und dann finden sich einzelne, oder Gruppen, die mit der Funktionalität was Spielbares machen. Zur zweiten Gemeinschaft würde ich mich zählen. Beim entwickeln von Funktionalitäten könnt ich höchstens nen Plan machen, wie das nachher auszusehen hat, aber nicht unbedingt, wie man da hin kommt :D

Wenn die Sache wirklich offen gebaut wird, dann braucht sich hier niemand niemals mehr irgendwelche Sorgen machen, daß Städtebau-Spiele mal aussterben werden :D :D

[SuperNicky]

Auf jeden Fall wird es für uns alle etwas wirklich Neues. Vielleicht geht der heutige Tag noch in die Annalen der Computerspielgeschichte ein...

[Manni]

@SuperNicky,

Die Frauen&amp;Männer der ERSTEN STUNDE! :)

[koppi]

Kaum ist man mal 2 Tage Offline ist ja hier die Hölle los. :8)

Bin schon gespannt was daraus wird.

Möchte auch mitmachen.

[SASUKO]

Hallo SuperNicky,

eine absolut tolle Idee - da habt ihr euch aber was aufgeladen - wow - habe mir darüber eigentlich noch nie Gedanken gemacht, aber wenn ich jetzt so a bisserl andenk - na pfiati - des ist ka klane Gschicht. Bin gspannt - wie Regenschirm!

Viel Erfolg!

[tobing]

Moin Moin, also ich denke, dass so eine Engine völlig davon unabhängig ist, ob die Grafiken nun Römer oder Ägypter oder sonstwas darstellen. Man braucht halt für alles und jedes und vieles jede Menge Grafiken, zum grössten Teil animiert, aber das ist nicht so direkt Teil der Programmierarbeit, sondern eine ganz eigene Sache. Story und Missionen sind dann wieder darauf aufbauend ein eigenes Thema, das durchaus einen eigenen Thread verdient, also macht doch einfach einen dafür auf! Für meinen Geschmack ist die Herstellung all dieser (animierten) Grafiken die absolute Höllenarbeit...

[BengJaming]

Zustimm! Aber das ist ja das interessante. Wenn es eine Engine gibt, zu der dann immer mal wieder neue Features hinzugebastelt werden können - so wie bei Sierra ja auch immer neue Sachen dazugekommen sind - von Spiel zu Spiel - dann ist das die eine Sache. Darauf dann Kulturen - also Grafiken zu schrauben ist ne zweite. Das spannende ist, daß das dann ein eigenes Team machen kann. Wäre sozusagen so, daß es eine engine gibt - zu der gibts dann Kulturen (also Spiele)- zu denen gibts dann Teuer

[tobing]

Ja, so dachte ich mir das. Im Extremfall könnte man dann ein Teuer mal römisch und mal chinesisch spielen... :)

Für mich ist natürlich die Logistik am Interessantesten, was also die Steuerung der Lager angeht hätte ich da durchaus ein paar Wünsche.

[DragonDarkhawk]

Moin in die Runde :D

Wie, kein Editor?!? http://www.staedtebauen.de/modules/RteMulti/pneditor/images/em.icon.question.gif:eek:
Was habt denn IHR für komische Ideen!!! Dann würde wirdasalles ja programmieren müssen:D

Wie tobing schon schrieb kann/soll/muss eine Engine komplett unabhängig von der Kultur-Grafik sein, sie soll nur und ausschließlich Funktionalitäten zur Verfügung stellen.
Eigentlich muß man das hier sogar noch etwas verfeinern: es wird wohl 2 Engines geben.
Eine Grafik-Engine, die ganz rudimentär Ein- und Ausgabe (ISO-Ansicht und Menüführung) handeln kann und deren Ergebnisse dann an die ->
Spiele-Engine weiterleitet, die rudimentäre Objekttypen (Gebäude/Person/Fahrzeug/Gelände usw.) kennt und anhand deren Attributen Interaktionen ermöglicht.
Die Grafik-Engine, so sie denn mal steht sollte im Idealfall einige Versionsnummern des Gesamtprogramms unverändert überstehen können, die Spiele-Engine kann dannum die Besonderheiten möglicher Kulturen (Götter etc.)erweitert werden.

Ich stell mir das ganze dann so vor, daß es Parallel dazu mindestens 3 Editoren geben wird:
a) Einen Objekt-Editor, in dem bspweise ein Gebäude gebastelt werden kann (Eine Erweiterung dieses Editors wäre dann auch die Möglichkeit, sich Monumente zu basteln ;)).
(Gebäude: Bezeichnung, Feld-Größe, Grafik-Ansichten (Nord/Süd/Ost/West/reduziert), Gebäude-Typ und damit Freischaltung mögliche Zusatz-Attribute (Einwohner/Güter/etc), Standard-Bau/laufende-Kosten, max. Anzahl auf Karte pro (Einwohner/generell/...).)
(Person: Aussehen, Grafik-Ansichten, Interaktionsmöglichkeiten, Geschwindigkeit, Zugehörigkeit zu Gebäuden, und sehr viele erweiterungsfähige Einstellungen, die hier noch erfunden werden können :D)
Vielleicht macht man aus dem Objekt-Editor auch gleich deren 3: Gebäude/Monumente/Personen, muss man gucken....

b) Natürlich einen Missions/Kampagnen-Editor, in demdann auch die für die Missi gültigen Objekte aus dem "a)"-Editor Verwendung finden, (mögliche) Ereignisse festgelegt werden, etc..

c) Den "großen" "Kultur-Editor".
Der wird vermutlich am wenigsten benutzt, aber ist für die Reduzierung des Programmieraufwandes ungemein wichtig:
Welche Grafiken werden für die Menüs verwendet, welche Menüs gibts? Welche Objekttypen sind für die aktuelle Kultur gültig (Im Missi-Editor einer Inka-Kultur sollte kein Sience-Fiction-Gebäude auftauchen :D, in einer Städtebau-In-Europa-Kultur, brauchts vielleicht keine Götter), sozusagen der eigentliche Spiel-Editor?


Wie Ihr vielleicht merkt, versuche ich in meinen Gedankenspielen, ein solches Game möglichst wenig hard zu kodieren und möglichst viel (fast alles, bis auf die generellen Möglichkeiten der Basis-Objekttypen, die dann per Editor "freigeschaltet" werden) auf viele, verspielte Menschen, die gerne Editoren bedienen, verlagern möchte :8)
Hierfür braucht man dann (gerade während der Entwicklung) ein möglichst flexibles Datenformat, daß möglichst auch mit Objekten verschiedener Versionsnummern zurechtkommen kann und dabei auch (für die Entwicklung) ein hohes Maß an Transparenz bietet: -> idealerweise XML

Natürlich öffnet ein solches Vorgehen auch Möglichkeiten Tür und Tor, die so mancher als cheaten bezeichnet (mal eben ne Klartext-Datei editiert, schon kann mein Holzfäller fliegen und mit Laserstrahlen um sich schießen :eek::8)), aber erstmal gehts ja darum, der Fantasie freien Lauf zu lassen und mit möglichst vielen Leuten neue Welten zu erschliessen. Und wer gerne fliegende Holzfäller mit Lasergewehren zwischen seinen Dinosauriern laufen hat..... :massa:soller er doch ;)

Wenn/Falls wir mal mit Version XYZ eines solchen Games das Tor zur Multiplayer-Welt aufstoßen sollten, kann man immer noch überlegen, ob man das (dann hoffentlich ausgereifte) Speicherformat binär umsetzt oder eine Lösung a la "Der Server stellt/überprüft die Configuration" oderso, um ein solches cheaten zu umgehen...
Aber das Thema cheaten stell ich damit mal auf der Prio-Liste 3 Positionen hinter den letzten Eintrag ;).




Jo......................................................





Nu habbich mich mal wieder ein wenig verlabert, kann das? :8)

Eigentlich wollt ich nur schreiben, daß es auf jeden Fall n Editor gibt, wenns nach mir geht :D

[DragonDarkhawk]

Ich stell grad fest, daß ich durch die dauernden "Ablenkungen" durch die Arbeit über 2 Stunden an dem Posting gesessen hab :D

Jo, is richtig, daß man bei so ner Vorgehensweise die Aufgaben im Team einfach nach Vorliebe der Member verteilen kann ;)

Und das schöne ist:
Wenn erstmal die Spiele-Engine weiß, was sie denn so alles verarbeiten können soll, und was es für Grundtypen gibt, sprich die Schnittstelle in XML einmal so richtig definiert ist, dann kann sich im Prinzip sogar jeder seinen eigenen Editor in seiner liebsten Sprache basteln, wenn ihm danach ist /modules/RteMulti/pneditor/images/em.icon.tongue.gif

Funktioniert dann noch die Grafik-Engine vernünftig, bleibt grad mal noch die Spiele-Engine, die öfters, aber dann von einem nun möglicherweise sehr kleinen Team gepflegt werden würde/müßte /modules/RteMulti/pneditor/images/em.icon.clown.gif/modules/RteMulti/pneditor/images/em.icon.cool.gif
...und trotzdemkönnte es andauernd Erweiterungen und neue Welten zum Download geben :D


Jo, so stell ich mir die Vorgehensweise bisher so vor....

[Manni]

Frage zwischendurch............an DragonDarkhawk,

würde das Programm auf allen windows-Versionen laufen?

MfG
Manni

[tobing]

Win98 und WinXP sollten schon sein, dass müsste jeweils geprüft werden, nicht dass jemand anfängt, spezifische Sachen einzubauen. Aber so wie DDhawk das beschreibt, wird das Ganze ziemlich flexibel, so dass man sogar einen Editor in einer anderen Programmiersprache schreiben könnte...Delphi vielleicht, falls das jemand hat... hab schon viel Gutes darüber gehört, kenne es aber selbst nicht. Grundlage der Grafik sollte DirectX sein, da hab ich ein bisschen Literatur drüber und die SDKs auch.

[DragonDarkhawk]

Wenn DirectX benutzt wird, kann natürlich keine Garantie mehr für eine überall vorhandene Lauffähigkeit gegeben werden, kommt ja dann AUCH noch auf die Installationen an...

Das ist aber dann eine reine Frage der verwendeten Grafik-Schnittstelle...
Die eigentliche Spiel-Engine dürfte auf allen WinVersionen laufen... ("dürfte" deshalb, weil ich mit solchen Formulierungen eigentlich generell sehr vorsichtig sein möchte, trau-schau-windows ;))

Ich werde als erste Schnittstelle aber wohl noch nicht DirectXverwenden, sondern altmodisch auf den Windows-DCs rummalen, auch wenns dadurch langsamer wird, so daß zumindest während der ersten Entwicklungszeit noch keine Win-Update-Jagd losbrechen sollte, um sich ein erstes Bild machen zu können ;)
Der Geschwindigkeitsnachteil sollte gerade bei aktuellen Systemen nicht merklich sein..

[tobing]

Hmm. Einspruch, Euer Ehren!






Leider ist es so, dass die Wahl der Grafikschnittstelle das Design bis in die Tiefe beeinflusst und dass man die Spielengine von der Grafikengine nicht ganz trennen kann. Sonst werden wir unweigerlich in das Problem hineinlaufen, dass das ganze nicht mehr tut, wenn erstmal ein paar Hundert Häuser und ein paar Tausend Leute unterwegs sind. Die Sache mit dem Timer und den animierten Grafiken muss man wohl leider schon auf dem untersten Level mit eingebauen, weil auch andere Spielabläufe zeitabhängig sind, das sollte dann bitte schön auch zusammen laufen.


Was DirectX angeht, so sollten wir mindestens Version 8 benutzen, sind die Schnittstellen ziemlich gut ausgereift. Irgendwo hab ich mal einen Artikel gefunden, der beschrieb, wie man 2D in einer 3D-Engine darstellen kann... muss ich mal buddeln gehen. Der Upgrade auf ein neueres DirectX ist in fast allen Fällen äusserst problemlos zu machen und lohnt sich auch... also würde ich das nicht als Gegenargument gelten lassen. DX9 ist übrigens Teil von WinXP SP1.

[DragonDarkhawk]

...zumindest hab ich noch nichts davon gehört, daß mein Action-Ärgern 2 auf irgendeinem Windows (win3.11 mal ausgenommen ;)) nicht läuft und da hab ich auch die DC-Variante genommen...

[tobing]

Ich sach ja auch nicht, dass die DC-Variante nicht funktioniert - nur wird es in gross nicht mehr schnell genug laufen, das ist es. Vermutlich reicht es für den Anfang, wenn man auf DirectDraw aufbaut (das ist im Prinzip so ähnlich die DC, nur etwas moderner und viiiiiieeeellll schneller).


Aber für einen ersten Entwurfist das noch nicht so massgeblich, nur wenn wir dann wirklich anfangen wird es später schwierig, so eine Designentscheidung nochmal umzustellen.

[DragonDarkhawk]

Hmm. Einspruch, Euer Ehren!






Bin kein "Ehren" nur ein kleiner Anwendungsentwickler mitschönen Träumen;)

Leider ist es so, dass die Wahl der Grafikschnittstelle das Design bis in die Tiefe beeinflusst
beeinflussen - ja
vorgeben darf sie es aber deshalb trotzdem nicht!

und dass man die Spielengine von der Grafikengine nicht ganz trennen kann. Sonst werden wir unweigerlich in das Problem hineinlaufen, dass das ganze nicht mehr tut, wenn erstmal ein paar Hundert Häuser und ein paar Tausend Leute unterwegs sind. Die Sache mit dem Timer und den animierten Grafiken muss man wohl leider schon auf dem untersten Level mit eingebauen, weil auch andere Spielabläufe zeitabhängig sind, das sollte dann bitte schön auch zusammen laufen.


Dem widerspreche ich doch gar nicht?!?
Aber das Ausgabeergebnis wird bei beiden Varianten gleich aussehen (Isometrisch, also "Pseudo-3D", aber trotzdem immer noch 2D), das "Futter" (Grafiken) auch, die (virtuelle) Position der Objekte auf der Karte wird von der Spiele-Engine vorgegeben, lediglich die Framerate wird unterschiedlich sein.
Die Grafik KANN der Logik nicht vorauseilen, ist dementsprechend der Flaschenhals und ob die Spiele-Engine jetzt von Grafik-Engine A oder B gebremst wird, ist doch vollkommen unerheblich.
Daß eine langsamere Grafik-Engine spätestens im Laufe der Entwicklung durch das schnellst verfügbare ersetzt werden sollte, ist klar, weil der Spielbarkeit dienlich, aber ich seh immer noch nicht das Design-Problem dabei...
Klar, wenn wir statt Iso auf echt-3D (bsp. OpenGL) mit beliebigem Zoom und Blickwinkel, DANN würde das einen erheblich größeren Einfluß auf das Design haben, aber solange der einzige Unterschied in der erreichten Framerate zu finden ist, weil ein Sprite mittels DC statt DirectX im Speicher zusammengemixt und dann auf den Bildschirm gepinselt wird....

Vielleicht bin ich ja blind, aber welche Vorteile ausser dem Speed und welchen Unterschied bei Design(wenns vernünftig gekapselt ist natürlich) überseh ich da?!?


Was DirectX angeht, so sollten wir mindestens Version 8 benutzen, sind die Schnittstellen ziemlich gut ausgereift. Irgendwo hab ich mal einen Artikel gefunden, der beschrieb, wie man 2D in einer 3D-Engine darstellen kann... muss ich mal buddeln gehen. Der Upgrade auf ein neueres DirectX ist in fast allen Fällen äusserst problemlos zu machen und lohnt sich auch... also würde ich das nicht als Gegenargument gelten lassen. DX9 ist übrigens Teil von WinXP SP1.

Hab ich nix gegen, mussich mich nur auch erstmal reinlesen. Die bei meinem rumexperimentieren benutzten DirectX-2(!)-Befehle haben für eine schnelle Ausgabe eigentlich vollkommen ausgereicht ;)

Ich möchte hier nichts niederreden, bin ganz im Gegenteil für alles (und vor allem für begründete Argumente) offen, aber ich seh halt zur Zeit einfach noch keine Notwendigkeit, ein mit minimalen Mitteln erreichbares Ziel mit einer eierlegenden-Wollmichsau-Atomraketenabschußbatterie-mit-Sitz-im-Weltraum erschlagen zu müssen...

Belehr mich bitte eines Besseren, wenn ich mich jetzt hier um Kopf und Kragen rede, aber in erster Linie gehts uns doch um die Logik und die, so habe ich mal vernommen, solle immer schön von der View getrennt gehalten werden. Schaffen wir dies (und darin seh ich nunmal einfach noch nicht die Schwierigkeit), sollte ein Austausch der Grafik-Schnittstelle doch eigentlich kein Problem sein?!?......





Diese Nachricht wurde ge&auml;ndert von: DragonDarkhawk, 17.02.04 - 14:22

[tobing]

Gut. Soweit akzeptiert, jetzt bin ich mal gespannt auf einen ersten Wurf. Kennst Du http://www.gamedev.net ? Dort gibt es jede Menge Artikel und Links, ich schaue gerade mal wieder nach einer vernünftigen library, die DX brauchbar kapselt und eine Abstraktion bereitstellt, mit der man schon mal arbeiten könnte. Wenn ich da was brauchbares finde, werde ich es hier posten. CDX hab ich zB mal eine Weile beobachtet, aber so richtig toll scheint mir das nicht zu sein. Vielleicht ist es aber doch gut genug für unsere Zwecke... werd's mir nochmal anschauen. Gibt auch noch ein paar andere in der Richtung.

[DragonDarkhawk]

<P>Jo, ich bin auch gespannt :D
Wenn meine Frau öfter wieder so früh müde wird, wie gestern, könnte es vielleicht sogar noch diese Woche was zu gucken geben :8)

gamedev kenn ich flüchtig, war dort aber schon länger abstinent..
Wenn Du da ein bißchen die Recherche übernehmen könntest, wäre das echt super, hab (wie schonmal an anderer Stelle geschrieben) zu Hause kein INet und auf der Arbeit nicht SO die Zeit zum surfen, zumal ich auch noch ab und an als Admin und Entwickler ein Auge auf Ad Astra halten muß ;)

[Manni]

**Was DirectX angeht, so sollten wir mindestens Version 8 benutzen**

Mindestens? Na auch höchstens denke ich, weil ja offiziell DX 9 für win 98/98SE nicht mehr "gedacht" war/ist.......oder liege ich da krumm?

Es gibt hier noch einige Mämba, die mit 98 unterwegs sind.

MfG
Manni

[tobing]

Soweit ich weiss, funzt DX9 auch auf Win98SE.


Recherche ist kein Problem, hab auch das eine oder andere Buch dazu...

[Seebaer]

Ahoi











DX 9 funktioniert mit Win 98 !!!





Grüße





Seebaer

[DragonDarkhawk]

Hab mal ein Beispiel-XML für eine Objektdefinition getippert (fürs Testen und zur Veranschaulichung meiner wirren Gedanken), kann ich das Ding hier irgendwo abkippen?

[tobing]

Da stellst Du aber eine Frage... hmmm... posten geht vermutlich nicht so gut, wenn Du es als Download vorschlägst, vielleicht gezippt? Schreib das Datum mit in den Filenamen, dann haben wir auch gleich eine rudimentäre Versionierung. Wenn wir alte Files nicht mehr brauchen, können wir die Downloads ja wieder löschen.






Watt bessares fällt mir grad nich ein...

[DragonDarkhawk]

Issja nich so groß, ich poste das einfach mal jetzt (wird wohl nur durch Zeilenumbrüche blöd lesbar sein) und mach auf adastra mal ein verzeichnis für solche Sachen, bzw. lass meinen Schwiegervater da mal ne subdomain einrichten. Dann können wir da schonmal eine ersten Datenaustausch handeln ;)

File: wiese1.xml
Das ist ein erster Entwurf, der die Möglichkeiten einer Objekt-Definition über XML veranschaulichen soll.
Vollständigkeit natürlich noch nicht gegeben.
Die Spiele-Engine muß dann "nur" noch jedes Tag für jeden Basis-Objekttypen verstehen können und dessen Auswirkung umsetzen können, um so ein nahezu beliebiges Objekt ohne Programm-Änderung beschreiben und in eine Mission aufnehmen zu können.
------------------------------
!--
Generell: - Für allgemeine Lesbarkeit ist KEIN TAB erlaubt, statt dessen Einrückung=3spaces verwenden!
- JEDER Tag muß einen Abschluß-Tag besitzen
- Beginn- und Abschluß-Tag können in unterschiedlichen Zeilen stehen
- Spaces zwischen Tag und Wert, Wert und Schluß-Tag, sowie an Beginn und Ende von Zeilen werden ignoriert
- Groß- und Kleinschreibung wird bis auf Sprachtexte ignoriert
- bei Ja/Nein-Werten sind 1/0 und true/false erlaubt
- optionale Tags und Attribute werden bei Fehlen als Nichtsetzung interpretiert
bsp: Tag "begehbar" ist optional, fehlt er, ist das Objekt von nichts begehbar
dessen Attribut "gaengigkeit" ist optional, fehlt es, gilt die Einstellung für alle Gängikeitstypen
Tag "selectable" mit Wert "0" ist also gleichrangig mit einer Auslassung des Tags
-->






!-- Tag object> umschliesst ein darstellbares Objekt -->
!-- Attribut "type" ist Pflicht und ordnet das Objekt einem Basis-Objekttypen zu
bisher erlaubt: natur/infrastruktur/gebaeude/person/tier/fahrzeug -->
!-- Attribut "id" ist Pflicht und _muß_ für eine eindeutige Zuordnung kultur-kampagne-objekt
über _alle_ lokal verwendeten und damit bei objekt-austausch
über _alle_ je erstellten objekte _eindeutig_ sein
Vor Verbreitung selbst erstellter Objekte sind diese daher mit einer noch zu erstellenden
über Web-Browser zugänglichen Datenbank abzugleichen!
Komfortable Editoren stellen auf Anforderung eine Verbindung mit dem einstellbaren
Server her und erledigen diesen Abgleich automatisch ;)
Idealerweise sollte die ID mit dem Dateinamen der Definitions(XML)-Datei sowie den Anfängen
der Grafik-Dateinamen identisch sein -->
!-- Attribut "version" ist optional. Bei Mehrfach-Vorkommen einer id wird die Höchste Versions-Nr verwendet. -->
object type="natur" id="wiese1" version="1.0">





!-- Tag name> umschliesst die Bezeichnung des Objektes im Spiel -->
!-- Attribut "lang" ist Pflicht und ordnet den Text einer Sprache zu
bisher erlaubt: deutsch -->
name lang="deutsch">Wiese/name>





!-- Tag beschreibung> umschliesst die Langtext-Beschreibung des Objektes im Spiel -->
!-- Attribut "lang" ist Pflicht und ordnet den Text einer Sprache zu
bisher erlaubt: deutsch -->
beschreibung lang="deutsch">
Grüne Wiese.
Sie kann zu Fuß durchquert und für Vieh als Weideland genutzt werden.
/beschreibung>

!-- Tag selectable> ist optional und enthält true/false für Auswählbarkeit durch den Spieler -->
selectable>0/selectable>





!-- Tag begehbar> ist optional und enthält true/false -->
!-- Attribut "type" ist optional und beschreibt den Basis-Objekttypen, für den die Begehbarkeit gilt
Bei Auslassung gilt die Begehbarkeit für alle Objekttypen -->
!-- Attribut "gaengikeit" ist optional und beschreibt die Mobilitätsstufe des Objektes, AB DER die Begehbarkeit gilt
Eine Person ohne Ziel oder ein Rennrad könnten bspweise eine gaengigkeit von 0 haben, ein Geländewagen von 5 -->
begehbar type="person" gaengigkeit="2">1/begehbar>
begehbar type="fahrzeug" gaengigkeit="3">1/begehbar>
begehbar type="tier">1/begehbar>





!-- Tag downgrade> ist optional und enthält die _id_ des Objektes zu dem das aktuelle im Falle
eines Wertverlustes mutieren kann.
Das downgrade-Objekt muß im Missions-Editor eingebunden worden sein, damit die Mutation stattfinden kann.
Unbekannte IDs werden ignoriert -->
downgrade>magergras5/downgrade>





!-- Tag upgrade> ist optional und enthält die _id_ des Objektes zu dem das aktuelle im Falle
einer Wertsteigerung mutieren kann.
Das upgrade-Objekt muß im Missions-Editor eingebunden worden sein, damit die Mutation stattfinden kann.
Unbekannte IDs werden ignoriert -->
upgrade>wildblumenwiese6/upgrade>

!-- Tag resource> ist optional und enthält den Maximalwert der in "type" angegebenen Resource -->
!-- Attribut "type" ist Pflicht und beschreibt die Basis-Resource, für die der Wert gilt -->
!-- Attribut "wachstum" ist optional und enthält die Resourcen-Erneuerung pro Zeiteinheit -->
!-- Attribut "start" ist optional und enthält den Startwert einer einer variablen Resource -->
!-- Attribut "downgrade" ist optional und enthält den Resourcen-Grenzwert, ab dem das Objekt zu einem
niederwertigerem Objekt mutiert (so vorhanden) -->
!-- Attribut "upgrade" ist optional und enthält den Resourcen-Grenzwert, ab dem das Objekt zu einem
höherwertigerem Objekt mutiert (so vorhanden) -->
resource type="heu" wachstum="2" start="75" downgrade="50" upgrade="90">100/resource>
resource type="kraeuter" wachstum="0.1" start="5" upgrade="10">10/resource>





!-- Tag grafik> ist für ausrichtung 1-4 in ansicht "normal" Pflicht, sonst optional und
umschliesst den relativen Pfad zu einem Bitmap des Objektes -->
!-- Attribut "ausrichtung" [1(Nord)-4(West)] ist Pflicht und ordnet der Grafik die zugehörige Ausrichtung zu -->
!-- Attribut "ansicht" ist für Wert "normal" Pflicht, sonst optional und ordnet der Grafik die zugehörige Ansicht zu
bisher erlaubt: normal/reduziert/selektiert
Das Bild zur ansicht selektiert wird über das Bild zu ansicht normal gelegt, muß also nur einen Rahmen enthalten -->
!-- Attribut "double" ist alternativ zur Angabe eines Bild-Pfades möglich und zeigt an,
daß der Tag-Wert auf das _vorhandene_ Bild aus "ausrichtung->tag-wert"
der _gleichen_ ansicht verweist
Diese Vorgehensweise ist der Doppeltvergabe eines gleichen Bildes aus
Speicherplatzgründen vorzuziehen -->
grafik ausrichtung="1" ansicht="normal">img/natur/wiese1.bmp/grafik>
grafik ausrichtung="2" ansicht="normal" double="true">1/grafik>
grafik ausrichtung="3" ansicht="normal" double="true">1/grafik>
grafik ausrichtung="4" ansicht="normal" double="true">1/grafik>
/object>





---------------





Diese Nachricht wurde ge&auml;ndert von: DragonDarkhawk, 18.02.04 - 10:19

[tobing]

Schick schick... hast Du schon eine Vorstellung, welche Tags für die Objekte da sein sollen? Wenn es um Grafiken geht, was ist mit animierten Grafiken für alle Objekte - also nicht nur Leute, die rumrennen. Genauso kann man doch auch die Wiesen-Tiles ein bisschen animieren... oder das eine oder andere Gebäude...

[DragonDarkhawk]

Für Animationen könnte man zB den Grafik-Tag der jeweiligen Ansicht um ein durchnummeriertes Attribut "anim" erweitern. Bei Abschaltung der Animationen für Performance durch den Spieler könnte dann dauerhaft das pic mit anim="1" genommen werden.

Sähe dann so aus:

grafik ausrichtung="1" ansicht="normal" anim="1">img/natur/wiese1_1.bmp/grafik>
grafik ausrichtung="1" ansicht="normal" anim="2">img/natur/wiese1_2.bmp/grafik>
grafik ausrichtung="1" ansicht="normal" anim="3">img/natur/wiese1_3.bmp/grafik>

Ist die Animation auf einen kleinen Teil der Grafik beschränkt (bspweise ein sich drehendes Mühlrad), könnte man auch nur den animierten Teil in die anim-Grafiken pinseln und das über die normal-Ansicht blenden (beispiel mit gleichgroßen Bitmaps):

grafik ausrichtung="1" ansicht="normal">img/gebauede/muehle4_norm1.bmp/grafik>
grafik ausrichtung="1" ansicht="normal" anim="1" overlay="true">img/gebauede/muehle4_norm1_anim1.bmp/grafik>
grafik ausrichtung="1" ansicht="normal" anim="2" overlay="true">img/gebauede/muehle4_norm1_anim2.bmp/grafik>

und um die Bitmap-Größe dabei noch zu reduzieren, wären auch zusätzliche positions-Attribute innerhalb der norm-ansicht denkbar (beispiel norm-bmp 50x70pixel, anims 20x20pixel):

grafik ausrichtung="1" ansicht="normal">img/gebauede/muehle4_norm1.bmp/grafik>
grafik ausrichtung="1" ansicht="normal" anim="1" overlay="true" posx="30" posy="40">img/gebauede/muehle4_norm1_anim1.bmp/grafik>
grafik ausrichtung="1" ansicht="normal" anim="2" overlay="true" posx="30" posy="40">img/gebauede/muehle4_norm1_anim2.bmp/grafik>

Was generell noch für Grafiken relevant ist, ist die Transparenzfarbe.
Bei meinen test-Grafiken hab ich Standardmäßig pink benutzt (0xFF00FF).
Wird diese Farbe aber anderweitig im Bitmap verwendet, kann eine andere Farbe als transparenz definiert werden

grafik ausrichtung="1" ansicht="normal" transparenz="0xAA3B4F">img/gebauede/muehle4_norm1.bmp/grafik>

Ein zusätzlicherTag der zB für die Grafik-Engine von Belang wäre, wäre:
die Größe in Felder des Objektes (bspweise eine Fabrik mit 2x3 Felder)
das könnte dann sowas sein wie:

fields ausrichtung="width">2/fields>
fields ausrichtung="depth">3/fields>

Standard wäre natürlich 1 (muss also zB bei der Wiese nicht angegeben werden).

Auf diese Weise lassen sich eigentlich beliebige Eigenschaften eines Objektes, und damit dann auch das Verhalten des Objektes definieren, wobei natürlich bei der Programmierung der Spiele-Engine ein hübscher Aufwand wartet /modules/RteMulti/pneditor/images/em.icon.blackeye.gif
Aber man muß ja nicht alles auf einmal umsetzen und kann/muss das schön nacheinander und pö-a-pö einbauen.

[tobing]

Andere Frage: Zum Schreiben/Lesen von XML-Files soll/kann welche Software in Frage kommen?

[DragonDarkhawk]

Im moment benutz ich noch meinen UltraEdit :D

Nee, dafür muß natürlich jedes Prog eine Schnittstelle besitzen, also das Spiel (nur lesen, evt.schreiben für Spielstände) sowie alle Editoren (lesen/schreiben).
Ein externes Programm dafür macht keinen Sinn, da die Daten ja irgendwie ins Spiel bzw. den Editor müssen (und wieder raus) und man mit einem externen Programm höchstens eine zusätzliche Schnittstelle zum Editor undso entwickeln müßte.
Wie man sich die schnittstelle besorgt, bzw. umsetzt, ist jedem Programm-Autor selbst überlassen.
Ich schreibe mir dafür beim Engine-Prototypen grademeine eigene Schnittstelle.
Mal gucken, evt. kann ich ja daraus ne DLL und/oder ein LIB machen, so daß diese dann nur noch von anderen Autoren eingebunden werden müßte, aber prinzipiell halte ich es für einfacher sich mal eben die Schnittstelle dafür selbst zu hacken.
Die Tag-und Attribut-Definitionen und damit die möglichen Feld-Definitionen der Objekte müssen in den Editoren ja eh bekannt und gehandelt sein, da kann man auch flott die entsprechenden schreib/lese-funktionen dazubasteln.

Ich geb ja dann auch den Quellcode raus, nur mach ich die Studie grad doch flott mit dem Builder, müßte man 2-3 VCL-Klassen durch MFC ersetzen um den Schnittstellen-Codemit VC++ zu nutzen...

[koppi]

HalloDragonDarkHawk,

willst du nicht auch nach Hamburg zu unserem Treffen kommen ? Wäre doch eine Super Gelegenheit ein bischen Brainstorming zu machen.

[tobing]

Selber programmieren würd ich nicht machen wollen. Es gibt bei Sourceforge eine library zum Parsen von XML-Files: http://sourceforge.net/projects/expat/ die sollten wir verwenden. Ist sicher hinreichend tauglich für unsere Zwecke. XML schreiben muss man dann doch selbst machen, das sollte aber soo schwierig nicht sein. Wer's als erstes implementiert wird hiermit dazu verdonnert, das als library zur Verfügung zu stellen - zumindest was geht.


Ach so, klaro, wäre supertoll, Dich in HH auch kennenzulernen...

[DragonDarkhawk]

Für das coden meines PHP-XML-Parsers hab ich inklusive testen ungefähr 2 Stunden gebraucht, für die C++-Version rechne ich eher weniger denn mehr Zeit ein, wenn ich das gegen die evt. benötigte Zeit für Download, Installation, Einlesen, Einbindung des sourceforge-projekts rechne, mach ich wenigstens den Versuch des selbst codens ;)

Der Parser für uns braucht ja nicht mit x-beliebigen XML-Files arbeiten, er braucht ja nur Dateinamen, Kommentare, Tags, Attribute und Werte zu kennen :8)
Die spätere Zuordnung der Parse-Ergebnisse zu Objekten und deren Membern muß auch beim sourceforge-projekt gemacht werden und ergibt da keinerlei Ersparnisse.

Was Hamburg angeht: Bin zZ ohne Auto und knapp bei Kasse, das macht eine Teilnahme von Düsseldorf aus etwas schwierig, zumal ich auch erstmal gucken müßte, ob Frau und Kinder ein-zwei oder gar mehr Tage Abwesenheit des Papas akzeptieren wollen würden ;)
Wäre aber schon ne verlockende Idee :massa:

[tobing]

Für einen Prototypen ist das OK. Aus meiner Erfahrung weiss ich aber, dass solche schnellen Anfänge sich im Laufe der Zeit auswachsen, und am Ende wäre es dann schneller und einfacher gewesen, eine library zu verwenden.

Hab vorhin gesehen, dass es http://www.isometrix.org noch gibt - vielleicht ist das auch eine brauchbare Startbasis? Ich schau's mir mal an...

[SuperNicky]

Jungs, ihr macht mich fertig !

@DDH : Tja , leider verloren, denn ICH habe seit Oktober wieder ein Auto, und mein Weg von AC nach HH führt mich eh gewohnheitsmäßig über Düsseldorf !
D.h. du kannst dir die Sache durchaus noch überlegen und ggf. deine Familie überzeugen, dich von dannen ziehen zu lassen. Es sind ja auch noch ein paar Tage bis dahin.

Und bis dahin - seit weiter fleissig ! (Ich würde ja gerne etwas konstruktiveres zum Besten geben, aber leider kann ich euch schon seit gestern nicht mehr wirklich folgen... schäm...)

[SuperNicky]

P.S. : Ich melde mich hiermit ab bis Aschermittwoch.

Alaaf !!!

(Wehe, es wagt jemand mit Helau zu antworten, insbes. Menschen aus D-Dorf http://www.staedtebauen.de/modules/Arena_Forum/images/smiles/icon_biggrin.gif (javascript: x())...
Also, trinkt nicht soviel, ihr wisst, wir sind alle nicht mehr die Jüngsten und brauchen unsere grauen Zellen noch ...)

Und noch en drejfach :

Oche - Allaaf ! Oche -

[DragonDarkhawk]

Hellblau - Hellblau! (ist kein Helau :D)

Von wann bis wann fährste denn nach HH? (sollten wir vielleicht im treffen-Thread weiterverfolgen ;))

[Seebaer]

Ahoi





Warum macht ihr nicht erstmal ein AddOn zu DEK? Es gibt mehrere entwickelteGebäude (zu sehen auf Screenshoots vor DEK Release) die nicht verwendet wurden. Mal nachfragen ob man die überlassen bekommt kostet ja nichts.











Grüße





Seebaer

[Manni]

***seit gestern nicht mehr wirklich folgen***.....da muss sich keiner schämen SuperNicky.........ich kann schon wesentlich länger nicht mehr folgen....... :p

Und dann auch noch das unentwegte Schleppen der Körbe dabei!!! tststs :p.......wie der Mann das alles schafft?!

Diese Nachricht wurde ge&auml;ndert von: Manni, 18.02.04 - 20:27

[tobing]

Na na. Also nun lasst Euch mal nicht von so einem Technik-Gefasel ins Bockshorn jagen... gute Ideen aller Sorten sind natürlich auch weiterhin gefragt! :)

AddOn kann man nicht ohne Erlaubnis und Unterstützung des Herstellers machen, und da glaube ich nicht dran. :(





Ob das Schleppen der Körbe so schwer ist, hängt natürlich auch von der Körbchengrösse ab... ;) :D

[Flilian]

@ SuperNicky
Du hast Dich sehr tapfer gehalten (immerhin als einzige Frau!!!), Anerkennung!
Und Du fährst tatsächlich über Karneval nach HH - die einzige Region in Deutschland, wo man Karneval glatt verpaßt, wenn man nicht die Fernsehübertragungen aus Köln und Mainz sieht? Willste flüchten vor dem Getümmel?

[Avra]

@ SuperNicky:

"Ich würde ja gerne etwas konstruktiveres zum Besten geben, aber leider kann ich euch schon seit gestern nicht mehr wirklich folgen"

<FONTcolor=#000066>Ich meinerseits hab von Anfang an nur chinesisch oder altgriechisch verstanden, was konstruktives diesbezüglich ist von meinereins nicht zu erwarten, ich find es aber echt toll was da grade abgeht, bleibt dran Burschen, niemals nicht aufgeben, ich versprech ich spiel alles was ihr produziert und wenns in 10 Jahren ist. Glück auf, oder wie sagt man da?

[tobing]

Also wirklich. Der Technik-Talk ist ja nur eine Seite des Projekts, dabei soll aber doch ein Spiel rauskommen! Ich gehe mal davon aus, dass wir zum Anfang im Wesentlichen eines der Staedtebauspiele nachprogrammieren werden, oder sowas wie den gemeinsamen Nenner der Spiele. Gewisse Dinge laufen ja in allen Spielen gleich ab. Das muss man aber mal genau beobachten und aufschreiben, wie es läuft, damit man es dann auch richtig programmieren kann. Dabei könnt ihr schon alle was beitragen, denn Spielen tut ihr ja wohl alle und damit wisst ihr auch, wie das Spiel abläuft, oder? Und darüberhinaus wollen wir Ideen sammeln, wo man Abläufe verbessern kann, oder einfach ändern, und da haben die meisten hier vermutlich auch den einen oder anderen Wunsch...

[DragonDarkhawk]

Volle Zustimmung tobing! http://www.staedtebauen.de/modules/RteMulti/pneditor/images/em.icon.smile.gif

Mal kurz was vom Zwischenstand bei mir zu Hause:
Dir Arbeit/Planung an den Engines ruht momentanbei einem noch recht frühen Stand.

Grund:
Vermeidung von Zusatzarbeit, sprich manuelles Erstellen von Test-Umgebungen und -Objekten.

Daher:
Vorziehen der Editoren in minimal-Funktionen, sowie Schnittstellen-Festlegung der entsprechenden ersten Rahmenwerte (sowas wie im wiese1.xml-Posting von mir).

Der Objekt-Editor ist kurz vor Fertigstellung
(Fertigstellung im Sinne von: Man kann erste Test-Objekte erstellen, laden/bearbeiten, die man auf eine ISO-Karte/Test-Mission klatschen könnte, enthält dann natürlich nochkeine komplexeren Objekteinstellungen -für die Engine-Prototypen werden erstmal nur Grafik-Einstellungen und Auswählbarkeit, später Beweglichkeit der Objekte benötigt).

Missions- und Kultur-Editor werde ich in entsprechender, rudimentärer Minimalfunktion ebenfalls noch vor der Weiterentwicklung der Engine-Prototypen machen, wobei diese erstmal maximal die Funktionalität besitzen werden, eine Objektverfügbarkeitsliste zu verwalten sowieeine einfache Kartenerstellung für Testzwecke zu ermöglichen (Erste Schnittstellendefinitionen in XML natürlich inklusive).

Vom Zeitplan sieht es nun so aus:
Übers Wochenende haben wir ab heute Besuch von meiner kleinen Schwägerin, so daß ich noch nicht GENAU weiß, wieviel Zeit ich so um die Mitternachtsstunden zur Verfügung habe :D
Dadurch: VIELLEICHT bekomm ich den Objekt-Editor heute noch in einen Zustand, in dem ich ihn Euch morgen das erste mal zum Ausprobieren und rumprobieren und mir Test-Objekte erstellen und schicken präsentieren kann. Falls nicht, will ich ihn zusammen mit den anderen Editoren spätestens Montag uploaden können (Am Wochenende bin ich immer INet-los).
Das erste Look-and-Feel der Engines werdet ihr daher wohl frühestens Mitte nächster Woche erleben können, der "spätestens"-Zeitpunkt hängt einfach von den mir dafür von der Family zur Verfügung gestellten Zeitscheiben ab ;)

[DragonDarkhawk]

Flilian schrieb:
Und Du fährst tatsächlich über Karneval nach HH - die einzige Region in Deutschland, wo man Karneval glatt verpaßt, wenn man nicht die Fernsehübertragungen aus Köln und Mainz sieht? Willste flüchten vor dem Getümmel?

Ich hab das eher so verstanden, daß Sie sich so komplett in genau dieses Getümmel stürzen will, daß sie nich mals mehr an den Rechner kommt :D

[tobing]

...gespannt bin...

[DragonDarkhawk]

Also heut wird leider noch nix aus dem upload des Editors.
Hab mich ein wenig mit der Tag-Attribut-Auswertung (der Parser tut jetzt auf jeden Fall schonmal komplett ;)) und ein paar (eigentlich unnötigen) Design-Fragen aufgehalten.
Jedenfalls sind die Grafiken und das Speichern noch nicht im Editor, da macht ein uploaden noch keinen Sinn.

Montag also.

[cassandra2]

Hallo ihr Spielebastler
Tobing,Du soltest dir nochmal die Forenseite OLIVEN, ÖL UND ATHENE raussuchen, 20.9. ca 9.00 Uhr. Scheint als wär es jetzt soweit.http://www.staedtebauen.de/modules/RteMulti/pneditor/images/em.icon.smile.gif
LG Cassy





9.34 Uhr um genau zu sein.





Diese Nachricht wurde ge&auml;ndert von: cassandra2, 20.02.04 - 13:56

[tobing]

Stimmt ja: http://www.staedtebauen.de/modules.php?op=modload&amp;name=Arena_Forum&amp;file=index&amp;action=viewtopic&amp;topic=74&amp;start=25

[DragonDarkhawk]

@tobing &amp; cassandra2: jaja, gute Ideen kommen halt immer wieder hoch :D

@everyone:
Soderle, nachdem ich nun 1. vergessen hatte, daß ja am Montag highlife in den Straßen war und ich mir deshalb Urlaub genommen hatte um meinen Kleinen ein paar Kamelle-Jagd-Möglichkeiten zu bieten und dann 2. gestern auch noch Urlaub brauchte, weil meine Frauso kränklich war, saß sie statt der Kinder nur noch das Bett hüten konnte, kann ich nun endlich wenigstens eine "So ungefähr wirds mal aussehen"-Version des Objekteditors uploaden.

Ist aber leider nicht die aktuellste Version, weil sich beim enntehmen der Diskette die Mechanik meines Disk-Laufwerkes verabschiedet hat http://www.staedtebauen.de/modules/RteMulti/pneditor/images/em.icon.angry.gif. Werde die Tage also noch ein büschn schrauben müssen,damit eine wirklich vernünftige Version zum Download bereitsteht... *seufz*

Die Funktionalitäten beschränken sich in der hiesigen Version noch auf Basis-Objekttyp "Natur" und die Grafik-Seite unter "Eigenschaften" ist noch nicht an die load- und speicher-routingen angebunden.

Ich lade das ganze aber trotzdem mal hoch,damit Ihr Euchschonmal einen kleinen Einblick verschaffen könnt, was ich da grad so am Basteln bin, hoffe das ist okay...:8)

Die Sourcen sind mit dem C++-Builder erstellt, wer den nicht hat, aber Code-Interessiert ist, sollte durch die source- und Header-Dateien aber trotzdem durchblicken können ;)
(Vielleicht hätte ich die noch ein wenig äufräumen sollen?!? :massa:)

Nuja, Ihr könnt mir ja vielleicht schonmal ein wenig Feedback dazu genen, auch wenn ich mir erhofft hatte, Euch heute eine vollständigere Version anbieten zu können....

[DragonDarkhawk]

Ich hab Sourcen und Application jetzt mal als Download unter "Tools" vorgeschlagen, aber vielleicht kann man dafür ja eine eigene Rubrik erstellen?!?

[cassandra2]

Hallo DDhawk

Wenn Du Kamelle sammeln kannst von wo aus dem Rheinland kommst Du?

LG Cassy

[tobing]

Die Downloads sind da, ich hab eine neue Kategorie Development eingerichtet.

[DragonDarkhawk]

<P>@Cassy: Aus Hilden (zumindest seit nem 3/4-Jahr). Und Du?

@tobing: schick-schick-schick :D
Jetzt bin ich der Gespannte;)(Bin Feedback-Süchtig :lol: ,auch wenndas erstmal nur ne Vorabversion ist /modules/RteMulti/pneditor/images/em.icon.tongue.gif)

[DragonDarkhawk]

Wo wir grad schomma dabei sind, wie wärs wenn wir dem Kind so langsam mal einen vernünftigen Namen geben?!?:massa:

Habs bis jetzt ja erstmal nur einfach "staedtebauen" bzw. "staedtebauen- selfmadegame" genannt, aber irgendwie weiß ich nicht so recht, ob das so das richtige ist...
Sollte ja was sein, was das Ganze als Städtebauer-Gamedeveloper-Framework identifiziert und später bei fertigen Kulturen/Kampagnen, dem jeweiligen Kulturnamen als Identifizierer vorangestellt werden könnte...
Also sowas wie "Städtebauer", was dann für die Spieler "Städtebauer - China", "Städtebauer - Inkas" oder "Städtebauer - Marsmission" heißen tät....

Jo... was meint Ihr? http://www.staedtebauen.de/modules/RteMulti/pneditor/images/em.icon.smile.gif

[DragonDarkhawk]

Aaaaaainen habbich noch, aaaainen habbich noch:

Was noch immens wichtig wäre, wäre eine Definition, wie groß wir unsere Felder machen...
Also zB 64 Pixel breit und 32 hoch oderso....

Ich hielte es für die Objekterstellung hilfreich, wenn wir uns da auf eine einzige Größe für alle Auflösungen festlegen würden, weil sonst 1. das eh schon super-arbeitsintesive Bildchen-erstellen natürlich exorbitant an Mühe aufwendiger würde, 2.die Gesamtgröße der jeweiligen Downloads (eigentlich ja unnötigerweise) entsprechend steigen und 3.bei Hinzufügen einer Auflösung sämtliche "alten" Objekte nochmals überarbeitet werden müßten...

Die im Editor-Zip enthaltenen Beispiel-Pics von mir sind vielleicht ein wenig klein geraten, da sollten wir was größeres nehmen, was bei allen Auflösungen halbwegs schicke Darstellungen ermöglicht. (BTW: die Beispiel-Pics hab ich auf die Schnelle mit Paint gepixelt, einfach um mal was zum Testen und rumspielen zu haben, die sollen natürlich nicht das non-plus-ultra unserer späteren Grafik darstellen :lol: )

[SuperNicky]

@Flilian : das war ein stille -Post - Missverständnis : die Hamburg - Frage von DDH bezog sich auf das Städtebautreffen im Mai. Über Karneval bin ich im Rheinland geblieben. Ich habe zwar nicht soo viel gefeiert (obwohl ich schon "Alaaf" geschrieen habe, als mein Herr und Meister am Altweiberdonnerstag (der hier in AC übrigens "Fettdonnerstag" heißt) nach Hause kam und mir gestand, dass er mein Auto zu Schrott gefahren hat), habe aber zu Hause auch keinen vernünftigen I-Net Anschluss (nur ein GPRS - Handy und das ist teuer und langsam).So, alle Klarheiten beseitigt.Und jetzt schau ich mir mal an, was der DDH da so erarbeitet hat.Bis später.

Diese Nachricht wurde ge&auml;ndert von: SuperNicky, 25.02.04 - 13:33

[DragonDarkhawk]

Mmmmh...
Ums schonmal vorwegzunehmen:
Die aktuell uploadete Version hat, wie ich grade gesehen hab, noch einen dummen und einen doofen Fehler, die in der akutellen Version bei mir zu Hause bereits behoben sind:
der dumme Fehler: bei denTags "name" und "beschreibung" fehlt beim speichern das attribut lang="deutsch" (dadurch werden beide tags beim Laden nicht ausgewertet). Das Attribut muß daher leider manuell nachgetragen werden http://www.staedtebauen.de/modules/RteMulti/pneditor/images/em.icon.angry.gif
der doofe Fehler: Unter Grafik wird das Startverzeichnis für die OpenPictureDialog gedoppelt. Gibt beim Klick auf den Button "..." ne Fehlermeldung, ist sonst nich weiter schlimm.

Wie gesagt, zu Hause hab ich das bereits gefixt, kommt dann hier hoch, sobald ich wieder n funktionierendes Disk-Laufwerk im Rechner hab.... *seufz*

[SuperNicky]

Name : abgekürzt ergäbe sich DEUBOSS, was fürs erste sicherlich als Arbeitstitel taucht;
Feedback : tschuldigung, geht nicht so schnell. Ich glaube, ich halte mich erstmal kusch, während ich am Verständnis arbeite (habe zum Glück momentan viel Zeit ;)
Falls noch jemand etwas für sein Verständnis tun möchte : unter
http://www.rz.rwth-aachen.de/mata/veranstaltungen/seminar_dv_0304.php
gibt es ganz unten einen XML - Vortrach (und sonstige Nettigkeiten) zum Downloaden und Durchlesen; und ein Parser ist ein Parser ist ein Parser. Allerdings ermangelt es mir noch sehr an Phantasie, wie man daraus ein Spiel schmieden tut.
So, genug gealbert, ich muss jetzt weiter an meinem Grundverständnis arbeiten, bis morgen !

[DragonDarkhawk]

Name : abgekürzt ergäbe sich DEUBOSS, was fürs erste sicherlich als Arbeitstitel taucht;
Als Arbeitstitel schon, aber warum nicht bereits ein wenig über eine endgültige Bezeichnung philosiphieren ;)

und ein Parser ist ein Parser ist ein Parser.
Volle Zustimmung. :lol:
Messe dem nicht zuviel bei, ist einfach nur als Schnittstelle gedacht, um die Definitionsdateien, also das XML zu lesen und (dann dem Writer) zu schreiben.
Irgendwie müssen die Daten ja aus der Datei in den Speicher und umgekehrt ;)

Allerdings ermangelt es mir noch sehr an Phantasie, wie man daraus ein Spiel schmieden tut.
Mit dem XML eigentlich gar nicht. Für XML als Datei-Format hab ich mich ganz einfach entschieden, weil man damit sehr flexibel und vor allem OHNE KONVERTIERUNG über verschiedene Versionen Daten definieren kann.
Ein starres Datei-Format, bei dem man beispielsweise sagt: An Stelle 18-22 einer Zeile steht mit führenden Blanks die Breite in Feldern eines Objektes oder die linksbündig die ID als String, schränkt 1. zB die maximal möglichen Längen eines Feldes extrem ein und 2. bräuchte JEDE Erweiterung des Dateiformates (weil beispielsweise ein Feld dazukommt oder vergrößert wird) eine Konvertierung ALLER älterer Dateien.
Klar könnte man auch hingehen und versuchen bspweise eine DB zu bemühen etc... aber dann bräuchte man wieder für jedes Prog, daß auf die Daten zugreifen will die entsprechenden Treiber etc und auch dort müßten Konvertierungen stattfinden.
Der größte Vorteil von XML aber ist ganz klar, daß XML ja nur die Definition für Datendefinitionen darstellt und man sich die Datendefinitionen selbst festlegen kann(Feld (==tag) xxx ist numerisch und kann Attribut yyy mit Wert zzz enthalten etc...).

Kommt ein Tag hinzu oder ändert sich der Inhalt, brauchts das jeweilige Programm nur zu verarbeiten, bzw. bei älteren Dateien ohne das Feld vernünftige Vorbelegungen zu haben, die Dateien bleiben aber lesbar, das ist das schönste daran ;)

Das Spiel schmieden tut man am Ende aus den Daten, die man den geschriebenen Dateien entnimmt. Wie diese gespeichert sind (fixes Format, Datenbank, XML, ini-Datei) ist dabei erstmal völlig egal. Hat man aber ein flexibles Format, wie XML, ist es ganz simpel viel-viel einfacher im Laufe der Entwicklungzusätzliche Daten mit einzubauen und kann sich so von einer simplen Anhäufung von Funktionen (Häuschen setzen und angucken, wie es auf ner Wiese steht) zu einem richtig komplexen Spiel entwickeln (ins Häuschen können Leute einziehen, das Häuschen bekommt einen rauchenden Schornstein, der Bäcker bringt Brötchen und der Milchmann stellt Flaschen vor die Tür, die von Meisen aufgebrochen werden :lol: )



...



Mmmmh, war das jetzt verständlich oder mauser ich mich immer mehr zur Laberbacke?!? :lol:

[SuperNicky]

Auf jeden Fall ! (Laberbacke ! :) )
So weit hätte ich es denn ja jetzt kapiert, bleibt also wieder die Frage : woher eine Engine kriegen und nicht stehlen.
Oder habe ich etwas verpasst ? (Z.B. dass der Engine - Bastler im Moment keine Zeit hat, aber im Prinzip schon drüber nachdenkt ? )
Hach, ist dat allet aufregend !

[tobing]

Soweit meine Recherchen bisher gediehen sind, kommen wir wohl nicht darum herum, eine Engine selbst zu basteln. Der Ansatz, so viel wie möglich per XML-Files zu beschreiben und die Engine das einfach lesen zu lassen, ist aber insofern sehr gut, weil man auf diese Weise alle möglichen Editoren unabhängig voneinander bauen kann, und dies sogar in verschiedenen Programmiersprachen.


Hab mir die Sachen von DDHawk mal angeschaut - der C++-Builder macht seine Sachen anders aber von der Machart her genauso wie das Visual Studio mit MFC, um solche Sachen zu bauen braucht man also unbedingt einen C++-Builder. Benutzt man die Wizards vom VS, dann braucht man natürlich auch unbedingt davon einen... womit ich mal wieder die Frage nach der Entwicklungsumgebung aufwerfen möchte... denn ob ein freier Compiler und eine freie IDE in Frage kommen, weiss ich leider nicht. Diese Entscheidung hat, zumindest was die Engine angeht, fundamentale Auswirkungen, darüber müssen wir also recht bald befinden.





Inzwischen habe ich so einiges an Material gefunden. Es gibt Libraries zur Bildbearbeitung, also um Bildchen in verschiedenen Formaten zu lesen und zu schreiben. SDL ist da mein Favorit, wird auch von etlichen anderen Projekten benutzt. Dann gibt es einige durchaus brauchbare Spielchen, die als Vorlage für ein 2D-ISO-Spiel herhalten können, welches ich davon bevorzuge, weiss ich noch nicht. Sind aber fast alle auf VS6.0 aufgesetzt und alle basieren auf DirectX. Dazu habe ich auch noch 2 Bücher zu Hause, und da hab ich auch schon mit der Lektüre begonnen. Sobald ich mehr Details weiss oder einen Favoriten habe, werde ich das natürlich hier posten... und ich rate, mal in den Artikeln bei http://www.gamedev.net (http://www.gamedev.net/) zu schmökern, da stehen einige brauchbare und interessante Artikel.





Die Tiles sollten wir übrigens 62x32 gross wählen, bei der Farbtiefe sollten zwar 16bit reichen, aber 24bit scheint meistens verwendet zu werden. Irgendwo hab ich ein Paper gelesen, das beschreibt, wie man 32x32 rechteckig in 64x32 rautenförmig umrechnet, weil es ja einfacher ist, ein rechteckiges Bild zu malen und das dann in eine Raute umzuwandeln. Denn: Die Rauten müssen ja genau zusammen passen, damit es keine schwarzen pixeligen Löcher dazwischen gibt...





Und noch was: Mit den XML-Files erstellen wir schon Spielbeschreibung und Details, daran können sich auch viele Leute beteiligen, ohne programmieren zu müssen. Wenn man zB ein Gebäude beschreibt, dann muss man zB definieren, welche Läufer losgeschickt werden, wann dies geschieht, wie sich das Gebäude verändert, wenn die 'Desirability' der Umgebung sich verändert, wie weit die Läufer laufen, was das Gebäude zur Funktion braucht und so weiter... Wäre mal eine gute Übung, alle diese Zahlen für eines der bekannten Spiele aufzuschreiben. Wirklich alle Zahlen! Das sind nämlich eine ganze Menge...





Mahlzeit.

[tobing]

Noch etwas, das man schon machen kann: Die Screens müssen entworfen werden. Ich denke, für den Anfang sollte es ausreichen, die gewohnten Standard-Windows-Controls zu verwenden, später können wir irgendwann mal daran denken, alles kulturspezifisch einzufärben und mit Hintergrundbildern zu versehen. Das sieht dann zwar zu Anfang so aus wie eine normale Windows-Anwendung, aber für den Spielspass sollte das keine grosse Rolle spielen. Im Prinzip sieht das dann so aus, dass es ein Menüsystem gibt (welche Menüs wollen/brauchen wir?), auf der rechten Seite wie gewohnt eine Übersicht (was findet sich da alles?) und die weiteren Menüs und Optionen (welche? und was davon definiert sich über ein XML-File?), und dann gibt es da noch die Detailscreens für jedes Item auf der rechten Seite.


Und noch was: Wenn wir alles per XML beschreiben, dann fängt das bei den Objekten an, schliesst die Beschreibung der Kultur ein, mit allen Besonderheiten (zB PlugIns für die Engine, damit spezielle Dinge speziell angezeigt bzw. gehandelt werden können), dann sind da Kampagnen, Karten, Optionen, Savegames und so weiter und so fort... also da könnte auch schon mal jemand ran, das mal mehr im Detail zu entwerfen.





Sagen wir mal so: Wenn ihr die Grafiken, Editoren und Kampagnenmacht, dann will ich wohl eine Engine dafür bauen...

[DragonDarkhawk]

Soweit meine Recherchen bisher gediehen sind, kommen wir wohl nicht darum herum, eine Engine selbst zu basteln.






Sowieso nicht.
Aber ich würde gerne darauf beharren, daß wir hier von ZWEI Engines reden sollten.





Das eine ist die reine simple Grafik-Engine, die nichts anderes macht, als die Sprites, das Menü und die diversen Dialoge für Einstelungen und Infos auf dem Bildschirm darzustellen, sowie die Nutzer-Eingaben zu fangen und weiterzuleiten. Das sollte dann ein recht "dummes" Teil werden können, das austauschbar (DC, DirectDraw, DirectX, etc...) bleibt.
Die größte Logik, die das Teil beherrschen muß, ist die Umsetzung von virtuellen Koordinaten (Draufsicht) der Objekte(Sprites/Menü/Dialoge) in "reelle" Koordinaten auf dem Bildschirm (Isometrisch) und sie bestimmt, welche Sprites überhaupt gezeichnet werden (die rumkopiererei im Speicher zur Anzeige eines Wildschweins ausserhalb des sichtbaren Bereichs kann man sich ja sparen). (Diese Logik kann natürlich über alle Ausgabearten (DirectX/DC..) gleich bleiben).





Die andere (und hier liegt der eigentliche Hammerteil) Engine ist die Game-Engine. Diese wiederum handlet die eigentliche Spiele-Logik (welches Objekt befindet sich wo auf einem virtuellen Koordinaten-System, welches Sprite des Objekts ist gerade aktiv, wann läuft ein Karrenschieber wohin los und welchen Weg wählt er.
Die Game-Engine sollte dabei aber wirklich nur in virtuellen Koordinaten arbeiten und die Umsetzung der Grafik-Engine überlassen:
Karrenschieber Manfred läuft von Feld 34/27 (Austrittspunkt Lager) nach Feld 11/13 (Warenannahmepunkt Flughafen) und wählt dabei die Route:
33/27 - 32/27 - .... - 11/27 - 11/26 - 11/25 - ... - 11/14 - 11/13
(Innherhalb der Felder gibts dann bspweise nochmal eine "interne Route" um das ganze flüssiger zu machen)
Die Grafik-Engine setzt das dann so um, daß Manfred nicht von oben nach unten und dann von rechts nach links läuft, sonder isometrisch von rechts oben nach mitte unten und dann weiter nach links oben.





Ebenso kennt zB nur die Grafik-Engine die aktuelle Bildschirm-Auflösung kann dementsprechend Dialoge zentrieren oder maximale Größen der Dialoge festlegen. Die Game-Engine sagt nur "blende Info-Dialog mit Text xxx und Überschrift yyy zentriert ein".





Zumindest stelle ich mir das so vor :D






Der Ansatz, so viel wie möglich per XML-Files zu beschreiben und die Engine das einfach lesen zu lassen, ist aber insofern sehr gut, weil man auf diese Weise alle möglichen Editoren unabhängig voneinander bauen kann, und dies sogar in verschiedenen Programmiersprachen.






Einmal das, und VOR ALLEM: Es ist eben Schritt für Schritt erweiterbar!
Wir dürfen bei aller Liebe zu den gewünschten Zielvorgaben (für den einen ein Spiel wie Pharao oder Kaiser im Inkareich "nachprogrammieren", für den anderen eine Städtebau-Simu auf dem Mars) nicht zu viel auf einmal machen.





Erst einmal müssen wir soweit sein, auf einer Map voller Gras ein Häuschen setzen zu können und DANN noch einem Männeken sagen können: "Lauf dahin und wohne drin".
Ist das SOWEIT umgesetzt (und bis dahin wird noch EINIGES zu tun sein), können wir daran gehen, einem anderen Männeken (Hugo) zu sagen: Du hast in Deinem Häuschen (Krämerladen) einen unbegrenzten Vorrat an Nahrung (meinetwegen können wir dieser dann auch schon einen Namen geben (ich wär für Silent Green :lol: )), Nimm davon was und laufe damit von Deinem Krämerladen aus auf ner Strasse rum und kehre bei einer bestimmten Bedingung wieder zurück (Hier reicht erstmal als Abbruchbedingung das, was bereits programmiert ist: der Nahrungsvorrat. Ist der leer gehts zurück - Berechnungen, wie weit Hugo schon gelaufen ist oder wie weit er von seinem Laden entfernt ist kommen erst in einem der nächsten Schritte.)
DANN können wir vielleicht sagen: Okay, während Hugo läuft prüfen wir, ob auf einem seiner Nachbarfelder ein Haus steht und wenn ja, dann übertrage x Mengen Silent Green von Hugo zum Haus.
Dann könnten wir hingehen und Manfred sagen: Hast Du was zu essen zu Hause, dann nimm davon y Mengen pro Zeiteinheit weg (auch essen genannt).





Das ganze soweit dann zu bringen, daß Hugo und Manfred auf diese Weise miteinder agieren ist schon ein gutes Stück Arbeit und sollte nacheinander Programmiert und entsprechend auch nacheinander in die Schnittstelle wandern. (Wieviel Nahrung von was kann man in ein Haus packen? Wieviel von was verbraucht ein Männeken in einem Haus?) Auf diese Weise können wir 1. jede programmierte Aktion auf Herz und Nieren testen, vergessen 2. nicht irgendwelche Parameter für Objektart y in Editor x und haben 3. immer wieder neue Erfolgserlebnisse auf dem Bildschirm, die uns sagen: "JOPP! Das wird irgendwann mal was ganz Tolles!" :D)





Wenn wir versuchen sollten, alles auf einmal umzusetzen garantiere ich bei den (im Gegensatz zu den vollbezahlten und -besetzten Programmierschmieden) wenigen Leutchens mit nicht so viel Zeit eine schnelle Verzettelung beim Umsetzen, Fruststunden bei der Entwicklung und endlose Fehlersuche (vor allem der Suche nach Fehlern, je mehr Funktionen auf einmal untergebracht werden, desto höher die Wahrscheinlichkeit, daß Fehler lange unentdeckt bleiben und dann die Tester frusten...)







ob ein freier Compiler und eine freie IDE in Frage kommen, weiss ich leider nicht. Diese Entscheidung hat, zumindest was die Engine angeht, fundamentale Auswirkungen, darüber müssen wir also recht bald befinden.:






Jo, da stimme ich dir zu...
Dazu bräuchte man dann mal ne Übersicht, was so an "Freien" verfügbar wäre, wie deren Entwicklungsstatus (vor allem in mittelfristiger Zukunft) aussieht und welche Schnittstellen zB zu OS und Grafik zur Verfügung stehen, was das Ding so drauf hat halt...
Erste Frage wäre: Wo findet man zu sowas die richtigen Infos?!? Sprich: wo fängt man an? ;)






Die Tiles sollten wir übrigens 62x32 gross wählen, bei der Farbtiefe sollten zwar 16bit reichen, aber 24bit scheint meistens verwendet zu werden. Irgendwo hab ich ein Paper gelesen, das beschreibt, wie man 32x32 rechteckig in 64x32 rautenförmig umrechnet, weil es ja einfacher ist, ein rechteckiges Bild zu malen und das dann in eine Raute umzuwandeln. Denn: Die Rauten müssen ja genau zusammen passen, damit es keine schwarzen pixeligen Löcher dazwischen gibt...






Jo, wenn 64px allgemeine Zustimmung finden, is okay. Die meisten (einfachen) Bitmap-Tools können ja nur 24-bit, insofern wär das wohl tatsächlich die Wahl der Qual.





Was aber das "umwandeln" angeht....
Öhm,....
Nu bin ICH derjenige, der Bahnhof versteht... Warum willst Du ein Quadrat zeichnen und das dann später in eine Raute _umrechen_?!? Und wie soll das Ergebnis (ästhetisch) aussehen?!? :?
I.d.R. werden die Sprites bei professionellen Games doch gleich in Isometrischer Ansicht gerendert... und ob jetzt rendern oder pixeln: für die Engines sollte das Ergebnis bereits isometrisch vorliegen. Wie der Objektersteller seine Grafiken isometrisch kriegt, sollte m.E.n. seine und die seines Grafik-Programms bleiben...
Zumal Du spätestens bei der 3.Dimension im Objekt beim Umrechnen auf Deine Grenzen stoßen dürftest, da ja in einer Draufsicht sämtlich Bild-Informationen der Seiten fehlen und dementsprechend gar nicht umgerechnet werden können...





Und was die Pixeligen Löcher angeht: Hat man eine Monochrom-Schablone eines Tiles, kann man jedes Tile jedes Objekts entsprechend anpassen. Hier müssen nur die Pixel der Schablone gekachelt eine Fläche ergeben, aber dafür braucht man ja wie gesagt, grad mal eine Schablone für alle Tiles. Im Kleinformat ist so was ja sogar in meinen Testbitmaps (nimm e.g. das "img/infrastruktur/strasse_plain.bmp", das auf 64px Breite und feddich ist die Schablone ;) )






Und noch was: Mit den XML-Files erstellen wir schon Spielbeschreibung und Details, daran können sich auch viele Leute beteiligen, ohne programmieren zu müssen. Wenn man zB ein Gebäude beschreibt, dann muss man zB definieren, welche Läufer losgeschickt werden, wann dies geschieht, wie sich das Gebäude verändert, wenn die 'Desirability' der Umgebung sich verändert, wie weit die Läufer laufen, was das Gebäude zur Funktion braucht und so weiter... Wäre mal eine gute Übung, alle diese Zahlen für eines der bekannten Spiele aufzuschreiben. Wirklich alle Zahlen! Das sind nämlich eine ganze Menge...






KANN gerne jemand machen, aber ich würde da gerne auf die Schritt-für-Schritt-Taktik, die ich weiter oben schon ansprach verweisen...
Zumindest für UMSETZUNG dieser ganzen Werte in unserem Prog, sollte dabei auch eine abhängigkeits-berücksichtigende Priorisierung vorgenommen werden.
(Also was man wann in die Schnittstellen und die Engines aufnimmt. Eine Definition und deren komplette Umsetzung bis zur Grafik-Engine einer kompletten Produktionslinie, macht auch von der Testbarkeit noch wenig Sinn, wenn die Transportwege von Waren noch nicht umgesetzt sind.)





Eine solche Übersicht kann sicherlich helfen, die nächsten Schritte zu planen bzw. eine grobe Ahnung von der möglichen, noch ausstehenden Arbeit zu bekommen, aber wir sollten uns grade für die nächsten 1-2 Jahre noch nicht ZU abhängig von den Logiken bestehender Games machen, oder?






Die Screens müssen entworfen werden. Ich denke, für den Anfang sollte es ausreichen, die gewohnten Standard-Windows-Controls zu verwenden,






Denke ich auch (Standard-Controls).
Schicke Optik der Menüs helfen in keinster Weise dem Voranschreiten des Gameplays und sollten von der Prio ganz weit hinten, bzw. jemandem, der grade einfach Lust auf Menüs malen hat, zur Verfügung stehen ;)






Menüs und Optionen (welche? und was davon definiert sich über ein XML-File?),






Da die Menüs und Optionen abhängig von der Entwicklung der beiden Engines sind, könnten wir diese auch einfach wachsen lassen und ausser "laden" - "speichern" - "neu" alles komplett (für praktisch überall vorkommende Einträge bspweise boolsch) per XML steuern... Oder eben hart, wenn sich herausstellt, daß ohne diesen Eintrag KEINE Kultur je auskommen wird...
Für Positionierung etc. kann man natürlich gerne schonmal Listen erstellen, aber ich denke, vollständig wird so eine Liste allein deswegen nicht, weil doch viele von uns den ein oder anderen Änderungs-/Erweiterungs-Wunsch gegenüber bestehender Games haben wird und noch so manche gute Idee für sowas während der Entwicklung in unsere Köpfe schleichen wird ;)






und dann gibt es da noch die Detailscreens für jedes Item auf der rechten Seite.






Die könnten sich (nur ein Vorschlag) ja zB aus den Basisobjekttypen und den darunter für die Kultur/Missi/Missionsstand zugelassenen Objekten automatisch generiert ergeben...






XML-Definition Kampagnen, Karten, Optionen, Savegames und so weiter:






Auch hier würde ich erstmal nur eine _grobe_ Struktur festlegen und die enthaltenen Daten mit dem Entwicklungsstand wachsen lassen. Darin liegt ja der große Vorteil von XML, daß man (bei entsprechenden Vorbelegungen bei Fehlen von Daten in älteren Dateien) nicht zwingend gleich zu Anfang alles komplett festzurren muß...






dann will ich wohl eine Engine dafür bauen...:






Welche denn? ;)
Die Grafik-Engine kann sicherlich jemand alleine bauen, die Game-Engine wird wohl der größte Klotz des gesamten Projekts, da könnte man sich evt. eine geschickte Verteilung überlegen, bei der möglichst wenig Überschneidungen sowohl der benötigten Dateien als auch der implementierten Logiken auftauchen (damit 1. möglichst wenig Räder 3mal erfunden werden und diese auch alle gleich rund sind...)












...

















Jo, ich glaub langsam auch selber, daß ich eine Laberbacke bin :lol:
... Mal gucken, ob der Beitrag nach dem Kopieren aus meinem Ultraedit noch ohne Probs von der Forensoftware geschluckt wird :lol:





Diese Nachricht wurde ge&auml;ndert von: DragonDarkhawk, 26.02.04 - 15:33

[tobing]

Nur nochmal kurz dazu: GameEngine vs. GrafikEngine - einverstanden. Beide beziehen sich auf die gleichen Objekte, von daher gibt es schon Gemeinsamkeiten, allerdings bin ich sicher, das über eine vernünftige abstrakte Schnittstelle separieren zu können. Wie die GameEngine zu zerlegen wäre ist mir noch nicht klar, weil dort ja die Objekte mit all ihren Eigenschaften rumwuseln, und gerade diese Eigenschaften sich auf lange Zeit immerzu ändern werden.


Zu XML: Auch einverstanden, aber. Unsere Programme müssen von den vielen Attributen, die im XML schon stehen dürfen, nur erstmal ganz wenige verstehen können. Um aber das Spiel zu entwerfen, das wir hier bauen wollen, ist es schon sinnvoll, weiter hinauszuschauen und über alle möglichen Attribute nachzudenken. Wildwuchs wird uns genausowenig zu einem guten Spiel bringen wie ein Mangel an konkreten Zielen, die wir umsetzen wollen. Oder anders gesagt, machen wir einen Entwurf in Richtung eines kompletten Spiels, entwickeln aber in kleinen Schritten mit klaren Prioritäten.





So, Feieramt für hier und heute.

[DragonDarkhawk]

Vorgehensweise: Jop! So können wir es machen! :D

Game-Engine und Objekte:
Ich fänds super, wenn wir einen echt Objektorientierten Ansatz hinbekommen würden.
Bei der Game-Engine gehts ja erstmal nur um die Organisation von Objekten (welche existieren bereits, welche dürfen hinzugefügt/gelöscht werden) und dann um die Interaktion der Objekte untereinander:
Objekt Person interagiert beim Laufen mit Objekt Untergrund (Straße, Wiese, Weg bzw. zB Resourcenabbau), bzw. mit einer definierten Menge von Untergründen (Wegsuche).
ObjektGebäude interagiert mit Objekt Untergrund (Baumöglichkeit)
Objekt Person interagiert mit Objekt Gebäude (Warentransfer, Wohnmöglichkeit, Arbeitsstätte)
Objekt Person interagiert mit Objekt Person (Kampf)

Die reine Organisation kann natürlich nur von der Game-Engine selbst geleistet werden, ansonsten würd ich gern versuchen, alle Events (Lager "produziert" Karrenschieber für Waren-Transfer zum Flughafen) nicht von der Game-Engine steuern zu lassen, sonder diese nur eine "vermittelnde" Funktion einnehmen zu lassen.
Anfrage nach Warew von Objekt Fabrik f an die "Umgebung" (Game-Engine). Game-Enginesuchtnach einem bestimmten Algorithmus alle (vielleicht von f vorgegebenen) Objekttypen, und f fragt dieses Objekt dann ob dieses die Ware hat und ob w geliefert werden kann und falls ja: Anstoß Kommunikation Lager l (hat genug w) und Fabrik f. Diese "regeln" dann untereinander, wie der Transfer stattfindet (bsp. ob Reservierung der Menge in l für f, Abholung durch Transportmöglichkeit von f oder Bringen von w durch l).

Bei einer solchen Vorgehensweisebraucht man immer nur die jeweils miteinander kommunizierenden Objekttypen anpassen, bzw. eine neue Kommunikationsform in der Engine unterzubringen und hat die Logiken schön übersichtlich separiert.
Die Game-Engine selbst sollte so wenig Spiel-Logiken wie möglich beinhalten, bzw. höchstens aus Performance-Überlegungen Übersichts-Werte und größere Logiken (Welche Objekte eines bestimmten typs befinden gerade in der Nähe des anfragenden Objekts usw.) beinhalten und statt dessen halt mehr so eine Objekt-Verwaltung werden...
Wenn man alle Logiken in die Engine packt, dürfte das zwar EVT. etwas schneller werden können (muss nich) aber dafür hätte man mit Sicherheit einen unübersichtlichen Wuselcode vorprogrammiert...Wird ja auch schon innerhalb der Objekte ganz schön happig...

Achso, zu den Objekten selbst, stell ich mir vor, daß die Objekt-Instanzen, die zB im Editor angelegt werden lediglich Eigenschaftsholder für die jeweiligen Objekttypen sind und immer nur ein einziges Objekt pro typ instanziert wird,welches dann vom eigentlichen Objekt im Spiel (das gesetzte Lager1 und Lager2 halt) aggregiert wird.
So können dann speicherintensive Member, wie zB Grafiken auf eine Instanz reduziert werden.
Vielleicht sollten wir uns um Mißverständnissen vorzubeugen hier auf eine Syntax einigen, bsp:
Objekttyp-Objekt: TypObjekt
Spiel-Objekt: SpielObjekt
Werde dann die Klassen auch entsprechend (um-)bennennen.


...


Soll erstmal als Erguss reichen, hab ein wenig Konzentrationsschwierigkeiten, weil ich mich tierisch erkältet hab, der Kopp eh schon total zu is und das halbe Glas Sekt von der Abschiedfeier eines Kollegen (geht zurück in die Firmenzentrale im Schwarzwald) tatsächlich merkbar ist....
Wenn das übers Wochenende nicht besser wird, werde ich wohl doch mal zu Hause bleiben und das Bett hüten, reicht ja, daß wir uns innerhalb der Familie nacheinander anstecken... http://www.staedtebauen.de/modules/RteMulti/pneditor/images/em.icon.dead.gif

[tobing]

Moin Moin,

also das mit TypObjekt und SpielObjekt hab ich noch nicht so ganz kapiert, aber dass man die Grafiken nicht kopiert sondern nur Referenzen benutzt, ist schon klar. So als Idee hat die GameEngine die SpielObjekte, und als Prototypen (eine Instanz, von der geklont wird) jeweils eine Instanz aller möglichen Objekte, die von der Kultur beschrieben wurden (XML). Incl. GrafikObjekt, also die repräsentierende Klasse. Die GrafikEngine bekommt nun eine Menge von (Zeigern auf) GrafikObjekte und zeigt die an bzw. veranlasst Events (wurde angeklickt, a begegnet b...) - zuständig für die Erzeugung und Löschung von SpielObjekten (und dazugehörigen GrafikObjekten) ist immer die GameEngine.





@DDHawk: Wie meinst Du das, dass Du die Klassen entsprechend umbenennen willst? Hast Du schon was hingeschrieben?





Hab per Recherche noch die eine oder andere Quelle für SourceCode ausgemacht, vielleicht komme ich am WE dazu, das mal etwas genauer zu eruieren. Allerdings ist alles, was irgendwie brauchbar aussieht, in C++ mit dem VisualStudio 6.0 gemacht (nur ganz wenig .NET ist mal dabei) und fast alles basiert auf DirectX, oder sonst liegt eine Library drunter, die Grafik abstrahiert und wahlweise DX, OpenGL oder X-Windows benutzt. Irgendwie hab ich schon den Wunsch, etwas zu finden, das für uns einen guten Start liefert, und das dann gemäss unserer Vorstellungen zu erweitern - umbauen sollte nicht so sehr nötig sein.





Performance: Sollte uns noch nicht gross interessieren in diesem Stadium. Es gibt nur einige wenige Dinge, die das jetzt schon beeinflussen können, und das ist die Wahl der Grafiktechnologie, und die Entscheidungen über das Memorymanagement. Auch die Frage, wo man OO macht und wo nicht, bestimmt die Performance, weil OO leider auch dazu tendiert, langsam zu werden...





Grafik: Ich schlage vor, dass wir IsoTiles im Format 64x32 mit 24bit Farbe benutzen, zu Beginn können wir dann BMP als Format verwenden, später könnte man das durch PNG ersetzen (Portable Network Graphics - ein komprimierendes, hoch effizientes und vor allem freies Format), die Libraries hab ich schon irgendwo rumliegen. Wäre supertoll, wenn irgendjemand recht bald ein paar Tiles herstellen könnte (ein genaues bitmuster schreibe ich am WE mal auf), die man dann schon im Programm einlesen könnte. Weil dann gibt es schon mal ein bisschen was Konkretes! Auch wenn ich mal anfangen will, gewisse Dinge mit einer der vorhandenen Engines auszuprobieren.

[DragonDarkhawk]

also das mit TypObjekt und SpielObjekt hab ich noch nicht so ganz kapiert
So als Idee hat die GameEngine die SpielObjekte, und als Prototypen (eine Instanz, von der geklont wird)

Das TypObjekt ist eine Instanz einer von einer Objektdefinitions-XML eingelesenen Klasse, also der, die mit dem Objekt-Editor beschrieben wird.
Diese enthält alle besschreibenden Eigenschaften eines Objekttyps.
Also:Lagerhaus. Hatdiese und jene Grafik für die und die Ansicht. Kann x Mengen von Stückgut lagern. Hat Beschreibung "Blubb" und Objekttyp-ID "LAGERHAUS1".

Das SpielObjekt ist dann eine Instanz eines Lagerhauses im Spiel, das irgendwo auf der Karte rumsteht.
Es enthält die aktuellen Eigenschaften IM RAHMEN der durch die im TypObjekt vorgegebenen Werte.
Also MeinLagerhaus1 hält sich einen Zeiger auf das (einmalig instanzierte) TypObjekt "Lagerhaus", liest daraus "kann 6400 Mengen Stückgut aufnehmen" und hat für Ausrichtung Nord die Grafik g1.
Zusätzlich sind in diesem Objekt dann die Eigenschaften "Position auf Karte" "aktuelle Ausrichtung (und damit verbundene Grafik)", "lagert 100 Mengen Holz und 600 Mengen Kryptonit", "Karrenschieberbringt gerade Waren zu Fabrik f" gespeichert.
MeinLagerhaus2 hält sich entsprechend die Info zu den gerade gelagerten 64000 einheiten WildKräutern und das es keine weiteren Waren annimmt.
Beide haben als Member aber einen Zeiger auf die gleiche TypObjekt-Instanz.

Die GameEngine lädt zu Beginn des Spiels einmalig alle enthaltenen TypObjekte und instanziert sie.
Während des Games werden dann nach Bedarf jeweils n SpielObjekte der Objektypen instanziert, die den Zeiger "ihres" TypObjekts übergeben bekommen. Also kein "Cloning", sondern einfach nichtredundante Datenhaltung ;)

Jetzt klarer? ;)

Die GrafikEngine bekommt nun eine Menge von (Zeigern auf) GrafikObjekte und zeigt die an bzw. veranlasst Events (wurde angeklickt, a begegnet b...)

Die GrafikObjekte hab ich in meiner jetzigen Version als Member der TypObjekte implementiert.
Die GrafikEngine würde dann eine Liste von SpielObjekten erhalten (sie brauchts dabei nicht interessieren was für ein typ dieses SpielObjekt hat) und befragt diese über deren virtuelle Position auf der Karte und die aktuell anzuzeigende Grafik.
Die BasisKlasse SpielObjekt holt sich dann die Info aus sich selbst (Position und interne ID der Grafik, sowie mit der Grafik-ID holt es sich einen Zeiger auf das aktuelle GrafikObjekt aus dem TypObjekt) und übergibt der Engine aktuelle virtuelle Position und aktuelles GrafikObjekt.
Durch umrechnung der virtuellen Koordinate sowie dem entnehmen der Origin-Points des Spritesaus dem GrafikObjekt kann dann das Sprite passend zur Aktuellen Ansicht auf dem Bildschirm positioniert werden und dann kaskadenförmig nach vorne die (evt. ja überlappenden) Objekte nachgezeichnet werden.
Der Origin eines Bilds muß allein schon deshalb im jeweiligen GrafikObjekt enthalten sein, weil ja durchaus durch animierte Bilder die Grafiken eines TypObjekts unterschiedlich hoch sein können.
(Beispiel: Ein springender Delphin auf einem Fischpunkt im Meer. Ist der Delphin unten, brauchts grad mal ein Wasser-Sprite von der Höhe 32. Origin dann x=0, y= 16. Springt der Delphin auf seinen höchsten Punkt, könnte die Zeichnung bis ins "darüber"liegendeTile reichen und das Sprite wird dann 64x50 Pixel groß mit Origin dann x=0, y=34. Schließlich soll ja der Delhin springen und nicht das Wasser unter ihm ;))

was das (a begegnet b) angeht: DAS wiederum sollte der GameEngine überlassen sein, sowas hat die GrafikEngine nix anzugehen, die soll bloss aktuelle Grafiken anzeigen und die Nutzereingaben an die Game-Engine weiterreichen, weil wir sonst anfingen SpieleLogik in die GrafikEngine zu packen... nix gutt....

Wie meinst Du das, dass Du die Klassen entsprechend umbenennen willst? Hast Du schon was hingeschrieben?

Na zumindest die Basisklasse (class objekt) und die erste Ableitung Natur (class natur_objekt) des TypObjekts.
Damit arbeite ich ja schon im Editor, weil ich die Member eh im Speicher halten muß und warum sollte ich die GLEICHEN Eigenschaften in 2 verschiedenen Klassen für GameEngine und Editor halten ;)

Halt für den Builder, ist klar, wenns denn ein anderer Compiler für die GameEngine wird, muß die Klasse dann neu oder zumindest umgeschrieben werden.

zu Beginn können wir dann BMP als Format verwenden, später könnte man das durch PNG ersetzen

Das sollten wir aber erst machen, wenn sich herausstellt, daß BMPs tatsächlich einen viel zu hohen Speicherplatzbedarf erzeugen.
Alle Win-BildProgramme können BMPs erzeugen, aber noch längst nicht jedes kann PNGs speichern. Dadurch könnte zusätzlich noch Konvertierungsbedarf bei der Erstellung anfallen -> sprich die Hürde zur Erzeugung neuer Objekte und deren Grafiken aus der Community heraus würde heraufgesetzt -
, mal abgesehen davon, daß viele Grafikschnittstellenintern mit BMPs arbeiten und beim Lesen im Spiel je nach Schnittstelle dann wieder "rückkonvertiert" werden müßte-> Performance -

Wäre supertoll, wenn irgendjemand recht bald ein paar Tiles herstellen könnte
Naja in "klein, pixelig und knuffig" kannst du ja die paar Beispiel-Tiles nehmen, fürs Testen einer Engine sollten die schonmal reichen, auch wenn die endgültige Tile-Größe noch anders wird, sollte ja höchstens durch 2-3 Parameter einstellbar sein, gell?... ;)

Diese Nachricht wurde ge&auml;ndert von: DragonDarkhawk, 27.02.04 - 14:22

[SuperNicky]

Tiles herstellen wär doch was für Manni !
(Nein, ich bin nicht faul, ich bin nur nächste Woche mal wieder nicht da (Ja, okay, in Hamburg bin ich auch, fahr aber nur durch.); muss am Dienstag zum Vorstellungsgespräch und komme erst am 9.3. wieder). Vielleicht und evtl. kann ich euch lesen vom Rechner meines Schwesterherzchens aus, aber irgendetwas nützliches hat sie da bestimmt nicht drauf. (U.a. muss ich noch meiner Mama Pharaoh beibringen ! Sie hat mutig angefangen, und dann fing es auf einmal an zu brennen (erinnert ihr euch ans erste Level ? ), und da hat sie Angst bekommen und aufgehört. Na, kann ja noch werden...

[DragonDarkhawk]

Tiles herstellen wär doch was für Manni !

Ist (hoffentlich) sogar was für ALLE halbwegs Interessierten ;)
Ich versuch auch, zumindest den Editor so bedienfreundlich wie möglich zu machen, versprochen :D

Sie hat mutig angefangen, und dann fing es auf einmal an zu brennen (erinnert ihr euch ans erste Level ? ), und da hat sie Angst bekommen und aufgehört.

:lol: Kannst Ihr ja sagen, das der Rechner dadurch NICHT zu heiß wird und der Brand auch NICHT auf die Gardinen übergreift :lol:
Neee, im Ernst, find gut, wie jung ist die Dame denn?

Na, kann ja noch werden...

Auf jeden Fall!!!
Wir Geschwister haben auch zusammengelegt und unserer Mutter zum 60.(!) Geburtstag einen Rechner geschenkt. Inzwischen ist sie richtig selbständig damit geworden, installiert und deinstalliert ihre Programme selbst, kann viele Fehler auch alleine lösenhat im Internet und per mail sogar neue Freundinnen in aller Welt gefunden, wieder regelmäßigen (email-)Kontakt zu Ihrem Bruder in Frankfurt und zu Ihren Cousins in Amerika, macht Ahnenforschung und Familiengeschichten... alles per PC.
Wichtig ist dabei ja einfach, die Angst vor dem PC und dessen Eigenarten zu nehmen, gell?;-)

[Manni]

Hallo Supernicky,

ich und Tiles????????? Hab noch nie Fliesen verlegt! :eek:

Mit guter Anleitung jedoch würde ich es versuchen. ;)

MfG
Manni

[SuperNicky]

Meine Mama ist Jahrgang 52 und damit jünger als so mancher, der sich hier herumtreibt.
Aber das mit dem PC haben wir schon ziemlich lange hinter uns, die letzten 10 Jahre hat sie damit sogar ihre Brötchen verdient. Jetzt hat sie ihr böser Ex-Boss allerdings entlassen (angeblich aus wirtschaftlichen Gründen, konnten wir aber widerlegen => Entschädigung !), und sie langweilt sich ein wenig. Deswegen dachte ich mir, sie könnte ja mal was anderes spielen als Solitaire.
Lieber hätte sie natürlich einen neuen Job.
Eckdaten : Industriekauffrau, ungebunden, mit langjähriger Berufserfahrung, Schleswig Holstein. Auto vorhanden. Na, weiß einer was ? (Bis zur Rente ist es noch ziemlich lange hin !)

[SuperNicky]

@Manni : ich hoffe ja auch auf eine Anleitung, denke aber nicht, dass das höchst kompliziert wird. Oder, Jungs ? (Ich erkläre mich hiermit bereit, gerne Anleitungen aller Art zu testen und so zu ihrer Perfektionierung beizutragen !)

[tobing]

Hab leider nicht so viel anschauen können, wie ich wollte. Aber eine Engine habe ich verworfen, und 2 Beispielprogramme gefunden, die MFC mit DirectX kombinieren. Das könnte jedenfalls ein Framework sein, in das wir dann sowohl die GrafikEngine als auch die GameEngine einklinken können. Ich bleib da dran...

[DragonDarkhawk]

Mach Dir nix draus, hab am Wochenende auch mehr Bett und Kinder gehütet, als am Rechner was machen können... http://www.staedtebauen.de/modules/RteMulti/pneditor/images/em.icon.dead.gif

...und ich glaub, heut wär ich man auch besser zu Hause geblieben...

[tobing]

Mach Dir nix draus, hab am Wochenende auch mehr Bett und Kinder gehütet, als am Rechner was machen können... http://www.staedtebauen.de/modules/RteMulti/pneditor/images/em.icon.dead.gif...und ich glaub, heut wär ich man auch besser zu Hause geblieben...





Mach ich auch nicht - und Dir wünsche ich man eine gute Besserung!

[DragonDarkhawk]

Danke!

Ich hoffe, die kommt auch mal langsamirgendwann, das grenzt zeitlich langsam am Verschleppungsstatus...

[SuperNicky]

Hallo Jungs, bin wieder da. Hier ein kleines Update, was meinen Erfolg angeht, meiner Mama unsere Städtebauspiele schmackhaft zu machen :
gestern abend erreichte mich eine SMS meiner kleinen Schwester mit folgendem Inhalt :

"Das Befürchtete ist eingetreten, Mama spielt die ganze Zeit Pharao, ich werde wohl bald zu einem vernachlässigtenKind und du bist Schuld ;) "

Ja, Städtebauspiele sind halt einfach gut !

[Flilian]

Dann brauchst Du jetzt nur noch die kleine Schwesterzur Städtebauspielerin zu machen... die fühlt sich dann nicht mehr vernachlässigt und Deine Mutter kann auch in Ruhe spielen :D

[tobing]

Nach längerer Sendepause mal wieder was Neues hier. Inzwischen habe ich mich umgeschaut, was es so gibt, wie andere Leute das machen und so weiter. Ausschlaggebend war für mich aber dieses Buch: Spieleprogrammierung. Konzeption, Entwicklung, Programmierung, m. CD-ROM. Das bhv Taschenbuch (http://www.amazon.de/exec/obidos/ASIN/3826680758/staedtebauend-21) - kostet nur knappe 17€ und es ist wirklich gut gemacht. Alles basiert auf OpenSource, Entwicklungsumgebung inklusive. Grundlage der Spieleengine ist die OpenSource-Library Allegro (http://www.allegro.cc/). Allegro tut unter Windows mit GDI oder DirectX, lässt sich mit MS VisualStudio bauen, aber auch mit OpenSource-Compilern wie MinGW (http://www.mingw.org/) oder Cygwin. Auf diese Weise können wirklich alle Interessierten hier einen Beitrag auch zur Programmierung leisten, wenn sie das wollen. Das Buch wendet sich auch an nicht so erfahrene Programmierer, ist also insoweit auch für Anfänger lesbar.






Eine Alternative, die ich noch im Rennen habe, ist die OpenSource-Library KYRA (http://www.grinninglizard.com/kyra/). Das basiert auf der SDL (http://www.libsdl.org/) und noch etlichen anderen Paketen - natürlich alle OpenSource - aber noch habe ich nicht alle Abhängigkeiten aufgelöst und eine lauffähige Version gebaut, so dass ich ein abschliessendes Urteil abgeben könnte.






Für Allegro spricht allerdings das Buch - ist halt eine klasse Einführung, so kann man wirklich gut klein anfangen. Es hat wenig Sinn, sich eines der schon fertigen grösseren Projekte in dieser Richtung anzuschauen, um das abzuwandeln - hab mir auch LinCity (http://lincity.sourceforge.net/) und FreeCiv (http://www.freeciv.org/) angesehen, oder auch CTP2 (alles OpenSource).






Von diesem Status ausgehend würde ich mich dazu entschliessen, unsere Spieleengine auf Allegro basierend zu bauen. Sobald ich was dazu habe, werde ich das hier posten, klare Sache. Und die Links zu den notwendigen Packages sowie die Installationsanweisungen dazu natürlich auch.






Aber zuerst ist ein Designdokument fällig, und damit habe ich auch schon begonnen. Werde ich demnächst posten...

[SuperNicky]

Schön !!!
Ich versuche mal, mir das Buch zu besorgen. Hört sich ja gut an (insbesondere der Satz über die "nicht so erfahrenen Programmierer"...).

[tobing]

Versuchen ist doch ganz einfach: ein paar Clicks und schon kommt es mit der Post... bin mal gespannt, ob es Dir auch zusagt.

[SuperNicky]

Ja, aber wenn die Post kommt, bin ich nie zu Hause; und außerdem habe ich keine privat nutzbare Kreditkarte. Lieferung auf Rechnung ist ja anscheinend nur möglich, wenn man nach Hause liefern lässt (oder was bedeutet "Lieferanschrift = Hausanschrift"), und nicht in die Firma.
Kurz : ich habe mir noch NIE etwas übers Internet bestellt, und bevor ich mir jetzt erst noch eine Kreditkarte besorge, fahre ich doch lieber in die Buchhandlung, woi ?
(Ich weiß, es ist albern, aber ich habe überhaupt erst seit zwei Wochen eine Kreditkarte. Die darf ich nicht privat benutzen, und deshalb habe ich eh keine Ahnung, wie man damit etwas bezahlt, weil ich sie noch nie benutzt habe. In der Hinsicht bin ich ein Totalverweigerer ... )

[tobing]

Na gut SuperNicky, wenn das so ist... Hauptsache Du kommst ran an das Buch und hast Spass damit!

[SuperNicky]

Ich habe mir am Samstag das Buch gekauft und war erstmal erschüttert, weil ich mir das Teil doch ein bisschen handlicher vorgestellt hatte.
Ich habe sogar schon angefangen, zu lesen, allerdings erstmal den einfachen Teil : die Interviews mit den Entwicklern.
Jedenfalls freue ich mich schon auf das lange Osterwochenende, da kann ich mich in Ruhe damit beschäftigen; ich glaube, wenn man das Buch im Kopf verarbeitet hat, ist man richtig gut (und das kann mir auf jeden Fall nicht schaden...)

-----------------------------
"I show my ass whenever I want." - Eminem

[tobing]

Wie jetzt. Also handlich ist das doch. Bisschen dick vielleicht, aber ich hab zu Hause ein Buch - Realtime Strategy Game Programming using DirectX 6- das ist genauso dick und doppelt so gross und natürlich englisch. Aber auch richtig gut...

[SuperNicky]

Angeber.

Also gut, mit den Interviews bin ich jetzt durch, d.h. wenn ich vielleicht über Ostern frei habe, kann ich ans Eingemachte gehen...
(Hoffen wir mal.)

[tobing]

Nana, so war das nicht gemeint. Hab die dicke Schwarte ja selbst gar nicht richtig gelesen, nur bisschen quer. Was ich davon aber gesehen hab ist, dass sich der Kauf nicht wirklich lohnt, also empfehle ich das auch nicht unbedingt. Andererseits ist es nicht schlecht, vor allem der Teil über die Ideenfindung und wie man so ein Projekt aufsetzt und welche Leute man so alles braucht in den verschiedenen Phasen des Projektes...


Ach so, ich werde mal meine Literatur zu dem Thema mit nach HH bringen, klare Sache.

[tobing]

Hab mir für den Anfang jetzt mal was ausgedenkt: Also ein Städtebauspiel soll es ja werden, aber auf dem Weg dahin möchte ich gern ein paar Stationen einbauen, damit man die ganze Sache überschauen kann. Mundgerechte Happen sozusagen.





Nun, ein nachprogrammiertes A-Train steht bei mir schon auf der Wunschliste, klare Sache. Das Spiel ist auch von der Grafik her viel einfacher als ein komplettes Städtebauspiel. An diesem Teil kann man auch schon mal die richtige Modularisierung in Game-Engine, Grafik-Engine und Menü- Framework entwickeln, damit man danach auf verschiedenen Schienen zu Mehreren weiterprogrammieren kann.





Eine Station vorher steht aber noch eine einfachere Sache, und zwar ein Thema, das mich seit einier Weile interessiert. Eine zunächst einmal nicht interaktive Simulation von Verkehr auf einer Strassenkreuzung - im Vergleich Rechts vor Links mit Ampel und Kreisverkehr, und dann möchte ich gern sehen, wo der Durchsatz von Autos am grössten ist. Ich werde schon mal heilfroh sein, wenn ich ein kleines Autochen über eine Strasse auf der ersten selbstgebastelten Karte fahren sehe! Und spätestens diese Programmversion werde ich dann auch hier zur Begutachtung zur Verfügung stellen.





Nun, ist noch ein ganzes Stück Arbeit bis dahin, aber das ist ein erreichbares erstes Ziel, denke ich mal. Und daran kann man eine ganze Menge über isometrische Karten und Animation lernen, also die grundlegende Mechanik jedes Spiels.

[theplayer]

moin moin,

ich muss mich jetzt mal unbedingt hier mit reinhängen. also es gibt ja schon schöne viele ideen. ihr habt aber nur ein kleines problem. leider kommt die planung meiner meinung nach etwas zu kurz. macht doch erstmal einen kleinen grundriss des spiels und überlegt euch auf was das spiel aufsetzen soll. windoze / linux / menuetos / ... .

--> Ich würde sagen windows oder linux wäre da wohl die beste variante.

wollt ihr ein spiel schreiben das nur unter dem bestimmten os läuft oder auch unter anderen? wenn ihr es für mehrere oses schreiben wollt könnt ihr schon mal directx vergessen. gibts ja unter linux nicht.

--> V E S A
vesa ist auf jeder grafikkarte heutzutage implementiert und kann auflösungen bis zu 1280 x 1024 pixel und sogar mehr darstellen. vesa ist schneller als direct x. vesa ist unter linux verfügbar. vesa ist free direct x nicht. vesa ist relativ einfach zu programmieren und für isometrie völlig ausreichend.

--> O P E N G L
heißt ausgesprochen: open graphics library
ist auch unter windows und linux verfügbar. kann auch 2d darstellen und ist auch schneller als directx.


ich würde mich freuen wenn ihr meine (hoffentlich sinnvolle) kritik mal überdenkt.

mfg the player

p.s. copyleft: the player

[theplayer]

ich hab doch direkt noch was vergessen.nehmt nicht so viele layer (so viele bibliotheken und ... )ist zwar ne schöne idee aber ihr könntet sehr schnell an die grenzen der bibliotheken stoßen und würdet danach anfangen selbst rumzubasteln und das wäre auch nicht das gelbe vom ei
zu der idee die bilder einfach in isometrisch umzurechnen kann ich / muss ich auch was sagen. das umrechnen wird sehr langsam sein und damit das gesamte spiel ausbremsen. ihr müsst ja davon ausgehen das ihr nicht nur 10 felder habt sondern vielleicht 5000. malt die bilder einfach direkt so wie ihr sie darstellen wollt ohne großes rumrechnen.und noch einen (hoffentlich der letzte):es gibt 3 möglichkeiten isometrie darzustellen. einaml als diamant





0





0 0





00 0





00





0











(die 0 stellen die felder dar)





einmal so (ich weiss nicht wies heißt müsst ich erst nachschaun)











0000





000





0000











und noch ne variante welche aber bestimmt rausfällt.wisst ihr denn überhaupt schon in welcher sprache ihr arbeiten wollt?
ich habe c / c++ rausgelesen. dann aber bitte nicht visual c++kostet einfach mal so viel dass ich euch das nicht kaufen könnt. nehmt doch etwas was open source ist oder zumindes freeware





Diese Nachricht wurde ge&auml;ndert von: theplayer, 08.06.04 - 14:56

[0siris]

Moin Player...

es gibt da ein paar KLEINE Dinge die ich gern noch anmerken taet (sorry for US keyboard):



1. 24 Bit == 1 Byte Platzverschwendung oder was?

Wenn ich mich nicht sehr stark verlesen habe behauptest du das Windows bei 24 Bit Farbtiefe 1 Byte Junk (nenn es wie du willst) erzeugt. Ja, was traut man seinen Feinden nicht alles zu!

Doch in diesem Fall ist das alles doch etwas anders... es ist naemlich eher so das 24 Bit Farbmodi entwickelt worden... und jede jetzige Standardgrafikkarte kann nicht mehr als 24 Bit Farbtiefe weil jeder Pixel drei Bytes gross ist: RGB. Daran laesst sich auch _NICHTS_ aendern weil die Grafikkarte nun mal nicht mehr unterstuetzt. (bis jetzt)

Da die CPUs aber schon zu 386er Zeiten 32 Bit auf einmal verarbeiten konnten war es doch naheliegend das sich mal jemand Gedanken macht ob man nicht den Zugriff auf die Grafikkarte noch etwas optimieren kann. Und daraus entstand dann der sog. 32-Bit Modus. (packed pixel)

Und hier hast du dich anscheinend verlesen:

"beim 32-Bit packed-pixel modus werden pro pixel drei Bytes daten (RGB) und ein byte Junk verwendet. Dadurch kann man mit einer instruktion einen Pixel aus dem Speicher lesen."

Die von mir junk genannten Daten werden auch oft alpha-channel genannt.



2. Du hast echt Hoffnung

Aber ich weiss nicht was dich dazu bringt denen ASM vorzuschlagen...

Ja. Ich habe doch echt nichts dagegen nur die muessen die 10MB Dokumentationen erst lesen die wir schon zu einem viertel gelesen haben...

Sag doch einfach C++ und nimm einfach GNU C++ oder LCC32 (ist mir zu instabil) oder sonstewas.

Und wenn du der Meinung bist du brauchst wirklich irgendwo mal ASM, z.B. um die Berechnungen der Isometrie noch etwas zu optimieren, dann kannst du doch einfach C-- nehmen.

Das ist klein (passt MIT allen Bibliotheken auf eine Diskette) laeuft unter DOS und Windows, macht Programme fuer DOS, Windows und MenuetOS, kennt Klassen...

Also wer auf Low-level steht der darf sich das ruhig mal auf der C-- Homepage (http://c--sphinx.narod.ru) anschauen bzw. saugen.

Dort gibt es auch tausend Beispiele und so.



3. Layer

Viele Layer sind schlecht. Rechnest du denn so fest damit das das Spiel als erstes unter FASM fuer MenuetOS geschrieben wird? Unter Windows/Linux gibt es nun mal tausend Layer und die sind auch nicht wegzubekommen weil du zum System gehoeren und man sich auch noch mit ihnen unterhalten muss.

Das ist eben der Vor- und gleichzeitig auch Nachteil von Klassen.

Und bitte lies erst mal ein wenig ueber Klassen und lerne wie man sie _RICHTIG_ anwendet bevor du was gegen layer hast. Versuchs doch mal und schreib irgendein Ding einmal mit Klassen und einmal nur mit Funktionen. Du wirst den Unterschied sehen: einmal am Code und einmal an der Geschwindigkeit. (da musst du aber sehr genau hinschauen :D)



-- und wenn ein Mensch einen Fehler in seiner Denkweise hat dann musst du ihn dazu bringen ihn zu erkennen und nicht drumherum zu arbeiten. Wenige layer ist der falsche Ansatz.

Es sollte eher heissen: warum kann layer x nicht mit layer y kombiniert werden?

Und wenn man das durchkaut dann sieht man (hoffentlich) wo der Fehler ist --



--[ ich hoffe das ich keinen beleidigt habe... ]--

[tobing]

Zunächst mal Dank für alle Anregungen! Angefangen habe ich schon ein wenig, Richtung Technologiestudie, und als Grundlage empfehle ich dieses Buch da - wurde weiter unten erwähnt. Dort wird alles sehr schön erklärt, insbesondere die Benutzung von Allegro (ein Layer, der die tatsächliche Grafik abstrahiert und auf diversen Compilern und BSen tut). Zur Zeit benutze ich noch Visual C++, plane aber mit einem ersten Release auch die makefiles für MinGW (als Entwicklungsumgebung) mitzuliefern. Als freie IDE kommt vermutlich Dev-C++ in Betracht (wäre toll, wenn das dann mal jemand ausprobieren würde, ob und wie das funzt). Alles OpenSource.


Über die zu verwendende Programmiersprache möchte ich nicht mehr diskutieren, wir verwenden C++. ASM kommt allenfalls in Frage, wenn es um Winzoptimierung geht, wenn wir mal soweit, sind reden wir vielleicht darüber. Die einzige Alternative wäre noch Java, aber das ist nicht mein Revier. Ich selbst programmiere seit >12 Jahren C++, habe also ein bisschen Erfahrung in dem Bereich...





Die Links zur hier angesprochenen Software finden sich irgendwo in diesem Thread, aber auch in den Weblinks im Bereich Entwicklung.





DirectX ist auch frei, das SDK kann man von M$ downloaden. Ist zwar ein bisschen umfänglich, strotzt aber nur so von Doku und Beispielen. Man muss kein Fan von M$ sein, um davor den Hut zu ziehen.

[tobing]

Hab gerade nochmal geschaut: Im Thread 'Freie Entwicklungsumgebungen' habe ich schon einiges zu dem Thema geschrieben, unter anderem, dass der M$-Compiler als Kommandozeilenversion freigegeben worden ist. Es handelt sich um den Compiler des Visual .NET Studio 2002.

[SuperNicky]

Asm, Masm, Tasm - egal, die Benutzung von Assembler geht immer zu Lasten der Kompatibilität und ist meiner Meinung nach in einem Open Source - Projekt nicht das Mittel der Wahl. DAS BUCH wird bei mir im Haushalt gerade verschlungen, leider nicht von mir, aber mein HUM wird gerade Allegro - süchtig. Es geht noch was...

[rot000001]

HUM = Herr und Meister</U>??????????






Nix Gleichberechtigung -odda wat ?????;)

[SuperNicky]

Hey rot, ich verrate dir jetzt mal ein großes Geheimnis : Männer müssen immer in dem GLAUBEN leben, der HUM zu sein - wir Frauen halten das seit Jahrtausenden so. Denn ist der Mann glücklich, freut sich der Mensch... ;)