Warsztat.GD

Produkcja gier => Produkcja => Wątek zaczęty przez: lukaszsa w Czerwiec 26, 2015, 22:05:38

Tytuł: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: lukaszsa w Czerwiec 26, 2015, 22:05:38
Cześć

Nie jestem tutaj świerzakiem ale potrzebuję pomocy w podjęciu ważnej decyzji (nie oczekuję że ktoś podejmie ją za mnie oczywiście).

Mam zakończony dokument który można by podciągnąć pod Game Vision Document i jestem w trakcie tworzenia szczegółowego opisu gry (Game Design Document) aha i żeby było jasne z pomysłem przespałem się wiele nocek i w ciągu 0.5 roku z bardzo złożonego projektu wyszła prosta i ciekawa ale nie prostacka gra.
Żeby mi pomóc musicie nieco wiedzieć o mnie i o grze. Coś o mnie:
Jestem programistą z małym doświadczeniem zawodowym piszę od 8 miesięcy w Java, od miesiąca w JavaScript, pisałem kiedyś proste skrypty w Python oraz od zawsze męczę podręczniki do C++ oraz napisałem pracę inżynierską w C++ (Sokobana). Za dużo czasu traciłem w życiu na podręczniki z ćwiczeniami a oczywiście za mało na projekty.

Postanowiłem jak pewnie wszyscy że stworzę grę i ją wydam.

To ma być platformowa gra przygodowa 2D z budowaniem jak w Terrari tylko że surowców jest tyle ile palców u jednej ręki a świat jest dużo prostszy i mniej zróżnicowany i mechanika też będzie dużo prostsza będzie w tym również opowiadana historia przez obrazki.

I tu jest pytanie jakie rozwiązanie polecacie. Zacząłem się uczyć SFML i Box 2D (piszę w C++) i pierwotnie myślałem żeby się tego nauczyć i napisać grę... ale mam 30 lat:) mam w tym roku zrobić certyfikat z Java(Associate) i zaaklimatyzować się w nowej pracy bo wreszcie pracuję jako programista i to wszystko ma wpływ na mój wolny czas i energię do pracy a grę chciałbym zaimplementować(z jakimś grafikiem i muzykiem jak już będę miał co im pokazać) i wydać w skończonym czasie to jest max 3 lata.
Doszedłem do wniosku, że nauka SFML BOX 2D i pisanie gry od podstaw to karkołomna rzecz(chociaż robiłbym to z wielką frajdą) i lepiej było by może użyć Silnika Unity ale to chyba wymaga licencji(czy dopiero jak będę chciał wydać to będę musiał wykupić licencję bo nie mam raczej kasy)

Pomóżcie proszę i doradźcie jakie rozwiązanie ma jakie wady i zalety.

Pozdrawiam i z góry dziękuję
Łukasz
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: Xirdus w Czerwiec 26, 2015, 23:09:10
lepiej było by może użyć Silnika Unity ale to chyba wymaga licencji(czy dopiero jak będę chciał wydać to będę musiał wykupić licencję bo nie mam raczej kasy)
Nie trzeba żadnej licencji, ani teraz ani przy wydaniu.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: lukaszsa w Czerwiec 27, 2015, 00:28:39
Ja kto to on jest darmowy nawet do użytku komercyjnego? Tak wiem przeczytać sobie licencję zrobię tak. (ale w którymś momencie będzie trzeba zapłacić pewnie?)

Wiem, że jest piątek wieczór więc mam nadzieję, że jutro pojawi się kilka pomysłów.

Gra ma być na PC bo o tym nie pisałem i zastanawiam się też czy jest jeszcze jakiś silnik w Javie?
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: laggyluk w Czerwiec 27, 2015, 00:35:52
jeżeli chcesz ją faktycznie zrobić a nie tylko robić to polecam ścieżkę Unity
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: Kyroaku w Czerwiec 27, 2015, 00:48:13
W Unreal Engine możesz pisać w C++ (jakby co).
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: lukaszsa w Czerwiec 27, 2015, 09:54:37
Rozważam też inne opcje.

Między innymi  SDK w Java takie jak: JMonkeyEngine bo w końcu to było by z korzyścią dla mnie i mojej pracy bo wymusza intensywną naukę Java.

Szukam również silnika mającego możliwości jak te w Unity 2D tylko z Java.

