Category

23 Aug 2015 Posted by: Comments: 0 In: Allgemein

Frisch aus dem Snippet-Labor: ein kleines Script, dass das ewig-nervige Rumgeklicke durch die Projektordner zu den Szenen ein wenig abkürzen soll.
Zumindest mich nervt sowas ziemlich ;)
Es lohnt sich vorallem, wenn man Unity schön über 2 Monitore fahren kann und Platz für ein paar extra Fenster hat.
Einfach „ScenesFolder“ anpassen und dort den Pfad zu euren Szenen angeben. Der Ordner sollte am besten NUR Szenen beinhalten.
Das Script selbst gehört in einen Editor-Ordner.
Unter „Window“ kann der Menüpunkt namens „ShowScenes“ gefunden werden – hiermit öffnet sich das Fenster und sieht etwa so aus:

scenelistwindow

Das Script:

 

16 Aug 2015 Posted by: Comments: 0 In: Allgemein

Nach ein paar Tests mit dem kostenlosen Service GameAnalytics kam folgende Erkenntnis: das Plugin aus dem AssetStore ist zwar ganz nett, aber kaum hilfreich. In den GameAnalytics  Docs stieß ich zwar auf einen wesentlich kürzeren und übersichtlicheren Ansatz, allerdings produzierte dieser Hickups. Dort wurde die WebRequest-Klasse verwendet. Damit kann man zwar mit etwas Bastelarbeit asynchron arbeiten, aber trotzdem gibt es Hickups unter Unity.
Also zurück zum guten alten Coroutine + WWW-Klasse.
Hier gibt es ein Snippet, mit dem sich der Service nutzen lässt, ohne in der Anwendung Performance-Probleme zu erzeugen.

 

15 Aug 2015 Posted by: Comments: 0 In: Allgemein, C#, Programming, Tutorial, Unity3D

Systeme koppeln mal anders! In diesem Post soll es um UnityExtension gehen.
So kanns aussehen: ein einfacher Würfel – aber was steckt dahinter? Und was sind Unity Extensions?

Ganz einfach: Unity Extensions sind Scripte, die Klassen, auch Unity-eigene Klassen, um diverse Funktionalitäten erweitern.

Ein einfaches Beispiel:
Sicher hast du irgendwann diese Methode verwendet:

Das ließe sich als Extension umsetzen und würde so aussehen:

So kann es benutzt werden:

So einfach ist das und lässt sich auf alles Mögliche anwenden! Da gibt es noch ganz andere Situationen, in denen Extensions pures Gold wert sind. 🙂
Nun viel Spass beim Extensions basteln!

13 Aug 2015 Posted by: Comments: 0 In: Allgemein, C#, Programming, Tutorial, Unity3D

Hier gibt es mal etwas anderes zu sehen als einen Spieleprototypen – nämlich einen CustomLogger, bzw. dessen Output.
Der Logger ist in C# geschrieben setzt aus Code-Schnipseln (Templates), je nach Bedarf, eine Html-Seite zusammen.
Ein wenig CSS und etwas JavaScript dürfen für Gestaltung und etwas Interaktivität auch nicht fehlen.
Der Logger findet seinen Einsatz natürlich wieder in Unity! Inspiriert ist das Tool durch einen interessanten Artikel zu den „best practices“ rund um Unity3D und der Tatasache, dass Unitys Standart Logger mit zunehmender Größe eines Projektes und der damit höhren Anzahl an Logs, einfach unübersichtlich wird. Sicher kann man auch mit diesem Logger auch an größeren Projekten arbeiten, aber warum sich das Entwicklerleben nicht auch mal etwas angenehmer machen?! Zumal sich das Tool im Anschluß in jedem anderen Projekt weiter verwenden lässt.

 

So sieht das Resultat also aus:

CustomHtmlLogger

04 Aug 2015 Posted by: Comments: 0 In: Allgemein
29 Nov 2014 Posted by: Comments: 0 In: Allgemein

Nachdem ich von meinem mittlerweile uralten Wacom Graphire 3 Studio XL auf ein Wacom Intuos 3 A5 Wide umgestiegen bin, mussten natürlich ein paar Tests her. Meiner Meinung nach gehört dieses Grafiktablet zur solideste Serie, die ich bisher getestet habe.

Hier also mal ein paar Sketches und Materialtests  mit meinem neuen alten Grafiktablet.

 

Golem

Sketches

