Wielka prośba do tych, którzy grali w Eist'a (artykuł i atr do pobrania tutaj: ->link<- ): Pracuję nad wersją dla systemu Android. Do końca jeszcze daleka droga, ale jeden przykładowy poziom, narysowany na bazie trzeciego levelu z oryginału, już działa. Przełożenie kafelkowej logiki na interfejs dotykowy było dość kłopotliwe. Chciałbym się dowiedzieć czy UI w tej postaci jest akceptowalny dla gracza.
Konieczny tablet lub telefon z Androidem minimum 4.3 i włączonym instalowaniem aplikacji spoza sklepu.
Będę bardzo wdzięczny za pomoc.
Edit: aktualna wersja dostępna na kanale Beta Google Play: ->link<-
miałem 3 minuty na testy, akurat czekałem na spotkanie
- odpala i chodzi >60 fps na słabym urządzeniu Manta MSP4004 - duży plus :) - miałem duży kłopot, żeby postawić strzałkę w wybranym miejscu - palec zasłania miejsce. może na tablecie to nie problem, ale na małym tel spory. pomysł - podczas ustawiania wokół strzałki wyświetla się okrąg czy inny znacznik, dopóki nie puści się palca strzałka nie jest jeszcze postawiona.
Hmmm, 480 x 800 i 4 cale? Ciężka sprawa, trzeba mieć drobne paluszki. Nie testowałem na ekranie poniżej 5", ale wyobrażam sobie. Z tym, że tego chyba nie przeskoczę, bo specyfika gry jest, jaka jest i za mały ekran zawsze będzie za mały. I tak poszerzyłem ścieżki względem oryginału. Gra będzie darmowa (chociaż pewnie z zakupami jakichś extrasów w aplikacji), więc każdy będzie mógł za free zobaczyć czy da się używać na jego urządzeniu.
Co do podświetlenia w miejscu dotknięcia: Używałem go do celów testowych. Można oczywiście wyłączyć, jeśli przeszkadza. Dzięki za podpowiedź.
Note 3, Android 5, działa ok, FPSy wariują, ale cały czas ponad 60 jest.
Da się grać, ale nawet na sporym ekranie jest problem z precyzyjnym umieszczeniem strzałek. Nie wiem czy Cię silnik gry puści, ale IMHO strzałki powinny być obiektami podlegającymi przesuwaniu po umieszczeniu na planszy, tak aby można było skorygować ich pozycję.
Jasne, że się da, nawet rozważałem taką opcję. Boję się tylko, czy nie uproszczę gry za bardzo. Oryginał opóźniał rozgrywkę przez powolne przemieszczanie kursora, a tu można wszystko zrobić błyskawicznie, więc konieczność usuwania źle postawionych strzałek jest poniekąd pożądanym opóźnieniem. TBH - przy odrobinie wprawy i aktualnej prędkości sprite'a, mam DUŻO za dużo czasu na roztrzaskanie tego przykładowego poziomu. Ale postawiłeś dobre pytanie, tylko chciałby poznać jeszcze choć jedna opinię na ten sam temat. Inna (ważna) sprawa, że wykrywanie if (arrowTouched) {} w pętli dla wszystkich możliwych strzałek na ekranie zeżre mnóstwo zasobów. Jeśli user postawi 40 strzałek (wolno mu), to raczej wywali apkę. No i na swoim starym tablecie będę miał fps w porywach do 10. :) Trzeba to przemyśleć.
EDIT: A najlepiej - zakodować i przetestować, co zaraz uczynię. :)
Nigdy się nie dorobiłem Notki, ale na LG G4 daję radę, nawet jakby lepiej niż na 10-calowym tablecie. Jeszcze dojdzie mysz jako drugi kontroler. Post Pirx'a uświadomił mi, że powinienem przed wczytaniem skalować bitmapy w dół dla mniejszych wyświetlaczy. Jakoś zapomniałem o telefonach z rozdzielczością mniejszą od full HD.
Z ostatniej chwili: na tablecie podczas przeciągania fps spada o połowę. Eksperymentuję dalej.
Cóż, sprzętowego nie, ale programowo mogę zrobić, co sobie zechcę. Niestety podczas testowania pojawia się problem: jeśli nie trafię dokładnie w strzałkę, dodaję obok niej nowe, takie, jakie aktualnie wybrałem. Musiałbym po dodaniu każdej strzałki kasować wybór w menu. Czyli żeby dodać np. dwie strzałki w dół po kolei, byłoby trzeba DWA RAZY wybrać strzałkę w dół z menu. Nie wiem czy to ma sens, ma?
Hehehe... Żeby wykrywać przeciąganie, musiałem napisać nową klasę, bo bazowa miała tylko ACTION_DOWN i ACTION_UP. Trochę mi szkoda wyrzucić taki ładny kawałek kodu. Spróbuję jeszcze zoptymalizować, ale pewnie w końcu i tak dam spokój, bo moja córka (Naczelny Tester) mówi, że będzie za łatwo. :)
No nie, jednak nie. Spróbowałem na telefonie i porażka: przeciągając strzałkę, kompletnie zasłaniam ją paluchem. Dużo wygodniej (i w sumie szybciej) jest po prostu usunąć i dodać od nowa. Nic to. Zostawię sobie ten kod na przyszłość w jakimś backupie, bo sporo się nad nim nawymóżdżałem. W pisaniu gier na Andka jestem absolutnym debiutantem. :)
EDIT: zamiast poprawiać UI, zrobiłem sobie kod do czytania leveli z plików. Nie będzie ładowania niepotrzebnej w danym momencie grafiki do zasobów i już widzę, że FPS na tablecie wygląda lepiej.
Wczytywanie następnego poziomu działa, tudzież dodałem kod do obsługi podstawowych dźwięków. Te ostatnie są w tej chwili mocno przykładowe i na 99% zostaną podmienione na coś lepszego, o ile dam radę to spłodzić.
Tak tytułem podsumowania, trochę się pochwalę. ;) Wersja na Andka od paru dni jest w sklepie Play. Na tę chwilę 40 poziomów, czyli tyle, ile w oryginale na Atari. Pozwoliłem sobie wspomnieć o atarionline.pl w opisie gry, w akapicie "Historia". Jest dostępny tutaj: ->link<-
@mav - już trzymam kciuki. Jeśli w Android Studio, to zawsze chętnie pomogę, na miarę swoich możliwości. W żadne inne Unity itp. się dotąd nie bawiłem, choć na przyszłość nie wykluczam.
Skoro o unity mowa, to możesz zerknąć: ->link<- Ale generalnie chodziłoby mi o integrację z płatnościami. Czy wstawiałeś też inne usługi, jak osiągnięcia, statystyki? Ja trochę jeszcze tego panelu developera nie ogarniam należycie. Do Unity są gotowe paczki integrujące z android sdk, więc może nie będzie to takie "trudne". Po świętach na pewno do tego zajrzę, ale w razie czego popytam, może gdzieś przez priva, żeby nie śmiecić w temacie. Aczkolwiek nie wiem, czy to moje tylko wrażenie, czy jednak informacji tego typu (po polsku zwłaszcza) jak na lekarstwo? Jak jakaś wiedza tajemna..
No tak. W przypadku Eista korzystanie z Unity byłoby chyba (?) mało celowe, bo z założenia cała plansza musi być widoczna na raz. Inaczej z gry logicznej zrobiłaby się przygodówka. :) No i Android Studio używam od dość dawna, więc przywykłem. Nie integrowałem na razie żadnego wspólnego scoreboard'u, ani też zapisu stanu do chmury. Dużo roboty plus uzależnienie się od usług Play, a nie wiem jeszcze czy pomysł w ogóle chwyci. Zostawiam to na ewentualną przyszłość. Co do in-app purchases: w zasadzie wystarczy wstawić kod z googlowego sampla, zmienić to, co opisane w komentarzach - i działa. Tylko przy subskrypcjach zalecają dodatkowo użycie własnego serwera. Z opisami po polsku jest źle. Tzn. w zasadzie nic naprawdę potrzebnego nie znajdziesz. Zresztą nawet panel developera w naszym języku ma dramatyczne błędy. Pół dnia się zastanawiałem co może znaczyć "Twój plik APK powinien uwzględniać niestandardowe elementy, które można przeciągać na tabletach wyposażonych w wyświetlacze o typowej rozdzielczości". Po przełączeniu języka na angielski okazało się, że chodzi o "drawables", nie żadne przeciągalne elementy. Najlepiej w ogóle nie używać polskiej wersji.
