Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Mär 29, 2024 05:49

Foren-Übersicht » Sonstiges » Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 13 Beiträge ] 
Autor Nachricht
 Betreff des Beitrags: Strategiespiel
BeitragVerfasst: Do Jan 25, 2007 18:11 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Hallo @ll

Vorweg: Es bestehen gute Chancen, dass dieses Projekt nicht eingefroren wird, aber sicher ist dies nicht.

Schon lange geisterte mir die Idee eines Strategiespiels im Kopf herum. Als mein Programmierlehrer (nen Kumpel, kein schulischer Unterricht, sowas haben wir leider nicht) dann als Aufgabe stellte, ein Rollenspiel zu Programmieren, habe ich sofort angefangen, ihn zu einem Strategiespiel zu überreden. Und das habe ich dann auch geschafft.

Aktueller Entwicklungsstand
Betadownload: nicht verfügbar
Entwicklungsstand: Planungsphase weitestgehend abgeschlossen, jetzt gehts ans Eingemachte
Commentthread

Dateien


Spielprinzip
Wer erinnert sich noch an das gute alte Ascendancy? Ich habe es vor kurzem wieder ans laufen gebracht und dort auch viele meiner Motivationen herbekommen.
Mein Strategiespiel (wofür wir noch einen Namen suchen, hat wer ne idee? :wink: ) wird auch Rundenbasiert ablaufen und sowohl im Weltraum als auch auf den Planeten selber spielen. Es wird alle Spielvorgaben aus XML-Dateien auslesen, das war eine Bedingung, weshalb es locker auch Modbar sein wird, sodass man z.B. in der Steinzeit anfangen und sich dann bis zu anderen Planeten vorarbeiten könnte, falls irgendwer so verrückt ist und einen solchen Mod erstellt. Im Gegensatz zu Ascendancy wird die Planetenansicht deutlich detaillierter sein. So á la Anno, oder so. Auf jeden Fall werde ich die aktuellste Version meines Wassershaders irgendwo unterbringen :wink: . Es wird verschiedene Rassen geben, die wie gesagt auch in den XML-Dateien deklariert sind. Diese Rassen könnten dann verschiedene Starttechnologien und -planeten haben. Eine Rasse, die Standardmäßig unterwasser lebt wäre z.B. denkbar. Die Ressourcenproduktion wird in der Standardausgabe (also ohne irgendwelche Modifikationen) deutlich gestaffelter sein, als bei Ascendancy. So wird es drei Baumaterialien, zwei verschiedene Nahrungsressourcen und Energie, sowie Forschungspunkte geben. Forschungspunkte können nicht gesammelt werden. Umweltfaktoren wie Verschmutzung und Temperatur werden sich auch auf die Moral und Produktivität auswirken. Bestimmte Einheitentypen werden mit individuellen Waffen- und Rüstungstypen ausgerüstet werden können, á la Earth-Reihe (wer sie kennt). Kämpfe werden ebenfalls Rundenbasiert ausgetragen, eine Kampfrunde entspricht auch einer Spielrunde. So kann man während eines Kampfes beispielsweise noch Einheiten nachproduzieren.
Mehr fällt mir jetzt nicht ein.

Es kann gut vorkommen, dass ich mich eine Weile nicht zu diesem Projekt melde, wie gesagt, es steht noch sehr am Anfang.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Zuletzt geändert von Lord Horazont am So Mai 24, 2009 01:08, insgesamt 3-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jan 25, 2007 18:28 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Append:
Die Technik hinter allem
Wie gesagt, es soll so ziehmlich alles Variabel sein. Für Planetenoberflächen (die auch per XML deklariert werden) können Texturen und sogar Shader festgelegt werden. Für die Grafik wird OpenGL, für den Sound, das LAN, Ereignisbehandlung, Fenster usw. wird SDL zum Einsatz kommen. Mods werden wahrscheinlich in ein spezielles Archivformat (das hab ich schon fertig) komprimierbar sein (mit nem kleinen Tool).

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Feb 03, 2007 14:57 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Da mir über die Tage einige neue Ideen gekommen sind, werde ich das Archivformat wohl neu schreiben (da hat mich mehr oder weniger freiwillig Sascha inspiriert, mit seinem VFS, welches Daten auf der Festplatte bevorzugt und so weiter). Eine weitere änderung wird sein, dass die Sounds von OpenAL verwaltet werden. Das ist zwar wieder eine Bibliothek mehr, aber mit den SDL-Sounds kenne ich mich überhaupt nicht aus.

