Autor Wątek: W czym się teraz pisze gry?  (Przeczytany 5168 razy)

Offline Rakieta

  • Użytkownik

# Lipiec 05, 2016, 23:59:39
Niestety i potem byle gra mobilna, która wykorzystuje 0,01% możliwości silnika zajmuje 1GB na karcie i zjada 0,5GB ramu. A gry na PC pisane w Unity mają drastyczne spadki wydajności, długie czasy wczytywania i masę innych problemów. No, ale gra jest więc o co chodzi? :P

Tak tylko dla rozjaśnienia sprawy jakby ktoś zainteresowany też czytał ten wątek, jeszcze raz się podłączę:

- Eksport gry 3D, którą tworzę na WSOC to 5 mb do WebGL. (chcę się zamknąć w 15 mb)
- Wersja na PC to 15 mb.
- Unity w dokumentacji podaje, że pusta scena dla iOS powinna zajmować 22 mb bez optymalizacji.
- Z optymalizacją 12 mb.
(nie mam modułu więc nie sprawdzę swojej gry)

Z tego co czytam z libGDX gry są cięższe, ale to tylko Google, więc nie wiem.

Jak w każdym silniku gra zajmuje tyle, ile Twoje assety. Chyba, że to kółko i krzyżyk.

Druga sprawa. Jacy twórcy taki performance. Generalnie większość tych gier tworzą amatorzy, którzy nie ogarnęliby silnika bez edytora. Wnioskowałbym więc, że tu tkwi sedno. Choć utrzymuję się w przekonaniu, że tylko moje gry mają problemy z wydajnością :) Gdzie zaczyna się optymalizacja, tam zaczynają się prawdziwe schodki, bo tutoriali już nie ma. Zdaje się, że UE ma trochę lepsze podejście do użytkowników pod tym względem.

Kos wspomniał Cocos2D, jest parę takich silniczków jeśli ktoś chce się ograniczyć wyłącznie do 2D. Nie ma co się rozpisywać polecam zajrzeć na tą listę: http://www.slant.co/topics/341/~2d-game-engines

---

FrozenShade - Serio porównujesz VS 2005 i VS 2010 do Eclipse? Ten Eclipse to jakaś wersja z 2005 roku? Unity pobierasz z bridgem do VS 2015, nie trzeba nic konfigurować.

PS: Używam Eclipse do Aplikacji Web i stron internetowych. Visual Studio do pracy z Unity. Nie wyobrażam sobie tego robić na odwrót. Choć zaznaczę, że w ramach rekrutacji do pracy tworzyłem aplikację WEB w .NET i Visual Studio i muszę powiedzieć, że różnica była ogromna, to co w Eclipse wyklepię w 3 minuty, w VS mógłbym w 1. Czytał wszystko i wszędzie, od kolumn bazy danych po klasy w CSS.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline deadeye

  • Użytkownik

# Lipiec 06, 2016, 01:51:40
Niestety i potem byle gra mobilna, która wykorzystuje 0,01% możliwości silnika zajmuje 1GB na karcie i zjada 0,5GB ramu. A gry na PC pisane w Unity mają drastyczne spadki wydajności, długie czasy wczytywania i masę innych problemów. No, ale gra jest więc o co chodzi? :P
Jeśli chodzi o czas ładowania i wydajność, to najczęściej wynika to z czasu poświęconego na optymalizacje, który w przypadku produkcji Unity jest często bardzo niski. Tyle że ten sam dev pisząc własny engine nigdy nie zrobiłby gry :)

Engine sam z siebie nie zamula, ale trzeba umieć go optymalnie wykorzystać - jak każde narzędzie.

Offline Durson

  • Użytkownik

# Lipiec 06, 2016, 04:04:13
Ja korzystam z unity i dziękuję Bogu, że twórcy umożliwili podpięcie dowolnego edytora. Do edycji skryptów w moim gentoo silnik otwiera mi emacsa ;)

Offline JasonVoorhees

  • Użytkownik
    • The Immortal Life of the Son of Jay

# Lipiec 06, 2016, 08:47:36
Niestety i potem byle gra mobilna, która wykorzystuje 0,01% możliwości silnika zajmuje 1GB na karcie i zjada 0,5GB ramu. A gry na PC pisane w Unity mają drastyczne spadki wydajności, długie czasy wczytywania i masę innych problemów. No, ale gra jest więc o co chodzi? :P
Trend jest taki, że używa się Unity i UE m. in. do gier mobilnych. Skoro się używa, to też ludzie nie mają wyboru, tylko muszą mieć mocny sprzęt. Do wymiany sprzętu przyczyniają się promocje (telefon przy przedłużeniu abonamentu).
Jeśli teraz zaczniesz robić grę, to skończysz za rok, może 2. Do tego czasu jeszcze więcej ludzi będzie miało aktualny sprzęt i problem wydajnosci jest nieistotny.

