1. Dragon (version alpha)

• Assignment: Dragon (version alpha)

• Complexity: medium

• Lines of code: 100 lines

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

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

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

1.1. English

1. In your directory create file dragon_alpha.py with class representing Dragon

2. Dragon has (attributes):

   1. name

   2. position on the screen

   3. texture file name, default img/dragon/alive.png

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

3. Dragon can (methods):

   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

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. Print NAME is dead, where NAME is the dragon's name

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

   5. Print position where dragon died

5. 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

6. 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)

Non-functional requirements:

1. Assignment is simulation of a software development process.

2. Assignment is a business requirements specification.

3. Solution must fulfill all the acceptance criteria.

4. How to implement those criteria is up to you.

5. You - programmer, Instructor - Product Owner.

6. Product Owner will not help you in architectural decisions.

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

Post notes:

2. Trainer acts as Product Owner with little technical knowledge

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

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

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

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

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

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

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

10. This is alpha version, so no new functionality like negative position checking etc

l. You can create tests, i.e.: unittest, doctest k. Do not read solution or any future iterations of this exercise;

if you read future tasks, you will spoil fun and learning

1.2. Polish

1. W swoim katalogu stwórz plik dragon_alpha.py a w nim klasę reprezentującą Smoka

2. Smok ma (atrybuty):

   1. nazwę

   2. pozycję na ekranie

   3. nazwę pliku tekstury, domyślnie img/dragon/alive.png

   4. punkty życia, domyślnie losowy int z zakresu od 50 do 100

3. Smok może (metody):

   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

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. Wypisz NAME is dead, gdzie NAME to nazwa smoka

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

   5. Wypisz pozycję gdzie smok zginął

5. 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

6. 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)

Wymagania niefunkcjonalne:

1. Zadanie jest symulacją procesu wytwarzania oprogramowania.

   Posłuży 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 tym związanych, ale całość dyskusji znajdzie zastosowanie do dowolnego rodzaju projektów informatycznych i problemów inżynierii oprogramowania w dowolnej domenie biznesowej.

2. Zadanie jest specyfikacją wymagań biznesowych.

   Nie jest to dokumentacja techniczna. Zadanie opisuje "co Smok ma robić", a nie "jak to ma robić". To ważna różnica i zwróć na to uwagę. 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.

3. Rozwiązanie musi spełniać kryteria akceptacyjne.

   Pamiętaj, że jest to wersja alpha więc nie wprowadzaj dodatkowych niezamówionych funkcjonalności (np. dodatkowych postaci, sprawdzania wychodzenia poza planszę itp.)

4. 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 może być framework do testów.

5. 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 Excelu 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.

6. 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.

7. 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.3. Hints

• Shortest possible solution could have 24 lines of code

• from random import randint

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

1.4. Solution

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

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

• Basic

• Intermediate

• Advanced