DangBean

Nie znam się na sprzedaży gier, jestem amatorem, ale czy to nie powinno być tak samo jak przy sprzedaży książek, muzyki, filmów... Jest twórca (przez wielkie tfu) który umie tworzyć, ale nie umie sprzedawać i wciskać ludziom kit. Tworzy. Chodzi po wydawcach, aż któregoś zainteresuje. Ten mu daje reda, który mu pomaga cośtam poprawić (np. u mnie poprawił błędy ortograficzne), czasami coś zmienić bo się nie sprzeda. Książka się drukuje, czy tam film, muzyka powiela - od tego są specjaliści. Robi się marketing - też specjaliści. Dzieło się sprzedaje - od tego są sprzedawcy. Twórca dostaje tntiemy i się cieszy, bo ma na piwo, a czasem na coś więcej. Wydawca leci na Karaiby i pali drogie cygara. W grach to tak nie działa?

No właśnie nie. Jak masz firmę to podstawa podatku będzie mniejsza o różnice kursowe i opłaty bankowe i na koniec roku będziesz mógł sobie odliczyć od podatku to 10% zapłacone w USA. A opłaty i przewalutowania bankowe (jeśli kontrahent nie chce PayPal) to może byc nawet 15% (tyle ze mnie raz zdarli jak miałem mały przelew z Kanady). A jak nie masz firmy i sprzedałeś za 1000USD, kontrahent przeleje ci 900USD (prawidłowo wypełniłeś W8BEN i pobrał 10% podatku), bank zabrał 25USD opłaty, ten drugi przeliczył ci po bandyckim kursie 3.50 - dostałeś 3062PLN, a podatek musisz zapłacić od 1000UDS*3.73 (kurs sredni NBP) = 3730PLN. Gdy masz firmę, wszystko to co ucieka po drodze - nie wchodzi do podatku. Wiec firma jest korzystniejsza gdyby nie jedno malutkie ale. To "malutkie ale" nazywa sie ZUS :twisted: . Na pocieszenie mogę powiedzieć, że zapomniałem napisać, iż sprzedaż softu i reklamy itp do USA nie podlega VAT.

Elegancko byłoby: global.zaznaczony = noone; ;)

Z umowy o unikaniu podwójnego opodatkwania PL-USA wynika, że jak masz EIN lub ITIN to powinni pobierać 10% podatku u źródła (w USA). 30% to podatek dla krajów które nie mają takiej umowy. W 2011 została podpisana nowa umowa PL-USA, w której jest 5%, ale nie została ratyfikowana przez Kongres. W W8BEN w odpowiednie rubryki wpisujesz to 10%, że umowa z PL i podajesz artykuł umowy dotyczący "Royalties". Oczywiście jak źle wypełnisz W8BEN to pobiorą ci 30%. Ale to wcale nie zwalnia od podatku dochodowego w PL. Żeby wypełnić W8BEN trzeba mieć amerykański EIN lub ITIN, bo jest tam taka rubryka (dla ułatwienia nazywa się TIN :rolleyes: ). Aby dostać EIN lub ITIN trzeba wypełnić formularz SS4 lub W-7 i wysłać go do ichniejszegi urzędu podatkowego. Może to można zrobić w ambasadzie, ale nic o tym nie słyszałem. Ja na odpowiedź na SS4 czekałem 3 miesiące. I jeszcze jedno, jak masz działalność, to na koniec roku można odliczyć to 10% pobrane w USA od podatku dochodowego płaconego w PL, jeśli dostaniesz z Redmont potwierdzenie ile zapłacili podatku i kiedy. Wtedy juz prościuteńko :rolleyes: przeliczasz na PLN według średniego kursu NBP z dnia poprzedzającego należność podatku w USA i odliczasz. Jak nie masz DG to nie wiem czy można. Acha, jak masz DG to różnicę kursową pomiędzy należnością podatkową i tym co faktycznie otrzymałes w PLN po przewalutowaniu przez bank lub PAYPAL możesz walnąć w koszty :rolleyes: . Jak nie masz działalności to przychodem jest cała kwota w USD (razem z 10%) przeliczona wg kursu średniego NBP z dnia poprzedzajacego i nieważne że banki lub PayPal zabrało ci z tego kolejne 12%. No chyba, że zarobiłeś w ciągu roku ze wszystkich źródeł mniej niż 3089PLN, to nic nie płacisz w PL.

Bez WebGL. Sprawdziłem - z WebGL działa. No ale WebGL nie na każdym telefonie jest...

Może kogoś zainteresuje, że w nowej wersji GMS 1.4.1556 poprawili import SWF. Moja paskudna geba ma już dwa oczka i jak sie ją skaluje to bardzo alegancko się powiększa, bez żadnej pixelozy :) . Niestety nie wszystko jest jeszcze super - w HTML5 grafika wektorowa się robi niwidzialna.

sami rzeźbicie? z jakichś darmowych zasobów? płacicie? każdy team ma muzykanta? no chyba nie yuma?

