Autor Wątek: Gotowy silnik czy pisanie od podstaw gry do wydania.  (Przeczytany 11732 razy)

Offline lukaszsa

  • Użytkownik

# 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.:)
« Ostatnia zmiana: Czerwiec 28, 2015, 11:00:07 wysłana przez lukaszsa »

Offline Mr. Spam

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

Offline koirat

  • Użytkownik

# 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.

Offline sramtuitam

  • Użytkownik

# 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ś.

Offline laggyluk

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

# 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ć

Offline lukaszsa

  • Użytkownik

# 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)

Offline JasonVoorhees

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

# 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 :)
« Ostatnia zmiana: Czerwiec 28, 2015, 14:05:46 wysłana przez JasonVoorhees »

Offline koirat

  • Użytkownik

# 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.

Offline JasonVoorhees

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

# 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 :)
« Ostatnia zmiana: Czerwiec 28, 2015, 14:23:06 wysłana przez JasonVoorhees »

Offline laggyluk

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

# 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.

Offline koirat

  • Użytkownik

# 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.

Offline koirat

  • Użytkownik

# 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.

Offline laggyluk

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

# Czerwiec 28, 2015, 14:38:37
jakiś taki memory dump, ciekawe

Offline koirat

  • Użytkownik

# 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).

Offline deadeye

  • Użytkownik

  • +1
# 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

Offline CheshireCat

  • Użytkownik

# 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.
« Ostatnia zmiana: Czerwiec 28, 2015, 15:35:39 wysłana przez CheshireCat »