Das Grundgerüst für die GUI steht jetzt, die Ereignisse (MouseMotion, MouseClick und KeyPress) werden richtig verteilt. Da ich ja ein paar Kommentare zur Technik, die hinter allem steckt geben sollte, erkläre ich jetzt mal, wie die GUI aufgebaut ist und die Ereignisse verarbeitet werden. Dabei habe ich versucht, möglichst das Verhalten eines gewissen Produktes einer Firma aus Redmond nachzubauen :wink:
Also. Die GUI besteht hauptsächlich aus zwei Klassen, TguiManager und TguiElement. TguiElement enthält alle Informationen, die jedes Element ( = Fenster / Button / Checkbox ) haben muss, dazu gehört z.B. Parent, Children (ein TList), ob es Children haben kann, ClientMargins (Also die Ränder für die ClientArea, wo die Childs reingezeichnet werden) und verwendete Texturen. Die Texturen sind in einer extra Klasse gespeichert, die ScaleMargins enthält, damit Ränder definiert werden können, die nicht mitgestreckt werden (z.B. der Rahmen von einem Button). Außerdem enthält die Texturklasse noch informationen über den Bereich der Textur, der für dieses Element bestimmt ist. So kann man mehere Elementtexturen in ein Bild packen, das spart Speicher. Die Basisklasse TguiElement enthält auch schon eine Klickverarbeitung, d.h. wenn die Linke Maustaste über dem Element gedrückt gehalten wird, dann wird die Active-Texture anstatt der Standard-Texture gezeichnet.
TguiManager enthält nur das Root-Element, eine abart von TguiElement. Dieses RootElement zeichnet seinen Hintergrund nicht nur die Child-Elemente, sodass die GUI an sich durchsichtig ist, nur alles, was man darauf packt, wird sichtbar. Das Root-Element kann in seiner Größe nicht verändert werden, nur durch einen speziellen Auflösungsänderungsaufruf, da das Element ja den ganzen Bildschirm abdecken soll.
Die Ereignisse werden bevorzugt an das gerade aktive Kindelement weitergegeben. Wenn kein Kindelement aktiv ist oder es das Ereignis nicht verarbeitet hat (var Handled: Boolean) dann verarbeitet das Element das Ereignis selbst. Das ganze läuft also rekursiv ab. Wenn das Element das Ereignis nicht verarbeitet hat, dann würde das Parent-Element versuchen es zu verarbeiten und so weiter.
Bild
Auf der rechten der Button und auf der linken die Textur mit beiden Stadien des Buttons

Ebenfalls habe ich heute das Grundgerüst für das ThreadedLoading, also das Laden während dem Rendern fertigestellt.
Dies arbeitet mit einer Befehlsqueue (:TList), bestehend aus einer Liste, die mit Container-Klassen gefüllt ist. Diese Klassen (TtlDataObject) enthalten einen Pointer, der mit dem Create-Befehl übergeben wird und einen Pointer auf eine Procedure, der als Parameter beim Aufruf dieser Pointer übergeben wird. So kann z.B. eine Textur vom Thread in den Speicher geholt werden (also auf eine SDL-Surface) und dann in ein spezielles Objekt. Dann übergibt der Thread einen Pointer auf die Surface und einigen anderen Informationen, die in einem TObject-Nachfahren liegen, sowie einen Pointer auf die Prozedur, die die Textur dann Anhand der Daten in dem Object auf die Grafikkarte lädt. Dies ist ja notwendig, um die Textur dann auch wirklich im Hauptthread zu haben und nicht nur im Nebenthread. So kann das dann auch mit Sounds oder gar ganzen GUI-Elementen gemacht werden. Die Queue ist selbstverständlich über Mutexes Threadsafe gemacht, alles andere wäre ja sinnlos :wink:

