Skocz do zawartości

gnysek

Administratorzy
  • Postów

    9 806
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    139

Odpowiedzi opublikowane przez gnysek

  1. 5 minut temu, Kewin napisał:

    Jestem pewien sukcesu, gra nie będzie się źle sprzedawać bo będzie darmowa, będę zarabiać na reklamach i mikropłatnościach. Kto nie zainstaluje rozbudowanej gry z realistyczną grafiką zajmującą mało miejsca. Myślę że milion pobrań na luzie będzie ;) ale tak już pisałem jest ryzyko porażki ale jestem dobrej myśli i robię wszystko według planu.

    Masz, firma która na giełdzie dostała chyba ponad 2 miliony złotych, robiła wielkie MMO Edengrad, mozesz poczytać różne rzeczy o nich na wp, money, bankierze i ogólnie niby profeska.

    https://play.google.com/store/apps/details?id=com.HuckleberryGames.Minglers
     

    100+ pobrań gry :D Toż to jest żal. I na pewno wpakowali w promocję trochę grosza, a tu nic.

     

    Także ja bym na za wiele nie liczył.

     

    Jak powiedział kiedyś TeeGee - dobrze, jak pierwsza gra sprzed się w 1000 kopii :D Jak będzie dobra, druga sprzeda się lepiej :)

  2. Z mojej perspektywy robisz tak:

     

    - szerokość view albo ustalasz na sztywno wszędzie, albo do szerokości telefonu (ale to wymaga przygotowania wszystkich etapów o szerokości co najmniej zgodnej z najszerszym ekranem, żeby nie było pasków, a wysokosci zgodnej z największym ratio). Oczywiście view może być 1:1, ale może też być mniejszy większy niż telefon, generalnie nie ma to znaczenia, byle zrobić to tak, że zawsze gracz widzi jakieś tam założone minimum na lewo i prawo od gracza.

    - wysokość view ustalasz z proporcji ekranu. Robiąc grę musisz pamiętać, że o ile w szerokość już ustaliłeś ile się miesci, tak w wysokość na jakimś dziwnym ekranie czasem coś może zniknąć, więc trzeba projektować levele i podążanie kamery tak, żeby ważny element (np. przycisk za dwiema ścianami który masz zobaczyć) się jednak nie schował. Trzeba też czasem postawić elementy otoczenia w miejscu gdzie ekran mógłby być za wysoki, żeby nie było pusto.

     

    I teraz wyjdą dwa warianty - albo z lewej i prawej widzisz zawsze to samo, a góra dół się lekko zmieniają, albo obcinasz/dodajesz zawsze parę pikseli na view, żeby było ładne ratio pikseli, podzielne przez 2, wiec bez rozmazywania :)

    Z GUI natomiast robi się ciut inaczej:

     

    - zakładasz sobie, gdzie będą elementy - np. cztery rogi ekranu, srodek ekranu, czy dolna część (na wyświetlanie dialogów)

    - zakładasz, ze te elementy nigdy nie zajmują 1/4 ekranu, tylko mniej

    - elementy w każdym rogu rysujesz nie względem 0,0, a względem tego rogu. Czyli w dolnym prawym rogu, piszesz draw_text(<gui_width> - 100,<gui_height>-20, "...."); Dzięki temu, jaki telefon nie będzie i zmienisz rozmiar GUI, to wszystko się automatycznie zbliży/oddali od siebie, ale będzie dokładnie tak daleko od rogu jak chcesz.

     

     

    Jest z tym nieco zabawy, ale jak się dobrze zaplanuje to się okaże, że mógłbyś dowolną rozdziałkę zmyślić, a i tak gra będzie działać. I nawet nie trzeba jej będzie na tych innych rozdziałkach długo testować - praktycznie tylko jak już będzie gotowa, ostatniego dnia, sprawdzić, czy na pewno coś w GUI się nie nakłada.

  3. image.png

    Wczesne testy stylu i paru rzeczy z których można skorzystać w GMS2 i zrobić fajny efekt - ot, tutaj generowanie cieni na surface na podstawie spritów (zamiast obiektów) ustawionych na różnych layerach. Generalnie tak myślę nad jakaś kreskówkowo-rysunkową grą obecnie. Kto jest na GMCLANie od dawna to pewnie nawet wie nad jaką :P

  4. Hm, generalnie zrobiłbym to poza eventem, ale niech zostanie. Daj w create:

     

    pressing = -1;


    w step
     

    if pressing > -1 then pressing--;
    
    if pressing == -1 {
        <nazwa_zmiennej_od_predkosci> -= 1;
    }

     

    a w tym getsture tap:

     

    pressing = 1;

     

    Powinno nienajgorzej zadziałać (zacznie zwalniać po 1 klatce obrazu).

  5. Tzn. liczysz, że jak użyjesz szyfrowania (nie hashowania), to dane w MySql będą bezpieczne? Jak ktoś pozna klucz (a będziesz go miał w aplikacji C# zapewne) to dupa zbita. Co do tego, że dane po https są przesyłane jawnie - cóż, przed wysłaniem (w przeglądarce) i po odebraniu (w PHP) owszem są jawne, ale przeglądarka pokazuje dane przed wysłaniem pakietów, a PHP po przetworzeniu przez Apache/Nginx.

     

    Co do włamów do bazy MySql - nie udostępniaj bazy z zewnątrz, to ryzyko włamania spadnie niemal do zera. A jak się ktoś włamie na serwer, to wierz mi, że nie trzeba nawet wejść do mysql, można po prostu zrobić loggera przychodzących danych w odpowiednim miejscu i je nawet na mejla wysyłać.

     

    Co do danych kart kredytowych - po co je chcesz zapisywać? Nawet jak robisz płatności-subskrypcje, to wystarczy autoryzowanie z bramki płatności i otrzymanie z niej kodu płatności i potem powoływanie się na niego, żeby ściągać kasę (capture). Sam numer karty też najlepiej, gdyby klienci podwali w bramce (payu/dotpay itp) - to jest miliard razy bezpieczniejsze. Zrobiłem w życiu ponad 50 sklepów internetowych i zawsze zalecamy klientom, aby nie wpisywać i nie przechowywać ŻADNYCH danych kart kredytowych na ich stronie i zostawić to bramkom płatności.

  6. To, czy duże i małe znaki są odróżniane czy nie nie zależy od ustawień PDO, a od ustawienia kodowania danego pola w tabeli mysql. Spróbuj zmienić np. na utf8_bin .

     

    A co do haseł jw. mamy co najmniej kilka ustaw które zabraniają trzymania ich w plaintekście. Nawet bez wycieku danych trzymanie czyjegoś hasła jawnie w swojej bazie jest równe ze zhackowaniem tej osoby - bo tak naprawdę masz loggera haseł wtedy.

×
×
  • Dodaj nową pozycję...