spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

wenn man so will könnte man sogar jedes kleine testprogramm als tool bezeichnen. und seis um zu sehen, ob ne datei richtig konvertiert wurde oder sowas...

ich mein der begriff tool impliziert ja schon, dass es sich nicht zwingend um was umfangreiches handeln muss.

schließlich ist sowohl ein hammer, als auch ne herti als werkzeug zu bezeichnen

KaiRo ist wirklich VERFLUCHT gut!
Der hat u.a. deren Versionenkontrolle geschrieben.

Allgemein zu Tool Programierung:

Einen gut nutzbaren 3D Editor von 0 an zu schreiben, der einem mehr bringt als einen vorhandenen zu nehmen kostet ca 3 Mannjahre Arbeit. Natürlich kann er schon vorher benutzt werden, aber nach 3 (Mann)Jahren hat er V1.0, also das geplante und wirklich sinnvolle ist drin. Ein reines "Placementtool" geht natürlich schneller.

Wenn nicht anders gesagt, rede ich über Grafik-tool-programmierung.

Man muß die ganze Pipeline beachten und "in Schuß halten" und nicht nur ein einzelnes Tool. Integration von Fremdtools ist wichtig. Auch Bibliothecken benutzen macht Sinn.

Im Gegensatz zur Spieleengine ist Performance fast immer unwichtig.

Nach meinem Geschmack (!) sind Vor- und Nachteile dieses Jobs:
+ Man arbeitet mit den Grafikern zusammen.
+ Man arbeitet an 3D Zeugs und sieht den Erfolg seiner Arbeit.

- Man muss viel GUIs schreiben
- In der Hierarchie normalerweise recht weit unten angeordnet. Andererseits kann man es als Einstieg nutzen.
- Man macht nix was 100 000 Leute nutzen.

Wie häufig ist die Hauptarbeit die Details. Ein Beispiel:
Wir hatten (und haben) viele Modelle bei denen 3D Punkte die für die Engine wichtig sind, per Objekten mit 1 Eckpunkt und 0 Polys markiert sind, z.B. die Rorhmündung einer Waffe wo Kugeln rauskommen. Nach einer Umstellung in der Pipeline wurden diese Objekte von einem Tool als unwichtig weggelassen.

Es ist ein RIESEN Unterschied ob man Tools für den internen Gebrauch schreibt oder z.B. auch für Modder. Einige Gründe sind:
- Doku
- Im wesentlichen wird ein Spiel einmal veröffentlicht (während es bei Applikationen immer neue versionen gibt). Wenn es also z.B. im Flug Simulator 8 fliegbare Maschinen gibt und die modeller etwas manuell machen müssen was pro Maschine 10 Stunden kostet und es mich 100 oder 200 Stunden kosten würde, das einmal per Programm zu lösen, so wird sich das nicht lohnen. Wenn man "modder" anlocken will und vielleicht hofft dass die 100erte Flugzeuge importieren, so sollte man es eben doch programmieren.
- Wenn ein Modeller in der Firma an ein Problem stösst, kann er zum Programmierer gehen. Ein Modder kann das nicht so gut. Daher muss man versuchen, von Anfang an alle Möglichkeiten zu sehen und abzudecken. Z.B. habe ich gerade heute erst einen CFS (Combat Flight Sim) Modder gelesen, der eine Schiffswaffe als Flugzeugheckstand deklariert hat, weils halt nichts anderes gab und hat dann entsprechende Probleme mit der AI bekommen :-D . Wenn man interne Tools schreibt, insbesondere bei der normalen Zeitknappheit, werden solche Probleme ignoriert bis man sich sicher ist, dass sie wirklich auftreten werden, d.h. dass man AI für Schiffskanonen braucht.
- In der Firma werden externe Tools genutzt, z.B. braucht man bei BoB zum Erstellen von "Quick missions" den C++ compiler, zum bequemen Suchen von fehlern in Landschaften ein exotisches Maleprogramm Names "Animate" oder so etc. Bevor man also die Tool Chain veröffentlichen kann, muss man es schaffen, dass es ohne teure Programme funktioniert.
Es gibt sogar fälle wo bei internen Tools eine bestimmte Hardware vorausgestzt wird.
- Auch Grafiker in Spielefirmen haben ein besseres Verständniss für technische Dinge und natürlich für Spieleentwicklung als Laien. Dazu kommt dass Sie 40+ Stunden pro Woche dran sitzen. Daher darf das ganze wesentlich komplexer sein als es sein darf, wenn der durchschnittliche Hobby Grafiker es bedienen können soll.

- Es empfiehlt sich auf fertige Programme zurück zu greifen wie bsw. FX Composer von nVidia.
- Man muss unterscheiden zwischen Programmen die das GUI mit WinAPI haben oder DirectX (Ja sry ka wie ich das sagen soll )

