rafalb.com

Design by Contract (TM) to technika programowania defensywnego, postulująca jawne specyfikowanie interfejsów komponentów, np. poprzez deklarowanie warunków, które muszą spełniać argumenty metod (to w zasadzie najczęstszy przypadek). Zwykle w projektach realizujemy to wymaganie albo poprzez zwykłe if-y rzucające ArgumentException, albo tworząc statyczne klasy pomocnicze, takie jak Check czy Require. Od pewnego czasu dostępne jest narzędzie Code Contracts opracowane przez Microsoft Research i to z niego zdecydowałem się skorzystać w projekcie EuroManager. Czytaj dalej...

Zawodnik w czasie biegu zwrócony jest w stronę wskazywaną przez jego wektor prędkości, natomiast stojąc zwykle stara się obrócić w kierunku piłki. Ten mechanizm jest tak naprawdę potrzebny głównie do odpowiedniego wyświetlania ikonek piłkarzy. Najprościej byłoby zaimplementować to w taki sposób, żeby w każdej klatce ustawiać kąt obrotu zawodnika na zgodny z kierunkiem ruchu i przy wyświetlaniu obracać obrazek reprezentujący piłkarza o taki właśnie kąt. Oczywiście, gdyby takie podejście działało poprawnie, nie napisałbym tego artykułu. Czytaj dalej...

Podobnie jak w przypadku piłki, w tym artykule zamierzam się skupić na mechanicznych (fizycznych) aspektach ruchu, pomijając na razie cały proces podejmowania decyzji, który zresztą wymaga jeszcze wiele pracy. Generalnie implementacja zachowania zawodników na boisku podzielona jest na trzy odrębne komponenty, jak można zobaczyć na poniższym diagramie. Czytaj dalej...

Logika biznesowa projektu jest w znaczącej większości pokryta testami jednostkowymi. Od pewnego momentu do każdej nowej funkcjonalności staram się stosować podejście Test-Driven Development, pisząc najpierw testy ją definiujące. Nie robiłem tego od samego początku, bo wahałem się czy w ogóle będzie to możliwe i wygodne w systemie, który praktycznie działa jako aplikacja czasu rzeczywistego. Okazało się jednak, że dzięki kilku prostym posunięciom mogę z powodzeniem stosować testy jednostkowe i TDD, a nawet więcej - nie wyobrażam sobie teraz rozwijania tego projektu w inny sposób. Czytaj dalej...

Opis implementacji mechanicznych zachowań obiektów (bo sztuczna inteligencja to inna sprawa) rozpocznę od najprostszego przypadku, czyli od piłki. Jest on prosty dlatego, że nie uwzględniam na razie jej rotacji, więc wszystko sprowadza się do ruchu po kopnięciu przez zawodnika i opóźnienia w wyniku kontaktu z podłożem. Czytaj dalej...

Po trzytygodniowej przerwie spowodowanej urlopowymi wyjazdami, chorobą i - na deser - awarią serwera, wracam do opisywania postępów w projekcie EuroManager (przypominam: konkurs Daj się poznać). W najbliższych dniach postaram się nadrobić to dłuższe milczenie z nawiązką. Dzisiaj rozpoczynam cykl artykułów poświęconych najważniejszej części aplikacji, czyli logice symulatora meczów. Czytaj dalej...

W poprzednich artykułach opisałem dość szczegółowo implementację odtwarzacza relacji meczowych, zrealizowanego jako aplikacja Silverlight umieszczona na stronie ASP.NET MVC. Skomplikowaną kwestią okazało się przekazywanie danych wejściowych do tej aplikacji. W większości przypadków w takich sytuacjach potrzebujemy przekazać tylko proste informacje, jak nazwa użytkownika czy ID, po którym - poprzez usługi WCF - możemy dociągnąć resztę danych. Tutaj jednak wolałem unikać opierania się o WCF (potencjalne problemy hostingowe), a zakres danych do przekazania jest dość obszerny. Czytaj dalej...

W poprzednim artykule opisałem mechanizm relacji meczowych od strony widoku, teraz z kolei czas zająć się tym trudniejszym (choć nie tak bardzo) elementem układanki, czyli view modelem i logiką prezentacyjną. Czytaj dalej...