Jednak cały czas muszę mieć na uwadze że chcę skończyć tą grę.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: Radomiej w Czerwiec 27, 2015, 11:50:17
W takim razie polecam ci LibGDX, piszesz w Javie. Możliwość portów na Androida, iOS, PC, HTML(GWT). Więc jeśli idziesz w kierunku Javy to idealny framework dla ciebie. Mocne community, sporo dodatkowych bibliotek i na pewno ma dobre wsparcie dla gier 2d(w 3d nie siedzę ale jakbym miał pisać coś większego to jednak na 70% wybrałbym MonkeyEngine). A jeśli chcesz wydać grę to naprawdę polecam polegać na bibliotekach innych osób i skupić się na pisaniu gry a nie na implementacji własnego silnika, bo nie zrobisz tego dobrze(presja czasu będzie kazała ci zrobić tylko tyle żeby działało).
Ja osobiście pracuję z takim zestawem:
- LibGDX
- LibGDX AI
- Ashley
- Box2D

Jeśli nie chcesz polegać na proceduralnym świecie to masz także wsparcie dla titlesetów, więc możesz sobie zagarnąć do pracy jakiś edytor i postawić swój level.
https://github.com/libgdx/libgdx/wiki (https://github.com/libgdx/libgdx/wiki)
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: sramtuitam w Czerwiec 27, 2015, 12:12:34
Cytuj
napisałem pracę inżynierską w C++ (Sokobana)

Mistrz świata!
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: wozix w Czerwiec 27, 2015, 19:52:54
A ja Ci zaproponuję Cocos2d-x. Piszesz w C++, masz ogromne community i deploy niemal wszędzie. Do wyboru bodajże 2 silniki fizyki (Chipmunk2D i Box2D). Sporo tooli. Na licencji MIT-podobnej.
Dla dynamicznej gry według mnie nie ma co się pakować w Javę, bo większość czasu będziesz się drapał po głowie jak tu oszukać GC, żeby się nie wywoływało.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: Xion w Czerwiec 27, 2015, 19:56:09
Cytuj
Dla dynamicznej gry według mnie nie ma co się pakować w Javę, bo większość czasu będziesz się drapał po głowie jak tu oszukać GC, żeby się nie wywoływało.
Znaczy unikać alokacji pamięci w głównej pętli gry, dokładnie tak samo jakby należało to robić w C++?...
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: bies w Czerwiec 27, 2015, 20:04:01
Znaczy unikać alokacji pamięci w głównej pętli gry, dokładnie tak samo jakby należało to robić w C++?...
Unikanie alokacji w Javie jest o wiele trudniejsze niż się na pierwszy rzut oka wydaje. Pamiętaj, że nie masz stosu i wszystkie obiektowe zmienne lokalne alokują.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: ArekBal w Czerwiec 27, 2015, 22:49:54
Tak to napisałeś jakby było trudniejsze niż w C/C++.
Jak korzystasz z libki gamedevowej to ta raczej nie alokuje...

A unikanie "new" samemu to chyba żadna magia. "Object Pooling for the win"
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: sramtuitam w Czerwiec 27, 2015, 23:26:04
Unikanie alokacji w Javie jest o wiele trudniejsze niż się na pierwszy rzut oka wydaje. Pamiętaj, że nie masz stosu i wszystkie obiektowe zmienne lokalne alokują.

Bzdura, poczytaj sobie o "escape analysis" w Javie.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: ArekBal w Czerwiec 27, 2015, 23:35:05
Aaaale to się sprawdzi tylko dla znanych typów "stosunkowo" prostych, typu vector3d/float3/Matrix4x4. Dla typu który gdzieś tam trzyma referencje nie można sobie "założyć" że kompilator to przewali na stos.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: wozix w Czerwiec 27, 2015, 23:43:38
Rozważam też inne opcje.

Między innymi  SDK w Java takie jak: JMonkeyEngine bo w końcu to było by z korzyścią dla mnie i mojej pracy bo wymusza intensywną naukę Java.

Moment, moment. Masz 30 lat, ukończyłeś studia (przez co zakładam, że konceptualnie programowanie jest Ci bliskie), programujesz od 8 miesięcy w Javie i nadal się jej uczysz? Idąc twoim tokiem myślenia nie nauczysz się programować w Javie robiąc grę, bo choćby nie nauczysz się J2EE.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: lukaszsa w Czerwiec 28, 2015, 10:56:33
Moment, moment. Masz 30 lat, ukończyłeś studia (przez co zakładam, że konceptualnie programowanie jest Ci bliskie), programujesz od 8 miesięcy w Javie i nadal się jej uczysz? Idąc twoim tokiem myślenia nie nauczysz się programować w Javie robiąc grę, bo choćby nie nauczysz się J2EE.
No tak fakt umiem programować w Javie. Po prostu czasem muszę zajrzeć do książki żeby sobie przypomnieć. Czasami za bardzo fiksuję się na tym żeby napierać podręczniki żeby trzaskać każdą regułkę, definicje w nocy o północy zamiast kodować po prostu.