Request a comment :wink:

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Zuletzt geändert von Lord Horazont am So Feb 24, 2008 13:21, insgesamt 2-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Apr 19, 2007 19:19 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Wie man vielleicht an meiner Aktivität im Forum bemerken kann, arbeite ich wiedermal an meinem Projekt weiter.

@World: In den letzten Tagen (und Wochen) habe ich mich hauptsächlich mit den Klassen für die Objektdefinitionen beschäftigt und kann sagen, dass ich sie jetzt zu ca. einem drittel Fertig habe. Dieses drittel entspricht den Klassen, die später die "Referenzen" für neue Objekte enthalten, also alles das, was man in XML-Dateien deklarieren kann, es sind also noch nicht die Klassen, die später die "richtigen" auf dem Spielfeld sichtbaren Einheiten enthalten.
Diese Klassen werden fähig sein, "Instanzen", also die "richtigen" Objekte zu erzeugen. Ich arbeite hier mit ", weil es sich natürlich nicht um Pascal-Instanzen/-Referenzen handelt.

@GUI: Ich habe jetzt auch endlich das Scissoring für das Abschneiden der Komponenten, wenn sie über die Parent-Komponente rausragen hinbekommen. Anfangs hatte ich zunächst einen nicht funktionierenden Algo, dann hatte ich das Problem, dass ich versehentlich auf das Result zugegriffen habe, anstatt auf den parameter... nun, das hat auch wieder einen Tag gedauert, bis mir das aufgefallen ist :roll:
Nun befasse ich mich mit komplexeren GUI-Komponenten wie Edit-Felder, CheckBoxen und sowas, wobei es da noch am Font hapert (siehe Thread in Allgemein).

Greuseliger Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Mai 11, 2007 16:56 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Und wieder hat sich etwas getan bei meinem Projekt:

Zunächst habe ich vor etwas längerer Zeit das Problem mit den Fonts gelöst. Man sollte Daten im Speicher lassen, wenn sie noch gebraucht werden... :oops: Aber woher sollte ich auch wissen, dass SDL_TTF die Daten noch nach dem Laden braucht...? :roll:

Dann ist mir aufgefallen, dass eine GUI mit dem Standard-SDL Cursor doch recht langweilig ist, also habe ich angefangen, eine "Cursor-Engine" zu schreiben. Die läuft mittlerweile auch schon recht gut, mit Animationen kommt sie auch klar. Erweiterungen, wie z.B. DisplayLists, können hier leicht eingebaut werden.

Weiterhin habe ich im Internet (Delphi3D.net) eine äußerst aufschlussreiche Demo zum Thema Wasserspiegeleffekte gefunden. Daraus habe ich mir dann einen eigenen Wassereffekt gebastelt, dem später noch über Shader Wellen hinzugefügt werden, die dann für entsprechende Reflektions- und Refraktionsabweichungen sorgen. Die für die Reflektion/Refraktion benötigte Textur wird der Auflösung angepasst. Sie hat immer die Größe der nächstniedrigeren POT, ausgehend von der Kleineren der beiden Bildschirmkantenlängen. So hat eine Auflösung von 800x600 eine Reflektionstextur von 512x512 Pixeln, eine Auflösung von 1280x1024 eine Reflektionstextur von 1024x1024 Pixeln.

Des weiteren habe ich jetzt eine Scriptsprache ausgesucht. Sie ist flexibel, es gibt Pascal-Header und sie ist portabel. Erweiterungen am Befehlssatz kommen ohne DLL's aus, einfach über ein paar Befehle in der Anwendung. Vielleicht hat es der eine oder andere schon erraten, ich meine LuaScript.
Scripts werden in den XML-Definitionen an bestimmten Stellen einbinbar sein, entweder als Referenz auf eine Scriptdatei oder als "Inline-Code".

