pyladiescz / roboprojekt Goto Github PK

Napsat testy a otestovat již hotové efekty políček z PR #137 :

• hole
• pusher
• gear
• laser - otestovat, jestli funguje správně trasování laseru i skrz křižovatky laserů
• flag
• repair

Hlavně otestovat správné přidítání/odečítání zranění, odečítání životů a následné (ne)oživení robota.

Řešte až po #82.

Použijte zatím sys.argv

• Terka
• Karolina
• Anežka
• Hanka
• Zuzka
• Katka
• Iveta
• Helena

Přidat robotí metodu na střílení laserem. Laser robota neprochází zdí a zasáhne pouze prvního robota v cestě. Laser putuje přes hrací plochu dokud nenarazí na zeď nebo robota. Robot zasažený laserem získá jedno zranění. Roboti s PowerDown nestřílí, ale můžou být zasaženi.

Načíst všechny obrázky na začátku a pak na ně už při vytváření spritů jen odkazovat.

Přečtěte si pořádně pravidla hry, ať víte kdy a jak se roboti navzájem posunují.
Je rozdíl mezi tím když robot sám jde a když ho posouvá třeba pohyblivý pás.

Teď se ve třech stejných for cyklech získavají cesty k políčkům, jejich typy a vlastnosti.

Když je v JSON mapě prázdné políčko (id=0), je reprezentováno pomocí Tile(path=0, rotation=0):

Ve frontendy je pak pro path=0 speciální logika:

Nebylo by lepší takovéhle „nepolíčko“ do seznamu tilelist_layer vůbec nedávat?

Na tomhle miniproblému nic dalšího nezávisí. Doporučuju někomu, kdo se v datovém modelu ještě úplně neorientuje (a má nějakou tu hodinku času). Jestli už teď víš jak to vyřešit, přenech to někomu jinému (nebo lépe, nabídni se jako kouč).

#130

Pridej dokumentacni retezce
Ostran import Enum

Napsat program, který vykreslí dvě statické části rozhraní - mapu a budoucí interaktivní část, viz obrázek.

Budeme potřebovat načítat větší mapy.
Aktuálně program neschroustá mapu rozšířenou o startovací pásek 12x4.

Vytvořit testovací mapu 12x16 a upravit kod, aby se zobrazovala celá.

Už je tu dost políček na jednoduchou testovací mapu: s jednou vrstvou, bez otočených políček. Nemusí být vůbec hratelná nebo složitá. Neměla by být symetrická, aby bylo poznat že se správně načte.

Pro sdílené mapy použijte Tiled 1.2 (jestli máš starší verzi a chceš dělat mapy, ozvi se na Slacku).

Nyní skript uloží exportovaná PNGčka do stejné složky, kde jsou SVGčka. My je máme oddělené, a bylo by super, kdyby skript takovou složku:

• pokud neexistuje, vytvořil,
• následně ji naplnil obrázky.