Mistrz świata!
Ha ha:) To był taki wielki std::cout << "PRACA INŻYNIERSKA << std::endl; :)

Dziękuję za pomoc. Przemyślałem wszystkie za i przeciw.
@laggyluk - napisał, że jak chcę zrobić a nie robić grę to wybrać Unity. To była świetna uwaga.

Musiałem się zastanowić czy chcę sobie dłubać silnik żeby sobie coś udowodnić lub się pochwalić czy tak naprawdę chcę zrobić grę. W internecie znalazłem również coś takiego:):
Cytuj
If you want to make games, make games.
If you want to make engines, that's cool too. But IMO it runs against the "making games" goal.

To drugie nie zawsze musi być prawdą ale jak patrzę na internety to widzę często dużo fajnych zaczętych gier na swoich silnikach i tyle lub aż tyle ale jednak nie są to ukończone projekty bardzo często.

Po rozważeniu wszystkich za i przeciw wybrałem UNITY GAME ENGINE.

Dziękuję wszystkim za pomoc i życzę wszystkim skończenia projektów.:)
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: koirat w Czerwiec 28, 2015, 12:18:26
Powiedz czy planujesz w swojej grze save game-y i mam tu na myśli zapisanie i odczytanie gry w każdym momencie. Bo jeśli wybrałeś Unity3d to możesz mieć poważny problem.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: sramtuitam w Czerwiec 28, 2015, 13:32:06
Aaaale to się sprawdzi tylko dla znanych typów "stosunkowo" prostych, typu vector3d/float3/Matrix4x4. Dla typu który gdzieś tam trzyma referencje nie można sobie "założyć" że kompilator to przewali na stos.

I to w zupełności wystarczy. W C/C++ referencje też trzyma się w postaci wskaźników do obiektów na stercie. Stos nie jest po to, żeby trzymać w nim całą aplikacje. Najczęściej używa się go do obliczeń wykonywanych w locie na takich właśnie typach jak wymieniłeś.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: laggyluk w Czerwiec 28, 2015, 13:36:48
Powiedz czy planujesz w swojej grze save game-y i mam tu na myśli zapisanie i odczytanie gry w każdym momencie. Bo jeśli wybrałeś Unity3d to możesz mieć poważny problem.
a we własnym silniku nie? trzeba sobie radzić
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: lukaszsa w Czerwiec 28, 2015, 13:55:52
Tak planuję zapis gry a w czym problem? (podjąłem decyzje już i muszę się tego trzymać poza tym jak by się i w czym by się nie robiło gry zawsze napotka się wiele rożnych problemów)
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: JasonVoorhees w Czerwiec 28, 2015, 13:56:41
Powiedz czy planujesz w swojej grze save game-y i mam tu na myśli zapisanie i odczytanie gry w każdym momencie. Bo jeśli wybrałeś Unity3d to możesz mieć poważny problem.
A co uważasz za problem z save'ami w Unity?
W Unity wszystko (nawet GameObject) jest serializowane, cały edytor opiera się na serializacji, zapis gry w takim środowisku to pikuś.

Szukam również silnika mającego możliwości jak te w Unity 2D tylko z Java.

C# to jest taka Java dla Unity. Naprawdę nie poczujesz różnicy, chyba, że zaczniesz korzystać z "property", ale to jest opcjonalne, bo możesz bez problemu operować na zwykłych polach i pisać do nich gettery, settery.

Warto poznać filozofię pracy w Unity i nie nastawiać się na Javowy profil działania. Zmieniając tok myślenia, poznając dobre praktyki pracy w Unity możesz tylko zyskać.

Od siebie polecę serię tutoriali: https://www.youtube.com/watch?v=cL9iHR1JxcE
Obszerne i wyjaśniające filmy :)
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: koirat w Czerwiec 28, 2015, 14:07:03
@JasonVoorhees Jak by tylko dało się zrobić w grze to co w edytorze to można by ratować sytuację.
Masz może jakieś doświadczenie z zapisem gry w Unity3d ?