Screenshots zu diesem Post
Bild

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Zuletzt geändert von Lord Horazont am So Feb 24, 2008 13:25, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Allgemeines zum Gameplay
BeitragVerfasst: Fr Mai 18, 2007 15:55 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Auf Anfrage mal ein wenig zum Gameplay:

Es wird zwei verschiedene Spielmodi geben, die sowohl im Single- als auch im Multiplayer verfügbar sind. Der Standardmodus ist der Mehrplanetenmodus. Hier sind alle Technologien verfügbar. Man startet alleine auf seinem Planeten (zumindest wenn man es nicht anders in den Spieleinstellungen angegeben hat, man kann auch pro Team einen Planeten zuweisen lassen) und muss sich dort erstmal ein wenig aufbauen. Irgendwann (bei einigen Rassen früher, bei anderen ein wenig später) hat man die Technologoien, die für den Weltraum erforderlich sind und kann erste Raumschiffe und -stationen bauen und den Weltraum erkunden.
Der zweite Spielmodus wird der Einzelplanetmodus sein. Hierbei starten alle Spieler auf einem Planeten. Sollten es verschiedene Rassen sein, wird der Typ des Planets zufällig aus den Startplaneten der Rassen ausgewählt. Die Weltraumtechnologien sind hierbei gesperrt, das heißt es ist einfach ein verhältnismäßig klassisches Ground-Strategy-Game.

Der Multiplayer wird eine Besonderheit (zumindest glaube ich, es noch nicht bei anderen Spielen gesehen zu haben) haben. Der Server kann die Bots auf die Clienten verteilen, sodass die Rechenlast nicht nur bei ihm liegt. Das hat allerdings den Nachteil, dass das ausklinken eines Spielers einen kurzen Augenblick länger dauert, da die ganzen Botinformationen zurück an den Server gegeben werden müssen. Sowohl Clients als auch Server werden die möglichkeit haben, diese Funktion zu deaktivieren, was bei Servern heißt, dass die ganze Rechenlast bei ihnen bleibt, bei Clients bedeutet es lediglich, dass sie keine Bots vom Server annehmen.
Gegebenfalls kann der Server es auch erlauben, dass die Clients eigene Bots einklinken, die dann aber beim verlassen mitgenommen werden, also auch aus dem Spiel sind.
Der Server wird ein Zeitlimit für die Runden festlegen können.
Internetspiel wird wohl nur direkt über IP bzw. über mein Server-Listing-Module möglich sein, da ich keinen Server zur verfügung habe, der die Last übernehmen könnte, daher wird der Server einen Port geöffnet haben müssen oder man benutzt eben Tools wie Hamachi.


Es wird auf dem Boden neun verschiedene Einheitentypen pro Rasse geben, per Mod kann man natürlich auch mehr oder weniger einbauen. Einige werden jetzt sagen, dass das deutlich zu wenig sind, aber ich bin der Meinung das reicht :wink: . Interessant wird bei ihnen sein, dass die "neun" nur die "Karosserien" betrifft. Es gibt also neun "Karosserien" pro Rasse, auf die man dann selbst Waffen, Schilde, Generatoren und Antriebe bauen muss, wofür je nach Klasse unterschiedlich viel Platz zur Verfügung steht. Es gibt drei Überklassen, das sind die Mechs, die Panzer und die Nahbodengleiter, von jedem gibt es noch einmal eine leichte, eine mittlere und eine schwere Version, die dann wie erwähnt unterschiedliche Ausrüstungen tragen können. Über Infanterie mache ich mir noch Gedanken, aber ich glaube, die werde ich weglassen.
Bei Gebäuden verhält es sich ähnlich wie bei den Einheiten, nur dass es deutlich mehr geben wird. Auch einige Gebäude werden Waffen tragen, alle werden aber Schilde haben können. Die Energie wird hier nicht wie bei den Einheiten aus Generatoren sondern aus den planetaren Kraftwerken gewonnen.