wooden_planks_0001wooden_planks_0002

 

09 Okt 2014 Posted by: Comments: 0 In: Allgemein, C#, Programming, Unity3D

In diesem Beitrag soll es um Build-Nummern gehen. Es gibt wie immer verschiedene Methoden Software zu versionieren.
Hier ist meine Methode für für Unity-Projekte und so kann es aussehen:

Um automatisch fortlaufende Build-Nummern zu verwenden, lässt sich folgendes machen:

30 Sep 2014 Posted by: Comments: 0 In: Allgemein, C#, Programming, Unity3D

Hi zusammen!

Nahezu alle Spiele haben in irgendeiner Form eine Art von visuellem Log System. Da es mich gestört hat während des Testens in Unity immer wieder in die Konsole zu schauen und dort auch nur drei verschiedene Typen von Logs möglich sind, habe ich mir ein eigenes kleines Log System für Unitys GUI Methode geschrieben. Davon abgesehen, dass es später auch noch sehr sinnvoll in Spielen eingesetzt werden kann um dem Spieler detailierte Informationen über das zu geben, was gerade so passiert und für ihn relevant ist.

Hier also der Code.
Leicht lesbar, einfach gehalten und schnell erweiterbar.

Der Logger:

 

 

Das UI:

 

So wird es benutzt:

 

 

Viel Spass damit 🙂

 

23 Sep 2014 Posted by: Comments: 0 In: Allgemein
01 Jun 2014 Posted by: Comments: 0 In: Allgemein, Unity3D

Für das unity-insider Forum habe ich vor einer Weile ein Tutorial zu einem Character Editor erstellt. Ich dachte es wurde mal Zeit das Ergebniss auch mal auf meinen Bloq zu stellen!

Als Basis wurde der Character Editor aus dem Asset Store benutzt und stark modifiziert, um ihn auch für Nutzer der kostenfreien Unity-Version zur Verfügung zu stellen.
Ursprünglich arbeitete der Editor mit AssetBundles.
Meine Version allerdings nutzt nun Prefabs und verarbeitet Json Strings zum Laden und Speichern der Character Setups.
Schaut euch einfach das Beispiel im Webplayer an. Dort habe ich die kostenfreien Characters von Unity Tech benutzt, die bereits fertig konfiguriert waren.
Natürlich kann man eigene Character verwenden, wenn man sie nach dieser Vorlage bearbeitet. 😉

download

Download Unity Package

Das package enthält ebenfalls das EditorScript für die Erstellung der einzenlnen Character Meshes. Wer es genauer haben will, schaut sich im Forum die Tutorials an!

Viel Spass damit.

30 Mai 2014 Posted by: Comments: 1 In: Allgemein, C#, PHP, Programming, Tutorial, Unity3D

In diesem Abschnitt des Tutorials zeige ich dir, wie du nun die Informationen der API in dein Spiel bekommst.
Natürlich zuerst Unity öffnen und ein neues Script mit dem Namen Slim.cs anlegen.
Dieses Script sieht folgendermaßen aus:

HttpMethod – ist ein enum mit den vier wichtigen Http-Methoden!

ServerUrl – erklärt sich von selbst.

endHelloWorld – hier wird es interessanter. wie bereits am Anfang des Tutorials erwähnt verarbeitet die API url´s.
Die Basis url ist die ServerUrl. An diese wird ein Endpunkt angesetzt. wie im bereits erwähnten Beispiel:

http://localhost/tutorialgameapi/game1/v1/character/Hans oder http://localhost/tutorialgameapi/game1/v1/hello/Hans

Wobei „character/Hans“ oder auch „hello/Hans“ der Endpunkt wäre.

GetHelloWorld(string s) – Testmethode, ruft die „Hello, <name>“-GET-Methode in der API auf.

NewHttpWebRequest –  führt die Request aus!

Der Rest sollte relativ gut lesbar sein!

 

So kannst du das Script testen:

auch dieses mal wird Folgendes zurückgeliefert:

„Hello, Hans“

und

{ “guid”: “1″, “name”: “Hans”, “health”: “100″, “score”: “1000″ }

 

Bis zum nächsten Teil!

Daniel

13 Apr 2014 Posted by: Comments: 0 In: Allgemein, Modelling, Unity3D

Download

Im Asset Store könnt ihr ein kostenloses kleines Asset von mir finden und direkt in eure Spiele einbauen!
Diese einhändige Axt hat 89 Polygone und kommt mit einer 1024² Textur. Viel Spass damit! 🙂

