Die fleißigen Foren-Leser werden es sicherlich schon wissen, für alle anderen möchte ich hier noch einmal auf den Stand von GIANTS-Software an der Gamescom 2010 hinweisen. Hier wird es eine spielbare Preview-Version der neuen Version des Landwirtschafts-Simulators geben.

Den Stand findet ihr hier:

Halle 8.1, Stand A-042

Auch wir von SFM-Modding werden dort vertreten sein und alle 2 Stunden einige Tipps und Tricks in Form eines Live-Moddings vorstellen. Auch für Fragen und Anregungen stehen wir euch während der gesamten Gamescom zur Verfügung.

Da Stefan (steyr1) leider nicht anwesend sein kann, wird uns Sven (Sven777b) unterstützen. Er wird euch alles rund ums Scripten und Konvertieren (Ingame bringen, XML, I3D) näherbringen, während ich (Face) euch Tipps und Tricks im Umgang mit Maya (UV-Mapping, Exportieren, Polygon-Modeling) und Photoshop (Texturepainting, Normalmapping) zeigen werde. Chris (MadMax) wird sich mit einigen anderen, in der LS-Szene bekannten Persönlichkeiten, um eure Fragen rund um den Landwirtschafts-Simulator und um die Betreuung der Spiele-Rechner kümmern.

Wir wünschen euch heute schon viel Spaß auf der Messe. Vielleicht sieht man sich ja!

Multihreading

Um die einzelnen Teile zu einem flüssigen Spielablauf zusammen zu bauen, benötigt man eine Technik um mehrere Programmteile nahe zu gleichzeitig ablaufen zu lassen. Hier kommt die Technologie des Multithreading zum Einsatz. Sie ermöglicht es z.B. das Rendering und die Soundausgabe gleichzeitig ablaufen zu lassen und somit ein flüssiges Gameplay zu realisieren.

Entgegen einem weit verbreitetem Gerücht muss hier kurz erwähnt werden, dass auch die GIANTS-Engine auf diese Technologie zurückgreift. Folgende Threads werden hier benutzt:

1x Sound
1x Spiellogik + Rendering (OpenGL mit wieder eigenen Threads)
2-nx Physik-Berechnungen

Der Ursprung dieses Gerüchts liegt am Windows-Betriebssystem, dass Programme und deren Threads managed und ein Programm erst auf mehrere Kerne verteilt, sofern eine bestimmte Anzahl an Threads benutzt wird.

Der Gameloop

Der Gameloop ist ein weiterer wichtiger Bestandteil eines Spiels, denn er sorgt für den reibungslosen, an den jeweiligen Rechner angepassten (FPS) Spielablauf. Der folgende Dummy-Code zeigt kurz den üblichen Ablauf in einer vereinfachten Form:

1. Solange das Spiel nicht geschlossen wird:
   1. Checke Input (Tastatur, Maus, Joystick, etz.)
   2. Berechne Physik
   3. Berechne Spiellogik
   4. Gebe Sound aus
   5. Male Spiel (Rendering)
2. Starte wieder bei 1.

Im Zuge des Multithreadings werden die einzelnen Schritte (1.1-1.5) nahezu parallel ausgeführt.

Wie bereits erwähnt, sorgt dieser Gameloop für den reibungslosen Ablauf des Spiels. Die Kennzahl die diesen Ablauf wiederspiegelt wird im 3D-Bereich als Frames-Per-Second(FPS) bezeichnet. Sie definiert also die Anzahl der gerenderten Bilder pro Sekunde und ist damit ein Indiz für das Empfinden des Spielablaufs. Das diese Kennzahl von einigen Faktoren abhängt, weiß jeder, der schon einmal verschiedene  3D-Spiele gespielt hat. Einige dieser Faktoren der Beeinflussung sind hier aufgelistet:

• Polygonanzahl und andere Einflüsse (Einstellungen, Tetxuren, etz)
• Qualität der Programmierung (Engine oder Scripte)
• Anderweitige Tätigkeiten am PC
• Potential des Rechners

