Mrežno rivalstvo: igra s malim kašnjenjem za BBC Micro: bit: 10 koraka (sa slikama)

2024 Autor: John Day | [email protected]. Zadnja izmjena: 2024-01-30 08:06

U ovom vodiču ću objasniti kako implementirati osnovnu igru za više igrača na BBC micro: bit sa sljedećim značajkama:

• Jednostavno sučelje
• Mala kašnjenja između pritiskanja tipki i ažuriranja ekrana
• Fleksibilan broj učesnika
• Jednostavna kontrola igre pomoću glavnog daljinskog ("root") uređaja

Igra je u suštini simulacija politike. Svi igrači počinju neraspoređeni u bilo koji tim, osim dva igrača. Jedan od ovih igrača dodijeljen je timu A, a drugi timu B.

Cilj igre je da svaki igrač bude u timu s većinom igrača u trenutku kada su svi pretvoreni.

Gornji dijagram prikazuje stroj konačnih stanja, tj. Specifikaciju stanja u kojima uređaj može biti i prijelaze između tih stanja.

Stanje se može smatrati trenutnim skupom podataka koji opisuju memoriju uređaja od njegovog uključivanja. Na temelju tih podataka uređaj može izvesti određene radnje ili drugačije reagirati na unos korisnika.

Prijelaz je logički uvjet koji, kada je istinit, uzrokuje promjenu stanja uređaja. Prijelaz može biti iz jednog stanja u bilo koje drugo stanje. Stanje može imati više prijelaza.

Gornji dijagram navodi sljedeća stanja:

• Nije dodijeljeno
• Slušajte A.
• Slušajte B
• Tim A
• Tim B

Uređaj koji pokreće kôd igre može biti u bilo kojem od ovih pet stanja, ali samo jedno po jedno i to samo ovih pet.

Pretpostavljat ću u cijelom vodiču da koristite Microsoftov uređivač MakeCode, koji se može naći na:

Potpunu implementaciju igre možete pronaći ovdje:

makecode.microbit.org/_CvRMtheLbRR3 ("microbit-demo-user" je naziv projekta)

A implementaciju glavnog ("root") mrežnog kontrolera možete pronaći ovdje:

makecode.microbit.org/_1kKE6TRc9TgE ("microbit-demo-root" je naziv projekta)

Na ove primjere ću se pozivati u cijelom svom vodiču.

Korak 1: Razmatranja o dizajnu velike slike

Prije nego što napišemo bilo koji kôd, moramo razmisliti o tome kako želimo da izgleda naš krajnji proizvod. drugim riječima, koji su zahtjevi aplikacije? Šta bi naš kôd trebao reći uređaju da uradi kada završi? Podijelio sam funkcionalnost glavne aplikacije u šest kategorija, od kojih se svaka može posmatrati iz drugačije perspektive dizajna.

1. Želimo kontrolirati radnje uređaja na osnovu trenutnog stanja
2. Želimo da uređaj reagira na unos korisnika
3. Možda bismo htjeli prikazati animacije i grafike pomoću 5 x 5 LED zaslona
4. Želimo inicijalizirati vrijednosti podataka u memoriji uređaja kada se uređaj podigne
5. Želimo bežično prenositi podatke putem radija uređaja
6. Želimo slušati i primati podatke putem radija uređaja te ih u skladu s tim obraditi

Dozvolite mi da se detaljnije pozabavim svakom od njih.

1. Želimo kontrolirati radnje uređaja na osnovu trenutnog stanja

Kao i većina drugih programa, izvršavanje instrukcija navedenih u kodu događa se jedan po jedan red. Želimo da naš uređaj izvršava određene instrukcije na osnovu svog unutrašnjeg stanja, kako je prikazano na dijagramu pri vrhu ovog vodiča. Mogli bismo napisati niz uvjeta nakon svakog bloka koda koji provjerava da li uređaj treba raditi, ali ovaj pristup može vrlo brzo postati neuredan, pa ćemo umjesto toga koristiti beskonačnu petlju koja jednostavno provjerava jednu varijablu, a na osnovu te varijable, izvršava određeni skup uputa ili ne radi ništa. Ova varijabla će biti identificirana sufiksom "_state" i u našoj korisničkoj aplikaciji i u našoj root aplikaciji.

