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

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 🙂

 

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

25 Mrz 2014 Posted by: Comments: 0 In: C#, PHP, Programming, Unity3D

Auf der Suche nach einer Möglichkeit eine REST API für eigene Spiele zu erstellen, bin ich über das Slim Framework gestolpert.
Das Framework ist in PHP geschrieben und ermöglich einen recht schnellen Start um solche API´s oder auch andere web applications aufzubauen. Es gibt natürlich einige dieser Frameworks. Slim schien mir jedoch genau das Richtige zu sein – es ist schnell, der Einstieg ist recht leicht und außerdem ist es recht gut dokumentiert.

Zuerst stellt sich natürlich die Frage was ist eine REST API, bzw. REST. Hierbei handelt es sich um eine Architektur, die es ermöglicht API´s mit gut lesbaren URL´s zu erstellen.
Sowas sieht zum Beispiel so aus: http://us.battle.net/api/wow/achievement/485

Dahinter steht meistens eine Datenbankabfrage, die dann wie im Beispiel einen Datensatz im Json Format zurückliefert. Dieser Datensatz kann dann in der eigenen App geparst und anschließend verwendet werden.

Letztlich übernimmt das Framework „nur“ das Routing für diese URL´s, denn eigentlich wird eine index.php angesprochen, diese erscheint wie im Beispiel aber nicht in der URL.

Im Wesentlichen werden dabei vier Befehle benötigt:

  • POST
  • PUT
  • GET
  • DELETE

Es gibt zwar noch mehr dieser Befehle, diese sind aber relativ selten im Gebrauch und werden im Moment vernachlässigt. Einige öffentliche API´s lassen auch nur GET Befehle zu, da die Entwickler natürlich die Daten in der Datenbank nur durch das Spielen des Spiel geändert (POST, PUT, DELETE) werden sollen und nicht durch z.B. Anfragen im Browser. Wie im Beispiel oben dienen diese Schnittstellen dann dazu um z.B. bestimmte Daten anderen web applications zu visualisieren.

 

Der Aufbau

Die gesammte API besteht aus der bereits erwähnten index.php und vielen „Controllern“ für die verschiedenen Datenbankabfragen.

Das Projekt kann dann z.B. so aussehen:

Slim_api

 

Die index.php ist (noch) relativ einfach:

Der erste Test der API kann also so erfolgen während Slim nun anhand der url routet:
http://www.yourdomain.com/api/v1/hello/Hans

Rückgabe wäre dann: „Hello, Hans„! Natürlich ohne Anführungszeichen.

 

Wie sieht es aber aus, wenn ich Daten aus einer Datenbank holen oder in irgendeiner Form modifizieren will?

Gehen wir davon aus, dass wir den Character „Hans“ neu anlegen und seine Daten modifizieren, zurückgeben oder löschen wollen.
Dazu benötigt die index.php diese vier Funktionen BEVOR : $app->run(); ausgeführt wird!

Bei drei dieser Funktionen taucht nun authentication auf.
Slim bietet die Möglichkeit eine Middlelayer einzubauen! Das ist großartig um z.B. durch eine Authentifizierung sicherzustellen, dass der Nutzer diese Aktionen auch ausführen darf.
Der GET-Befehl darf immer ausgeführt werden, da dieser ja nur Daten abruft, aber nicht modifiziert. Kann man machen, muss man natürlich nicht.
Also soweit so gut, damit die API nun die Daten die via PUT über den Body gesendet werden „herausfischen“ kann, benötigt es noch eine Funktion namens verifyRequiredParams.
Diese wird mit den „Feldern“ füttert, die sie filtern soll.
In diesem Fall ist es das Feld „data“. Dahinter verbirgt sich ein json String.
Beide Funktionen werden weiter unten im Text beleuchtet!

Um Nun die Daten von Hans abzurufen sieht die url nun so aus:
http://www.yourdomain.com/api/v1/character/Hans

oder auch mit der id von Hans (angenommen Hans ist bereits eingetragen und hat die id 999):

http://www.yourdomain.com/api/v1/character/999