• Hru bude řídit server, ke kterému se budou přihlašovat klienti (speciální sraz)
• Power Down (#232)
• Vyřešit odpojování klientů (#384)
• Z grafiky bude poznat, co se na herní ploše děje (#308)
• Sepsat návod (#50)

Rozšíření:

• Na přihlašovací obrazovce půjde vybrat robota a pojmenovat ho
• Hra obsahuje návod přímo v sobě
• Klient bude zabalený jako spustitelný soubor pro Windows (PyWorking, možná v červnu)
• Nasadit server v cloudu

Řešte po #81

„Obrázky“ políčka jsou aktuálně reprezentovány jako dvojice (ID políčka, rotace). Dvojice není úplně ideální: když z ní chci jednotlivé prvky, musím dělat buď:

• value[0] a value[1] (takže není poznat co dostávám), nebo
• coordinate, rotation = value (což je super do té doby, než budu potřebovat další kousek informace, a bude potřeba všechno předělat na trojice).

Použijte na to místo dvojice třídu.

Napište hezčí ovládací písmenka přímo do toho rozhraní.

backend.py:

• robot.die()
• robot.walk()
• robot.move()

//Done.

• zeď
• vlajka (1-8)
• startovací políčka (1-8)
• laser (začátek, paprsek)
  • jednoduchý
  • dvojitý
  • trojitý
• posuvníky (pushers) (1/3/5 a 2/4)
• díra
• zem
• pohyblivý pás
  • 1 rovný
  • 1 křižovatka
  • 1 zatáčka (doprava, doleva)
  • 2 rovný
  • 2 křižovatka
  • 2 zatáčka (doprava, doleva)
• Otáčecí kolečko (doprava, doleva)
• Opravovací políčko
  • Vylepšovací políčko

Issues #84 (pohyb robota) a #82 (načítání efektů políček) vypadají že budou co nevidět vyřešené.
Myslím že je čas na první efekty políček!
Doporučuju se napřed zaměřit na zdi, než na ty ostatní.
Můžete přitom doladit, jak jsou efekty políček reprezentovány v kódu ­­– a zvášť jak reprezentujete zeď, #45.

• Políčka na jedné souřadnici by měly být u sebe, v jednom seznamu.
• Roboti by si měli pamatovat svoje souřadnice.

V backendu ve funkci move nahradí tento if:

if direction == 0:
    y += distance
elif direction == 90:
    x += distance
elif direction == 180:
    y -= distance
elif direction == 270:
    x -= distance

Z UML diagramů zůstalo nedořešené téma, jak bude definovaná zeď v rámci efektu políčka.
Otevírám tedy tímto téma k zamyšlení a diskusi.
Souvisí s #22.

Věcem které se používají v jiném kódu, jako názvy souborů a funkcí (from jmeno_souboru import jmeno_funkce), počet argumentů funkce (jmeno_funkce(1, 2, 3)) se říká API (application programming interface). Když se API nějaké funkce změní (přejmenuju soubor, změním počet argumentů), kód který tu funkci používal přestane fungovat.

Poznámky o tom, že je něco nedodělané, by neměly být součástí API. Pak totiž vznikají věci jako:

from backend_WIP import get_tiles, get_coordinates, get_data

… které bude potřeba všechny opravit, až se backend „dodělá“. (Kdy to bude? Žádný kód není úplně hotový a perfektní, jsou v něm jen nedodělky s větší nebo menší prioritou.)

Poznámky "WIP" stačí mít mít v komentářích, dokumentaci, nebo issues.

Opravit mapy - nyni jejich nacitani kolabuje: na cestach k souborum, na spatnem tilesetu atd.

Když robot vyjede z mapy, tak spadne hra.

Když robot nějakým způsobem zemře, nasadí se do hry až v následujícím kole, zbytek kola se na ploše neobjevuje

Během práce na načítacím modulu jsme se s @befeleme dostaly k otázce, zda by backendu neprospělo, kdyby se z něj vyčlenilo nejen načítání datového vstupu (u nás nyní JSON soubor vygenerovaný z Tiled), ale i všechno, co jen načítá cesty k obrázkům ve složkách.

Robot si nepamatuje kolik má životů, vlajek, zranění.
Potřebuji to načítat do Interface.

Přidat moduly:

• Backend
• Frontend
• Testy
• Hra

Až to bude hotové, smazat skript kde je to teď všechno.

Soubor README.md je vizitka projektu; GitHub ho ukazuje na hlavní stránce. Měly by tam být věci jako:

• co ten program dělá
• jak to nainstalovat (většinou předpokládám že čtenář má aktivované virt. prostředí, ale ten předpoklad tam zmíním),
• jak to spustit
• jak spustit testy
• jak se zapojit (zatím asi nechcete aby se do toho zapojovali cizí lidi)

Všemi velkými písmeny, např. WIDTH, se tradičně pojmenovávají konstanty – proměnné, které mají vždycky stejnou hodnotu.
Takové hodnoty není potřeba předávat funkcím jako argumenty. Použijte globální proměnnou (a jestli je nadefinovaná v jiném modulu, naimportujte si ji).

Aktuálně je stav hry jen mapa (slovník souřadnice → seznam políček). Bude k tomu potřeba přidat i seznam robotů, a případně pak nějaké zdi nebo jiné věci.

Udělejte si na stav hry dataclass, který bude obsahovat mapu a roboty. Roboti by se měli objevit na počátečních políčkách.

Čím víc lidí (nebo kousků kódu) používá nějakou funkci, tím je k ní důležitější napsat dokumentaci – popis toho, co ta funkce dělá. Člověk si může číst samotný kód, ale tam není všechno.

Dobrá jména funkcí a argumentů už jsou dokumentace sama o sobě. Třeba:

def add(a, b):
    return a + b

… je OK pro funkci, kterou používám někde níž v tom samém souboru. Když si ale jen přečtu kód, není jasné např. jestli je tuhle funkci dobré zavolat na řetězce, add("Hello, ", "world!").

def add(a, b):
    """
    Add two numbers

    `a` and `b` should be numbers (int or float).
    Returns the sum.
    """
    return a + b

Velké projekty, kde je potřeba aby se s kódem mohl každý co nejrychleji seznámit a korektně ho měnit, to berou fakt vážně, a dokumentace je často delší než samotný kód – viz třeba tenhle kód z Javy.
Používají se i nástroje, které ověří že každá funkce a každý argument jsou zdokumentované. To už je docela extrém (u mladšího projektu se pak může stát, že se změní kód ale neaktualizuje dokumentace, a dokumentace co neodpovídá kódu je horší než žádná dokumentace). Ale je dobré se u každého argumentu aspoň zamyslet, jestli o něm jméno říká všechno co je potřeba.

Do dokumentačních řetězců (viz materiály, nebo do vyhledávače dej docstring) je dobré psát co funkce dělá, jaké bere argumenty, co vrací. U složitějších struktur (seznam dvojic slovníků souřadnic) je dobré uvést příklad, aby si to člověk líp uvědomil
Do normálních komentářů je dobré psát jak se to dělá, jak funkce postupuje – věci, které nezajímají toho, kdo pak bude funkci volat.
Například:

def get_coordinates(data):
    """
    Get a list of tile coordinates for a map

    `data` is a dict loaded from a Tiled 1.2 JSON file.
    Returns a list of all tile coordinates, for example:
       [(0, 11), (0, 10), (0, 9), ..., (0, 0), (1, 11), (1, 10), ..., (11, 1), (11, 0)]
    """

    # Get the size of the game board from JSON
    map_field_height = data['layers'][0]['height']
    map_field_width = data['layers'][0]['width']

    # Create map - list of x, y tuples 
    # Transformation with reversed is required as the JSON tiles
    # are in the opposite y direction
    coordinates = []
    for y in reversed(range(map_field_height)):
        for x in range(map_field_width):       
            coordinates.append((x, y))

    return coordinates

Co se „štábní kultury“ týče, je dobré mít jeden řádek s krátkým (jednořádkovým!) popisem, pak řádek vynechat, a pak rozepsat detaily. Všechno v „trojitých dvojitých“ uvozovkách, """.

Zapnout integraci