Software ontwerp in C/C++: Project opdracht


« Terug naar Software ontwerp in C/C++

Project resultaten 2018 - 2019

Project opdracht - tweede kans

Dezelfde minimumvereisten gelden als hieronder. Werk met een nieuwe Github repository, en vertrek opnieuw vanaf de gba-sprite-engine. Geregistreerde tijd bijhouden is niet meer nodig.

De opdracht is niet vrij te kiezen. Het criteria ‘originaliteit’ zal beoordeeld worden op de manier waarop je deze vaste opdracht hebt ingekleurd.

Opdracht beschrijving

Ontwerp een Mario Party kloon. In dit bordspel gaan spelers op een klassieke manier het bord rond om punten te verzamelen. De structuur van het bord is gelijkaardig aan een Ganzenbord spel. Elke plek waar de speler zijn of haar pion terecht komt, brengt een bepaalde actie met zich mee. In Mario Party wordt er meestal een minigame gespeeld, dat indien gewonnen punten oplevert. Hier is een video van de officiële GBA implementatie:


Wat moet minimaal aanwezig zijn?

Wat is optioneel?

Inleverformaat op dezelfde manier als in de eerste kans. Deadline op vrijdag, 23 augustus 2019, 12u ’s middags.

Project opdracht - eerste kans

Om jullie recent bijgeslepen object-geörienteerde technieken te laten zien gaan jullie een GBA spel ontwerpen en ontwikkelen in C++11. De focus van de opdracht ligt niet op correcte low-level IO mapping maar op kritisch denken en testen zoals gezien in labo 7. Uiteraard komen zowel pointers en GBA programming technieken van de vroegere labo’s, als C++ class inheritance en abstractie lagen uit de latere labo’s aan bod.

Vertrek vanuit de gba-sprite-engine library die ik gebouwd heb op Github door een Fork te nemen met de knop rechtsboven. Op die manier bespaar je veel werk met een nieuw GBA project op te zetten en alle IO adressen opnieuw te mappen. Er is een README voorzien voor meer info. De engine gebruikt Tonc achterliggend.

Wat voor soort spel het moet zijn laat ik volledig aan jullie over. Het spreekt voor zich dat complexiteit (en originaliteit!) mee in rekening gebracht wordt: zie evaluatiecriteria. Inspiratie nodig?

Werk in groepen van 2 of indien oneven 3.

In het kader van onderzoek naar onderwijs vragen wij jullie je tijd gespendeerd aan het project bij houden in een bestandje. Dit mag niet veel administratie vragen: enkel in een simpele CSV bijhouden op welke dag jullie hoeveel tijd werk aan het project spendeerden is voldoende. De eenheid is in uren - een halfuur kan bijvoorbeeld met 0.5 uitgedrukt worden. Dit is een voorbeeld bestandje: https://github.com/wgroeneveld/gba-sprite-engine/blob/master/timespent.csv. Wanneer jullie het project in Github overnemen komt deze file automatisch mee. Werk dit tijdig bij, dat voorkomt moeten gokken. Dit is individueel dus als jullie samen aan een project werken, maak dan twee files aan!

Bedankt om mee te werken aan een beter onderwijs!

Minimumvereisten

Lees dit goed na: projecten die niet voldoen aan de volgende vereisten zullen niet geëvalueerd worden.

  1. De code leeft in een repository op Github onder jullie username met de MIT license.
  2. Je vertrekt vanuit gba-sprite-engine - zie hierboven. Daarbij blijf je binnen GBA MODE0 en werk je met sprites. C++11 is hiermee ook een vereiste.
  3. Indien je je baseert op andere bestaande code doe je aan bronvermelding! Plagiaat wordt zeer ernstig bestraft.
  4. Je project moet uiteraard minstens compileren.
  5. Je repository README.md bevat een kleine functionele beschrijving van jullie spel.
  6. Naast de functionele beschrijving upload je ook een schets van je domein model, gepaard met verklarende tekst.
  7. Je repository timespent.csv bevat jullie individueel geregistreerde tijd in uren.

Het is niet de bedoeling om je te baseren op één van de engine demo’s en die simpelweg verder uit te werken. Dat biedt onvoldoende uitdaging en originaliteit.

Omdat als vereiste elk project op Github leeft kunnen jullie elkaar’s repository ook raadplegen. Of jullie daar gebruik van willen maken laat ik aan jullie over: onthoud sharing is caring en vergeet de bronvermelding niet. Het is geen race voor het beste waarbij je je code zorgvuldig moet afschermen: iedereen vertrekt vanuit dezelfde basis en iedereen kiest een ander soort spel.

Evaluatiecriteria

Punten worden op twee keer op /20 gegeven. Eenmalig een globaal cijfer, eenmalig een genormaliseerd cijfer, rekening houdend met de volgende subcriteria en gewichten:

  1. O.5 Design
    Hoe is je Object-Oriented design en domein model?
    Hoge score: duidelijk herkenbare objecten, terug te vinden in domein model, met gescheiden verantwoordelijkheden.
  2. O.5 Clean Code
    Hoe leesbaar is je code?
    Hoge score: eenvoudig begrijpbare variabelen, methodes, klassen.
  3. 0.1 C++ Conventies
    Is je code opgebouwd volgens de aangeleerde C++11 standaarden?
    Hoge score: correct gebruik van header/source files, smart pointers, STL, templates, naamgeving conventies hoofdletters.
  4. 0.3 Complexiteit
    Hoe moeilijk heb je het gemaakt?
    Hoge score: gekozen voor een uitdaging in de plaats van een eenvoudige implementatie.
  5. 0.3 Originaliteit
    Met welke insteek heb je je idee vorm gegeven?
    Hoge score: een origineel idee uitgewerkt in plaats van een standaard 2D platformer.
  6. 0.2 GBA UI
    Hoe uitgebreid is de grafische representatie?
    Hoge score: alle UI technieken uitgebreid toegepast: tiles, sprites, scrolling backgrounds, …

Waarbij beide cijfers herleid worden tot één.
Bovenstaande criteria zijn herzien op 05/12/2018 en finaal voor academiejaar 2018 - 2019.

Inleverformaat

Datum te bepalen, evenals verdedigingsdata.

Praktische tips

 Top