Im späteren Verlauf des Workshops werden wir noch sehen wie man diese FPS-Kennzahl in die Berechnung der Scripte mit einbeziehen kann, um so, trotz geringer FPS-Zahl einen reibungslosen Spielablauf zu garantieren. Zuvor sollten aber noch einige wichtige Prinzipien genannt werden, um eben die FPS-Zahl nicht unnötig zu verschlechtern:

1. Performance-orientiertes Modding ist wichtig
   1. Saubere Scripte
      1. Abfangen unnötiger Berechnungen
      2. Weglassen unnötiger Schleifen-Durchläufe
   2. Sauberes Polygonmodelling
      1. Weglassen unnötiger Polygone
      2. Weglassen unnötiger Details
      3. Darstellung von Details durch Texture-, Normal-, Specular-Maps
      4. Richtige Einstellung der I3D-Files
2. Auswirkungen des Moddings beachten
   1. Modding ist Eingriff in die Standard-Spielroutinen
   2. Veränderung an diesen -> erneutes Testen erforderlich

Grundlagen des Modelling

Zum Ende noch ein paar Definitionen der wichtigsten Begriffe:

• Bestandteile eines Modells:
  • Vertex (Eckpunkt eines Modells)
  • Polygon (Fläche zwischen 3-Vertices)
  • Face (Fläche aus mehreren Polygonen)
  • Mesh (Ansammlung von zusammengehörenden Faces/Polygonen)
  • TG (Transformgroup zur Definition eines neuen Spaces)
  • Modell (Ansammlung von Meshes und Transformgroups)
• Sichtbarkeit:
  • Per Defintion sind Faces/Polygone nur von einer Seite sichtbar!
  • Sichtbarkeit wird über sogenannte Normals gesteuert
• Normals:
  • Benötigt zur Berechnung des Lichteinfalls und der Reflexionen
• Weitere Grundbegriffe:
  • Shading (Definition der Oberfläche eines 3D-Objektes)
  • Textur (Muster/Struktur die auf ein 3D-Objekt aufgebracht wird)
  • Mapping (Prozess des Auflegens einer Textur auf ein 3D-Objekt)
  • Lightning (Prozess des Positionierens von Lichtquellen)
  • Rendering (Erzeugen einer 2D-Ansicht eines 3D-Modells)
• Lichtarten:
  • Pointlight (hat Ursprung und strahlt rundum Licht ab)
  • Directionallight (strahlt auf der ganzen Breite aus einer definierten Richtung)
  • Spotlight (wie Pointlight, nur Begrenzung auf Abstrahlkegel)
• Orientierung und Ausrichtung
  • Jedes Objekt (TG/Mesh) hat einen Nullpunkt (Pivot)
  • Alle Aktionen werden von diesem aus berechnet
    • Translation (Verschiebung)
    • Rotation (Drehung)
    • Scale (Skalierung)
• Local- vs. Worldspace
  • Worldspace (Koordinaten ABSOLUT zum Spiel-Nullpunkt)
  • Localspace (Koordinaten RELATIV zum Vater-Nullpunkt)

Viel Spaß beim Lesen

Nur Auszüge?

Ja und Nein. Einerseits werde ich nicht alles 1:1 übernehmen können, da viele Kapitel einfach zu viel Theorie enthalten, um hier in einem Artikel zusammen gefasst zu werden. Um dies zu bewerkstelligen, werde ich die einzelnen Artikel nochmals aufteilen. Andererseits gibt mir diese Splittung auch die Möglichkeit, die einzelnen Kapitel mit mehr Inhalt zu füllen, denn die Ursprünglichen Folien sind eben sehr spärlich gefüllt, denn es sind ja nur Folien.

Wichtig ist jedoch, dass ich persönlich wohl eher keine Fragen per Email-Anfragen beantworten werde. Deshalb wäre ich froh, wenn diese Fragen hier als Kommentare gepostet werden!

Also starten wir mit Kapitel 1: Grundlagen des Game-Development

Die Game-Engine

