Mittwoch, 27. Juni 2012

Running Man

Als letzte Aufgabe hatten wir das Ziel ein Spiel zu entwickeln, in dem die Spielfigur alleine einen Weg/in eine Richtung läuft und der Spieler die Figur zum Ziel bzw. so weit wie möglich bringt.

Prototyp
Nachdem wir uns auf eine Idee geeinigt hatten haben wir das 2D-Tutorial von Unity3D (http://unity3d.com/support/resources/tutorials/2d-gameplay-tutorial) genommen und dieses modifiziert und mit Juiciness versehen.

Ziel des Spiels ist es, die Figur so weit wie möglich zu bringen. Es gibt 2 Ebenen, wobei immer auf einer der beiden Ebenen eine Falle (in unserem Spiel Kisten, die den Weg versperren) platziert ist, in welche nicht gelaufen werden darf.
Sößt man aber auf solche Kisten, spawnt man wieder am Anfang des Levels und kann es erneut probieren. Man kann zwar einen kurzen Moment darauf reagieren, aber es ist mehr auf Trial & Error aufgebaut.
Daher sollte man sich die Kombination des Weges (z.B.: oben, unten, unten, oben, unten, oben, oben, ......) merken. Es ist also ein Running Man zum Mitdenken.

Running Man
Das Spiel kann man hier probieren: Running Man

Mittwoch, 13. Juni 2012

Juicy Pong

Dieses Mal sollten wir einem Spiel etwas Juiciness verleihen, indem wir es mit diversen Features aufpeppen. Wir haben uns dafür entschieden in Unity3D Pong nachzubauen und es mit einigen Effekten zu versehen, damit das Spielerlebnis deutlich besser wirkt als das typische Pong.

Neben Soundeffekten und Farbeffekten haben wir noch weitere Funktionen eingebaut, die das Spiel lebendiger wirken lassen und somit der Spielspaß gesteigert wird.

Standard Pong

Juicy Pong

Aber am besten sieht und probiert man es einmal selbst aus:
(alle Funktionen werden über die Checkboxen links aktiviert/deaktiviert)
Juicy Pong

Mittwoch, 30. Mai 2012

MoonRover

Dieses mal ging es darum ein Spiel für den MoonRover (www.ptscientists.com) zu entwickeln, das man genau 5 Minuten lang spielen kann. Der echte MoonRover soll dabei für 5 Minuten in einer 10mx10m grossen Halle fernsteuerbar sein.

folgende Steuerungsvarianten sind möglich:
  • direkt steuerbar
  • realistisches Delay von 3 Sekunden

Zur Steuerung sollten lediglich Tastatur und Maus verwendet werden.

Nach einem intensiven Brainstorming, bei dem versucht wurde eine möglichst kreative und spannende Idee zu generieren, welche die Anforderungen erfüllt haben wir uns für folgende Spielidee entschieden.
Ziel des Spiels ist den Mondroboter durch das Gelände zu steuern um Schilder einzusammeln. Nach 2 Minuten tauchen plötzlich Aliens auf, welche den Roboter beschießen. Diesen Schüssen soll man versuchen auszuweichen. Wird man getroffen verliert man eines der gesammelten Schilder wieder. Fährt man ein Alien um bekommt man wieder ein Schildzurück. Besitzt man kein Schild mehr fährt der MoonRover nur mehr sehr langsam. Zum Schluss hat man noch eine Minute Zeit den Rover zu einem Zielpunkt zu bewegen, bevor das Spiel endet.

Das Spiel wurde in Unity3D entworfen. Wir haben eine mondähnliche Landschaft in einer ca. 10mx10m große Box erstellt und diese mit einer Minimap erweitert, um die Übersicht zu erhöhen.

Unity3D Editor: Die Mondlandschaft

Man steuert den MoonRover mit den Pfeil- bzw. WASD-Tasten. Um den Benutzer entscheiden zu lassen, ob er im normalen Modus oder im Realitymodus mit 3 Sekunden Latenzzeit spielen möchte, haben wir die Möglichkeit eingebaut mit Drücken der Taste "m" zwischen diesen Modi zu wechseln.

Da der echte Rover über frei drehbare Räder verfügt haben wir auch einen Modus eingefügt, mit dem man "strafen"/seitlich fahren kann. Diesen aktiviert man durch drücken der Taste "x".
Man sieht die Landschaft aus der First Person-Perspektive, da beim realen Roboter die Kamera ebenfalls vorne auf der Oberseite des Roboters angebracht sein wird.

Spielbildschirm mit Minimap und einzusammelndem Schild
Spielbildschirm mit Aliens und Projektilen



Da unser Spiel aus mehreren kleinen Aufgaben besteht wirkt es abwechslungsreich und füllt die geforderten 5 Minuten gut und spannend aus.

Mittwoch, 23. Mai 2012

Play Ludwig

Diesmal hatten wir die Aufgabe eine iPad Steuerung für das Spiel "Ludwig" zu konzipieren.
Dies gestaltete sich aber schwieriger als erwartet, da doch einige Hürden von Apple eingebaut sind, um ein App zum Testen auf das iPad zu bekommen.

Ludwig ist ein Physikspiel zum Thema erneuerbare Energien, welches derzeit für Windows PCs verfügbar ist.


Um das Spiel auch auf dem iPad vertreiben zu können, gilt es, ein auf iPads angepasstes Steuerungskonzept zu integrieren. Ziel dieser Aufgabe ist es, mögliche Steuerungskonzepte zu entwickeln und diese, mittels in Unity erstellten Prototypen, zu testen.

Theoretische Herangehensweise:
Jedes Gruppenmitglied hat sich selbstständig Steuerungskonzepte überlegt, sollte sie in Unity umsetzen und mittels XCode auf einem iPad testen. Danach wird ein Konzept (oder eine Kombination aus mehreren Konzepten) ausgewählt, in der Gruppe verbessert und präsentiert.

Prakitsche Herangehensweise:
Um die erdachten Steuerungskonzepte umsetzen zu können, muss einmal ein funktionierendes Setup aus Unity und XCode geschaffen werden, was alles andere als einfach ist. Trotz etlicher Versuche haben wir es nicht geschafft, ein Unity Projekt über XCode auf ein iPad zu transferieren. Wir konnten somit keinen Prototypen am iPad testen, möchten aber dennoch das entstandene Endkonzept vorstellen.

verworfene Konzepte

Die zuerst entwickelten Steuerungskonzepte bauten auf Basis der Kippbewegungen und Sensoren im iPad auf.

Alternative 1:

Die Kamera dreht man durch einen Schwenk.
  • Schwenken des iPads nach links -> Kamera fährt nach links
  • Schwenken des iPads nach oben -> Kamera fährt nachoben
  • .....
Die Bewegung funktioniert wie die Kameradrehung, nur drückt man rechts unten auf den "Bewegen"-Button.

Alternative 2:

Das Laufen aktiviert/deaktiviert man über das Kippen des iPads, Springen durch Schütteln. Die Laufrichtung könnte durch einen Finger am Display reguliert werden. Je nachdem in welche Richtung der Finger zeigt, in diese Richtung läuft Ludwig (links-rechts).

Es könnte einen Button für den Turbo geben, um das schnelle Laufen zu ermöglichen - er kann aktiviert oder deaktiviert werden, muss also nicht die ganze Zeit gedrückt werden.

Beim anklicken des Map Symbols würde ich die Map bildschirmdeckend vergrößern, damit man wirklich einen Überblick über die Welt hat.

Das Interface ist ähnlich wie jetzt aufgebaut, da alle Maus-Operationen ja auch mit dem Finger ausgeführt werden können.

Bei manchen Operationen(Labor) könnte es aber zu Problemen mit der Genauigkeit kommen.

Zum Schwenken der Kamera gibt es einen eigenen Modus, in dem man das iPad beliebig schwenken kann, um sich Überblick zu verschaffen.

Alternative 3 und 4:

Diese waren sehr ähnlich und wurden dann mit guten Features der verworfenen Alternativen zu einem Endkonzept vereinigt.

Endkonzept

Prinzipiell war die erste Idee, dass Ludwig gesteuert wird, indem man das iPad kippt/bewegt, also über die eingebauten Sensoren. Da es sich hierbei aber um ein Spiel handelt, welches sicherlich länger am Stück gespielt wird oder man einfach mal im Liegen spielen möchte und dies sonst auf Dauer zu mühsam bzw. ermüdend gewesen wäre, würde diese Idee wieder verworfen und eine Alternative entwickelt.

Die Steuerung funktioniert hier, indem man am Bildschirm einen Bereich antippt und Ludwig geht zu diesem Punkt (er folgt der Bildschirmberühung). Der Bereich des Spiels am Bildschirm ist im Breitbildformat. Ober- und Unterhalb des eigentlichen Spielfensters sind 2 Bereiche offen, in denen Einblendungen für Quests, die Karte, Benachrichtigungen, etc. angezeigt werden. Dies soll dazu dienen das eigentliche Spielfenster relativ "sauber" zu belassen und so die Übersicht zu steigern. Weiters bekommt man keine Probleme beim Berühren des Spielfensters zum Steuern.

Spielfenster ohne zusätzliche Anzeigen
 Es werden einzig die 3 Buttons links unten immer eingeblendet. Alles drei Buttons sind zum aktivieren bzw. deaktivieren, sprich man drückt darauf und die Einstellung verschwindet erst wieder, wenn der Button wieder berührt wurde.

Beim Berühren des Buttons unten in der Mitte des Bildschirms springt Ludwig. Kommt Ludwig bei einem Teil vorbei, welches er Benutzen oder aufheben kann wird dieser Button zB. durch den Button "Holz aufheben" ersetzt.

Der Button ganz links im Bild ist der "Kamerabutton". Aktiviert man diesen Modus, so kann der Benutzer das iPad schwenken und sich so in der Gegen umsehen, als sehe er durch ein virtuelles Fenster. Die Steuerung wird hier von den eingebauten Kippsensoren übernommen.

Spielfenster mit eingeblendeten Anzeigen
Der mittlere Button aktiviert den Übersichtskameramodus. Dieser wird im normalen Spiel mit der Taste "C" aktiviert. Hierbei zoomt die Kamera heraus und man kann sein näheres Umfeld besser überblicken.

Spielfenster im Übersichtskameramodus
Der rechte Button aktiviert den Turbomodus, bei dem Ludwig zwar mehr Energie verbraucht, sich aber dafür auch schneller bewegt. (im Spiel durch halten der Taste "Shift").

Alle restlichen einblendbaren Funktionen können durch Berühren der jeweiligen Buttons im Bild ein- und ausgeschalten werden. Der Rücksack wird geöffnet, indem man Ludwigs Rücken berührt.

Sonntag, 6. Mai 2012

Fallen

Bei dieser Aufgabe mussten wir zum Verb "Fallen" ein Spiel entwickeln. Wir haben uns für Unity 3D entschieden um unsere Idee umzusetzen.

Bei dem Spiel geht es darum einen Dummy die Stiegen hinunter zu stoßen. Je öfter er mit diversen Körperteilen aufschlägt desto mehr Punkte bekommt man.

Steuerung: Man zieht mit der Maus von links nach rechts. Je schneller man diese bewegt, desto härter wird der Dummy gestoßen. Es ist dabei aber wichtig nicht zu schnell zu werden, damit man ihn auch oft genug aufschlagen lässt, bevor er am Boden ankommt.
Hat man seine gewünschte Geschwindigkeit "eingestellt" drückt man die Leertaste und der Dummy wird die Treppe hinunter gestoßen.

zum Spiel: Stiegenschubser

Mittwoch, 25. April 2012

Super Mario Wars

 Ziel dieser Aufgabe war es mit einem Spiel, welches über einen Leveleditor verfügt ein Level zu bauen, welches man im Multiplayer spielen kann. Es war gefordert, dass ein Spiel in ca. 3-5 Minuten vorbei sein sollte.


Zuerst mussten wir uns ein Spiel aussuchen. Nach kurzer Überlegung und Diskussion, ob wir den Age of Empires, Worms Armageddon oder den Super Mario Leveleditor nehmen haben wir uns für Super Mario entschieden.




Nun mussten wir uns mit dem Leveleditor, der zwar nicht allzu schwer zu bedienen ist, aber trotzdem für uns alle neu war, vertraut machen. Danach haben wir unabhängig von einander Levels erstellt und uns diese gegenseitig zur Verfügung gestellt. Nach einigen Testsspielen entschieden wir uns für das Leveldesign, das den meisten Spielspaß brachte.



Anschließend haben wir das Spiel mit Freunden, Mitbewohnern und Geschwistern getestet und erhielten durchwegs positives Feedback, aber auch teilweise Kritik in Form von Verbesserungsvorschlägen. (z.B.: Lücken schließen im Wolkenlevel, damit man nicht mehr durchfallen kann.)

Nach Einfließen der Verbesserungen wurde diese nochmals getestet, für gut befunden und somit hatten wir unser fertiges Mutliplayer-Level. Und man kann sagen was man will, aber Super Mario macht immer Spaß.


Hier noch der Link zur offiziellen  Downloadseite des Spiels:
Super Mario Wars
und der Link zu unseren erstellten Levels (inklusive verworfener Entwürfe):
Maps  (diese kopiert man einfach in den "maps"-Ordner des Spiels)

Sonntag, 15. April 2012

Trackmania

Ziel beim Erstellen der Levels war ein neues "Streckenteil" einzuführen, dem Spieler die Bewätigung einfach zu zeigen und es dann in anderen Varianten in immer schwerer werdenden Strecken einzubauen.


Beim Levelpack "Hangtime" wird ein Element verwendet, bei dem der Spieler mit ausreichend Geschwindigkeit die Wand entlang fährt, da die Strecke auf gerader Linie unterbrochen ist. In den folgenden Levels ist das "Hangtime"-Element in eine etwas anspruchsvollere Strecke eingebaut, danach muss der Spieler sogar eine Kurve an der Wand entlang fahren und zum Abschluss ist das Element in eine lange Strecke mit anderen bekannten Elementen eingebaut. Außerdem muss der Spieler zusätzlich zum Durchfahren der Kurve noch an Höhe gewinnen, da die Strecke weiter oben fortsetzt und es wurde auch noch ein Looping eingebaut, bei dem man die Spur wechseln muss, da man bei normalem Durchfahren hinunterfallen würde.

Das Element wurde also anfangs leicht erklärt und stetig erweitert und schwerer gemacht. (gerade Wand; in Strecke eingebaut; Kurve fahren; Kurve mit Höhenanstieg und Looping mit Spurwechsel)

Die Levelfiles kopiert man einfach in
 C:\Users\"Benutzername"\Documents\TrackMania\Tracks\Challenges\My Challenges