2. Želimo da uređaj reagira na unos korisnika

Uprkos normalnom izvršavanju koda koji se odvija uzastopno, to jest, jedan red po red, potreban nam je uređaj da reagira na pritiske tipki, dok glavna petlja stanja određuje što bi uređaj trebao učiniti u bilo kojem trenutku. U tu svrhu uređaj ima mogućnost slanja signala softveru nižeg nivoa koji stupa u interakciju s hardverom, pokrećući ono što se naziva događajem. Možemo napisati kôd koji govori uređaju da učini nešto kada otkrije određenu vrstu događaja.

3. Želimo prikazati animacije i grafike pomoću 5 x 5 LED ekrana

Čini se da je mehanizam za to jednostavan, ali blok za prikaz slike dodaje skriveno kašnjenje od 400 ms. Budući da želimo da naš uređaj nastavi izvršavati svoju petlju stanja sa što manje kašnjenja, morat ćemo urediti javascript kôd kako bismo smanjili kašnjenje.

4. Želimo inicijalizirati vrijednosti podataka u memoriji uređaja kada se uređaj podigne

Prije nego što naš uređaj učini bilo što, aplikacija mora učitati svoje podatke u memoriju. To uključuje konstantne varijable nazvane po čitljivosti koda, varijable koje sadrže slike, koje mogu biti dio animacije, te varijable brojača koje moraju početi s 0 da bi radile ispravno. Na kraju ćemo dobiti dugačak popis imena varijabli i njihovih novo dodijeljenih vrijednosti. Kao izbor osobnog stila označit ću konstantne vrijednosti, tj. Vrijednosti koje nikada neću morati mijenjati, koristeći ALL_CAPS. Takođe ću dati prefiks identifikatorima glavnih promenljivih sa nazivom kategorije koji se odnosi na neku vrstu objekta ili tipa pod koji identifikator potpada. Time se pokušava olakšati praćenje koda. Nikada neću koristiti naziv varijable poput "item" ili "x" zbog nejasnoća koje nastaju pri pokušaju dešifriranja koda.

5. Želimo bežično prenositi podatke putem radija uređaja

Ovo je zapravo prilično jednostavan zadatak kada se koristi jezik blokova MakeCode. Jednostavno postavljamo sve uređaje na istu radio grupu u vrijeme pokretanja, a zatim kada želimo poslati signal, možemo proslijediti jedan broj u blok "Radio send number" koji nam je dostavljen. Važno je da pošiljalac i primalac rade na istoj radio grupi, jer ako ne, oni će slati ili primati na različitim frekvencijama, a komunikacija će biti neuspješna.

6. Želimo slušati i primati podatke putem radija uređaja te ih u skladu s tim obraditi

Uzimajući u obzir ista razmatranja kao i prethodna stavka, slušat ćemo dolazne prijenose na isti način na koji ćemo slušati unos korisnika: s rukovaocem događaja. Napisat ćemo blok koda koji će ispitati sve dolazne signale i provjeriti treba li se poduzeti bilo kakva radnja bez ometanja glavne petlje stanja.

Osim toga, trebali bismo ukratko razmotriti dizajn daleko jednostavnije root aplikacije, programa koji će omogućiti uređaju da kontrolira cijelu mrežu. Neću trošiti puno vremena na ovo jer je daleko jednostavnije od gore navedenog dizajna i mnogo toga je jednostavno ponavljanje. Podijelio sam funkcionalnost root kocke u tri kategorije.

1. Želimo biti u mogućnosti odabrati signal
2. Želimo biti u mogućnosti prenijeti signal

-

1. Želimo biti u mogućnosti odabrati signal

To se može učiniti jednostavnim pritiskom tipke na ponavljanje mogućih signala. Budući da postoje samo tri, ovaj pristup će biti dovoljan. Istovremeno, možemo imati petlju koja stalno ponovo prikazuje odabrani signal, omogućavajući korisniku da pritisne dugme i vidi kako se odabrani signal pojavljuje na LED ekranu sa vrlo malim kašnjenjem.

2. Želimo biti u mogućnosti prenijeti signal

Budući da postoje dva gumba, možemo odrediti jedno za odabir, a drugo za potvrdu. Kao i korisnička aplikacija, signal jednostavno šaljemo putem mreže kao broj. Nisu potrebne druge informacije.

