ZweiDe

Übersicht Sonstiges Smalltalk

Gehe zu Seite Zurück  1, 2, 3 ... 12, 13, 14 ... 18, 19, 20  Weiter

Neue Antwort erstellen

Fetze

BeitragMi, März 03, 2010 23:08
Antworten mit Zitat
Benutzer-Profile anzeigen
Die Steuerung ist sicherlich Geschmackssache, aber soweit ich das bisher sehen kann, ist sie nicht objektiv schlecht.. es gibt ja auch Leute, die sie gut finden oder gut damit klarkommen, darunter auch ich. Ich persönlich finde die Steuerung sehr eingängig und mit etwas Übung gut beherrschbar. Ich denke, es ist Übungssache.

Wenn es konkrete Punkte gibt, die ich verbessern kann, werde ich das gerne tun, aber von kaum jemandem, der sich über die Steuerung beklagt, habe ich bisher konkrete Vorschläge oder konkrete Kritik gehört, zumeist nur "Nicht so toll" oder "Komme damit nicht klar". Ich würde euch ehrlichgesagt gerne mal über die Schulter schauen, um herauszufinden, wo genau es hakt, das merkt man ja auch selbst nicht immer. Wenn ihr eine Idee habt, würde mir das sehr weiterhelfen; ich will die Steuerung auf jeden Fall für möglichst viele Leute zugänglich machen.

(Kleiner Tip: haltet den Mauscursor nicht zu weit unten, denn je weiter unten er sich befindet, desto empfindlicher / schneller reagiert die Steuerung. Das ist bewusst so gehalten - falls es euch also zu hektisch wird, haltet den Cursor eher oben.)

Ich würde mich freuen, noch ein paar konkretere Vorschläge / Anmerkungen zu hören!

ozzi789

BeitragDo, März 04, 2010 8:33
Antworten mit Zitat
Benutzer-Profile anzeigen
Kann es drann liegen dass ich wahrscheinlich nur OGL 2.1 habe, btw wie finde ich das raus?
Sig @home

danke Very Happy
0x2B || ! 0x2B
C# | C++13 | Java 7 | PHP 5

Fetze

BeitragDo, März 04, 2010 11:32
Antworten mit Zitat
Benutzer-Profile anzeigen
OpenGL 2.1 reicht aus. Am besten findest du das mit nem Diagnosetool raus, was du mit deinem Grakatreiber installiert haben könntest.

Probiers aber erstmal mit der neuen glfw.dll, die ich hochgestellt hab, bei D2006 gings danach Smile

ozzi789

BeitragDo, März 04, 2010 12:09
Antworten mit Zitat
Benutzer-Profile anzeigen
Ok werd ich, bin aber gerade anner Abreit, werds heute abend hier rein posten Smile
mfg
0x2B || ! 0x2B
C# | C++13 | Java 7 | PHP 5

Alfadur

BeitragDo, März 04, 2010 17:11
Antworten mit Zitat
Benutzer-Profile anzeigen
Logfile sagt

Entering gamestate MainMenu...
System.NullReferenceException: Object reference not set to an instance of an object.
at Tao.OpenGl.Gl.glGenFramebuffersEXT(Int32 n, Int32& framebuffers)
at Fetze.Module.ZweiDe.Texture.CreateRenderBuffer(TexFlag flags, Boolean reqZBuffer, Boolean floatingpoint)
at Fetze.Module.ZweiDe.TextHelper.SetText(String text)
at Fetze.Module.ZweiDe.TextHelper..ctor(String text, Single xHandle, Single yHandle, TexFlag texFlags, Single aniso)
at Fetze.Module.Fenster.Window..ctor(String title, Single x, Single y, Single w, Single h, Boolean locChildrenArea)
at SteCore.SteApp.OnGameStateEnter(GameState newState)
at StarTrade2.StarTrade2App.OnGameStateEnter(GameState newState)
at SteCore.SteApp.PerformGameStateSwitch()
at SteCore.SteApp.Run()
A Cray is the only computer that runs an endless loop in less than four hours.

Fetze

