i003_z006 (Akcelometr )

[mzglicz]

Nazwa funkcjonalności: Dodanie obsługi akcelometru

Opis zadania (co najmniej 50 słów) Dodam obsługę akcelometru, żeby w sytuacji kiedy człowiek przytrzyma palcem ekran i przechyli ekran to żeby potworki leciały zgodnie z akcelometrem

Wpływ zadanie na dotychczas zaimplementowane funkcjonalności: Nowy feature w grze

Diagram sekwencji:

Oszacowany czas przewidziany na realizację zadania: Do końca iteracji

[mzglicz]

Opis implentacji (bardziej znaczące algorytmy największe trudności): Znowu algorytmów zabójczych nie ma. Co zmieniłem i dlaczego : w GameObject dodałem metode Update(GameTime gt, int dx,int dy) zawsze powinno być |dx| +|dy| = 1 Jest to kierunek wytyczony przez akcelometr, Jedynie w klasie Enemy robi coś sensownego ( w pozostałych wywołuje Update(gt), bo może bedziemy chcieli by bomy się przesuwały ? )

Enemy powinien lecieć w kierunku w którym wyznacza wektor (dx,dy). Tyle, że może sie okazać to niemożliwe dlatego dodałem w Enumie faced Stoped i zdefinowałem jego kierunek jako Point(0,0). W ten sposób zatrzymuje Enemy. Teraz w zależności od wartości accelometerOn w GamePlayScreen albo wywołuje Update(gt) albo Update(dx,dy).

Wykorzystuje biblioteki: Microsoft.Devices.Sensors;

Zmiany w stosunku do podanego wcześniej opisu zadania: Brak Zmiany w stosunku do podanego wcześniej wpływu na dotychczas zaimplementowane funkcjonalności: W sytuacji jak gracz wykona GestureType.Hold na ekranie to włącza się akcelometer i wszystkie stworki(Enemy) lecą w strone w którą wskazuje wymieniony wyżej akcelometer. Zmiany w stosunku do podanego wcześniej diagramu sekwencji (nowy diagram)

Zmiany w stosunku do podanego wcześniej szacunkowego czasu przewidzianego na realizacje zadania : Okazało się być prostsze niż myślałem.

[mzglicz]

Do zastanowienia się : Czy nie lepiej było by przesuwać stworki po dwóch osiach naraz tzn: Rozumiem, że ruch np (1,1) nie jest legalny bo stworki nie poruszają się po skosach ale można by przesyłać pierwszy i drugi kierunek tzn (os1, val1), (os2,val2) i mechanizm ruchu byłby taki : jeśli da się isć po os1 o wartosc val1 to zrób tak w przeciwnym razie spróbuj po osi os2 i wartość val2. W obecnej sytuacji przesyłam jednie tak (os1,val1) zakodowane w parze (dx,dy)

[mm4tt]

Trochę mi się nie podoba, że zmieniłeś interface. Czy było to konieczne?

Nie lepiej w klasie GameplayScreen obsługiwać wszystkie wejścia od gracza i w miejscu gdzie wykrywamy, że akcelerometr zanotował deltę robimy: foreach( var e in Engine.Instance.Enemies ) { var p = e.position += delta; if( Engine.Instance.Maze.isPassble(p.x,p.y) ) //czy jakies inne sprawdzenie czy nie ma murku e.position = p;
}

Oczywiście taki kod wymaga najpierw poprawki Stefana.

Zmiana intrefejsu wiąże się z tym, że musimy przerabiać cały kod. Będzie trzeba mergować nasze branche, poza tym dorzucamy argumenty, które w większości przypadków są bezużyteczne. Przypomina mi to WinApi, gdzie funkcje mają po 16 argumentów, z których podaje się 2-3 :)

[mzglicz]

Rozumiem twój ból ale uważam, że rozwiązanie które proponujesz nie jest optymalne. Według mnie najsensowniejsze rozwiązaniem, żeby nie zmianiać interfaceu było by przenieść wiedze o akcelometrze do Engine wtedy każdy obiekt osobno mógłby w swojej funkcje Update uznać jak się zachowa, przy accelometerOn i jakimś tak dx,dy które będą polami w Engine Rozwiązanie które proponujesz nie jest zgodne z płynnym ruchem który zaimplementował Stefan (chyba, że chcemy z tego zrezygnować, to są te poprawki).

Jak spojrzałem w swoje rozwiązanie to jest trochę copy and paste za dużo.

Jeśli dobrze rozumiem w rozwiązaniu które propnujesz Enemy przesuwał się dwukrotnie ? Raz zgodnie ze strategią w Update w Engine a za drugim razem w GamePlay'u?

W dniu 3 maja 2013 19:19 użytkownik IIUJ-MateuszMatejczyk < notifications@github.com> napisał:

Trochę mi się nie podoba, że zmieniłeś interface. Czy było to konieczne?

Nie lepiej w klasie GameplayScreen obsługiwać wszystkie wejścia od gracza i w miejscu gdzie wykrywamy, że akcelerometr zanotował deltę robimy: foreach( var e in Engine.Instance.Enemies ) { var p = e.position += delta; if( Engine.Instance.Maze.isPassble(p.x,p.y) ) //czy jakies inne sprawdzenie czy nie ma murku e.position = p;

}

Oczywiście taki kod wymaga najpierw poprawki Stefana.

Zmiana intrefejsu wiąże się z tym, że musimy przerabiać cały kod. Będzie trzeba mergować nasze branche, poza tym dorzucamy argumenty, które w większości przypadków są bezużyteczne. Przypomina mi to WinApi, gdzie funkcje mają po 16 argumentów, z których podaje się 2-3 :)

Reply to this email directly or view it on GitHubhttps://github.com/bbsszz/yapg/issues/14#issuecomment-17406841 .

Pozdrawiam, Maciej Zgliczyński

[mm4tt]

Moim zdaniem powinien się przesuwać dwukrotnie, bo to jest jakby dodatkowa siła, która działa na wrogów.

Poza tym dogranie płynności to jest tak naprawdę znalezienie dobrych wartości update rate i tego jak często akcelerometr zbiera dane, więc również nie widzę tutaj problemu. Nawet chyba powinno być tak, że akcelerometr działa powiedzmy 1.3 razy częściej niż normalny update, wtedy będzie widoczne ściąganie, ale wrogowie mogą się przeciwstawiać.

Jeszcze trzeba wyłączyć ruchy playera na czas działania akcelerometru, ale to już lepiej modyfikować jedną klasę(Playera) niż wszystkie, w sensie dodać jakieś metody, które będą włączać i wyłączać jego update.

Nie chce się czepiać, po prostu napisałem jak moim zdaniem to powinno wyglądać :) Tak i tak będzie działać i raczej nie będzie się już dużo tutaj zmieniać, więc jak dla mnie to nawet może tak zostać. Możesz to zaimplementować, możesz zostawić. Up to you, nie ma spiny :)

[mzglicz]

A propo Player'a to sposób w jaki teraz jest zaimplewany to accelometr działa tylko wtedy jeśli wykonamy Hold na telefonie, czyli oprócz jakiegoś dokończenia ruchu to i tak player nie będzie się nie będzie wstanie ruszyć. Przynajmniej ta Nokia Lumia 800 na której testuje nie obsługuje takiej sytuacji.

Dobra narazie zmienie interface i przerzuce wiedze o akcelometrzez do engine i przez to interfacy nie będą się zmieniać, i kod zmieni się tylko w Enemy.

Z tą płynnością to chodzi mi o to że Stefan ma taką sytuacje, że stowrki przesuwają się między polami płynnie (kombinacja wypukła pola na którym jest i pola na które zmierza) teraz jeżeli dobrze rozumiem twoją propozycje to chciałbyś żebym jeszcze przeleciał po Enemies i ich przesuną o jedno pole. Co wydaje mi się że da wrażenie teleportu. Po drugie może sprawić że pole do którego zmierzamy nie będzie osiągalne, tzn z poziomu GamePlayScreen czy Engine nie dokońca mam dostęp (w nowje wersji będę miał bo pola musiałem zrobić publiczne by serializować) do kierunku w którym lecą stworki. Teraz jeżeli zmienie pole na którym jest stworek nie ruszając jego kierunku ruchu to może się okazać , że będę się przemieszczał do pola zajętego (którego pole obok jest wolne i tam zmierzał Enemy ale akcelometr go przesunał)

Narazie klepnę to co mi się wydaje. Jak ustalimy twoją wizje to odbije do innego brancha i ją też zaimplentuje. Chciałbym tego taska zamnknąc w ten weekend a najlepiej dzisiaj. Bo mam trochę rzeczy i stęskniłem się za swoim dowodem osobistym (chce oddać telefon).

W dniu 3 maja 2013 23:22 użytkownik IIUJ-MateuszMatejczyk < notifications@github.com> napisał:

Moim zdaniem powinien się przesuwać dwukrotnie, bo to jest jakby dodatkowa siła, która działa na wrogów.

Poza tym dogranie płynności to jest tak naprawdę znalezienie dobrych wartości update rate i tego jak często akcelerometr zbiera dane, więc również nie widzę tutaj problemu. Nawet chyba powinno być tak, że akcelerometr działa powiedzmy 1.3 razy częściej niż normalny update, wtedy będzie widoczne ściąganie, ale wrogowie mogą się przeciwstawiać.

