Jump to content
Unity Insider Forum

Blogs

Featured Entries

  • Mark

    UltraTerrain Dev Diary #2

    By Mark

    Nachdem die Tests nun immer umfangreicher werden wächst auch die Funktionsvielfalt.

    Im letzten Post habe ich den PageDataHandler erwähnt, dieser ist nun fast vollständig implementiert, dazu musste aber einiges gemacht werden.

    Der PageDataHandler soll wie der Name bereits andeutet in der Lage sein die Daten einer Page zu handhaben/verwalten, darunter fällt wie bereits erwähnt das Laden der Daten.

    Das Laden der Daten basiert auf 2 Schritten:

    1. Wenn noch keine komprimierten (zip) Daten im Objekt vorhanden sind dann wird das dem System zugehörige VirtuelleFileSystem nach den passenden Page Daten gefragt. Das VirtuelleFilesystem ist das VFS aus SaveIt und kann in einer Datei verschiedene Unterdateien speichern und lesen, das ganze ohne jedesmal die gesamte Datei in den Speicher zu laden. Die Daten wurden vorher komprimiert in das VFS abgelegt.

    2. Sind die komprimierten Daten vorhanden werden diese dekomprimiert und in die Datenarrays gelegt die ein PageDataHandler hat. Das sind aktuell nur 2 Arrays, einmal die VoxelValues welche angeben wir einflussreich ein Voxel ist (0.0 bedeutet kein VoxelEinfluss und 1.0 bedeutet vollen Einfluss) und die BlendValues, welche angeben wie die verschiedenen Texturen später miteinander verschmelen werden.

    Der 2. Schritt ist gesondert vom ersten aus folgendem Grund: Der PageDataHandler soll wenn eine Page längere Zeit unverändert bleibt die Daten zwischenspeichern können um Speicherplatz zu sparen um später wenn die Page noch viel länger unangetastet blieb diese Daten in das VFS zu speichern. Dies soll später dafür sorgen dass nur die Voxeldaten in Speicher verbleiben die unbedingt nötig sind um entweder schnelle änderungen zu ermöglichen oder wieder schnell parat zu sein um änderungen vorzunehmen.

    Intern arbeiten die Load und LowerMemorConsumption Methoden mit Asynchronen Operationen die jeder Zeit abgebrochen werden können um zB wärend eine Page grade die Daten komprimiert diese Operation abzubrechen da ich die Daten spontan doch unkomprimiert benötige.

    Das System für diese Asynchronen Operationen basiert auf den Unity Threading Helper.

    Bestimmte Aktionen können allerdings nicht abgebrochen werden und sind damit auch synchron und nicht asynchron, zB das löschen aller Daten bei dem es keinen Zwischenschritt gibt der noch abgebrochen werden könnte.

    Das System zu laden und Speichern der VoxelDaten bedarf aber noch einen weiteren Zwischenschritt um Versionsupdates auf neuere UltraTerrain Versionen zu ermöglichen, aus diesem Grund wird in den Page Daten später noch die Version des Dateiformates (unabhängig vom VFS Format) abgespeichert werden und basierend auf dieser Version werden dann die geeignetesten Speichermethoden gewählt.
    • 0 comments
    • 505 views
 

UV-Mapping Tutorial Teil 1/2

Herzlich Willkommen zu meinem Blog Eintrag über UV-Mapping. In diesem Tutorial werde ich euch zeigen, wir ihr den Affen-Kopf (Sue) in Blender texturiert. Zur Info: Ich verwende die Blender Version [b]2.61.[/b]


Für dieses Tutorial brauchen wir 2 Programme:[list]
[*]Gimp 2.*
[*]Blender
[/list]
[b]In Blender:[/b]

Ich habe als erstes den Affen Kopf eingefügt und den Standard Cube gelöscht. Danach habe ich in die UV-Editing Ansicht gewechselt.

[attachment=515:UV_editing_view.png]

Danach wechseln wir mit[b] [TAB][/b] in den [b]Edit-Mode[/b]. Wenn wir uns jetzt das Modell ansehen, können wir sehen das es aus vielen einzelnen Edges besteht. Das komplizierte am UV-Editing ist nicht das Editieren in Blender selbst, sondern die Vorstellung zu besitzen wie ich das Modell zerschneiden muss.

[i]Ich vergleiche UV-Editing gerne mit einer Cornflakes Schachtel. Um nämlich eine solche Schachtel zu falten, muss man zuerst den Karton zerscheiden. Dies Erinnert dann an das Netz eines Würfels aus dem Geometrie Unterricht.[/i]

Nun, unsere Aufgabe ist es, aus diesem Affenkopf ein solches Netz zu erkennen, und deswegen sollte man ein Grafisches Vorstellungsvermögen besitzen.

Bei Sue ist es noch leicht zu verstehen wie ich dieses Modell zerlegen sollte.

Als erstes wählen wir alle Edges aus die wir Abtrennen wollen. Am besten wählt ihr dazu das Edge-Auswahlwerkzeug aus. Wenn alles Edges ausgewählt sind benutzen wir [b][STRG+E][/b] und klicken danach auf Mark-Seam

[attachment=516:mark_seam.png]

Wenn das alles erledigt ist, bedarf es nur noch eines kleinen Schrittes. [b][A][/b] alles auswählen und danach [b][U] [/b]und Unwarp klicken. Wie ihr jetzt sehen könnt wurde unser UV Erstellt und es ist bereit zum Exportieren (man kann es zwar noch bearbeiten, ist aber in diesem Fall nicht nötig). Exportieren könnt ihr es ganz einfach, indem ihr auf [b]UV's[/b] geht und danach [b]Export UV Layout.[/b]

[attachment=517:export_uv.png]

Im 2 Teil erkläre ich euch, wie ihr mit Gimp die Textur erstellt und wie ihr dies dann anwendet.

[b][i]Schreibt bitte in die Kommentare, was ich nächstes mal machen sollte.[/i][/b]



[b][font=comic sans ms,cursive]Zootec alias Zendee[/font][/b]

Zootec

Zootec

 

Android/iOS Input

Hallo Leute,
ich hab mal ein Tutorial geschrieben.
Der Anlass war,das die Basic Versionen von Unity iOS/Android kurzzeitig umsonst sind.
Wenn diese Aktion vorbei ist und jemand dieses Tutorial liest...ich hab noch zehn Lizenzen^^
Ich hoffe euch gefällt es.
//Die Scripts wurden nicht getestet,sollten aber funktionieren.
//Falls nicht,sagt es mir bitte.

Beschleuningungssensor/Accelerometer

Wir fangen mit etwas ganz einfachem an.
Und zwar lesen wir die Daten vom Accelerometer aus :
[code]
//AcceleromterControls.js
//©2012 Yannic St.

#pragma strict

var speed : float = 20;

private var thisTransform : Transform;

private var direction : Vector3;

function Start()
{
thisTransform = this.gameObject.transform;/*Wenn wir das Transform von dem Objekt in einer Variable speichern,
muss Unity nicht in jedem Frame danach suchen.*/
}

function Update()
{
direction.x = -Input.acceleration.y*speed;//'direction.x' soll die y-Rotation(-,weil es gedreht ist) vom Gerät mal 'speed' sein.
direction.z = Input.acceleration.x*speed;//'direction.z' soll die x-Rotation vom Ger�t mal 'speed' sein.

direction *= Time.deltaTime;//Wir machen unsere Logik unabh�ngig von der Framerate.

thisTransform.Translate(direction);/*Das Objekt mit Transform.Translate(); bewegen,
als Paramter der dreiteilige Vektor 'direction'.*/
}
[/code]

Jetzt kommen wir zu einem Thema,welches nicht ganz so einfach ist,nämlich Touch-Input.
Aber nach einer kurzen Einführung habt ihr bestimmt Lust selbst zu experimentieren.

[code]
//TouchControls.js
//�2012 Yannic St.

#pragma strict

var speed : float = 10;

private var thisTransform : Transform;

private var direction : Vector3;

function Start()
{
thisTransform = this.gameObject.transform;/*Wenn wir das Transform von dem Objekt in einer Variable speichern,
muss Unity nicht in jedem Frame danach suchen.*/
}

function Update()
{
if(Input.touches.length>0&&Input.touches[0].phase == TouchPhase.Moved)//Wenn der erste Touch stattgefunden hat und der Finger bewegt wurde...
{
var touchDeltaPosition : Vector2 = Input.touches[0].deltaPosition;/*Die 'deltaPosition' von einem Touch ist die Differenz zwischen
dem Punkt wo er begonnen hat und wo er aufh�rt.*/

direction.z = touchDeltaPosition.y*speed;//'direction.z' soll die y-Position vom Touch-Delta mal 'speed' sein.
direction.x = touchDeltaPosition.x*speed;//'direction.x' soll die x-Position vom Touch-Delta mal 'speed' sein.

direction *= Time.deltaTime;//Wir machen unsere Logik unabh�ngig von der Framerate.

thisTransform.Translate(direction);/*Das Objekt mit Transform.Translate(); bewegen,
als Paramter der dreiteilige Vektor 'direction'.*/
}
}
[/code]

Virtuelle Joysticks sieht man oft in mobilen Spielen.
Unity gibt uns in den Standard Assets(Mobile) eine Klasse mit,
die ein solches System erleichtert.
In folgendem seht ihr wie man das schnell zusammenbastelt und
dann eine eigene Steuerung programmiert,die darauf aufsetzt.

[code]
//JoystickControls.js
//�2012 Yannic St.

#pragma strict

var forwardSpeed : float = 20;
var backwardSpeed : float = 15;
var sideSpeed : float = 10;

var joystick : Joystick;

private var thisTransform : Transform;

private var direction : Vector3;

function Start()
{
thisTransform = this.gameObject.transform;/*Wenn wir das Transform von dem Objekt in einer Variable speichern,
muss Unity nicht in jedem Frame danach suchen.*/
}

function Update()
{
if(joystick.position.y>0)//Wenn die y-Position vom Joystick gr��er als 0 ist...
{
direction.z = joystick.position.y*forwardSpeed;//'direction.z' soll die y-Position vom Joystick mal 'forwardSpeed' sein.
}
else//Wenn die y-Position vom Joystick nicht gr��er als 0 ist...
{
direction.z = joystick.position.y*backwardSpeed;//'direction.z' soll die y-Position vom Joystick mal 'backwardSpeed' sein.
}

direction.x = joystick.position.x*sideSpeed;//'direction.x' soll die x-Position vom Joystick mal 'sideSpeed' sein.

direction *= Time.deltaTime;//Wir machen unsere Logik unabh�ngig von der Framerate.

thisTransform.Translate(direction);/*Das Objekt mit Transform.Translate(); bewegen,
als Paramter der dreiteilige Vektor 'direction'.*/
}
[/code]