BeitragDo, März 04, 2010 17:16
Antworten mit Zitat
Benutzer-Profile anzeigen
Bist du sicher, dass du OpenGL 2.1 support hast? Was für ne Grafikkarte hast du, mit welchem (aktuellem?) Treiber? Mehr Informationen! Ein Logfile kann auch nicht zaubern Wink

ozzi789

BeitragDo, März 04, 2010 20:38
Antworten mit Zitat
Benutzer-Profile anzeigen
glfw.dll fix hat geholfen, auf jeden der Hammer Very Happy
0x2B || ! 0x2B
C# | C++13 | Java 7 | PHP 5

Fetze

BeitragFr, März 05, 2010 15:36
Antworten mit Zitat
Benutzer-Profile anzeigen
Meine alte Roadmap ist quasi abgeschlossen und wie die spielbare Techdemo gezeigt hat, ist der Core in den Grundzügen soweit einsatzbereit.

Baustellen, an denen ab jetzt noch gearbeitet werden muss / wird:
Arrow Ausrüstungssystem
Arrow Levelverkettung, Kampagnen, Skript
Arrow Gigantische Content-Massen, das wohl größte Problem (Suche nach wie vor fähige Grafiker!)
Arrow Das User Interface / die Präsentation aller genannter Punkte, läuft so nebenher

Und, speziell für mich und alle, die eventuell später noch Mitarbeiten werden:
Arrow Ausbau des Editors, Priorität auf Leveleditor, sekundär evtl. auch Content-Plugins.

Fetze

BeitragFr, März 05, 2010 20:38
Antworten mit Zitat
Benutzer-Profile anzeigen
Habe heute mal wieder am Editor gearbeitet.

user posted image
user posted image

Der ColShape-Editor war bereits vorher fertig, wurde aber glaube ich bisher noch nicht gezeigt. Das andere ist ein Blick aufs IngameWindow mit daneben arrangiertem ObjectBrowser - an letzterem bastele ich gerade herum.

Der Editor ist modular aufgebaut und basiert auf einer Plugin-Architektur. Standardmäßig gibt es nur ein MainForm das Daten sowie Level laden und speichern kann, jedoch über keine Möglichkeiten zur Modifikation dieser verfügt - ebenfalls immer dabei ist das IngameWindow, welches einen WYSIWYG-Blick auf das Spiel ermöglicht. Alles andere ist in je eine separate PlugIn-Dll ausgelagert, so beispielsweise der ColShape-Editor oder auch, woran ich gerade bastele, verschiedene Editoren zur Objektmodifikation.
Plugins müssen grundsätzlich alleine, nur auf Basis des Grund-Editors lauffähig sein, können jedoch über entsprechende Interfaces miteinander kommunizieren. Außerdem gibt es globale Editor-Events, an die sich jedes Plugin anhängen kann, so beispielsweise AfterLevelEnter oder BeforeLevelLeave.

Was den Leveleditor-Part betrifft, an dem ich gerade arbeite: Der Objektbrowser ist noch nicht wirklich fertig, es fehlt noch an Übersicht / Gliederung und Funktionalität (Zentrieren auf, Umbenennen, Interaktion im IngameWindow). Anschließend wird ein Steuerelement für Objekteigenschaften hinzukommen, das auf das gerade gewählte Objekt reagiert und ein PropertyGrid zur Verfügung stellt.

Mal schauen, wie lange ich dazu brauche. Ein Leveleditor ist definitiv notwendig; während Spielregeln und Objekttypen problemlos per Hand in Inidateien geschrieben werden können, würde das im Leveldesign einfach zu sehr ausbremsen.

Fetze

BeitragDi, März 09, 2010 21:56
Antworten mit Zitat
Benutzer-Profile anzeigen
Immernoch dabei, am Editor herumzubasteln. Ich möchte zumindest den Level-Part des Editors zu einem gewissen Grad lauffähig kriegen, bevor ich mich weiter dem Game Core widme, denn so kann meine Ein-Mann-Leveldesign-Crew parallel mit ihrer Arbeit beginnen.

