• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

[Aufgabenstellung] Programmierwettbewerb Nr 4

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
Hallo, ich wollte mal in die Runde horchen: Wie ist bei euch der Stand der Dinge mit dem Moonlander Projekt?
Gibt es Blocker? Gibt es etwas, was leichter als erwartet gewesen ist in der Umsetzung?
Oder irgendwas worauf ihr besonders "Stolz" seid, was besser geklappt hat als vielleicht erwartet?
 

Rakorium-M

NGBler

Registriert
14 Juli 2013
Beiträge
413
Projekt ist eigentlich fertig (bis auf ein paar Kleinigkeiten) und wird gerade getestet. Das fertige Programm werd ich die Tage über mal hier reinstellen.


Am Schwersten (und Nervigsten) war die Umsetzung der Kollisions-Simulation. Trotz ausführlichem Tutorial und Beispiel-Code hab ich Tage damit verbracht, das Teil zu debuggen (inklusive Debug-Code wie "schreib die Szene in eine SVG-Datei, damit ich sie mir genauer ansehen kann"). Wobei ich auf diesen Code jetzt natürlich auch "besonders stolz" bin.

Am Anfang hatte ich einen ziemlichen Blocker mit OpenGL. Das Framework ist einfach null intuitiv, extrem low-level und bläht alles unglaublich auf. Beispiel: Eine transparente PNG-Grafik anzeigen kostete mich ~300 Zeilen Code und zwei Tage Arbeit. Hiermit gelobe ich nie wieder Entwickler zu verfluchen, die DirectX statt OpenGL verwenden :D. Egal was die Linux-User dazu sagen.

Relativ leicht fand ich die restliche Physik (Position, Speed, Beschleunigung, Rotation). Die Mathematik kannte ich schon und konnte das eigentlich einfach runterschreiben.
Außerdem ist Kotlin ne ziemlich coole Sprache. Teilweise hab ich Routinen in 2-3 Zeilen geschrieben, die im C++-Tutorial noch 20 Zeilen hatten.


Gerne verbessern würde ich noch das "Endgame": Momentan kann man den Lander ziemlich schräg stellen, ohne dass das Einfluss auf das End-Ergebnis hat. Außerdem wackelt der Lander manchmal so stark, dass das Spiel ihn als "nicht stillstehend" erkennt. An den Routinen muss ich noch feilen. Wie bestimmt ihr eigentlich, ob ein Landeanflug gelungen ist?


Steht schon was fest wie wir den Code abgeben? Mit Git, oder einfach ein Zip-Archiv hier posten?

Gruß
Rakorium
 

KaPiTN

♪♪♫ wild at heart ♪♫♫♪

Registriert
14 Juli 2013
Beiträge
29.138
  • Thread Starter Thread Starter
  • #64
Morgen fange ich an. Wallah.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
Wie bestimmt ihr eigentlich, ob ein Landeanflug gelungen ist?

Aktuell, Geschwindigkeit beim Auftritt (wählbares Maximum) und Winkel, wobei, der Winkel soll nur simulieren dass der Länder kippen würde. Genau die Physik habe ich nicht drin, zum Beispiel das der Länder nen Abhang herunterrutscht. Aber vielleicht kannst du bei deiner Lösung die Geschwindigkeit bzw. schwere des Aufpralls berücksichtigen? :)

@KaPiTN: Wird langsam Zeit... :D
 

Rakorium-M

NGBler

Registriert
14 Juli 2013
Beiträge
413
Die Aufprallgeschwindigkeit nutze ich schon, um die Beschädigung am Lander zu bestimmen. Außerdem checke ich welches Teil die Oberfläche berührt - das Landegestell verträgt deutlich mehr als der eigentliche Lander darüber.
Danach zeigt sich dann, ob der Lander sich weiterbewegt (kippt, rutscht etc.). Mit guten Reflexen kann man da noch was retten, indem man nochmal abhebt bevor das Ding komplett kippt. Am Ende muss der Lander still und aufrecht stehen bleiben.
Nur "still stehen bleiben" ist manchmal nicht so einfach, wenn der Lander anfängt zu wackeln oder hin- und her zu wippen. Durch die Kollisionskorrektur kann das durchaus ziemlich lange dauern. Dieser Teil der Erkennung macht noch Probleme.
Hab mir auch noch überlegt, eine Art Rutsch-Schaden durch Reibung zu berechnen. Momentan kann man über die Oberfläche rutschen ohne Schaden zu erleiden. Wird aber zeitlich knapp.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
@Rakorium-M: Nichts desto trotz, wenn die Landesequenz sauber funktioniert, ist es ein ziemlich cooles (Zusatz)Feature (mit der +-Physik dahinter). :)
 

