1. Dragon v1.0

  • Assignment: Dragon v1.0

  • Complexity: medium

  • Lines of code: on average 100 lines, shortest solution is 24 lines

  • Time: 89 min, then 144 min live coding with instructor

  • Warning: Don't delete code, assignment will be continued

../_images/dragon.gif

Figure 1.16. Firkraag dragon from game Baldur's Gate II: Shadows of Amn

1.1. Agenda

  • 09:00 - 09:20 - Assignment introduction (functional and non-functional requirements)

  • 09:20 - 10:50 - Students write code

  • 10:50 - 11:00 - Git commit and push, break

  • 11:00 - 11:40 - Code review (2-3 volunteers)

  • 11:40 - 11:45 - Break

  • 11:45 - 13:15 - Trainer writes code (TDD)

  • 13:15 - 14:00 - Lunch

  • 14:00 - 15:30 - Trainer performs refactoring

  • 15:30 - 15:45 - Survey, break

  • 15:45 - 17:00 - ...

1.2. English

  • Assignment is simulation of a software development process.

  • Assignment is a business requirements specification.

  • Solution must fulfill all the acceptance criteria.

  • How to implement those criteria is up to you.

  • You - programmer, Instructor - Product Owner.

  • Product Owner will not help you in architectural decisions.

  • Do not check neither solution nor future versions (beta and rc).

Non-functional requirements:

  1. In your directory create an empty file dragon_v1.py

  2. Add file to the version control system (should be automatic)

  3. Commit with message: "Dragon: NAME", where NAME is your first name

  4. Push changes to the repository

  5. In this file write a solution to the assignment

  6. Upon completing assignment commit and push changes to the repository

Functional requirements:

  1. Create Dragon with:

    1. name

    2. position on the screen

    3. health points, default random int in range from 50 to 100

    4. path to the texture file, default img/dragon/alive.png

  2. Dragon can:

    1. have position set to any place on the screen

    2. move in any direction by specified value

    3. make damage in range from 5 to 20

    4. take damage

  3. Assume left-top screen corner as an initial coordinates position:

    1. going right add to x

    2. going left subtract from x

    3. going up subtract from y

    4. going down add to y

  4. When health points drop to, or below zero:

    1. Dragon has status dead

    2. Change texture file name to img/dragon/dead.png

    3. Display NAME is dead, where NAME is the dragon's name

    4. Display how much gold dragon dropped (random integer from 1 to 100)

    5. Display position where dragon died

  5. Run the game:

    1. Create dragon named "Wawelski"

    2. Set Dragon's initial position to x=50, y=120

    3. Set new position to x=10, y=20

    4. Move dragon left by 10 and down by 20

    5. Move dragon left by 10 and right by 15

    6. Move dragon right by 15 and up by 5

    7. Move dragon down by 5

    8. Dragon makes damage

    9. Make 10 points damage to the dragon

    10. Make 5 points damage to the dragon

    11. Make 3 points damage to the dragon

    12. Make 2 points damage to the dragon

    13. Make 15 points damage to the dragon

    14. Make 25 points damage to the dragon

    15. Make 75 points damage to the dragon

    16. Dragon should die at the position x=20, y=40 and drop gold (1-100)

Post notes:

  1. Trainer acts as Product Owner with little technical knowledge

  2. You are the software engineer who need to decide and live with consequences of your choices

  3. Task is a narrative story telling to demonstrate OOP and good engineering practices

  4. Calculated last position of the game should be x=20, y=40

  5. You can introduce new fields, methods, functions, variables, constants, classes, objects, whatever you want

  6. Don't use modules form outside the Python Standard Library

  7. Task is business requirement specification, not a technical documentation, i.e., "what Dragon has to do, not how to do it"

  8. You don't have to keep order of specification while writing code

  9. This is 1.0 version, so no new functionality like negative position checking etc

  10. You can create tests, i.e.: unittest, doctest

  11. Do not read solution or any future iterations of this exercise; if you read future tasks, you will spoil fun and learning

Good luck, have fun!

1.3. Polish

Zadanie jest symulacją procesu wytwarzania oprogramowania. Motyw Smoka z zadania jest tylko narracją do demonstracji obiektowego paradygmatu programowania i dobrych praktyk programistycznych. Nie piszemy gry i nie będziemy omawiali specyfiki game-dev! Siłą rzeczy poruszymy kilka kwestii z związanych ze specyfiką gier (np. to że smok zieje ogniem itp), ale całość dyskusji znajdzie zastosowanie do dowolnego rodzaju projektów informatycznych i problemów inżynierii oprogramowania w każdej domenie biznesowej.

Ty - programista, Prowadzący - Product Owner. Przy tym zadaniu wcielisz się w rolę inżyniera oprogramowania (programisty), a Prowadzący będzie zachowywał się jak Product Owner z niewielką wiedzą techniczną - 10 lat temu był programistą, a teraz większość czasu spędza w arkuszu kalkulacyjnym i na spotkaniach. Pamiętaj, że doświadczenie Product Ownera rzutuje na sposób w jaki pisze kryteria akceptacyjne. Jego kariera programisty może powodować, że w specyfikacji wymagań pojawią się kwestie techniczne i sugestie jak dany problem rozwiązać. Musisz to odfiltrować z treści zadania. Niestety to bardzo częsty scenariusz w branży IT.