Um sich einen Überblick zu verschaffen, was genau eine Game-Engine ist bzw. beinhaltet, reicht ein Blick auf Wikipedia. Hier erfährt man folgendes:

“Eine Spiel-Engine (engl. Game Engine) ist ein Computerprogramm, das den Spielverlauf steuert und für die visuelle Darstellung des Spieleablaufs verantwortlich ist.”

Da es sich bei einer solchen Game-Engine aus einem Gerüst verschiedenster Teile handelt, ist es notwendig sich einen genauen Überblick über die einzelnen Bestandteile zu verschaffen, um später genau zu wissen, wie die einzelnen Funktionen einer Engine zusammenspielen. Die wichtigsten Bestandteile sind die folgenden:

Grafikengine (Darstellung des Spiels, das sogenannte Rendern)

Physiksystem (Berechnung der physikalischen Gegebenheiten im Spiel)

Soundsystem (Mischen und Wiedergeben der verschiedenen Sound-Files/-Streams)

Steuerung (Abfangen und Reagieren auf Nutzer-Eingaben, z.B. Tastatur, Maus, etz,)

Datenmanagement (Management aller Daten, z.B. Positionsdaten von Fahrzeugen)

Netzwerkanbindung (Optional)

Skript-Unterstützung (Optional)

Hieraus ist nun auch der Unterschied zwischen einer 3D-Engine und einer Game-Engine ersichtlich. Denn eine 3D-Engine ist nur ein Teilbereich bzw. eine Untermenge einer Game-Engine.

Warum Skript-Unterstützung?

Kommen wir nun zum wohl, aus Sicht dieses Workshops, wichtigsten Part der Game-Engine und der Frage, warum eine Skript-Unterstützung bei einer Game-Engine Sinn macht.

Um diese Frage zu klären ist eine Auflistung von Vor- und Nachteilen sinnvoll:

Vorteile:

+ Script-Sprache leichter erlernbar (für Artists und Designer)

+ Schnelles Prototyping

+ Keine Neucompilierung des Engine-Codes

+ Erleichterte Modding-Möglichkeiten

Nachteile:

- Script-Sprache ist langsamer als Nativer-Code (C++)

- Einbindung einer Script-Unterstützung mit Aufwand verbunden (Geld, Zeit, Wartung)

Wenn man sich diesen Vergleich nun ein bisschen genauer ansieht und auch die einzelnen Vor- und Nachteile gewichtet, wird man merken, dass die Vorteile doch sehr überwiegen. Das zeigt sich auch in der Entwicklung der letzten Jahre. Immer mehr Engine-Hersteller bieten diese Script-Unterstützung an. Die bekanntesten Sprachen sind wohl UnrealScript, C-Script und LUA. Letztere wird in vielen bekannten Spielen, wie z.B. WorldOfWarcraft, Crysis, Siedler und auch im Landwirtschafts-Simulator benutzt.

So das war nun der erste Teil des Workshops. Weitere Folgen. Viel Spaß beim lesen.