exomo

NGBler

Registriert
1 Aug. 2015
Beiträge
129
So ein gute Physik-Engine habe ich nicht, bei mir beschränkt sich die Physik auf die Bewegung des Raumschiffs, also ohne Interaktion mit dem Boden. Kollision wird nur erkannt und anhand der Geschwindigkeit und Drehung des Raumschiffs bestimmt ob man verloren oder gewonnen hat. Die Kollisionserkennung war bei mir trotzdem mit der schwierigste Teil, vor allem weil ich mich mit verschiedenen Ansätzen experimentiert habe. Die Lösung die ich jetzt gewählt habe erlaubt (fast) Pixelgenaue Erkennung ob das Raumschiff den Boden berührt, aber das ist auch alles.

Anfang hatte ich einen ziemlichen Blocker mit OpenGL. Das Framework ist einfach null intuitiv, extrem low-level und bläht alles unglaublich auf. Beispiel: Eine transparente PNG-Grafik anzeigen kostete mich ~300 Zeilen Code und zwei Tage Arbeit. Hiermit gelobe ich nie wieder Entwickler zu verfluchen, die DirectX statt OpenGL verwenden :D. Egal was die Linux-User dazu sagen.
Genau das ist der Grund warum ich für die Grafik eine Bibliothek verwende, obwohl ich sonst auch alles selbst machen wollte. Aber um mich noch mit OpenGL rumzuärgern war mirt die Zeit dann doch zu knapp. Eine transparente PNG-Grafik anzeigen ist sind dann noch etwa 5 Zeilen Code oder so.

Ich hatte ja ein paar Ideen für coole Features, aber wie erwartet bin ich nicht dazu gekommen davon etwas umzusetzen. Ich will heute noch ein paar Kleinigkeiten verbessern und morgen hoffentlich eine "fertige" Version haben, in der zumindest alle Basis-Features drin sind.
 
Zuletzt bearbeitet:

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
Leute, ich wollte nur mal eben anmerken, dass ich das ganz geil finde, was ihr da so zaubert!
Wenn ich mir das so angucke, bin ich doch froh, dass ich nicht mitgemacht habe :D Vielleicht wirds ja irgendwann mal was.

In theSplit's Version bin ich jedenfalls schon ganz gut :D

Viel Spaß euch noch und weiter so! Ich bleibe auf dem Laufenden :beer:
 

KaPiTN

♪♪♫ wild at heart ♪♫♫♪

Registriert
14 Juli 2013
Beiträge
29.138
  • Thread Starter Thread Starter
  • #70
Ich hoffe es nimmt mir keiner krumm, daß ich den Termin etwas reißen werde?
 

exomo

NGBler

Registriert
1 Aug. 2015
Beiträge
129
Ich bin eigentlich nicht fertig mit dem was ich noch machen wollte, aber damit ich den Termin einhalte gibt es jetzt schon mal die V0.9 sozusagen mit hübscherer Grafik. Falls ich noch dazu komme gibt es heute nochmal ein kleines Update im laufe des Tages.

Screenshot:

Video: https://ufile.io/o1ix2i37
Binaries (Windows): https://ufile.io/n862p5mr
Source Code (C++): https://ufile.io/9jprzevd

Ich hoffe das funktioniert mit den Downloads, falls ihr noch Tipps habt wo man besser Videos bzw. Files hochladen kann lasst es mich wissen. Anhänge im Board sind leider auf 2MB begrenzt.
 
Zuletzt bearbeitet:

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
@exomo: Ich kann dein Programm leider nicht starten:

Fehler.png
 

Rakorium-M

NGBler

Registriert
14 Juli 2013
Beiträge
413
@exomo: Same here. Bau mal [kw]-static-libgcc -static-libstdc++[/kw] als Linker-Parameter für GCC ein.
Selber compilieren klappt auch nicht, vielleicht ist mein System zu alt (meint zumindest CMake, ist ein Linux Mint / Ubuntu 18.04). Auf welchem System hast du denn compiliert?
[src=text]In file included from /tmp/ExomoMarsLander/code/src/gel.cpp:1:0:
/tmp/ExomoMarsLander/code/src/../include/stxutif.h: In member function ‘virtual std::__codecvt_abstract_base<wchar_t, char, __mbstate_t>::result gel::stdx::utf8cvt<strict>::do_in(gel::stdx::utf8cvt<strict>::state_type&, const extern_type*, const extern_type*, const extern_type*&, gel::stdx::utf8cvt<strict>::intern_type*, gel::stdx::utf8cvt<strict>::intern_type*, gel::stdx::utf8cvt<strict>::intern_type*&) const’:
/tmp/ExomoMarsLander/code/src/../include/stxutif.h:129:45: error: no match for ‘operator|’ (operand types are ‘gel::stdx::utf8cvt<strict>::state_type {aka __mbstate_t}’ and ‘int’)
_State = (state_type)(*_Next1 & 0x1F) | 1<<28;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
[/src]
 

