1926050

Diese Prüfung wird nicht mehr angeboten.
 

Nummer	1926050
Studiengang	Interaktive Medien (IAM 2006)
Modul	Multimedia-Anwendungen
Lehrveranstaltung	Multimedia-Anwendungen/Programmierung
Alternativname	Multimedia-Programmierung, MMProg
Kürzel	i4.MM
Prüfer
Zweitprüfer
Prüfung	Diese Prüfung wird nicht mehr angeboten.
Prüfungsart	Studienarbeit, Präsentation
Details
Hilfsmittel

Termine

• 2.10.2015: Anmeldung zum Kurs (https://moodle.hs-augsburg.de/course/view.php?id=1171) und Nennung der RZ-Kennung
• 11.10.2015: Abgabe von Thema und Grobkonzept für die Studienarbeit (via Moodle)
• 21.-23.10.2015: Zwischenpräsentationen der Studienarbeit (via Praktikum)
• 1.11.2015 Vollständige Abgabe der Studienarbeit einschließlich einer Erstellungserklärung (via Moodle und SVN)
• 4.11.2015: Prüfungspraktikum
• 5./6.11.2015 November: Präsentation der Studienarbeiten

Studienarbeit

Als Teilnehmer der Lehrveranstaltung „Multimedia-Anwendungen/Programmierung“ (MMProg) sollen Sie nachweisen, dass Sie in der Lage sind, eine interaktive Web-Anwendung mit Hilfe von HTML 5 und JavaScript (ECMAScript 5) zu erstellen.

Sie müssen daher im Rahmen einer Studienarbeit eine derartige Anwendung gemäß den in der Vorlesung vermittelten Prinzipien realisieren. Am Ende des Semesters müssen Sie diese Arbeit präsentieren. Sie können sich das Thema (in Absprache mit dem Professor/Dozent) selbst aussuchen.

Da sich die Vorlesung und das Praktikum an dem Thema Spiele orientieren ist es sinnvoll ein Spiel als Studienarbeit zu programmieren.

Anbei finden Sie eine exemplarische und unvollständige Liste mit Themenvorschlägen:

• Mini-Billard
• Mini-Mohrhun
• Geschicklichkeitsspiel: herabfallende Gegenstände sammeln, Ballerspiel, ...
• Snake
• Memory
• Vier gewinnt, Fünf gewinnt, Reversi ... (zwei Spieler, evtl. auch ein Spieler + KI)
• Point-and-Click (2D)
• Jump-and-Run
• Spielephysik
• Tic Tac Toe
• Pong
• Doodle Jump
• Flappy Bird
• Bubble Worlds

Es ist empfehlenswert und in den meisten Fällen auch einfacher die Studienarbeit alleine anzufertigen. Sie können die Studienarbeit allerdings auch als Zweier- oder Dreier-Teams realisieren. In diesem Fall muss die Arbeit aus klar erkennbar eigenständig angefertigen Teilen bestehen. Jedes Teammitglied muss einen angemessenen Teil dieser Anwendung implementieren.

Beachten Sie, dass Sie im Falle einer Wiederholungsprüfung eine vollkommen neue Arbeit erstellen müssen.

Dokumentation

Die Dokumentation der Studienarbeit (ein PDF-Dokument) muss Folgendes enthalten (siehe auch die Abgabeliste im Anschluss an die Erstellungserklärung):

1. den Autor/die Autoren der Anwendung
2. den Namen der Anwedung
3. eine aussagekräftige Kurzbeschreibung der Anwendung
4. eine kurze Installationsanleitung (falls notwendig)
5. eine kurze Bedienungsanleitung
6. ein technisches Konzept der Anwendung
   1. Inhalt: Strukturierung/Aufbau des Codes, angewendete Programmiertechniken, verwendete Technologien und Begründungen für sämtliche Entscheidungen
   2. Umfang: ca. eine Seite Text, bei Verwendung von Grafiken entsprechend mehr
   3. UML-Diagramme dürfen gerne verwendet werden, sind aber kein Pflichtbestandteil
7. Quellenangaben zu allen für die Arbeit verwendete Quellen: Software, fremde Bibliotheken, fremde Algorithmen, Literatur (Nachschlagewerke) etc.
8. Bei mehreren Autoren: Eine Übersicht, welcher Autor für welche Teile der Arbeit verantwortlich ist.

Bewertung

Sie müssen bei der Erstellung der Arbeit darauf achten, dass Sie verständlichen, lesbaren, modularen und wiederverwendbaren Code nach anerkannten objektorientierten Programmierprinzipien schreiben. Die Anwendung muss mit mit HTML5 und JavaScript erstellt werden.

In die Bewertung fließen ein:

In die Bewertung der Studienarbeit fließen ein:

• Studienarbeit
  • Angewendete Programmiertechniken
    • Timer (setTimeout, setInterval, requestAnimationFrame)
    • Event-Listener, Verarbeitung von Events
    • Objekte, Konstruktoren oder Factories
    • Rendering mit DOM oder SVG
    • Ergänzend: Anspruchsvolle Verwendung von Browser-APIs oder Libraries
  • Qualität
    • Modularisierung (Datei- und Code-Ebene)
    • Sinnvolle Benennung, Aussagekraft
    • Wiederverwendbarkeit, Konfigurierbarkeit
    • Korrektheit, keine Fehler
    • Keine Redundanz
  • Model-View-Controller
    • Sämtliche (Spiele-)Logik im Model
    • Sauberes Model
    • Saubere View
    • Sauberer Controller
  • Umfang
    • Angemessene Code-Menge
    • Höherer Eigenanteil als Fremdanteil
    • Aktivität im SVN-Repository
  • Dokumentation
    • Angemessener Umfang
    • Form
    • Technisches Konzept
    • Quellenangaben
• Prüfungspraktikum
  • Qualität und Korrektheit der Lösungen

Bitte beachten Sie, dass die Studienarbeit im Vergleich zum Prüfungspraktikum wesentlich stärker gewichtet wird.

Die gesamte Arbeit wird als mangelhaft bewertet, sobald auch nur ein Plagiat enthalten ist.

Die Arbeit wird als unvollständig und damit als nicht abgegeben gewertet, wenn eine der Zwischenabgaben nicht erfolgt ist.

Die Arbeit wird als unvollständig und damit als nicht abgegeben gewertet, wenn ein wesentlicher Bestandteil fehlt, d.h., wenn in der Abgabeliste im Anschluss an die Erstellungserklärung eine wesentliche Frage mit nein beantwortet wurde oder wenn die Erstellungserklärung samt Abgabeliste fehlt.

Die Arbeit wird als unvollständig und damit als nicht abgegeben gewertet, wenn die grobe Enstehungsgeschichte der Arbeit nicht anhand der Besprechungen im Praktikum oder anhand der Versionen im SVN-Repository nachvollzogen werden kann (entweder regelmäßige Teilnahme am Praktikum oder mindestens 5 einschlägige Updates vor jeder Zwischenabgabe und anschließend mindestens 10 einschlägige Updates vor der Endabgabe).