Ramy czasowe projektu
Jak rozumiem każdy miał co innego na głowie, stąd jak do tej pory nic się w projekcie nie stało. Jednakże 16 czerwca kończy się nam rok akademicki, więc fajnie by było w piątek 12 czerwca zakończyć drugą iterację. A skoro tak, to pierwszą musimy zrobić na 29 maja. Tak, to za tydzień! Mamy jak by na to nie patrzeć pewien natłok obowiązków, jednak mam nadzieję że sobie poradzimy. Potrzebne by było, żeby jutro pojawiło się rozbicie user stories na ficzery, potem zaś na taski. Choć przyznam od razu, że większość user stories i tak opisuje jedną funkcjonalność, więc ten krok pośredni niekoniecznie musi mieć sens. Tak czy owak roboty sporo, czasu mało, więc zapraszam do zabawy.
Michał: Zaczynałem się obawiać, że pomarliście. Czasu jest bardzo niewiele, a widząc brak aktywności zaczynam się obawiać, że zakopaliście się w przerzucanie rzeczy po tracu, tudzież działa syndrom dużego komitetu i nikt nie czuje się za nic odpowiedzialny. Jeśli czujecie się skołowani i nie bardzo macie wizję tego co jest ważne i w którą stronę pójść najpierw to nie czekajcie, tylko walcie z pytaniami, możemy w każdej chwili uruchomić stronę dyskusji. No a jeśli tak jest w istocie, to na Waszym miejscu spróbowałbym osiągnąć kilka podstawowych celów, do których reszta będzie nadbudówką:
1) skompilować pustą aplikację z PALem (a jak się nie da to w Bullecie or sth)
2) stworzyć prostą klasę animata, która będzie go reprezentować przez takie rzeczy jak pozycja w świecie, masa, promień, kierunek
3) zrobić prostą wizualizację w OpenGL (póki co lokalną), to sfery więc sprawa jest trywialna
4) dodać ileś takich stworów do systemu, ustawić im jakieś losowe wektory ruchu i zobaczyć, że to się rusza, przy tej okazji dużo się nauczycie o tym jak zachowuje się system fizyki, dotąd piece of cake.
5) zobaczyć jak działa detekcja kolizji, tzn. upewnić się, że engine fizyczny nie robi czegoś bardzo głupiego typu sprawdzanie przecinania się poligonów z których złożone są sfery, a jedynie porównuje odległości między ich środkami
6) dorzucić parę punktowych animatów robiących za pożywienie i opadających na dno
7) dołożyć proste aktuatory na sferach (stałe popychanie) oraz sensory stwierdzające odległość do najbliższego kawałka jedzenia. Dopisać program sterowania animatem taki, żeby mając jeden sensor po lewej, jeden po prawej, zależnie od tego który notuje większą odległość od najbliższego kawałka jedzenia odpowiednio uruchamiał aktuator i obracał kierunek ruchu animata w stronę tego kawałka. Zademonstrować, że to pływa. Też piece of cake, ale trzeba będzie napisać już parę linijek własnego kodu.
od Krzysztof Giaro <giaro@eti.pg.gda.pl> Witam,
Przypominam, ze zbliza sie koniec semestru, a wiec i zaliczenie pierwszej czesci projektu grupowego. Zgodnie z umowa mieliscie Panowie przygotowac wiekszosc oczekiwanego przez klienta oprogramowania w obecnym polroczu laczac w ten sposob zajecia projektowe z seminarium, tak by kolejny semestr mozna bylo przeznaczyc na poprawianie usterek. Poniewaz w najblizszym czasie bede wystawial oceny z "Elementow Bioinformatyki", zamierzam niebawem dowiedziec sie od klientow czy uzyskali juz od Panow oczekiwane oprogramowanie w satysfakcjonujacym ich stanie, aby na podstawie ich oceny Waszej wspolpracy wystawic stopnie z przedmiotu. Jezeli zatem projekt Panow wymaga pewnych udoskonalen, prosze o wprowadzenie ich teraz, aby jakowes niedopatrzenia nie spowodowaly klopotow z zaliczeniem.
Pozdrawiam,