Textur

weapon_axe_1h_0001_2013_12_20

02 Mrz 2014 Posted by: Comments: 0 In: Allgemein, Modelling

Ja, ich mag den Stil der Blizzard Designer sehr, erst recht das Design von „World of Warcraft“. Deshalb habe ich mir ein wenig die verschiedenen Gebäude angeschaut und blieb bei den Häusern von „Gilneas“ hängen. Die Anmutung dieser englischen Häuser brachte mich dazu ein wenig in dieser Richtung zu experimentieren. Die Texturen sind zwar noch nicht gemacht, aber hier gibt es schonmal einmal ein paar Modelle zu sehen.

26 Jan 2014 Posted by: Comments: 0 In: Allgemein, C#, Game Design, Global Game Jam, Modelling, Unity3D

Heute sind wir erst gegen 10 Uhr an den Start gegangen und haben zuerst entspannt gefrühstückt, bevor es wieder richtig zu Sache gegangen ist. Ein paar soziale Interaktionen mit „echten Menschen“ müssen auch mal sein. 😉 Fachgespräche sind natürlich auch dabei, außerdem ist es ja auch interessant was die anderen Teilnehmer auf die Beine stellen!

Da es bei unserer Idee darum geht nur mit Hilfe von Kopfbewegungen die Anwendung zu steuern, musste auch ein passendes Controller-Script her. Dieses wurde heute entwickelt und getestet. Während ich also am Script gearbeitet habe, hat sich Björn um ein paar 3D Modelle gekümmert. Ich war schon überrascht über seinen sehr schnellen Workflow in Silo!
Leider bietet OpenDive nicht alle Möglichkeiten die Oculus Rift bietet, daher sind wir zwar eingeschränkter, allerdings helfen diese Einschränkungen auch dabei ein wenig schneller vorwärts zu kommen. Bevor ich lange weiter schreiben – der Game Jam ruft!

Weiter geht´s!

26 Jan 2014 Posted by: Comments: 0 In: Allgemein, Global Game Jam

Heute sind wir relativ entspannt gegen 10 Uhr an die Arbeit gegangen. Es war zwar nicht mehr viel Zeit bis wir unser „Spiel“ auhf die Seite des GGJ hochladen mussten. Wir sind uns einig, dass wir uns eher an einem Experiement versucht haben, als wirklich ein Spiel zu entwickeln.

 


Hier gibt es nochmal alle Infos zu unserem Experiment auf der GGJ-Seite:

http://globalgamejam.org/2014/games/menschenverschwindenohhhnoooo

 

Hier gibt es noch zwei Artikel von Ratking´s Jana Reinhardt:

http://ratking.de/2014/02/04/global-game-jam-in-leipzig/#beginning

http://leipziggamejam.wordpress.com/2014/02/04/die-spiele-des-global-game-jam-2014-2/

 

An alle die teilgenommen haben: bis zum nächsten Mal 🙂

25 Jan 2014 Posted by: Comments: 0 In: Allgemein, C#, Game Design, Global Game Jam, Modelling, Unity3D

IMG-20140124-WA0000

Björn mit der OpenDive an unserem Projekt

 

Pünktlich 14.30 Uhr stand ich also fertig gepackt, mit Laptop, Iso-Matte und Schlafsack vor meiner Tür und wartete auf meine Mitfahrgelegenheit nach Leipzig. Kalt war´s! Leider war der junge Mann, welcher sich später als angenehmer und witziger Zeitgenosse entpuppte, nich ganz ortskundig in Halle. Nach seiner langen Oddysee durch Halle traffen wir uns dann endlich am Hallmarkt. Schnell das Zeug in den Wagen gepackt und schon waren wir startklar für den GLOBAL GAME JAM, an dem er übrigens auch teilnehmen wollte. Mit leichter Verspätung trudelten wir auch ein und kaum angekommen wurden die ersten bekannten Gesichter begrüßt! Dann ging alles relativ zügig voran – Themenvorstellung, Vorstellrunde. Das übliche Prozedere! Das dauerte auch ein Welchen, denn in diesem Jahr war der Andrang in Leipzig doch wesentlich größer als zuvor – Schöne Sache!
Das Thema war im ersten Moment doch ein wenig seltsam: „We don´t see things as they are. We see them as we are“.
Ich emfand das Thema als spannend und gleichzeitig ein wenig sperrig.
Schon vor dem Start habe ich mit Björn, einem ehemaligen Kommilitonen, über ein mögliches Team geredet. Open Dive war im Gerede und so sollte es auch sein! Also ging´s ans Open Dive Demo angucken, Beispiele testen und Ideen aus den Köpfen quetschen. Um für den Samstag richtig fit zu sein, ging es dann auch verhältnismäßig früh gegen 1.30 Uhr in den Schlafsack und gegen 9.30 Uhr wieder raus.

Weiter geht´s! 😀

21 Dez 2013 Posted by: Comments: 0 In: Allgemein, Modelling

Wenn man so im Flow ist kann man auch direkt weiter machen. Rausgekommen ist eine Axt, dieses Mal als Zweihänder.

Polycount: 244

Polycount: 420

 

 

 

 

 

20 Dez 2013 Posted by: Comments: 0 In: Allgemein, Modelling

„Übung macht den Meister“ heißt es und um im Training zu bleiben kommt hier ein kleines Asset:

 

 

Ziel der Sache war, wie unschwer zu erkennen, ein Lowpoly-Objekt mit „handgemalter“ Textur im Cartoon-Stil. Dafür werden zusätzlichen Maps wie Ambient Occlusion oder Specular Map benutzt. Alles was zu sehen ist, ist eine einfache Diffuse Map. Das gute Stück ist praktisch „game ready“ und kann in einem Videospiel mit entsprechendem Stil verwendet werden!

weapon_axe_1h_0001_2013_12_20

16 Dez 2013 Posted by: Comments: 0 In: Allgemein

Es hat noch geklappt! 🙂
Jana und Friedrich von ratking.de richten den Game Jam in Leipzig aus. Vom 24.01.2014 bis zum 26.01.2014 wird gejammt. Ich habe es noch auf die Liste geschafft und bin nun auf die anderen Teilnehmer gespannt. Scheinbar ist der Game Jam in diesem, bzw. nächsten Jahr sehr begehrt und der Andrang verhältnismäßig hoch.
Infos zur Game Jame in Leipzig gibt aus hier.

04 Dez 2013 Posted by: Comments: 0 In: Allgemein

Lange  hat es gedauert, doch nun ist es endlich geschafft.

Obwohl, eigentlich ging es sehr schnell. Vor ca. 24 Stunden habe ich mich dazu durchgerungen, mich endlich von meiner alten Site, bzw der Website meiner früheren Band „Freispringer“ ( www.freispringer.de leitet jetzt hierher weiter ) zu verabschieden und auf einen neuen Webspace umzuziehen. Es wurde einfach Zeit. Wirklich. Denn ehrlich – wer verbindet dieses Wort „Freispringer“ schon mit einem Menschen, der Multimedia|Virtual Reality-Design studiert hat und dementsprechend im 3D-Bereich unterwegs ist? Was hat freispringer.de schon mit einem Unity3D-Entwickler und Echtzeit-Anwendungen zu tun? Nichts. Um fair zu sein muss man allerdings sagen, dass der Name damals auf die Springerfigur im Schach anspielte. Da nunmal auch Schach ein Spiel ist, könnte man jetzt zwar einen Bogen schlagen, aber das wäre mir dann doch zu weit hergeholt.

Klare Entscheidung: ich brauchte eine neue Seite. Aber wie sollte ich sie nur nennen? Kurz sollte der Name sein.

Nach einigen Überlegungen bin ich nun bei www.3dan.de hängen geblieben. Es steckt einiges drinnen: „3D“, „dan“ für Daniel oder als Kürzel für 3D-Animation. Ein Freund von mir, tätig bei KingArt Games in Bremen, meinte, es würde sich auch lesen wie „3D an!“. Auch schön!

Wie ich bereits geschrieben habe, ging es recht schnell. Nachdem die IPS die Seite übernacht gelistet hatte, war der erste Handgriff schon vor dem Frühstück eine WordPress-Installation auf den Weg zu schicken. Keine 30 Minuten später war alles soweit eingerichtet. WP lief, das Theme stimmte.
Nur den Content in den neuen Blog zu bekommen dauert ein bisschen länger, letztlich ist aber alles angekommen wo es soll und die neue Website ist einsatzbereit.

Tja, was kommt jetzt?

Nunja, ich denke über eine Tutorialreihe für den meinen Blog nach, aber zuvor steht viel Größeres bevor!
Freunde von mir, ebenfalls Alumni der Hochschule für Kunst und Design Halle und ich planen den Start in die Gaming Industry.
Das wird eine wilde Reise werden, soviel ist sicher! Wir werkeln fleißig an Game Design Documents und auch an einem Prototypen.
Mehr will ich dazu noch garnicht verraten.

Schönen Gruß
Daniel

 

22 Nov 2013 Posted by: Comments: 0 In: Allgemein, C#, Programming, Tutorial, Unity3D

Nachdem ein paar Videos über „The Legend of Zelda: A Link Between Worlds“ ein wenig Nostalgie erzeugt haben, dachte ich mir, dass ich doch einen ähnlichen Controller für meine Unity3D Projekte gut gebrauchen könnte, der sich super mit einem Xbox Controller nutzen lässt. Grundsätzlich ist das C# Script nicht sonderlich kompliziert und mit wenigen Zeilen umgesetzt! Dazu kommt noch ein CameraController, der den Spieler verfolgt.
Im Beispiel könnt ihr euch das Ganze mal genauer anschauen!

Hier ist das C# Script für den Spieler, es wird einfach an das Player  Prefab gehängt.

Quick´n´dirty für XInput

 

 

Diesen CameraController einfach an das Player Prefab hängen:

 

10 Nov 2013 Posted by: Comments: 0 In: Allgemein, C#, Programming, Unity3D

Wenn man häufiger Unity Projekte erstellt um kleine Tests zu machen oder doch große Proekte strukturieren möchte, ist es einfach mehr als nervend, wenn diese immer wieder per Hand angelegt werden müssen. Daher habe ich hier zwei kleine Scripte geschrieben, die ab sofort in allen meinen neuen Projekten zu finden sein werden. Mit Hilfer des Codes ist es so möglich einfach im EditorWindow Strukturen anzulegen in dem man beispielsweise schreibt „Scripts/SubFolder/SubFolder2“. Nun muss man nicht mehr tun als es zu speichern und Unity erstellt nun drei ineinander verschachtelte Ordner. Außerdem kann man diese Struktur als txt-Datei speichern und in anderen Projekten laden, modifizieren oder auch Ordner wieder löschen.

05 Nov 2013 Posted by: Comments: 0 In: Allgemein, Modelling

Für das Spiel „Soulbound“ werden hier immer mal einige Asset zu sehen sein.







 

04 Okt 2013 Posted by: Comments: 0 In: Allgemein, C#, Programming, Tutorial, Unity3D

Hallo und willkommen zum zweiten Teil einer kleinen Tutorialreihe rund um das Thema RPG.
In diesem Teil möchte ich euch demonstrieren wie man seinem Character Fähigkeiten gibt.
Dies soll als Basis für ein Kampfsystem dienen. Im Rahmen des Tutorials und der Tatsache, das dieses Gebiet komplex werden kann, wird dieses AbilitySystem natürlich nicht riesig werden und nur die grundlegende Herangehensweise demonstrieren.
Jedoch wird es so angelegt, dass es nach oben skalierbar lässt!
Dieses Tutorial richtet sich eher an Anfänger als an Fortgeschrittene und natürlich auch an Diejenigen, die solche Systeme schon immer interessiert haben. Wie immer ist das Ganze eine von vielen Möglichkeiten ein AbilitySystem umzusetzen.

Legen wir los und definieren erstmal die Fähigkeit. Dafür legen wir uns eine Klasse an:

Soweit so gut, wir haben eine Fähigkeit. Das ging schnell…wir sind fertig 😉 nene…
Diese Fähigkeit wird uns nun als Basis für alle anderen Fähigkeiten dienen, die einem so einfallen könnten.

Damit wir mit dieser Fähigkeit etwas anfangen können, bekommt sie einige Parameter und wir nehmen an, dass diese Fähigkeit Schaden am Gegner verursachen soll.
Ganz im Stile der MMO´s geben wir den Fähigkeiten Abklingzeiten, bzw „CoolDowns“, die bestimmen in welchem Interval die Fähigkeit benutzt werden kann.

Um Fähigkeiten zu nutzen, müssen sie natürlich irgendwie ins Spiel gelangen.
Dazu nutze ich gerne Dictionaries. Sicher mag jetzt der ein oder andere sagen, das man ja auch Lists nutzen kann oder ArrayLists.

Ich entscheide mich jedoch definitiv für das Dict und lasse es folgendermaßen aussehen:

 

Zum Nachlesen:
http://www.dotnetperls.com/dictionary

Dieses Dict kann man jetzt einfach zu seinem CharacterScript hinzufügen ODER wir machen ein neues und nennen es Player.cs

Wichtig: using System.Collections.Generic; ! Sonst wird´s nichts mit dem Dict;)

Der Grund Dictionaries zu verwenden ist einfach der, dass sich auch später wesentlich besser nachvollziehen lässt welche Fähigkeit
gerade wohin geschickt wird etc. alles läuft anhand des Names der Fähigkeit (anstatt einer ID), so dass auch nach wochen noch klar ist,
was eine Fähigkeit ist, warum sie so heißt. Ich für meinen Teil kann mit der Fähigkeit „Mortal Strike“ mehr anfangen als mit der id 6534651 😉
Davon abgesehen nutzen wir eh eine recht übersichtliche Anzahl von Fähigkeiten und nicht 100000.

Um nun endlich die Fähigkeit verfügbar zu machen, muss sie noch ins Dict, das machen wir in der Start Methode.

Damit das noch ein wenig flexibler wird:

Damit es noch etwas schicker wird geben wir der Ability einen Konstruktor mit einigen überladungen mit.

Das sollte reichen für´s Erste, später gibt es hier noch einiges umzustellen, also nicht voreilig werden;)

Jetzt schauen wir nochmal in die Start Methode der Player.cs

Wir können nun natürlich auch mehrere Fähigkeiten on the fly erstellen:

Schnell sollte hier klar werden, dass sich das so auf Dauer nicht so schön bearbeiten lässt und wir Unmengen an Variablen erzeugen.
Eine Lösung werden wir uns später anschauen.

Um nun die Fähigkeit auch mal zu „benutzen“ müssen wir sie noch auslösen.
Auch das passiert in der Player.cs!

Wir erweitern das Script um eine Update Methode, lösen die Fähigkeiten per Tastatur aus und benutzen den CoolDown.

Damit die Abklingzeit wieder zurückgesetzt werden kann (wir wollen ja die Fähigkeit nach Zeit X wieder benutzen )
müssen wir sie noch updaten.

Das Ganze in die Update Methode:

Die Player.cs sollte nun so aussehen:

Soweit, so gut.
Im nächsten Teil kümmern wir uns darum, dass die Abilities und ihre Werte einfacher zu modifizieren sind, ohne sie jedes Mal in der Start Methode neu zu setzen.
Danach integrieren wir ein kleines Kampfsystem in dem wir in der Console ein wenig „Schattenboxen“ um so die Fähigkeiten zu testen 😉

#edit: bugfrei!

Dropbox Link zum Package – ohne jedoch die Herangehensweise zu verstehen bringt es nicht viel;)

Weiter geht´s hier –> rpg-basics-abilities-teil-2 <–

03 Okt 2013 Posted by: Comments: 0 In: Allgemein, C#, Programming, Tutorial, Unity3D

Hi Leute,

ich möche euch gerne zeigen wie man relativ einfach ein kleines Charakterklassen System zaubert. Mit verschiedenen Klassen, Verhalten etc. Ihr kennt diese Systeme sicherlich, denn sie kommen in fast jedem RPG vor. Sicher hat auch jeder schon mal daran gedacht, sowas umzusetzen (oder auch nicht;) ).
Wo wir schon beim Umsetzen sind: natürlich bleibt das Ganze rudimentär und nimmt keine Ausmaße großer MMO´s etc an – aber wenn das System einmal verstanden ist, könnt ihr daraus Einiges machen, wenn ihr wollt.

Zuerst einmal der Ausgangspunkt: angenommen das Spiel hat 3 spielbare Klassen (Warrior, Mage, Priest) und verschiedene NPC´s (Boss, Monster, Merchant). Wie kann man nun vorgehen ohne bestimmte Sachen 6 mal zu scripten? An dieser Stelle kommen wir schon zum ersten Problem, dessen Lösung aber garnicht so schwer ist!

Jetzt kann man sich erstmal die Frage stellen: Was haben diese 6 gemeinsam? Zuersteinmal: es sind „Entitäten“. Aber ein Baum oder ein Haus ist defacto aber auch eine „Entität“ – sie „sind“ (…natürlich nur virtuell).
Ok, sagen wir einfach es sind „Units“. Jede Characterklasse, jeder NPC ist zuerst eimal eine „Unit“. Wie geht es nun weiter in der Hierachie? Ganz einfach: Was haben alle Monster, Bosse oder Merchants gemeinsam? Sie sind NPC´s… und NPC`s wiederum Units.
Und was haben alle Warriors, Mages und Priests gemeinsam? Sie sind spielbare Character… nennen wir sie einfach „Heroes“ und natürlich sind alle spielbaren Klassen vom Typ Hero eine Unit.

So ergibt sich also eine Art Baum …oder eher die Wurzel eines Baumes;)

unbenannt-2v8psl

Bevor es ans Scripten geht, gibt es Dinge, die alle Units gemeinsam haben:
Sie können sich bewegen oder haben zumindest die Möglichkeit es zu tun.
Sie können Attacken ausführen oder andere Fähigkeiten nutzen. Aber bevor jetzt schon über Fähigkeiten nachgedacht wird, bleiben wir erstmal bei der Bewegung und fangen an die Scripte anzulegen.

Diese Basisklasse von der alle Units erben, nenne ich einfach mal Unit.cs und die sieht so aus:

Wie man sieht, ist NPC nicht vom Typ MonoBehaviour, sondern vom Typ Unit. Da aber Unit vom Typ MonoBehaviour ist, vererbt sie diese Eigenschaften und damit kann die NPC Klasse auf alles zugreifen was MonoBehaviour so mit sich bringt und nicht nur das – die NPC-Klasse kann auf alle Variablen zugreifen, die in Unit.cs public sind. Hier könnte man auch internal oder protected nutzen.
Wichtig ist aber, dass alle Variablen und Methoden nicht private sind.
Um das mal zu verdeutlichen nehmen wir als Beispiel noch die guten alten Healthpoints ins Spiel, gehen nochmal in die Unit.cs und machen folgendes:

Getters und Setters zum nachlesen: http://www.dotnetperls.com/property

Nun hat JEDE erbende Klasse den Zugriff auf Healthpoints (aber nicht auf _healthpoints! brauchen wir auch nicht) und kann diese setzen oder anderweitig verwenden, zB. für Healthpoints im GUI.

Damit wir mit den Healthpoints auch was machen können, kann man jetzt noch eine Methode einbauen:

WICHTIG:
Damit auch diese Methode für alle erbenden (bzw. abgeleitete) Klassen verfügbar ist, ist auch sie public.
Nebenbei sparen wir uns das Ganze x mal in jede Klasse zu schreiben… 😉
Bei 20 Methoden und 100 Variablen ist das einiges an Zeitersparnis, vorallem, wenn man änderungen vornehmen möchte;)

Weiter geht´s mit dem Hero Script:

Wie bereits anfangs erwähnt ist auch Hero von Unit abgeleitet.

Nun wird das Ganze noch einmal gesplittet und sieht folgendermaßen aus:

Alles eigenständige Scripts versteht sich.

Die Heroes sehen folgendermaßen aus:

Warum wird das gemacht? So kann man sich die Möglichkeit vorbehalten, dass Heros noch andere Dinge machen können als NPC´s. Diese können dann von Hero zu Hero auch wieder variieren. Das ist natürlich kein Muss, denn eigentlich könnten alle spielbaren Klassen und NPC´s auch direkt von Unit erben. Wir machen es trotzdem;)

Nachdem nun die Klassen klar sind, kommt der nächste interessantere Schritt:

Die Klasse Unit (und damit alle anderen Klassen) wird näher definiert.
Da sich alle Units bewegen können, setzen wir genau dort an und geben ihr die Methode Movement() ohne Uberladung. Wenn man genau schaut und das sollte man in Tutorials ja eh 😉 liest man dort virtual… und genau: die Methode ist leer und das bleibt sie hier auch.

Was genau virtuals sind, könnt hier nachlesen: http://www.dotnetperls.com/virtual
Dort steht alles recht gut erklärt und ich will es nicht zum x-ten Mal wiederholen 😉

Die virtual bringt nun keine Performanceschübe etc. Zum Einen sagt sie, dass alle abgeleiteten Klassen diese Methode überschreiben dürfen, zum Anderen dient sie einfach dazu das „Skelett“ der Klasse genauer zu definieren und Gegensatz zur AdjustHealth-Methode kann kann die Movement-Mehtode für jede Klasse andere Anweisungen abarbeiten! Natürlch kann man die Methode auch dort bereits mit Anweisungen füllen und so eine Standardmethode für alle abgeleiteten Klassen erstellen.

Die 2 nächsten Beispiele zeigen den Gebrauch:

override erklärt: http://www.dotnetperls.com/override

Nun wird dank des overrides die bekannte Methode „überschrieben“ und ausgeführt. Wie gesagt, es bringt keinen echten Vorteil, nur weiß man nach Wochen noch, dass diese Methode bei allen anderen Klassen des gleichen Typs existieren muss, außerdem kommt so mehr Struktur in den Code.

In das Boss-Script schreiben wir nun:

Nun müssten sich Monster geradeaus bewegen (entlang der z-Achse) und Bosse immer im Kreis (entlang der z-Achse um ihre y-Achse)

Alle anderen Klassen machen fürs Erste nichts.

Apropos „machen“ – es wird Zeit en paar Primitive zu nutzen und die Scripte anzuhängen.
Aber nicht irgendwie!!! Nicht einfach Anhängen und los!
Das machen wir eleganter.

Wenn ihr euch ein paar Cubes, Capsules, Cylinder in die Szene gezogen habt, erstellt gleich noch 6 Materialien und benennt sie wie folgt:

None, Boss, Monster, Merchant,Player, Base – gebt ihnen ein paar schickere Farben…rot für Monster und Boss, sowie Grün für das Player Material sind recht sinnfällig. Dem Merchant habe ich ein blau verpasst. None ist pink und Base bleibt weiß.
WICHTIG: legt diese in einen Ordner namens „Resources“ !!! (ohne Anführungsstriche)
Wo dieser Ordner liegt ist egal, hauptsache die Materialien sind dort drinnen.

Danach erstellt ihr noch ein paar Tags – da wären Monster, Boss, Merchant sinnig. (wer hätte es geahnt) Den Player-Tag gibt es ja schon.

Wenn das soweit fertig ist kommt eine State Machine zum Einsatz – eine ganz einfache.
Dafür wird ein neues Script namens CreatureSetup angelegt.
Hängt dieses Script an eure GameObjects – und zwar NUR dieses.

In diesem Script ist auch ein enum, mit welchem wir im Inspector festlegen können zu welcher Klasse unser GameObject gehört (Ich bin so frei und gehe davon aus, dass ihr bereits aus zuvor angelegten Primitiven Prefabs gemacht habt, was nun die Arbeit erleichtern solte)

Schaut euch die GameObjects mal im Inspector an… da lässt sich jetzt myCreatureType einstellen!
Außerdem lassen sich die Healthpoints zu Beginn festlegen.

Wenn nun das Spiel gestartet wird, checkt die State Machine von welchem CreatureType das GameObject ist und hängt das entsprechende Script und Material an, außerdem setzt es gleich den richtigen Tag. Wohin das führt dürfte langsam klar werden… das Setzen von Healthpoints oder das Anhängen eines Talent-Scripts, entsprechend der Unit-Klasse, über diese State Machine steht nun nichts im Wege.

…aber noch sind wir nicht fertig!!!

Angenommen ihr müsst aus einem anderen Script von einem anderen GameObject auf das Klassen-Script zugreifen, hättet ihr vlt ein Problem, wenn diese nicht alle vom gleichen Typ wären!

Denn woher soll nun das Objekt von dem ihr auf eure Ziel zugreifen wollt, wissen welches Script dranne hängt?! Warrior? Merchant oder doch Boss?

Alles halb so schlimm, wir nehmen einfach das Unit-Script!

Nun erstellt ein neues GO in der Szene.
Erstellt ein Script Namens Test und hängt es an das neue GO.

Dieses Script Checkt das Level nach dem Tag „Player“ NACHDEM alle Units ihre State Machine abgearbeitet haben, denn die läuft in der Awake-Methode.
Außerdem „attackiert“ es den Player und zieht ihm 5 Healthpoints ab. Ihr könnt es in der Console nachlesen;)

Alternativ kann man hier auch noch ein switch case nutzen und direkt die am GO angehängte Klasse ansprechen. Wie man sieht ist AdjustHealth auch dort verfügbar!

Der letzte Schritt.
In die Klassen Priest, Warrior, Mage, Monster, Boss und Merchant wird jetzt noch folgendes geschrieben:

Hier nochmal für Faulpelze zum selber gucken (unity 3.5.5 required)

unitypackage

Nächster Teil –> Abilities <-- anlegen und nutzen