Stranded III Dev. Blog - Kommentare
Offline
(ja, die Strings werden extern ausgelagert und man wird auch selbst übersetzen können)
Forum
Projekte Stranded III Dev. Blog - Kommentare(ja, die Strings werden extern ausgelagert und man wird auch selbst übersetzen können)
DC has written@ Hurri04: Eine sehr gute und auch sehr wichtige Frage. Ich habe die Darstellung im Inventar noch nicht endgültig entschieden. Du hast aber bereits 2 der denkbaren Darstellungen genannt (stumpf alles nebeneinander oder mit Unterauswahl). Klar ist nur:
Stumpfes Stacking wie in Stranded II geht natürlich nicht mehr. D.h. unter anderem auch, dass Items ihre Eigenschaften/Attribute/Scriptvariablen NICHT mehr verlieren werden, sobald man sie aufsammelt/einlagert.
Natürlich wird man gezielt auswählen können, welche Items mit welchen Attributen man für Kombinationen oder andere Aktionen benutzen will. Alles andere wäre ziemlich frustrierend und dämlich.
Hurri04: Eine sehr gute und auch sehr wichtige Frage. Ich habe die Darstellung im Inventar noch nicht endgültig entschieden. Du hast aber bereits 2 der denkbaren Darstellungen genannt (stumpf alles nebeneinander oder mit Unterauswahl). Klar ist nur: Stumpfes Stacking wie in Stranded II geht natürlich nicht mehr. D.h. unter anderem auch, dass Items ihre Eigenschaften/Attribute/Scriptvariablen NICHT mehr verlieren werden, sobald man sie aufsammelt/einlagert. Natürlich wird man gezielt auswählen können, welche Items mit welchen Attributen man für Kombinationen oder andere Aktionen benutzen will. Alles andere wäre ziemlich frustrierend und dämlich.okay, dann würde ich als alternative zu meinem vorherigen vorschlag dazu raten, sowas wie tabs zu verwenden, wo dann items in gruppen eingeteilt sind, beispielsweise baumaterialien, werkzeuge, lebensmittel etc.
wäre dabei halt nicht schlecht, wenn sich solche tabs dann über definitionsdateien festlegen ließen.
oder du machst gleich das ganze rucksack-interface modbar, sowas würde dann halt für mod-ersteller nochmal das i-tüpfelchen an freiheit bedeuten
DC has written In Stranded III wird der Trend eher in Klasse statt Masse gehen (was Items angeht). Vor allem beim Bauen wird das denke ich angesichts des Dauerklickwahnsinns aus Stranded II eine gute Entscheidung sein.ich stimmte dem zu, dass es ein paar gebäude in S2 gibt, wo das wirklich nervig ist. allerdings finde ich nicht, dass darunter die anzahl der verschiedenen in S3 enthaltenen items leiden sollte, sondern vielmehr sollte einfach nur ein neues bausystem her
Das Klasse statt Masse hast du glaube ich Missverstanden. Ich meine damit natürlich nicht wie viele verschiedene Items es insgesamt im Spiel geben wird sondern dass man einfach geringere Anzahlen an Items zum bauen brauchen wird (und dafür die Attribute mehr ins Gewicht fallen könnten).
edited 1×, last 29.11.12 02:31:05 am
beim craften von items hingegen könnte dann ein solcher name übernommen werden, sodass man dann einen "Eichenbogen" oder so bauen kann, wenn man einen ast von einer eiche verwendet.
Ich persönlich schätze einfach mal, dass man nicht benannte Holzarten nimmt, sondern nur deren Eigenschaften.
Beispiele:
Ast [hart, lang]
Geeignet für Bauarbeiten, SpeereAst [flexibel, lang]
Geeignet für spezielle Bauarbeiten, BögenAst [hart, kurz]
Geeignet für WerkzeugAst [flexibel, kurz]
Geeignet für... keine Ahnung, da fällt einem bestimmt noch etwas ein. Möglicherweise kann man die Attribute aber auch weiter gefächert fassen. Von sehr lang bis sehr kurz oder so. Oder halt Zahlenwerte. Da gibt es einiges an Möglichkeiten. Speziell zum Scripten dürfte das ganze aber schön zu machen sein. Man könnte nämlich, wenn man die Attribute abfragt, entweder sie ignorieren oder nach ganz bestimmten Items prüfen: if ($ast.haerte > 0) oder so
Aber das ganze kann sich ja noch stark ändern. Vielleicht wird diese Idee irgendwann sogar wieder rausgeworfen und durch eine andere ersetzt, wer weiß.
edited 1×, last 29.11.12 04:44:45 pm
und zwar aus dem vorherigen dev blog update, wo gesagt wird, dass es für objekte und dergleichen statt zahlen-typnummern nun namen-IDs gibt.
muss sagen, da bin ich eigentlich nicht so der fan von, da ich in meinen scripts einige sachen habe, wo ich beispielsweise einfach nach bestimmten faktoren eine variable inkrementiere und dann ein objekt vom typ des variablenwerts erzeuge oder ähnliches.
meiner ansicht nach ist sowas wesentlich effektiver als wenn man erst durch eine liste von objekten durch-iterieren muss...
von daher wäre meine frage, ob man bei diesen namen-IDs auch zahlen einsetzen und mit diesen arbeiten kann.
Eindeutige Bezeichner ohne Kollisionen (z.B. kann man seine Objekte "nickname.objektname" nennen Anhand der Namen ist immer sofort klar, um was es sich handelt. Kein lästiges Nachschlagen von IDs.Wie gesagt werden intern aber dennoch Ganzzahlen als IDs benutzt, da es effizienter ist. Es wäre auch absolut kein Thema, Scriptzugriff auf die internen Ganzzahlen IDs zu gewähren. Diese können sich aber verständlicherweise ändern, wenn man zu einer Mod neue Objekte (Definitionen) hinzufügt. Das Mapping von Textbezeichnern auf Ganzzahlen wird daher in Maps mitgespeichert. Man müsste also vorsichtig sein, wenn man mit den Integer IDs arbeitet und diese mit der Map abspeichert in Form von Scriptvariablen. Die Zuordnung könnte sich ändern und somit für Chaos sorgen.
Aber dennoch wird es sicher möglich sein, auch mit den ganzzahligen IDs zu arbeiten, wenn man das möchte. Nur Speichern in Savegames als ganzzahlige ID ist eben ein problembehaftetes Unterfangen.
edited 2×, last 29.11.12 08:33:13 pm
Ansonsten wird es wahrscheinlich auch einen Befehl geben, mit dem man zu einer ID den Namen zurückgeben lassen kann.
Keine Sorge, das wird schon funktionieren.
Edit: Okay, DC hat das ganze ja jetzt aufgeklärt.
Edit: Gibt es eigentlich schon einen Thread, in dem man allgemeine Fragen zu Stranded III stellen kann? Wie du sagtest, sollte dieser Thread jetzt nicht für allgemeine Fragen missbraucht werden, DC.
edited 2×, last 29.11.12 11:07:41 pm
Im Blog wird ja gesagt, dass die Lua-Schnittstelle komplett in C# geschrieben wurde, daher denke ich mal ist die Antwort C#. Allerdings ist dieses, soweit ich weiß, nicht wirklich plattformunabhängig. Es gibt zwar Mono für Unix und Linux, aber das ist nicht aktuell und hat soweit ich weiß einige Einschränkungen.
Ich programmiere in JavaScript (es ist anzumerken dass das JavaScript in Unity explizite Variablentypen und richtige Klassen hat) aber bin mir nicht sicher ob ich nicht doch vielleicht besser auf C# wechsle. Einen Unterschied macht es aber nicht, da Unity den gesamten Code gleichermaßen kompiliert. Es kommt also das Gleiche dabei raus, egal welche Sprache man nutzt. Man kann daher theoretisch sogar die Sprachen vermischen also einen Teil in C# schreiben und einen anderen in JavaScript oder Boo.
Lass das bitte drin! Es ist zu genial, um es wieder zu entfernen. Naja, vielleicht nicht als Standard, aber bitte als Option oder spezielles Easter egg. Wäre dann sowas wie die Explosionen auf der Menü-Insel in Stranded II bei einem Rechtsklick.
Aber auf Dauer vielleicht nervig. Als Option implementieren wäre am besten.
DC: wollte noch was zu dem letzten Blogbeitrag mit Blender loswerden:
so sieht kein einfacher Hammer aus, das ist ein Katapult mit einer Murmel in der Mitte.. --oder wolltest du das im Comicstyle machen?ich würde den Stein viel flacher machen, den Stiel länger und zum zusammenbinden etwas wie Rinde nutzen. (ref. Bilder: eins, zwei)
auch wäre es vielleicht später für die Skalierung gut das metrische System zu benutzen und es so auf die richtige größe zu bringen man könnte mehr modifier nutzen, dass man dann später Dinge leichter verändern kann (sodass man vielleicht sogar später die modifier mit der Zeitleiste verknüpfen kann und man dann im Spiel viele Variationen von einem Item erhalten könnte ) Die Engine Einheiten von der Größe her an eine echte Einheit aus der richtigen Welt anzupassen (Meter) ist natürlich sinnvoll. Ich werde das versuchen. Im Zweifelsfall mit einem Umrechnungsfaktor der intern benutzt wird, so dass zumindest nach außen (Definitionen und Scripts) alles bequem in bekannten Einheiten angegeben werden kann.
An so etwas wie Modifier habe ich auch schon gedacht. Im Prinzip habe ich das schon mit den Attributen (habe ich denke ich in irgendeinem Blog-Eintrag erwähnt) eingebaut. Die Standardwerte kommen von der Objektdefinition, sie lassen sich aber pro Instanz mit anderen Werten überschreiben. Ich habe auch geplant, dass man mit Attributen das Aussehen von Objekten und den Namen von Items beeinflussen kann (z.B.: "epischer Baumstamm" oder "wackelige Axt"). Das ist aber noch nicht umgesetzt.