Više ću govoriti o jednostavnom protokolu signala u sljedećem odjeljku.

Korak 2: Signalni protokol: jednostavan jezik za mrežnu komunikaciju

Sljedeći signali mogu se smatrati skupom svih mogućih riječi koje uređaji mogu koristiti za međusobno razgovaranje. Budući da je mreža tako jednostavna, nema se puno toga za reći, pa možemo prikazati ova tri signala jednostavnim cijelim vrijednostima.

0. Resetiraj

• Identifikator u kodu: SIG-R
• Cijela vrijednost: 0
• Svrha: Recite svim uređajima u dometu da odustanu od onoga što rade i ponašaju se kao da su tek pokrenuti. Ako ovaj signal dopre do svakog uređaja na mreži, cijela mreža će se poništiti i korisnici mogu započeti novu igru. Ovaj signal može emitirati samo root uređaj.

1. Konverzija A

• Identifikator u kodu: SIG-A
• Cijela vrijednost: 1
• Svrha: Recite bilo kojem uređaju koji je u stanju LISTEN_A, kada primi signal konverzije, da se prebaci u stanje TEAM_A.

2. Konverzija B

1. Identifikator u kodu: SIG-B
2. Cijela vrijednost: 2
3. Svrha: Recite bilo kojem uređaju koji je u stanju LISTEN_B, kada primi signal konverzije, da se prebaci u stanje TEAM_B.

Korak 3: Želimo kontrolirati radnje uređaja na osnovu trenutnog stanja

Konačno, možemo početi pisati kod.

Prvo otvorite novi projekt u Make Code

• Kreirajte novu funkciju. Nazvao sam mine loop jer je ovo jezgra aplikacije
• Dodajte blok petlje koji će se ponavljati neograničeno dugo. Koristio sam while (true) jer doslovno true nikada neće biti lažno, stoga kontrolni tok aplikacije nikada neće izaći iz petlje
• Dodajte dovoljno blokova if-else da provjerite je li uređaj u nekom od pet mogućih stanja
• Kreirajte varijablu koja će zadržati trenutno stanje uređaja
• Kreirajte varijable koje predstavljaju svako od pet mogućih stanja

  Napomena: U redu je da ove varijable još nemaju dodijeljene vrijednosti. Doći ćemo do toga. U ovom trenutku je važnije da pišemo čist, lako čitljiv kod

• Promijenite svaki uvjet u blokovima if-else kako biste usporedili trenutno stanje s jednim od mogućih stanja
• Na dnu if-else blokova dodajte pauzu za određeni broj milisekundi i stvorite varijablu koja će držati taj broj. Inicijalizirat ćemo ga kasnije. Uvjerite se da varijabla ima opisni naziv, poput otkucaja ili otkucaja srca. Budući da je ovo jezgra uređaja, ova pauza će odrediti brzinu kojom uređaj izvršava glavnu petlju, pa je to vrlo važna vrijednost i previše je važna da bi bila magični broj bez imena.

Napomena: Ne brinite o sivim blokovima na trećoj slici. Doći ću do njih kasnije.

Korak 4: Želimo reagirati na unos korisnika

Sada želimo reći uređaju kako se rukuje pritiskom na tipke. Prva pomisao bi mogla biti jednostavno korištenje blokova "Kada se pritisne dugme" u kategoriji unosa, ali željeli bismo detaljniju kontrolu od toga. U naprednom odjeljku koristit ćemo blok "on event from (X) with value (Y)" iz kontrolne kategorije jer smo napredni u ovom vodiču.

• Napravite četiri bloka "o događaju od …".

  • Dvije od ovih bi trebale provjeriti izvor događaja "MICROBIT_ID_BUTTON_A"
  • Dva od ovih bi trebala provjeriti izvor događaja "MICROBIT_ID_BUTTON_B"

  • Od dva događaja koji ciljaju svako dugme:

    • Treba provjeriti ima li događaja tipa "MICROBIT_BUTTON_EVT_UP"
    • Treba provjeriti ima li događaja tipa "MICROBIT_BUTTON_EVT_DOWN"
  • Napomena: Ove opcije velikim slovima su oznake koje se koriste u nižem nivou micro: bit koda. Oni su jednostavno čuvari mjesta koja se kasnije zamjenjuju cijelim brojevima kada se kod prevede u izvršnu binarnu datoteku. Ljudima je lakše koristiti ove oznake nego tražiti koji cijeli broj staviti, iako bi obje radile na isti način.

