Schemat blokowy/diagram UML do przetwarzania kart w grze CashFlow

Stworzyć schemat blokowy lub diagram UML (co lepsze?) dla przetwarzania karty, która wypadła z talii i przyszła od innego gracza w grze, która opiera się na grze CashFlow. Obecnie istnieje mapa myśli tego, jak już zaprogramowaliśmy przetwarzanie kart, zob. 8_function_mindmap_v3.zip Chcielibyśmy, abyście mieli w swoim doświadczeniu około dziesięciu ŚWIEŻYCH schematów blokowych lub diagramów, abyście szybko, nie zaglądając do podręcznika, orientowali się, który element schematu blokowego jest potrzebny w danym momencie i wiedzieli, jak go używać/opisywać. Mogliście nam krótko, przystępnie wyjaśnić.

Rezultatem przetwarzania karty, która przychodzi, mogą być sytuacje, gdy Karta wchodzi w interakcję z raportem, zob. str. 9 101_1996_ru.pdf:

1. Nie trafia do Raportu

2. Trafia do Raportu

3. Aktualizuje dane Raportu

4. Usuwa (wycofuje, z Raportu)

Najważniejsze: to przetwarzanie N kart jednocześnie, tzn. dla jednego użytkownika rozważamy, że jednocześnie może wejść więcej niż 1 karta. (Zaprogramowaliśmy wszystkie sytuacje, ale dla przypadku, gdy karta 1)

Specyfika bieżącej gry, która uzupełnia Cashflow, którą wzięliśmy za podstawę: 

1. Istnieje dodatkowa talia kart: "Działania"

2. Istnieje 10 Rang - w trakcie gry gracz zdobywa określoną Rangę, a niektóre karty działają tylko dla określonego zestawu Rang

wszystko inne w pełni odpowiada logice gry CashFlow

3. Czynnik czasu

4. Czynnik nastroju

5. Karty wielowariantowe (W jednej karcie Gracz może wybrać kilka wariantów, lub wykonać jedno jednolite działanie, lub drugie, lub trzecie itd.)

Oto następne warunki dla Kart:

1. Obowiązkowa/Nieobowiązkowa

2. W raporcie ma/nie ma być coś (Na przykład: Obowiązkowo trzeba wydać jakieś środki, pod warunkiem, że w raporcie są Dzieci)

3. Użytkownik akceptuje (lub musi ją obowiązkowo zaakceptować), lub nie akceptuje karty

4. Użytkownik osiągnął/nie osiągnął odpowiednią Rangę

5. Wystarczająco/Niewystarczająco 

- czasu

- nastroju

- pieniędzy (może wziąć kredyt, lub 

nie może, jeśli CashFlow jest niewystarczający)

6. W zależności od tego, jak przebiegły warunki, karta wchodzi w interakcję z raportem

Dane kart - ustandaryzowane i znajdują się w JSON, jeśli brać w rozrachunku talii, to:

- Zasoby (4 typy)
- Małe słabości (2 typy)
- Siły wyższe (7 typów)
- Działania (2 typy)
- Umowy (5 typów)

Łącznie 20 typów kart. Mogę wysłać w wiadomościach prywatnych, do zapoznania się. (Nie wyślę publicznie - pracowaliśmy nad tym jako zespół.)

Jak widzę realizację tego projektu:

1. Zapoznacie się z Projektem

2. Zadacie wszelkie pytania wyjaśniające

3. Możliwe, że od razu stworzycie jakąś podstawową schemat blokowy/diagram UML

4. Zrobimy kilka sesji rozmów na Skype, w których będziecie demonstrować ekran, a my rozmawiając wyjaśnimy wam, jakie sytuacje nie zostały uwzględnione, lub zostały uwzględnione nie tak

5. Jeśli w bieżącym projekcie zabraknie czasu, zamykamy bieżący i otwieramy nowy oraz dopracowujemy schemat blokowy/diagram UML.

Zasady gry zob. 101_1996_ru.pdf