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¶
In your directory create file
dragon_alpha.py
with class representing DragonDragon has (attributes):
name
position on the screen
texture file name, default
img/dragon/alive.png
health points, default random
int
in range from 50 to 100
Dragon can (methods):
have position set to any place on the screen
move in any direction by specified value
make damage in range from 5 to 20
take damage
When health points drop to, or below zero:
Dragon has status
dead
Change texture file name to
img/dragon/dead.png
Print
NAME is dead
, whereNAME
is the dragon's namePrint how much gold dragon dropped (random integer from 1 to 100)
Print position where dragon died
Assume left-top screen corner as an initial coordinates position:
going right add to
x
going left subtract from
x
going up subtract from
y
going down add to
y
Run the game:
Create dragon named "Wawelski"
Set Dragon's initial position to x=50, y=120
Set new position to x=10, y=20
Move dragon left by 10 and down by 20
Move dragon left by 10 and right by 15
Move dragon right by 15 and up by 5
Move dragon down by 5
Dragon makes damage
Make 10 points damage to the dragon
Make 5 points damage to the dragon
Make 3 points damage to the dragon
Make 2 points damage to the dragon
Make 15 points damage to the dragon
Make 25 points damage to the dragon
Make 75 points damage to the dragon
Dragon should die at the position x=20, y=40 and drop gold (1-100)
Non-functional requirements:
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).
Post notes:
Trainer acts as Product Owner with little technical knowledge
You are the software engineer who need to decide and live with consequences of your choices
Task is a narrative story telling to demonstrate OOP and good engineering practices
Calculated last position of the game should be x=20, y=40
You can introduce new fields, methods, functions, variables, constants, classes, objects, whatever you want
Don't use modules form outside the Python Standard Library
Task is business requirement specification, not a technical documentation, i.e., "what Dragon has to do, not how to do it"
You don't have to keep order of specification while writing code
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¶
W swoim katalogu stwórz plik
dragon_alpha.py
a w nim klasę reprezentującą SmokaSmok ma (atrybuty):
nazwę
pozycję na ekranie
nazwę pliku tekstury, domyślnie
img/dragon/alive.png
punkty życia, domyślnie losowy
int
z zakresu od 50 do 100
Smok może (metody):
być ustawiony w dowolne miejsce ekranu
być przesuwany w którymś z kierunków o zadaną wartość
zadawać komuś losowe obrażenia z przedziału od 5 do 20
otrzymywać obrażenia
Kiedy punkty życia Smoka spadną do lub poniżej zera:
Smok ma status
dead
Zmień nazwę pliku tekstury na
img/dragon/dead.png
Wypisz
NAME is dead
, gdzieNAME
to nazwa smokaWypisz ile złota smok wyrzucił (losowa liczba od 1 do 100)
Wypisz pozycję gdzie smok zginął
Przyjmij górny lewy róg ekranu za punkt początkowy:
idąc w prawo dodajesz
x
idąc w lewo odejmujesz
x
idąc w górę odejmujesz
y
idąc w dół dodajesz
y
Przeprowadź grę:
Stwórz smoka o nazwie "Wawelski"
Ustaw inicjalną pozycję smoka na x=50, y=120
Ustaw nową pozycję na x=10, y=20
Przesuń smoka w lewo o 10 i w dół o 20
Przesuń smoka w lewo o 10 i w prawo o 15
Przesuń smoka w prawo o 15 i w górę o 5
Przesuń smoka w dół o 5
Smok zadaje obrażenia (5-20)
Zadaj 10 obrażeń smokowi
Zadaj 5 obrażeń smokowi
Zadaj 3 obrażenia smokowi
Zadaj 2 obrażenia smokowi
Zadaj 15 obrażeń smokowi
Zadaj 25 obrażeń smokowi
Zadaj 75 obrażeń smokowi
Smok powinien zginąć na pozycji: x=20, y=40 i zostawić złoto (1-100)
Wymagania niefunkcjonalne:
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.
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.
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.)
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.
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.
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.
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 betweena
andb
(inclusive!)
1.4. Solution¶
EN: Note, that this will spoil your fun and learning
PL: Zwróć uwagę, że to zepsuje Twoją zabawę i naukę