Gibt man das in die Adresszeile des Browser ein, wird standartmäßig der GET-Befehl ausgeführt und man erhält die Daten von Hans, wenn er in der Datenbank vorhanden ist.

Nicht vergessen: dahinter liegt die index.php!
Die eigentliche URL sieht nämlich so aus:
http://www.yourdomain.com/api/v1/index.php

Direkt neben der index.php liegt eine .htaccess-Datei, die dafür sorgt, dass index.php aus der URL entfernt wird. black magic! 😉

Die .htaccess-Datei sieht so aus:

Um nun die Daten vom Character „Hans“ zu bekommen, braucht es noch den „CharacterController“ und der sieht so aus:

Wie man sieht gibt es eine Klasse namens AbstractController, diese übernimmt den Aufbau der Datenbankverbindung:

und greift dabei auf das connect-Script zu:

die config.php sieht dann so aus:

Die verifyRequiredParams Funktion und die sieht so aus:

Da ich das Feld ‚data‘ übergebe, wird genau danach gesucht. $app->request()->getBody() holt den Body, danach wird geparst und ein paar Checks für das Errorhandling gemacht, für den Fall, dass das Feld ‚data‘ nicht vorhanden ist. Wenn irgendwas mit den Feldern nicht stimmt (nicht vorhanden oder falsch benannt), wird Slim gestoppt: app->stop();

Und was macht nun ‚authentication‘ ? Ein sehr tolles Feature von Slim ist die Möglichkeit Middlelayer einzufügen.
Die Funktion ‚authentication‘ soll überprüfen, ob denn überhaupt Daten verarbeitet werden dürfen, indem das Vorhanden sein von Usernamen und Passwort im Header überprüft wird.

Man sollte sich hier sowieso mit einem „ApiKey“ und Ähnlichem absichern und sowas im Vorfeld prüfen oder besser gleich https nutzen!
Für das Beispiel verzichte ich aber erstmal darauf.

Nun hat man so ziemlich alles zusammen was man benötigt und kann neue Controller erstellen (siehe Abb. oben), diese Controller erben natürlich vom AbstractController und werden automatisch in die index.php geladen.

Von dort aus muss, wie im Beispiel, nur eine Instanz erzeugt werden. Slim übernimmt im Hintergrund die „Magie“ beim Routen, während die Datenbankabfragen vom jeweiligen Controller erledigt wird.

So lässt es sich echt schnell entwicklen! 🙂

 

der Unity3D, bzw. C#-Teil

Jetzt muss das Ganze noch mit Unity verbunden werden. Hierfür nehme ich nicht die Unity-eigene WWW-Klasse. Ich persönlich finde, dass sich Coroutinen für solche Angelegenheiten einfach nur bedingt anbieten und sich dazu unter C# nicht als strings zurückgeben lassen. In diesem Fall heißt der unser Verbündeter „HttpWebRequest“. Der nächste Nachteil der Coroutinen von Unity besteht aus dem Fakt, dass sie nur mit POST und GET arbeiten. Ich benötige aber auch DELETE und PUT. Diese kann man in der „HttpWebRequest.methode“ mitschleifen! Um hier den ein oder anderen Workaround zu vermeiden ist in diesem Fall die „HttpWebRequest“-Klasse der klare Sieger! Auch die WebClient-Klasse tut sich hier schwer. Einziger Nachteil ist bis dato, dass ich System.IO nutzen muss. Dies bedeutet, dass der WebPlayer (vorerst) wegfällt, da dieser aus Sicherheitsgründen in einer Sandbox läuft. Das ist auch gut so. 😉

Holen wir die Daten in das Spiel:

 

 

 

Abschließend muss ich sagen, dass ich nicht einen einzigen Blick in die Slim.php werfen musste – die Doku und ein paar kleine Tests haben völlig ausgereicht um die API auf Slim aufzusetzen.

So soll es sein – funktioniert einfach out of the box! Unity3D, bzw. C# verhielt sich anfangs ein wenig sperriger. Hier war ein wenig die „trial and error“-Methode gefragt.

 

Cheers!

Daniel

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!

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! 😀

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.

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