Problem jest taki że jak korzystasz z bibliotek/frameworków typu black-box to może się okazać że czegoś się nie da zrobić. We własnym silniku zawsze możesz zmienić co zechcesz.

Spędziłem 3 miesiące próbując zrobić zapisywanie i odczytywanie gry w Unity3d w każdym momencie (3 lata tworząc samą aplikacje - full time). I mam już pewną opinię na temat tego silnika.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: JasonVoorhees w Czerwiec 28, 2015, 14:18:35
@koirat: Aż takich rzeczy nie robiłem w Unity, wybacz ;) Póki co robię mniejsze gry, w których wystarczy zapisać ustawienia użytkownika. Dzięki za wyjaśnienie.

Jakbym chciał zapisać grę w każdym momencie, to zacząłbym od kombinowania z serializacją wszystkich obiektów na scenie. Przy ładowaniu bym je po prostu deserializował :)

Teraz na szybko poszukałem czegoś na ten temat i znalazłem coś interesującego:
http://answers.unity3d.com/questions/443525/serialize-a-gameobject-including-components.html

Cytuj
   //Save it
   byte[] data = anyGameObject.SaveObjectTree();
 
   //Load it back
   data.LoadObjectTree();

Próbowałeś czegoś takiego?


Wiem, że własny silnik daje dużą dowolność (sam do niedawna działałem na własnych). Wybór obcego silnika wiąże się z podporządkowaniem się wszystkiemu co oferuje, z ewentualnymi wadami, czy zaletami. Aczkolwiek obchodzenie wad, czy wykonanie czegoś inaczej niż sobie wyobrażaliśmy jest również interesujące :)
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: laggyluk w Czerwiec 28, 2015, 14:23:33
Spędziłem 3 miesiące próbując zrobić zapisywanie i odczytywanie gry w Unity3d w każdym momencie (3 lata tworząc samą aplikacje - full time). I mam już pewną opinię na temat tego silnika.
Wasteland 2 i Pillars of Eternity potrafi zrobić save game to chyba się da?

mi póki co wystarczało playerprefs a w nieco bardziej złożonych przypadkach serializacja do xml albo własnego formatu. fakt że nie miałem przypadku gdzie konieczny byłby zapis całej sceny.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: koirat w Czerwiec 28, 2015, 14:32:43
Funkcje które wysłałeś to rozszerzenie udostępnione dzięki UnitySerializer, któreg strona internetowa nawet już nie działa. Oczywiście próbowałem tego i innych cudów ale to po prostu mi nawet nie działało.

Powiem tak doszedłem już dość daleko w tej całej serializacji, już nawet pojawiały mi się obiekty z animacjami na scenie, materiały, textury , lightmapy itp. Ale niektórych rzeczy się najnormalniej w świecie nie dła zapisać bo w run-time po prostu nie ma do nich dostępu.

Ale na prosty rozum i chwilę zastanowienia, jak by dało się zapisać grę to już dawno by zespół Unity o tym trąbił, przecież taki monumentalny feature zasługuje na konkretny marketing.
Ale jak widzisz stosują raczej strategie zaciemniania gdzie savegame-em nazywają serializację kilku prymitywnych pól i zapisaniem ich do PlayerPrefs.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: koirat w Czerwiec 28, 2015, 14:36:57
Wasteland 2 i Pillars of Eternity potrafi zrobić save game to chyba się da?
Może mają save-game stratny, odczytujesz grę i masz w gruncie rzeczy co innego, tylko player nie zauważa.
Ogólnie w naszej grze nie mogliśmy sobie pozwolić na coś takiego.