exomo

NGBler

Registriert
1 Aug. 2015
Beiträge
129
Ach Mist, habe ich die lib schon wieder vergessen, ich packe die DLL heute abend noch dazu oder baue mit den static flags.

@Rakorium-M
gel.cpp ist nicht von mir, aber ich schaue mal warum das sich nicht kompilieren lässt. Das ist eine lib für utf-8 Dateien, wird aber im Moment gar nicht verwendet. Du kannst gel.Cpp einfach löschen und nochmal den cmake configure starten und bauen.

Ich baue auf einem Win 10 mit einem mingw-w64 g++ 8.1
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
@exomo: Unter Debian Unstable bekomme ich auch den/einen Fehler beim kompilieren, hier der Auszug:

[src=text]USERPATH/exomomarslandersource/src/../include/stxutif.h: In instantiation of ‘std::__codecvt_abstract_base<wchar_t, char, __mbstate_t>::result gel::stdx::utf8cvt<strict>::do_in(gel::stdx::utf8cvt<strict>::state_type&, const extern_type*, const extern_type*, const extern_type*&, gel::stdx::utf8cvt<strict>::intern_type*, gel::stdx::utf8cvt<strict>::intern_type*, gel::stdx::utf8cvt<strict>::intern_type*&) const [with bool strict = true; std::__codecvt_abstract_base<wchar_t, char, __mbstate_t>::result = std::codecvt_base::result; gel::stdx::utf8cvt<strict>::state_type = __mbstate_t; gel::stdx::utf8cvt<strict>::extern_type = char; gel::stdx::utf8cvt<strict>::intern_type = wchar_t]’:
USERPATH/exomomarslandersource/src/../include/stxutif.h:98:18: required from here
USERPATH/exomomarslandersource/src/../include/stxutif.h:125:17: error: no matching function for call to ‘__mbstate_t::__mbstate_t(int)’
{ _State = (state_type)(*_Next1 & 0x7F); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/x86_64-linux-gnu/bits/types/mbstate_t.h:4,
from /usr/include/wchar.h:42,
from /usr/include/c++/8/cwchar:44,
from /usr/include/c++/8/bits/postypes.h:40,
from /usr/include/c++/8/bits/char_traits.h:40,
from /usr/include/c++/8/string:40,
from /usr/include/c++/8/stdexcept:39,
from USERPATH/exomomarslandersource/src/../include/stxutif.h:4,
from USERPATH/exomomarslandersource/src/gel.cpp:1:
/usr/include/x86_64-linux-gnu/bits/types/__mbstate_t.h:21:3: note: candidate: ‘__mbstate_t::__mbstate_t()’
} __mbstate_t;
^~~~~~~~~~~
/usr/include/x86_64-linux-gnu/bits/types/__mbstate_t.h:21:3: note: candidate expects 0 arguments, 1 provided
/usr/include/x86_64-linux-gnu/bits/types/__mbstate_t.h:21:3: note: candidate: ‘constexpr __mbstate_t::__mbstate_t(const __mbstate_t&)’
/usr/include/x86_64-linux-gnu/bits/types/__mbstate_t.h:21:3: note: no known conversion for argument 1 from ‘int’ to ‘const __mbstate_t&’
/usr/include/x86_64-linux-gnu/bits/types/__mbstate_t.h:21:3: note: candidate: ‘constexpr __mbstate_t::__mbstate_t(__mbstate_t&&)’
/usr/include/x86_64-linux-gnu/bits/types/__mbstate_t.h:21:3: note: no known conversion for argument 1 from ‘int’ to ‘__mbstate_t&&’
make[2]: *** [CMakeFiles/exomo_marslander_lib.dir/build.make:76: CMakeFiles/exomo_marslander_lib.dir/gel.o] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/exomo_marslander_lib.dir/all] Fehler 2
make: *** [Makefile:84: all] Fehler 2

[/src]
 

Rakorium-M

NGBler