Im Weltraum finden sich pro Rasse jeweils sieben Raumschiffklassen, die ebenfalls wie die Einheiten ausrüstbar sind. Die sieben Klassen sind Korvette, Fregatte, Zerstörer, Schlachtschiff, Frachter, Träger, Jäger. Jede Schiffsklasse hat eigene Eigenschaften, wie Größenklasse (flighter für ein kleines Kampfschiff, frighter für ein kleines Frachtschiff, battleship für ein Großkampfschiff, vielleicht kommen noch welche dazu), Hangargröße (wie viele kleine Schiffe reinpassen), Frachtraumgröße für Waren und noch einiges mehr.
Raumstationen können genauso wie Bodengebäude Schilde und Waffen (teilweise) tragen, allerdings brauchen sie Energiegeneratoren, da natürlich kein planetares Kraftwerk zur Verfügung steht.

So, ich glaube das wars vorerst.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Okt 29, 2007 15:39 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Hi

Ja, das projekt gibt es noch, aber ich habe einige zeit nicht daran gearbeitet. Nun ein Fortschritt:
Nach langem Arbeiten habe ich jetzt eine einigermaßen annehmbare Partikelengine gebastelt. Diese muss allerdings noch massiv verbessert werden, sie geht bei >2000 Partikeln gnadenlos in die Knie, wofür sie allerdings Subframe Sampling unterstützt. Diese Technik ermöglicht es, selbst bei niedrigen Frameraten die Partikel noch flüssig laufen zu lassen. Ohne Subframe Sampling kommt es zu Partikelhaufen. Deren Ursache liegt darin, dass ohne Subframe Sampling nur einmal pro Frame die Spawn-Routine durchlaufen wird. Wenn jetzt ein Frame länger dauert, als die zeit, die zwischen zwei Partikeln liegt, dann werden alle Partikel, die in der zwischenzeit hätten gespawnt sein sollen auf einmal gespawnt, was sich dann in dem erwähnten Haufen äußert. Subframe Sampling vermeidet dies, indem es die Spawn Routine in bestimmten virtuellen Zeitabständen aufruft.
Ohne Subframe Sampling können auch höhere Partikelanzahlen erzielt werden. Subframe Sampling benötigt für 2000 Partikel genauso viel Zeit wie ohne Subframe Sampling für 10000 gebraucht wird. Diesen Abstand zu verringern ist dann mein nächstes Ziel.
//Edit: Dank einer kleinen Optimierung (<20 Zeilen) ist der Unterschied jetzt praktisch nicht mehr spürbar

Und hier noch ein Screenshot:
Bild
(klick für größer)
Hier sind es 100 additiv gerenderte Partikel.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Zuletzt geändert von Lord Horazont am So Feb 24, 2008 13:25, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 22, 2007 16:36 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Eine eher nebensächliche Info, aber ich habe mich jetzt endgültig für eine Audiobibliothek entschieden.
Eigentlich hatte ich vor, alle drei Konkurrenten ausführlich zu testen:
FMOD
OpenAL
SDL_mixer.

Allerdings bin ich bei FMOD hängengeblieben und nicht mehr zu den anderen beiden gekommen. Dafür habe ich jetzt einen vollständigen Audioplayer für die Konsole mit Spectrum- und Waveformanalyzer, Pitch und Volumeregelung sowie Unterstützung für Livestreams. Nunja, damit ist wohl klar, was ich nehme. FMOD wins.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Dez 01, 2007 19:45 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Hi ihr alle

Obwohl ich das sicherlich schon irgendwo erwähnt habe, hier noch einmal ein Überblick über die GUI. Das eigentlich nur deshalb, weil mir aufgefallen ist, dass ich bisher nur einen einzigen GUI-Bezogenen Screenshot gepostet habe, und der ist auch noch aus den Anfangszeiten des Projektes.

