[Aufgabenstellung] Programmierwettbewerb Nr 4

Jump to last post
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?
 
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
 
  • Thread Starter Thread Starter
  • #64
Morgen fange ich an. Wallah.
 
Rakorium-M schrieb:
Wie bestimmt ihr eigentlich, ob ein Landeanflug gelungen ist?
Zum Vergrößern anklicken....

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? :)

You do not have permission to view link please Anmelden or Registrieren
Wird langsam Zeit... :D
 
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.
 
You do not have permission to view link please Anmelden or Registrieren
Nichts desto trotz, wenn die Landesequenz sauber funktioniert, ist es ein ziemlich cooles (Zusatz)Feature (mit der +-Physik dahinter). :)
 
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.

Rakorium-M schrieb:
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.
Zum Vergrößern anklicken....
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:
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:
 
  • Thread Starter Thread Starter
  • #70
Ich hoffe es nimmt mir keiner krumm, daß ich den Termin etwas reißen werde?
 
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:
You do not have permission to view link please Anmelden or Registrieren

Video:
You do not have permission to view link please Anmelden or Registrieren

Binaries (Windows):
You do not have permission to view link please Anmelden or Registrieren

Source Code (C++):
You do not have permission to view link please Anmelden or Registrieren


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:
@exomo: Ich kann dein Programm leider nicht starten:

Fehler.png
 
You do not have permission to view link please Anmelden or Registrieren
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]
 
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
 
You do not have permission to view link please Anmelden or Registrieren
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]
 
You do not have permission to view link please Anmelden or Registrieren


Anforderungen: Java 8 oder neuer (64bit für Linux / Mac, 32/64bit für Windows), Grafikkarte mit OpenGL 3.2 oder neuer.
Download:
You do not have permission to view link please Anmelden or Registrieren

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
You do not have permission to view link please Anmelden or Registrieren
. An Libraries und Ressourcen wurden verwendet:
You do not have permission to view link please Anmelden or Registrieren
as OpenGL-Wrapper und
You do not have permission to view link please Anmelden or Registrieren
(als Perlin-Noise-Ersatz für die Oberflächenform). Teile der Kollisionsberechnung sind inspiriert durch das Tutorial
You do not have permission to view link please Anmelden or Registrieren
. Grafik von
You do not have permission to view link please Anmelden or Registrieren
und
You do not have permission to view link please Anmelden or Registrieren
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
 
You do not have permission to view link please Anmelden or Registrieren
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! :)
 
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 ....
 
You do not have permission to view link please Anmelden or Registrieren
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.
 
@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)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben