Category

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

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

20 Apr 2014 Posted by: Comments: 1 In: C#, PHP, Programming, Tutorial, Unity3D

In Teil 3 werde ich dir zeigen wie du die Daten vom Character „Hans“ aus der Datenbank abrufen kannst.

Bevor das passiert, nochmal eine kurze Zusammenzufassung darüber was im Projekt aktuell funktionieren sollte:

  • Die Programme sind installiert und laufen
  • Das PHP Projekt ist angelegt
  • Slim ist an seinem Platz im libs Verzeichnis
  • Der erste Test hat ein „Hello, NAME“ zurückgeliefert
  • Die Datenbank tutorialslim ist angelegt
  • Die Tabelle characters ist angelegt
  • die Spalten in der Tabelle wurden angelegt
  • Character „Hans“ ist als Datensatz in der Datenbank angelegt

Das ist soweit schon ganz gut.

Im nächsten Schritt werden wir die Daten aus der Datenbank ziehen und im Browser als json string anzeigen lassen.

Dazu erstellst du nun ein PHP Script namen AbstractController.php und speicherst es in das controller Verzeichnis.
Dieses Script sieht nun so aus:

 

 

Von diesem Script erben alle Controller-Scripts später. Die Idee dahinter ist schlichte Vererbung von Funktionalitäten innerhalb der Klassen. Ein Beispiel dafür ist das Verbinden zur Datenbank, die nun durch alle erbenden Klassen ganz simpel erfolgen kann. Das zeige ich dir direkt am nächsten Script, denn dieses wird alle Aufgaben rund um die Character-Daten erledigen.

 

Das StatusController-Script kommt, wie alle Controller-Scripts, ebenfalls in das controller-Verzeichnis.  Dieses Script sorgt dafür, dass du einen String in Json Format vom Server zurück erhälst, der den Fehler-Code und eine Nachricht enthält.

 

Erstelle jetzt ein neues Script mit dem Namen CharacterController.php und speichere dieses ebenfalls im controller Verzeichnis.

Das CharacterController-Script:

 

 

Nun muss noch die index.php modifiziert werden und sollte so aussehen:

Wenn du nun alles richtig gemacht hast und du

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

in die Adresszeile deines Browsers eingibst, sollte folgendes zurückkommen:

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

 

Das Repo zum Projekt: https://bitbucket.org/AgentCodeMonkey/tutorialslimapi

Cheers!

Daniel

Weiter mit Teil 4

20 Apr 2014 Posted by: Comments: 1 In: C#, PHP, Programming, Tutorial, Unity3D

Weiter geht´s mit Teil 2 des Tutorials!

Bis hierher brauchtest du noch keinen Zugriff auf die Datenbank. Da dies aber geplant ist, musst du zuerst deine Datenbank startklar machen.

Dabei gäbe es zwei Varianten:
Variante 1: Erzeugen der Datenbank durch Code.
Variante 2: HeidiSQL.
An dieser Stelle tendiere ich selber eher zu HeidiSQL, weil es komfortabler ist.
Aber vielleicht ist es für dich auch interessant zu sehen wie man diese Dinge mit Hilfe von eigenem Code bewerkstelligen kann. Für die spätere Administration des Daten nutze ich dann aber definitiv HeidiSQL.
Bevor ich zur ersten Variante komme, erzeugst du ein Script, welches du definitiv brauchen wirst!

Dieses Script heißt config.php. und kommt in den include Ordner.

Wozu dieses Script dient sollte sich recht schnell erschließen.
Variante 1

Wenn du Variante 1 nutzen willst, dann erstellst du ein PHP Script und nennst es dbconnect.php.
Auch dieses Script kommt in den include Ordner.

Variante 2
In dieser Variante erstellst du die dbconnect.php nur mit den folgenden Zeilen, speicherst es im include Ordner und folgst der Anleitung im Video unterhalb des Scripts:

 

Öffne HeidiSQL und verbinde dich mit der Datenbank. Wer nicht mit HeidiSQL arbeiten möchte und lieber PHPMyAdmin oä. nutzt, muss sich aus dem Video die einzelnen Schritte ableiten.

Richte dort eine Datenbank namen tutorialslim ein, dazu folge dem Video.

In der nächsten Runde geht es darum die Daten aus der Datenbank zu holen.

Das Repo zum Projekt: https://bitbucket.org/AgentCodeMonkey/tutorialslimapi

Cheers

Daniel

Weiter zu Teil 3

 

20 Apr 2014 Posted by: Comments: 0 In: C#, PHP, Programming, Tutorial, Unity3D

Hallo und willkommen zu meiner Tutorialreihe zum Thema Unity3D und Slim Framework.

In diesem Tutorial möchte ich dir zeigen wie du recht schnell mit Hilfe des Slim Frameworks eine API oder einen Web Service für dein Unity3D Spiel erstellen kannst.
Serverseitig benutze ich dabei PHP, denn das Slim Framework ist in PHP geschrieben.
Der Client, bzw. das Spiel nutzt C# .
Bevor ich begonnen habe dieses Tutorial zu schreiben, habe ich mich selbst durch ein Tutorial gearbeitet und daraus bestimmte Dinge für mich abgeleitet. Dieses Tutorial hat zwar nichts mit Unity zu tun, beleuchtet aber die Funktionsweise von Slim.  Falls es dich interessiert – zu finden ist dieses Tutorial hier:
http://www.androidhive.info/2014/01/how-to-create-rest-api-for-android-app-using-php-slim-and-mysql-day-12-2/

 

Was soll erreicht werden?

  • Zugriff auf eine Datenbank durch eine Unity App.
  • Erstellen/Abrufen/Modifizieren/Löschen von Daten in einer Datenbank über einen Web Service.
  • Die API soll auch für andere Plattformen funktionieren. (Android/iOS Apps)
  • …soll Daten im json Format zurückliefern.
  • …soll leicht erweiterbar sein.

 

Was wird benötigt?

  • Unity 3D
  • MonoDevelop oder Visual Studio
  • NetBeans – eine starke IDE für PHP – Würde ich an dieser Stelle empfehlen! Ein anderer Editor tut es natürlich auch.
  • XAMPP, WAMP oä – Apache Server, Datenbank etc.
  • HeidiSQL – kostenloses Tool zur Datenbankmodellierung – alternativ: PHPMyAdmin
  • Ein wenig Umgang mit Unity3D, C# und/oder PHP oder zumindest irgendeiner anderen Scriptsprache

Meine Wahl fällt übrigens auf XAMPP, bei WAMP kann ich leider keine Hilfe anbieten, sollte es dort Probleme geben.

Außerdem gehe ich davon aus, dass zumindest Unity3D und MonoDevelop oder Visual Studio installiert sind.

 

Das Tutorial ist grob in zwei Bereiche geteilt:

Die Erstellung des Web Service/API in PHP und die Erstellung des Clients in C#.

Ich beginne mit dem Web Service und dessen Vorbereitung.

 

1. XAMPP

Wenn du XAMPP bereits installiert hast, kannst du diesen Schritt überspringen und startest den Apache und das MySQL Modul.

Installiere die aktuelle Version von XAMPP auf deiner Maschine.
https://www.apachefriends.org/de/index.html

  1. Starte das Control Panel.
  2. Im Control Panel:
  3. Starte das Apache Modul
  4. Starte das MySQL Modul
  5. Schließe das Panel, es läuft im Tray weiter.
  6. Öffene im Browser die URL http://localhost oder einfach nur localhost
  7. Folge den Anweisungen – Sicherheitscheck etc.
  8. wenn alles ok ist, …ist alles ok 😉

 

2. HeidiSQL

Wenn du HeidiSQL bereits installiert hast, kannst du diesen Schritt überspringen und öffnest HeidiSQL oder deine Alternative.

Installiere die aktuelle Version von HeidiSQL auf deiner Maschine.
http://www.heidisql.com/

  1. Starte HeidiSQL
  2. HostName/IP ist: localhost oder 127.0.0.1
  3. trage Nutzer und Passwort in die vorgesehenen Felder ein. Diese Daten hast du bereits beim Absichern von XAMPP erstellen müssen!
  4. HeidiSQL offen lassen 😉

 

3. NetBeans

Wenn du NetBeans bereits installiert hast oder nicht nutzen willst, kannst du diesen Schritt überspringen und öffnest NetBeans oder deine Alternative.

Installiere die aktuelle Version von NetBeans auf deiner Maschine.
https://netbeans.org/downloads/index.html

…natürlich die Version für HTML 5 und PHP…oder gleich für alles. Das ist Geschmackssache. Ich nutze nur die PHP Version – das reicht mir.

 

4. Der Web Service

So sollte es am Ende aussehen:
tutorial_slim

libs – alle third party libraries kommen hier hinein. z.B. Slim
include – Helferklassen kommen hier hinein (config.php)
index.php – ist für die API Requests zuständig
htaccess – regelt die API Struktur
model – beinhaltet bestimmte Klassen, die als blue print, bzw. Model dienen
controller – beinhaltet später alle Scripte, die die Zugriffe auf die Datenbank ausführen
v1 – v1 ist die gängige Abkürzung für “Version 1” – hier drinnen liegt die index.php, die später aufgerufen wird!

Lade das Slim Framework herunter.
http://www.slimframework.com/

Gehe zum Verzeichnis /xampp/htdocs/.
Im Verzeichnis htdocs legst du ein neues Verzeichnis an: tutorialgameapi.

innerhalb von tutorialgameapi legst du 3 neue Ordner an:

  • libs
  • game1
  • game2

In den Ordner libs entpackst du das herunterladenen Slim Framework.
Das muss so aussehen:

libs

  • Slim
  • test
  • index.php
  • …das ganze andere Zeug was dort drinne ist.

Warum du es dort ablegen solltest liegt auf der Hand: falls noch andere Web Services (game2) auf dem gleichen Server können diese alle auf den gleichen Code zugreifen und die Wartung ist ebenfalls einfacher.

 

In NetBeans legst du nun ein neues PHP Projekt an, vergibst einen Namen und nutzt das tutorialgameapi als Projektordner, klar. Nimm gleich die höchste PHP Version, aktuell 5.5.

Das Default Encoding steht auf UTF-8.
Das Projekt läuft natürlich als “Local Web Site” und die Projekt URL sieht so aus: http://localhost/tutorialgameapi/

Soweit so gut.

Im game1 Ordner legst du nun vier neue Verzeichnisse an

  • controller
  • include
  • model
  • v1

5. Die index.php

Im v1-Verzeichnis erstellst du nun eine index.php
Der Inhalt des Scripts ist natürlich so ziemlich identisch zum Code des „Hello, World“-Beispiels in den Slim Docs. 😉

Bevor du das Script testen kannst komme ich direkt zur Besonderheit dieser API´s:
die index.php taucht in der angesprochenen url nicht auf! Damit können besser lesbare URL´s erstellt werden und damit das klappt brauchst du diese kleine .htaccess-Datei.
Diese liegt direkt neben der index.php im v1-Verzeichnis und macht ein wenig “black magic” 😉

Das reicht erstmal. Zum Testen öffne http://localhost/tutorialgameapi/game1/v1/hello/Hans im Browser.

Damit wäre bereits der erste und grundlegende Schritt im PHP Projekt getan! Alles was jetzt kommt, baut auf diesem Prinzip auf.

Das Repo zum Projekt: https://bitbucket.org/AgentCodeMonkey/tutorialslimapi

 

Cheers!

Daniel

Weiter zu Teil 2

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:

 

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

05 Sep 2013 Posted by: Comments: 0 In: Allgemein, C#, Game Design, Programming, Tutorial, Unity3D

Hallo zusammen,

Beim letzten Mal haben ich ja gezeigt wie man seine Fähigkeiten mit einem „Cooldown“ versehen kann. In dieser Runde werde ich euch zeigen, wie man grundlegend ein Kampfsystem angehen kann. Dabei sei wie immer gesagt, dass es sich um das Prinzip handelt und das Ganze natürlich weiter ausgebaut werden kann (und muss).