Also. Die GUI kann mittlerweile Labels, Buttons, Listboxen und Panels.
Die Listboxen waren ein harter Brocken, zumal es nicht einfach war, das Scissoring richtig einzurichten, außerdem muss da noch ein wenig an der Performance geschraubt werden.

Außerdem ist die GUI fähig, Texturen mit Rändern zu strecken. Man kann also angeben, wie groß der nicht zu streckende Rand oben, unten, links und rechts sein soll und der wird separat gezeichnet. Das ganze klappt übrigens auch fürs Wiederholen von Texturen, was auch nicht unbedingt einfach war.
Anstatt Texturen kann die GUI auch Farbwerte verarbeiten, sodass man Elemente aus einfachen Farbübergängen erzeugen kann, wie es auch auf dem Screenshot zu sehen ist.
Transparenz ist natürlich bei beiden Varianten voll unterstützt.

Und dazu gibts dann auch den Screenshot:
Bild

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Mai 22, 2008 16:21 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
So nun ist mein letzter Beitrag hier ne ganze Weile her und ich muss unbedingt mal wieder etwas schreiben. Entgegen dessen, was man vielleicht annehmen könnte, lebt das Projekt noch.

Es gab zwar in letzter Zeit immer wieder irgendetwas, das mir dazwischengekommen ist, aber ich komme doch vorran, selbst wenn nur in kleinen Schritten.

Zuerst einmal habe ich meine Partikelengine ausgebaut. Vorallem habe ich das Scripting endlich eingebaut gehabt, mit Lua. Damit habe ich zuerst einmal einen kleinen Feuerpartikelemitter mit Rauch gebaut:
Bild
Leider kam da auch ein großes Problem auf, welches mit dem Garbage Collector von Lua und meinen Plänen was die übergabe von Objekten an Lua betraf, weshalb ich seit kurzem und dank der Tutorials von Delphic und einer menge Tipps von littleDave an einer eigenen Scriptsprache arbeite.

Zwischendrin habe ich mich darum gekümmert, wie ich die GUI aus Dateien lade. Wie bei allen Daten, die das Projekt verwenden wird, kommt auch hier XML zum Einsatz. Man kann eine Art Stylesheets festlegen, die z.B. eine Textur oder einen Verlauf deklarieren, der dann unter einem eindeutigen Namen, den man dort mit angibt, in allen Elementen verwendet werden kann. Auch hierzu habe ich ein Bild:
Bild
Dies zeigt den vorraussichtlichen Ladebildschirm des Projektes, das Modell in der Mitte wird sich aber vermutlich noch ändern, vielleicht eine Darstellung einer Galaxie oder so (ich brauchte erstmal einen Platzhalter). Die Lichtstrahlreihe rotiert dabei um den "Projektor" herum. Auch kommt natürlich noch der finale Name für das Projekt dort oben hin, anstatt "SoTecWare's Strategy Game", ich muss mir da unbedingt noch was ausdenken.

Nebenbei habe ich mit der Story angefangen, ich habe da schon ein paar konkrete Einfälle. Sobal die ersten paar "Kapitel" (später dann vermutlich Missionen) fertig sind, werde ich die hier mal Hochladen, wenn interesse besteht.

Also: Ich und das Projekt leben noch :wink:

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 08, 2009 11:37 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Auch hier kann ich mal wieder ein Update bekannt geben.

Ich habe mich entschieden, mal die komplette worldmanager.pas in die Tonne zu treten und alle Klassen dafür neu aufzubauen. Dabei bin ich dieses mal deutlich strukturierter vorgegangen, habe vorher Listen und Diagramme erstellt, bis ich mir sicher war, dass mein Konzept so einigermaßen akzeptabel ist..
Das ist jetzt auch schon ein paar Monate her, angefangen hab ich damit kurz vor Weihnachten ;).

