Hm.
Klingt ja wie schon wieder Abschied...
Schade.

Also, ich habe relativ wenig bis gar keine Ahnung vom Programmieren. Also lass Dich da nicht von mir und meinen Bemerkungen abschrecken.

Ich weiß auch nicht, wo es Schnittstellen zu anderen Herangehensweisen geben könnte. Aus meinem Heimatprojekt weiß ich, daß bestimmte Sachen (KI, Menüeinbindungen) mit anderen Sprachen geschrieben werden. Vielleicht wäre also für Dich doch ein Mittun möglich. Auch wenn es nicht Deiner prinzipiellen Herangehensweise entspricht.

Oder es klingt, als hättest Du Erfahrung mit logischen Abläufen...

Naja, wie gesagt, ich bin da eher interessierter Beobachter...

@Godot2
Nunja, ich habe schon bei anderen Projekten erlebt, daß die - meist langwierigen - irgendwann auf keine kompatible Entwicklungssprache zurückgreifen konnten.
Von daher halte ich es für gut, mit dem Nutzen der Alpha, einfach in die Zukunft zu arbeiten und dabei - eventuell - mit Einfluss auf die Entwicklung von Godot2 nehmen zu können.
Gibt dann zwar sicher ein paar ärgerliche Probleme, könnte aber auch recht interessant werden. :)


@Grafiken - free

Hast Du Erfahrungen mit den dahinterstehenden Lizenzen?
Oder hast Du schon gestöbert, ob da Grafiken zu finden sind, die bei xforce2 reinpassen könnten?



edit:
Um nicht freiwillige Manpower ungenutzt vergehen zu lassen: ;)
Ich bastele bei TVTower.org (Wirtschaftssimulation, Fernsehprogramm) mit.
Was uns gerade ein wenig Sorgen macht, ist das Fehlen eines Editors, um Filme, Werbungen, Nachrichten etc. bequem bearbeiten zu können.
Die Daten sind als .xml-Dateien abgelegt und ich arbeite da teils mit Browsern...
Falls Du da Interesse hast, schau's Dir einfach mal an.

Das "viel Glück" sollte kein verfrühter Abschied sein. Bewerte es bitte eher als "ich warte mal was dabei heraus kommt". Sollten sich bei Andianas Tests herausstellen, dass das Team sich anderweitig umschaut und Java oder Web in Betracht zieht, verfolge ich das Geschehen weiterhin mit hohem Interesse. C# wäre eine Alternative, allerdings sind hier hohe Lizenzkosten das Problem, sobald die Express-Version des VisualStudios nicht mehr ausreicht. Oh und die latente Bindung an Microsofts Plattform darf nicht vergessen werden (da Crosscompiler nur bedingt tauglich sind).

--- Smalltalk ---

Jeder der hier anwesenden Entwickler wird mir wahrscheinlich zustimmen, dass es bestimmte K.O.-Kriterien gibt, wann und in welchem Umfang man für Projekte entwickelt.

Zum einen ist es nicht ratsam, mehrere verschiedene Programmiersprachen zu vermischen, sofern man nicht mit .NET arbeitet. Im Endeffekt muss kostbare Zeit in Wrapper/Schnittstellen zwischen den Sprachen investiert werden und - das größere Übel - die Entwickler sind nicht austauschbar. Das bedeutet wenn Entwickler A ausfällt, kann Entwickler B nicht ohne weiteres übernehmen (da er ev. die Sprache nicht ausreichend beherrscht). Nicht mehr mit adäquatem Aufwand pflegbare Codesegmente sind der Anfang vom Ende.

Ich selbst kenne keinen Entwickler, der sich in seiner Freizeit intensiv (und ohne monetäre Absichten) in eine Programmiersprache/Umgebung für ein einziges Projekt einarbeitet. Das gilt auch für mich selbst. Ich kann mit umfangreichen Kenntnissen in speziellen und recht unbekannten Toolkits wenig anfangen.

