Programowanie Obiektowe Obrony i Poprawa Zera

Informacja dla studentów I roku z przedmiotu Programowanie Obiektowe. Dotyczy harmonogramu i sposobu oceny pracy z Projektu z przedmiotu Programowanie Obiektowe, zawiera także informacje jak poprawić zero.

Najistotniejsze informacje:
Poprawa Zera:
Na lab 14 zbiorę deklaracje (nie wiążące) kto poprawia zero.
Na lab 15 odbywa się poprawa zara i obrona projektu.

Osoby z grupy nr 2 majac zajęcia od 15:00
będą poprawiać zero od 16:45 a od 15:00 będą bronić projekt.
Osoby z grupy nr 6 mając zajęcia od 16:45
będą poprawiać zero od 16:45 a od 18:30 bronić projekt.
Zatem obie grupy będą poprawiać zero w jednym terminie od godziny 16:45.
Jeśli z grupy nr 6 będzie osoba, która chce bronić projekt a nie ma do poprawy zera to może zrobić to wcześniej i przystąpić do obrony od 16:45.

Osoba poprawiająca zero i broniąca projekt może pójść na krótką przerwę i się zrelaksować. Wejść bronić projekt powinna najpóźniej 10 min po zakończeniu poprawiania zera.
Wszystko odbywa się w sali 033
Termin oddania projektu to najpóźniej 5 czerwca godzina 18:10
Oddanie projektu po tym terminie oznacza zmniejszenie maksymalnej liczby pkt.

Szczegóły o jakie pytaliście (nie ma TLDR)

Aby uzyskać zaliczenie z przedmiotu w terminie podstawowym należy zdobyć co najmniej 120 pkt . Jest to połowa z maksymalnej liczby punktów z ćwiczeń(140) i projektu(100). Każdy student musi mieć maksymalnie 3 zera i oddać projekt zdobywając za niego co najmniej połowę punktów. Spełnienie każdego z trzech wymagań daje zaliczenie. Skala ocen standardowo od 50% ocena 3, a następnie co 10% pół oceny wyżej.

PO Projekty Semestralne
Każdy student ma szansę na oddanie Projektu z PO, jeśli nadal uczęszcza na studia, nie musi mieć maksymalnie 3 zer. Projekt oddany na 7 dni przed końcem (liczy się data oddania do oceny na moodle) pozwala zdobyć maksymalną liczbę pkt (100 pkt). Oczywiście projekt można przynieść (wrzucić na moodle) także dzień przed obroną – wówczas projekt oceniam w skali do 80 pkt. Na obronie projektu można mieć własny laptop. Warto wcześniej sprawdzić jak wasz projekt uruchamia się na komputerach w pracowni- po to, aby obronę poświęcić na pracę, a nie walkę z niezgodnościami w wersjach środowiska. Terminy mogą ulec zmianie, jeśli będzie inna liczba osób, niż przewiduje. Opis jak wygląda obrona podawałem na zajęciach, ale będzie także na końcu tej wiadomości.

Gry muszą spełniać kryteria z linku:

zadania-semestralne-2023

oraz

https://ktrojanowski.blog.uksw.edu.pl/programowanie-obiektowe/zasady-zaliczenia-lab/zasady-dla-zadania-sem/

Doszczegółowienie dla Kulek:
Gra Kulki oczywiście jest dla 1 gracza, więc nie może być w niej gracza komputerowego.
Logika gry: http://www.kurnik.pl/kulki/zasady.phtml
Oprócz tego ważne są takie informacje:
Gra zaczyna się z 3 kulkami na planszy.
Gracz widzi jakie 3 następne kulki pojawią się w kolejnej turze, kolejna tura rozpoczyna się w momencie kiedy po przesunięciu kuli nie nastąpiło zbicie.

warto pograć parę rozdań na kurniku aby sprawdzić jak to wygląda w praktyce.

Doszczegółowienie dla Domino:
Gramy w wersję podstawową zgodnie z opisem:
http://www.kurnik.pl/domino/zasady.phtml zatem są tylko dwa końce węża. Dodatkowo, nie trzeba ustawiać dubli pod kątem 90 stopni.
Warto pograć parę rozdań na kurniku aby sprawdzić jak to wygląda w praktyce.