Ziel ist es am Ende zwei Testattacken nutzen zu können, die mit einem Cooldown versehen sind. Diese Attacken machen anhand von unterschiedlichen Charakterwerten Schaden am Gegner. Dinge wie Animationen und der damit verbundene Zeitversatz zwischen Auslösen der Attacke und der verzögerten übermittlung des Schadenswertes werden komplett vernachlässigt.(der Schaden sollte ja nicht schon am Gegner abgezogen werden, während der Angreifer erst zum Schlag ausholt)

Wer das Tutorial nachvollziehen möchte, sollte vorher Teil 1 und Teil 2 gemacht haben.

Zuerst einmal müssen wir klarstellen, wen wir angreifen. Dafür erweitern wir das Player.cs ganz simpel um

.

Cool sind auch ein paar klassische RPG-Werte mit denen man arbeiten kann. Die kommen ebenfalls in die Player.cs

AttackStat ist ein enum und sieht folgendermaßen aus:

schreibt es im Script üBER die Player-Klasse in Player.cs. Enums eigenen sich für solche Dinge recht gut, da sich hier ein definierter Name und ein Wert an einer Stelle speichern lassen.

Außerdem muss noch die Start Methode angepasst werden und wird um folgende Zeile erweitert:

Für ein Kampfsystem brauchen wir natürlich noch: Attacken. Was sind Kämpfe schon ohne Attacken?! 🙂

Dafür legen wir eine neues C#-Script an und nennen es Attack

Dieses Script dient als Basisklasse und natürlich können spezielle Attacken davon erben. Für den Anfang reicht aber dieses eine Script.

Um die Attacken nutzen zu können legen wir nun noch eine Variable in der Player.cs an

und initialisieren sie in der Start Methode mit

Jetzt kann zwar eine Instanz von Attack erzeugt werden, aber was sollte da mit schon passieren? es braucht noch eine kleine Methode und ein paar Variablen.

Was genau ist DoDamage und GetStatValue?

Ersteres ist nichts anderes als eine einfache Methode, die unsere Healthpoints in Player.cs bearbeitet:

GetStatValue sieht folgendermaßen aus:

Um das Ganze zu vereinfachen gibt GetStatValue anhand des AttackStat dessen Wert zurück. Hier wäre Platz für Formeln, oder besser noch ein Aufruf eines Scripts, das aus dem AttackStat einen neuen Wert wie AttackPower berechnet und zurückgeben kann! In unserem Fall ist es nur der Strength-Wert, also 10.

Wenn also der Attacker seine Attacke auslöst, wird in der Attack-Klasse anhand dessen Werte berechet, welchen Schaden der Defender (der Angegriffene/Verteidiger) bekommt. Auch hier lässt sich noch viel machen, zb. um den Schaden anhand eines Wertes des Defenders zu verringern.

Soetwas kann dann so aussehen: (bitte nicht in das Script einfügen)

DamageReduce muss dann jedoch im enum angelegt werden und natürlich initialisiert werden!

Damit die Attacken nun bei Knopfdruck aktiviert werden, bzw die Schadenswerte auch an den Defender übermittelt werden, muss die attack-Methode ausgelöst werden.
Dies geschieht in Player.cs, in der Update-Methode und zwar dann, wenn der Knopf gedrückt wurde und der CoolDown bei 0 ist.

wir übergeben „this“, also die Player.cs aus der die Attacke ausgelöst wird, das Player.cs-Script des Ziels, den Modifier der Fähigkeit und den Wert, der die Attacke beeinflusst.

Gleiches gilt für die andere Attacke:

Nun Geht es an Testen und dafür kopieren wir das GameObject des Spielers und nennen es Defender. Für die Qick and Dirty Variante habe ich anfangs drei bools in die Player.cs genommen:

stellt diese im Inspector beim Player auf: useAbilities = true; showHealth = false und showCooldowns = true;