Moim zdaniem najlepiej to pokazuje Opera - zbadaj element na prawym klawiszu myszy. Można obejrzeć i zmieniać kod strony obserwując efekty.

Grafikę robię w dużej części w GM, ale sporo robię w InkScape. Inkscape daje grafikę wektorową, którą można przekonwertować do png w dowolnej skali. Czyli jak się okaże że jednak zrobiłeś za mały lub za duży rysunek i Ci w grze nie pasuje, to wracasz do Inkscape i eksportujesz jeszcze raz w innym rozmiarze. Poza tym można tę grafikę zrobić na kilku warstwach i jak coś spieprzysz, to łatwiej to zmodyfikować. Jedyną wadą jest konieczność eksportowania z Inkscape do GMS. Oczywiście pewnie lepiej robić to samo w Corelu ale Inkscape jest za darmo :rolleyes: . Próbowałem grafikę z Inkskapa importować jako wektorową do GMS za pomocą swfmill (bez konwersji do png), ale niestety fragmenty rysunków mi zżerało i się poddałem. Jak masz kasę to możesz grafikę wektorową robić we Flashu i to się ponoć importuje do GMS bez problemu. Do przetwarzania dźwięków używam Wavosaura (też free). Efekt bajerzasty, ale shadery nie są łatwe do rozgryzienia. Na pewno nie na początek.

Ja bym zrobił tak - niech każdy gracz ma swoją dyspozycję meczową: GML dyspozycja = random_range(umie*0.8, umie*1.2); sumujemy dyspozycje wszystkich graczy i mamy stan drużyny. Na początku gry trzeba pamiętać o randomize();

Z Tortoisa korzystam tylko jak chcę zrobić diff'a z poprzednia wersją. Moim zdaniem fajnie mieć te ikonki w GMS przy obiektach i skryptach, człek wie gdzie ostatnio grzebał. Raz zrobiłem commita w Tortoisie, przy otwartym GMS i GMS mi zgłupiał, kompletnie pogubił ikonki. To było co prawda w 1.3, może teraz byłoby lepiej.

Czy ktoś z Was korzysta z SVN w GMS? Mam taki problem - jeśli dodaję skrypt (lub cokolwiek innego) to GMS nazywa go defaultowo np. script137, zmieniam mu nazwę na moj_skrypt i czasami GMS kiełbasi w svn w ten sposób, że nie można zrobić commit all. Jedyny sposób jaki na to znalazłem to otwarcie cmd i ręczne: svn rm "C:\Users\JA\Documents\GameMaker\Projects\project1.gmx\scripts\script137.gml" Bardzo to upierdliwe. Zwłaszcza jak trzeba to kilka razy zrobić przy jednym commit. Zna ktoś może lepszy sposób?