AXIS_1
AXIS_2
AXIS_3
AXIS_4
AXIS_5
AXIS_6
AXIS_W
AXIS_X
AXIS_Y
AXIS_Z
BUTTON_1
BUTTON_10
BUTTON_11
BUTTON_12
BUTTON_13
BUTTON_14
BUTTON_15
BUTTON_16
BUTTON_2
BUTTON_3
BUTTON_4
BUTTON_5
BUTTON_6
BUTTON_7
BUTTON_8
BUTTON_9
KEY_0
KEY_1
KEY_2
KEY_3
KEY_4
KEY_5
KEY_6
KEY_7
KEY_8
KEY_9
KEY_KP_0
KEY_KP_1
KEY_KP_2
KEY_KP_3
KEY_KP_4
KEY_KP_5
KEY_KP_6
KEY_KP_7
KEY_KP_8
KEY_KP_9
KEY_KP_divide
KEY_KP_enter
KEY_KP_equals
KEY_KP_minus
KEY_KP_multiply
KEY_KP_period
KEY_KP_plus
KEY_a
KEY_b
KEY_c
KEY_d
KEY_e
KEY_f
KEY_g
KEY_h
KEY_i
KEY_j
KEY_k
KEY_l
KEY_m
KEY_n
KEY_o
KEY_p
KEY_q
KEY_r
KEY_s
KEY_t
KEY_u
KEY_v
KEY_w
KEY_x
KEY_y
KEY_z
KEY_f1
KEY_f10
KEY_f11
KEY_f12
KEY_f13
KEY_f14
KEY_f15
KEY_f2
KEY_f3
KEY_f4
KEY_f5
KEY_f6
KEY_f7
KEY_f8
KEY_f9
KEY_ampersand
KEY_asterisk
KEY_at
KEY_backquote
KEY_backslash
KEY_caret
KEY_clear
KEY_colon
KEY_comma
KEY_delete
KEY_dollar
KEY_down
KEY_end
KEY_equals
KEY_esc
KEY_exclaim
KEY_greater
KEY_hash
KEY_home
KEY_insert
KEY_lalt
KEY_lctrl
KEY_left
KEY_leftbracket
KEY_leftparen
KEY_less
KEY_lshift
KEY_minus
KEY_pagedown
KEY_pageup
KEY_pause
KEY_period
KEY_plus
KEY_question
KEY_quote
KEY_quotedbl
KEY_ralt
KEY_rctrl
KEY_return
KEY_right
KEY_rightbracket
KEY_rightparen
KEY_rshift
KEY_semicolon
KEY_shift
KEY_slash
KEY_space
KEY_tab
KEY_underscore
KEY_up
MOD_ALT
MOD_CAPS
MOD_CTRL
MOD_LALT
MOD_LCTRL
MOD_LMETA
MOD_LSHIFT
MOD_META
MOD_MODE
MOD_NUM
MOD_RALT
MOD_RCTRL
MOD_RMETA
MOD_RSHIFT
MOD_SHIFT
MOUSE_BUTTON_LEFT
MOUSE_BUTTON_MIDDLE
MOUSE_BUTTON_NONE
MOUSE_BUTTON_RIGHT
MOUSE_BUTTON_WHEEL_DOWN
MOUSE_BUTTON_WHEEL_UP

Wichtig zu wissen ist, dass es trotz des Vorhanden seins einiger Tasten zu Problemen kommen kann.

iGoogle – Support
Absofort kann der RSS-Feed auch direkt in iGoogle angezeigt werden. Hierzu habe ich diese kleine Grafik oben rechts in der Title-Leiste eingebaut. Per Klick wird der Feed direkt in eure iGoogle-Oberfläche geladen.

Bis demnächst

Thema heute: Bug-Tracking oder auch Fehler-Verfolgung

Nicht nur im wahren Leben sind Käfer oft eine kleine Plage. Auch in der Software- bzw. Mod-Entwicklung ist das Vorhanden sein dieser kleinen Mitbewohner wohl DAS K.O-Kriterium, dass sogar den besten Mod unspielbar und unbeliebt macht.

Um dieser Plage Herr zu werden, bedarf es entweder guter Planung oder der zu Hilfenahme eines sogenannten Tracking-Tools. Im folgenden Beispiel möchte ich nun kurz unser eingesetztes Bug-Tracking-System vorstellen.

Hierbei handelt es sich um das OpenSource-Tool FlySpray in der Version 0.9.9.6.

Wie man auf diesem Screenshot gut erkennen kann, gibt es die Möglichkeit verschiedenste Projekte (Mods) anzulegen. Jedem dieser Mods können nun von verschiedenen Nutzern (Modder & Tester) neue Aufgaben (Tickets) zugeordnet werden. Die Übersicht zeigt gut welche Aufgaben noch zu erledigen sind und wie weit der Fortschritt bei der Bearbeitung ist. Die einzelnen Farben definieren die Dringlichkeit der Aufgabe.

Das Roadmap-Feature gibt den Mod-Beteiligten eine gute Übersicht über den Gesamt-Status des aktuell gewählten Projekts, um so abschätzen zu können, wie viel Zeit noch eingeplant werden muss.