Satysfakcjonujący nas save game mogę opisać tylko w ten sposób. Wgrywam pustą scenę, deserializuje uprzednio zapisany stan gry, i mam wszystko jak poprzednio.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: laggyluk w Czerwiec 28, 2015, 14:38:37
jakiś taki memory dump, ciekawe
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: koirat w Czerwiec 28, 2015, 14:53:32
Tak, powiem ci że już nawet daleko w tym zaszedłem, korzystając z refleksji, zapisywałem całą strukturę razem z polączeniami referencyjnymi, eventy, delegaty, structury, yield, tablice itp. W planie jeszcze miałem zająć się słownikami typu Dictionary HashSet bo one wymagają specjalnego traktowania podczas serializacji. Jednak w końcu się poddałem bo Unity3d wbiło mi nóż w plecy, można powiedzieć że mam za swoje bo przecież spodziewałem się tego ;(. (biorąc pod uwagę z czym już się zetknąłem podczas pracy z tym produktem).
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: deadeye w Czerwiec 28, 2015, 15:02:21
Może mają save-game stratny, odczytujesz grę i masz w gruncie rzeczy co innego, tylko player nie zauważa.
Ogólnie w naszej grze nie mogliśmy sobie pozwolić na coś takiego.

Satysfakcjonujący nas save game mogę opisać tylko w ten sposób. Wgrywam pustą scenę, deserializuje uprzednio zapisany stan gry, i mam wszystko jak poprzednio.
Miałem taki system w xml - każda property była odczytywana za pomocą refleksji i serializowana do xml, analogicznie odczyt polegał na setowaniu każdej property gameobjectów przez refleksję. W takiej wersji definicja levelu nie różni się niczym od save (bo save to po prostu stan świata z danego momentu). Z tego co pamiętam, miał on mniej niż 500 linijek kodu i powstał w tydzień (nie licząc assetów oczywiście), drugi tydzień żeby wczytywać dowolnie zdeformowane meshe z obj.

Oczywiście żeby taki system miał sens działać, to każdy gameobject musi być odpowiednio zaprojektowany - tworzyzs go, ustawiasz mu dane, jak transform, dane logiki (np typ jednostki, hp, typ broni) a kod prefaba sam na podstawie tych danych odtwarza odpowiednie wewnęrzne gameobjecty (np na podstawie typu broni odtwarza odpowiedni child z danym typem broni, jego meshem itd). Można też serializować wszystko, ale takie podejście nie ma sensu z powodów logicznych - choćby nie wiadomo co było zainicjalizowane a co nie.


Anyway, dla większości gier takie rozwiązanie jest błędne - zamiast tego powinno się trzymać cały gamestate jako czyste dane, klasy, które mają dane typu pozycja, typ jednostki itd, ale nie są gameobjectami Unity tylko zwykłymi klasami. Takie klasy możesz serializować od ręki, i później na ich podstawie odtworzyć całą scene. Wtedy też kod logiki gry operuje na czystych danych, i nie masz typowego mojo jakie tworzą początkujący userzy Unity, gdy piszą wszystko w gameobjectach i mieszają wartwy logiki z prezentacją itd. \


// z tego co piszesz, to ty nie chcesz serializować świata gry, tylko cały stan aplikacji w danym momencie. Wg mnie takie rozwiązanie to overkill, i to niezależy od silnika którego używasz.z
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: CheshireCat w Czerwiec 28, 2015, 15:33:48
@JasonVoorhees Jak by tylko dało się zrobić w grze to co w edytorze to można by ratować sytuację.
Masz może jakieś doświadczenie z zapisem gry w Unity3d ?

Problem jest taki że jak korzystasz z bibliotek/frameworków typu black-box to może się okazać że czegoś się nie da zrobić. We własnym silniku zawsze możesz zmienić co zechcesz.

Spędziłem 3 miesiące próbując zrobić zapisywanie i odczytywanie gry w Unity3d w każdym momencie (3 lata tworząc samą aplikacje - full time). I mam już pewną opinię na temat tego silnika.

Ja mam z kolei problem z fizyką w Unity przy większych prędkościach (ale daleko im do relatywistycznych).
Próbowałem różnych tutoriali, workaroundów, nawet najmniejszego, niemal ciągłego, próbkowania, długo dyskutowałem również z jednym z programistów Unity, z którym tak się złożyło studiowałem :)
Skończyło się na tym, że musiałem napisać podzbiór fizyki od zera.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: koirat w Czerwiec 28, 2015, 15:37:04
// z tego co piszesz, to ty nie chcesz serializować świata gry, tylko cały stan aplikacji w danym momencie. Wg mnie takie rozwiązanie to overkill, i to niezależy od silnika którego używasz.z
Niech się serializuje chociaż świat, z resztą jakoś sobie poradzę.