In der Programmierung halte ich gerne an folgendem Motto fest: "mach das was du selber kannst". In klaren Worten heißt das, nutze keine Technik die Du nicht beherrschst. Natürlich muss man das Rad nicht neu erfinden, aber am Ende des Tages ist mir eine kompakte und überschaubare Iso-Engine, die die Entwickler fest im Griff haben lieber, als eine geschlossene Box in Form eines Toolkits. So würde ich z.B. als fiktives Beispiel lieber die UISO-Engine für Java einbinden als Godot zu nutzen. Warum? Weil ich bei UISO die Chance sehe, dass man den Quellcode tatsächlich verstehen und darauf aufbauend weiterentwickeln kann. Ähnlich verhält es sich mit der Verwendung von 3D-Engines, wenn kein begabter 3D-Modeller/-Animateur im Team ist.

Ich bevorzuge eine gesunde Mischung aus Eigenentwicklung und die gezielte Nutzung von Drittprodukten wie z.B. Tiled, die auf bekannte Standards setzen. Standards deshalb, um die Abhängigkeit zu eben jenen Produkten auf ein Minimum zu reduzieren. Sollte in diesem Beispiel der Map-Editor in 1-2 Jahren nicht mehr weiterentwickelt werden oder hoffnungslos veraltet/fehlerhaft sein - dann wechselt man auf etwas anderes, was das Mapformat ebenfalls verarbeiten kann. Was macht man, wenn Godot ab der 2.1 nicht mehr weiterentwickelt oder fehlerbereinigt wird? Nebenher in zehn- oder gar hunderttausende Zeilen fremden Code einarbeiten, um das Toolkit selbst fortzuführen? Bitte nicht falsch verstehen, ich möchte hier nicht Godot diskreditieren, es muss hier nur als Beispiel herhalten. Die Fragen muss man sich bei allen Fremdlösungen stellen, die man ins Boot holt.

Nun denn, ich schwätze einfach zuviel in letzter Zeit, die Textwand hier ist länger geworden als beabsichtet. Wer es dennoch durchgelesen hat, vielen Dank für die Aufmerksamkeit :)


Oh welch Perle ist das gute Stück denn! MadTV! Ich bin positiv überrascht von der ansprechenden Qualität des Remakes. Du sprichst sicherlich von der "database.xml" im Ressource-Ordner. Ein Editor ist das kleinste Problem und zeitnah realisiert (je nach Anforderungen). Ich registriere mich mal in eurem Forum dort und melde mich, damit es hier nicht weiter ins Offtopic abtriftet.

Hey Mayo, danke für den vielen Text ;)

Schade das du nicht so überzeugt von GoDot bist.
Ich finde deine Kritik etwas voreilig.
Die Website wurde erst vor einem Monat neu aufgesetzt, daher dort auch keine News. Die kommen auch leider primär über Twiter.
Die 2.0 Alpha ist zu 1.1 kompatibel, nur die 1.1 kann nichts öffnen was mit der 2.0 erstellt wurde. Ich weiß nicht was daran so negativ ist.
Aber ja Godot ist relativ jung als Open Source Projekt und hat ne relativ kleine Comunity. Aber sie ist doch recht aktiv bei der Entwicklung und es wurde zuvor schon Jahrelang kommerziell genutzt und entwickelt.
Was die Dokumentirrung angeht, da gibt es wirklich noch Verbesserungsbedarf aber die im Editor eingebaute Referenz finde ich schon recht nützlich und andere Docs sind ja auch in Arbeit.
Für Tiled und Blender gibt es ein Import-Modul.



Nun ja da muss man dann durch oder schauen das man es irgendwie portiert bekommt. Aber ob dass nun wirklich mehr Arbeit ist als sich in ein selbsgeschiebenes, vermutlich noch schlechter dokumentiertes Toolkit einzuarbeiten?


Genau deshalb werden wir uns auch nie auf eine Sprache einigen können denn jeder hier kann was anderes und will etwas anderes später machen.

Ähm, wenn ich mich einmischen darf? :)

Mayo hat Interesse, Andiana eine Vision...

Bringt das bitte irgendwie zusammen. Versucht die Berührungspunkte zu finden, das Trennende verstehe sogar ich.

Ich möchte gerne ein richtig schönes Rundentaktikspiel haben und mache dafür auch mit bei dem ganzen uncodischen Scheiß. :)

(Ich übe auch schon Balancing.;)

edit: Textwände sind gut!

Nachtrag:



Also an Bord sind:
- gast2: mischt sich gerne ein ;), testet und gibt Feedback sowie Aufmunterungen, später erstellt er vielleicht (Symbol-)Schriften und einfache Grafiken
- Meine Wenigkeit: Entwickler der fast ausschließlich Linux verwendet und noch nie in Java und C# programmiert hat, nur geringe Kenntnisse von C/C++ besitzt und PHP + HTML5 + JS + CSS nicht für die beste Wahl für ein Offline-Singel-Player-Spiel mit eventuell hohem RAM-Verbrauch (Grafiken + größere Maps) hält

Keine Profi-Entwickler, Grafiker* oder jemand der einen Server bereitstellt und wartet.

Drüber hinaus gibt es wohl ein paar Interessierte die noch Vorbehalte und/oder keine Zeit haben und sich für C++, C#, Python und Rust oder überhaupt nicht fürs Programmieren interessieren.

Daran wird sich vermutlich auch erst etwas ändern wenn man etwas hat mit dem man auf große Werbetour gehen kann.
Auf "Hey ich plane was und suche dafür gute Entwickler und Grafiker" wird wohl kaum einer anspringen.

GoDot mit dem leicht zu lehrenden, Python ähnlichem, GD-Script + C++ Module und per Maus zusammengeklickte Animationen sehe ich da als besten Kompromiss an. Zudem wird es auch mein Wunsch nach einer brauchbaren freien Entwicklungsumgebung unter Linux & Windows gerecht.

Die Grafiken müssen relativ neutral (da verschneide Gamesets), modifizierbar und in einem leicht reproduzierbarem Stile sein. Von daher schweben mir da hauptsächlich 2-fabige Symbole als Grafiken vor.
Gamesets und Mods sollen diese aber "überschreiben" können (und das können sie in meiner nächsten Version bereits).

Der Bodeneinsatz soll natürlich schon hübsch werden, aber dass hängt davon ab ob wir wieder so jemanden wie JohnS bekommen. Auf jeden Fall werden hier 2D Grafiken verwendet. Blender-Experten können ja dennoch 3D Modelle erstellen und davon 2D Aufnahmen speichern.

Die Frage ob unser Projekt die Grenzen von GoDot sprengen wird, sehe ich da mehr als hypothetisch an.
Nach derzeitigem Stand sehe ich da nur das Problem dass niemand sagen kann wie es sich nun entwickelt.
Aber das Problem hat man bei allem anderen auch. Derzeit wird ja bei vielem die Entwicklung nur noch auf Android und iOS fokussiert.



Wenn er GoDot nicht mag aber euch bei TVTower hilft und du dann mehr Zeit für X-Force hast, dann ist doch auch allen geholfen :)



*Btw: Weiß jemand was mit JohnS ist? Ich hatte ihn vor Wochen mal angemailt aber keine Antwort erhalten.

Das Problem dabei ist, daß er genau einen Flaschenhals beseitigen könnte, damit ich mit Texten loslegen kann.
Muß mich da derzeit immer mit den .xml-Kram rumärgern. :)

Aber an sich passt das schon. Und so fix geht das hier ja auch nicht voran. :)
Bin da recht geduldig.

Ja xml von Hand bearbeiten ist eklig, wäre ja schön wenn das klapt :)

Bei meinem X-Force 2 verwende ich übrigens deshalb kein xml oder einzeiler json sondern .cfg-Dateien.
Das lässt sich gut editieren und leicht verstehen, ist aber leider kein exakter Standard.
Später möchte ich deshalb auf toml wechseln.

Ist dies euer game @ gast 2?

http://www.tvgigant.de/en/pages/downloads

Ja. :)

Seit neuestem auch: TVTower.org


Andiana schrieb:
"Ja xml von Hand bearbeiten ist eklig, wäre ja schön wenn das klapt :)"

Habe da jetzt ein paarmal paar hundert Datensätze verändert, korrigiert und erweitert und wieder verändert...
Jetzt sieht .xml schon fast normal aus...

Aber das wäre wirklich eine feine Sache.


Für xforce2 wäre es auch schön, wenn es einen handhabbaren Editor gäbe.
Das wäre wirklich praktisch, wenn das Verändern oder auch nur Zusammentragen der Werte für Waffen, Munition, Panzerungen, Gelände, Baustoffe etc. irgend einfacher ging, als beim alten xforce.
Da habe ich mich für ein Spielsatzbalancing echt muhlig gemacht, allein um die Werte irgend zusammenzukriegen.
Zum Teil wäre es schon hilfreich, wenn es eine Tabellenausgabe der betreffenden Werte geben täte.

