Ach ja, DAS ist eine der beiden PNs, die noch ungelesen in meinem Postfach liegen (hatte die als Erinnerung an mich selbst geschickt, damit ich nicht vergesse, mich da mal zu registrieren, aber mich inzwischen an die eingeblendenen Notifications gewöhnt :o )…
[QUOTE=Firephoenix]Das pdf ist nicht mehr verfügbar.
Wie ist denn der aktuelle Stand bei euch?
Gruß[/QUOTE]
Was mit dem PDF ist weiß ich nicht, das müsste @MrBarsack beantworten.
Der aktuelle Stand ist, dass wir Forschung, Tests und Diskussionen zu zwei verschiedenen Lösungsansätzen durchführen. Es ist schließlich ja auch elementar, wie das ganze Projekt aussehen soll, bevor man anfängt einfach zu coden. 
Mehr ins Detail zu gehen würde jetzt vielleicht etwas den Rahmen sprengen, deswegen würde ich mal warten ob MrBarsack das PDF nochmal hochlädt, da stand glaub ich schonmal einiges drin.
Wir haben dich schon vermisst. 
Hey,
Das pdf ist nicht mehr verfügbar.
Wie ist denn der aktuelle Stand bei euch?Gruß
Tut mir leid, die PDF ist wohl nach dem Server-Umzug verschwunden. Hier nochmal hochgeladen:
http://download.jemgengine.com/Treffen/Treffen31.08Ergebnis.pdf
Den aktuellen Stand hat @Gonzo schon gut erklärt. In der PDF war bzw. ist eine Zusammenfassung von unserem letzten Treffen. 
Ach ja, DAS ist eine der beiden PNs, die noch ungelesen in meinem Postfach liegen (hatte die als Erinnerung an mich selbst geschickt, damit ich nicht vergesse, mich da mal zu registrieren, aber mich inzwischen an die eingeblendenen Notifications gewöhnt )…
Kann passieren. Hab dich mal auch ins Core Team gepackt, damit du auch alle Bereiche siehst.
Demnächst, am 14. wird übrigens wieder ein Treffen zur Engine stattfinden. Wir wollen uns nun endgültig bezüglich der Basis der Engine entscheiden.
Gruß, MrBarsack
Klingt ziemlich spannend, was ihr da vorhabt. Kann man erfahren, was das Ziel des ganzen ist?
Generell: Weltherrschaft.
Aber nochmal ernst: Weiber und Bier. :o)
Es soll kurz gesagt eine Game-Engine werden, die es ermöglichst in einer Sprache zu entwickeln und dann für “alle” Plattformen sein Spiel zur Verfügung zu stellen. Im Prinzip eine “plattformunabhängige” Game-Engine. Dazu gibt es (grob zusammengefasst) zwei Ansätze, die wir momentan diskutieren. Entweder 1) Die Game-Engine wird in einer Sprache (Java) entwickelt und zur Verfügung gestellt und von dort auf alle Plattformen gebracht. Oder 2) Die Game-Engine wird in mehreren Sprachen angeboten und bei Bedarf wird der Source-Code konvertiert um eine bestimmte Plattform ansprechen zu können.
Beide Ansätze haben Vor- und Nachteile, es ist nicht zuletzt auch die Frage des Aufwands. Und im Falle von Option 1) wäre es recht wahrscheinlich, dass die Game-Engine auf libGDX aufsetzt.
Hey,
Klingt ziemlich spannend, was ihr da vorhabt. Kann man erfahren, was das Ziel des ganzen ist?
Also, da zitiere ich mal den Starterpost:
Dies steht für Java Easy Multi-Platform Game Engine. Ziel des Projektes ist es, eine „Game Engine“ zu erstellen, welche:
[ul]
[li]Möglichst viele Plattformen erreicht,
[/li]> [li]Dem Entwickler vieles erleichtert / viel Arbeit abnimmt,
[/li]> [li]Hohen Funktionsumfang bietet,
[/li]> [li]Und trotzdem einfach zu verstehen ist.
[/li]> [/ul]
Und das ist auch noch aktuell das ungefähre Ziel. Über genauen Funktionsumfang wird in den kommenden Treffen bzw. im Forum diskutiert.
Edit: Gonzo war etwas schneller.
Derzeit wird es wieder spannender. Wir haben bereits angefangen das Projekt zu organisieren.
Intern haben wir schon so einige Diskussionen durchgekaut, auch die Ideen die ich anfangs hatte - verworfen wurden diese nicht, haben uns dazu aber entschlossen als Grundbaustein libGDX zu nutzen so wie es die Grundidee der Engine bereits vorgab.
Mein Kopf sprüht so vor Ideen und Umsetzungsmöglichkeiten, nur eben spielt der Zeitfaktor eine rolle.
Da das ganze noch nicht wirklich Spezialisiert wurde, möchte ich auch eine Äußerung der Engine machen worauf hier noch nicht näher eingegangen wurde. Für mich persönlich ist es wichtig, was sich auch später in der Engine wiederspiegeln wird:
[ul]
[li] Einfach zu bedienen, simple API - Man soll sich ja auf das wesentliche Konzentrieren „Sein eigenes Spiel“[/li][li] Portierungsmöglichkeiten zu anderen Plattformen (Desktop, Mobile/App, Web,…)[/li][li] Weniger Arbeitsaufwand (libGDX wäre so ein Fall: Man muss für jede Plattform ein Projekt erstellen - Das ganze soll wegfallen)[/li][li] simple Nutzung von 2D/3D und 4D (mit Schnüffelsensor und Pupsgeräusche) unteranderem auch mit Texturen und alles was da so zugehört[/li][li] Und noch so einiges mehr… (Audio/Networking/Physic/UI/…)[/li][/ul]
Sicherlich werden auch diverse (Build-)Tools existieren, ich persönlich habe daran gedacht, die Engine in einer oder auch mehrere IDE’s (eclipse, Netbeans, IntellliJ,…) zu integrieren, denn sonst wäre das ganze ja einfach nur ein „Erweitertes Framework“.
Und das ist auch noch aktuell das ungefähre Ziel.
ungefähr ist leider etwas ungefähr gesagt. Es ist das Ziel**.**
Sind multiplayer features angedacht?
Definitiv. Genau diesen Umfang sollte eine Game Engine bieten und dies wird unsere Engine auch bald bieten. Wir legen grad erst den Grundbaustein und dann werden natürlich auch derartige Features implementiert.
An libgdx selber bin ich bis jetzt immer vorbeisgestolpert, da das Setup der Arbeitsumgebung für eine schnelle Entwicklung einfach abartig viel ist, bzw nach viel aussieht
Genau das ist es und dies hindert auch viele Entwickler daran etwas mit libGDX zu machen. Insbesondere wenn man seitens libGDX ließt „Multiplattform“. Es gibt durchaus mit libGDX einen mehraufwand, wenn man ein einziges Projekt(!) für unterschiedliche Plattformen bereitstellen möchte - Und hier kommt die JEMGEngine zum Einsatz.
Sollte man Multiplayer-Support nicht besser spezialisierten Libs überlassen (etwa JGN)? Ich habe den leisen Verdacht, ihr verhebt euch ein bisschen…
Inwiefern siehst du da Schwierigkeiten? In erster Linie ist es ja kein kommerzielles Projekt, dementsprechend haben wir nicht den Druck Kunden bedienen oder einen Termin einhalten zu müssen. Und sicherlich ist es auch ein Projekt bei dem wir alle was lernen können, mal unabhängig vom Ausgang. Wenn am Ende eine eigene Engine steht, die oben genannte Punkte bietet, ist das doch ein toller Erfolg. Ob das dann „die beste“ Engine ist bzw ob sie „den besten“ Multiplayer-Support hat, ist momentan doch eher zweitrangig. Wenn wir merken, dass ein Thema zu groß ist um es mit 3-4 Mann umzusetzen, dann werden wir das schieben oder auf externe Lösungen setzen. Ansonsten hätten wir ja auch gleich sagen können, dass wir ne Engine von null auf hochziehen, aber genau aus diesem Grund (-> Manpower) war es für uns sinnvoller auf ein bestehendes Framework aufzusetzen um unsere Ideen zu verwirklichen.
Offtopic: Sandersdorf, lustig Da war ich bis vor zwei Jahren auch noch desöfteren. Ein guter Kumpel und meine damalige Freundin kommen von dort.
Macht doch erstmal ein konkretes Spiel und extrahiert (bzw. schaut erstmal, was sinnvoll zu extrahieren waere) dann erst eine neue GameLib.
Einfach zu bedienen, simple API
Das ist die hohe Kunst der Softwareentwicklung. Eine einfache API fuer ein komplexes Problem ist furchtbar schwierig zu machen. Leider
Portierungsmöglichkeiten zu anderen Plattformen
Meinst du, LibGDX macht den initialen Arbeitsaufwand zum Spass? Portierung (besonders, wenn es viele verschiedene sein sollen) IST kompliziert.
simple Nutzung von 2D/3D
Warum? Entscheidet euch fuer 2D oder 3D. Das zu kombinieren, schafft imho unnoetigen Aufwand.
Multiplayer: Was schwebt euch denn da vor? Schon mal ein Spiel mit MP, Lag Correction, Interpolation und dem ganzen Kram geschrieben? Wie soll sowas in eine Lib rein? Da fehlt mir grad die Idee
Mein Tipp nochmal: Macht erst das Spiel und wenn der Code dazu genial ist, extrahiert eine Lib. Nicht andersrum!
Das sehe ich ganz anders. Es ist ja nicht so, dass wir blutige Anfänger sind. Wir haben alle schon unsere Spielchen programmiert, ich zum Beispiel schon mehrfach in Java, mit Slick/LWJGL und auch für Android. Da hat man einfach schon gewisse Ideen was es geben sollte und was nicht. Und der von dir vorgeschlagene Weg ist aus meiner Sicht für unser Vorhaben einfach falsch. Wann ist so ein Code denn „genial“? Ist die aus einem Spiel extrahierte Lib nicht vielleicht viel zu spezifisch, u.A. weil das Spiel nur für eine Plattform geschrieben wurde? Haben wir da überhaupt alles gebraucht was wir so an Ideen für die Engine hatten?
Ich halte es für durchaus sinnvoll die bereits gemachten Erfahrungen als Grundlage für eine Engine zu verwenden. Es ist natürlich ganz klar, dass wir bereits während der Entwicklung Tests und Demos bauen wollen und so bekommen wir selbst ja auch einen Eindruck von der „Verwendbarkeit“. Sicherlich ist es auch nicht verkehrt Leute für eine Alpha/Beta-Phase zu gewinnen, die dann einfach mal ihre Spielchen mit unserer Engine umsetzen und dann Feedback geben. Aber das ist noch mindestens 3 Schritte entfernt.
Das ist schon klar. Aber wir wollen dem Entwickler einen fest definierten Grundzustand bieten. Der soll funktionieren, schnell verwendbar sein und für einfache Fälle ausreichen. Jede weitere Funktion ist dann natürlich zugänglich, aber eben kein Muss. Das ist die Idee dahinter, wenn wir sagen, dass wir es „einfacher machen“ wollen. Die Komplexität kannst du nicht beseitigen, aber du kannst die Dinge die am meisten verwendet werden so aufbereiten, dass die meisten Fälle abgedeckt werden.
Das führt das weiter, was ich zum vorherigen Zitat eben schon schrieb. Natürlich ist Portierung kein einfaches Thema, aber wir wollen für einfache Spiele eine einfache Portierung. Natürlich steigt die Komplexität je komplexer das Spiel ist. Aber wieso soll jemand, der nur ein Tic Tac Toe programmieren möchte mit Dingen belästigt werden, die sein Projekt garnicht betreffen? Das ist das was ich mit „Grundzustand“ dann meine. Die Vision bzw der Use Case sieht ja ganz einfach aus: Der Entwickler legt ein neues JEMGEngine-Projekt an, schreibt seinen Java-Code für das Spiel und drückt auf „Bauen“. Dann hat er sein Spiel für alle unterstützten Plattformen. Das zu bekommen ist ein weiter Weg, aber ich bin der festen Überzeugung, dass man sowas hinbekommt. Schritt für Schritt. Und DAS ist ein unglaublicher Mehrwert gegenüber libGDX und anderen Engines/Frameworks.
Wir machen erst 2D und danach 3D. LibGDX bietet beides, also wäre es Unsinn wenn wir das nicht supporten. Aber natürlich ist aufgrund des Aufwands erstmal 2D im Fokus.
Und nochmal zur Erinnerung: Wir setzen auf libGDX auf. Also ist deren 2D- und 3D-Unterstützung schon da. Wir wollen das erweitern und bestimmte Dinge optimieren oder vereinfachen. Von daher ist nicht die Frage ob wir 2D oder 3D machen, sondern wie wir es verwenden und ob wir etwas zusätzliches machen wollen.
Ich will nur am Ende sagen können: „Ich hab’s ja gleich gesagt!“
Offtopic: Sandersdorf, lustig
Sag Bescheid, wenn du mal im Lande bist…
Ist legitim.
Wir werden unsere Erfahrungen machen und wenn das Ergebnis nicht zufriedenstellend war, dann müssen wir eben daraus lernen.
Mein Kumpel wohnt hier in Karlsruhe, deswegen hab ich da jetzt keinen akuten Grund ihn daheim zu besuchen. Und das mit der Freundin… naja, wie gesagt, damalige Freundin eben
Foto? Name? Anschrift? Telefonnummer? Persönlichkeitsprofil?
Gonzo hat imprinzip schon alles gesagt.
Wir habe alle Fachspezifische Erfahrungen und jeder ist in seinem Gebiet gut. Fremde gebiete sollten aber da auch nicht das Problem sein, erstens kann man sich da wunderbar hereinarbeiten, zweitens gibt’s ja auch noch das Team - wir greifen uns dann ohnehin unter die Arme und helfen uns gegenseitig. Und genau so lernt man auch schnell etwas neues: Indem man Erfahrungen austauscht.
Foto? Name? Anschrift? Telefonnummer? Persönlichkeitsprofil?
Warum fragst du nicht gleich nach Facebbook?
Die gleichen Fragen kann ich einfach umdrehen: Ist die Lib nicht zu spezifisch? Oder zu abstrakt, um sinnvoll nutzbar fuer MEIN Projekt zu sein? Sind alle Ideen, die ihr fuer eure Engine habt, fuer die meisten Usecases ueberhaupt sinnvoll? Oder besteht nicht auch die Gefahr, dass ihr irgendwas baut, was niemand braucht und somit als „Ballast“ in der Codebase rumliegt? Wozu braucht man ueberhaupt eine Engine, um ein TicTacToe-Spiel zu entwickeln?
Ich kann nur von meinen Erfahrungen reden und da ist es nunmal so, dass die besten, einfachsten, flexibelsten „Engines“ (egal welcher Bereich, nicht auf Spiele beschraenkt) oder Technologien aus einem konkreten Produkt hervorgegangen sind - und eben nicht andersrum. Da besteht immer die Gefahr, dass man Dinge bereitstellt, die keiner braucht und die wirklich wichtigen Sachen schlicht vergessen werden. Ich nenn das unfairerweise gerne „akademische“ Projekte, denn grad im wissenschaftlichen Umfeld werden gerne die krassesten Dinge gebaut - die am Ende keiner braucht oder benutzen kann.
Deshalb ist meine Empfehlung, mit irgendwas Konkretem zu beginnen oder dieses Etwas zumindest parallel zur Engine/zum Framework zu entwickeln. Ausserdem macht das auch viel mehr Spass und gibt hoffentlich Motivation ueber einen laengeren Zeitraum. Und TicTacToe ist ein schlechtes Beispiel
Welche Platformen wollt ihr eigentlich genau unterstuetzen?
Klingt vielleicht blöd, aber ich finde das in der Hinsicht ein gutes Beispiel. Warum? Unser Anspruch muss es sein auch solche Spiele sinnvoll und schnell umsetzen zu können. So gewinnen wir auch Einsteiger/Anfänger. Und was soll der Vorteil sein? Vor allem auch bei der Portierung auf andere Plattformen und bei der Unterstützung. Und Unterstützung kann in dem Fall einfach sein, dass das Zeichnen einfach gehalten ist, das Fenster ohne Konfiguration erstellt wird und Ressourcen einfach zu handhaben sind. Jetzt nur mal ein Beispiel.
Ich verstehe deine Bedenken, aber wie gesagt, wir haben alle schon Erfahrungen gesammelt, die wir jetzt eben als Ideen umsetzen wollen.
Wie oben schon erwähnt, das befürworte ich absolut. Außerdem ist ein gutes Spiel mit der eigenen Engine ja auch der beste Showcase.
Prinzipiell „alle“.
Desktop wird ja überall dort unterstützt wo ein JRE läuft. Außerdem soll es die Engine für Browser geben, für Android und für iOS. Für den Browser wird GWT verwendet, iOS soll über roboVM laufen. Das sind alles Punkte die aber schon in libGDX da sind. Da müssen wir erstmal nix machen.
Ich hatte schonmal “Moorhuhn” als Beispiel angesprochen. Da hätte man alles zusammen - auch Sachen, die bei TicTacToe NICHT dabei sind. Grafik (ggf. sogar 3D), Sound, Animationen, Interaktionen, und einen Multiplayermodus lutscht man sich da auch noch aus den Fingern. Gleichzeitig ist es so primitiv, dass nicht viel Arbeit in die übrige Spiellogik gesteckt werden muss. Es könnte wirklich als Demo der reinen Funktionalität der Engine dienen. Aber das ist ja nur ein (unverbindlicher) Gedanke.
Der Einwand mit den “akademischen” bzw. am Reißbrett geplanten Libs/Engines/… ist prinzipiell gerechtfertigt. Aber ich habe bisher nicht erkannt, wo diese Andeutung herkommt. Vielleicht HABEN ja alle beteiligten schon ein Portfolio von Spielen, aus denen sie jetzt die besten Stücke rausschälen und in die Engine einfließen lassen. (Da die Punkte, die da diskutiert w(u/e)rden, teilweise schon SEHR “elementar” klingen, glaube ich zwar nicht, dass es “genau so” ist, aber der Übergang ist natürlich fließend)
Tic Tac Toe habe ich ja wie gesagt als Beispiel genannt um auch zu verdeutlichen, dass man Anfänger ansprechen möchte. Sowas wie Moorhuhn ist als Demo natürlich viel besser geeignet, weil es wie du sagst ja mehrere Aspekte abdeckt. Ich hab da auch schon eine andere Idee für ein schönes Spiel.
Nunja, was jetzt die Erfahrung angeht, so ist das sicherlich irgendwo zwischen „rein akademisch“ und „breites Portfolio“. Wir sind ja jetzt auch alle noch nicht so wahnsinnig alt und zumindest von Marco weiß ich ja, dass er ne Ecke älter ist und sicherlich mehr Erfahrung hat. Ich bin generell auch der Meinung, dass man für viele Dinge einfach (Berufs-)Erfahrung benötigt und sie gescheit einschätzen zu können, das habe ich ja während meines Dualen Studiums und jetzt in der Zeit als Vollzeit-Entwickler selbst gemerkt. Aber ich bin auch der Meinung, dass man Ideen und vor allem eine Vision haben muss. Wir haben jetzt trotz der (meiner Meinung nach) tollen Ideen nicht den Anspruch oder gar Druck, dass das Ergebnis perfekt sein muss. Wir glauben aber eben, dass wir etwas bieten können, das viele Leute anspricht. Und das ist ja eben einfach das Ergebnis unserer bisherigen Erfahrungen.
Ich habs ja schonmal erwähnt. Sollten wir auf die Schnauze fallen, dann haben wir ja (hoffentlich) trotzdem was gelernt. 
Genau, es ist ja nicht so dass man damit Geld verdienen möchte, das ganze wird ja ohnehin Opensource bereitgestellt werden.
Die Vision ist einfach und kurz gesagt: Wir möchten eine Engine entwickeln die Anfänger aber auch Profis verwenden können (wenn diese sich denn für unsere Engine entscheiden) die wirklich einfach zu Nutzen ist, die Arbeit erleichtert und die alles bietet was man benötigt. Auch um selbst etwas zu lernen, Erfahrungen auszutauschen und alles was da so zugehört.