W tegorocznej edycji Motorola Science Cup, podobnie jak w latach ubiegłych, ocena Waszych projektów będzie kompleksowa i uwzględni zarówno aspekty techniczne, jak i wizualne. Zależy nam na wyłonieniu projektów, które łączą solidny kod z intuicyjnym i atrakcyjnym interfejsem użytkownika. Te same, sprawdzone kryteria oceny stosowaliśmy w poprzednich edycjach konkursu, gwarantując sprawiedliwą i rzetelną ocenę. Aby lepiej zobrazować proces oceny i kryteria, załączamy przykładowy zrzut ekranu z arkusza oceny zeszłorocznego zadania “Gry wektorowe”, które uzyskało najwyższą ocenę. Ten przykład pozwoli Wam lepiej zrozumieć, na co zwracamy uwagę podczas oceny.

Podejście do błędów

Zdajemy sobie sprawę, że błędy się zdarzają, szczególnie w projektach realizowanych w krótkim czasie. Dlatego nie odejmujemy punktów za błędy w działaniu aplikacji. Naszym celem jest ocena Waszych umiejętności, kreatywności i podejścia do rozwiązywania problemów, a nie karanie za nieuniknione potknięcia. Oczywiście, brak implementacji funkcjonalności lub jej niepełna implementacja, widoczna w kodzie, będzie miała negatywny wpływ na ocenę. Różnica między błędem a brakiem implementacji jest kluczowa. Błąd to coś, co nie działa poprawnie, ale jest zaimplementowane. Brak implementacji oznacza, że dana funkcjonalność w ogóle nie została zaprogramowana.

“Kody na nieśmiertelność” i “cheaty”

Zachęcamy Was do dodania do dokumentacji opisów “kodów na nieśmiertelność” lub innych “cheatów”, które umożliwią nam łatwiejsze testowanie Waszych gier. Te kody znacznie ułatwią nam ocenę funkcjonalności i sprawdzenie różnych aspektów Waszych projektów. Dzięki nim będziemy mogli szybciej i skuteczniej sprawdzić poprawność implementacji i ogólne działanie gry. Nie jest to wymagane, ale zdecydowanie zalecane.

Docenimy dobrą dokumentację i wyjątkowe pomysły

Wbrew pozorom, bardzo lubimy czytać dokumentacje! Automatycznie generowane opisy parametrów funkcji są mniej interesujące, ale bardzo cenimy sobie dobrze napisane teksty, w których można prześledzić cały proces powstawania projektu – wraz z wszystkimi Waszymi wzlotami i upadkami. Pamiętamy na przykład dokumentację, w której jeden z uczestników opisał, jak radził się swojego taty w sprawie programowania losowych kształtów asteroid! To właśnie ten rodzaj historii i opisów procesu tworzenia projektu bardzo cenimy. Wasze starania w tym zakresie zostaną zauważone i nagrodzone dodatkowymi punktami.

Dodatkowo, jeśli któryś z aspektów Waszego projektu zostanie przez nas oceniony jako wyjątkowy – na przykład niezwykle dobra muzyka, samodzielnie wykonana piękna grafika lub niebanalne pomysły – możemy przyznać za niego punkty ponad ustalony limit. To pozwoli Wam „podciągnąć” kilka punktów straconych w innych miejscach. Należy jednak pamiętać, że suma punktów za zadanie nie może przekroczyć maksymalnej ustalonej wartości.

Ocena dwutorowa – obiektywna i subiektywna

Oceny będą prowadzone na dwóch płaszczyznach: obiektywnej i subiektywnej. Ocena obiektywna skupia się na jakości kodu, dokumentacji i architekturze aplikacji, natomiast ocena subiektywna uwzględnia wizję autora zadania i ocenę ogólnego wrażenia. To sprawdzony system, który od lat zapewnia sprawiedliwą i kompleksową ocenę projektów. Autor zadania zawsze będzie zaangażowany w proces oceny.

Wybrane kryteria oceny obiektywnej

  • Czytelność, poprawność, efektywność i stosowanie dobrych praktyk programistycznych. Jasne nazewnictwo, komentarze, modułowość i spójny styl formatowania są kluczowe.
  • Jasna i kompletna dokumentacja projektu, instrukcji obsługi i opisu architektury (w tym opis cheatów).
  • Logiczne i efektywne zaprojektowanie aplikacji, w tym wybór odpowiednich struktur danych i algorytmów.

Niektóre kryteria subiektywne

Ocena subiektywna uwzględnia wizję autora zadania – jak dobrze udało się Wam oddać ducha i założenia danego zadania. Będziemy oceniać, jak dobrze spełniacie założenia projektu i jak oryginalne jest Wasze rozwiązanie. Pod uwagę brana będzie intuicyjność i komfort użytkowania aplikacji, Wasza kreatywność, oryginalność i innowacyjność.

Estetyka i interfejs użytkownika są równie ważne jak porządny kod.

Brak limitów

Nie ma żadnych ograniczeń co do wielkości kodu źródłowego ani objętości folderu node_modules. Skupcie się na stworzeniu najlepszego możliwego rozwiązania, bez ograniczania się sztucznymi limitami. Ta zasada obowiązuje od wielu lat i pozwala Wam na pełną ekspresję Waszych umiejętności.

Mamy nadzieję, że te informacje, wraz z załączonym przykładem arkusza oceny z zeszłorocznego zadania pomogą Wam w przygotowaniu projektów.