Wenn ihr irgendwelche Fragen habt(auch allgemein zu Android/iOS),
dann beantworte ich sie gerne

Graphiler

Graphiler

 

Tutorial Reihe: Raumschiff Modellieren Teil 1

Das ist mein erster Blog Eintrag und ich hoffe ihr habt Verständnis Ich werde euch in ca. 5 Tutorials zeigen, wir ihr in Blender ein Raumschiff modelliert und danach schön texturiert. Das Raumschiff wird ein Low-Poly Modell. In diesem Tutorial werdet ihr alles lernen, was man können muss um Blender zu bedienen. Nun wünsche ich viel Spaß

[b]LM -> Linke Maustaste[/b]
[b]RM -> Rechte Maustaste[/b]
[b]MM -> Mittlere Maustaste[/b]
[b]Buchstaben -> Buchstaben eben;)[/b]
----------------------------------------------------------------------

Wenn ihr euch Blender runtergeladen habt, müsst ihr es noch Installieren und danach starten. Damit keine Differenzen zwischen mir und euch sind verwendet bitte die Blender Version 2.6.1. Eigentlich gehen alle Blender Versionen ab 2.5. Ich werde hier, in diesem Tutorial nicht auf die Bedienung eingehen, da ich hoffe das ihr dies bereits könnt. Los gehts

[b]1.[/b] Alls erstes löschen wir den Standard Cube:[b] LM -> X -> Delete[/b]

[b]2[/b]. Wir fügen eine Plane hinzu, gehen in den Edit Mode und löschen 3 Edges.[b] (X -> Edges)[/b]

[b]3[/b]. Als nächstes richtigen wir das einzelne Edge parallel zu [b]Y-[/b]Achse aus. Danach fügen wir einen Mirror-Modifier hinzu. Aktiviert das Häckchen Clipping.

[attachment=503:modifier.png]

Der Zwischenstand


[b]4[/b]. Nun können wir die Grundform Modellieren. Geht in die Links Ansicht und drückt[b] [5][/b] am Nummern-Pad. Jetzt könnt ihr Anfangen Einzelne Punkte zu verschieben und mit [b][E][/b] zu erweitern. Die letzten beiden Punkte verbindet ihr mit [b][F][/b] (Die letzten beiden Auswählen).

[b]5[/b]. Jetzt müssen wir dem ganzen Modell noch ein wenig Tiefe geben. Wählt dazu alle Vertices und drückt [b][E][/b].

Ab hier kann ich euch nicht mehr weiter helfen, ihr müsst einfach ein wenig experimentieren.


[attachment=504:finish_2.PNG]
So sieht meins aus.

[attachment=505:finish_subvide.PNG]
Und so, wenn ihr einen SubdivisonSurface-Modifier hinzugeügt habt.

Ich hoffe euch hat das Tutorial gefallen. Wenn ihr wünsche habt, schreibt es in den Kommentaren, und wenn ihr Rechtschreibfehler findet, behaltet sie einfach

Blender File: [url="http://valerian-tschopp.com/uploads/tutorial.blend"]http://valerian-tsch.../tutorial.blend[/url]

Zendee

Zendee

 

Modellieren für Spieleengines

Dieser Blogeintrag ist an alle gerichtet, die 3D-Modelle für Spiele entwerfen.

Man findet ja überall im Internet Modelle, die primär für die Verwendung in Spielen gemacht wurden. Auch wenn hier und da an die spezifischen Anforderungen von Modellen für Spiele gedacht wurde, so schauen Blender-, 3DS-, Cinema- oder SoftImage-Nutzer * doch oftmals nicht über das Modelling-Programm hinaus und übersehen einige Dinge, die das Designen von Spielszenen mit ihren Modellen erheblich vereinfachen würden. Denn Spieleengines rendern nicht wie Modellingprogramme, und ein Leveldesigner arbeitet meist anders als ein Modeller.

