Jump to content

leomar

Pilot
  • Content Count

    48
  • Donations

    0.00 EUR 
  • Joined

  • Last visited

Community Reputation

29 Aufsteigende Sonne

1 Follower

About leomar

  • Rank
    Kosmischer Staub
  • Birthday 09/25/1980

Profile Information

  • Gender
    Male
  • Location
    Regensburg

Star Citizen

  • RSI Handle
    leomar
  • Golden Ticket
    No
  • Meine Schiffe
    135c
    Endeavor
    F7C-M Super Hornet
    F7C Hornet Wildfire
    Javelin
    Khartu Al [Xian]

Recent Profile Visitors

888 profile views
  1. Das kommt dann Ende 2019. Dann kann man Schulungsplätze für seine NPC`s pledgen. Bei der Roberts Space Academy.
  2. Ein Datum bei Scrum ist Schall und Rauch. Der unnötige Versuch soetwas wie Forcast in einen Prozess zu bekommen der eigentlich geschaffen wurde um solche Timelines zu verhindern weil sie nur Probleme machen. Es ist "in meinen Augen" Unsinn bei so einem Monster von Projekt festlegen zu wollen welches Feature ich vom 12.03.2018 bis zum 20.04.2018 entwickeln will. Weil das einfach keiner vorhersehen kann. Selbst wenn du den besten Softwarearchitekten mit dem Gott der Projektplanung von Scotty zusammen beamen lässt klappt das nicht. Zu viele Unabwägbarkeiten, Bugs, neue Ideen, neue Technologien usw. Keine Daten sondern Prioritäten sollten vergeben werden. So wie Scrum es vorsieht. Alle benotigten Userstories gescheit priorisieren dann kann man in etwa abschätzen in welcher Reihenfolge was entwickelt wird. Aber auch da nur ganz grob. Das letzte Wort hat das Entwicklungsteam. Wenn ich als PO eine Story Tankstutzen an Raumschiffen auf die höchste Prio setze wird mir das Team eins Husten und sagen wir müssen erstmal das System "Fuel" in das Spiel integrieren. Und selbst dann kommt es mit einer geschätzten Wahrscheinlichkeit von 99,761% noch dazu das die Features nachher nochmal wieder angefasst werden müssen. Diese Bilder zeigen ja auch nur grob wie sie die Stories in etwa geschnitten haben. Wenn da steht MISC Prospector fertig am 19 Mai 2017 dann ist das doch totaler Mumpitz. Das Ding ist bei weitem nnicht fertig. Es kann fliegen. Und evtl etwas ballern. Aber die Mining Mechanik fehlt, die abnehmbaren Behälter fehlen. Eigentlich die ganze Spielmechanik die dieses Schiff ausmacht. Ohne die hinter den Balken stehenden Informationen ist das alles Schall und Rauch über den man sich natürlich trefflich streiten kann. Ist ja fast die Stammtisch beim Fussball vor dem Videobeweis. Einfach nicht hinsehen, 2.6 oder ein anderes Spiel zocken und auf die Mail warten in der steht das 3.0 fertig ist. Moment mal ... was mach ich dann hier ? Kacke ! Ich liebe Stammtisch wie beim Fußball !! Ach Mist. Wollte ja noch was zum Topic schreiben Astro, deine Übersetzungen mit den tollen Erläuterungen und dein Hörzeitraum sind nach meiner Meinung das Beste was es im deutschsprachigen SC Umfeld gibt. Wenn das nicht leidet kannst mit Prisma weiter machen Bitte Editierfunktion nutzen, keine Doppelpsts, Gruß Chase Der Doppelpost war ein bewusst gewähltes Stilmittel
  3. Ich fände es gut wenn Verallgemeinerungen möglichst wenig genutzt werden. Ausdrücke wie "usere ach so tolle Community", "Nörgler", "rosarote Brille" sind doch nur Ausdrücke die Verwendet werden um sich selbst gegen VERMEINTLICHE Archetypen abzuheben. Solche Archetypen habe ich aber bisher selten gesehen. Sowohl Kritik wie auch Begeisterung sind vom Standpunkt (in meinem Fall leider auch mal der Gemütslage) des Schreibenden aus zu betrachten. Und das gestaltet sich im Falle Star Citizen schwerer als bei fertigen Spielen. Was daran liegt, dass der Stand der Entwicklung und die Kommunikation und Ideen von CIG viel Platz für eigene Interpretationen lassen. In meinem Fall z.B. Ich habe SC mit einer für mein Empfinden sehr hohen Summe unterstützt, weil ich zu dem Zeitpunkt ein bestimmtes Spiel "vor Augen" hatte. Und vor allem weil es modbare private Server geben sollte. Ein eigener Server auf dem man eine kleine Welt erschaffen oder aber auch gescriptete Missionen mit Freunden spilen kann. Mittlerweile aber ist das Thema PS gaaaanz nach hinten gewandert. Irgendwann weit nach release. Auch das Spiel welches ich mir damals ausgemalt habe ist in keiner Weise mit den heutigen SC zu vergleichen. Aber dafür kommen Themen rein, welche ich als sau cool empfinde. Das FoiP hab ich mir schon immer mal gewünscht. Und Themen die ich total kacke finde. Ein Buggy mit AA Waffen ? WTF ? Es fällt meiner eigenen Fanboy Seite schon schwer mit meiner Kritik Seite umzugehen und andersrum. Ich betrachte eigentlich hauptsächlich dieses Forum als Informationsquelle zu SC und bin der Meinung das die Kritik welche ich gelesen habe durchaus gerechtfertigt ist. Gleichzeitig finde ich auch das CIG bei der Implementierung einen verflixt guten Job macht und die Innovationen größtenteils Sinn ergeben. Und man darf natürlich auch nicht unbeachtet lassen was der Astro in seinen Videos über die GC mehrmals sagt: "GEBT MIR DAS DING. ICH WILL ES TESTEN!". Ich bin einfach ungeduldig. Und ich verallgemeinere jetz mal. Ich vermute viele Andere auch. In diesem Sinne. Vermeidet Fronten wo keine sind.
  4. Ja, von Unit Tests bin ich mal ausgegangen. Aber für komplexe UCs werden die sich was eigenes gebaut haben bzw. bauen müssen. Sie haben ja genug Engine Devs an Bord. Dinge wie die Crashes bei doppeltem Spawn eines Schiffes wären damit bestimmt gut zu automatisieren. Oder die Position nach dem Spawnen wie der Bug nach der Planetenrotation. Geht aber auch nur zu einem gewissen Grad. Z.B. der Fehler aus dem ATV mit den falschen Translationen der Radkappen lässt sich einfach schwer automatisieren. Wobei sowas super zum testen für die Evocatis bzw. einfach für die Spieler wäre. Das wäre jetzt für mich kein 3.0 Blocker. Der Begriff der "Developers tears" war auch richtig nice. Den kannte ich vorher auch noch nicht. Den führe ich auch ein.
  5. Ich war 4 Jahre Scrum Master. Da macht man das eine oder andere mit :D. Bin lieber wieder Dev. Das mit den Fehlern hatte ich auch so verstanden. Wobei das im aktuellen Stadium fast nicht zu werten ist. Da sind mit Sicherheit doppelte Einträge drin. Fehler die es schon lange nicht mehr gibt usw. Frage mich eh wie die da eine vernünftige Testautomatisierung hin bringen. Aktuell haben die bestimmt einen Marker "3.0 relevant" bei den Bugs eingebaut oder ein "Mustfix" mit der Versionsnummer 3.0. Muss für für alle Beteiligten bei CIG aktuell wirklich die Hölle sein. Da gibt es kaum Zeit zu nachtesten.
  6. Ich kann es versuchen. Auch wenn ich mich als Erklärbär eigentlich nicht so eigne. Und direkt vorweg die Bitte an alle SCRUM Jünger mich nicht zu lynchen. Ich vereinchfache das ganze an einigen Stellen um es verständlicher zu machen. Mit der Vermutung eines Bugtrackers liegst du schonmal nah an der Warheit. Das würde dem System aber nicht gerecht werden. Jira ist im Grunde genommen ein System zur Verwaltung von agilen Softwareprojekten. Das läuft hier unter den schon öfter gefallenen Stichwort SCRUM. Wobei CIG in dem Bereich scheinbar noch etwas anders arbeiten als ich es gelernt habe. Jira wird von der Firma Atlassian entwickelt https://de.atlassian.com/ die nebenbei auch noch ein Tool namens Confluence betreiben, welches sich ähnlich wie ein Wiki zur Dokumentation eignet. Häufig werden die beiden Systeme zusammen eingesetzt weil sie sich sehr gut ergänzen und ineinander integrieren lassen. Mit ihren anderen Tools habe ich noch nicht gearbeitet. Aber zurrück zu Jira. SCRUM bedeutet ja im Prinzip das zerbrechen eines Projektes in immer kleinere Teile und das Verteilen dieser Teile auf unterschiedliche Entwicklungsteams. Die Unterteilung verläuft in verschiedenen Abstufungen wobei die beiden untersten in der Regel die "User Story" als vorletzte und der "Task" als kleinste Einheit gelten. Alle diese Teile kann man in Jira erstellen und dann wie in einer Baumstruktur verschachteln, zuweisen und in verschiedene Status versetzen. Das ist etwas schwierig auszudrücken daher mal ein Beispiel: Ich habe das Projekt Star Citizen. Das kann man in Jira als Projekt. Also lege ich in Jira ein Projekt "Star Citizen" an. Dann lege ich die einzelnen User an und teile sie in Teams auf. Dann setzt sich Chris hin und sagt wir brauchen folgende Features : ......., Mobiglas, ........ Neben allen anderen Features wird dann also Mobiglas als Feature (auch Epic genannt) unter dem Projekt angelegt und in diesem Punkt wird genau definiert welches Ergebnis sich Chris davon verspricht. Nun setzen sich die Architekten, Developer, Designer und Chris hin und besprechen ganz grob welche abgeschlossenen Unterpunkte das Mobiglas definieren : ........, Sternenkarte, ........ Neben allen anderen Punkten wird dann Sternenkarte als Userstory unter das EPIC Mobiglas angelegt. Dort wird dann genau beschrieben was die Sternenkarte können muss. Das sind übrigens die tollen Balken welche man im schedule report sehen kann. Nun kommt irgendwann der Zeitpunkt an dem man festlegt das man sich in einem der folgenden Sprints mit der Sternenkarte beschäftigen will. Also gehen die Entwickler hin und zerteilen die Userstory nochmals in kleinere Tasks welche in der Regel nicht länger als einen Tag dauern sollten und möglichst gut parallel abzuarbeiten sind. (Das liest sich hier sehr toll ist aber in der Praxis sehr oft ....ähm... problematisch) Diese Tasks werden jetzt unter die Userstory eingefügt. Dann beginnt der Sprint und um eine Übersicht zu behalten wer grad an was arbeitet bietet Jira neben einer Darstellung der einzelnen Tasks in einem SCRUM Board. Mit welchem die Entwickler die Tasks zwischen verschiedenen Status verschieben können. Siehe Abbildung Wenn dann alle Tasks auf "done" sind, dann ist die User story "Sternenkarte" fertig (naja ... fertig ist so eine Sache). Wenn alle User Stories fertig sind ist das Epic "Mobiglas" fertig. Und wenn alle Epics .... okok ... warten wir es ab. Dazu können natürlich Kommentare dran gepackt werden, man kann die einzelnen "Commits / Checkins" den Paketen zuordnen usw. Außerdem kann das System nebenbei natürlich noch andere Arten von Aufgaben verwalten wie z.B. Bugs. Die Grafik welche wir gerade auf der schedule report Seite sehen ist direkt aus Jira erzeugt. Eigentlich musst du da ein Video draus machen. Das lässt sich mit Bildern aus Jira und einem Beispiel viel besser erklären und mir hat grad schon zwei mal der Browser den Text gefressen.... Ich hoffe es wird trotztdem einigermaßen klar.
  7. Servus Sam, vielen Dank für die tolle Arbeit. Finde deine Videos immer sehr informativ. Solltest du nochmal Hilfe beim Thema Versionsverwaltung (Branches) oder Jira brauchen kann ich gerne Input liefern.
  8. Wird aber normalerweise genutzt um "bewertete" Arbeitsaufgaben zu tracken. Im SCRUM werden ja die Tasks zu beginn jedes Sprints von den Entwicklern auf ihre Komplexität geschätzt. Damit bekommt man ein ganz grobes Gefühll wieviel Arbeit drin steckt pro Aufgabe. Und der Burndown Chart gibt dann pro Tag an wieviele Komplexitätspunkte noch zu offen bzw. in Arbeit sind im Sprint. Das für die Bugfixing Phase zu nutzen ist nur bedingt sinnvoll. Zwar sehen wir nun die Anzahl, aber die Severity (Blocker, critical) gibt keinen Hinweis darauf wie komplex das Problem ist. Ein Blocker kann mit einer Zeile Code behoben werden. Ein weniger schwerer Fehler aber den kompletten Umbau von z.B. Item System 2.0 bedeuten. Außerdem wird es wieder viel Geschrei geben wenn die Anzahl der Bugs in den nächsten zwei Wochen eher steigt als sinkt. Sobald die Evocatis am testen sind wir da einiges an Bugs auffallen.
  9. Ist ein Zusammenschnitt mehrerer ATVs
  10. Wenn man sich den Zeitplan ansieht bin ich eigentlich recht zufrieden mit dem Inhalt. Mittlerweile scheint ja die Zusammenarbeit unter den Standorten und das halten eines stabilen main branches ganz gut zu funktionieren. Nur so kann ich mir eigentlich die schnelle Folge von 2.6.1 bis 2.6.3 erklären. Daher bin ich eigentlich auch recht zuversichtlich das der Terminplan diesmal in etwa eingehalten werden kann. Wichtig wäre in dem Zusammenhang mal der Delta Patcher. Dann können sie noch deutlich mehr Iterationen raus geben. Und das war ja eigentlich die ursprüngliche Idee von Chris Roberts. Mehr Versionen in kurzer Zeit raus zu geben. Das nimmt auch viel Gefahr von der zeitgleichen Integration von Großen Features. Sie entwickeln jetzt parallel an jeder Menge Features die laut Schedule alle auf ihren Feature Branches noch nicht fertig sind. Allein schon den Kram der jetzt für 3.0 eingeplant ist in der Zeit auf einen Branch zu integrieren ist eine sehr ambitionierte Aufgabe. Um das alles sauber rein zu bekommen müssten meiner Meinung nach bis Mitte Mai 75% der Features "fertig" sein. Zeitpläne sind in diesem Projekt aus Sicht der Entwickler eigentlich ohnehin illusorisch. Dafür gibt es zu viele unfertige Features. Und wenn dir ein eingeplantes Feature au welchen Gründen auch immer weg bricht, nimmt es meist noch ein paar andere mit die darauf bauen. Daher sind die ATV`s auch immer so interessant. Da kann man mal sehen wo die Entwicklung sich momentan bewegt. Wenn wie angekündigt die Persistenz, das neue Item System und die neuen Locations kommen ist man schon mal ein deutliches Stück weiter.
  11. Aber genau dafür pledge ich ja. Das ist der Grund warum mir dieses Projekt mehr als die üblichen 60, mehr als ein paar Hundert Euro wert ist. Für den Glauben das CIG mit Hilfe der Community eben das bauen kann. Ich will eben nicht das nächste MMO wo in dem ich entweder einen rot umrandeten Haufen Goblins (Sorry Goblins. Ich mag euch. Ihr seid nur ein Beispiel) verkloppe oder mich von anderen Spielern vermöbeln lasse. Bitte nicht falsch auffassen. Es gibt nicht umsonst so viele Spieler da draußen welche sich daran erfreuen. Aber ich teile da die Vision von Chris Roberts. Da muss doch noch mehr gehen. Und ein gutes Beispiel ist doch Eve online. Das ist für mich ein großes Vorbild wenn es darum geht einem Spiel mehr als nur den direkten kompetitiven Ansatz in form von Gefechten zu geben. Gebe dir vollkommen Recht. Das ist entscheidend für den MMO Part. Und daher müssen diese Teile von Anfang an den gleichen Stellenwert bekommen wie das dogfighting oder die first person experience. Wobei der Part auf den ich mich ja am meisten freue eigentlich der PS Teil sein wird. Würde mir gerne einen eigenen Server so modden, daß ich mit ein paar Freunden meine eigenen gescripteten Abenteuer in einem abgeschlossenen Verse spielen kann.
  12. Je schneller die Schiffe fertig sind mit ihren verschiedenen Spezialisierungen, Funktionen und Bestandteilen desto genauer ist das Bild der Entwickler über die Funktionalitäten. Sowohl im Umfang, Anwendungen, Beziehungen etc. Daher finde ich es gut mehr Schiffe zu entwickeln wenn sie neue Aspekte des Spiels abdecken. Mehr Funktionen bedeutet zwar mehr Entwicklungszeit. Aber besser als wenn man auf Basis der jetzigen Schiffe Funktionen entwickelt und dann feststellen muss. Ach kacke. Ja das der mit dem Mining. Da gabs ja nie ein Konzept. So soll das also. Können wir schon machen. Müssen wir aber 50% refactoring betreiben. Und man kann früher Gedanken ins balancing stecken. Bin aber schon dabei. Der 5te gleichartige Dogfighter macht keinen Sinn Gesendet von meinem GT-I9195 mit Tapatalk
  13. Auf der Seite gibt es keine Informationen über Spectrum oder hab ich die übersehen ? Hat da schon jemand etwas gehöt ? Sollte ja im November noch in die Testphase gehen.
  14. Ein Modul mit Sitz- bzw. Schlafplätzen. Dann könnte man aus der CAT einen Personentransporter machen. Als Konkurrenz zur Starliner. Gesendet von meinem GT-I9195 mit Tapatalk
  15. Nochmal zum andocken. zurrück Hab grad nochmal das Video aus dem Anniversary sale angeschaut. Ist das dort eurer Meinung nach ein Schleusentor zum andocken ?
×
×
  • Create New...