Rozmiar aplikacji jest w miarę skalowalny. W Unity czysty APK ma ok. kilkunastu MB. Przy assetach można zaoszczędzić miejsce włączając kompresję tekstur oraz zmieniając ich wymiary (np. zamiast 1024x1024, robimy 512x512, bo na mobilkach więcej często nie trzeba ;)). Dodatkowo dźwięki/muzykę można przestawić, żeby były konwertowane na mono. W większości przypadków jakość ścieżki dźwiękowej na tym nie ucierpi ;) Dzięki tym zabiegom moja gra ze 110MB APK zmalała do ok 50MB - http://tilotsoj.com/
A jest tam trochę dużych tekstur. Gra była przygotowana pod rozdzielczosc full HD na PC.

Co do środowiska programistycznego, to w Unity od początku używam MonoDevelop i nie widzę tam niczego irytującego ;)
« Ostatnia zmiana: Lipiec 06, 2016, 08:52:14 wysłana przez JasonVoorhees »

Offline FrozenShade

  • Użytkownik
    • Skullstone's official site

# Lipiec 06, 2016, 09:25:41
Coś tam możesz ocenić, jednym z wyznaczników jakości silnika jest ilość, że tak kolokwialnie sobie to nazwę "ślepych uliczek" - sytuacji w któych tworząc oprogramowanie dochodzisz do momentu w którym czegoś nie da się zrobić za pomocą tego silnika.

Zazwyczaj są to sytuacje zaskakujące, nazwali byśmy je funkcje oczywiste które nie zostały uwzględnione w silniku.

No właśnie w JME czegoś takiego nie spotkałem. Byłem w stanie przerobić całkowicie renderowanie (z forward na deferred), podmienić loader materiałów tak, aby dla kart graficznych Intela wczytywał inny plik normalmapy oraz rozwiązać wiele innych, mniejszych lub większych problemów, które na co dzień pojawiają się podczas tworzenia. Właśnie dlatego określiłem ten silnik jako elastyczny.

To juz w ogole ciekawa sytuacja. Wiesz ze wydajnosc VS jako IDE stopniowo sie degradowala, i wlasnie wspomniany VS2010 jest najbardziej "zamulajaca" wersja? Po 2010 zdecydowali ze konieczny jest refaktor, i pozniejsze wersje jak 2012, 2013 czy teraz 2015 maja gigantyczna roznice wydajnosci (mowie tu o wydajnosci przy wielkich repo majacych tysiace plikow C/C++).

Z własnych doświadczeń mogę powiedzieć, że 2008 jest dużo mniej stabilny i  bardziej zamulający niż 2010.
W domu kodzę w Eclipse i nie pamiętam kiedy ostatnio nazwałem to środowisko jakimś brzydkim słowem, a Visualowi obrywa się prawie codziennie ;)

Offline Karol

  • Użytkownik

# Lipiec 06, 2016, 10:05:23
mi się lazarus nawet podoba ale co tu ma IDE do rzeczy skoro i tak przy pisaniu gry w pascalu praktycznie wszystko klepiesz w kodzie?
Właśnie to, że te klepanie w kodzie jest mało wygodne w Lazarusie, brak podglądu zdefiniowanych elementów w pliku, podpowiadanie działa dopiero jak się je wymusi skrótem, a jak już się pojawi to nie wyświetla w podpowiedzi dokumentacji załączonej do metody. Do tego całe IDE to rozwalone naście okien, które ciągle znikają pod innymi, a AnchorDocking jest do bani.

Druga sprawa. Jacy twórcy taki performance. Generalnie większość tych gier tworzą amatorzy, którzy nie ogarnęliby silnika bez edytora. Wnioskowałbym więc, że tu tkwi sedno.
Ok, dzwonię już do Obsidianu powiedzieć im że są ciency w uszach :D

Trend jest taki, że używa się Unity i UE m. in. do gier mobilnych. Skoro się używa, to też ludzie nie mają wyboru, tylko muszą mieć mocny sprzęt.
Ludzie jedzcie gówno, miliardy much nie mogą się mylić ;) Problem w tym, że to często prowadzi do absurdalnych sytuacji, gdzie gra typu Adventure Capitalist (tło + paski postępu) używają Unity i na smartfonie z 2GB pamięci bardzo szybko z tego backgroundu wypada, bo wystarczy, że włączę inną grę (też na Unity) i system musi miejsce robić.

Jeżeli chodzi o 2D to zawsze można wykorzystać jakąś bibliotekę która ma wbudowany prosty rendering 2D, np. SFML. SDL też chyba miał coś takiego z tego co pamiętam.
SFML fajnie wygląda, w miarę prosto.

Offline koirat

  • Użytkownik

# Lipiec 06, 2016, 11:22:31
Co do środowiska programistycznego, to w Unity od początku używam MonoDevelop i nie widzę tam niczego irytującego ;)

Ja tez trochu uzywalem - jakies 4 lata, niestety nie moge podzielic twojej opini. MonoDevelop działa dobrze, do momentu az zaczyna sie sypac ;)