• Izabrao sam, zbog stila, da svaki blok "on event from …" pozove funkciju koja opisuje podignuti događaj. Iako to nije strogo potrebno, po mom mišljenju ovo poboljšava čitljivost. Ako neko to želi, može staviti kôd za rukovanje događajima unutar samog bloka "on event from …".

  Napomena: Blok koda koji obrađuje odgovor uređaja na događaj intuitivno se naziva "rukovalac događajima"

• Dodajte, u svakom rukovatelju događaja, istu strukturu if-else koja se koristi za podjelu kontrolnog toka na osnovu stanja uređaja kao strukturu u glavnoj petlji stanja.
• Dodajte blokove dodjele koji mijenjaju to stanje uređaja kako je navedeno u našem dijagramu stanja
  • Znamo da kada je uređaj u stanju NIJE DODJELJENO, uređaj bi trebao reagirati na dugme A pritisnuto prelaskom u stanje LISTEN_A, i na dugme B pritisnuto prelaskom u stanje LISTEN_B
  • Također znamo da kada je uređaj u stanju LISTEN_A ili LISTEN_B, uređaj bi trebao reagirati na otpušteno dugme A i otpuštanje dugmeta B, prelaskom nazad u stanje NIJE DODJELJENO.

  • Konačno, znamo da kada je uređaj u stanju TEAM_A ili TEAM_B, uređaj bi trebao reagirati na pritisnuto dugme A i pritisnuto dugme B emitovanjem SIG_A i emitovanjem SIG_B.

    U ovom trenutku nije potrebno popuniti detalje o signalima za emitiranje. Na to ćemo doći kasnije. Ono što je važno je da mi uputimo ove funkcije da koriste kôd koji ćemo napisati dajući tom bloku radnji ime, poput broadcastSignalSIG_A, koji opisuje šta treba učiniti u tom trenutku

Korak 5: Želimo pokrenuti vrijednosti podataka u memoriji uređaja pri pokretanju uređaja

U ovom trenutku koristili smo mnogo varijabli (imena podataka), ali zapravo nismo tim vrijednostima dodijelili vrijednosti. Želimo da uređaj prilikom učitavanja učita vrijednosti svih ovih varijabli u memoriju, pa stavljamo inicijalizaciju za ove varijable u blok "na početku".

Ovo su vrijednosti koje moramo inicijalizirati:

• Signalne konstante, prema signalnom protokolu. Vrijednosti MORAJU biti:

  • SIG_R = 0
  • SIG_A = 1
  • SIG_B = 2
  • Napomena: Ja sam ovim konstantama stavio prefiks sa "EnumSignals" kako bih označio da se ove varijable ponašaju kao da su dio popisanog tipa koji se zove Signali. Ovako se ove varijable mogu implementirati u druge programske jezike. Definicija i objašnjenje nabrojanih tipova izlazi iz okvira mog vodiča. Netko može to tražiti na Googleu ako to želi. Ovi prefiksi su jednostavno stilski izbori i uopće nisu bitni za pravilno funkcioniranje programa.

• Konstante stanja, koje mogu biti proizvoljne sve dok imaju vrijednost. Odabrao sam stil da jednostavno koristim cijele brojeve uzlazno od 0, ovako:

  • NEPRIJEDLJENO = 0
  • LISTEN_A = 1
  • LISTEN_B = 2
  • TEAM_A = 3
  • TEAM_B = 4
  • Napomena: Donio sam istu stilsku odluku u vezi s prefiksima i za ove varijable. Osim toga, napomenuću da je sve oko ovih dodjela, vrijednosti i redoslijeda potpuno proizvoljno. Nije ni važno da su ove vrijednosti konzistentne od uređaja do uređaja, jer se koriste samo interno, a ne za komunikaciju putem mreže. Bitno je samo da varijable imaju vrijednost i da se mogu međusobno uspoređivati kako bi se vidjelo jesu li ekvivalentne ili ne.