Dennoch mache ich mir Gedanken über den nächsten ToDo-Punkt des Game Cores, denn bis vor kurzme hatte ich noch keinen Schimmer, wie der zu realisieren sei: Einer flexiblen, asynchronen Scripting-Engine, die dynamisch angelegte, objektlokale Variablen ("Tagging") unterstützt und sowohl für Levelscripte als auch Objekt-Sonderverhalten verwendet werden kann.

Grundsätzlich habe ich in C# da zwei Möglichkeiten:
1. Den Traditionellen Ansatz, mir eine eigene Scriptsprache zu schreiben und schön Befehle als Klassen mit Ableitungshierarchie zu definieren, um alles flexibel und leicht erweiterbar zu machen. Sowas in der Art habe ich für die DeathSequences zusammengebastelt, aber die Anforderungen waren dort alles andere als hoch.
Oder 2.: Ich kann mit DotNet zur Laufzeit C# Code kompilieren und einbinden. Man könnte also direkt in C# scripten, was von den Möglichkeiten her schon das Nonplusultra ist.. aber den entscheidenden Nachteil hat, dass asynchrone Scripte nicht oder nur sehr begrenzt möglich sind. Jeder kennt die Scripting-Situation, zu Zeitpunkt A etwas zu tun, dem Script dann zu sagen, dass es 10 Sekunden warten soll und dann die nächste Aktion ausführen. Genau das wäre hier kaum Möglich, es sei denn, ich packe jeden dieser Aktionsblöcke in eine eigene Funktion, was ziemliches rumgefrickel und enorm umständlich wäre.

Aus diesem Grund wäre ich fast versucht gewesen entgegen aller Vorteile von #2 trotzdem #1 zu bevorzugen.. bis ich etwas herausfand, wozu ich ein wenig ausholen muss:

In C# gibt es die folgende Möglichkeit, um durch "Collections", also alles, das eine Sammlung von Dingen enthält, zu iterieren:
Code: [AUSKLAPPEN]

foreach (string s in myStringArray)
{
  ...
}

Nur so als Beispiel. In C++ nimmt man für sowas meist Iteratoren, zB. aus der STL, in BlitzMax.. weiß ich nicht mehr, obs da sowas gab. Eine solche COllection, das könnte zB. ein Array sein, [ generische ] Liste / Dictionary / Stack / ... oder aber auch ein eigener Collection-Typ. Prinzipiell kann man mit allem mittels foreach durchiterieren, was ein Objekt vom Typ IEnumerable<Datentyp> zurückliefert und entsprechend implementiert ist. So geht zB. auch folgendes:
Code: [AUSKLAPPEN]

foreach (string s in myStringList.Reverse)
{
  ...
}

während Reverse im Beispiel mal ein Property sei, womit man die Liste rückwärts durchiterieren kann. Ich denke, damit das System dahinter klar wird, sollte ich weiter darauf eingehen. Wenn ich nun selbst eine Möglichkeit zur Verfügung stellen will, durch irgendetwas durchzuiterieren, brauche ich also ein Stück Code, das ein IEnumerable<DatenTyp> zurückliefert. Das kann prinzipiell auch ein isoliertes Stück Code sein. Wenn ich beispielsweise durch alle Potenzen von x bis zum Exponent y iterieren will, könnte ich das wie folgt implementieren:
Code: [AUSKLAPPEN]

public static IEnumerable<int> Power(int number, int exponent)
{
   int counter = 0;
   int result = 1;
   while (counter++ < exponent)
   {
      result = result * number;
      yield return result;
   }
}

Code: [AUSKLAPPEN]

foreach (int i in Power(2, 8))
{
   Console.WriteLine(i);
}

Ausgabe:
Zitat:

2
4
8
16
32
64
128
256


Das eigentlich geniale hier ist das ominöse Schlüsselwort yield. Es ist der Schlüssel zum Iteratorensupport von C# und prinzipiell tut es nichts anderes als die Funktion an dieser Stelle zu unterbrechen, einen Rückgabewert zu liefern und die Möglichkeit offen zu halten, an genau dieser Stelle innerhalb der Funktion später weiterzumachen! In foreach wird über den Rückgabetyp IEnumerable<int> ein Objekt vom Typ IEnumerator<int> angefordert. Dieser speichert den aktuellen Wert, d.h. den letzten Rückgabewert und kann durch einen Funktionsaufruf "MoveNext" zum nächsten Wert iterieren. De factor wird dabei die Funktion aufgerufen bzw. fortgesetzt, die mittels des in-Statements im foreach angegeben wird, hier also "Power". Das ganze kann man auch manuell machen:

Code: [AUSKLAPPEN]

IEnumerator<int> it = Power(2, 8).GetEnumerator();
while (it.MoveNext())
{
   Console.WriteLine(it.Current);
}

Dieser Code hier ist identisch zu dem oben, aber mittels MoveNext() bestimmen wir jetzt selbst, wann wir den nächsten Rückgabewert haben wollen. So.. und jetzt wird es etwas "freaky". Wer bis hier hin nicht mitgekommen ist, kann sich den Rest des Beitrags vermutlich sparen, aber ich will niemanden Abschrecken - das Endergebnis ist, als Programmierer gesprochen, bildhübsch.

Also: Wie missbraucht man dieses konzept nun für seine Zwecke, wenn das Übergeordnete Ziel ist, asynchrone Scripte in echtem C# Code zu haben? Ich denke, diejenigen von euch, die mitgekommen sind, ahnen es bereits.

So könnte eine Scriptfunktion von uns also später aussehen:
Code: [AUSKLAPPEN]

public static IEnumerable<?> MyScript()
{
   Console.WriteLine("Script begin");
   yield return ?;
   Console.WriteLine("Script mid");
   yield return ?;
   Console.WriteLine("Script end");
}

Mit einem yield return markieren wir eine Position, an der das Script die Kontrolle zurück an das Hostprogramm, d.h. das Spiel zurückgibt. Der Clou an der Sache ist, dass wir so auch sehr lange und asynchrone Scripte problemlos mit einer Methode implementieren können, anstatt in unserem Script für jeden Aktionsblock eine eigene Methode zu schreiben und alle umständlich zu verketten.
Ein anderes Gegenbeispiel: Man stelle sich vor, wir hätten versucht, eine Scriptfunktion stattdessen zwecks Asynchronizität in einem eigenen Thread auszuführen.. ein Albtraum!
Hier sind wir hingegen in der Lage, auf einfache Art selbst zu bestimmen, welche Blöcke als Ganzes ausgeführt werden. Aber es geht noch weiter, schließlich haben wir die Möglichkeit, hier etwas zurückzuliefern.

Ich denke, Code sage hier mehr als tausend Worte. Man verzeihe mir die aus Gewohnheit englisch gehaltenen Kommentare:
Code: [AUSKLAPPEN]

public abstract class ScriptContinueCondition
{
   public abstract bool IsFulfulled();
}

Code: [AUSKLAPPEN]

public class Wait : ScriptContinueCondition
{
   protected   DateTime   beginTime;
   protected   TimeSpan   time;

   public Wait(TimeSpan time)
   {
      this.beginTime = DateTime.Now;
      this.time = time;
   }

   public override bool IsFulfulled()
   {
      if (DateTime.Now - this.beginTime >= time) return true;
      return false;
   }
}


Ausführung eines Scripts vom Spiel aus, Beispiel:
Code: [AUSKLAPPEN]

// This is our script iterator, normally would be saved locally somewhere
IEnumerator<ScriptContinueCondition> scriptPos = MyScript().GetEnumerator();

// This is our simulated game loop
while (true)
{
   // Check, if we can proceed
   if (scriptPos.Current == null || scriptPos.Current.IsFulfulled())
   {
      // Process a script block
      scriptPos.MoveNext();
   }

   // Print something to look busy.
   Console.WriteLine(".");
   // This simulates we're doing something else here
   System.Threading.Thread.Sleep(100);
}

Beispielscript:
Code: [AUSKLAPPEN]