Weiterhin habe ich das Netzwerkinterface neu aufgebaut, weil SDL_net mir zu viele Mängel hatte. Außerdem habe ich Synapse entdeckt, welches mir auch viel mehr Spaß macht. Leider leiten die Klassen nicht von TStream ab, sonst wäre das perfekt.
Ich habe auch schon angefangen, ein netzwerkprotokoll zu entwerfen, um einen groben Überblick darüber zu bekommen, wie ich die Client-Server-Kommunikation, die Datentrennung zwischen Client und Server und den ganzen Rest gestalten kann.

Nebenbei arbeite ich auch wieder an Thorium, damit ich endlich eine solide Scriptsprache für die Arbeit in der GUI oder den Partikelsystemen habe. Vorallem bin ich darauf gespannt, welche Performance Thorium bei Partikelfunktionen für Spawning und Death hinlegt... Allerdings mache ich mir keine Illusionen: Wahrscheinlich wirds relativ langsam. Dann werde ich das Konzept für die Partikelemitter etwas umstellen müssen und die dynamischer Hardcoden (klingt widersprüchlich, ich weiss ;) ).

Zu meinem Weltkonzept werde ich hier auch noch bald einen Thread aufmachen, damit ich mir von den "großen Jungs" (äh, und Mädels natürlich, wenn die was dazu zu sagen haben ;) ) ein paar Tipps abholen kann, beziehungsweise einen abschließenden Kommentar.

An dieser Stelle will ich mich auch noch einmal für den Klasse Support hier bedanken, speziell in den Konzeptthreads die ich hier ab und zu starte, bezüglich dieses Projektes (RefIDs, Weltaufbau usw. usf)

Gruß Lord Horazont
:)

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Mai 24, 2009 01:06 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Langsam ernährt sich das eichhörnchen - aber okay.

Ich arbeite auch hin und wieder (wenn ich nicht gerade Dawn Of War spiele, mit Frase über Interfaces, Streams und EBML diskutiere, mit ihm und i0n0s zusammen D2 zocke, auf irgendeine weise anderen leuten bei ihren (Informatik-bezogenen) Problemen helfe oder an anderen Projekten schreibe) am Strategy Game. Ich habe auch mal ne hübsche Mind-Map gemacht, die alle Objekte des Strategy Game in irgendeine Ordnung bringt.... Ich dacht mir, das enthalte ich euch nicht vor und hab mal ne PNG draus gemacht. Ein bisschen groß geraten und ohne die Funktion von FreeMind, zweige auch einzuklappen (Standard, denke ich), wäre ich auch hoffnungslos verloren. Diese Karte stelllt alle Objektarten, die es im Spiel geben wird, dar. Jede Klasse hat hier also vier Unterpunkte. Unter "<Inheritors>" sind die Nachfahren der Klasse, unter "Actions" die Methoden des Controllers, unter "Definition data" die Definitionsdaten, die aus der XML-Datei gelesen werden können und unter "Runtime data" die Daten der eigentlichen Instanz dargestellt. Eigentlich sind es also drei Vererbungslinien, etwas anders dargestellt.

Joa, und diese MindMap habe ich hier jetzt immer links neben Lazarus offen und verändere sie simultan zum Quelltext beziehungsweise umgekehrt. Sie dient mir so als Dokumentation, damit ich nicht allzu schnell den Überblick verliere. CodeExplorer hin oder her, irgendwann gehts einfach nicht mehr.

Ich habe mir nebenbei viele, viele Gedanken gemacht und die auch teilweise zu Papier gebracht habe, etwa beispielsweise über das Diplomatiesystem, Kolonien und etwas auf View-Ebene, nämlich Aktionen (also so lustige kleine Buttons, wie man sie aus vielen Strategiespielen kennt, die dann Einheiten bzw Gebäuden zugeordnet sind). Dazu noch viel viel Kram, der mir jetzt gerade nicht mehr einfällt. Beispielsweise dürfte die MindMap nichtmal ansatzweise vollständig sein - vieles denke ich mir dazu und schreibe es nicht auf, weil es sich sowieso in mein Hirn eingebrannt hat. Ohgott, mir darf jetz nur keine ... größere Langzeitablenkung über den Weg laufen, sonst ist vermutlich die hälfte weg.