Die Aufgabe

Eine Aufgabe umfasst eine kurze Beschreibung, die den Bug, das gewünschte Feature oder den Hinweis spezifiziert. Nun können dieser Aufgabe noch Personen zugewiesen werden, die sich mit dieser befassen sollen. Weitere Kriterien wie Priorität, System, Version und Schweregrad können ebenso angegeben wie verschiedene Tester- und Entwickler- Kommentare, um den Bug-Report oder Feature-Request besser nachvollziehen zu können.

Vorteile, aber auch Nachteile

Ein Vorteil dieses Systems ist sicherlich die Nachvollziehbarkeit eines jeden Problems, sei es ein Bug, ein Hinweis oder ein komplexer Feature-Request, denn dieses System gibt einen sehr guten Überblick über alle Aufgaben die während der Mod-Entwicklung aufgekommen sind. Ein weitere Vorteil ist, dass eben keine Bugs vergessen werden. Denn einmal ins System eingetragen, bleiben sie auch so lange dort, bis sie von einem Modder behoben wurden.

Dieser Vorteil zeigt auch schon einen Nachteil, welcher aber eigentlich kein Nachteil ist. Die einzelnen Aufgaben müssen per Hand eingetragen werden. Es gibt zwar einige Drop-Down-Boxen die einige Vorauswahlen bereitstellen, jedoch muss der eigentliche Beschreibungs-Text noch von Hand eingetragen werden.

Wenn man nun aber bedenkt, dass man diesen Text sowieso dem Modder per ICQ oder Email gesendet hätte, ist dieser Nachteil auch schon wieder neutralisiert und es zeigt sich, dass dieses System nur Vorteile mit sich bringt.

Ein nettest Feature ist die Email-Benachrichtigung, ähnlich wie bei der Versions-Kontrolle. Sobald etwas neues eingetragen wurde, bekommt der zuständige Nutzer eine kurze Benachrichtigung über die Änderung per Email.

Voraussetzungen

Um dieses System zum laufen zu bringen, benötigt man im Falle von FlySpray einen Webserver mit PHP und MySQL-Datenbank.

Fazit

Jeder der es satt hat, dass immer wieder Bugs vergessen werden, sollte sich dieses oder andere BugTracking-Systeme unbedingt einmal genauer anschauen. Für den Modder der nur ein paar Texturanpassungen macht oder Landschafts-Objekte moddet ist dieses System wohl eher nichts, denn der Verwaltungsaufwand übersteigt hier wohl eher den gewonnenen Nutzen.

In diesem Sinne, bis demnächst!

]]> http://blog.sfm-modding.de/2010/07/06/tools-der-mod-entwicklung-die-zweite/feed/ 3 http://blog.sfm-modding.de/2010/06/29/das-zauberwort-versionskontrolle/ http://blog.sfm-modding.de/2010/06/29/das-zauberwort-versionskontrolle/#comments Tue, 29 Jun 2010 14:45:04 +0000 Manuel Leithner http://blog.sfm-modding.de/?p=41 “Versionskontrolle? Was ist das denn wieder?” werden sich nun sicherlich einige von euch fragen. Ganz einfach:

Zauberei!

Nein. Das Ganze hat natürlich rein gar nichts mit Zauberei zu tun, sondern ist ein Prozess, um verschiedene Entwicklungszustände von Software für die Zukunft zu speichern.

Bei einem weiteren Blick auf Wikipedia erfährt man nun:

“Eine Versionsverwaltung ist ein System, das zur Erfassung von Änderungen an Dokumenten oder Dateien verwendet wird. Alle Versionen werden in einem Archiv mit Zeitstempel und Benutzerkennung gesichert und können später wieder hergestellt werden. Versionsverwaltungssysteme werden typischerweise in der Softwareentwicklung eingesetzt um Quelltexte zu verwalten.”

