Hallo ihr lieben. Nach einiger Zeit habe ich fast alle Lizenzen erhalten (bis auf die offensichtlichen wir Kaufen, Verkaufen und Silage abladen etc...) und wo ich mich nun wieder auf Heimreise bin freue ich mich wieder auf das Game.

Daher einige Fragen die mir bisher unklar sind.

Bodenfestigkeit:
Es gibt ja die an der Oberfläche und die der Tiefe. Trotz Pflug hat sich nix geändert. Warum? Ich spiele Sandbox Modus da ich nicht noch mehr Missionen machen mag sondern endlich loslegen will. Felder sind frisch gekauft und gelten als gegrubbert in der Übersicht. Dennoch erschien mir die Festigkeit als zu hoch.

Nährwerte:
Wenn ich am Anfang alles Dünger auf optimale Werte für meine Fruchtsorte, reicht das dann für die gesamte Wachstumsphase? Was ist mit düngen später? Wir schaut das mit Unkraut und so aus? Muss man ggf bewässert?

Tierfutter:
Man kann ja Silage, Stroh, Gras und Heu verfüttern. Gibt es da einen Unterschied? Ausser derenge die man pro Feld bekommt. Aber wozu sollte ich Heu erstellen wenn es Gras auch macht. Macht es einen Unterschied ob das Vieh auf der Weide ist oder im Stall? Frisst es ggf. Gras auf der Weide selbst und muss nicht gefüttert werden? Wie schaut es mit Wasser aus?

Soweit erstmal meine ersten Anfängerfragen.

PS: kann man Silage auch mit dem Ladewagen aufnehmen und an das Vieh verfüttern und somit das nervige Beladen umgehen oder das gar an einen Helfer auslagern? Wird es Förderbänder geben?

Danke für die Antworten! Heißt im Umkehrschluss dass nicht ganz alles essenzielle fertig wurde. Aber großes Potenzial hat. Warum aber wurde das Game released? Man hätte doch die 2 Updates für farming und Tierhaltung abwarten können noch?

Ist zwar OT, aber da kann ich aus dem Nähkästchen plaudern, sofern es jemanden überhaupt interessiert, wie die Welt der IT tickt.

Vorab: ich arbeite in einer größeren Softwarefirma; unsere Aufträge (zwischen 50.000€ bis im 3 stelligen Millionenbereich über mehrere Jahre gehend) sind sicherlich überhaupt nicht mit einem PC Spiel vergleichbar, aber viele der Ansätze werden auch in der Spieleentwicklung verwendet (einige wenige EA Titel, Microsoft FlightSim, Rockstar Spiele, einige Epic Titel, Valve,...)



"Den Entwickler" gibt es nicht. Eine robuste Software benötigt Projektleiter (aka Scrummaster o.ä. je nach Vorgehen gibt es andere Begriffe für welche den Issuetracker und das Vorgehen festlegen sowie die Kundenanforderungen definieren), Buildmanager (welche am Ende den Source in Binärdateien übersetzen lassen; idealerweise mittels CI/CD Pipelines im Jenkins/Travis/Concourse/TeamCity/TFS,...), Programmierer (welche, wenn gut erzogen mit GIT in unterschiedlichen Branches arbeiten und jeder einzelne Featurebranch automatisiert gebaut wird, so dass direkt nach Vollendung der Arbeit geguckt wird, ob die Software noch baut), IT Architekten (welche den technischen Gesamtkomplex verstehen und managen) und vor allem viel Orga und Disziplin der Programmierer (nicht alles innen Master pushen, reviews etc,... ). Diese Rollen alle zusammen, kann man als Entwickler bezeichnen. Wobei in kleineren Projekten einzelne Personen mehrere Rollen einnehmen können, wobei dann zum einen die Person nicht im optimalen Leistungsbereich eingesetzt wird, und die Effizienz und Qualität des Produktes leidet.

Klassische Softwareentwicklung, wie sie heute nur noch in Einzelfällen praktiziert wird (aka wenn der Kunde drauf besteht und die Vorteile der agilen Methoden nicht verstanden hat oder aus Audit- und Compliancegründen nicht verwenden darf). Die obersten beiden Punkte entfallen bei Kundenprojekten:
- Idee wird in ein visuell vorzeigbares Format gebracht
- Investoren werden gesucht
- Anforderungen/ Ziele werden festgelegt
- Demo wird gebaut - der GO erfolgt
- erstes vorzeigbare Releases welche nicht featurecomplete sind: ALPHA
- sobald alle Features enthalten sind: BETA; von nun an wird nur noch gefixt
- sobald man meint, das Produkt ist fertig: RELEASECANDIDATE und die Software wird einem größeren Benutzerkreis zugänglich gemacht
- findet man keine Fehler mehr: RELEASE/FINAL

Diese Vorgehensweise hatte allerdings den massiven Nachteil, dass der Kunde während der Entwicklung nicht einbezogen wurde bzw. nur noch geringe Änderungsmöglichkeiten aufgrund des starren Konstruktes angewendet werden konnten. Weiterer Nachteil: es existierte ein Programmablaufplan. Die Kaffee-Sourcecodeconverter bauten üblicherweise unlesbare Methoden oder Spaghetticode mit denen nur sie etwas anfangen konnten. Andere brauchten eine massive Einarbeitungszeit, da man das komplette Gesamtkonstrukt verstehen musste, wenn man grundlegend etwas ändern wollte. Den Kunden stellte man dann zufrieden mit "von Grund auf neu programmiert!" und verkaufte den Nachteil oftmals als großen Vorteil.