Osobiście moim zdaniem każdy engine gry powinien mieć taką funkcjonalność jak zapis i load.  Nie wiem co dla ciebie znaczy overkill jeśli ilość zajętej pamięci przez taki save, to uważam że to nie problem. Pierwsza sprawa to przecież nie musimy umieszczać mediów w pliku (chyba że zechcemy - powinna być taka opcja), Druga to że powinniśmy móc wykluczyć niektóre dane z procesu serializacji jak nie chcemy ich serializować, albo utworzyć dla nich surrogaty jeśli te dane możemy w jakiś sposób odtworzyć. Na koniec można dane spakować żeby zajmowały mniej miejsca.

Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: laggyluk w Czerwiec 28, 2015, 16:59:34
UE4 niby ma wbudowany save, ciekawe jak bardzo bo od czasu do czasu strugam grę z fizyką..
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: koirat w Czerwiec 28, 2015, 17:37:52
W Unity3d dawałem jakoś radę zapisać fizykę, UE4 z tego co wiem też używa PhysX więc nie powinno być problemów. Ale sam jestem ciekaw jak to w UE4 działa.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: Kos w Czerwiec 28, 2015, 19:00:49
Anyway, dla większości gier takie rozwiązanie jest błędne - zamiast tego powinno się trzymać cały gamestate jako czyste dane, klasy, które mają dane typu pozycja, typ jednostki itd, ale nie są gameobjectami Unity tylko zwykłymi klasami. Takie klasy możesz serializować od ręki, i później na ich podstawie odtworzyć całą scene. Wtedy też kod logiki gry operuje na czystych danych, i nie masz typowego mojo jakie tworzą początkujący userzy Unity, gdy piszą wszystko w gameobjectach i mieszają wartwy logiki z prezentacją itd.

Wow, srsly? W 'poważnym' unity radosne korzystanie z gameobjectów się nie sprawdza i należy wszystko pisać samemu? Jestem nieco zaskoczony.

Dziwię się też że nazywasz to 'mieszaniem warstwy logiki z prezentacją'. Znaczy co, całe Unity to prezentacja, a własny kod to logika? Myślałem że o to chodzi w podejściu komponentowym, że podział odpowiedzialności jest jakby w inną stronę - jedne komponenty od wyświetlania, inne od logiki, a GameObject spina wszystko w całość.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: laggyluk w Czerwiec 28, 2015, 19:12:42
no to żaden sekret że z unity wychodzą takie kwiatki po jakimś czasie użytkowania nie mniej powoli idzie ku lepszemu :P
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: koirat w Czerwiec 28, 2015, 20:32:37
Niestety jeśli gruntownie nie przerobią core, co niestety się nie zapowiada, to powolne podążanie w dobrą stronę utknie w minimum lokalnym.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: lukaszsa w Czerwiec 29, 2015, 10:38:20
To jak juz poruszyliscie ten temat to pytanko.
Czyli zapisywanie stanu gry to moze byc jakis duzy problem?
Bo to bedzie po czesci jak w Terrari kafelki beda mialy swoje wlasciwosci, postac rownierz, w grze bedzie rownierz opis sytuacji zwiazanej z oczekiwanym zdarzeniem do ktorego moze byc odliczany czas. Pewna "maszyna stanow relacji NPCow do postaci"... itd.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: laggyluk w Czerwiec 29, 2015, 10:42:59
jeżeli jesteś w stanie sobie wyobrazić mechanizm zapisu i odczyty z pliku stanu owych obiektów to nie :P poprostu unity nie ma wbudowanej magicznej funkcji 'save game' która zrobiła by to za Ciebie
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: koirat w Czerwiec 29, 2015, 11:24:11
Zależy jak masz grę zaprojektowaną. Ale zakładam że poza danymi obiektu trzeba jeszcze odbudować relację pomiędzy obiektami, np gdy jeden obiekt przechowuje referencję do drugiego. Jeśli korzystasz z wątków to również trzeba zdawać sobie sprawę że może być to dodatkowy problem.

