Konrad-GM

Może jakiś Jekyll, stronka bez cms, php, mysql, tylko plain html, css i js z możliwością dodawania newsów w markdownie. Prywatne repo na GitLabie + Pipeline CI i nie będzie trzeba martwić się deployem.

Jakoś nie mogę się przyzwyczaić do wyskakującej ikonki podczas walki, wtedy z paska szybkiego dostępu próbuję potów używać przy jednocześnie wciśniętym atakowaniu, może źle w to gram Zszedłem ze ścieżki i nawet znalazłem jakiś domek w lesie, grób, skrzynię, przez to często schodzę ze ścieżek eksplorować Widziałem, że planujesz wydać też wersję PC po iOS. Powodzenia! Edit: Brata też namówiłem do ogrania Darkosena, kiedyś graliśmy w Almorę Online i mu się mega podoba też ta odsłona Edit2: BTW. Jak wejdzie się na stronę AD przez google to wyskakują jakieś dziwne scam reklamy.

Pograłem jakiś czas, zdobyłem kilka lvli, pozwiedzałem kilka lokacji i... gra się mega przyjemnie, chociaż czasami sterowanie jest sztywne, nie zawsze działa używanie potów, podnoszenie rzeczy i trzeba mashować przycisk bo jakaś animacja się jeszcze nie skończyła. Jest też kilka problemów, może bardziej designerskich niż technicznych, np. główna linia fabularna na razie jest dość... cienka, znalazłem list, teraz mam znaleźć jakiegoś gościa i nie wkręciłem się w nią w ogóle, robiłem kolejne poboczne questy byle by pozbierać poziomy na dalsze wypady, a questy są typowe dla tego gatunku - idź zabij X robali/much/krabonszczów/bandytów, albo znajdź rodowy miecz/zbroję czy inne badziewie itd. To co prawda początek gry zapewne, więc głównej fabuły jeszcze nie ocenię. Z takich poważniejszych problemów jakie szczególnie mi przeszkadzały - to otoczenie które jest mało czytelne, nie widać co jest górką, a po czym można chodzić. Nieraz złapałem się na tym, że przelazłem jakąś drogę i utykałem na pozornych przejściach, albo zastanawiałem się czy to nie jest górka zanim tam pójdę, bo utknąłem w buszu i nie mogłem znaleźć wyjścia No i jeszcze takie czepialstwo z mojej strony - mam ekran w telefonie 19.5 / 9 przez co widzę paski na bokach, co prawda jest przycisk "wymuś pełny ekran", ale wszystko jest wtedy rozciągnięte. Gratuluję ukończenia pierwszego dużego projektu! i to w pojedynkę. Na pewno wrócę do grania a co by pozwiedzać inne lokacje Almory i ciskać firebollami w monstra. Powodzenia w kolejnych produkcjach! Na pewno będę śledził Gear Studio

Na pewno poprawnie połączyłeś się z telefonem przy `adb connect`? Może firewall jakiś blokuje ADB

Nie testowałem tego na GMSie, ale możesz spróbować włączyć debuggowanie po wifi na androidzie ręcznie. 1. Podłącz telefon po USB i sprawdź w ADB wszystkie widoczne urządzenia: 2. Jak będziesz miał swoje urządzenie widoczne, przełącz ADB do trybu debugowania po sieci `tcpip`, wpisz coś takiego: Ale poza jedną rzeczą, w miejsce portu 5555 wpisz port jaki masz skonfigurowany w GMSie. Możliwe też, że zadziała jak podasz taki sam port jak tutaj. 3. Teraz możesz spróbować połączyć się z urządzeniem, ale najpierw znajdź IP telefonu w lokalnej sieci. Możesz odłączyć telefon od kabla USB i spróbować zrobić deploy. Tutaj masz bardziej szczegółowy opis jak co działa: https://developer.android.com/studio/command-line/adb#wireless

Nie korzystam z GMa już od dłuższego czasu tak naprawdę, ale może spróbuj pobawić się substytutem jak GMowy path, znalazłem nawet jakieś tutoriale. Bazując na nich chyba załapiesz jak można to też rozwiązać, co prawda dalej będziesz musiał policzyć odległość od tych segmentów żeby postać mogła "złapać" linę (chyba, że GM potrafi znaleźć najbliższy punkt funkcjami path ) https://youtu.be/OkUMpnvxS1s https://youtu.be/fOL_VYzwDcE

