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

../_images/dragon.gif

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

1.1. English

  1. In your directory create file dragon_alpha.py

  2. In this file define a class representing Dragon

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

  4. Dragon can (methods):

    1. have position set to any place on the screen

    2. make damage in range from 5 to 20

    3. take damage

    4. move in any direction by specified value

  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. When health points drop to, or below zero:

    1. Dragon is dead

    2. Set object status to dead

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

    4. Print XXX is dead, where XXX is the dragon's name

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

    6. Print position where dragon died

  7. Run the game:

    1. Create dragon at x=50, y=120 position and name it "Wawelski"

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

    3. Move dragon left by 10 and down by 20

    4. Move dragon left by 10 and right by 15

    5. Move dragon right by 15 and up by 5

    6. Move dragon down by 5

    7. Dragon makes damage

    8. Make 10 points damage to the dragon

    9. Make 5 points damage to the dragon

    10. Make 3 points damage to the dragon

    11. Make 2 points damage to the dragon

    12. Make 15 points damage to the dragon

    13. Make 25 points damage to the dragon

    14. Make 75 points damage to the dragon

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:

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

  2. W pliku zdefiniuj klasę reprezentującą Smoka

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

  4. Smok może (metody):

    1. być ustawiony w dowolne miejsce ekranu

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

    3. otrzymywać obrażenia

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

  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. Kiedy punkty życia Smoka spadną do lub poniżej zera:

    1. Smok jest martwy

    2. Ustaw status obiektu na dead

    3. Zmień nazwę pliku tekstury na img/dragon/dead.png

    4. Wypisz XXX is dead, gdzie XXX to nazwa smoka

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

    6. Wypisz pozycję gdzie smok zginął

  7. Przeprowadź grę:

    1. Stwórz smoka w pozycji x=50, y=120 i nazwij go "Wawelski"

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

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

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

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

    6. Przesuń smoka w dół o 5

    7. Smok zadaje obrażenia

    8. Zadaj 10 obrażeń smokowi

    9. Zadaj 5 obrażeń smokowi

    10. Zadaj 3 obrażeń smokowi

    11. Zadaj 2 obrażeń smokowi

    12. Zadaj 15 obrażeń smokowi

    13. Zadaj 25 obrażeń smokowi

    14. Zadaj 75 obrażeń smokowi

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.

  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, 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ę.

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