Dies alles hat sich geändert hin zu einem agileren Modell. Da gibt es nun viele verschiedene Möglichkeiten. Bei uns in der Firma (tatsächlich Webentwicklung für Kunden meistens auf Grundlage des Web CMS Coremedia aber auch von adobe aber auch AI sowie AR/VR Entwicklung für größere Kunden; in fast jedem Fall auf Java basierend) wird auf Kanban oder Scrum gesetzt welche sich ähneln aber im Ablauf unterschiedlich sind.

Der Kunde wird von Anfang an einbezogen und erstellt seine Anforderungen aus Kundensicht. Der Anforderungsmanager erstellt aus diesen funktionalen Anforderungen dann systemische Anforderungen welche die Aufgabe technisch beschreiben. Dies kann ein Feature sein z.B. Tierhaltung.
- gemeinsam mit dem Architekten werden daraus nun Aufgabenpakete geschnürt, was da alles zu erledigen ist. Ein Aufgabenpaket sollte in einem fest definierten Zeitraum abgeschlossen sein. 1 Woche, 2 Wochen (meistens genutzt) in seltenen Fällen 4 Wochen wobei dann die Abstimmung im Team leidet während bei 1 Woche der Orga- und Abspracheoverhead höher ist
- je eine Aufgabe wird einem Entwickler zugeteilt als Verantwortlicher, welcher sich jedoch aus einem Topf weiterer (junior) Entwickler bedienen kann; oder man hilft sich gegenseitig
- der Entwickler erstellt an dieser Aufgabe Unteraufgaben mit ganz konkreten Arbeitsschritten
- im täglich stattfindenden Abstimmungsmeeting (5-15min) werden die Unteraufgaben verteilt und jeder weiß, wer was macht
- ist die Arbeit erledigt, wird die Arbeit ins GIT gepusht (oder anderes VCS, wobei GIT sich als Standard etabliert hat)
- der CI/CD Server den der Buildmanager aufgesetzt hat, baut daraus binaries und guckt auf linting, ggf. Schwachstellen in der Implementierung (ich sag nur: Zusammenfriemeln von Strings :-D) und CodingConvention
- ist der Build erfolgreich, wird diese Änderung in den Entwicklungszweig der Software automatisch überführt und ein weiterer Buildjob baut die Komplettsoftware erneut und rollt sie auf Testsystemen aus

Auf diese Art und Weise kann der Kunde jederzeit auf dem Testsystem gucken, was die Entwicklung macht, und beizeiten Änderungen einbringen. Auch werden die Anforderungen erweitert oder geändert. Der Kunde kann sich also sein Zielsystem nach Wunsch zusammenbauen.
Die größte Gefahr dieser Vorgehensweise ist Unerfahrenheit mit solch komplexen Prozessen. Daher gibt es immer Seniorentwickler welche die kleinen an die Hand nehmen über mehrere Jahre hinweg.
Der Vorteil ist: man baut kleinere Programmpakete welche über Schnittstellen miteinander verbunden sind. Den Überblick über diese Pakete und Schnittstellen hat der IT Architekt. Dieser entwickelt sie sogar zusammen mit den Seniorentwicklern. Damit bleibt das gesamte Paket wartbar, ein Entwickler muss nur ein kleines Paket verstehen und die Schnittstellen kennen. Im Zweifel wird ein Modul eben neu geschrieben mit eben diesen definierten Schnittstellen.

Damit das ganze auch organisatorisch seine Ordnung hat, gibt es (bei Scrum) alle 2 Wochen ein Abstimmungsmeeting, wo dem Kunden der Fortschritt gezeigt wird, und die weiteren 2 Wochen aufgeplant werden. Damit ist ein kontinuierlicher Fortschritt und eine Vorhersagbarkeit garantiert.

Zur Ausgangsfrage: ein Spiel ist dann fertig, wenn eines der Punkte gegeben ist:
- RELEASE/FINAL in der klassischen Entwicklung
- wenn der Publisher es verlangt (Werbezwecke, Verkaufspushes,...)
- wenn ein agiles Projekt vom Kunden auf Produktivsystemen verwendet werden kann


Und alle 3 Punkte haben eines gemeinsam: soll weiterentwickelt werden, muss Geld fließen. Daher hat sich im Spielbereich bei agilen Arbeitsweisen auch das Abomodell so etabliert. Kunden zahlen einen geringeren aber regelmäßigen Beitrag um die Entwicklung am Laufen zu halten. Wenn, wie im Falle CnC, ein Release erfolgt, werden vielleicht noch paar Inhaltsadditions hinzukommen (hat z.B. Egosoft mit der X-Serie auch so gemacht) letztlich aber müssen für weitere Entwicklung auch die Kosten wieder gedeckt werden. Das sind dann die berüchtigten DLC wenn man eben kein Abogame hat.

Wobei es auch paar Studios gibt, die ihre Kunden melken bis zum Umfallen mittels DLC UND Abomodell. Aber solange es dafür einen Markt gibt...