public static IEnumerable<ScriptContinueCondition> MyScript()
{
   Console.WriteLine("Script begin");
   yield return new Wait(TimeSpan.FromMilliseconds(1000));
   Console.WriteLine("Script mid");
   yield return new Wait(TimeSpan.FromMilliseconds(1000));
   Console.WriteLine("Script end");
}


Ausgabe (in etwa):
Zitat:

Script begin
.
.
.
.
.
Script mid
.
.
.
.
.
Script end
.
.
.
.
[...]


Viel Code auf einmal. Zum Verständnis werde ich kurz umreißen, was er tut: Jeden Durchlauf des MainLoops wird ein Block des Scripts ausgeführt, sofern die mit dem letzten Rückgabewert definierte Bedingung erfüllt ist. Im Beispielscript wird der erste Block sofort bei Scriptbeginn ausgeführt, mit dem zweiten und dritten wird jeweils eine Sekunde gewartet. Durch die Abstraktion der "ScriptContinueCondition" wäre es auch denkbar, andere Bedingungen zu definieren, man könnte sogar vom Script aus eine anonyme Methode oder einen Delegaten / Funktionspointer übergeben, der bestimmt, wann die Bedingung erfüllt ist.
Obwohl man damit absolute Freiheit bei der Definition der Fortführungsbedingung erhält, sollten das natürlich trotzdem bloß Fortführungsbedingungen bleiben. Das Triggern bestimmter Scriptereignisse durch Events wird die primäre Umsetzung dieses Scriptingsstems ein. Beispiel: Ein GameObject vom Typ "Area", das in seinem Script zu entsprechenden Zeitpunkten Methoden aufruft wie "OnGameObjectEnter" oder "OnGameObjectLeave", etc.

Mal hoffen, ich hab jetzt mit diesem sehr C#-lastigen Exkurs niemanden vergrault. Ich für meinen Teil fühle mich ein wenig, als hätte ich damit den Heiligen Gral des C# Scripts in den Händen, vielleicht ist da einfach meine Begeisterung mit mir durchgegangen Wink

Jo0oker

BeitragDi, März 09, 2010 23:19
Antworten mit Zitat
Benutzer-Profile anzeigen
Nur mal so aus Interesse,
nutzt du für dein Layout WeifenLuo?

lg Jo0oker
Tehadon, das kostenlose 3D RPG
www.tehadon.de
http://www.blitzforum.de/worklogs/14/
Das Abenteuer wird beginnen!

Fetze

BeitragDi, März 09, 2010 23:45
Antworten mit Zitat
Benutzer-Profile anzeigen
Jep. Hab selten ein geileres GUI-Submodul gesehen - lediglich ein wenig unterdokumentiert Smile

peacemaker

BeitragMi, März 10, 2010 11:16
Antworten mit Zitat
Benutzer-Profile anzeigen
Interessanter Ansatz, ich würds genau gleich machen.

Die Vorteile die laufzeitkompilierter C#-Code bringt sind einfach viel zu gross um sie nicht zu nutzen. Enormer Speed, sehr mächtige OOP-Werkzeuge... das wäre ideal um Verhalten zu Skripten. Beispielsweise für Bots, einfach z.B. von Behaivour erben, verhalten implementieren, und schon läufts!


mfG
~Tehadon~
www.tehadon.de
http://www.blitzforum.de/worklogs/14/

Fetze

BeitragDo, März 11, 2010 23:13
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich kämpfe gerade in er Reflectionhölle um mein Leben, jedenfalls fühlt es sich so an. Ich glaube aber, den Kampf so langsam zu gewinnen.

Es begann alles damit, dass man im Editor mittels eines PropertyGrids, das von DotNet zur Verfügung gestellt wird, Objekte bearbeiten können sollte. Es klang alles sehr einfach: Objekt reinstecken und Reflection macht den Rest. Ha! Von wegen!