Beim Defender stellt alles auf false, bis auf showHealth, das sollte true sein,

Die OnGUI-Methode muss nun noch angepasst werden, denn sonst sehen wir ja nichts.

Nun muss beim Player der Defender in den GameObject-Slot des Inspector gezogen werden und andersherum, damit wir auch ein target haben.

Nun sollte dem Defender Healthpoints abgezogen werden, wenn man die Attacken ausführt 🙂

Hier der Dropbox-Link. zur aktuellsten Version 1_7

Und viel Spass beim erweitern dieses Systems 🙂

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

Hallo zusammen!

Weiter geht es mit dem AbilitySystem. Wir nehmen ein paar kleinere Änderungen vor, die uns das Leben als Spieleentwickler erleichtern werden. Da ich in Teil 1 bereits erwÄhnt habe, dass wir unsere Abilities überarbeiten werden und auf eine andere Art und Weise laden.
Die Variante, die mir persönlich am meisten zusagt, ist die der ScriptableObjects.

Was genau das ist kann man hier im Forum in diversen Tutorials erfahren, zB. hier! Daher will ich uns nicht lÄnger damit aufhalten ScriptableObjects zu erklÄren, sondern wie wir sie in der Praxis für unsere Abilities nutzen. Diejenigen, die ScriptableObjects bereits kennen werden eine Ahnung haben was nun passieren wird;)

Zuersteinmal verÄndern wir unsere Ability Klasse geringfügig:

Wichtig ist, dass wir die UnityEngine Bibliothek einbinden, sonst wirds nichts mit dem ScriptableObject. Außerdem erbt Ability jetzt von ScriptableObject. Auch das ist wichtig.
Außerdem ist die Klasse nun serialisierbar… auch hier: was genau das bedeutet ist bereits in Tutorials abgedeckt. Siehe hier!

Die Idee ist nun folgende: ScriptableObjects lassen sich im Projekt als Assets ablegen, Ähnlich wie Prefabs. Dies ermöglicht uns einfach den Unity DragnDrop Workflow beizubehalten um so die Assets zu kopieren und zu verÄndern. Damit lassen sich in kürzester Zeit x Abilities erstellen, ganz ohne dass wir jedes mal eine neue Klasse anlegen müssen etc. Die Designer werden sich freuen!

Wie erstellt man nun dieses Asset? Auch dazu gibts ausführlicheres im Forum (Siehe Link oben) und ich spare mir die Details. Wir benötigen auch nur ein kleines Script, das alles weitere über die Hierachy gemacht werden kann ohne einen großen Manager zu erstellen etc. Für den Anfang reicht das auch.

Das Script:

ACHTUNG: die Ordnerhierachie müsst ihr schnell selber erstellen UND dieses Script muss in einen Ordner namens Editor! Also den auch noch schnell erstellen.
Im Menu erscheint nun ein weiterer Punkt, unter dem ihr Create/Ability findet.
Ist die Ordnerstruktur korrekt, sprich der Pfad zum Zielordner, könnt ihr nun per Klick ein Asset erstellen. Dieses Asset kann nun umbenannt werden.
Nennen wir es wieder „Mortal Strike“ und wie ihr schon seht lassen sich diverse Variablen per Inspector einstellen.
_name : Mortal Strike
_coolDown : 1,3
_damageModifier : 1,5

Danach gibts Copypasta – einfach das Asset anklicken und Strg + D .
Jetzt noch umbennen, einstellen:
_name : Heroic Strike
_coolDown : 3.0
_damageModifier : 2,2

Wir haben nun 2 Abilities und auf diese Weise noch x Andere machen! Schnell und einfach.

Was wir nun noch machen müssen: Abilities laden und zwar nur anhand (ich erwÄhnte es eingangs) an ihrem Namen!

Dafür gehen wir wieder in die Player.cs und modifizieren 2 Dinge:

und folgendes

:

Jetzt noch die Abilities im Inspector ins abilityInit ziehen.

Tada!

Weiter geht´s im nächsten Teil!

Dropbox Link