Jeszcze trzeba wyłączyć ruchy playera na czas działania akcelerometru, ale to już lepiej modyfikować jedną klasę(Playera) niż wszystkie, w sensie dodać jakieś metody, które będą włączać i wyłączać jego update.

Nie chce się czepiać, po prostu napisałem jak moim zdaniem to powinno wyglądać :) Tak i tak będzie działać i raczej nie będzie się już dużo tutaj zmieniać, więc jak dla mnie to nawet może tak zostać. Możesz to zaimplementować, możesz zostawić. Up to you, nie ma spiny :)

Reply to this email directly or view it on GitHubhttps://github.com/bbsszz/yapg/issues/14#issuecomment-17418954 .

Pozdrawiam, Maciej Zgliczyński

[mzglicz]

Dobra Mateusz masz w branchu i003_z006b wywalone płynne poruszanie się i nakładanie ruchu akcleometra. Obczaj i stwierdź co myślisz. Kod może byc trochę syfny ale chodzi głównie o to bys obczaił które Ci bardziej pasuje.

W dniu 4 maja 2013 10:58 użytkownik Maciej Zgliczyński zglicz@gmail.comnapisał:

A propo Player'a to sposób w jaki teraz jest zaimplewany to accelometr działa tylko wtedy jeśli wykonamy Hold na telefonie, czyli oprócz jakiegoś dokończenia ruchu to i tak player nie będzie się nie będzie wstanie ruszyć. Przynajmniej ta Nokia Lumia 800 na której testuje nie obsługuje takiej sytuacji.

Dobra narazie zmienie interface i przerzuce wiedze o akcelometrzez do engine i przez to interfacy nie będą się zmieniać, i kod zmieni się tylko w Enemy.

Z tą płynnością to chodzi mi o to że Stefan ma taką sytuacje, że stowrki przesuwają się między polami płynnie (kombinacja wypukła pola na którym jest i pola na które zmierza) teraz jeżeli dobrze rozumiem twoją propozycje to chciałbyś żebym jeszcze przeleciał po Enemies i ich przesuną o jedno pole. Co wydaje mi się że da wrażenie teleportu. Po drugie może sprawić że pole do którego zmierzamy nie będzie osiągalne, tzn z poziomu GamePlayScreen czy Engine nie dokońca mam dostęp (w nowje wersji będę miał bo pola musiałem zrobić publiczne by serializować) do kierunku w którym lecą stworki. Teraz jeżeli zmienie pole na którym jest stworek nie ruszając jego kierunku ruchu to może się okazać , że będę się przemieszczał do pola zajętego (którego pole obok jest wolne i tam zmierzał Enemy ale akcelometr go przesunał)

Narazie klepnę to co mi się wydaje. Jak ustalimy twoją wizje to odbije do innego brancha i ją też zaimplentuje. Chciałbym tego taska zamnknąc w ten weekend a najlepiej dzisiaj. Bo mam trochę rzeczy i stęskniłem się za swoim dowodem osobistym (chce oddać telefon).

W dniu 3 maja 2013 23:22 użytkownik IIUJ-MateuszMatejczyk < notifications@github.com> napisał:

Moim zdaniem powinien się przesuwać dwukrotnie, bo to jest jakby dodatkowa

siła, która działa na wrogów.

Poza tym dogranie płynności to jest tak naprawdę znalezienie dobrych wartości update rate i tego jak często akcelerometr zbiera dane, więc również nie widzę tutaj problemu. Nawet chyba powinno być tak, że akcelerometr działa powiedzmy 1.3 razy częściej niż normalny update, wtedy będzie widoczne ściąganie, ale wrogowie mogą się przeciwstawiać.

Jeszcze trzeba wyłączyć ruchy playera na czas działania akcelerometru, ale to już lepiej modyfikować jedną klasę(Playera) niż wszystkie, w sensie dodać jakieś metody, które będą włączać i wyłączać jego update.

Nie chce się czepiać, po prostu napisałem jak moim zdaniem to powinno wyglądać :) Tak i tak będzie działać i raczej nie będzie się już dużo tutaj zmieniać, więc jak dla mnie to nawet może tak zostać. Możesz to zaimplementować, możesz zostawić. Up to you, nie ma spiny :)

Reply to this email directly or view it on GitHubhttps://github.com/bbsszz/yapg/issues/14#issuecomment-17418954 .

Pozdrawiam, Maciej Zgliczyński

Pozdrawiam, Maciej Zgliczyński

[mm4tt]

Sorry, myślałem, że dodałem ten komentarz rano, a zapomniałem kliknąć comment :) Tak więc:

Dobra, teraz łapie o co chodzi z tą płynnością ruchu. I wytłumaczyło się dlaczego Stefan trzyma współrzędne ekranowe, a nie położenie na gridzie. Jak dla mnie to nie powinno być żadnej płynności ruchu, Labirynt jest z założenia dyskretny i nie powinno być stanów pośrednich jeżeli chodzi o położenie. Na pewno nie w warstwie modelu naszego silnika.

Dopisze w tasku Stefana, żeby to wywalił. Jak chcemy mieć płynność to jest zadanie grafiki, więc powinno się dodać jakąś animację, trwającą między updatami. Wtedy update Enemy aktualizowałby położenie, akcelerometr zaktualizuje położenie, a sama metoda draw działająć na wypadkowym przemieszczeniu i zapewni wrażenie płynności poprzez odpowiednią animację. Wystarczy, żeby Draw wykonywało się kilka razy częściej niż update i zapamiętywało położenie na ekranie. Płynność zostanie i nasz model silnika będzie spójny i taki jak należy. Trzeba to tak zrobić, bo Maciek Puczkowski będzie miał niedługo ten sam problem jak będzie implementował modyfikator, który odpycha wrogów.

Co do klepania, to ja bym się mimo wszystko wstrzymał do poprawek Stefana. Wtedy wszystko będzie banalne. Ale jak bardzo Ci zależy, to możemy uznać, że to co teraz napisałeś zamyka taska.

[mzglicz]

Zamknij mi tego taska. Najwyżej coś się otworzy jak będzie problem ze scalanie branchów

[mm4tt]

Zmergowałem Twój kod do i003, ale moim zdaniem są dwie rzeczy do poprawki:

• Ackelerometr powinien powodować większe przemieszczenie niż ruch przeciwników, tak żeby faktycznie się zsuwały, teraz mogą stać w miejscu
• Jak ktoś zrobi hold, to włączasz akcelerometr, wyłączasz go dopiero kiedy ktoś zrobi inny gest, co jest trochę dziwne, bo można już nie trzymać palca na ekranie, a dalej potworki się będą zsuwać

[mzglicz]

Pierwsze : zastanowie się nad tym. Drugie: to dziwne tzn, robie coś takiego: if (gesture.GestureType != GestureType.Hold) { StopAccelerometer(); } Więc akclelometer powinien się wylaczyc, jesli tak sie nie dzieje to nie wiem jak wyczaic, że przestał trzymać

W dniu 12 maja 2013 22:43 użytkownik IIUJ-MateuszMatejczyk < notifications@github.com> napisał:

Zmergowałem Twój kod do i003, ale moim zdaniem są dwie rzeczy do poprawki:

• Ackelerometr powinien powodować większe przemieszczenie niż ruch przeciwników, tak żeby faktycznie się zsuwały, teraz mogą stać w miejscu
• Jak ktoś zrobi hold, to włączasz akcelerometr, wyłączasz go dopiero kiedy ktoś zrobi inny gest, co jest trochę dziwne, bo można już nie trzymać palca na ekranie, a dalej potworki się będą zsuwać

Reply to this email directly or view it on GitHubhttps://github.com/bbsszz/yapg/issues/14#issuecomment-17784966 .

Pozdrawiam, Maciej Zgliczyński

[mm4tt]

Jeżeli nie trzyma, to nie ma żadnego gestu w tablicy gestów(prawdopodbnie, nie sprawdzałem). Twój kod wyłaczy dopiero kiedy ktoś zrobi inny gest niż hold, co nie jest to zgodne ze specyfikacją

[mzglicz]

w branchu i003_z006fix1 (odbijającego od i003) zminiełem sposób uruchomiania acclemotru. Nie mam teraz telefonu. Nie widzę jak przetestować równoczesny hold i accelometer oba wymagają myszki. Zmieniłem sposób włączania i wyłączania accelometru, tak, że brak GesturType.Hold sprawi, że wyłączy się Accelometer. Btw to po co jest enum GestureType.None , skoro tablica może być pusta ?

[mm4tt]

Zaraz będę w domu to na to zerknę i zamknę co trzeba. Ackelerometr możesz ustawić w jakimś położeniu a później nacisnąć na ekran, co da holda. Możesz też odegrać na akceleometrze ruchy. Wydaje mi się, że GestureType.None służy do wyłączenie obsługi gestów, jak podaje się jakie gesty obsługiwać (Pewnie ma wartość zero, to jest maska bitowa)

[mm4tt]

Akceptuję, ale mam 2 uwagi:

1. Nie wiem jak to testowałeś, ale kierunki akcelerometru były odwrócone. Może inaczej trzymasz telefon, tak czy owak poprawiłem :)
2. Trzeba wyregulować jak bardzo akcelerometr wpływa na przeciwników, moim zdaniem teraz jest za bardzo. Ale to zrobimy w następnej iteracji, w większym tasku dotyczącym grywalności