Hurri04 has written
so, nachdem ich gestern in der FH schonmal in über einer stunde (!) nen fetten monster-post geschrieben hatte, den ich blöderweise nicht posten konnte, weil der login-cookie abgelaufen war, als ich auf vorschau gedrückt hatte und deswegen dann der ganze scheiß text weg war (
) (woraufhin ich beinahe
so reagiert hätte), versuch ich dann jetzt einfach nochmal, alles in groben zügen zusammenzufassen.
Dass geschieht dir mit deiner Wall of Text ganz recht! 
:p
Ich kenn das aber. Ist echt bitter... 
Seitdem schiebe ich die Texte bei US vor'm Abschicken lieber noch einmal schnell ins Clipboard. strg+a und strg+c sind ja schnell gedrückt, jedenfalls schneller als 10000 Buchstaben... 
Hurri04 has written
im grunde ist das garnicht kompliziert
Allein die Länge deines Beitrages belegt doch schon, dass es kompliziert ist. 
Hurri04 has written
die bereits vorher erwähnten sender werden als als zielpunkte für den roboter genommen. sobald der spieler einen solchen sender aus dem inventar schmeißt, wird an der stelle auf dem boden ein info erstellt, welches von dem roboter über s2cmd:unitpath angesteuert werden kann. dabei überprüft er zunächst, welches info am nächsten dran ist und schließt dann über eine variable, die die ID des infos, an dem der roboter zuletzte war, bereithält, das vorherige info als neue richtung aus.
Das reicht aber noch lange nicht aus... 
(wenn Robby Roboter bspw. stets nach dem nächsten Info schaut, fährt er ständig zwischen zwei Punkten hin und her...)
Hurri04 has written
damit der roboter auch selbstständig um hindernisse herummanövrieren kann, erstellt man 2 typen von sendern, der eine dient als markierung für einen zielpunkt, der andere als markierung für einen wegpunkt.
So einfach funktionieren Algorithmen zur Hinderniserkennung und -umgehung aber nicht...
Hurri04 has written
der unterschied liegt einfach darin, dass beim erreichen eines zielpunktes kurz pause gemacht wird, dann wird eine animation abgespielt, wie der roboter den schaufelarm ausfährt, in die erde greift und eine ladung davon auf seine lade kippt. gleichzeitig wird auch eine variable erhöht, damit der roboter weiß, wann er zu seiner basis zurückkehren und die erde abladen muss.
bei einem wegpunkt fährt der roboter einfach weiter.
Okay, das geht und kann man auch ziemlich genau so implementieren, ja.
Aber der Roboter kann ja auch zufällig herumlaufen und ab- und zu (zufällig) eine Idle-Ani abspielen. Das spart extrem viel Arbeit und man braucht nur noch beim Event "idle" den Code für die eigentliche Funktion des Roboters eintippen.
Ich wäre dafür die Items einfach einzulagern. Ist der Stauraum voll, kehrt der Roboter zurück, und man kann hier dann auch bequem das Exchange-Menü verwenden.
Hurri04 has written
die zwei unterschiedlichen sender kann man dabei einfach geschickt (für den spieler) in einem einzigen item unterbringen, wenn er einen sender im inventar benutzt, dann legt er (aus seiner sicht) nur einen kleinen schalter an der seite des senders um. scripttechnisch wird einfach ein sendertyp durch einen anderen ausgetauscht (wie etwa bei den lustigen bunten lichtern, die es ja schon in s2lis gibt).
Joa - zwei Schaltmodi quasi. Wäre auch kein Problem.
Hurri04 has written
zudem gibt es noch eine fernbedienung, die ja eh schonmal geplant war, aber wegen mangel von einsatzmöglichkeiten noch nicht eingebaut wurde. diese kann man dann verwenden, um den roboter manuell zu steuern, falls er sich doch einmal festgefahren haben sollte.
zudem gibt es bei der fernbedienung dann noch eine funktion, mit der man dem roboter ein festes gebiet zuteilen kann, damit nachher, wenn man mehrere roboter hat, sich nicht alle gegenseitig auf der pelle hocken.
Naja... (s.u.)
Hurri04 has written
am anfang soll man sich erstmal nur wenige roboter bauen können (1-2). die idee ist, dass man bei den robotern zwischen 2 modi umschalten kann: proben nehmen (und je nach fund fähnchen setzen) oder massig erde von der grabestelle zur basis transportieren.
So ähnlich hatte ich mir das auch gedacht. Bei S2LiS sind ja schon zwei Roboter drin. Der eine müsste das Terrain begradigen und der andere Pflanzen aussähen können, afair...
Hurri04 has written
diese ersten roboter erkunden dann erstmal die gegend, prüfen also, wo was in welcher menge zu finden ist. später, wenn man schon einige fundstellen mit hohen ertragsquoten lokalisiert hat, kann man die roboter dann umschalten, sodass sie die erde abtransportieren.
k
Hurri04 has written
anfangs lässt sich dann (da nur wenig erde angekarrt wird) nur wenig metall aus dieser herausfiltern, aber mit der zeit kann man dann nen paar mehr roboter bauen (5-6 oder auch mehr), die dann größere mengen erde heranschaffen, sodass auch genug metall für größere bauprojekte gewonnen werden kann, wenn der spieler sich an die materialaufwendigeren gebäude, maschinen und werkzeuge macht.
Naja, sicher... Mehr bauen geht immer.
Hurri04 has written
zudem gibt es noch spezielle infos, die eine fundstelle mit erhöhten wahrscheinlichkeiten für das finden der verschiedenen sachen in der erde markieren. diese infos können entweder vom mapper per hand auf der insel verteilt werden oder werden auf zufallskarten eben zufällig verteilt, am besten dann mit einem mittleren radius und in nicht zu kleiner anzahl.
In etwa so wie die Süßwassergebiete, ja. So hatte ich mir das eigentlich auch gedacht...
Da reicht im Prinzip sogar schon ein stupides Info-Objekt - drei, vier Zeilen in der Def. und ein schnödes Icon (Wasser, Erdöl, L-Metall usf.).
Hurri04 has written
wenn ein roboter dann z.b. eine fundstelle erreicht, bei der er (durch ultraschall-sensoren oder sonstwie (spielt ja in der zukunft, da fällt einen schon was ein
)) unterirdisch eingeschlossenes wasser findet...
Läuft in jedem Fall über Schallwellen, ja. Meines Wissens dürfen sich hier allerdings Sender und Empfänger der Welle nicht am gleichen Ort befinden. Das war ja damals bei der "Geosonde" schon das Problem...
Aber eigentlich kann man ja beide - Roboter & Geosonde - zusammenarbeiten lassen. Der Begriff "Messstation" wäre vielleicht aussagekräftiger... Cool wäre auch "Nexus"... Das könnte zum einen eine Messstation (die Geosonde...) sein, welche ständig Daten vom Roboter erhält, zum anderen aber auch quasi die "Tankstelle" des Roboters sein. Denn dieser hat ja nicht unbegrenzt Energie und müsste ab und zu bei seinen Arbeiten eine Pause einlegen und zur Tanke fahren.
Hurri04 has written
aufgrund der tatsache, dass das fundgebiet einen gewissen radius besitzt [...] sollte es dem spieler dann möglich sein, die versorgungsleitungen irgendwie so zu verlegen, dass ein hub genau in diesem fundgebiet ist
D.h. der Spieler muss nicht genau auf ein Fähnchen bauen. Absolut korrekt, so hatte ich mir das auch gedacht. 
Hurri04 has written
s-metall + [werkzeugkasten] => kettenräder
s-metall + [werkzeugkasten] => zahnräder
s-metall + zahnräder + [werkzeugkasten] => getriebe
kettenräder + getriebe + s-metall + [werkzeugkasten] => fahrwerk
zahnräder + s-metall + e-bausatz + [werkzeugkasten] => motor
fahrwerk + motor + e-zellen + s-metall + [werkzeugkasten] => fertiger roboter
Naja... hört sich eigentlich ganz gut an... Hast du da Ahnung von so'n Zeugs? So eine Zerlegung in Einzelkomponenten müsste man ja auch bei vielen anderen Sachen machen.
Bis jetzt hatte ich hier einfach für jedes Material die entsprechenden Materialteile, also "L-Metallteile", "Plastikteile" usw. (Halbzeug sozusagen) als Items definiert, welche man aus dem entsprechenden Material in einer Fertigungsanlage herstellen können soll.
Das da oben ist natürlich cooler. Fehlt allerdings noch ein KI-Chip...
(KI-Chips kann man bei bspw. den Drohnen finden [todo])
Hurri04 has written
bin mir nicht ganz sicher, ob das so viele arbeitsschritte sein sollen/müssen, aber andererseits kann man einige der einzelteile auch noch bei anderen sachen brauchen, etwa wenn man sich einen anderen roboter baut, der einem als fahrendes lager dient (war ja schonmal im gespräch, um den trageaffen abzulösen). den könnte könnte man z.b. auf 2 kettenräder mit 2 motoren setzen, während der erd-roboter auf 3 kettenrädern fährt und auch 3 motoren hat (und dann auch mehr e-zellen braucht).
Hm... gute Idee eigentlich. So ungefähr kennt man das ja auch teilweise von einigen Games. Hab' nur leider keins mehr zu Hause... 
Das Fahrwerk ließe sich ja generell für alles fahrbare (Geländewagen, Roboter...) nehmen. Aber anstelle der "zahnräder" könnte man die von mir angedachten S-Metallteile (oder L-Metallteile, je nachdem) nehmen. Das wäre eine grobere Spezifikation (ansonsten müsste man wohl auch Schrauben etc. mit reinnehmen...) und ließe sich auch für Gebäude verwenden.
Hurri04 has written
die sender sollten einfach herzustellen sein:
l-metall (oder plastik?) + e-bausatz + e-zellen + [werkzeugkasten] => mehrere sender
Ich bin wirklich eher für diese Tankstellen-Hubs die gleichzeitig als Messstation etc. dienen. Man kann ihnen noch weitere Funktionen unterschieben, bspw. dass sie Alarm geben, wenn Feinde in der Nähe sind. Solche Stationen werden ja im allgemeinen eh weiter draußen stehen anstatt mitten in der Basis. Quasi so'n richtiger kleiner Außenposten.
Der Roboter hat dann grob die beiden Modi:
- gehe zu Station
- folge dem Spieler
Eigentlich könnte die Station auch als Lager fungieren. Wird der Roboter einer Station zugewiesen, dann kehrt er stets dorthin zurück, lädt gesammelte Ressourcen ab, tankt Energie, holt neue Pflanzensamen etc. und macht sich dann wieder an die Arbeit (ist das Lager voll, geht er offline).
Roboter die keiner Station zugewiesen sind, können ebenfalls ein Gebiet bearbeiten, gehen aber offline, sobald die Energie alle oder der Stauraum voll ist.
Nein, ehrlich... jetzt wo ich so drüber nachdenke... (erstmal alles markieren und ab ins clippi 
)... die Idee mit dem Außenposten finde ich eigentlich ganz cool.
Sollte quasi wie der Verteiler zu Anfang sein mit entsprechenden Funktionen. Kann man vielleicht auch beides gleich in ein Objekt schmeißen...
Hurri04 has written
die fernsteuerung wird dann praktisch als extra genommen, damit man aber auch sieht, wo man den roboter hinsteuert, wenn man mithilfe der fernbedienung auf seine sicht wechseln will, müsste man noch ein paar kameras herstellen, die dann an den robotern "befestigt" werden können (unit wird einfach gegen eine andere ausgetauscht, deren modell eine kamera dran hat).
Das mit der Kamera wird schwierig... Hatte ich alles schon einmal getestet (meines Wissens gab es da mal eine kleine Testmap "test_drohne" oder so...) Ich weiß auch nicht so genau, wie das dann mit feindlichen Units ist, die dann den Roboter angreifen... Den Schaden soll ja dann der Spieler nehmen, und nicht Robby.
Evtl. will ich da ein wenig am SC herumbasteln.
Hurri04 has written
l-metall (oder plastik?) + e-bausatz + e-zellen + [werkzeugkasten] => fernbedienung
l-metall (oder plastik?) + e-bausatz + e-zellen + acrylglas (für linse) + [werkzeugkasten] => mehrere kameras
Wegen einer kleinen Linse braucht man aber kein Acrylglas... Bzw. dürften das höchstens ein paar Tropfen sein. Eine fertige Linse wird einfach beim E-Bausatz mit reingeschmuggelt.
Ansonsten... ja, würde die Kombis auch so vorschlagen.
(Gibt es hier jemanden der sich um die Defs/Kombis kümmern will...?)
Also ich dachte da an etwa folgendes Menü:
follow (player)
return (wait)
stop (wait)
assign (continue)
refuel (continue)
'wait/continue' bedeutet jeweils ob die gerade ausgeführte Aktion fortgesetzt oder auf neue Befehle gewartet werden soll.
Bei "assign" erscheint ein Untermenü mit allen Stationen zur Auswahl. Mindestens aufgeführt ist hier sicherlich die Basisstation (Verteiler).
Ich habe übrigens gerade beschlossen, dass der Verteiler in Basisstation umbenannt werden sollte.
Bei "return" kehrt die Einheit zur zugewiesenen Station zurück (bzw. ignoriert den Befehl, falls keine Station zugewiesen wurde) und wartet auf weitere Befehle
Bei "refuel" kehrt die Einheit zur zugewiesenen Station zurück, tankt Energie, holt neue Samen, leert den Stauraum usw. und kehrt zur vorherigen Aktion zurück.
Die anderen Kommandos sind sicher klar.
Je nach Drohnentyp ("Drohne" klingt nebenbei besser als "Roboter", finde ich) kommt noch ein zusätzlicher Menüpunkt dazu:
explore
collect (material)
seed (plants)
flatten (terrain)
scout
Sämtliche Kommandos beziehen sich auf ein Gebiet um den aktuellen AI-Mittelpunkt. Dieser wird auf die aktuelle Position der Drohne gesetzt, sobald sie eines der obigen Kommandos erhält.
Das Einzugsgebiet der Drohne sollte also nicht notwendigerweise auf das Gebiet um den Außenposten beschränkt sein.
Wie gesagt führt Mangel an Samen, voller Stauraum, mangelnde Energie usw. zu einem Interrupt und die Drohne kehrt zur zugewiesenen Station (assign) zurück oder schaltet sich an Ort und Stelle ab.
Zu den Kommandos genauer:
explore
- Gebiet nach Rohstoffen untersuchen und Fähnchen setzen
- hier braucht man eigentlich nur einen loop für infos und checkt die distanz zur drohne was keine dolle sache is
collect (material)
- Material in der Umgebung einsammeln
- hier bräuchte man wohl einen loop für items...
- und für objekte... (das scripting dürfte hier tückisch sein...)
seed (plants)
- Pflanzen setzen
- script dürfte schon vorhanden sein
flatten (terrain)
- terrain begradigen
- script dürfte schon vorhanden sein
scout
- nach feinden ausschau halten und ggf. alarm geben, verteigen oder angreifen
Hurri04 has written
im allgemeinen sieht das ganze dann aber folgendermaßen aus (als flussdiagramm):
spieler startet spiel -> fundgebiete-infos werden gespawnt (bei zufallskarte) -> ... -> spieler baut roboter -> spieler bastelt sender -> spieler läuft über map, lässt dabei sender fallen, entweder mit wegpunkt- oder zielpunkt-einstellung -> spieler startet roboter im proben-sammeln-modus -> roboter fährt wegpunkte ab -> roboter nimmt bei zielpunkten proben -> falls die probestelle bei einem fundstellen-info ist, dann ergibt sich wegen des infos eine hohe wahrscheinlichkeit, die auch auf der fahne wiederzufinden ist; falls die probestelle abseits eines fundstellen-infos liegt, dann wird ein neues info erstellt, das aber einen kleineren radius und auch kleinere wahrscheinlichkeiten hat (ebenfalls auf fahne zu sehen) -> sind alle stellen wo ein sender lag untersucht und mit fähnchen versehen, fährt der roboter zur basis zurück -> der spieler sammelt die sender wieder auf und lässt weitere stellen absuchen ODER er verteilt sie so, dass die zielpunkte bei den fundstellen mit den höchsten wahrscheinlichkeiten liegen -> er startet die roboter wieder (abhängig vom vorherigen schritt wieder im suchen-modus oder nun um graben-modus) -> (im falle vom graben-modus) der roboter schafft erde heran, die er in seiner basis ablädt, wo sie gefiltert und aufbereitet wird -> der spieler erhält metall und/oder ton/lehm und kann dieses/diesen dann weiterverarbeiten.
Boah... null Lesefluss... kriegt man ja Augenkrebs...
Oben habe ich mal einen Gegenentwurf vorgeschlagen.
Hurri04 has written
hatte da so ne fixe idee und wollte die mal in den raum werfen, aber wenns nicht gut ankommt, dann auch gut...
Ich wäre ja schon dafür E-Zellen als Munition zu nehmen. Nur wäre mir da so ein Balken neben dem Icon lieb, der mir den Ladestatus der E-Zelle anzeigt...
Wäre das einfach umzusetzen hätte ich es längst gemacht, aber es steht auf jeden Fall auf meiner SC-ToDo.
Man soll sich hier auch zwischen einer grafischen und einer textbasierten Ausgabe entscheiden können, also entweder ein Balken, oder die Ausgabe "5/6" oder "38/50". Außerdem sollte es möglich sein, zu entscheiden, ob zwei Munitionspakete mit einander 'verschmolzen' werden können (bspw. Patronen des einen Magazins ins andere Magazin), oder nicht (Akku/E-Zelle).
Sowas wäre auch für Flaschen (eine Flasche, 5 Schlücke) und einen Haufen anderen Zeugs nützlich. Kenn' ich auch eigentlich nicht anders von guten Strategie-Rollenspielen...
Wie gesagt. Wenn das alles klappt wie ich es mir vorstelle, dann läuft die Laserwaffe mit E-Zelle.
Puh... (strg+a, strg+c) Eigentlich wollte ich noch ein paar Begriffe hervorheben... Bin jetzt aber erstmal k.o. edited 1×, last 26.11.11 09:10:09 pm
Stranded II 
Stranded 2 - Lost in Space Mod (Pre-Alpha-Release)
Offline
...
"
"
"