Das Ende vom Lied:
Arrow Jedes Objekt, das ich in ein PropertyGrid stecke, wird in einem PropertyBag-Objekt gekapselt, damit ich mehr Kontrolle über die Darstellung hab. Ein PropertyBag-Objekt kapselt eine Liste von PropertySpecs, die sich wiederum mit Reflection und Resourcendaten (zB. Sprachabhängige Beschreibungen und Kategorienamen) selbst erstellt.
Arrow Für verschiedenste Dinge schreibe ich gerade - fürs PropertyGrid - TypeConverter und UITypeEditoren, darunter welche für Vektoren (2D und 3D), für Winkel und Geschwindigkeiten (Spezielle doubles bzw. Vektoren), für Farben, für Referenzen auf andere Objekte und für Collections aus SteObjects
Arrow Damit der Editor bei all seiner Dynamik nicht auseinander bricht, gibt es jetzt eine zentrale Event-Pipeline für die Events "ObjectRenamed", "ObjectCreated", "BeforeObjectDeleted" (MitInterventionsmöglichkeit), "AfterObjectDeleted" und "ObjectPropertyEdited". Diese Events werden für ALLE SteObjects gefeuert. Ich kann also von jeder Stelle aus wenn ich will ein Event empfangen, wenn ein X-Beliebiges SteObject gerade umbenannt oder gelöscht wird / werden soll. Ebenso, wenn voneinem beliebigen SteObject ein beliebiges Property geändert wird. Das IngameWindow updated sich zB. wannimmer von einem beliebigen SteObject ein Property namens "Pos" oder "Angle" geändert wird. Der ObjectBrowser updated sich, wenn eines seiner Child-Objekte umbenannt wird, etc. etc.
Arrow Gleichzeitig habe ich im Rückrat des Ganzen, den SteObjects noch ein paar Sachen verbessert und verändert. So haben sie jetzt beispielsweise eine neue virtuelle Methode, um sie auf den Speichervorgang vorzubereiten. Das liegt daran, dass es sich leider herausgestellt hat, dass es nicht immer problemlos möglich ist, SteObject und SteObjectDesc komplett synchron zu halten. Das ist zB. der Fall, wenn ein SteObject ein Array von SteObjects enthält, das von außen zugreifbar ist - es gibt von innen keine akzeptable Möglichkeit, herauszufinden, ob ein einzelnes Array-Element bei einem Lesezugriff auf das Array ausgetauscht wurde. Das Array ReadOnly schalten ist aber auch nicht immer eine gute Idee, also ist das hier die beste Lösung. Immerhin: Die wenigen Fälle, in denen SteObject und Description asynchron werden können, werden dank der neuen Sonderbehandlung niemals auffallen.


Im Moment arbeite ich weiter an weiteren Convertern und Editoren fürs PropertyGrid. Man soll schließlich am Ende auch alle Properties eines Objekts bearbeiten können, wenn sie schon da sind. Danach werde ich eifrig Kategorieeinordnungen und Beschreibungen anhängen und dann, irgendwann, ist dieser Part des Editors endlich abgeschlossen. Nachdem ich die letzten Tage durchschnittlich 8 Stunden drangesessen hab, freue ich mich drauf.

ComNik

BeitragDo, März 11, 2010 23:20
Antworten mit Zitat
Benutzer-Profile anzeigen
Nur eine kurze Zwischenfrage: Da du ja sehr viel mit Reflection machst. Ist das nicht eigentlich langsam? Da ja alles per String Handle nunja gehandelt wird?

lg (wieder mal spannende Einträge etc.. Wink)
ComNik
WIP: Vorx.Engine

Fetze

BeitragFr, März 12, 2010 10:15
Antworten mit Zitat
Benutzer-Profile anzeigen
Reflection ist sicher nicht die schnellste Variante, etwas zu tun, aber bisher hatte ich nie ernsthaften Grund für Performance-Tests in dem Bereich - was hauptsächlich daran liegt, dass Reflection bei mir hauptsächlich zum Speichern, Laden und für Sonderaktionen im Editor zum Einsatz kommt. Ingame achte ich darauf, keine Reflection zu nutzen, da es hier wirklich auf die Performance ankommt.