Zresztą już od pewnego czasu chodzi mi po głowie jak sensownie to rozwiązać, mowa o uniwersalnym systemie zapisu, i przyznam że nie jest to trywialne zadanie.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: lethern w Czerwiec 29, 2015, 14:18:00
(na moją wiedzę) Problem z zapisem najpewniej pojawi się przy m.in. wskaźnikach i referencjach - nie da się zserializować wskaźnika, trzeba serializować jako identyfikator, a przy loadzie umieć zamienić go na obiekt. Niby proste, ale ten obiekt musi istnieć, więc problemem może być odpowiednia kolejność loadu lub kolejność tworzenia. Jeśli obiekt A wskazuje na obiekt B, a ten wskazuje na obiekt A, to albo mamy problem (bo nie możemy zalinkować ich ze sobą w czasie konstrukcji - jeden nie będzie istniał gdy tworzymy drugi), albo rozdzielamy wczytywanie-konstruowanie obiektów od wczytywania-podpinania wskaźników (żeby nie mieć problemu z kolejnością ani z wspomnianymi "pętlami"). Dalej, problem wskaźników dotyczy czasem i bardzo prostych rzeczy - małych struktur czy klas, które są dynamiczne i  akurat są wskazywane w kilku miejscach - nie chcemy zapisywać ich wartości, tylko wskaźnik (identyfikator). Jeśli nie mamy automatu, który serializuje zawartość obiektu, jak i "transformuje" wskaźniki na identyfikatory i z powrotem, to może to być sporo roboty. Dalej temat zahacza o dynamiczne funkcje / delegaty / lambdy (jak je zapisywać / identyfikować). Dalej są jeszcze nie-nasze obiekty (3rd party), przy których możemy nie mieć dostępu do środka, żeby móc je zapisać (i nie należy tu myśleć o jednej konkretnej klasie z silnika, możemy potrzebować zapisać stan różnych klas, z różnych bibliotek)
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: laggyluk w Czerwiec 29, 2015, 14:23:29
no tak ale jest to wciąż raczej zagadnienie wspólne dla różnych silników niż konkretnie unity. poprawcie mnie jeśli się mylę i save jest w każdym innym frameworku którego nie próbowałem
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: komorra w Czerwiec 29, 2015, 15:22:08
Można referencjować po unikalnym ID: http://docs.unity3d.com/ScriptReference/Object.GetInstanceID.html
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: lukaszsa w Czerwiec 29, 2015, 20:38:19
Dziękuję za wyczerpujące odpowiedzi i ciekawą dyskusję.

Qrcze jeszcze długa droga przede mną dopiero jestem w połowie pisania Dokumentu Projektu Gry(język polski jest piękny).
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: koirat w Czerwiec 29, 2015, 21:56:18
Można referencjować po unikalnym ID: http://docs.unity3d.com/ScriptReference/Object.GetInstanceID.html
Do identyfikacji podczas zapisu używałem tego RuntimeHelpers.GetHashCode w przypadku własnych obiektów również. Nie ufam niczemu co wydobywa się z silnika Unity3d ;) , między innymi funkcji zwracającej HashCode dla obiektów z UnityEngine która jest  overridowana i zwraca z tego co pamiętam  GetInstanceID (cokolwiek ma ono oznaczać).

Toć to się aż prosi o jakąś kolizję w przypadku użycia słownika.
Jak można pokusić się o zmianę HashCode dla typów referencyjnych jest dla mnie zagadką.

Najgorsze jest jednak to że nie wiem czy przypadkiem nie nastąpi gdzieś sytuacja w którym Unity3d utworzy dwa różne obiektu .NET udające ten sam obiekt, czyli odnoszące się do tego samego obiektu w enginie.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: komorra w Czerwiec 29, 2015, 22:04:04
Ale GetHashCode jest haszem, używanym głównie przy wyszukiwaniu właśnie, słownikach, itp. Natomiast GetInstanceId powinien zwracać unikalne ID obiektu (żadne dwa różne obiekty nie mogą mieć tego samego instanceId). Dlatego przy odtwarzaniu referencji hasz nie powinien być używany - bo właśnie są kolizje, a instanceId.

GetInstanceID (cokolwiek ma ono oznaczać).

Unikalne ID obiektu, zapewne inkrementowane za każdym razem gdy wywoływany jest (wewnętrznie czy zewnętrznie) konstruktor UnityEngine.Object. A jak wiadomo prawie wszystkie klasy silnika po nim dziedziczą.