@ gast 2

hatte das auf chip.de gesehen und da viel mir ein was du schriebst über tvtower.

Ich werds morgen mal spielen :)

Es waren in erster Linie der Gesamteindruck und die Probleme bei meinen eigenen Versuchen mit der 1.1. und 2.0 Alpha. So konnte ich mein 1.1er Projekt eben nicht in der 2.0 Alpha öffnen, da es mit Abstürzen quittiert wurde. Wahrscheinlich Zufall, Konstellation von installierter Software auf meinem PC, was auch immer. Das maue Gefühl blieb. Aber wie bereits erwähnt, ich wollte nur auf mögliche Probleme aufmerksam machen, die Frameworks mit sich bringen. Wenn Du gute Fortschritte erzielst, soll es die richtige Entscheidung sein.

Ich hatte auch gedacht, dass das Team etwas größer sei. So etwas mit nur einem Entwickler zu starten und zu hoffen, dass sich alles andere wie Grafiker & Co findet ist auf jeden Fall mutig :)


Ich vermute mal, dass Gast2 nicht mit dem Format an sich ein Problem hat (es ist einfacher Plaintext mit simpeln Strukturen), sondern mit den vielen Abhängigkeiten und internen IDs für Genres, Funktionen, Typen usw. Dieselbe Problematik träfe bei TOML auch zu. Es graust mich bei dem Gedanken, dass Du TOML gegenüber XML oder JSON bevorzugst, aber ich bin schon ruhig ;)

So oder so verfolge ich Deine Fortschritte mit Godot. Ich hoffe das ich Unrecht habe und Du mich eines Besseren belehrst. Denn so wie Gast2 habe ich auch Interesse an einem XForce2, egal wie es entstehen mag.

Ja selbstverständlich wird es so etwas später auch geben.
Die Editoren stehen aber recht weit hinten auf der Liste, bis dahin wird man auf einen Texteditor zurückgreifen müssen.
Anfangs gibt es ohnehin nur 2 Gamesets bei denen ich selbst die Finger im Spiel haben werde. Ich muss ja auch testen was ich da fabriziere.

Alles was du genannt hast wird ja in der UFOpädie angezeigt.
Daher wird sich der neue Editor auch mehr an der UFOpädie als an den derzeitigen Editor orientieren.


Oh ok dass ist natürlich was anderes. Ich hatte da kein Problem beim Umstig.
So einen Absturz hatte ich allerdings auch schon mal, aber da hatte ich auch blödsinnigen Code geschrieben.


Ja ich auch :D


Ja ist es, aber die Alternative wäre zu sagen das X-Force doch tot ist. Das will ich aber nicht und hoffe einfach dass ich einen längeren Atem und ein dickeres Fell habe als die 3 vor mir. So in einem halben Jahr werde ich hoffentlich so weit sein dass ich etwas habe was Andere schon begeistert und dann auf große Werbetour gehen.

Nochmal zur meiner angedachten Grafik:
UI Symbole wie hier bzw. wie bei dem neuen X-Com auch bei den Waffen und Einrichtungen usw. Keine aufwendige 3D / Iso Grafiken.
Und so vielleicht der Bodeneinsatz. Aber letzteres hängt sehr stark von dem ab was die Grafiker sagen werden.

Hallo,

nachdem ich hier seit Längerem nicht mehr reingeschaut hatte und ich nun auf diesen Thread aufmerksam geworden bin, auch ein paar Zeilen von mir.

Ich habe mir das GitHub Repository mal angesehen und das erste, was mich abgeschreckt hatte, war der Status des Codes: "GDScript 100.0%".

Ich weiß jetzt nicht, wie die Planung ist, aber falls alles in GDScript geschrieben werden soll, dann sehe ich da dasselbe Problem, weshalb XForce nicht weiter entwickelt wurde. Man sollte hier mal vom Worst Case Szenario ausgehen und sich ausmalen, was passieren würde, wenn die GoDot-Engine nicht mehr zu verwenden wäre, aus welchen Gründen auch immer. Das wäre für das Projekt wohl zur Einstufung möglicher Schwierigkeiten eine Kathastrophe. Ein mehr oder weniger Austauschen der Engine in Verbindung mit Anpassungen an eine neue, würde dadurch zerstört, da man im schlimmsten Falle jede Zeile Code umschreiben müsste, Python-Basis hin oder her.