Wielokrotnie mialem sytuacje ze tekst wyswietlany wyswietla sie w zlym miejscu i trzeba zeskrolowac tam i z powrotem zeby sie dobrze wyswietlal.

Debuger często przestawał działać i nawet reset monodevelop nie pomagał. <-- ten bug był najgorszy

Funkcja wyszukiwania ciągów wielokrotnie zawiesiła mi MonoDevelop.

To bylo w tej wersji co szła z unity 4.* niewiem jak to wygląda teraz w unity 5.

Offline Kos

  • Użytkownik
    • kos.gd

# Lipiec 06, 2016, 12:00:25
Trend jest taki, że używa się Unity i UE m. in. do gier mobilnych. Skoro się używa, to też ludzie nie mają wyboru, tylko muszą mieć mocny sprzęt.

Mocnym sprzętem nie nadrobisz faktu że gra zjadła połowę baterii w godzinę. O ile w ogóle dasz radę grać godzinę, bo po 30 minutach telefon parzy w ręce. Co z tego że chodzi szybko? Poza tym nawet na mocnym telefonie gry unity wgrywają się 5-10 sekund albo i więcej. Powinniśmy sobie stawiać wyżej poprzeczkę, jako gracze i jako deweloperzy.

Offline JasonVoorhees

  • Użytkownik
    • The Immortal Life of the Son of Jay

  • +1
# Lipiec 06, 2016, 12:46:35
Powinniśmy sobie stawiać wyżej poprzeczkę, jako gracze i jako deweloperzy.
Dobrze, my sobie postawimy poprzeczkę wyżej, a tymczasem programiści bez takich barier/oporów zrobią kilka fajnych gier ;)
Jeśli chcemy być na rynku pracy, czy nawet na rynku gier (indywidualnie) konkurencyjni, to musimy korzystać przynajmniej z takich ułatwień jak wszyscy inni.
Walka o słuszność nie dużego znaczenia z perspektywy gracza.
« Ostatnia zmiana: Lipiec 06, 2016, 12:53:32 wysłana przez JasonVoorhees »

Offline Kos

  • Użytkownik
    • kos.gd

  • +4
# Lipiec 06, 2016, 14:59:45
Nie chodzi mi o słuszność tylko o user experience. Wiele razy przestałem grać w grę bo mi się któregoś razu nie chciało czekać aż się wgra albo było mi szkoda baterii.

Offline JasonVoorhees

  • Użytkownik
    • The Immortal Life of the Son of Jay

# Lipiec 06, 2016, 15:10:41
Mi na Hearthstone nigdy nie było szkoda baterii :)

Offline koirat

  • Użytkownik

# Lipiec 06, 2016, 15:55:32
@Kos
Najwyraźniej gra nie była na tyle dobra aby było warto na nią czekać.

Offline toxic

  • Użytkownik

# Lipiec 06, 2016, 16:27:04
Cytuj
No dobra, a jak z Cocos2D? też duże, też PC+mobilki, ale jakby mniej kolosalne. Ktoś coś widział, coś wie, opowie?

Cocos2D nie, ale 'liznąłem' trochę Cocos2d-js (czyli zasadniczo taki wrapper javascriptowy na Cocos2D-x). Taki tam HelloWorld na resorach.

Jak dla mnie może być, tylko:
a) javascript niewiele kupował. Ponieważ to się i tak potem w runtimie wykonywało jako natywny kod, to nie za bardzo dało się rozpędzić z javascriptem - np. trzeba było w paru miejscach się domyślić, które 'obiekty' javascriptowe musisz zwolnić odpowiednią metodą, a które nie (garbage collector tak działał)
b) coś mi spowalniał przy dużej ilości (>200) obiektów na ekranie. Ale nie zrobiłem testów, czy to rendering (za dużo sprajtów), czy też logika moja nieoptymalnie napisana.

Ot, takie tam. Pewnie "zwykły" Cocos2d nie ma takich hm... niespodzianek. Ale ogólne wrażenie fajne.

Offline laggyluk

  • Użytkownik
    • http://laggyluk.com

# Lipiec 06, 2016, 18:19:37
Nie chodzi mi o słuszność tylko o user experience. Wiele razy przestałem grać w grę bo mi się któregoś razu nie chciało czekać aż się wgra albo było mi szkoda baterii.
poza cocosem jest jeszcze marmalade dla hardkorów

Offline damoch

  • Użytkownik

# Lipiec 08, 2016, 19:21:17
Ja korzystam z Unity+VS albo Game Makera:Studio. I moim zdaniem, jeżeli ktoś chce robić projekt 2D jakiejkolwiek wielkości Game Maker  powinien w zupełności wystarczyć. Na początku zaporowa może wydawać się cena, ale jeżeli będziesz miał jakiś konkretny pomysł to pewnie nie będzie stanowiła problemu.
http://www.yoyogames.com/get