Zitat

- Man macht nix was 100 000 Leute nutzen.

Sry. DAS sehe ich nicht unbedingt so. Wenn es ein Spiel ist, wo der Spieler auch noch Lust hat seine eigenen Levels u.d.g. zu entwerfen. s. bsw. CounterStrike, wird das tool auch öffters benutzt werden, bzw auch von mehr Leuten
Wobei "tool" aus dem englischen ja so viel wie "Werkzeug" bedeutet, was wiederum sehr gut zutrifft, da es ja wirklich nur ein WERKZEUG zum fertigen Spiel ist

Zitat

BoB

Meinst du "Battle of Britain"?!


PS: @Osram: es tut mir leid das ich mich nicht mehr auf dein Angebot gemeldet hab, aber leider lautet meine Antwort nein Sry

Bis dahin wirst du aber noch viel üben müssen

Naja ne einfach GUI zu schreiben ist (finde ich) nicht soooo schwer, für jemanden der etwas Übung hat und schon was im 2D Bereich gemacht hat.

Sicher hat Osram in etlichen Punkten Recht, aber ich finde mit den 3 Jahren ists etwas zu übertrieben. Ich hab zwar wirklich keine Erfahrung in dem Bereich, aber von der Konzeptphase eines Spieles bis zum Release vergehen ja schon ca. 3 Jahre. Da belibt kein Platz für einen so ausgereiften Editor

Ich habe mal einen Votrag von KaiRo gehört, der mich total umgehauen hat. Es ging auch tatsächlich um ein Tool, nämlich die besagte Versionenkontrolle. Es gibt wahrscheinlich weltweit 100 oder mehr Leute, die Vollzeit (semi) professionell Versionenkontrollen entwickeln (PVCS und Nachfolger, VSS, Alienbrain, Perforce etc, aber auch CVS, SVN etc) und sicher meistens über mehrere Jahre. Und dann kommt da einer, der gar kein offizieller Coder ist, der es neben seinem eigentlichen Job her macht, er macht es in gewisser Hinsicht ganz anders als andere und bringt es zum Einsatz und es ist sinnvoll und arbeitet auch bei 100 000 Dateien noch gut mit. Hätten die da auch nur leicht schlechtere Stühle gehabt, ich wäre wahrscheinlich während des Vortrages zusammen mit meinem Stuhl umgefallen :-D

Zitat von »"koschka"«

Sicher hat Osram in etlichen Punkten Recht, aber ich finde mit den 3 Jahren ists etwas zu übertrieben.

Ich habe für meinen Modeller 3 Jahre veranschlagt und die auch gebraucht und warte das Programm immer noch. Wie gesagt, der Modeller konnte natürlich vorher schon benutzt werden. Aber Du kannst für ein paar tausend Euro einen Modeller kaufen in dem wahrscheinlich hundert(e) von Mannjahren drin sind. Selbst wenn Du Features weglässt die für Deine Engine uninteressant sind und vor allem Sachen machst, die in Deinem Einsatzgebiet besonders wichtig sind, so dauert es doch bis Du etwas hast, was Deinen Modellern einen Vorteil gegenüber einem etabliertem Programm bietet.

Einer der besten Coder die ich kenne hat es in einem Jahr geschafft - mit 3 Leuten . Ich war selber überrascht dass seine Erfahrung sich so genau mit meiner gedeckt hat.

Übrigens ist für mich Mannjahr "Ein Mann bei 40 Wochenstunden, normalem urlaub etc in einem Jahr". Wenn Du also z.B. 80 Stunden arbeitest kannst Du es vielleicht auch in einem guten Kalenderjahr schaffen.
3D Studio Max wurde (am Anfang) von 2 Leuten gemacht, von denen vorher einer einen Modeller (+Animationssystem) für den Amiga geschrieben hatte, d.h. also sicher einer der erfahrendsten Leute auf dem Gebiet. Sie haben in den ersten 2 Jahren 6 Tage a 18 Stunden gearbeitet plus einen a - ich glaube - 14.

Zitat

Ich hab zwar wirklich keine Erfahrung in dem Bereich, aber von der Konzeptphase eines Spieles bis zum Release vergehen ja schon ca. 3 Jahre. Da bleibt kein Platz für einen so ausgereiften Editor

Erstens gibt es einen Grund warum fast alle Spielefirmen den 3D Modeller von einer bekannten Firma nehmen (Kinetix, Maxxon etc) und nicht selber einen schreiben.
Zweitens werden Tools normalerweise für mehrere Spiele einer Firma eingesetzt. Wenn es also beim ersten damit erstellten Spiel sich noch nicht lohnt und die Grafiker mangels guten Features länger brauchen, so kann es trotzdem Sinn machen, weil man darauf aufbauend beim 2. bis n. Spiel dann ein gutes, maßgeschneidertes Tool hat.