Speicher, Laden und Sonderaktionen dürfen ruhig etwas länger dauern, da ich sie als einmalige, rechenintensive Prozesse verstehe. Wenn der Editor einen Level lädt, erwartet man als Nutzer von vornherein, dass es einen Moment dauern könnte (Auch wenn ich bisher noch gut unter der Sekunde bin Wink ) und die genannten Sonderaktionen sind einfach die Mühe wert: Dank Reflection ist es möglich, bevor man dem User gestattet, ein Objekt zu löschen, zu überprüfen, ob andere Objekte dieses noch referenzieren und ihn ggf. darüber in Kenntnis zu setzen. Wird ein Objekt umbenannt, wird automatisch dafür gesorgt, dass alle Objekte, die dieses noch referenzieren, automatisch einen aktualisierten Id-Wert erhalten. In größeren Projekten wäre es anders wohl gar nicht möglich, überhaupt ein Objekt umzubenennen. Very Happy

Wenn es um Dinge wie das PropertyGrid geht: Reflection wird hier zwar genutzt, jedoch bloß einmalig beim Aufbau der Tabelle und dann nochmal beim Setzen und erneutem Holen von Einzelwerten. Selbst wenn es doppelt so langsam wäre, das ist einfach nur ein Tropfen auf dem heißen Stein. Weitaus mehr Zeit kostet es da, ein Control wie das PropertyGrid neu zu zeichnen, wenn der Cursor drauf herum fährt Wink

Trotzdem; das Argument zählt für mich nicht, wenns um Dinge geht, die sehr schnell oder sehr oft ausgeführt werden müssen, beispielsweise die KI-Statemachine der Raumschiffe. Zwecks Flexibilität und Einfachheit suche ich die für einen State zu nutzenden Methoden per Reflection heraus. Dies geschieht jedoch einmalig bei Initialisierung des Spiels: Ich speichere die so erlangten MethodInfo-Objekte zwischen, um sie nicht erneut heraussuchen zu müssen. Wird ein Schiff erstellt, verwende ich diese, um daraus ein für dieses Schiff angepasstes (Aufruf objektlokaler Methoden) Delegate-Array zu erstellen; der Aufruf eines Delegates ist kaum langsamer als der einer Methode, wie ich sie normalerweise definiere Smile

Fetze

BeitragSa, März 13, 2010 13:52
Antworten mit Zitat
Benutzer-Profile anzeigen
Musste nochmal das gesamte System zur Erkennung von Objektreferenzen sowie das zum Umbenennen von string / Id - Referenzen auf umbenannte Objekte neu schreiben. Der Grund: Es funktionierte zwar, aber nicht in allen theoretisch möglichen Fällen - und ich bin erstens kein Fan von zusammengeschusterten Schnelllösungen und zweitens nicht auf unliebsame Überraschungen später in der Entwicklung aus.

Referenzen werden nun auch extrem verschachtelt erkannt, beispielsweise, wenn der Verweistyp nicht "Objekttyp" ist, sondern "Dictionary<Bla,List<Objecttyp>[]>" oder irgendwas ähnlich abgefahrenes. Auch wird der Verweis erkannt, wenn er sich innerhalb eines geschachtelten Objekts befindet - aber nur, wenn dieses geschachtelte Objekt selbst kein Verweis ist, sondern sich mitsamt seiner Description wiederum im Parentobjekt befindet. Beispiel:

Code: [AUSKLAPPEN]

class ObjectA : SteObject {...}; class ObjectADesc : SteObjectDesc {...}

class ObjectB : SteObject
{
  List<ObjectA> objRefList;  // Nur Referenz, da desc. Objekte sich nicht ebenfalls in ObjectBDesc befinden
  ObjectA[] nestedObjects;  // Echte, nested SteObjects, da auch ObjectADesc[] in ObjectBDesc enthalten.
}

class ObjectBDesc : SteObjectDesc
{
  List<string> objRefList;
  ObjectADesc[] nestedObjects;
}


Eine solche Verweisprüfung ist nötig, da sich in der Rekursion sonst Schleifen ergeben können und durch Verweisrekursion die Ergebnisse verfälscht werden. Ein Item, das einen Verweis auf ein zu erzeugendes Projektil hat, sollte dieses nicht ebenfalls nach Verweisen scannen - das ist Sache des Projektils. Auf der anderen Seite muss es aber seine eigenen ActionSteps durchsuchen, denn diese gehören, als nested SteObjects, direkt zum Item dazu. Ich hoffe, ihr seht den Unterschied.