Jak wygląda obrona:
Obrona projektu polega głównie na drobnej modyfikacji we własnym kodzie (zajmującej przeciętnie nie więcej niż kilkanaście minut). Jednak dla waszej wygody mogę czekać na wykonanie modyfikacji nawet sześćdziesiąt minut. Orientacyjny przebieg obrony wygląda następująco:
1) Zadam dodatkowe zadanie do wykonania w sali (drobna poprawka, czas do 60 minut)
a) Jeśli ktoś poprawkę wykona w 10 minut powinien przystąpić do dalszego kroku przed upłynięciem 60 minut, robi to przez zgłoszenie się do prowadzącego.
b) jeśli po przekroczeniu 60 minut nie będzie chętnych do oddawania rozumiem, że osoba nie poradziła sobie z zadaniem i nie realizujemy dalszych kroków.
c) Brak realizacji drobnej modyfikacji lub wykonanie jej w zły sposób oznacza brak możliwości oceniania. Modyfikacja nie może popsuć pozostałej logiki programu.
2) Prezentacja programu i kodu – przyznanie punktów
3) Po przyznaniu punktów weryfikuje kod czy nie został popełniony plagiat – zadanie offline zajmie mi to niestety parę dni.

Ponieważ obrona polega na drobnej modyfikacji (a zatem i kompilacji) proszę przyjść np. na 14 zajęcia i sprawdzić jak zachowuje się program w sali i czy są jakieś błędy wynikające z różnic środowisk (w domu i w sali). Oczywiście można oddawać projekt na własnym komputerze (nie ma gwarancji dostępu do gniazdka, po opuszczeniu sali należy pozostawić salę w stanie niepogorszonym). Weryfikacji na stanowiskach można zrobić zarówno w terminie swoich zajęć, chwilę przed lub chwilę po (o ile będą wolne miejsca) oraz podczas konsultacji od 18.15

Projekt zostanie oceniony negatywnie, jeśli nie jest napisany obiektowo (np. wszystko napisane w jednej klasie nie spełnia definicji, że program jest napisany obiektowo) oraz w przypadku, gdy nie można grać swobodnie (program posiada błędy pozwalające na grę w sposób niezgodny z zasadami, zawiesza się w trakcie rozgrywki lub nie ma pełnej logiki pozwalającą na grę zgodną z zasadami).
Oceniana jest nie tylko mechanika gry, ale także zastosowanie technik obiektowych. Zatem należy wykorzystać wszystkie techniki z listy, ich brak oznacza zmniejszenie liczby pkt.

Dodatkowo proszę pamiętać, że w kodzie musi znaleźć się:
Kapsułkowanie, dziedziczenie, listę inicjalizatorów konstruktora, polimorfizm, strumienie, rozdzielenie na pliki źródłowe, kontakt z plikami, gra z komputerem(nie dotyczy kulek), gra z żywym przeciwnikiem (nie dotyczy kulek), walidacja ruchów (gra zgodnie z zasadami), walidacja odczytywanych danych z pliku
brak implementacji dla więcej niż 4 elementów z powyższej listy oznacza brak pozytywnej oceny

Aby być ocenionym należy w archiwum uploadowanym na e.uksw.edu.pl należy zamieścić:
1) Projekt z kodem źródłowym programu (użyć opcji clean z Visual Studio aby wykasować zbędne pliki, skasować także niepotrzebny plik z rozszerzeniem Nazwa_Projektu.sdf)
2) Dokumentacja
3) Przykładowe dane wejściowe (może to być zapis trwającej gry).

W zależności od wykonania (np. częściowe, niepełne lub błędne) powyższych elementów można dostać punktację inną niż maksymalną.
Skala punktów kończy się na 100 i dotyczy projektu oddanego w terminie. Oddanie w terminie późniejszym (także w sesji poprawkowej). Oznacza taki sposób oceny:
Oceniamy standardowo do 100 pkt, następnie obliczamy 80% podliczonego wyniku, ponieważ oddanie projektu w terminie późniejszym oznacza naliczenie 80 pkt za projekt maksymalnie zatem np.:
Zdobyłem 100 pkt, 100*0.8 = 80 pkt
Zdobyłem 60 pkt, 60*0,8 = 48 pkt

Jak wygląda wrzesień?

We wrześniu sytuacja wygląda następująco:
1) Projekt oceniany na max 80% możliwych punktów do zdobycia.
2) Po pozytywnym zaliczeniu Projektu można przystąpić do poprawy części ćwiczeniowej.

Wynika z tego, że poprawa projektu jest przed terminem poprawy ćwiczeń. Obrona projektu w terminie wrześniowym wygląda tak samo jak w czerwcowym.