Registriert
14 Juli 2013
Beiträge
413


Anforderungen: Java 8 oder neuer (64bit für Linux / Mac, 32/64bit für Windows), Grafikkarte mit OpenGL 3.2 oder neuer.
Download: MoonLander.jar
Quellcode: Anhang anzeigen moonlander-rakorium-source.zip

Hier Apollo 1337. Huston, wir haben ein Problem! Boardcomputer ausgefallen, Mission Control System offline!

Mitten im Landeanflug der neusten bemannten Mond-Mission bemerkt der Computer an Bord von Apollo 1337, dass neue Updates zur Verfügung stehen und dringend installiert werden müssen.
Die Astronauten reagieren schnell: Im Handumdrehen sind die Anschlüsse von Haupttriebwerk (=Leertaste) und Steuerungsdüsen (=Pfeil links / rechts) freigelegt. Mit etwas Geschick lässt sich damit der Sturz abbremsen und ein sicherer Landeplatz ansteuern - doch der muss erstmal gefunden werden!
Es bleibt nur ein Ziel: Setzt Apollo 1337 sicher auf der Oberfläche ab!




Implementierung
Implementiert wurden Anforderungen 1-4 und 6. Anforderung 5 (zufallsgesteuerte Winde) fand ich unlogisch (der Mond hat schließlich keine Atmosphäre), wurde daher ersetzt durch zufallsgesteuerten Eintrittswinkel.
Als zusätzliches Feature wird die Interaktion zwischen Lander und Mondoberfläche simuliert, der Lander kann rutschen, kippen, abprallen oder sich überschlagen. Deshalb kann ich auf eine festgelegte Landezone verzichten - der Spieler muss selbst eine geeignete Landezone ausfindig machen, auf der der Lander ruhig zum Stehen kommen kann.

Programmiert wurde in Kotlin. An Libraries und Ressourcen wurden verwendet: lwjgl as OpenGL-Wrapper und OpenSimplexNoise (als Perlin-Noise-Ersatz für die Oberflächenform). Teile der Kollisionsberechnung sind inspiriert durch das Tutorial "How to Create a Custom 2D Physics Engine: Oriented Rigid Bodies". Grafik von Lander und Triebwerkfeuer stammen von Google. Rendering, Physik-Engine und die Generierung von Boden und Hintergrund sind selbst gebaut.

Spezifikation Apollo 1337
  • Größe: 10 m
  • Masse: 10,3 t
  • Leistung Haupttriebwerk: ~36 kN (3,5 m/s²)
  • Leistung Seitentriebwerke: ~ 60 °/s²
  • Treibstoff bei Eintritt: 20 l
  • Treibstoff-Verbrauch: 1 l/s (Haupttriebwerk), 0,1 l/s (Seitentriebwerke)
  • Eintrittsgeschwindigkeit: 12 m/s (bei 90 m über der Oberfläche)
  • Schwerkraft Mond: 1,62 m/s²
  • Maximale Belastung Landegestell: 2 m/s
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
@Rakorium-M: Das ist schon, irgendwie, ziemlich schwer die richtige Balance zu finden, um den Lander sanft zu landen. :D
Und eine spannende Einleitung. Für die Präsentation gibts 10 von 10 Punkten! :)
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.728
Ort
in der Zukunft
List sich toll @Rakorium-M :) Und Spiel funktioniert auch.
Einzig das ich eigentlich "gelandet" bin (auf schrägem untergrund - kippte aber nicht und war somit stabil... gab auch keine gerade Stelle am untergrund).
Geschwindigkeit war bei 0.1m/s .. somit bin ich nie gelandet ....
 

Rakorium-M

NGBler

Registriert
14 Juli 2013
Beiträge
413
@theSplit: Danke! Mit etwas Übung geht's eigentlich, sobald man den Dreh raus hat wie man den Lander gerade hält.

@drfuture: Das Problem hatte ich in #66 schonmal angerissen: Der Lander wackelt noch zu viel, weil er bspw. instabil steht (oder weil die Physik nicht genau genug arbeitet). Wenn du noch Sprit hast kannst du kurz abheben und direkt daneben aufsetzen, meist reicht das.
 

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
@Rakorium-M: Coole Version! Hatte grade ein Mission failed und habe mich gefragt wieso. War wohl zu hart aufgesetzt. Eindeutiger für den Spieler wäre es vielleicht noch, wenn die Kapsel in dem Fall explodiert oder sichtbar Schaden nimmt. (Auch wenn das tatsächlich unrealistisch sein mag :p)
 
Oben