Naja, jedenfalls war das alles ein Riesenstress, ich saß gestern wieder bis nachts um 2 dran und heute morgen auch schon drei Stunden. Aber jetzt bin ich damit endlich fertig und kann damit fortfahren, meine Objekte im PropertyGrid vernünftig editierbar zu machen.

Fetze

BeitragMo, März 15, 2010 23:03
Antworten mit Zitat
Benutzer-Profile anzeigen
Großes Update: Der Editor ist da! Genaugenommen die erste Version davon, mit der man halbwegs was anfangen kann.

StarTrade2:
http://www.fetzenet.de/st2_cur..._build.zip

Editor:
http://www.fetzenet.de/st2_cur...editor.zip

Installation:
Arrow Das Archiv so in den StarTrade2-Ordner entpacken, dass die .dll-Files überschrieben werden.
Arrow Im Editor-Package befindet sich kein Content, nur der Editor. Ist deswegen nicht alleine lauffähig.
Arrow Nach dem Entpacken wurde die Datei Options.ini (Hauptverzeichnis) überschrieben, in der die Lautstärkeregelung liegt. Wer Ingame wieder Sound haben will, muss sie entsprechend bearbeiten - im Editor ist die Musik deaktiviert.

Verwendung:
Arrow Level laden: "Datei-->Öffnen", Levelfile auswählen, zB. Testlevel.ini. Beim Öffnen einer anderen Ini-Datei passiert halt nix, weil die keine Leveldaten enthält.
Arrow Speichern von Leveln und der Blueprint-Library sollte beides voll funktionsfähig sein.
Arrow Im Ansicht-Menü kann man einzelne Komponenten ein- und ausblenden.
Arrow Kamerasteuerung: Mittlere Maustaste, Rechte Maustaste, Mausrad
Arrow Objektinteraktion: Auswählen und Linke Maustaste
Arrow Objekte löschen mit Entf / Backspace
Arrow Strg + D: Ausgewähltes Objekt duplizieren
Arrow Rechtsklick auf ausgewähltes Objekt: Kontextmenü
Arrow Mit dem ObjectCreator-Fenster ("Objekt Erstellen") kann man beliebige neue Objekte erstellen, einfach eine DragDrop-Aktion ins IngameWindow durchführen.


In der bisherigen Version sollte es mit dem Editor bereits möglich sein, auf Basis des Contents Level zu erstellen - in der Pre-Alpha-Testversion ist das Script, das Gegner erstellt allerdings noch hardcoded und wird ablaufen, wannimmer keine Feinde mehr herumschwirren. Den Content selbst kann man relativ einfach beareiten und erweitern, da er "wie immer" in .ini-Dateien im Content-Unterverzeichnis ausgelagert ist.

Wäre cool, ein wenig Feedback zu bekommen, je mehr desto besser Smile
  • Zuletzt bearbeitet von Fetze am Mi, März 17, 2010 0:56, insgesamt einmal bearbeitet

Thorsten

BeitragMo, März 15, 2010 23:40
Antworten mit Zitat
Benutzer-Profile anzeigen
Bei der St2Editor.exe tut sich bei mir gar nichts. Die .exe läuft zwar mit 50% CPU Aulastung aber es kommt weder ein Fenste rnoch eine Meldung oder so.

mfG,

Thorsten

Fetze

BeitragDi, März 16, 2010 1:05
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich hab mal Testweise den aktuellen Stable Build des Spiels geladen und dann den des Editors und wie in der Installationsanleitung beschrieben drüberkopiert: Bei mir gehts. Liegt also definitiv nicht am Package. Andere Erfahrungsberichte?

Gehe zu Seite Zurück  1, 2, 3 ... 12, 13, 14 ... 18, 19, 20  Weiter

Neue Antwort erstellen


Übersicht Sonstiges Smalltalk

Gehe zu:

Powered by phpBB © 2001 - 2006, phpBB Group