• Radi čitljivosti, konstanta se zove BOOT_STATE i postavi je na UNASSIGNED. To čini činjenicu da smo se vratili u stanje pokretanja, umjesto u proizvoljnije stanje, eksplicitnije kada uređaj primi signal za resetiranje, što ćemo kasnije implementirati.

• Konstante animacije, korištene u sljedećem koraku za kreiranje animacija koje omogućavaju izuzetno niske latencijske prekide putem korisničkog unosa. Do sada ih nismo koristili, ali svakako će biti objašnjeni i korišteni u sljedećem odjeljku. Značenje nekih od njih trebalo bi biti intuitivno zbog njihovih naziva.

  • TICKS_PER_FRAME_LOADING_ANIMATION = 50
  • MS_PER_DEVICE_TICK = 10
  • MS_PER_FRAME_BROADCAST_ANIMATION = 500
  • MICROSECONDS_PER_MILLISECOND = 1000
  • NUMBER_OF_FRAMES_IN_LOADING_ANIMATION = 4

• Još jedna varijabla za animaciju, ovaj put brojač koji definitivno nije konstantan. Kao i većina brojača, mi ga inicijaliziramo na 0

  iTickLoadingAnimation = 0

• Napravite dvije serije varijabli za držanje okvira animacija. Prva, koju nazivam "animacija učitavanja", trebala bi imati četiri slike (koje ste možda pretpostavili posljednjom konstantnom inicijalizacijom), a druga koju nazivam "animacija emitiranja", koja bi trebala imati tri slike. Preporučujem imenovanje varijabli tako da odgovaraju okvirima animacije, npr. ringAnimation0, ringAnimation1…

  Kreirajte iste vrednosti slike kao ja ili kreirajte originalnije i hladnije slike

• Na kraju, ali ne i najmanje važno, moramo postaviti radio grupu uređaja na 0 pomoću bloka "grupa radio -grupa (X)"
• Opcionalno, na serijski izlaz napišite poruku "Inicijalizacija je dovršena" kako biste rekli korisniku da je sve proteklo u najboljem redu.
• Sada kada smo završili s postavljanjem uređaja, možemo pozvati našu funkciju petlje stanja.

Korak 6: Želimo prikazati animacije i grafiku pomoću 5 X 5 LED ekrana

A sada nešto sasvim drugo.

Želimo prikazati nekoliko animacija i nekoliko znakova, ali ne želimo prekidati glavnu petlju stanja. Nažalost, blokovi koji prikazuju slike i tekstualne nizove imaju zadano kašnjenje od 400 ms. Nema načina da se ovo promijeni bez uređivanja javascript prikaza koda. Dakle, ovo ćemo učiniti.

• Kreirajte funkciju za svaku sliku. To će omogućiti korištenje jednog bloka za prikaz slike umjesto uređivanja javascripta svaki put. U ovom se posebnom programu nijedna slika ne koristi više od jednom, ali i dalje mislim da ovaj stil čini kod lakšim za čitanje.
• U svaku novu funkciju dodajte blok "prikaži sliku (X) na pomaku 0" s odgovarajućim imenom varijable slike koje zamjenjuje (X)

• Dodaj, u glavnoj petlji stanja. Blokove "Prikaži niz (X)" svakom bloku osim onom koji rukuje sa stanjem UNASSIGNED. Dodajte znak za prikaz uređaja kako biste naznačili različita stanja. Evo šta sam uradio:

  • LISTEN_A: 'a'
  • LISTEN_B: 'b'
  • TEAM_A: 'A'

  • TEAM_B: 'B'

    Za stanje UNASSIGNED, uputite poziv funkciji koja će ažurirati animaciju učitavanja. U nastavku ćemo popuniti detalje ove funkcije

• Prebacite se u javascript način.
• Pronađite svaki poziv na X.showImage (0) i basic.showString (X)

• Promijenite svaku pojedinačno u X.showImage (0, 0) ili basic.showString (X, 0)

  • Dodavanje ovog dodatnog argumenta će postaviti kašnjenje nakon akcije na 0. Podrazumevano je ovo izostavljeno, a uređaj će pauzirati 400 ms nakon izvršavanja svakog od ovih blokova.
  • Sada imamo mehanizam bez kašnjenja koji prikazuje naše slike u našim animacijskim blokovima, koje sada možemo izgraditi