Das Ganze kann man natürlich auch bei der Entwicklung von Mods für den Landwirtschafts-Simulator benutzen. Und genau deshalb habe ich mich heute hingesetzt und so ein System aufgesetzt. Hat leider einige Zeit in Anspruch genommen, aber der entstandene Nutzen enorm.

Denn wer kennt es nicht. In deinem Team gibt es mehrere Leute, die den Mod testen. Nach einigen Minuten kommen schon die ersten Beschwerden über einen Bug. Schnell wie du bist, fixed du den Bug und willst eine neue Bug-freie Version zu Verfügung stellen. Jedoch musst du nun an jeden deiner Tester eine Zip verschicken. Nach 1-2 Wochen hast du ein regelrechtes Zip-Wirwar im Team denn keiner weiß, ob er denn noch die neuste Version besitzt.

Hier schafft SVN (Subversion – Versionsverwaltung) Abhilfe. Man verteilt einfach an alle Tester die Zugangsdaten zum SVN-Repository (Globale Speicherstelle des Mods) und sobald sich am Mod etwas ändert, erhalten alle eingetragenen Nutzer eine Email mit der Aufforderung die neue Version zu laden. Somit können sie nun das SVN-Verzeichnis neu “auschecken” (bezeichnet den Vorgang, die aktuelle Version zu laden) und besitzen nun immer die aktuellste Version.

Einige denken sich nun sicherlich: “Mmmmmh das Ganze kann ich aber auch auf meinen Webserver legen”

Richtig, aber SVN bringt weitere Vorteile mit sich. Wie der Name schon sagt, handelt es sich um ein Tool zur Versionsverwaltung bzw. -kontrolle. D.h. sobald man etwas an einer Datei ändert und diese “eincheckt” (bezeichnet den Vorgang des Online-Stellens einer geänderten Datei) wird die Vorgängerversion dieser Datei archiviert und ist somit auch zu einem späteren Zeitpunkt problemlos rekonstruierbar, um bei Bedarf nachzusehen, was man eben bei dieser Version genau geändert hat.

Ein weitere Vorteil ist, dass mehrere Leute gleichzeitig an einem Mod arbeiten können. Also Beispiel nenne ich hier mal mich als Scripter und MadMax als Tuning-Spezialist. Da er relativ oft Dinge in der XML ändert, in der ich natürlich auch herumfuhrwerke, kommt es oft zu Überschneidungen und wir müssen uns dann immer zusammen hinsetzen und die beiden XML-Dateien vergleichen. Auch hier schafft SVN Abhilfe. Denn es vollzieht diesen “Merge”-Vorgang (zusammenführen von 2 verschiedenen Dateien zu einer neuen) voll automatisch. Nur in seltenen Fällen muss man als Nutzer noch definieren, was gemacht werden soll.

Falls ich mit diesem kleinen Einblick in die Software-Entwicklung nun auch eure Interesse wecken konnte, findet ihr hier einige Links:

• http://www.xp-dev.com/ (Ein kostenloses SVN-Repository)
• http://tortoisesvn.tigris.org/ (Der SVN-Client zum Connecten auf das Repository)

Grüße Manuel aka Face

In den nächsten Wochen werde ich die einzelnen Foliensätze für das Web aufbereiten und dann nach und nach in kleinen Artikeln online stellen. Ich werde Anfangs zu Testzwecken die Diskussionsplattform offen lassen, sodass auch über diese Artikel diskutiert werden kann, sofern Fragen aufkommen.

Ich hoffe, dass sich dadurch noch mehr neue Modder finden lassen, die die Community noch weiter voranbringen.

Hier werdet ihr in Zukunft kleine Artikel rund um den Landwirtschafts-Simulator und Demolition-Company finden. Diese Artikel werden sowohl Tipps&Tricks und Tutorials als auch generelle Diskussionsthemen rund um euer Lieblingsspiel beinhalten.

Ein solcher Blog macht natürlich nur Sinn, wenn ihr User euch an diesen kleinen Diskussionen beteiligt. Deshalb würde es uns freuen, wenn ihr euch rege daran beteiligen würdet.

Mit freundlichen Grüßen,
SFM-Modding