Ewentualnie można sobie GUIDami radzić jakoś, ale C# powy GUID string - to string więc szybkość jego przeszukiwania i operacje mogą być pewnie wolniejsze, niż porównywanie intowych instanceID.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: koirat w Czerwiec 29, 2015, 22:47:10
GamoObject.GetHashCode zwraca GameObject.InstanceID i tu jest problem. Bo nie wiadomo co to jest ten InstanceID. Jeśli będe miał dictionary z jakimiś tam obiektami i między innymi z GameObject to może się okazać że jakiś tam inny obiekt będzie miał taki sam HashCode co GameObject.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: Xion w Czerwiec 30, 2015, 01:40:41
@up: Będziesz miał dictionary/(hash)(mapę)/etc. używające GameObject jako klucza? I jeszcze do tego z wymieszanami jakimiś innymi obiektami jako kluczami? Huh?! Nie wiem, co to za design, ale osobiście trzymałbym się od niego z daleka.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: lethern w Czerwiec 30, 2015, 02:55:37
czytam ten post.. i czytam... no i nijak nie widzę wzmianki o gameobject-kluczu
xion, to tak absurdalny pomysł, że nie wiem jak mógł wpaść komuś do głowy
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: Xion w Czerwiec 30, 2015, 08:06:41
Wiem, że absurdalny. Ale z jakiegoś powodu koirat wspomniał o wbudowanej w język (C#, a także w Javę, Pythona, etc.). funkcji do obliczania hashkodów obiektów. Hashkodów, które istnieją po to właśnie, żeby obiekty można było trzymać w hashowalnych strukturach: w zbiorach jako elementy i słownikach jako klucze.

Stąd moje założenie, że z jakiegoś bardzo dziwnego powodu chodziło mu o słownik kluczowany GameObjectami. Alternatywą była bowiem jeszcze dziwniejsza konstrukcja słownika int->GameObject, gdzie kluczem każdej wartości jest jej własny hashkod. To oczywiście ma zero sensu, bo jest równoważne zwykłemu zbiorowi elementów GameObject; sama struktura danych zapewnia tu unikalność względem hashkodu.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: koirat w Czerwiec 30, 2015, 09:39:11
@up: Będziesz miał dictionary/(hash)(mapę)/etc. używające GameObject jako klucza? I jeszcze do tego z wymieszanami jakimiś innymi obiektami jako kluczami?
Ale jaki masz problem z GameObject jako kluczem ? Naprawdę jestem w stanie sobie wyobrazić multum przypadków gdzie było by to użyteczne. Choćby nawet użycie takiego HashSet<GameObject>

Cytuj
int->GameObject, gdzie kluczem każdej wartości jest jej własny hashkod. To oczywiście ma zero sensu, bo jest równoważne zwykłemu zbiorowi elementów GameObject; sama struktura danych zapewnia tu unikalność względem hashkodu.
Tylko że wyszukiwanie danego obiektu w dużym zbiorze może trwać bardzo długo, z użyciem hashcode jest to bardzo wydajne.

Natomiast dlatego int->"Jakis Object" bo nie wiem czy ktoś nie tworzy własnej implementacji GetHashCode dla danego obiektu. Więc aby tego uniknąć (akurat potrzebowałem tego uniknąć) musiałem zawsze zastosować defaultową implementację GetHashCode.
Tytuł: Odp: Gotowy silnik czy pisanie od podstaw gry do wydania.
Wiadomość wysłana przez: fn2000 w Lipiec 23, 2015, 14:56:55
HashCode - domyślna implementacja tego w C# nie jest polecana do unikalnego oznaczania obiektów.

W temacie: przy obecnych dostępnych narzędziach i SDKach stworzenie gry 3D na bazie własnego silnika lub gotowego SDKa, dla osoby, która nie zna gotowego SDK jest porównywalne - czas na tworzenie silnika jest dyskontowany przez ścieżkę nauki SDKa i jego optymalizację pod konkretne rozwiązanie.

Należy sobie odpowiedzieć na dodatkowe pytania:

- na jakie platformy ma być dostępna gra: im jest ich więcej tym zyskujesz bardziej korzystając z gotowego, multiplatformowego SDKa,

- jaka jest ogólna jakość gry: jeśli tworzysz graficznie BF4 lub Crysisa: SDK traci na atrakcyjności - będzie wymagało głębokiej ingerencji / zaawansowanego korzystania, żeby osiągnąć oczekiwany rezultat.

- czy jesteś programistą czy artystą? Jeśli to drugie to gotowy SDK daje większe szanse na dokończenie projektu,

- jak sprawną kontrolę sprawujesz nad samym sobą? W przypadku tworzenia własnej technologii w 99% przypadków skończysz na tworzeniu silnika na sprzedaż (zarabianie na sprzedaży własnej technologii - czyż to nie wspaniały i nowatorski pomysł? Złośliwość zamierzona) niżeli gry.

Ogólna rada:

- stwórz prototyp gry w Unity (lub innym SDKu) - doprowadź to do wersji grywalnej, z tymczasową grafiką - jeśli dojdziesz do tego etapu jesteś miszczem! Dalej popraw grafikę, daj na Early Access i odcinaj kupony ;)