Ja bym to zrobił podobnie jak to @gnysek zaproponował, ale zamiast procentowego wskaźnika, to trzymał długości segmentów, oraz nie usuwał obiektu gracza, a w nim sterował poruszanie się po linie. np. przypuśćmy, że mamy taką linę: Można podzielić ją na segmenty, np. ręcznie powstawiaj punkty, np. w kodzie i wtedy będziesz miał listę punktów z której możesz policzyć długość każdego segmentu. Teraz najciekawsza rzecz - żeby pozwolić graczowi "złapać" linę, musisz policzyć jak daleko od najbliższego segmentu jest gracz. W pętli for dla każdego segmentu sprawdzaj, jak daleko gracz jest od liny. Jeżeli będzie odpowiednio blisko, to przypisz graczowi poprzez zmienną, do której liny należy, oraz na którym segmencie "zaczął się wspinać". Możesz przerobić ten skrypt https://www.gmlscripts.com/script/point_line_distance tylko wyciągnij z niego dwie wartości jak odległość i zmienną t, bo przyda Ci się do obliczenia jak daleko na tym segmencie jest gracz. A sama wspinaczka to co Step Event musisz ustawić gracza na odpowiedni segment linii. Np. jeżeli masz w graczu zapisaną wartość 120, to znajdujesz na którym segmencie jest gracz np. w pętli for i następnie liczysz wektor normalny z dwóch punktów tego segmentu i mnożysz przez różnicę (120 - [długość całkowita do punktu startowego segmentu na którym jest gracz]) a na koniec dodajesz wartości współrzędnych punktu startowego tego segmentu. Samo sterowanie poruszania się po linie to modyfikacja zapisanej zmiennej, możesz też tę wartość clamp-ować, żeby nie wylazł Ci poza linę. PS. pamiętaj, że złożoność tego rozwiązania to O(n), im mniej segmentów, tym lepiej

A dlaczego nie wrócić do tego pomysłu?

Możliwe, że ma to związek z aktualizacją GMS 2.2, mnożenie łańcucha znaków przez liczbę nie działa. Jak zrobisz rzutowanie funkcją real(str) powinno zadziałać, albo odwróć kolejność mnożenia: surface_resize( application_surface, window_scale*view_width, window_scale*view_height );

Wysyłasz zapytanie do google po nieszyfrowanym protokole `http://` z poziomu strony która jest szyfrowana. To nie problem z certyfikatem, a mieszaniem protokołów - jak odwiedzasz stronę po HTTPS, to przeglądarki odrzucają *każde* zapytanie które zrobisz po HTTP. https://developers.google.com/web/fundamentals/security/prevent-mixed-content/what-is-mixed-content

ImageMagick ma jeszcze komendę mogrify dla wielu plików, ale jeżeli nie zadziała zawsze możesz skrypt napisać, np. pod windowsa w konsoli wpisz: for %f in (*.png) do convert %f ( +clone -alpha extract -draw "fill black polygon 0,0 0,15 15,0 fill white circle 15,15 15,0" ( +clone -flip ) -compose Multiply -composite ( +clone -flop ) -compose Multiply -composite ) -alpha off -compose CopyOpacity -composite %~nf_rounded_corners.png Pod Linuxa działa to trochę inaczej np dla windowsa usunąłem znaki \ przy nawiasach i zamieniłem pojedyncze ' na "

@nowy_user osobiście korzystam z ImageMagick, a jak zaokrąglić rogi jest nawet opisane w dokumentacji IM - http://www.imagemagick.org/Usage/thumbnails/#rounded

Zwykły Chrome, a DevTools można znaleźć pod F12 lub Ctrl+Shift+I albo z menu > Więcej narzędzi > Narzędzia developera. Do pracy głównie używam Chrome dlatego na nim ogarniam toolsy (dla remote debug), a firefox z tego co wiem też ma podobne DevToolsy.

Teraz działa u mnie ok, zrobiłem test na mobile (devicePixelRatio = 3) jak i desktopie ale w trybie mobile (devicePixelRatio = 2) Desktop w trybie mobile (720px i devicePixelRatio = 2) Mobile (1080px i devicePixelRatio = 3)