Prvo ćemo izgraditi relativno jednostavnu funkciju animacije emitiranja. Jednostavnije je jer ne želimo da korisnik može učiniti bilo što dok se funkcija ne dovrši, kako bi se spriječilo njihovo neželjeno emitiranje funkcije emitiranja. Da bismo to postigli, možemo jednostavno držati kontrolni tok ograničen na blok dok se funkcija ne dovrši, što je standardno ponašanje.

• Kreirajte funkciju koja će prikazivati emitiranu animaciju.
• Unutar tog bloka dodajte tri poziva funkcija, po jedan u svaki okvir animacije, redoslijedom kojim bi trebali biti prikazani

• Dodajte blok "wait (us) (X)" nakon svakog poziva funkciji prikaza slike.

  Napomena: Ovaj blok, iz odjeljka napredne kontrole, ići će čak i dalje od "pauze (ms)" jer će potpuno zamrznuti procesor dok ne istekne navedeno vrijeme. Kada se koristi blokada pauze, moguće je da će uređaj obavljati druge zadatke iza scene. To je nemoguće sa blokom čekanja

• Zamijeni (X) sa (MS_PER_FRAME_BROADCAST_ANIMATION x MICROSECONDS_PER_MILLISECOND)
• Animacija bi sada trebala pravilno funkcionirati

Drugo, izgradit ćemo mehanizam za prikaz animacije učitavanja. Ideja iza ovoga je ažuriranje LED ekrana u određenom intervalu, koji definiramo u varijabli MS_PER_DEVICE_TICK. Ova vrijednost, dužina ključa uređaja, je broj milisekundi koje uređaj pauzira nakon završetka svake iteracije petlje stanja. Budući da je ova vrijednost dovoljno mala, možemo ažurirati prikaz jednom tijekom svake iteracije prikazane petlje i korisniku će se učiniti da animacija neprimjetno napreduje, a kada se stanje promijeni, bit će vrlo malo kašnjenja između unosa korisnika displej se ažurira. Brojanjem krpelja, što radimo s varijablom iTickLoadingAnimation, možemo prikazati odgovarajući okvir animacije.

• Kreirajte funkciju koja će ažurirati animaciju učitavanja
• Dodajte uvjet da provjerite je li brojač krpelja dostigao maksimalnu vrijednost. Ovaj uvjet će biti istinit ako je vrijednost brojača tikova veća od broja sličica u animaciji učitavanja pomnoženog s brojem kvačica za prikaz svakog okvira

  Ako je uvjet istinit, vratite iTickLoadingAnimation na 0

• Dodajte blok if-else uslova. Oni će odrediti koji okvir animacije će se prikazati.

  Za svaki okvir animacije, ako je brojač tikova manji od broja kvačica u svakoj animaciji pomnoženog s brojem okvira animacije (počevši od 1), tada prikažite taj okvir, inače provjerite je li sljedeći okvir onaj koji će biti prikazano

• Na dnu bloka povećajte iTickLoadingAnimation
• Animacija bi sada trebala pravilno funkcionirati

Napomena: Svi sivi blokovi koji se pojavljuju u mom primjeru generiraju se kada se uredi javascript prikaz bloka. To jednostavno znači da blok predstavlja javascript kod koji se ne može prikazati pomoću standardnog skupa blokova i mora se urediti u tekstualnom obliku.

Korak 7: Želimo bežično prenositi podatke pomoću radija uređaja

Ovaj korak je daleko kraći od prethodnog. Zapravo, to je vjerojatno najkraći korak u cijelom ovom vodiču.

Podsjetimo se da smo, kad smo programirali odgovor uređaja na unos korisnika, imali dva bloka na snimku ekrana koji nisu objašnjeni u tom odjeljku. To su bili pozivi funkcijama koje šalju signale putem radija. Preciznije:

• Pritisnuto dugme za uključivanje A:

  • Ako je uređaj u stanju TEAM_A:

    Emitirani signal SIG_A

• Pritisnite dugme B za uključivanje:

  • Ako je uređaj u stanju TEAM_B

    Emitirani signal SIG_B

Kreirajte ove funkcije ako već ne postoje.

U svakoj funkciji:

• Pozovite funkciju animacije emitiranja. Ovo će spriječiti da se bilo što drugo dogodi dok se ne završi, što će biti za MS_PER_FRAME_BROADCAST_ANIMATION * 3 = 1,5 sekunde. Konstanta se množi s tri jer u animaciji postoje tri okvira. Ovo je proizvoljno i može se dodati više ako je estetska nadogradnja dovoljno velika. Druga svrha ove animacije je spriječiti korisnika da spamira funkciju emitiranja.
• Dodajte blok "radio send number (X)", gdje je konstanta signala spomenuta u nazivu funkcije

To je sve što je potrebno za emitiranje putem radija.

Korak 8: Želimo slušati i primati podatke putem radija uređaja i prema tome ih obraditi

Ovo je posljednji korak za kreiranje glavne aplikacije.

Reći ćemo uređaju kako obrađivati dolazne radio signale. Prvo će naš uređaj imenovati primljeni signal. Zatim će, na osnovu vrijednosti tog signala, odlučiti koju radnju treba poduzeti, ako postoji.

Prvo:

1. Napravite blok koda koji počinje blokom "primljeno na radiju (X)".
2. Opcionalno, dodijelite tu primljenu vrijednost drugoj varijabli s opisnijim imenom.
3. Pozovite funkciju koja će obraditi signal

Drugo, u funkciji obrade signala:

1. Napravite blok if-else naredbi koje granaju kontrolu protoka na osnovu vrijednosti signala.

2. Ako je signal bio SIG_R

   Postavite stanje uređaja na BOOT_STATE (zato smo ovu konstantu stvorili ranije)

3. Ako je signal bio SIG_A i ako je trenutno stanje LISTEN_A

   Postavite stanje uređaja na TEAM_A

4. Ako je signal bio SIG_B i ako je trenutno stanje LISTEN_B

   Postavite stanje uređaja na TEAM_B

To je to. Prijava je završena.

Korak 9: Root uređaj: Želimo biti u mogućnosti odabrati signal

Sada ćemo napisati jednostavnu aplikaciju za "root" uređaj, odnosno uređaj koji će kontrolirati mrežu.

Ovaj uređaj će morati obavljati dvije funkcije:

• Želimo omogućiti korisniku da odabere jedan od naših signala
• Želimo omogućiti korisniku emitiranje signala

Budući da su specifikacije ove aplikacije podskup prethodnih, dat ću pregled, ali neću ulaziti u toliko detalja kao prije. Gornja slika sadrži potpuni kod za ovu aplikaciju.

Da biste omogućili korisniku odabir signala:

1. Inicijalizirajte 5 varijabli u bloku "na početku":

   1. Tri signala (0, 1, 2)
   2. Broj signala (3)
   3. Varijabla koja zadržava trenutno odabrani signal (inicijalno postavljen na prvi signal, 0)

2. Pritisnite i držite dugme A:

   1. Povećajte odabrani signal
   2. Provjerite je li odabrani signal veći ili jednak broju signala

      Ako je tako, postavite odabrani signal na 0

3. Nakon početnog bloka, pokrenite "zauvijek" petlju koja prikazuje trenutnu odabranu vrijednost signala bez kašnjenja

Omogućiti korisniku emitiranje signala

1. Postavite radio grupu na 0 u bloku "pri pokretanju"

2. Držite pritisnutim dugme B:

   Emitirajte odabrani signal pomoću bloka "radio send number (X)"

To je to. Aplikacija root čvora je izuzetno jednostavna.

Korak 10: Završili smo

Iznad je slika uređaja koji pokreću aplikaciju. Dvojica s desne strane pokreću glavnu "korisničku" aplikaciju, a ona s lijeve strane pokreće "root" aplikaciju.

Pokazao sam ovu igru na CS Connections 2018, jednonedeljnoj ljetnoj konferenciji za nastavnike srednjih i srednjih škola o obrazovanju računarstva. Učiteljima sam dao oko 40 uređaja i objasnio im pravila. Većina je igru smatrala zabavnom, a mnogima je bila zbunjujuća sve dok nisu shvatili kako se igra. Demonstracije su bile kratke, ali otkrili smo da je igra ugodna među prilično raznolikom publikom.

Više informacija o CS Connections 2018 možete pronaći ovdje.