Darum würde ich hiermit gerne eine zusammenfassende Liste mit Dingen, deren Beachtung eine deutliche Verbesserung der Qualität von Modellen für Spiele bewirken kann, anführen.[list=1]
[*][size=5][u]Einheitliche Größen in Serien[/u][/size]
Da Modellingprogramme alle unterschiedliche Größeneinheiten suggerieren, es bei 3D-Engines nicht anders ist und sogar von Spiel zu Spiel die Einheiten gerne mal neu interpretiert werden **, kann man von Modellern, die nicht an einem bestimmten Projekt arbeiten, nicht erwarten, dass die Modelle alle in der richtigen Größe beim Leveldesigner ankommen.
Was allerdings schön wäre, wäre eine einheitliche Skalierung.
Beim Importieren kann man dann allen Modellen den selben Skalierungsfaktor geben.
Muss man aber für 30 Gebäude bei jedem auf's Neue per Augenmaß einen Skalierungsfaktor finden, wird's nervig.
Die Lösung: Alle Modelle einer Serie, also einer Menge zusammen gehörender Modelle benutzen die selben Größeneinheiten.
[*][size=5][u]Objektmittelpunkt bei 0,0,0[/u][/size]
Die Grund für diesen Punkt ist verteilt auf die Vorlieben verschiedener Engines.
In einigen Fällen fährt man komplett problemlos, wenn man die Objekte beliebig im Raum verteilt. Spätestens bei der Benutzung von Bones in der Unreal Engine sollte man aber das Skelett auf 0,0,0 platzieren. Das ist aber nicht der einzige Fall, in dem das sinnvoll bzw. sogar nötig sein kann.
Zusammenfassend gesagt: Ein 3D-Modell ist nur dann mit allen Engines kompatibel, wenn die Objekte auf 0,0,0 platziert sind.
Darauf zu achten schränkt aber keinesfalls ein: Man kann ja anstatt des Objekts dessen Punkte verschieben.
In z.B. Blender heisst das: Edit Mode statt Object Mode.
[b][u][color=#ff0000]Falsch:[/color][/u][/b]
[img]http://bytezero.de/files/uin/objektverschiebung.jpg[/img]
[b][u][color=#009900]Richtig:[/color][/u][/b]
[img]http://bytezero.de/files/uin/meshverschiebung.jpg[/img]
Ausnahme sind allerdings Objekte, die anderen untergeordnet sind, siehe Punkt 5.
[*][size=5][u]Skalierung auf 1,1,1[/u][/size]
In diesem Fall sind sich die Engines schon eher einig: Objekte sollten nicht skaliert werden, also die Standardskalierung von 1,1,1 behalten.
Spätestens bei Modellen mit Bones wird das in allen Engines sehr wichtig.
Das ganze lässt sich genau so umsetzen wie bei der Objektverschiebung.
[b][u][color=#ff0000]Falsch:[/color][/u][/b]
[img]http://bytezero.de/files/uin/objektskalierung.jpg[/img]
[b][u][color=#009900]Richtig:[/color][/u][/b]
[img]http://bytezero.de/files/uin/meshskalierung.jpg[/img]
[*][size=5][u]Kontaktpunkt auf den Objektmittelpunkt setzen[/u][/size]
Damit versüßt man jedem Leveldesigner den Tag.
So gut wie jedes Objekt hat einen Kontaktpunkt *** (/-Kante /-Fläche).
Dieser Punkt definiert sich dadurch, genau an der Position zu sein, wo das Objekt an andere Objekte angrenzt.
Ein Mensch oder ein Tisch z.B. stehen auf dem Boden, und zwar mit der Unterseite der Füße. Der Kontaktpunkt liegt also unter den Füßen.
Eine Wandlampe dagegen hängt an der Wand, also ist der Kontakpunt an der Seite, mit der die Lampe die Wand berühren soll.
Positioniert man den Mesh so, dass dieser Kontaktpunkt auf dem Objektmittelpunkt liegt, so bringt das einige Vorteile für den Leveldesigner.
Will dieser z.B. das Objekt skalieren, so wird das Objekt ja vom Objektmittelpunkt hin bzw. weg skaliert.
Der Objektmittelpunktliegt dabei, wie der Name schon sagt, in der Mitte und wird nicht bewegt.
Liegt der Kontakpunkt woanders, dann skaliert man in die Wand hinein oder davon weg:
[img]http://bytezero.de/files/uin/inwand.jpg[/img]
Liegt der Kontaktpunkt aber genau an dieser Stelle, dann ist dieser nach dem Skalieren immernoch an der Wand (/auf dem Boden /...) und das Objekt muss nicht noch einmal neu positioniert werden.
Auch beim Drehen des Objekts ergeben sich daraus Vorteile.
Also merken:
[b][u][color=#ff0000]Falsch:[/color][/u][/b]
[img]http://bytezero.de/files/uin/objekt010.jpg[/img]
[b][u][color=#009900]Richtig:[/color][/u][/b]
[img]http://bytezero.de/files/uin/objekt000.jpg[/img]
[*][size=5][u]Objekte unterodnen[/u][/size]
In keinem Modellingprogramm, das ich kenne, fehlt die Möglichkeit, Objekte einander unterzuordnen.
Objekte eines 3D-Modells, das aus mehreren zueinander beweglichen Teilen besteht, werden spätestens im Leveleditor einander untergeordnet.
Diesen Schritt schon im Modellingprogramm zu machen halte ich für eine sinnvolle Idee.
Erstellt man also einen Roboter aus mehreren Einzelteilen, heißt es:
Beine, Kopf und Arme dem Körper, Füße den Beinen und Hände den Armen unterordnen.
Dabei sollten auf jeden Fall der vorherige und der nächste Punkt beachtet werden!
[*][size=5][u]Objektmittelpunkt auf den Drehpunkt setzen[/u][/size]
Nicht nur der Kontaktpunkt ist interessant, sondern auch der Drehpunkt eines Objekts kann es sein.
Modelliert man z.B. ein Karussell, dann sollte man den Objektmittelpunkt nicht außerhalb der Mittelachse wählen.
Im Spiel soll sich das Karussell nämlich ggf. drehen, und es ist schon ein wenig schade, wenn dazu beim Leveldesign rumgetrichst werden muss.
Setzt man den Objektmittelpunkt auf den Drehpunkt, so muss man das Objekt einfach nur noch um die richtige Achse drehen.
Kombiniert mit dem Kontaktpunkt-Ansatz kommt bei einem Karussell nur ein Objektmittelpunkt in Frage: Unten in der Mitte.
[/list]

Beachtet man als Modellierer für Spiele diese recht einfachen Punkte, dann macht man sich eine Menge Freunde unter den Leveldesignern

[size=2]* Ich erhebe keinen Anspruch auf Vollständigkeit dieser rein zur Textzierde erstellen Liste.
** Gears of War benutzt 156UU (Unreal Units) als Charakterhöhe, Unreal Tournament ungefähr 200UU.
*** Namenskreation von mir, also beim Googlen nicht wundern [/size]

Sascha

Sascha

 

ScriptableObjects - Assets für jeden Zweck (oder: Wie man ein Inventarsystem richtig baut)

Es ist nicht das erste Mal gewesen, dass ich meinte, an die Grenzen von Unity gestoßen zu sein - und mich irrte.
Dieses Mal war es der zweite oder dritte Ansatz gewesen, ein komplett sauberes Inventarsystem zu erstellen.
Unity ist ja sonst immer sehr flexibel und bietet alles, was der Programmierer braucht, für jeden Zweck.
Aber für diese Situation schien die Engine keine vernünftige Lösung bereit zu stellen:[list=1]
[*]Das Inventar soll in mehreren Scenes verfügbar sein
[*]Ich will jede Scene starten und testen können
[*]Ich will nicht mit Item-IDs arbeiten, da sie unübersichtlich und unsicher sind
[*]Ich will die Items per Drag&Drop angeben können
[*]Items sollen ein Bild, einen Namen und evtl noch Eigenschaften haben
[/list]
Wer sich schon einmal an einem Inventarsystem versucht hat (und alles folgende noch nicht kennt), wird auch das Gefühl gehabt haben, dass Unity für diesen Fall keine wirklich schöne Lösung parat hält.

Was man bräuchte, wären Datenstrukturen, die Scene-übergreifend verfügbar sind (Punkt 1).
Wegen Punkt 2 kommt [url="http://unity3d.com/support/documentation/ScriptReference/Object.DontDestroyOnLoad.html"]DontDestroyOnLoad()[/url] dafür nicht in Frage, weil ich zum Testen nicht in jedem Level ersteinmal ein Inventory-Objekt platzieren will, und sollte dieses am Player drankleben, dann will ich nicht jedes Mal das Inventory neu mit Items bestücken.
Das allein schon, weil ich die auch alle wieder löschen muss, wenn ich das Spiel von vorne starte, da wegen DontDestroyOnLoad() bei jedem Scenewechsel ein neues Inventar auftaucht.
Ein Singelton wäre die nächste Möglichkeit:
[Inventory.js]
[code]private static var existing : Inventory;

function Awake()
{
if(existing)
{
Destroy(this);
}
else
{
existing = this;
DontDestroyOnLoad(this);
}
}[/code]
...davon gäbe es immer nur eins.
Aber wer will denn schon diesen hässlichen GameObject-Müll in seinen Scenes haben, besonders, wenn er, wie ich an diesem Punkt, ein sauberes Konzept haben will?

Punkt 3 und 4 sorgen dafür, dass ich nicht einfach ints hin- und herschieben kann, will ich ja auch nicht.
Welcher Designer will schon ständig darauf achten müssen, welche Nummer jetzt wo liegt... und wenn sich dann mal wo die Nummer ändert... gar nicht erst drüber nachdenken.
[b]Ich brauche also irgendein Objekt oder Asset, das jeweils ein Item repräsentiert.[/b]

Und Punkt 5 besagt, dass dieses auch noch verschiedene Felder haben soll, also mind. eine Texture2D, ein paar Strings und wer weiß, was noch alles.

[b]Zusammengefasst:[/b] Ich will ein Asset haben, dass ich selbst programmieren kann.

[size=4][u]Prefabs benutzen?[/u][/size]
Was hat man denn alles an Assets, die Scripts haben können?
Naja, Prefabs.
Prefabs sind prima, aber nicht dafür, denn sie sind Schablonen zum Klonen und können verändert werden.
Ein Prefab-Item könnte zwar als Referenz hin- und hergeschoben werden, aber auch Instanziiert und dann verändert, und das geht völlig am Zweck vorbei, dann hat man zwei Instanzen des gleichen Items, die unterschiedlich sind...
Das kann man vielleicht sogar wollen, aber das ist dann wieder eine ganz andere Geschichte.
Ausserdem hat ein Prefab, welches ja ein GameObject ist, immer eine Transform-Komponente, wobei wir wieder bei überflüssigem Datenmüll wären.

Keine Prefabs also.

[size=4][u]Und wie soll das jetzt gehen?[/u][/size]
Eine Datei wie eine xml, die ich mit einem Skript auslese, kam für mich nicht in Frage, da so etwas im Editor schlecht zu benutzen ist und den Workflow ausbremst.
Um also herauszufinden, was ich noch alles als Variablentyp in meinem Inventory-Script verwenden könnte, ab in die Scripting-Reference.
Eine Variable (und damit alles, was ich im Inspektor als Eigenschaft deklarieren kann) ist - wer objektorientiertes Programmieren richtig gelernt hat - immer vom Typ Object oder einem Subtyp.
Also schaue ich mir die Subtypen von Object an, die Unity so anbietet, und stoße auf [b]ScriptableObject[/b]s.

ScriptableObject erbt direkt von Object und ist damit schon mal kein MonoBehaviour, also nichts, das man als Skriptkomponente einem GameObject geben kann.
Der andere wichtige Subtyp von Object in Unity ist [i]Component[/i], dessen Subtypen allesamt genau das Gegenteil, also GameObjects zuweisbar, sind.

Was ist nun aber der Sinn davon?
Die Scripting Reference sagt (übersetzt):
[quote]Eine Klasse, von der man erben kann, um Objekte zu kreiren, die keinen GameObjects zugewiesen werden sollen.
Das ist am nützlichsten für Assets, die Daten speichern sollen.[/quote]
Selbstgemachte Assets also - Hurra!

[size=4][u]Aber wie benutzt man sie?[/u][/size]
Gute Frage. Die Scripting Reference hilft hierbei nicht weiter.
Aber wer schon hier und da mal Assets über ein Skript bearbeitet hat, kennt bereits die [url="http://unity3d.com/support/documentation/ScriptReference/AssetDatabase.html"]AssetDatabase[/url]-Klasse, genauer:
Die Funktion [url="http://unity3d.com/support/documentation/ScriptReference/AssetDatabase.CreateAsset.html"]CreateAsset()[/url].
Erster Parameter: Ein Objekt, das als Asset-Datei (.asset) in dem Asset-Ordner gespeichert werden soll,
zweiter Paramater: Der Pfad relativ zum Projektordner.

Also einfach ein ScriptableObject als Parameter übergeben und fertig?
überraschende Antwort: Ja.

Aber als erstes erstellen wir uns unser [b]InventoryItem.cs[/b]:
[code]using UnityEngine;
using System.Collections;

public class InventoryItem : ScriptableObject //nicht MonoBehaviour
{
public Texture2D image;
public string itemName; //Nicht "name", das gibt ärger wegen Object.name
public int value; //der Preis des Items
}[/code]
Wie man sieht: Wir erben nicht von MonoBehaviour, sondern von ScriptableObject.
Man kann das Skript deshalb nicht mehr als Komponente an ein GameObject heften.
Ich benutze hier bewusst C#, da man in JavaScript immer automatisch von MonoBehaviour erbt, also kein ScriptableObject damit scripten kann (ausser als embedded Class, und das muss ja nicht sein...).

[size=4][u]Und wann CreateAsset() aufrufen?[/u][/size]
Da man keinen Eintrag "Create Asset" im Kontextmenü hat, und auch das Erstellen einer .asset-Datei außerhalb von Unity nicht funktioniert (ScriptableObject nicht nachträglich zuweisbar), müssen wir CreateAsset irgendwo unterbringen.

Hierbei hilft uns [url="http://unity3d.com/support/documentation/ScriptReference/MenuItem.html"][MenuItem][/url] (JS: @MenuItem).

Mit [MenuItem] erstellen wir uns jetzt eine statische Funktion in einem neuen Script, welches im einem Editor-Ordner stecken muss:
[code]using UnityEditor; //WICHTIG!
using UnityEngine;
using System.Collections;

public class CreateInventoryItem
{
[MenuItem("Inventory/Create Inventory Item")]
static void CreateAsset()
{

}
}
[/code]
[font=Courier New]using UnityEditor;[/font] ist standardmäßig nicht in einem neuen C#-Skript enthalten, also unbedingt einfügen, denn ohne funktioniert [MenuItem] nicht.
Wegen genau dieser Anweisung muss das Skript auch in einem Ordner namens "Editor" stecken: In einen Build kann man dieses Skript nicht mehr exportieren, daher würde das Skript überall anders eine Fehlermeldung werfen.

Jetzt füllen wir der Reihe nach CreateAsset() mit Anweisungen:[list]
[*]Ein neues InventoryItem erzeugen:[code]ScriptableObject asset = ScriptableObject.CreateInstance(typeof(InventoryItem));[/code]
...warum nicht einfach über "new", sei später erklärt.
[*]Das Asset erzeugen:[code]AssetDatabase.CreateAsset(asset, "Assets/NewInventoryItem.asset");[/code]
...das .asset ist wichtig, genau wie der Ordner Assets.
[*]Und damit das Ganze richtig schön wird, Fokus-Schmankerl, die das Asset im Project View markieren:[code]EditorUtility.FocusProjectWindow();
Selection.activeObject = asset;[/code]
[/list]
Das fertige Script sieht dann so aus:
[code]using UnityEditor;
using UnityEngine;
using System.Collections;

public class CreateInventoryItem
{
[MenuItem("Inventory/Create Inventory Item")]
static void CreateAsset()
{
ScriptableObject asset = ScriptableObject.CreateInstance(typeof(InventoryItem));
AssetDatabase.CreateAsset(asset, "Assets/NewInventoryItem.asset");
EditorUtility.FocusProjectWindow();
Selection.activeObject = asset;
}
}[/code]

Speichern, schließen, fertig!
Jetzt einmal oben im Editor auf Inventory klicken (wenn es nicht da ist, einfach oben irgendetwas anklicken, dann kommt's), neues Item erstellen, umbenennen und Werte zuweisen.
Das kann man jetzt beliebig oft und einfach machen.

[size=4][u]Fertig![/u][/size]

Erstellt man jetzt irgendwo ein Feld[code]Inventory item;[/code]...erhält man ein Skript, das weiß, welches Item der Spieler bekommt, wenn man es aufsammelt.
[spoiler][code]InventoryItem item;

void OnTriggerEnter(Collider other)
{
if( ... ) //Wenn Spieler, oder: Wenn Inventar hat
{
// Inventar erhält item
Destroy(gameObject);
}
}[/code][/spoiler]
Ein Inventar hat dafür ein Array:[code]InventoryItem[] items;[/code]...vermutlich aber auch ein dynamisches

Jetzt haben wir ein System erstellt, mit dem man durch einfache Klicks, Drag&Drop und Texteingabe beliebig tolle Items erstellen kann, und das, ohne dass man beim Benutzen auch nur einen Moment lang eine Zeile Code anschauen muss.
Völlig intuitiv also, ganz so, wie es in Unity üblich ist, sodass sich der Designer drüber freut

Bei den Schnipseln habe ich, wie man sieht, weiterhin C# benutzt. Wer mal versucht, eine mit C# gemachte Klasse in JS zu benutzen, weiss, warum.

[size=4][u]Nachtrag zu ScriptableObject.CreateInstance()[/u][/size]
Ach ja, da war ja noch etwas: Warum nicht einfach [font=Courier New]new InventoryItem()[/font] benutzen?
Zuerst einmal: Das geht auch.
Unity mag es nur nicht und gibt dabei eine Warnmeldung aus, man solle doch CreateInstance() benutzen. Das ist dann etwas nervig.

In der Praxis macht "new" aber nur einen Unterschied: Ein über CreateInstance() erzeugtes Objekt verhält sich genau wie ein MonoBehaviour als Komponente.
Schaut man sich das Asset, das ein mit CreateInstance() erzeugtes Objekt beinhaltet, an, sieht man, dass man die Klasse tauschen kann, also ein anderes ScriptableObject-Derivat einfügen kann,
genau wie man bei MonoBehaviour-Komponenten im Inspektor das Script tauschen kann.
Das ist vermutlich eine gute Sache, wenn das Script irgendwie mal abhanden kommt.

Benutzt man dagegen "new", fehlt diese Einstellung und das Asset ist an die ScriptableObject-Klasse gebunden.
Das klingt zwar ganz nett eigentlich, warum sollte man tauschen können?
Aber die Warnmeldung drängt schon ein wenig dazu, CreateInstance() zu bentzen, wer weiß schon, welcher Sonderfall ansonsten die Assets corrupted oder solche Scherze...
Von daher: Jeder für sich.

[size=4][u]Schluss für heute[/u][/size]
So, jetzt habt ihr was über ScriptableObjects, MenuItem und über objektorientierte Programmierung gelernt. Happy Coding!

[size=4][u]Noch ein kleiner Nachtrag[/u][/size]
Wenn man es mit MenuItem übertreibt, sieht der Unity Editor plötzlich reichlich unübersichtlich aus.
Den MenuItem-Eintrag sollte man daher vielleicht ändern auf
[code][MenuItem("Assets/Create/Inventory Item")][/code]
Viel besser!

Sascha

Sascha

 

Copyright - Damit umgehen und selbst anwenden

Unser User Blacky ist sicher nicht der erste, der auf [url="http://forum.unity-community.de/index.php?/topic/1059-allgemeine-frage-zum-%C2%A7-recht-oder-copyright/page__pid__7118#entry7118"]das Thema Copyright[/url] gestossen ist.
Die Frage danach, was man (benutzen) darf und wie man mit dem gleichen Recht seine eigenen Werke vor der Benutzung anderer schützen kann, ist immer aktuell für die meisten Hobbyisten - nicht nur in der Spieleentwicklung, wenn auch hier in besonderem Maße.
[img]http://blackicegames.de/files/uin/titel.png[/img]

Als Anfänger kann man problemlos ausschließlich mit den Standard Assets arbeiten, als Profi macht man das irgendwie selber oder bezahlt, und dazwischen ist man in einer langen Phase des Kämpfens um einzelne Assets.

[u][size=5]Benutzung von Materialien anderer[/size][/u]
Ob 3D-Modell, Textur oder Sound: Es gibt vielerlei Dinge, die im Internet schon fertig zur Benutzung nur so auf ihren Download warten.
Für private Zwecke, sprich: Zum Spiele entwickeln Lernen, darf man sicherlich alles herunterladen und benutzen.
Nur beim Veröffentlichen ist Vorsicht geboten - auch, wenn man kein Geld damit verdient.

Generell gilt schon einmal: Ausschau halten bei Inhalten anderer.
In der Regel sind irgendwo Informationen darüber gegeben, ob und wie man etwas benutzen darf.

[b][size=4]© - das amerikanische Copyright[/size][/b]
Das Copyright ist ähnlich zum deutschen Urheberrecht, unterscheidet sich aber auch ein wenig.
Insgesamt betrachtet bedeutet es: Dieses Werk ist rechtlich geschützt, wer es verwenden will, braucht eine Erlaubnis dazu.
Das Recht an dem Objekt liegt dabei nicht zwangläufig beim Ersteller: Das Copyright-System erlaubt es, dass ein sog. Rechteverwerter über die Verwendung zu bestimmen hat.
Nicht zuletzt darum schaut man auf das, was hinter dem Symbol steht, meistens findet man ein Datum und einen Namen dahinter.
Hinter diesem Namen verbirgt sich der Ansprechpartner.
Gibt dieser zu einer Verwendung nach abgeklärten Richtlinien (z.B. auch kommerziell oder nur non-kommerziell) sein OK, kann das Objekt benutzt werden.
[url="http://de.wikipedia.org/wiki/Copyright"]Mehr Infos[/url]

[b][size=4]Creative Commons[/size][/b]
Die Creative Commons sind ein vergleichsweise neues System, das die Rechte anderer im Vorfeld wesentlich genauer beschreibt.
Es basiert auf der Idee freier Medien, deshalb kann ein Objekt mit CC-Lizenz auf jeden Fall verwendet werden, nur eben unter Einschränkungen.

Es gibt von der CC-Organisation verschiedene Lizenztypen, die je nach Bedarf ausgewählt und benutzt werden können.
So ist z.B. von vorneherein definiert, ob das Werk kommerziell genutzt werden darf, ob das Objekt zu anderen Objekten weiterverarbeitet werden darf (wie ein Remix eines Liedes) oder unter die Rechtsprechung welches Landes das angewendete Kopierrecht fallen soll.
Es gibt aber keine Lizenz, die die Verwendung des Objekts generell verbietet.

Hat man ein Objekt mit einer CC-Lizenz vor sich, kann man schnell daraus erkennen, was man damit darf und was nicht, und unter welchen Bedingungen.
Aussehen tut das in etwa so:
[url="http://creativecommons.org/licenses/by-nd/3.0/de"][img]http://i.creativecommons.org/l/by-nd/3.0/de/88x31.png[/img][/url]
Man beachte den Link, der auf eine Seite führt, die die Rechte genauer beschreibt.

Objekte mit einer CC-Lizenz sind super für Hobbyentwickler, da die eingeschränkteste CC-Lizenz immernoch die nichtkommerzielle Benutzung erlaubt, wenn nichts an dem Objekt selbst verändert wird.

[b][size=4]Nutzungsbedingungen - Terms of use[/size][/b]
Manchmal aber findet man Objekte, die keine der beiden genannten Kennzeichnungen besitzen.
Auch abgesehen von Bildern, die man über die Google-Suche sucht und sich dann ohne Kontext anzeigen lässt (in solchen Situationen ist man verpflichtet, den Kontext des Bildes anzusehen, den der Anbieter bereit stellt, um zu sehen, ob er z.B. ein © darunter gesetzt hat), sollte man Vorsicht walten lassen.
Die Seite des Anbieters hat u.U. eine Seite mit Nutzungsbedingungen aufgestellt.
Diese gilt für jedes Objekt der Seite.

[u]Beispiel: Freeplaymusic.com[/u]
Die Musikstücke auf der Seite sind zum größten Teil kostenlos herunterladbar, und die Seite wirbt auch mit der freien Verwendung aller erworbenen Stücke.
"Toll!", denkt man sich, und benutzt heiter die mp3-Dateien.
In diesem Fall aber begibt man sich auf sehr dünnes Eis, den wenn man einen Blick in die Terms of use der Seite wirft, so findet man folgenden Abschnitt:
[quote]3. FPM Uses Requiring A [b]Signed Paid License[/b]:
[...]
(h) Internet

(i) Any website including but not limited to personal websites and any website used to promote a business, product, service, organization or club;

(iii)Any videos including videos posted, viral or disseminated in any other fashion.

[b](iii) Gaming / Shareware / Freeware[/b]

(iv) Podcasting

(v) Blogs[/quote]
So viel dazu. Die Terms of use verbietet eindeutig die Benutztung der Musik bis zum Abschluss einer kostenpflichtigen Lizenz.
Bei näherer Nachfrage ergibt sich: Für einen Webplayer-Build kostet ein Lied 25$ - und das für [b]eine[/b] URL (also [b]ein[/b] Spiel) und auch nur für [b]ein[/b] Jahr.
Bei Standalone-Spielen zum herunterladen sind es sogar 50$ - und das nur, wenn man unter 100 Downloads bleibt.

Dementsprechend groß dürfte der ärger sein, wenn man die Regeln bricht - auch, wenn man sie schlicht übersehen hat.
Sucht also immer gründlich nach irgendwelchen Nutzungsbedingungen!

[b][size=4]Mein Zeug ist kostenlos![/size][/b]
Wenn man bezüglich eines Objektes deutlich angegeben hat, wie der Autor die Handhabung seines Werkes wünscht, dann hält man sich einfach daran.
Steht irgendwo: "everything may be used for free for commercial purposes"
...dann darf man sich freuen, denn wenn der Autor das sagt, kann das keine Falle sein.
Seid aber so nett und nennt den Autor in den Credits eures Spiels, besonders, wenn darum gebeten wird "Credits appreciated".

[b]Es gibt noch weitere Lizenz-Typen[/b], wie z.B. die GNU-Lizenz. Schaut euch einfach an, was für eine Lizenz das Objekt schützt, und dann googelt es ggf.

[u][size=5]Eigenes Material schützen[/size][/u]
Will man sein Spiel oder sonst irgendetwas schützen, so muss man nur eine der genannten Lizenzen geltend machen.[list]
[*]Für ein Copyright, setze ein © unter das betroffene Objekt.
Am besten so:
Image © DiesesJahr, MeinName
oder
MeinSpielName © DiesesJahr, MeinName

Versucht aber gar nicht erst, einen Namen durch © zu schützen, der bereits geschützt ist (auch wenn es mit einer anderen Lizenz ist).

Fertig! Das ganze ist sofort rechtskräftig!
[*]Für eine CC-Lizenz, besuche die [url="http://creativecommons.org/choose/?lang=de"]Creative Commons-Seite[/url] und suche deine Bedingungen aus.
Der Generator gibt am Ende HTML-Code aus, der einfach auf die Website zu kopieren ist.
[/list]
Ich wünsche allen Erfolg dabei, nicht in rechtliche Fallen zu tappen. Möge euer Leben Anklagefrei sein!

Sascha

Sascha

 

Portal + Portal 2 von Valve

[img]http://s3.directupload.net/images/110109/oopo5c99.jpg[/img]
[size="2"][font="Verdana"][b]
[size="4"]Portal[/size]
[/b]
[b]Genre:[/b] Action / Geschicklichkeit
[b][b]Veröffentlichungsdatum:[/b] 10 Oct 2007
Entwickler:[/b] Valve
[b]Publisher: [/b]Valve
[b]Multiplayer:[/b] Nein
[b]Level Editor:[/b] Ja
[b]Steam Errungenschaften:[/b] Ja
[b]Steamplayâ„¢:[/b] Ja

Portal ist kurz gesagt ein Denkspiel das nach einiger Zeit in ein Spiel für Zeitvertreib wechselt.
Portal geizt mit 19 Level und einer geschätzten Spieldauer von 2,5-3 Stunden.

[b]Die Geschichte:[/b]

Sie wachen in einem Aufwachraum auf und werden von einer netten weiblichen Computerstimme begrüßt. In diesem riesigem Labor werden Sie durch Portale geschickt um von A nach B zu gelangen um mit einem Aufzug zum nächsten Level zu gelangen. Die moderne Computerstimme begleitet Sie dabei 19 Level lang und gibt recht ironische Witze von sich, jedoch hilft Ihnen dabei durch das Labor zu gelangen. Am Ende erwartet Sie eine Belohnung.
-Wird nicht verraten-
[b]
Fragen die jedem in den Kopf kommen nachdem man Portal gespielt hat:[/b]

[i]Wieso bin Ich dort aufgewacht und wieso bin ich gefangen und muss diese Rätsel lösen?[/i]
- Dies ist unklar. Es steht nur fest das Sie eine art Versuchskaninchen für das "Aperture Laboratories" sind.
- Der Zweck wird nicht gennant.

[b]Die Details von Portal:[/b]

Es gibt immer zwei Portale. Ein Eingangs- und ein Ausgangsportal. Diese können aber auch andersherum genutzt werden.
Durch die Portale können sie durchsehen und schauen was auf der anderen Seite passiert.
Zu beginn sind Portale vorgegeben und müssen durch diese nur wechseln.
Alleine oder mit einem Cube - der meist für eine beschwerung dienen muss um eine Tür zu öffnen.
Nach einigen Level und verstehen des Prinzips bekommen sie eine Portalkannone in die Hand gedrückt und dürfen selber ein Portal (das zweite ist fest) platzieren.
Dies fördert ein wenig mehr. Gegen 3/4 des Spieles dürfen sie nun genüsslich zwei Portale in der öffnen und schließen.
[b]
Einige Aufgaben:[/b]

Die Aufgaben in Portal sind recht abwechslungsreich. Gegenstände ohne oder mit ihenen durch ein Portal befordern um einen Button zu beschweren der eine Tür offen hält, oder Leuchtkugeln per Portal umzulenken um wiederum eine Tür zu öffnen. Wenn Sie durch eine erhöte Fallgeschwindigkeit in ein Portal gelangen, werden sie aus dem anderem Portalausgang ebenfalls "herausgeschleudert" und können somit Spalten oder hohe Mauern überwinden.

[b]Fazit: [/b]Portal ist ein lustiges Denkspiel das viel Spaß macht durch eine tolle aber einfache Grafik. Ein Zeitvertreib fürs Wochenende.

[i]Ein Portal-Spieler hat es geschafft das Spiel in unter 10Minuten durchzuspielen. Respekt![/i]
[url="http://www.youtube.com/watch?v=W1U5RUVENNE&feature=player_embedded#at=751"]Youtube-Link[/url]


[size="4"][b]Portal 2[/b][/size]
[b]
Genre: [/b]Action, Abenteuer / Geschiklichkeit
[b]Veröffentlichungsdatum:[/b] 18 Apr 2011
[b]Entwickler: [/b]Valve
[b]Publisher: [/b]Valve
[b]Multiplayer:[/b] Nein
[b]Co-op:[/b] Ja
[b]Platformen:[/b] PC, Mac, Ps3, xbox360

[b]Besonderheit: [/b]Bewegungssteuerung für den PC

In Portal 2 werden neue Testkammern im "Aperture Laboratories" erwartet, sowie einen Koop-Modus der eine eigene Kampage enthält mit unterschiedlichen Spielcharaktern. Dabei ist ein gemeinsammes Denken vorrausgesetzt. Valve hat versprochen das die Level anspruchsvoller werden und die Physik überarbeitet wurde.[/font][/size]

Daniel W.

Daniel W.

 

Battelfield Bad Company 2 + Vietnam

[img]http://s13.directupload.net/images/110107/7qu5isav.png[/img]

[b]Publisher[/b]: Electronic Arts
[b]ENTWICKLER[/b]: EA Digital Illusions CE AB (DICE)
[b]VERÖFFENTLICHUNGSDATUM[/b]: 05.03.2010
[b]Genre[/b]: FIRST-PERSON-SHOOTER
[b]Platformen[/b]: XBOX 360™, Playstation® 3, PC

[b]Besonderheit:[/b] [i]Frostbite Engine mit Destruction 2.0[/i]

Nachdem Battlefield Bad Company (konsolenexklusiv) ein so großer Erfolg wurde beauftragte EA DICE mit der Entwicklung des 2.Teils. Diesmal bestand die Herausforderung der Entwickler darin, dass Spiel für alle Plattformen zu veröffentlichen. Mit der hauseigenen ‚Frostbite‘-Engine als Basis, die schon bei Bad Company1 zum Einsatz kam, machten sie sich ans Werk.

Schon in der Beta machte das Spiel einen sehr guten Eindruck. Vor allem die bis dato noch nie dagewesene Zerstörbarkeit der Umgebung und die damit verbunden Taktischen Möglichkeiten waren ein Novum.

Am [b]5.März[/b] konnten wir uns endlich auf das fertige Spiel stürzen.

Im Singleplayer übernimmt man die Rolle des Soldaten Preston Marlowe, eines von vier Mitgliedern der B-Company, genannt Bad Company. Die anderen Mitglieder Haggard, Sweetwater und Sarge begleiten den Spieler durch die Kampagne, die ganz gut gelungen ist aber keine neuen Maßstäbe setzt. Besonders witzig sind die Kommentar der Probanden. Alles in Allem kann man sagen das der Singleplayer gelungen ist.

Aber man kauft sich kein Battlefield wegen des Einzelspieler-Modus, das Herzstück der Serie war und ist immer noch der Mehrspielernodus. In Bad Company geht es heiß her. Da kommt vor allem die Besonderheit der Engine zum Vorschein, die Zerstörbarkeit. Zur Auswahl stehen 4 Klassen, Sturmsoldat, eine Art Rambo mit MP, Sanitäter, Heiler mit MG, Pionier, Panzerabwehr und Uzi, und Aufklärer, Aufklärer mit Scharfschützengewehr. Neue Waffen können für jede Klasse freigeschaltet werden, indem man Punkte für sie sammelt, man tötet Leute oder benutzt klassenspezifische Ausrüstung ala Defibrillator oder Munitionspack. Zusätzlich dazu gibt es noch ein separates Profillevel-System dadurch kann man Waffen freischalten die nicht an Klassen gebunden sind. Man hat relativ flott alles freigespielt. Zu den Maps kann man nur sagen das sie relativ unterschiedlich und ausgeglichen sind, wobei es oft davon abhängt welchen Modus man Spielt. Die Modi sind Rush (Objectives nacheinander zerstören/verteidigen) (auch im Squadmodus) ,(Squad-) Team-Deathmatch und Eroberung (Objectives einnehmen&halten).Man kann sie klassisch oder im Hardcore (mehr Schaden) Modus spielen. Das Zerstörungssystem ist sehr gelungen, nichts gibt einen ein besseres Gefühl als einen Camper mit einer Granate auszuräuchern oder mittels luftschlag ein Haus in seine Einzelteile zu zerlegen. Aber die Zerstörbarkeit hat nicht nur seine Vorteile, nicht allzu
selten wird man Opfer einer Panzerabwehrwaffe (RPG oder Gustav), das nervt vor allem wenn man als Fußsoldat stirbt aber der Panzer unbehelligt durch die Map düst.

[b]Fazit:[/b] Man kann sagen das BC2 sehr gelungen ist. Der Singleplayer ist eine nette Dreingabe. Der Multiplayer ist dank der Frostbite Engine und der Zerstörbarkeit ihrer Maps hervorragend, doch aufgrund von RPG Spamer und Sniper-Camper und der Tatsache das man schnell alles freigeschalten hat verliert sich schnell die Motivation. Alles im Allem ist Battlefield Bad Company 2 dennoch eine Empfehlung wert.


Am [b]21.Dezember[/b] ist die erste [b]Battlefield Bad Company 2 Erweiterung (Vietnam)[/b] erscheinen mit neuen Maps, Waffen und mehr.

Die Entwickler von Battelfield Bad Company 2 Vietnam schicken uns zurück in die Jahre 1950 des Vietnamkrieges.
Was erwartet man in dieser Zeit? Natürlich: Dschungel, Reisfelder, zeitgenössische Waffen und einen Soundtrack mit Hits wie Fortunate Son oder Ritt der Walküre. Diese Soundtracks können mitlerweile nicht nur im Ladebildschirm, sondern auch als Radiosender in Panzer, Helikopter und Jeeps.

[b]Die Waffen.[/b] Natürlich gibt es keine Rotpunkt-Visiere, Bewegungssensoren oder Lenkraketen. Nur ganz neu - und recht Spaßig - ist der Flammenwerfer. Die DLC muss im Hauptmenü ausgewählt werden und ein externes Hauptmenü (nur für das Multiplayer-Pack-Vietnam) öffnet sich. Vietnam bietet 14 neue Waffen, einige neue Panzer und Kriegsboote die mit schweren MG´s vorne und hinten besetzt sind.

Neue Medallien sind für die neuen Waffen nun verfügbar.

[b]Ganz neue Map:[/b]

Als eindeutige Sieger der jüngst beendeten Community-Challenge rund um das Shooter-Addon Battlefield Bad Company 2 Vietnam gehen PC-Spieler hervor. Die haben das angepeilte Ziel 69 Millionen Teamaktionen zu bewältigen, vor den Konsolen-Gamern erreicht.
Battlefield Bad Company 2 Vietnam: "Operation Hasting" wurde für alle Speiler verfügbar: Electronic Arts und Dice haben die Zusatzkarte für Battlefield Bad Company 2 Vietnam, "Operation Hasting", nun für alle Plattformen freigeschaltet. Zwar haben Konsolenspieler das angepeilte Ziel der Community-Challenge nicht erreicht, dennoch machen die Verantwortlichen die besagte Multiplayer-Map für alle verfügbar.

Daniel W.

Daniel W.

 

Spielemusikklassiker

Als ich eben eine meiner älteren Festplatten nach Unterhaltung absuchte, fand ich unter anderem den Ordner mit "Earth 2150: The Moon Project".<br />
Mann, das war ein Spaß damals.<br />
<img src="http://blackicegames.de/files/uin/titel.png" style="float:left;padding: 4px;" />Heutzutage gibt es immernoch gute Musik, aber damals... damals... waren die Lieder, die einzig für z.B. ein Auftauchen im Hauptmenü gemacht wurden, irgendwie noch etwas besonderes.<br />
Da kommen heutige Lieder, die einfach aufgekauft werden oder jene, die die selben Melodien wie vor zig Jahren neu vepacken (Halli-hallo Nintendo), einfach nicht heran.<br style="clear:both;" />
Hier das Lied, das mich dazu veranlasst hat, ein paar der mir am besten gefallenden Musikstücke vergangener Spielegenerationen mit euch zu teilen:<br />
<object width="480" height="385"><param name="movie" value="http://www.youtube.com/v/4Zd1daL7FWg?fs=1&hl=de_DE"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/4Zd1daL7FWg?fs=1&hl=de_DE" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object><br />
Wenn ich daran zurück denke, welche Musik mir noch so gefallen hat, fällt mir z.B. Battlefield 1942 ein.<br />
Aus heutiger Sicht, aber, wenn man mal drüber nachdenkt, auch schon damals, ist der revolutionär gute Soundtrack des zweiter-Weltkrieg-Spiels (damals war das auch noch nicht so durchgekaut) dem Spiel selbst um Längen voraus.<br />
Das Spiel spielt heute keiner mehr.<br />
Die Musik hören immernoch einige.<br />
<object width="480" height="385"><param name="movie" value="http://www.youtube.com/v/kaopMpvMZbg?fs=1&hl=de_DE"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/kaopMpvMZbg?fs=1&hl=de_DE" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object><br />
Bei genauerem Hinschauen entpuppt sich Electronic Arts, welches ja nun einmal für Battlefield verantwortlich war und ist, sowieso als sehr geschmackvoll, wenn es um Soundtracks geht.<br />
Ich habe seit Jahr und Tag den Menüsong von Battlefield Vietnam als Handyklingelton:<br />
<object width="480" height="385"><param name="movie" value="http://www.youtube.com/v/T0acN2v6aIc?fs=1&hl=de_DE"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/T0acN2v6aIc?fs=1&hl=de_DE" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object><br />
Dieses wiederum ist ein Remix von "White Rabbit" von den Jefferson Airplanes.<br />
Und wenn das keinen Stil hat, was dann?<br />
<object width="480" height="385"><param name="movie" value="http://www.youtube.com/v/WANNqr-vcx0?fs=1&hl=de_DE"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/WANNqr-vcx0?fs=1&hl=de_DE" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object><br />
Abgesehen davon entspringt wohl die Hälfte aller Musik auf meinem portablen Multimediagerät einem der vielen Need For Speed Soundtracks seit Underground 1.<br />
Besonders herausstechen tut dabei unter anderem das adrenalinausstoßfördende Verfolgungsjagdlied "The Mann" von Paul Linford und Chris Vrenna, zu hören in Need For Speed Most Wanted.<br />
Obwohl dieses Lied tatsächlich schon eher einer neuen Spielegeneration zugehörig ist (es gibt ja sogar eine Next-Gen-Version davon), ist es dennoch ein Stück Musik, das mir nach wie vor Gänsehaut beschert, wenn ich an die spannenden Polizeijagden zurückdenke.<br />
<object width="480" height="385"><param name="movie" value="http://www.youtube.com/v/RzvKJTfURts?fs=1&hl=de_DE"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/RzvKJTfURts?fs=1&hl=de_DE" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object><br />
Aber ich will ja nicht ausschließlich nostalgisch wirken.<br />
Die in letzter Zeit für Need For Speed zuständigen beschränkten sich auf eine Menge von 2 bis 3 guter Lieder pro Soundtrack, und Nintendo recycled alte Melodien, um die Fans glücklich zu stimmen.<br />
Dennoch gibt es auch heute noch beizeiten wirklich aus der Masse heraus stechende Lieder, die man wirklich auch ohne Spiel hören kann - mit macht es natürlich trotzdem mehr Spaß - ein Beispiel hierfür wäre Bionic Commando:<br />
<object width="480" height="385"><param name="movie" value="http://www.youtube.com/v/Wj94owo0kbA?fs=1&hl=de_DE"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Wj94owo0kbA?fs=1&hl=de_DE" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object><br />
Ja, ich weiß, auch diese Melodien haben in diesem Spiel nicht das Licht der Welt erblickt, aber als man sie das letzte Mal hörte, waren sie noch ziemlich 8-bit.<br />
Jedenfalls gibt es auch dieses nette Exemplar eines Hauptmenüliedes im Spiel, stilvoll auf den Tasten präsentiert:<br />
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/o6jujSx5N8E?fs=1&hl=de_DE"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/o6jujSx5N8E?fs=1&hl=de_DE" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object><br />
So, jetzt habt ihr ein wenig von dem abgekriegt, was ich gute Musik in Spielen nenne.<br />
Ich hoffe, das eine oder andere Lied gefällt euch, und ich habe euren Horizont erweitert [img]http://forum.unity-community.de/public/style_emoticons/default/wink.gif[/img] <br />
Damit das ganze aber noch einen kleinen Lerneffekt hat:<br />
<br />
Musik in Spielen ist wichtig.<br />
Vielleicht nicht für kleine Indie- oder Erstlings-Projekte, dafür für größere Projekte umso mehr.<br />
Musik kann das sein, was das Spiel vollendet, aber auch das, was einen Spieler auch nach Jahren noch an die gute Zeit mit einem Spiel erinnern kann.<br />
Wer ein gutes Spiel macht, wird dafür gemocht.<br />
Wer darin gute Musik hat, verewigt sich.

Sascha

Sascha

 

Ãœber Immersion

[size=5]W[/size]ird mal wieder Zeit, dass ich euch mächtig die Meinung sage, daher hier ein kleiner Abstecher ins Thema Immersion.<br /><img src="http://blackicegames.de/files/uin/titel.png" style="float:left;padding: 4px;" /><br />Als Immersion bezeichnet man es, wenn man sich richtig in ein Spiel oder einen Film hinein versetzen kann.<br />Wenn ein Spieler beim Spielen um sich herum nichts mehr mit kriegt, dann haben die Entwickler einiges richtig gemacht.<br /><br style="clear:left;" />Natürlich kann eine merkwürdige Wahrnehmung von Realität und Nicht-Realität auch von übermäßigem Spielekonsum herrühren...<br />[quote name='www.german-bash.org']Foxer: ich hock eindeutig zu viel vorm pc<br />Zulu: und was is jetz neu daran? *fg*<br />Foxer: ...<br />Foxer: naja, jedenfalls warn wir heute wieder mit der Rettung unterwegs<br />Foxer: auf einmal seh ich auf der 3. autobahnspur so ein baustellenfahrzeug fahren und dahinter ein normaler pkw mit ner warnleuchte darüber in form eines dreiecks und darin ein gelbes "!"<br />Foxer: und ich so zum fahrer "he, fahr mal rüber zu dem auto da, der hatn quest für uns"<br />Zulu: wtf...<br />Foxer: glaub mir, eine skunde später wollte ich mich für den satz aufhängen[/quote]<br />In der Regel aber ist es Aufgabe des Entwicklerteams, eine ordentliche Stimmung zu inszenieren und durch das Beseitigen von störenden Fehlern Immersion zu erzeugen.<br /><br />Dabei gibt es einige Fehler, die man machen kann, hier zwei davon:<br />[list]
[*]Modelle, Texturen und Animationen unterschiedlicher Qualität einbauen
[*]Hinweise darauf platzieren, dass alles nur ein Spiel ist
[/list]
Auf diese beiden Fehler würde ich gerne einmal kurz eingehen.<br /><br />[size=4][u]Modelle, Texturen und Animationen unterschiedlicher Qualität[/u][/size]<br /><img src="http://blackicegames.de/files/uin/texq.jpg" style="float:right;padding: 0 4px 0 8px;" /><br />In dem Beispielbild rechts von meinem momentanen Projekt sieht man einen Bildausschnitt, den man ingame aufgrund der Positionierung der Kamera nie zu Gesicht bekommt.Wäre dieses Spiel ein 3rd-Person-Spiel, sodass die Kamera in vergleichbarer Weise nah an den Boden herangebracht werden könnte, wäre eine klare Differenz in der Qualität zwischen den Texturen des Astronauten und des Planeten, auf dem er steht, sichtbar.<br />So eine Differenz lässt den Spieler die Texturen als solche wahrnehmen, und schon ist die Immersion hin.<br /><br />Das liegt aber nicht an der [i]niedrigen[/i] Qualität!<br /><br /><img src="http://blackicegames.de/files/uin/st3000_lq.jpg" style="float:left;padding: 0 8px 0 4px;" />Dieses Bild aus Spacetaxi 3000 ist qualitativ verschlechtert worden, so ähnlich würde das Spiel vermutlich mit sehr schlechten Texturen aussehen.<br />Trotzdem hat man ein einheitliches Gesamtbild, was letztenendes besser für die Immersion wäre, als das selbe Bild mit super-hochauflösendem Taxi (Dass man so kaum noch spielen kann, ist ein anderes Thema).<br /><br /><br />Habt ihr nicht auch das Gefühl, dass heutige Spiele nicht mehr so lebhaft wirken wie die früheren?<br />Dass man in GTA Vice City noch viel mehr Leben im Spiel wahrgenommen hat als in GTA IV?<br />Ich denke, das kommt durch die hohe Grafikqualität neuerer Spiele. Früher hat ein Bruchteil der Polygone einen Menschen dargestellt, und irgendwie haben die Menschen lebendiger gewirkt.<br />Der Grund ist vermutlich die Differenz zwischen Animations- und Modellqualität.<br />Denn eines steht fest: Das menschliche Gehirn ersetzt laufend Informationen, die die Wahrnehmung nicht liefert.<br />So ist es auch hier: Wenn ein Mensch-Modell Low Poly ist, dann erkennt man es trotzdem als Mensch und das Gehirn fügt jede Menge Infos automatisch hinzu, unter anderem die fehlenden Details subobtimaler Bewegungsabläufe.<br />Dass einem die simplen Haartexturen alter Spiele nicht so spanisch vorkommen wie die Polygonmatte von Cel aus Mirror's Edge liegt daran, dass das Gehirn beim Analysieren ihrer High Poly-Gestalt feststellt, dass es nicht mehr viel zu ergänzen gibt - und schon fällt einem auf, dass ihre Haare starr sind wie Knetmasse.<br />Genauso stören aus auf den ersten Blick unerfindlichen Gründen auch die Menschen in GTA IV.Sie sehen sehr realistisch aus, aber sie bewegen sich... irgendwie nicht richtig.<br />Sie sind gut animiert, ja, aber nicht gut genug, um an die Grafik des Spiels angepasst zu sein.<br /><br />[size=4][u]Immersionszerstörende Hinweise[/u][/size]<br /><br />Viele Entwickler wollen es ihren Spielern leicht machen, allen voran Nintendo, deren Lieblingszielgruppe inzwischen die Casual Gamer sind.<br />Diese sind auf schnellen Spielspaß aus, dessen Bedienung man sich nicht erst über einen längeren Zeitraum als fünf Minuten hinweg aneignen muss.<br />So passiert es dann schonmal, dass der Charakter im Spiel plötzlich sagt: "Drücke B, um dieses Item zu benutzen".<br /><br />WTF?<br /><br />Schlimmer geht es kaum noch, wenn es um die Immersion geht.<br />Ja, es gibt natürlich auch Spiele, die sind einfach nur Spiele, nehmt dazu als Besipiel jedes beliebige Flash Game im Netz.<br />Man startet sie, spielt ein paar Runden und hat seinen Spaß.<br />Sobald es aber darum geht, eine mitreißende Geschichte zu erzählen, in die der Spieler eintauchen können soll, ist das nicht mehr lustig, sondern komplett kontraproduktiv (verdammt nochmal, Twilight Princess...).<br /><br />Wenn Du einfach nur ein Spiel programmierst, dass ein Spiel ist und bleiben darf, dann braucht Dich das alles eigentlich nicht zu stören.<br />Solltest Du aber an einem Spiel arbeiten, in dem Immersion wichtig ist, dann achte immer kritisch darauf, diese aufrecht zu erhalten.<br /><br />Weiterhin viel Erfolg beim Spiele machen<br /><br />Nachtrag: Mehr Infos über Immersion: [url="http://de.wikipedia.org/wiki/Immersion_%28virtuelle_Realit%C3%A4t%29"]Klick[/url]

Sascha

Sascha

 

Wachsende Zahlen

[size=5]H[/size]igh End-Grafik, kinoreifer Sound, tolle Synchronstimmen, spannende Handlung... die großen und bekannten Spiele heutzutage haben so viele Qualitäten, dass man teilweise nur staunen kann, wenn man überlegt, wie viel Aufwand dahinter steckt.<br />Gerade bei so viel positivem ist es schwer zu verstehen, dass einige Grundlagen gänzlich vernachlässigt werden.<br />Nehmen wir uns für das folgende zwei Beispiele moderner Spiele, die auf den ersten Blick nicht viel gemeinsam haben: [b]GTA IV[/b] und [b]Final Fantasy XIII[/b].<br /><br /><img src="http://blackicegames.de/files/uin/titel.png" style="float:left;padding: 0 8px 0 4px;" />Wie gesagt, bis auf römische Nummerierungen erkennt man nicht viel ähnlichkeit.<br />GTA IV ist ein ein [b]Open World Third-Person Shooter[/b] mit Fahrzeugen, Final Fantasy XIII (FF) dagegen ein sehr lineares [b]Rollenspiel[/b] (RPG).<br />Unterschiedlicher geht es eigentlich kaum.<br />Eine Gemeinsamkeit gibt es aber: Wachsende Zahlen.<br />In FF bestimmen sie das Spiel , indem sie die momentane Stärke des Spielers angeben (so ist es bei RPGs üblich).<br />In GTA dagegen gibt es lediglich das Geld, das einem zwar kaum auffällt, aber bis auf den Fortschritt in der Handlung die einzige Belohnung für den Spieler darstellt.<br /><br />Beide Spiele machen in Bezug auf wachsende Zahlen massive Fehler, auf die ich nun etwas eingehen möchte.<br /><br /><img src="http://blackicegames.de/files/uin/bellic2.jpg" style="float:right;padding: 4px;" />Da wäre zuerst einmal GTA IV.<br />Das Spiel macht sehr vieles richtig: Eine tolle Physik, mit der man jeden Autounfall fast schon als Ruck im Körper spürt, eine tolle Grafik, wegen der man gerne mal einfach am Pier 45 stehen bleibt und entweder dem geschäftigen Treiben der Leute oder einfach dem Sonnenuntergang über den glitzernden Wellen zusieht, und eine Stadt, die an jeder erdenklichen Stelle wieder neue Details aufweist.<br />Ein Sache aber wurde ganz schlimm falsch gemacht: Das Geld.<br />In GTA IV erhält man, wie auch in allen vorherigen Teilen der Serie, nach den meisten Missionen einen bestimmten Betrag zugeschrieben.<br />Dieses Geld lässt sich primär in Waffen investieren.<br />Ansonsten gibt es in dem Spiel noch Energieauffüller, Freizeitaktivitäten und Pay'n'Spray-Besuche zu kaufen, aber um es mit den Worten der Mastercard-Werbekampagne auszudrücken:<br />Volle Energie: 2$<br />100%-Freundestatus bei allen NPCs: 1.000$<br />Cops vergessen 50 Mal Dein Nummernschild: 5.000$<br />Waffenkosten abzüglich derer, die man auf der Straße findet: 20.000$<br />Verwendungsmöglichkeiten für Deine restlichen 700.000$: Unbezahlbar<br /><br />Denn hier liegt der Fehler: Man bekommt viel mehr Geld, als man tatsächlich ausgeben kann<br />Wo ist das Problem?<br /><br /><img src="http://blackicegames.de/files/uin/johnson2.jpg" style="float:left;padding: 0 8px 0 4px;" />Erinnern wir uns an den Vorgänger des Spiels, GTA San Andreas.<br />Der Protagonist, Carl Johnson, konnte überall auf der riesigen Weltkarte Immobilien erwerben, damit man darin speichern konnte.<br />Diese Investition ist schon einmal wesentlich attraktiver, als Geld für einen Besuch der Bowlingbahn mit Cousin Roman auszugeben.<br />Des Weiteren waren die Häuser im Vergleich zum Verdienst so teuer, dass man durch das reine Beenden der Hauptmissionen nicht genügend Geld hatte, um sich alle zu kaufen.<br />Und genau so ist es richtig: Der Spieler soll nicht einfach nur ganz viel Geld haben, er muss es sich erarbeiten.<br />Denn es macht den Spieler nicht glücklich, eine große Zahl auf dem Schirm stehen zu haben, sondern, sich eine große Zahl auf dem Bildschirm [b]verdient zu haben[/b].<br />Dies wird dadurch verstärkt, dass man auch Ausgaben hat!<br />Denn es macht keinen Unterschied, 100 Einheiten Geld zu haben oder eine Million, wenn man keine Ausgaben hat, an denen man den Wert dieses Geldes messen kann.<br />Auch wenn die Einheit Dollar ist, sodass man weiß, wie viel das gesammelte Vermögen wert ist, stört ein immer wachsender Geldberg wie in GTA IV.<br />Das Geld hat keinen Wert mehr, und der Belohnungseffekt beim Erhalten sinkt drastisch.<br /><br />Dieses Konzept funktionert auch bei EP, XP, Leveln oder wie auch immer man die steigende Macht eines Charakters bezeichnet.<br /><img src="http://blackicegames.de/files/uin/redsteel22.jpg" style="float:right;padding: 4px;" />Wenn, wie z.B. bei Red Steel 2, das Leveln nur dazu gut ist, an einem bestimmten Punkt plötzlich so gut zu sein, dass alle Gegner, da sie selbst nicht mit der Zeit stärker werden, nur noch Kanonenfutter sind, dann ist ein Levelsystem fehl am Platz.<br /><br />Womit wir zu Final Fantasy XIII kommen.<br />Im Gegensatz zu Red Steel 2 ist FF ein richtiges RPG, das vom Levelsystem lebt.<br />Ein auf den ersten Blick unglaublich komplex wirkendes Fähigkeitensystem (Kristarium genannt) will durch das Erhalten von XP erkundet werden.<br /><br />Der grundlegende Fehler, der hierbei gemacht wurde, ist wesentlich dezenter und schwerer zu erkennen.<br /><img src="http://blackicegames.de/files/uin/ffxiii.jpg" style="float:left;padding: 0 8px 0 4px;" />Wie eingangs erwähnt, ist FFXIII sehr linear, heißt: Der Spieler hat kaum freie Wahl, wo er lang geht, er muss von Punkt a nach Punkt b, und das in jedem Level von neuem.<br />Eine solche Linearität hat für ein RPG negative Konsequenzen.<br /><br />Verteilt ein Game Designer die Gegner auf dieser Strecke zwischen a und b, muss er sie sehr stark an den Level des Spielers anpassen, da dieser gegen sie kämpfen [b]muss[/b].<br />Zu schwache Gegner sind langweilig, und zu starke unmöglich zu besiegen.<br />Ergo ist der Gegnerlevel immer dem des Spielers ähnlich.<br /><br />Und wenn das der Fall ist, wird das Levelsystem überflüssig.<br /><br />Und damit sind wir an einem Kernproblem des RPG-Genres angekommen.<br />Wie sorge ich als Entwickler dafür, dass der Spieler seine steigende Stärke [b]spürt[/b]?<br />Dass sie ihm angezeigt wird, reicht nämlich nicht.<br />Die Lösung des Problems lässt sich durch das Betrachten von guten RPGs finden. Und an dieser Stelle nehme ich mir dafür Pokémon.<br />Es gibt vielleicht Leute, die mit diesem Spiel als Positivbeispiel nicht einverstanden sind, aber eines hat Pokémon immer richtig gemacht:<br />Man kann jederzeit an einen Ort gehen, an dem Gegner sind, die stärker oder schwächer sind als man selbst.<br />Man sieht seine eigene Stärke nicht nur durch Werte angezeigt, man spürt sie, wenn man gegen einen Arenaleiter am verlieren ist oder merkt, dass man die Viecher, mit denen man eben noch Probleme hatte, plötzlich mit einer Attacke besiegt.<br /><img src="http://blackicegames.de/files/uin/rubin2.jpg" style="float:right;padding: 4px;" />Des Weiteren gibt es noch die verschiedenen Typen.<br />Diese sorgen dafür, dass man ein noch so starkes Wasser-Pokémon haben kann, und dennoch in der Elektro-Pokémon-Arena versagt.<br />Auf diese Weise zwingt man den Spieler, sich von der Hauptmission abzuwenden und erneut zu leveln (nachdem man sein Digda gefangen hat).<br /><br />So kommte ich also zu dem Schluss:<br />Egal ob man nun Level oder Geld hat, wann immer das Erfolgsgefühl des Spielers von wachsenden Zahlen abhängig gemacht wird, gibt es ein paar simple Regeln zu beachten:<br />[list=1]
[*]Besser zu werden muss sich im Spielverlauf [b]spürbar lohnen[/b]

[*]Es muss immer eine [b]Motivation[/b] geben, noch besser zu werden<br /> (z.B. dass man auf überlegene Gegner stößt)

[*]Der Spieler [b]sollte[/b] nie [b]zu schlecht[/b], und [b]darf[/b] nie [b]zu gut[/b] sein<br /> (bzw. zu arm oder zu reich)
[/list]
Denkt man an solche Dinge, kann man tatächlich auch ein System erstellen, in dem wachsende Zahlen nicht nur nötig sind, sondern den Spieler auch wirklich belohnen.<br/><br />Viel Erfolg beim eigenen RPG!

Sascha

Sascha

 

Yeah, Spiele machen!

[size=5]W[/size]elches bessere Thema gäbe es wohl, kommende schriftliche Merkwürdigkeiten zum Thema Spieleentwicklung einzuleiten, als die Spieleentwicklung selbst?<br />
Wie auch immer ein Leser genau auf diese Zeilen stieß, es wird wohl mit der massiven Welle aus Menschen zu tun haben, die die Spieleentwicklung für sich entdeckt haben oder noch entdekcne wollen, und das vielleicht sogar, ohne eine professionelle Ausbildung für Grafikdesign, Programmierung oder sonst einer sich dafür anbietenden Fähigkeiten auf ausgeprägtem Niveau zu besitzen.<br />
<br />
<img src="http://blackicegames.de/files/uin/titel.png" style="float:left;padding: 4px;" />Ein Mangel an genannten Eigenschaften ist heutzutage mit rapide sinkender Wichtigkeit versehen.<br />
Denn, und das hast Du sicher bereits bemerkt:<br />
Spieleentwicklung wird immer einfacher. Immer präsenter.<br />
Während vor zehn Jahren das Monopol der Spieleentwicklung bei Menschen mit mehr verbrachter Zeit im Keller oder der Garage als an der frischen Luft, oder alternativ hoch und höher bezahlten Visionären, lag, ist in den letzten Quartalen ein neuer Trend entstanden, der sich aus der Modding-Szene ableitete.<br />
Grundidee ist, dass auch Hobbyisten das Zeug dazu haben, Spiele zu entwickeln.<br />
Gezeigt haben das neben diversen Mods genialer Qualität auch die Erfolge von Community Content, der nicht selten durch mitgelieferte Editoren eines Spiels enstehen konnte.<br />
<img src="http://blackicegames.de/files/uin/reignofsteel.jpg" style="float:right;padding: 4px;" />So war es nur eine Frage der Zeit, bis sich die Entwickler verschiedener Spiele-Engines dazu entschieden, ihre Produkte kostenlos anzubieten, 2009 beispielsweise erschienen Unity Indie und die Unreal Engine in Form des UDK.<br />
Diese Engines erhöhten das Niveau, die Bedienfreundlichkeit und die Anzahl an Möglichkeiten für Independant Developer (unabhängige Entwickler) im Vergleich zu den bereits verfügbaren, kostenlosen Engines deutlich.<br />
Das XNA Game Studio von Microsoft beispielsweise verfolgte bereits viel früher den Ansatz, Spieleentwicklung kostenlos zu machen, setzte allerdings viele Programmierkenntnisse voraus.<br />
<br />
Resultat der Veröffentlichungen war eine Welle von Benutzern, nicht selten unausgebildete Hobbyisten, die plötzlich Spiele für PC, Mac, oder iPhone entwickeln konnten, ohne sich dafür dumm und dusselig zu zahlen, und diese Gelegenheit nutzten.<br />
Neben denen, die an ersten Versuchen scheitern, gelingt es immer mehr Anfängern, stolz erste Ergebnisse zu präsentieren.<br />
<img src="http://blackicegames.de/files/uin/spacetaxi.jpg" style="float:left;padding: 0 8px 0 4px;" />Weitere Konsequenz des Trendes ist die Enstehung vieler Info- und Tutorial-Seiten, Videos und Internetforen (siehe Unity Insider), deren Zweck es ist, Neulingen einen guten Start zu ermöglichen, denn die neue Zielgruppe muss nun mal bei null anfangen.<br />
<br />
Probleme gibt es allerdings auch ein paar.<br />
So ist ein professioneller Programmierer / Designer / etc., sobald er seine Ausbildung beendet hat, in der Lage, sich bei einem richtigen Spielehersteller zu bewerben.<br />
Dort findet er Gleichgesinnte, Ausrüstung, Anleitung und Bezahlung.<br />
Nichts davon kommt für Hobbyentwickler von alleine.<br />
Equipment und Bares sind in den allermeisten Fällen schöne Nebeneffekte für diejenigen, die wirklich Talent dazu haben.<br />
Gleichgesinnte zu finden ist da schon einfacher, aber auch das ist schwierig, wenn diese tatsächlich effizient arbeiten sollen.<br />
<br />
Richtig Spiele entwickeln ist vermutlich die Königsklasse aller kreativen Arbeit.<br />
Ein Team sollte eine gewisse Menge Fähigkeiten abdecken, damit das Spiel erfolgreich werden kann.<br />
Die wichtigsten Bereiche sind:<br />[list]
[*]Programmieren (unabdingbar)
[*]Zeichnen und Bildbearbeitung (sehr wichtig und unabdingbar wenn's gut werden soll)
[*]Modellieren und Texturieren (für ein 3D-Spiel unabdingbar, sonst nicht nötig)
[*]Anderes (damit's richtig gut wird - Mapdesign, Sound, Video, Texte, Internetseite, ...)
[/list]
Letztenendes reicht also ein einziger, um ein Spiel auf die Beine zu stellen, wenn er etwas programmieren und ein wenig designen kann.<br />
Das Resultat wird dann allerdings entweder schlecht programmiert (und voller Fehler) sein oder schlecht aussehen - davon ist auszugehen.<br />
Zwei Kollegen sind daher in 99% der Fälle ein Muss, damit am Ende etwas spielbares entsteht.<br />
Als Information: Allein der Bereich Graphics Designer lässt sich, wenn man es genau nimmt, in dutzende Bereiche aufteilen, was der Grund ist, dass an großen, professionellen Spielen auch mehrere dutzend Leute beteiligt sind.<br />
Orientiert man sich daher als Einsteiger an großen Projekten (ich lese immer wieder "ich will eine riesige Spielwelt" oder "ich baue ein mmorpg"), dann muss man seine Einstellung zur ganzen Sache gleich einmal grundlegend überdenken.<br />
Denn es sitzen nicht zu Unrecht mindestens achzig gut bezahlte Menschen zum Teil mehrere Jahre an einem einzigen professionellen Titel.<br />
Wer in seinem ersten Spiel nichts weiter als eine Kugel hat, die man über einfarbige Kisten hinweg von a nach b steuern muss, der darf auf sich stolz sein.<br />
Wer sich als erstes vornimmt, mit seinem Kumpel aus der Schule, der immerhin eine zwei im Kunstkurs hat, einen Blockbuster mit geplanten 50 Spielern gleichzeitig auf 60km² Spielwelt zu bauen, bevor er alt und schrumpelig geworden ist, sollte sich lieber Briefmarken sammeln als Hobby nehmen.<br />
Wer jetzt versuchen will, möglichst viele "Mitarbeiter" um sich zu scharen, sollte unbedingt bedenken, wie schwer es ist, ein Team zu leiten, dass nicht bezahlt wird, und wie unmöglich es wird, die Arbeit aller zu koordinieren und zu einem Endprodukt zusammen zu fügen, insbesondere, wenn man das noch nicht einmal alleine geschafft haben sollte.<br />
<br />
Aber bitte nicht abschrecken lassen!<br />
Was ich damit sagen will ist zweierlei.<br />
Erstens: Jeder hat mal klein angefangen.<br />
Und das nicht, weil es mehr Spaß macht, sondern, weil es nicht anders geht.<br />
So ziemlich jeder, der es mit der Überholspur versucht hat, hat es zu gar nichts gebracht. Ausnahmen bestätigen aber auch hier die Regel.<br />
Zweitens: Sei realistisch.<br />
Baue dir erst das simpelste Spiel, dass Dir einfällt, dann das zweitsimpelste, und wenn beide fertig sind und funktionieren, hast Du so viel Einblick in den Aufwand dieser Arbeit bekommen, dass Du weißt, wie viel Du als nächstes schaffen kannst.<br />
Und wenn man so weit ist, kann es erstmal nur noch bergauf gehen.<br />
<br />
Viel Glück beim Spiele Programmieren!

Sascha

Sascha

×