Tu to się można spierać - są tacy którzy nie korzystali i tacy którzy wprost przeciwnie. Chodziło mi o to, że nie zawsze gra "od razu będzie działać". Moim grom to się nie przytrafiło :( . Nie działają. Zmiana była baaardzo bolesna, ale miała sens, więc nie złorzeczę tylko cieszę się, że GMS jest lepszy i piszę sobie nową gierkę :rolleyes: .

To się nazywa hurraoptymizm :rolleyes: Jeśli w GM8 nie korzystałeś z jednej z ponad setki funkcji, które w GMS zostały wycofane, to gra będzie od razu działać. (pełna lista w dokumentacji http://docs.yoyogames.com/ w sekcji Reference->Obsolete functions) Ale spróbować nie zawadzi :thumbsup: - szybkość "śmigania gry" w GMS i GM8 to niebo i ziemia.

np. Wavosaur jest darmowy i prosty w obsłudze. Nie potrzeba godziny muzyki. Bitrate nie musi być 256k. Nie każdy gracz to audiofil ;)

To raczej żartem było. Lepiej rozważ poradę gnyska.

specjalnego eventu na to nie ma Musisz w obiekcie, który będzie śledził tą zmienną (obiekt śledź ;) ) w create event ustawić sobie lokalną zmienną np prev_a GML prev_a=global.a; a w stepie sprawdzać czy się nie zmieniło: GML if(prev_a!=global.a){ prev_a=global.a; //tutaj to co chcesz robić }

Jeśli ten kod jest wywoływany w step event, albo w alarmie, to za każdym razem, gdy jest wywyływany ustawiasz hp_drzewa na początkowe 5. To nigdy nie da zera. Dlatego nie powinno być var przed hp_drzewa oraz hp_drzewa powinno być ustwiane na początkowe 5 w create event. var oznacza, że zmienna ma zakres tylko w tym skrypcie nie poza nim. Bez var zmienna ma zakres w całej instancji obiektu - we wszystkich eventach. powodzenia :D

instance_destroy() nie ma argumentów :rolleyes: . Działa na self. Ale najprawdopodobniej lepiej użyć tej funkcji, jeśli to ścięte drzewo nie jest już nam dalej potrzebne. Np.: GML var id_drz; id_drz = instance_nearest(x,y,ob_drzewo_lisciaste_1); if(distance_to_object(id_drz)<6) with(id_drz){ instance_destroy(); } albo: GML with(ob_drzewo_lisciaste_1){ if(distance_to_object(other)<6) instance_destroy(); }

Jak odwołujesz sie do ob_drzewo_lisciaste to jest to odwołanie do wszystkich instancji. Albo trzeba znaleźc najbliższe drzewo i zapamietać jego id w zmiennej, miej wiecej tak (nie sprawdziłem): GML var id_drz; id_drz = instance_nearest(x,y,ob_drzewo_lisciaste); if(distance_to_object(id_drz)<6) instance_deactivate_object(id_drz); albo w pętli with zbadać odległość do każdego drzewa (też nie sprawdziłem): GML with(ob_drzewo_lisciaste){ if(distance_to_object(other)<6) instance_deactivate_object(self); } Wewnątrz pętli with self-ami są kolejne instancje ob_drzewo_lisciaste, a other to ten obiekt w którym jest pętla with (nasz bohater?).

Nie wystarczy zainstalować najnowszej wersji SDK. Muszą być jeszcze: Android 2.1 (API 7), Android 2.2 (API 8), Android 3.2 (API 13), Android 4.0.3 (API 15). Poza tym ja miałem jeszcze problemy ze ścieżką. Teraz mam zainstalowane SDK w roocie bez spacji i działa. http://help.yoyogames.com/entries/23363366...dio-for-Android

Trochę mnie zaskoczył Twój post, ale pomysł by krzywe beziera zamieniać na trójkąty nie wydaje się bezsensowny, więc poeksperymentowałem. Gdyby było tak jak piszesz, to przy powiększaniu sprite'a powinna pojawić się struktura złożona z trójkątów, bo przecieź sprite musi być pamiętany jako skończona liczba vertexów. W SWF sprite składa się z takich obiekcików: <DefineShape3 ShapeId="8"> <Bounds MaxX="5132" MaxY="4098" MinX="4982" MinY="3365" /> <FillStyles> <SolidFillStyle Color="9b" /> </FillStyles> <LineStyles> <LineStyle Width="96" Color="ff00009b"> </LineStyle> </LineStyles> <Edges> <StyleChange> <Move DX="5084" DY="3860" /> <SetFill0 Index="1" /> <SetLine Index="1" /> </StyleChange> <Curve CDX="-12" CDY="280" ADX="-25" ADY="-89" /> <Curve CDX="-24" CDY="-143" ADX="8" ADY="-302" /> <Curve CDX="12" CDY="-280" ADX="25" ADY="88" /> <Curve CDX="3" CDY="17" ADX="3" ADY="26" /> <Line DX="-17" DY="276" /> <Line DX="27" DY="127" /> </Edges> </DefineShape3> Rysyję sprite'a zaimportowanego z SWF skalując: GML draw_sprite_ext(sprite0, 0, x, y, skala, skala, 0, c_white, 1); No i przy dużej skali nie pojawiają się trójkąty, tylko pixeloza. Obawiam się, że krzywe beziera są podczas importu zamieniane nie na vertexy, ale na pixle :( . Czyli jak chcemy aby nasz bohater odchodził w siną dal na tle jelonka i zachodzącego słońca, to najlepiej narysować go wektorowo, i wyeksportować z inkskapa kilka png w różnych skalach i gdy bohater odchodzi skalować, a co ileśtam kroków podmieniać sprite'a na mniejszy. A miało być tak pięknie. Jestem dziebko zawiedziony.

Znalazłem coś takiego: http://gmc.yoyogames.com/index.php?showtopic=643832 Gosciu eksportował bezposrednio z flasha i też mu oczko zjadło. Czyli to jednak błąd GMS. (to w ogóle jakiś spisek iluminatich - w obu przypadkach oczko :rolleyes: ). Kolejny ciekawy efekt jaki zauważyłem to zmiana grubosci fragmentów krzywych importowanych z SWF podczas ruchu. Tak jakby te linie migotały. Gdy się ruch spritów ogląda w flashu to tego nie ma. Chyba trzeba jeszcze poczekać aż dopracują grafikę vektorową. Może dodadzą import SVG. Nie trzeba będzie konwertować, a bardzo to upierdliwe.

Dzięki Threef. Poeksperymentowałem. Pusty projekt - room nie miał tła - zwykłe sprites też zostawiają węża. Jak się włączy tło, to wszystko jest ok - wąż znika. Jak się doda tilesy - też jest ok. Fajny efekt powstaje jak tiles jest półprzezroczysty - za obiektem idzie taki półprzezroczysty znikajacy cień na kilkanaście pixlów. Efekt przypominający sposób rysowania ruchu w niektórych komiksach :rolleyes: . Możnaby wykorzystać gdyby nie świadomość, że pewnie YoYo to naprawi.

Z tym brakującym oczkiem to możliwe. Warstwa była jedna, może GMS jakoś inaczej interpretuje kolejność rysowanych krzywych. Ale czemu zostawia węża? Obiekt się przesuwa to i sprite też powinien, bez zostawiania śmieci, niezależnie od głębokości warstw. Próbowałeś używać spritów wektorowych w GMS?