Natter hatte ja angedeutet, auf C++ o.ä. zu setzen und das sehe ich ähnlich. Wenn, dann würde man doch gerne etwas lernen, was einem vielleicht auch anderweitig noch etwas bringt. Viele Projekte setzen ja anscheinend weiterhin auf C in Verbindung mit z.B. LUA als Skriptsprache für die Spielmechanik.

Ich selbst kenne XForce jetzt schon ziemlich lange und würde sicherlich gerne mal meine paar Zeilen Code beisteuern.

Ja dann ist das Projekt tot.

Aber wie sieht denn das Worst Case Szenario aus wenn man nun auf C + LUA oder C++14 + QT5 setzt?
2/3 nochmal neu schreiben weil in 10 Jahren es kaum noch PCs gibt und man nur noch Swift oder Java interessierte findet. Oder überraschenderweise D/Go/Rust es doch schaffen C/C++ abzulösen?
Oder LUA/QT längst von HTML6 + Dart/CoffeeScript/TypeScript abgelöst wurde?

Ist das so viel besser oder nicht auch das Selbe wie jetzt wo man ein Bruchteil den Codes weiter verwenden könnte wenn man auf Lazarus portieren würde?

Die Frage ist was man für realistisch hält und wie gut man in die Zukunft schauen kann.
Ich für meinen Teil halte für wahrscheinlicher dass wir nicht genug C/C++ Experten finden die hier mitmachen als dass GoDot verschwindet.

Da lasse ich mich da gerne eines besseren belehren und bin gespannt ob du nun C/C++ Programmierer anwerben kannst die fest zusagen.
Ich behaupte dass Leute, die nur paar Zeilen Code beisteuern wollen weil sie C/C++ lernen möchten, auch nicht mehr schaffen als ich alleine mit meinem GoDot.
Mal ganz davon abgesehen dass sie es auch könnten wenn sie GoDot-Module schreiben.

Ja, Risikoanalyse ist knifflig, aber ein paar Aussagen kann man doch mit ziemlicher Sicherheit treffen. Eine Programmiersprache oder Bibliothek, die hunderttausende Nutzer hat, darunter viele große träge Firmen, wird nicht einfach innerhalb von 5 Jahren in der Versenkung verschwinden. Vor allem, da wir ja von einem Videospiel sprechen C++ in der Videospielindustrie noch viel verbreiteter ist als in vielen anderen Branchen. Man kann also IMHO sehr wohl behaupten, dass C++ plus z.B. Qt viel zukunftssicherer ist als irgendeine kleine Open Source Engine.

Ob die zukunftssichere Alternative aber auch aus anderen Gesichtspunkten sinnvoll ist (vor allem im Hinblick auf verfügbare Leuten und Fähigkeiten), ist natürlich eine andere Frage --- eine. zu der ich als Außenstehender nichts sagen kann.

Schön mal wieder etwas von dir zu lesen, sujin.



Ja etwas anderes wollte ich auch gar nicht behaupten.
Nur stufe ich das Risiko dass Godot innerhalb von 5 Jahren einfach in der Versenkung verschwindet auch nicht als sonderlich höher ein. Klar, ausschließen kann ich es nicht.

Aber dass ich auf GoDot setze sollte niemanden davon abhalten die optimale Alternativen zu nennen.
Nur ein "ich würde ja XY nutzen und ein paar Zeilen Code beisteuern" reicht nicht um mich umzustimmen.
Meine Möglichkeiten lassen die Leitung eines primäre auf C/C++/C#/Java setzendes Projektes jedenfalls nicht zu.

?? :)

Ich wollte eigentlich nur auf mein ungebrochenes Interesse hinweisen. :)

Wenn es um die Zukunftsicherheit einer Codebasis geht, wird wohl kaum ein Weg an C/C++ vorbei fuehren. Ich sehe dabei auf einen Zeithorizont > 10 Jahre.
Selbst wenn die Compiler von jetzt auf gleich nicht mehr weiterentwickelt wuerden, gibt es mit gcc einen, der stets kostenlos bleiben wird.
Zudem sind die Sprachfeatures, die mit C++14 integriert sind auch in 10 Jahren noch nutzbar :)
Und ganz zur Not koennte man auch seinen eigenen Compiler compilieren :P

