Ruben Hooijer - Blok 1 Eindproject

[loljoch]

Ik ga Tetris maken met een twist. De game krijgt een twist dat de blokken eerst "Empowered" moeten zijn voordat je een line kan clearen(verwijderen). Hiermee kan ik nog andere dingen toevoegen zoals een tijdlimiet op de empowered blokken (empowering gaat weg na bepaalde tijd) of nieuwe blokken die empowered blokken de-powered maakt en de-powered blokken, empowered maakt.

[loljoch]

Versie 1 van me class diagram, het idee is dat er bij mijn tetris niet letterlijk iets valt in de engine, maar de verschillende blokjes lichten gewoon op. (net als lampen op een muur, wanneer er een is opgelicht dan is de plek al bezet)

[aaronvark]

Maak je UML liever niet transparant, nu kan ik de lijnen niet zien als ik hem open (want mijn achtergrond is zwart). Volgens mij snap ik je UML helemaal, behalve de aggregation (open ruit) pijl van Grid Singleton? naar MainBlock. Bevat het MainBlock een GridSingleton (in een onlosmakelijke samenkomst?) Ook zou ik aangeven dat Grid een singleton is met een stereotype <>.

In de Grid class is er nog een kans om wat herhalende code te vangen in functies die de x/y offsets per direction als parameters ontvangt. Daar wordt het dan iets leesbaarder van, maar het is even puzzelen met hoe je ze opbouwt. Die switch direction zou je mooi in een "CoordFromDirection" functie kunnen wrappen, is die CanShapeMove functie iets leesbaarder.

Waarom doe je "GetComponent().enabled = false;" op MainBlock (die inherit toch van Block?). Als je een Block script EN en MainBlock script op dezelfde GameObject hebt zitten dan gaat er iets mis. Het idee is dat je alleen de laatste stap in de inheritance tree op de GameObject zet (dus MainBlock, in dit geval), anders zou GetComponent namelijk ook het MainBlock kunnen returnen (dat is namelijk ook een Block).

In MainBlock heb je ook weer die Direction en Coordinate die je tot een nieuwe coord maakt. Misschien dit in een static utility class gooien? of als functie van een eventuele Coordinate class?

[loljoch]

Een korte toelichting over:

• Wat je qua features voor de eindopdracht wilt gaan uitwerken Ik wil de main feature maken, dat blokken dus eerst licht moeten geven voordat ze gecleared kunnen worden. En ook een switch blok die dan de kleuren omruilt (dus als je licht geeft dan stop je met lichtgeven, en als je geen licht geeft dan geef je licht)

• Hoe ver je nu bent Op het moment heb ik een goed werkende Tetris die nog geen score bijhoud, maar erg makkelijk uitbreidbaar is

• Welke dingen je graag zou willen proberen (in relatie tot OOP, patterns, language features, etc.) Ik wil graag een game controller erin zetten met delegates (want deze snap ik waarschijnlijk pas wanneer ik ze gebruik)

[aaronvark]

Die Game Controller, daar bedoel je dan een soort public event manager zoals wat Valentijn een keer liet zien? Dat is waarschijnlijk een prima beginpunt om events / delegates wat te oefenen zonder direct in allerlei object relaties terecht te komen.

Ben benieuwd hoe je die switch wilt gaan doen. Waarschijnlijk is het 't makkelijkste om dat vanuit het grid te doen, en de blokken echt een variabele (mss een enum?) te geven waartussen ze kunnen cyclen. Die enum kan je dan weer verbinden aan een specifieke kleurweergave, zonder dat je het verdere gedrag hoeft te veranderen, of color checks/sets moet hardcoden. Hoe beïnvloedt dit switchen de gameplay van het geheel?

[loljoch]

Github naar de game https://github.com/loljoch/BrightBlocks