Napisałem mega prosty skrypt, spróbuj dodać go do shella index.html przed zamknięciem taga </body>: <script> (function (window, DOM) { 'use strict' var vp = getMetaViewport() window.addEventListener('resize', updateMetaViewport) updateMetaViewport() function getMetaViewport() { var meta = DOM.querySelector('meta[name="viewport"]') if (!meta) { meta = DOM.createElement('meta') meta.name = 'viewport' DOM.head.appendChild(meta) } return meta } function updateMetaViewport() { var width = window.innerWidth * window.devicePixelRatio vp.content = 'width=' + width + ', initial-scale=1, maximum-scale=1, minimum-scale=1, user-scalable=no' } })(window, document); </script>

Pograłem chwilę, ale odrzuca mnie brak płynności i przez to brak responsywności w sterowaniu. Dałoby radę zwiększyć FPSy minimum do 60?

Tak jak zasugerował to już @gnysek, jest to poprawne zachowanie przeglądarki na mobilkach. Używasz <meta> viewport które jest tutaj "problemem" tak jak sam zauważyłeś. Zaproponowane przez Ciebie na sztywno wstawienie skalowania działa u mnie (prawie) ok, ale ostatecznie nie działa to idealnie. Jakbyś miał czas i chęci to usprawnić, to myślę, że użycie window.devicePixelRatio byłoby lepszym rozwiązaniem - w ten sposób obsłużysz każdy ekran tak naprawdę. Podgląd w devtoolsach, na mobile mam devicePixelRatio = 3, a na desktopie mam 1. Szerokość ekranu mobile u mnie to 1080px a ww. canvas to 360px. Jakby pomnożyć szerokość 360px * devicePixelRatio (czyli 3) to na mobile zwróci poprawny rozmiar 1080px. Na Twoim drugim poprawionym przykładzie liczy mi 720px więc to jest *prawie* ok, idealnie u mnie działałoby to przy scale = 0.3333 (1.0 / devicePixelRatio).

A jakiś link do tego projektu znajdę?

Zapowiada się super, trzymam kciuki i powodzenia Edit: Chociaż trochę się obawiam elementów MMO w grze single player.

Podejrzewam, że Ty nie jesteś programistą, a marketingowcem, z którymi @gnysek ma pewnie masę doświadczenia w pracy ;P Ale nie jesteś programistą, żeby zrozumieć na czym to polega, dlatego ciężko będzie przekazać Ci konkretną wiedzę techniczną (nie da się jej przekazać w jednym zdaniu, żeby napisać stronę ecommerce), skoro nie wiesz jakie to jest skomplikowane - chociażby taka obsługa bramek płatności, jeszcze gorzej, jak będzie trzeba obsłużyć ich kilka, kolejne abstrakcje, kolejne interfejsy które trzeba, niestety, zaprogramować. BTW. To jest prosta i konkretna odpowiedź z doświadczenia a nie z wywyższania się. Albo napisz swoją wtyczkę, w takim np. Presta masz masę gotowych interfejsów w systemie i możesz je obsługiwać jak CI się tylko podoba bez myślenia, jak zaimplementować kolejkowanie zamówień czy obsługę bramek płatności, w tym skonfigurować serwer SMTP i wygenerować oraz wysyłać maile (np. z fakturami) do klientów - a to chyba jest ważne w marketingu? Bo przeważnie nie jest to tak dobry pomysł jakby się wydawało, zwłaszcza, jak nie ma się doświadczenia z programowaniem. Starsi koledzy też pewnie tak myśleli, ja np. napisałem własny sklep dla własnych potrzeb (i kilka innych stron), masa zabawy z tym była... generalnie polecam napisać swój sklep, sporo się nauczysz i zrazisz do takich przekonań Ale tu jest już jakaś funkcja, przez którą będziesz umieszczał dane, dodajmy do tego formularz zgłoszeniowy, że ktoś chce kupić jakiś przedmiot, może nawet bramkę płatności XSS podałem dla przykładu, pierwsza strona Google pod hasłem "common ecommerce website vulnerabilities" - https://lirax.org/6-common-security-vulnerabilities-in-e-commerce-systems/ Jak dla mnie fajny CMS, kilka stron na nim postawiłem i działa naprawdę nieźle - w tym w łatwy sposób można dodawać podstrony bezpośrednio w HTMLu (z wbudowanym silnikiem template'ów). Generowałem w nim PDFy, wysyłałem customizowane maile, zarządzałem użytkownikami (poza adminami/redaktorami ofc.)... Ale nie stawiałem na nim sklepów, tutaj własną wtyczkę musiałbyś dopisać (co jest banalne w October CMS), albo skorzystać z wtyczek z marketu