Gegen eine Entwicklung in C/C++ spricht tatsaechlich der Schwierigkeitsgrad der Sprache, bzw. die "einfache" Moeglichkeit weitere freiwillige Entwickler zu finden, die in der Sprache firm sind.

Eine weitere Option waere es natuerlich auch eine bereits verfuegbare -und- verbreitete Engine zu verwenden, die fuer Nicht-Kommerzielle Zwecke kostenlos genutzt werden koennen (Unity, CryEngine, Unreal Engine). Viele dieser Engines koennen mit C++ oder einem Java Dialekt massiv in ihren Faehigkeiten ergaenzt werden.
(Und ja, man kann mit ihnen auch 2D entwickeln :) )

Um den Vergleich einmal zusammen zu fassen:

Reine C/C++ Basis:
+ Sehr maechtige Sprache
+ Maximale Performance moeglich / geringer Overhead
+ Freie Compiler verfuegbar
+ "Aufgabe" der Entwicklung der Sprache sehr unwahrscheinlich
+ Cross-Compiling / Plattformunabhaengigkeit sehr gut moeglich, wenn vom Beginn an darauf geachtet wird
+ Maximale Unabhaengigkeit => "Alles ist moeglich"

- Hohe Lernkurve / Viele Fehlerquellen (Pointer...) => "Langsame" Entwicklung
- Viele grundlegende Spielalgorithmen muessen neu implementiert werden (Grafikmodul, ...)


Verbreitete Engines (UE,CryEngine,Unity):
+ Schnell sichtbare Ergebnisse
+ Ggf. "uniforme" Schnittstelle fuer Codebeitraege (da stets dieselbe "IDE" genutzt wird)
+ Viele grundlegende Mechaniken bereits verfuegbar, meist gut getestet (AAA, hohe Performance, Multicore Support)
+ Tutorials / Module fuer haeufige Probleme vorhanden

- Hohe Abhaengigkeit von der Engine
- Ggf. schlechte Aenderung/Erweiterbarkeit von Kernfunktionen


OpenSource Engines (Godot, ...):
+ Schneller sichtbare Ergebnisse
+ Einige grundlegende Mechaniken bereits verfuegbar

- Maessige Abhaengigkeit von der Engine (Im Notfall kann man durch den OpenSource Status auch selbst Hand anlegen)
- Ggf. fuer selbe Aufgaben geringere Performance im Vergleich zu AAA-Engines.


Meiner Meinung nach geht es nun darum festzulegen, was einem am wichtigsten ist.
Ich stelle hier ein paar moegliche Prioritaeten, mitsamt einer (subjektiven) Rangfolge der entsprechenden Loesungen.

- Zukunftsicherheit
==> 1. C++, 2. AAA-Engine, 3. Open Source Engine

- Implementierungsaufwand (schnelle Ergebnisse)
==> 1. AAA-Engine, 2. Open Source Engine, 3. C++

- Lernkurve (moeglichst niedrig)
==> 1. AAA-Engine, 2. Open Source Engine, 3. C++

- Open Source Basis
==> 1. C++ (gcc), 2. Open Source Engine, 3. AAA-Engine

- Dokumentation
==> 1. C++, 2. AAA-Engine, 3. Open Source Engine

- Community
==> 1. C++ (stackoverflow FTW!), 2. AAA-Engine (Verbreitung), 3. Open Source Engine

- Freiheit / Moeglichkeiten / Unabhaengigkeit
==> 1. C++, 2. Open Source Engine, 3. AAA-Engine

- (Moegliche) Performance
==> 1. C++, 2. AAA-Engine (well-tested), 3. Open Source Engine


Soa.. und nun verschwind ich wieder fuer die naechsten... 2015 Jahre (Laut Forum war ich zuletzt am 30.11.-0001, 00:00 da xD)

PS: Es gibt wohl ein Problem mit Umlauten... immer wenn ich ein "ae","oe","ue" oder "sz" schreiben wollte, hat er meine Wall-of-text nicht genommen <.<... (Habe FF und Chrome getestet)
PPS: Raziel ist auch mein Acc... dachte das "schreibproblem" laege am Alter des Accs...