Wymagania niefunkcjonalne:

  1. W swoim katalogu stwórz pusty plik dragon_v1.py

  2. Dodaj plik do systemu kontroli wersji

  3. Zapisz (commit) zmiany jako "Dragon: NAME", gdzie NAME to Twoje imię

  4. Wypchnij (push) zmiany do repozytorium

  5. W pliku zapisz kod do rozwiązania zadania

  6. Po skończeniu zadania zapisz i wypchnij zmiany do repozytorium

Wymagania funkcjonalne:

  1. Stwórz Smoka z:

    1. nazwą

    2. pozycją na ekranie

    3. punktami życia, domyślnie losowy int z zakresu od 50 do 100

    4. ścieżką do pliku tekstury, domyślnie img/dragon/alive.png

  2. Smok może:

    1. być ustawiony w dowolne miejsce ekranu

    2. być przesuwany w którymś z kierunków o zadaną wartość

    3. zadawać komuś losowe obrażenia z przedziału od 5 do 20

    4. otrzymywać obrażenia

  3. Przyjmij górny lewy róg ekranu za punkt początkowy:

    1. idąc w prawo dodajesz x

    2. idąc w lewo odejmujesz x

    3. idąc w górę odejmujesz y

    4. idąc w dół dodajesz y

  4. Kiedy punkty życia Smoka spadną do lub poniżej zera:

    1. smok ma status dead

    2. zmień nazwę pliku tekstury na img/dragon/dead.png

    3. wyświetl NAME is dead, gdzie NAME to nazwa smoka

    4. wyświetl ile złota smok wyrzucił (losowa liczba od 1 do 100)

    5. wyświetl pozycję gdzie smok zginął

  5. Przeprowadź grę:

    1. Stwórz smoka o nazwie "Wawelski"

    2. Ustaw inicjalną pozycję smoka na x=50, y=120

    3. Ustaw nową pozycję na x=10, y=20

    4. Przesuń smoka w lewo o 10 i w dół o 20

    5. Przesuń smoka w lewo o 10 i w prawo o 15

    6. Przesuń smoka w prawo o 15 i w górę o 5

    7. Przesuń smoka w dół o 5

    8. Smok zadaje obrażenia (5-20)

    9. Zadaj 10 obrażeń smokowi

    10. Zadaj 5 obrażeń smokowi

    11. Zadaj 3 obrażenia smokowi

    12. Zadaj 2 obrażenia smokowi

    13. Zadaj 15 obrażeń smokowi

    14. Zadaj 25 obrażeń smokowi

    15. Zadaj 75 obrażeń smokowi

    16. Smok powinien zginąć na pozycji: x=20, y=40 i zostawić złoto (1-100)

Informacje dodatkowe:

  1. Zadanie jest specyfikacją wymagań biznesowych. Nie jest to dokumentacja techniczna. Zadanie opisuje "co ma być", a nie "jak to robić". Zwróć na to uwagę, bo to ważna różnica!

  2. Sposób implementacji jest dowolny. Możesz wprowadzać dodatkowe pola, metody, funkcje, zmienne, stałe, klasy, obiekty, unittest lub doctest, type annotation - co tylko chcesz, ale nie korzystaj z modułów spoza biblioteki standardowej. Wyjątkiem są frameworki do testów (pytest, hypothesis, itp).

  3. Rozwiązanie musi spełniać kryteria akceptacyjne. Pamiętaj, że jest to wersja 1.0 więc nie wprowadzaj dodatkowych niezamówionych funkcjonalności (np. dodatkowych postaci, sprawdzania wychodzenia poza planszę itp.). Z tego powodu nie musisz trzymać się kolejności punktów i podpunktów w zadaniu, a także rozwiązać problemy inaczej niż jest napisane. Masz pełną dowolność.

  4. Product Owner nie doradzi Ci w sprawie decyzji architektonicznych. Nie podpowie Ci czy lepiej będzie zrobić to w jakiś konkretny sposób, albo czy jak zastosujesz to pewne rozwiązanie to jaki będzie wpływ na przyszłość. Zadanie polega na tym, że to Ty musisz podejmować decyzje i ponosić ich konsekwencje, tj. łatwa możliwość wprowadzania zmian w przyszłych wersjach. Musisz znaleźć balans, między wdrożeniem szybkim funkcjonalności, łatwością zrozumienia i utrzymywania kodu i nie zablokowaniem sobie drogi na wprowadzanie zmian w przyszłości. Pamiętaj o TDD, YAGNI, DRY, KISS, SOLID, emerging architecture i over-engineering.

  5. Nie przeglądaj rozwiązań ani treści kolejnych części zadania. Jeżeli zaglądniesz w przód, to zepsujesz sobie zabawę i naukę. To zadanie ma niesamowity potencjał edukacyjny. Nie niszcz go.

Powodzenia i miłej zabawy!

1.4. Hints

  • Shortest solution has 24 lines of code

  • from random import randint

  • randint(a, b) - random integer between a and b (inclusive!)

1.5. Solution

  • EN: Note, that this will spoil your fun and learning

  • PL: Zwróć uwagę, że to zepsuje Twoją zabawę i naukę

  • Basic

  • Intermediate

  • Advanced