Nie jestem jasnowidzem i nie mogę powiedzieć co jest niezabezpieczone, sporo zależy jak napiszesz taki sklep. Możesz poczytać sobie o łatkach zabezpieczeń innych kombajnów jak np. Wordpressa żeby mieć ogólny zarys czym jest chociażby taki XSS i np. w jakich niespodziewanych miejscach można umieścić kod https://wordpress.org/news/category/security/ Może też dlatego @gnysek poleca użyć gotowca jak Presta, bo podejrzewam, że działa marketingowo a nie próbuje podbić rynek swoim autorskim super frejmworkiem Jak dla mnie pisz własny sklep, jeżeli to nie jest pisane dla klienta a tylko do celów własnych, to sporo się nauczysz i nabierzesz doświadczenia jak to działa od kuchni. PS. Presta też jest mocno podatna na zmiany i czcionki spokojnie mógłbyś zmienić Edit: Może rzuć okiem na OctoberCMS, dość ciekawe rozwiązanie, można w dość łatwy sposób pisać szablony bezpośrednio w HTMLu i doklejać kod PHP, mega prosty CMS i w dodatku podstawowa instalacja ma minimalnie wymagane pluginy.

xD xDD Akurat większość problemów dot. zabezpieczenia to wbrew pozorom wcale nie SQL injection. Community i battle-testy. Czyli nie wiesz, co jest wymagane, stawiam na żadne bądź b. małe doświadczenie w programowaniu takich rozwiązań Nie twierdzę, że pisanie własnego sklepu to zło, sporo się można nauczyć, ale po tym co napisałeś stwierdzam, że nie masz doświadczenia z tematem (i dlaczego z góry zakładasz, że Twoje rozwiązanie będzie "lepsze"... jak nie będzie ).

O, a tego nie wiedziałem, czyli najlepiej jakby wspierać oba ratio 16:9 oraz 19,5:9

Często grafik z doświadczeniem myśli zupełnie inaczej ;P Ale dlaczego miałby to robić? Że za darmo? Albo za "procent"? Sorry ale jeżeli już ktoś się zgodził na procent, to teraz staje się tym "doświadczonym" grafikiem co już więcej na procent niczego Ci nie zrobi Żeby zarobić te miliony to IMO trzeba mieć dużo szczęścia. Nawet gry AAA z dużym budżetem na reklamę mogą słabo się sprzedawać, faktor tym większy, im bardziej gra jest "indie" Popytaj się innych grafików w branży o wycenę, bo na cenę może wpływać sporo czynników i zapewne każdy wyceni Ci je inaczej. Może nawet uda Ci się podłapać studenta co dopiero zaczyna w branży, będzie taniej, ale większe ryzyko, że będą to mocne średniaki, chyba, że gość utalentowany ale nie zna cen rynkowych

Jeżeli będziesz trzymał się proporcji 16:9 to większość ekranów jest ok, czarne paski pojawiają się tylko na jakichś abominacjach Obsłużenie wszystkich możliwych rozdzielczości jest IMO bardzo trudne, osobiście też próbowałem rozwiązywać ten problem w swoich aplikacjach (nie tylko grach). dlatego nie widzę niczego złego w trzymaniu się ustalonych proporcji, to sporo ułatwia pracę (polecam 16:9, najbardziej popularne). Jeżeli z jakiejś przyczyny takie rozwiązanie Ci nie odpowiada, możesz zawsze rysować UI po współrzędnych ekranowych, np. od prawego dolnego rogu (jeżeli np. pasek życia masz na dole po prawej stronie) a nie standardowo od lewego górnego, pamiętaj też, że na mniejszych ekranach elementy mogą na siebie nachodzić. PS. W Godot jest nawet opcja rozciągania ekranu tak (tryb "2d"), żeby skalowało sprite'y do ustalonych proporcji np. 1280x720 (16:9), tzn. jeżeli miałbym ekran np. retina 3840×2160 to rozciągnie obrazki ale surface (render target) na którym będą rysowane ma oryginalny rozmiar 3840×2160 (chyba, że jest poza proporcją 16:9, to wtedy pojawiają się czarne paski), więc antyaliasing linii, i innych kształtów rysowanych dynamicznie działa poprawnie. A nawet jak sprite będą zeskalowane w dół, to po ich rozciągnięciu na większym ekranie nie będzie tragedii.