So, dank der tatkräftigen Hilfe der "Mädels", die ich im letzten Post wohl unterschätzt habe (;)) gibts nun auch das Model-Controller-View-Konzept. Das dürfte denke ich bekannt sein, man trennt Daten, Darstellung und Aktion. Hier allerdings endet das in sieben Vererbungslinien. Einmal die Definitions-Reihe, wo für alle Spielklassen, die in XML-Dateien definierbar sind, eine Klasse existiert. Dann die eigentliche Model-Ebene, wo die Datenklassen implementiert sind. Die Haupt-Controllerebene, wo alle Methoden der Objekte definiert und teils auch implementiert werden. Die Controller-Interfaceebene, wo die Controller nochmal als Interfaces abgebildet werden. Die Client-Controllerebene, wo alle Methoden, die Clientseitig anders sind als in der Hauptebene entsprechend verändert wurden. Diese Klasse implementiert dann das Interface und wird dann an die Haupt-Controllerklasse weitergegeben. Das gleiche gibts dann noch mal für die Serverseite.

Ohne viel Implementation nimmt der Worldmanager schon 3865 Zeilen in Anspruch, es fehlen noch die komplette Client- und Serverseitige Controllerdeklaration sowie große Teile der Interfaces. Die Datei frisst 131 KB, was für ein leeres Gerippe schon ziehmlich Krass ist. Ich frage mich, auf was ich mich da eingelassen habe. Aber irgendwann bekomm ich das fertig. Ich habs zu weit gebracht um aufzuhören ;).

Achso. Ich habe auch schon etwas an der Story geschrieben. Ich weiss nicht, ob das so berauschend ist und eventuell ists teils nen bissl holprig, vorallem, wenn ich spät dran gearbeitet habe (was bei der Story häufiger vorkam) oder Pausen zwischendrin gemacht habe. Aber hier gibts schonmal ne Vorschau. Ich hoffe nur, dass ich das auch implementiert bekomme. Eventuell kommt noch irgendwo etwas abwechslung dazu, sodass man sich entscheiden kann, wie man agiert. Im Text sind immer kleine Einschübe, die Informationen über das geschehen nebenbei geben (Gebäude, die freigeschaltet werden, usw.). Alles, was Text ist, wird als Gespräch oder Cutscene angenommen. Vielleicht auch nicht. Hängt vom Kontext ab, ich hoffe, ihr kommt damit klar. Ansonsten: Fragen, Anregungen usw. bitte an mich :).

gute nacht, und jetzt wirklich, Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Strategiespiel
BeitragVerfasst: So Jan 31, 2010 12:26 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Nach einem Dreivierteljahr ohne Updates, und das leider auch hinter der Kulisse, habe ich nun beschlossen, das Projekt offiziell aufzugeben. Ich hatte das schon Anfang diesen Jahres vor, habs aber immer wieder vor mich her geschoben. [edit]Nach der Diskussion im Meinungsthread war ich wohl auf veralteten Stand. Der Thread bleibt bestehen[/edit]

Zwar ist das ganze Konzeptuell vermutlich möglich und womöglich könnte ich es auch Umsetzen, aber mir fehlt die Motivation daran weiter zu arbeiten. Auch dass ich immer wieder im eigentlichen Gameplay in meinem Kopf umstrukturiert habe, hat nicht geholfen.

Thorium ist hiervon übrigens nicht betroffen. Das entwickle ich beizeiten weiter, Support gibts dafür sowieso noch.

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 13 Beiträge ] 
Foren-Übersicht » Sonstiges » Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 30 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.040s | 17 Queries | GZIP : On ]