Dodatkowe informacje, kontrargumenty i podziękowania: . . . . Zacznijmy od tego, że film to oczywiście satyra typowego użytkownika unity3d napisana żartem. Proszę nie brać tego w 100% na poważnie i nie wypisywać tysiąca kontrargumentów dlaczego nie mam racji. Zabezpieczając się przed najczęstszymi lub najciekawszymi, odpowiadam na kilka poniżej: "Pracując w silnikach oszczędza się czas, bo wszystko jest już gotowe": Teoretycznie tak, ale zanim użyjemy gotowych funkcji najpierw trzeba poznać jak działają i nauczyć się sposobu ich używania. Po za tym takie sklejanie kodu i funkcjonalności z różnych źródeł często utrudnia integracje z innymi elementami i sprawia, że na koniec i tak dużo rzeczy trzeba zrobić od nowa. Np. stawiasz drzewa w unity, chcesz dodać niszczenie siekierą i okazuje się, że musisz je postawić od nowa tym razem ze skryptem. Potem chcesz dodać, że się losowo respią i znowu musisz wszystkie zniszczyć itd itp.. "Jak ktoś nie potrafi dobrze danego języka to się w tym wszystkim zakopie": Zwróciłem w filmie uwagę, że pisanie własnego silnika lub gry "from scratch" tworzy duży codebase. Takie programowanie NARZUCA naukę niektórych wzorców i patternów, dzięki którym nasz kod nie zamieni się w spaghetti. Sam robiłem dużo projektów w Unity (nawet moja gra mobilna jest w 100% na tym silniku). Po jakimś czasie wszystko było nie do rozczytania. Oczywiście można winić mój okropny kod i umiejętności, ale moim zdaniem to format skryptów sprawia, że piszemy w bardzo specyficzny sposób. Przez to każdy obiekt ma po parę skryptów, które często zawierają jedną funkcjonalność nieumożliwiając użycie jej w innych miejscach. Robi się kompletny syf (z doświadczenia wielu osób to mówie jak coś). Tworząc rzeczy samemu, jesteśmy odpowiedzialni za strukturę projektu. Jeśli wiemy, że coś będzie użyte wiele razy to piszemy to tak, żeby można to było zrobić. Wszystko da się dobrze zrobić w Unity, ale 99% użytkowników nie ma takich umiejętności. "Jakakolwiek uwaga do kodu z odcinka": Kod w devlogach ( a szczególnie wstawki gdzie kopiuję kod i troche zmieniam ) jest często specjalnie robiony w celach humorystycznych i nie występuje w codebasie gry "Odrzucił pythona bo jest za trudny": Odrzuciłem C bo jest za trudne i reszte języków bo tworzą spaghetti i łatwo się w nich zakopać btw mam pomysł, żeby na uwagi @DevKacper odpowiedzieć w youtube shortcie, ale jeszcze nwm czy się zgodzi W ramach sprawdzenia się w umiejętnościach programowania każdemu polecam napisanie własnego symulatora cząsteczek (particle system), bo to proste i przyjemne zadanie na około godzinę czasu. Możesz dodać dowolną funkcjonalność i napisać to w dowolnym języku lub stylu. W ten sposób okaże się czy jesteś prawdziwym programistą XD Z góry chciałbym podziękować @Szyromix, za wskazanie paru rad dotyczących pomysłu na film. Również @bebekorginal, od którego ukradłem format historii i ściągnąłem styl montowania (lekka inspiracja) [Proszę nagraj coś nowego, bo świetnie się ogląda twoje najnowsze filmy].Oraz @DevKacper za feedback na temat devlogów i kontrargumenty
W filmie wspominam, że jak ktoś wie co robi to pozytywnie skorzysta z zalet silnika. Niestety przeciętny użytkownik nie ma wystarczającej wiedzy żeby nie robić głupich rzeczy. Wszystko trzeba brać oczywiście z dystansem bo film to satyra
Ja tam lubię powtarzać to co zobaczę w poradnikach na YT, książkach na temat Unity, blendera czy c# i jakoś nie jest mi z tym źle, wręcz przeciwnie, powtarzanie takiej "ubitej ścieżki", krok po kroku sprawia mi sporo frajdy. Traktuje to jako fajną zabawę, nie szukam wyzwania, nie próbuję nawet stworzyć gry. Można powiedzieć, że przerabiam te poradniki i książki dla samej przyjemności z przerabiania materiału. Dla samej ciekawości i przyjemności nauki nowego narzędzia. Dla mnie to wystarczy. Więc jeśli ktoś lubię sobie robić gry z poradników na yt, tworzyć "kod spagetti" itd, to niech sobie robi, skoro sprawia mu to przyjemność. Nie wiem po co ludzi do takiego czegoś zniechęcać. Dla niektórych ważna jest droga nie cel.
@@BiznesBear jak któś wie jak i ma 200 ludzi to myśle żę unreal naj.epszy z powody grafiki ale trzeba mieć komputer z nasa choć ostatnio małe studia sie przenoszą na godota pewnie z powodu gdscript
Jako game dev pracujący z Unity codziennie, powiem, że radzenie początkującemu programiście, by nie używał silników i gotowców, tylko pisał wszystko sam od 0, to najgorsza rada jaką słyszałem ever :D
@@Wigtor Pełna odpowiedź wymagałaby odniesienia się do każdego argumentu z filmu i wypowiedź byłby tak długa, że pewnie nikt by jej nie przeczytał. W wielkim skrócie, jeśli chcesz robić gry, to chcesz się skupić na robieniu tej gry, nie na tworzeniu silnika. Jeśli ktoś nie rozumie co się dzieje w tutorialu do Unity, czy pisze kod spaghetti w prostych skryptach, to polegnie na tematach wymagających zaawansowanej wiedzy jak fizyka, rendering, system kolizji, optymalizacja performance'u itp. Pomijam już masę sytuacji, że jak ktoś np. stwierdzi, że jego gra na PC, bardziej się nadaje na telefony, musiałby zmienić wszystko w swoim napisanym na PC silniku. W Unity masz to out of the box. Jeśli chcesz poćwiczyć programowanie i pobawić się w pisanie fizyki, super ćwiczenie. Jeśli chcesz pisać grę, ucz się z tutoriali i dowolnego gotowego silnika i rób grę. Jeśli nie potrafisz zrobić gry w gotowym silniku, szansa, że ją zrobisz lepiej, pisząc wszystko od 0, jest minimalna.
Podzielam to zdanie. Również pracuję w Unity i gdybym miał zaczynać od totalnego zera bez silnika to spędził bym parę lat na tworzeniu skryptów które nikomu nie są potrzebne. Większość branży siedzi na Unity lub Unrealu, więc jeśli ktoś na poważnie myśli o zdobyciu umiejętności potrzebnych do pracy przy grach, to powinien zapoznać się z którymś z tych dwóch silników. Nawet jeżeli jakaś firma ma własny silnik to odpowiadają za niego osobni programiści, którzy nie robią gier i jest to osobno specjalizacja. Pisanie silnika od zera gdy chcemy robić gry to sztuka dla sztuki i jako taka powinna być traktowana. Jako samorozwój gdy już mamy trochę doświadczenia i chcemy dowiedzieć się jak dokładnie działają pewne rzeczy, których cała branża używa na codzień.
Nie pytaj typa, bo gada do Ciebie głupoty. Taka prawda, żeby olać to Unity jak najszybciej. Przez to, że nowy Prezes jest Agentem Electronic Arts, a to są terroryści na kasę.@@Wigtor Oni Ci przedstawiają tylko dwie alternatywy, bo tak mają sprane łby, mądrzy w gębie. Unity nigdy nie używaj, szkoda nerwów na instalacje powtórne, zawieszanie się etc. Jak nie chcesz używać Unreal, to możesz CRYENGINE : ). Oni tak używają jakby byli wydawcami o zasięgu Wojewódzkim, a nawet o takim zasięgu nie są. Słuchaj się obszczymajtków to daleko nie zajedziesz.
prosta odpowiedź. NIE KORZYSTAJ Z NARZĘDZI RÓB SWOJE XDDDD. Przecież to jest dosłownie absurd nad absurdy. Dlaczego np. rolnik miałby korzystać z ciągnika skoro może zaprząść kobyłę i płóg i orać. ALbo lepiej nie weźmie płóg w łapy i sam to tara @@Wigtor
Ja zazwyczaj jak robię coś w Unity to najpierw myślę na jakiej zasadzie to ma działać, jak mi się nie udaję po wielu godzinach to szukam w dokumentacji. A na YT szukam filmów jak dana rzecz działa konkretnie i w jakim celu.
Pomimo że to satyra to szczerze narracja tego filmu jest trochę błędna. Skupiasz się na użytkowniku unity, a niekoniecznie samym silniku, o którym wspomniałeś parę razy, tylko to co podałeś za minus, można całkiem łatwo uzasadnić, np. 0:29 Silnik nie zawiera na start wszystkiego, tylko masz pakiety które możesz pobrać do projektu, ale nie musisz. Jedyne co unity wczytuje w nowym projekcie to to co jest wymagane do tego, by działała fizyka itp. a do bardziej skomplikowanych rzeczy trzeba użyć package manager'a. A jeszcze odnośnie 3:50 bo zahaczasz o bardzo podobny temat, polecając biblioteki. Tyle że jak narzekałeś na unity mówiłeś o tym że uczysz się konkretnego silnika. A używając biblioteki co robisz, wiesz jak działa ta biblioteka od środka czy tak samo uczysz się jak działa ta konkretna biblioteka a nie wszystkie inne. Jak narzekałeś na osoby oglądające poradniki, czy używając nowej biblioteki nie używasz google'a by dowiedzieć się czegoś czego o niej nie wiesz, czyli to na co narzekasz w przypadku unity? 4:10 tworzenie silniku jest trudniejsze zwłaszcza jeżeli chcesz uzyskać taki sam rezultat jak osoba z silnikiem, dosłownie mamy czasy w których osoba używająca UE5 jest w stanie zrobić w pół godziny grę, w której zrobienie czegoś podobnego zajęłoby naprawdę ogrom czasu tworząc własny silnik. Jako przykład mogę dodać to, że polecałeś napisanie własnego particle systemu, tylko ten sam czas możesz poświęcić na uczenie się vfx graph'a w unity i uzyskać znacznie lepszy efekt. W tym samym czasie. Odnośnie plusów i minusów pisania własnego silnika polecam film code monkey "Why I'm glad I didn't use Unity" - Code Monkey Reacts. W całkiem dobry sposób to podsumowuje, oglądając film gościa który ma całkiem podobną opinie do ciebie. A i odnośnie momentu 4:18 i 3:46. Czy ty odpaliłeś unity i zacząłeś z niego korzystać przez więcej niż 5 godzin, czy po prostu mówisz bzdety. Bo obu tych rzeczy możesz nauczyć się korzystając z unity lub unreal'a.
Spokojnie bracie, po co te nerwy. Oczywiście, że skupiam się na użytkowniku, a nie na silniku, bo taki był zamysł filmu i ma wzbudzić w oglądających pewne refleksje. Silnik zawiera za bardzo dużo bloatu na start. Po co mi fizyka 3D, renderer 3D, grafika 3D, dźwięk 3D w grze 2D? Dlaczego mam wbudowaną obsługę reklam na telefon, czy sterowanie dotykiem skoro go nie potrzebuję? Biblioteki działają troszeczkę inaczej niż całe silniki. Przykładowo SDL ( z którego aktualnie korzystam na kanale) zawiera funkcję do tworzenia okna, funkcję do rysowania i funkcję do handlowania inputem. Nie uczysz się jak działa biblioteka od środka, czy jak jej powinno się używać. Gdy musisz stworzyć okno poprostu używasz istniejącej funkcji. Jest to taki skrót, żebyś nie musiał pisać wszystkiego od zera. Możesz ją zastosować w dowolnej strukturze, czy języku. Potrafiąc SDL'a pisałem gry w SFML'u Pygami'e i wielu innych bibliotekach np. citro2d na nintendo ds czy glib2d na Playstation Portable. Daj mi kogoś, kto ma dużo doświadczenia z unity i zerowe w unrealu i zobaczymy czy sobie poradzi. Odnośnie końcowych momentu 4:18 i 3:46 to pracowałem w unity. Dużo i często. Wydałem grę na androida, która zarabia jakieś grosze do tej pory. I mam nadzieję, że nigdy do tego nie wrócę. PS: Właściwie to "Why im'a glad i didn't use unity" to była lekka inspiracja do zrobienia tego filmu. Dodatkowo moja opinia niestety podparta jest moimi doświadczeniami, czyli tysiącami godzin spędzonych na programowaniu i tworzeniu własnych narzędzi. Jest duża szansa, że gdybym tego nie robił, to uważał bym inaczej. Możliwe, że tak samo jak ty. PS2: Właściwie to napisanie particle systemu to 0.5-1godzina czasu tylko,ze ten czas możesz również wykorzystać na naukę hiszpańskiego, czy nowego języka programowania do pracy. Dziwny argument masz, bo czas zawsze można lepiej wykorzystać, a moim zdaniem takie wyzwanie jak to jest bardzo przyjemnym sposobem, dzięki któremu sprawdzisz się poza strefą komfortu i wiele się nauczysz. Pozdrawiam
@@Wigtor Nie no jestem spokojny, po prostu czułem potrzebę napisania tego bo sam film wygląda mi bardziej nie na samą satyrę, a po prostu podawanie argumentów przeciw silnikom, które mają zostać udowodnione przez historyjkę. I z pierwszym kontrargumentem się nie zgadzam, jeżeli wybierzesz w unity że chcesz stworzyć grę 2D, to raczej wybierzesz albo 2D core, albo 2D (URP) które (właśnie to sprawdziłem) na start mają tylko rzeczy związane z 2D, dosłownie polecam sprawdzić samemu jeżeli masz pobrane unity. Tak samo jest z reklamami i sterowaniem dotykowym. Overall, masz racje odnośnie robienia gier na starsze platformy jak psp czy właśnie ds. I tak sam do końca nie korzystałem nigdy z bibliotek, przez co moja wiedza o nich nie jest jakaś duża. Tylko czy to naprawdę jest takie ważne jeżeli takie unity już na sam start, pozwala ci portować może nie na psp, ale np. na xboxa, playstation czy switcha. Więc jeżeli nie obchodzi cię robienie gier na 15 letnie konsole to raczej nie widzę zbyt wiele minusów korzystania z unity. A odnośnie przenoszenia się z unity na unreala, oczywiście nie będzie to tak że osoba która znała unity od podszewki od razu zacznie robić nie wiadomo co. Ale i tak proces uczenia się unreala przejdzie znacznie szybciej, niż gdyby nie używać żadnego silnika. Bo dużo narzędzi i tak będzie w jakiś sposób podobna, a odnośnie pisania kodu to unreal ma blueprinty które podobno są serio świetne i bardzo intuicyjne. Więc basically wystarczy ci wynieść po prostu odpowiedni mindset do pisania kodu. Jakby spoko tobie unity nie przypadło, ale mówienie, że robienie własnego silnika jest znacznie lepsze do robienia gier, niż użycie do tego silnika brzmi po prostu jak niedopowiedzenie. Bo niby spoko wiesz więcej na temat tego jak działa twoja gra, ale co z tego jeżeli druga osoba osiągnęła lepszy rezultat w krótszym czasie. Gdzie jedyne w czym twoja gra wygrywa to performance(ale to tylko wtedy jak wiesz jak nie robić spaghetti). Nie chcę powiedzieć że pisanie silnika i robienie gry na raz to coś znowu bardzo złego, ale mam wrażenie że od tego znacznie więcej osób się odbije. Zwłaszcza że nawet jeżeli chcesz robić gry i z tego wyżyć, to używanie silnika jest znacznie mądrzejsze. Bo i tak większość studiów korzysta albo z unity/unreal, niby dalej masz studia z autorskimi silnikami jak frostbite czy cryengine. Ale i tak ostatnio coraz częściej słyszy się o tym że duże studia przechodzą na unreala, np. cd projekt red lub bandai namco. Odnośnie pisania particle systemu, przepraszam że nie sprecyzowałem, ale VFX graph to particle system w unity, który jest bardziej wydajną wersją unity particle system. Przez co uważałem że argument jest całkiem trafnym porównaniem. Końcowo mogę powiedzieć, że prawdopodobnie kiedyś dzięki tobie też wyjdę poza banieczkę unity i spróbuje zrobić grę(lub jakiś program) nie korzystając z unity, ucząc się przy okazji c++ lub pythona. Z samej ciekawości odnośnie bibliotek i co można z nimi zrobić. PS. Jeżeli walnąłem jakąś gafę jak z bibliotekami chcę przeprosić z góry i byłym wdzięczny za wskazanie mi błędu. Więc no, Miłego dnia
@@Wigtor Widzisz to co napisałem wyżej, zapomnij o tym pisanie własnego silnika jednak jest znacznie lepszą opcją, niż używanie unity(ale zawsze można użyć godota).
Moim zdaniem to nie zależy od tego czego używasz tylko jak tego używasz. Tak samo jak moge wpisać w yt "Jak zrobić strzelanke w unity" i kopiować to co twórca filmu miał na myśli tak samo np moge wyszukać "Jak zeobić prostą baze danych w pythonie" Gdy natomiast wyszukujesz rzeczy typu "Jak działa rigitbody w unity" albo "jak wczytać obrazki w pygame" to uczysz sie jak myśleć samodzielnie. Chat GPT też nie zaszkodzi jeżeli pytasz sie go o drobne rzeczy a nie przepisujesz kod 1 do 1
Ale weź też to pod uwagę, że z tutoriala "jak stworzyć prostą strzelankę" możesz wyciągnąć wnioski, nauczyć się to co zrobiłem no i oczywiście zrozumieć jak działa taki cały system i na podstawie tego możesz myśleć o zrobieniu czegoś podobnego, ale jednak posiadając już przydatnś wiedzę
Umiejętności programowania to tylko mały element rzeczy potrzebnych do robienia gier. To jest rzecz, która się przydaje czy używasz jakiegoś silnika czy nie. Nie pisz własnego silnika, bo wymyślasz koło na nowo. Czemu nie wykorzystać swojego czasu do zrobienia czegoś, co będzie chociaż trochę nowe? Silników jest cała masa, i nie wszystkie są tak wypasione jak Unity czy UE5 ;) Część jest mała i lekka w sam raz pod małą lekką grę indie. W robieniu gier największym wyzwaniem są assety. Na gotowcach nie zrobisz nic sensownego, no chyba, że wymyślisz coś takiego jak Tetris, gdzie nie musisz mieć grafik, bo wszystko sobie narysujesz z prostokątów. Jeśli chodzi o gry, fajną zabawą jest zrobienie czegoś co praktycznie nie wymaga assetów, albo mogą być umowne. Zrobiłem kiedyś pac-mana, sudoku. Można te stare klasyki rozbudować o nową mechanikę i już jest coś ciekawego. Proste logiczne gierki są nawet grywalne i nie muszą mieć specjalnie grafiki. Wystarczy sobie ogarnąć temat gier retro, z 8-bitowców. Kopalnia pomysłów. Pixle jak woły i nagle okazuje się, że grafikę sobie sam narysujesz i to szybko. A silnik to tylko narzędzie. Nawet kod to tylko narzędzie.
Już abstrachując od faktu, że film to satyra i nie powinno się go brać na poważnie, to ciekawe spostrzezenie. To znaczy ja od zawsze widzialem gamedev od drugiej strony medalu - programowania. Nie mialem i prawdopodobnie nie bede mial nic wspolnego z grafiką czy innymi assetami. Przez to automatycznie będę przekazywał swoją opinię opartą na tych właśnie doświadczeniach. Zastanawiam się czym następnym razem (podczas tworzenia filmu o takiej tematyce) nie wziąć jakiejś artystycznej duszy do wypowiedzenia się. Co o tym sądzisz?
@@Wigtor Jeśli chodzi o gamedev, masa artystów potrzebna do czegokolwiek innego niż retro. Artysta od modeli 3D, czasem ogarniają też tekstury, artysta od grafik 2D (UI, uzupełniająca grafika), jedna z bardziej poszukiwanych umiejętności to tworzenie map. Level design to zwykle najdroższa rzecz w grach. Najwięcej godzin na to idzie. Ludzie zaczynają przygodę z tym z reguły na scenie modderskiej, robiąc nowe mapy i misje do znanych tytułów. Prawdę mówiąc nie widziałem jeszcze dobrego wywiadu z level designerem. No może poza panem Romero, ale to stare czasy. Miałem też problemy z dźwiękami do mojego Sudoku ;) Ciężko dobrać z darmowych gotowców coś co nie wkurza i jakoś pasuje do reszty. Z muzyką poszedłem na łatwiznę - darmowe chip-tune-ki z keygenów ;) Nie wszędzie pasują. Co do kodowania, na tym najczęściej pojawiają się opóźnienia, ścinki i glitche. Zdecydowanie to nie jest temat dla początkujących, jasne, nawet ja robiłem proste gierki, ale proste. W czymś większym to już trzeba mieć te lata praktyki i kilka zatłuczonych klawiatur ;)
Już widzę jak ktoś kto nie umie programować, zacznie naukę od tworzenia gry bez jakiegoś silnika typu Unity / Unreal. Ktoś kto nie potrafi programować tym bardziej będzie kopiował bez myślnie kod z różnych poradników do stworzenia takiego silnika - i tam tym bardziej sie zagubi, a nie znając wzorców projektowych kod bedzie jeszcze większym spagetti. Przy unity czy unreal początkujący, małym nakładem pracy będzie widział zadawalające go efekty i progres, że coś w jego grze się dzieje: coś sie renderuje, może poruszać postacią itp. Gdzie przy tworzeniu czegoś takiego od podstaw pierwsze widoczne efekty będą widoczne po dużo wiekszym nakłądzie pracy i czasu - a efekty mogą nei być na tyle zadowalające i taka początkująca osoba może się zniechęcić. Unity to narzędzie pozwalające na łatwy start dla osób zielonych, ale również potężne narzędzie dla zaawansowanych twórców. Mimo twoich argumentów i tak polecam Unity czy inne tego typu narzędzie dla osób którzy chcą zacząć naukę programowania na przykładzie stworzenia swojej pierwszej gry.
Nikt nie oczekuje od początkującego że będzie wiedział wszystko, a nawet kopiując kod i próbując naprawić błędy które powstały przy kopiowaniu, czegoś się uczysz, poznając coraz więcej i więcej silnika i tego jak się pisze i jak się powinno pisać skrypty.
Widać ze nigdy nie miałeś styczności z programowaniem w Unity oraz z poważnym gamedevem. Jestem deweloperem kilkunastu gier na steamie oraz aktualnie pracuję przy projekcie AAA wlasnie w Unity. Wprowadzasz ludzi w błąd, 90% filmu jest nie prawdą, nie wiem skąd masz takie informacje xd
@@nopepsi206 Liczyłem, że serio podasz jakieś argumenty, bo może kiedyś powstanie poprawkowe videło, ale się przeliczyłem. Też mogę powiedzieć, że pracuje w branży 7 lat, tylko że ja mam dowody, a nie rzucam argumentum ad personam gdzie popadnie. Miłego
To, co krytykujesz tutaj, to użytkownicy, którzy próbują zrobić grę po raz pierwszy i nie mają zielonego pojęcia, jak się do tego zabrać, dlatego sięgają po poradniki zamiast eksplorować Unity samodzielnie. Straszna otoczka miniatury i tytułu sugerująca, że Unity jest złe, choć w filmie nie o to chodzi. Straszny clickbait - nie wiem, czy to konieczne. Z drugiej strony, jak można nauczyć się tworzyć gry w Unity, nie próbując tego praktycznie? Ktoś, kto nie zna podstawowych zmiennych, a chce tworzyć gry, nie zrobi tego bez oglądania poradników. Nauka języka, na przykład angielskiego, wymaga zapoznawania się i wkuwania znaczeń poszczególnych słówek. To samo tyczy się programowania - trzeba działać, działać i działać, aż w końcu nie trzeba będzie sięgać po poradniki, bo samemu się będzie wiedziało, co zrobić. Dlatego uważam, że film jest trochę mylny. Ten, kto chce osiągnąć wyższy poziom programowania, to zrobi, a kto będzie tylko kopiować kody, nie osiągnie niczego. W tym tkwi nauka. To moje zastrzeżenia dotyczące treści filmu, ale cały format, poczucie humoru i sposób wykonania są bardzo dobre. Życzę Ci sukcesów!
Eee, trochę niesprawiedliwa diagnoza. Duża część problemu, który opisujesz nie leży w silniku, tylko w sposobie uczenia się. Życiowa prawda brzmi - każdy Piotr był kiedyś Brajankiem. Nauka KAŻDEGO języka zaczyna się od oglądania poradników i kopiowania kodu. Nie ma nic złego w zaczynaniu od Unity, Clickteam Fusion czy nawet Scratcha, bo dają podstawowe pojęcie o tym, czym jest programowanie i pozwalają na skupieniu się na innych ważnych częściach tworzenia gry. Tworzenie własnego silnika ma sens tylko kiedy masz już dobre pojęcie o tym jak wygląda proces tworzenia gry.
Ale bzdura w 4:09 ,no to powodzenia od 0 pisać grafikę, fizykę pod 3d i może obsługę VR, samemu bez bug'ów. Do tego trzeba mieć już jakieś dobre podstawy algebry i fizyki.
tylko nie używaj gotowych bibliotek, napisz je sam - według tego co doradziłeś w filmie na temat silników gier. Zadasz pewnie sobie pytanie - dlaczego mam je pisać od nowa skoro już ktoś to zrobił? No i własnie to samo pytnaie powinieneś sobie zadać w postaci - po co istnieją gotowe rozwiązania typu Unity, UE, Godot, GameMaker etc. Film z tyloma bzdurami że to hit@@Wigtor
Ja używam unity ale większość skryptów pisze sam a jak potrzebuje pomocy to nie kopiuje lub bezmyślnie przepisuje tylko patrzę na czym polega ten skrypt
"Tak naprawdę podczas tworzenia w Unity nie uczysz się robić gier, uczysz się obsługiwać program Unity3D" Masz rację nie robi się w tym gier tylko programy szpiegowskie :O.
Już chciałem dać łapkę w dół ale pojawiłem się w filmie 4:39 więc zostawiam w górę :D A tak serio to możliwe, że niedługo nagram film z tym, że z argumentami w drugą stronę tak już na poważnie xD
Chcesz stworzyć grę - nie używaj gotowych silników - napisz swój. Chcesz edytować grafikę - nie korzystaj z Photoshopa - napisz swój program graficzny. Głupszej logiki nie słyszałem.
na najnowszym filmie trochę to sprostowałem. Nie chodzi o to, żeby każdy pisał własny rendering 3d itp, ale jeśli ktoś potrafi programować i chce zrobić platformówke 2D, to silnik to trochę overkill. Change my mind
Nie jest przesadą. Dostajesz gotowe narzędzie i skupiasz się na tworzeniu gry a nie na tworzeniu narzędzia. To tak jakbyś chaciał stworzyć prostą grafikę i używał do tego Photoshopa albo Gimpa - też mógłbyś powiedzieć, że te programy są zbyt rozbudowane do prostej grafiki - ale nie musisz korzystać ze wszystkich ich funkcji - używasz tylko tych kótrych potrzebujesz. Tak samo jest z silnikami do gier. Nawet do prostych gier używa się silników nawet tych poteżnych bo to po prostu oszczędza czas i pozwala skupić się na samej grze.
>twierdzenie żeby ktoś z zerowym doświadczeniem w programowaniu rzucał się na głęboką wodę, i pisał grę bez silnika xd imo korzystanie z poradników i kopiuj-wklej kod na początku jest jak najbardziej ok - trochę gorzej jak mija jakiś czas, i ktoś się nie uczy języka ani api unity, tylko wszystko z poradników dlatego też imo najlepiej rozpocząć korzystanie z unity dopiero jak się już chociaż trochę zna c#
@@Wigtor też bym tak nie robił, ale w filmie nie było widać jakoby piotr znał już język programowania, tylko od razu poszedł w gamedev bez żadnego silnika
Chyba mylisz tworzenie gry z nauka programowania. Unity nie jest do nauki programowania tylko do tworzenia gier. Tworzenie gry na wlasnym silniku to glupota i pomimo, ze wole Unreal Engine to Unity jest rowniez bardzo dobrym narzedziem. Kazdy na poczatku przygody z programowaniem pisze spaghetti code i Unity nie z tym nic wspolnego. Niby ten filmik to miala byc satyra, ale chyba autor nie do konca zna znaczenie tego slowa.
Nie zgadzam się / ewentualnie to zależy. Film celuje w osoby tworzące gry 2D, bo 90% SKOŃCZONYCH projektów w godocie/unity to takowe. Silnik w takim wypadku to czysty overkill i wystarczy spojrzeć na ilosc fpsów - wiele gier korzystających z unity, które pobrałem wyciągały max 120 podczas gdy podobne gry napisane from scratch przebijają barierę 1000 klatek. Po drugie tworzenie gier według Ciebie może różnić się od tego jak postrzegają to inne osoby. Jeżeli uważasz, że to biegłe operowanie w edytorze jakiegoś silnika, level design, tworzenie assetów i marketing, to moim zdaniem brakuje Ci ważnego elementu - Rozwiązywania problemów. Tego nie da się nauczyć sklejając fragmenty istniejących rozwiązań znalezionych na forum unity, czy pobierając gotowy plugin. Tworząc grę samemu ponad 50% czasu będzie poświęcone na tworzeniu nowych mechanik, czy naprawianiu błędów. Bez skilli w programowaniu i problemsolvingu dokończenie projektu jest nie możliwe. Dlatego wiele twórców szufladkuje się w gotowe rozwiązania i dlatego dużo gier to kopie istniejących z innymi assetami. Takie jest moje zdanie, ale wynika z moich doświadczeń i z tysięcy godzin spędzonych na programowaniu oraz tworzeniu własnych narzędzi. Każde rozwiązanie jest odpowiednie dla innej grupy docelowej i mój film celuje w takich matematycznych świrów. Pozdrawiam
@@WigtorJak nie lubię współczesnych gier które same się przechodzą to też uważam że pisząc od zera dużo więcej się nauczy i o wiele bardziej potem się to przyda, tak jak mówisz większość gier 2D tworzonych w gotowym już silniku to gry tworzone bez żadnego pomysłu czy idei. ruclips.net/video/SaVX38SLKHk/видео.html ten materiał ma sześć lat, ale niewiele się zmieniło w tej kwestii zgadzam się praktycznie ze wszystkim co w nim powiedział.
Po miesiacu uzywania unity zaczalem nauke c++ i vulkana. Po roku mam swoja wlasna biblioteke do renderowania 2d i teraz tworze silnik 3d z interfejsem graficzym. Co prawda moj kod jest niskiej jakosci, a sporo rzeczy wymaga dopracowania, ale wciaz sie ucze. To byla jedna z lepszych decyzji w moim zyciu
@@Wigtor Akurat temat macierzy jest dla mnie niezbyt zrozumialy. Rozumiem jakies podstawowe pojecie Model Projection View, ale poki co nie zaglebiam sie w ta czarna magie. Wszystkiego mozna nauczyc sie w trakcie rozwijania silnika, wiec sie nie poddawaj na czyms takim ;)
@@Wigtor tylko weź pod uwagę że jest to niesamowicie niewydajne narzedzie i sugerowanie go a jednocześnie krytykowanie unity pod względem wydajności jest trochę dziwne
No dobra, w sumie zastanawiałem się nad tym bo kompletnie nie mogę pospinać mojej gry, ba! nie mogę nawet zacząć. Mam kilka pytań: 1. Czy w takim razie, żeby lepiej odtworzyć realistyczną fizykę zachowywania się statku tak jak w np The Expanse lepszy będzie C++? (Mi się wydaje, że tak, ponieważ tak jakby daje szersze pole możliwości od C# ale czuję, że się mylę) 2. W jaki sposób zacząć myśleć nad tym projektem? Chcę zrobić symulator bitwy kosmicznej, żeby to wszystko wyglądało i działało jak w The Expanse.
Jeśli chodzi o fizykę 3D to ciężko Ci będzie to samemu napisać bez odpowiedniej wiedzy. Chyba, że masz jakieś poprzednie doświadczenia z taką pracą. W C# (czyli też w unity) jesteś w stanie zrobić dokładnie to samo co w c++ -> wniosek: Twórz w tym co bardziej lubisz / jest dla Ciebie mniej problematyczne. Jeśli nie potrafisz czegoś zrobić w unity jest spora szansa, że bez silnika/ w c++ też Ci nie wyjdzie. Pozdrawiam
pracuje przy silniku unity od 2 lat nie zajmuję się kodowaniem jednak wiedza jaką nabyłem przez te 2 lata pozwala mi naprawiać niektóre błędy w kodzie, to nie kwestia tego, że unity jest złe tylko tego, że ludzie nie starają się naprawiać błędów sami tylko chcą znaleźć gotowe rozwiązania w sieci albo porzucają projekt bo jest tak zbugowany. Jednak korzystanie z gotowych skryptów i kursów sprawiło że rozumiem kod w C# i potrafię na nim pracować, mimo że tak naprawdę zajmuje się level designem :). Podsumowując zależ jak kto podchodzi do nauki pisania :)
każdy silnik czy też język programowania ma swoje assety (biblioteki) zgadza się. Początkujący twórca będzie kopiował i wklejał to do swojego projektu i to jest błąd. Przed podjęciem tego kroku powinien zapoznać się z dokumentacją danego asseta i to ze zrozumieniem (dlaczego to tak działa a nie inaczej) żeby było wiadomo gdzie dany fragment kodu można wykorzystać, i podjąć stosowne kroki aby zapobiec ewentualnym błędom bądź usunąć taki jak wystąpi. Pozdrawiam
A może by tak użyć Unity tylko powstrzymać się od bezmyślnego kopiowania komponentów? Przecież pisząc w jakimś PyGame czy innej bibliotece, też możesz skopiować całą zawartość bez świadomości co zmienić, jak naprawić błąd - tylko takich źródeł będzie mniej. Argument dot. nauki komponentów na pamieć też jest kiepski. Większość z tego można sprowadzić do analizy matematycznej. Można używać fizyki, ale nie trzeba - wtedy albo 2d, albo 3d i tworzymy grę na komponentach fizycznych. Jeśli nie, można użyć tylko colliderów i raycastów, a jeśli nie to można z wszystkiego zrezygnować. Kopiowanie komponentów bez zrozumienia jest głupie. Ale równie bezsensowne jest pisanie swojego silnika. W komentarzach sporo osób z doświadczeniem to tutaj zauważyło. Jak chcesz się nauczyć, musisz rozwiązywać problemy - niezależnie gdzie one będą. Nie ma łatwiej drogi.
ten film (jak go gdzieś w listopadzie zobaczyłem) zainspirował mnie do zrobienia gry nie w unity tak jak zwykle robiłem i powiem że to byłą najlepsza decyzja jaką mogłem podjąć. Nie będę musiał dawać zaliczki, prosty w debugowaniu, w 2 odgarnąłem wszystkie podstawowe rzeczy, kod jest prosty i wygodny. No żyć nie umierać!
Ja w unity dopiero się uczę i uważam, że samo unity nie jest problemem, problemem jest to, że dochodzisz do momentu, w którym nie wiesz i nie umiesz nic dalej zrobić, ALE wtedy odpalasz poradnik na youtube i okazuje się, że nie działa i znowu i znowu aż w końcu znajdujesz ten dobry i gratulacje nauczyłeś się odróżniać spoko rzeczy od syfu
Masz racje, wczytywanie wszystkich komponentów nie jest potrzebne dla początkującego game maker. Ale Unity pozwala oswoić się z programowaniem. Jeśli nie kopiujesz wszystkiego bez zrozumienia kodu to jest dobra droga żeby zacząć co kolwiek programować. Ja sam zaczynałem od Unity i dzięki temu mogłem skupić się na koncepcie gry. Jeśli robisz gry pod mobile to myślę że Unity jest przystępnym silnikiem z dużymi możliwościami. Jak zaczynałem programować na początku swojej przygody to moje kody wyglądały typu hello world albo prosty kalkulator. Nie wyobrażałem sobie wtedy że mogę stworzyć jaką kolwiek gre. Unity mi w tym pomogło a nie zaszkodziło.
- Pisanie gry od podstaw jest bardzo fajne - ja po stworzeniu w ten sposób gry, zrozumiałem jak można stworzyć świat, w którym można się poruszać i wchodzić z nim w interakcje, za pomocą słów, co zmieniło moje spojrzenie na Biblię i opisany tam sposób stworzenia świata.. :) ..Jednak użycie silnika przyspiesza znacznie napisanie "fajnej" gry, a w dzisiejszych czasach, czas też czasem ma znaczenie... :)
nah, argumenty pokroju unity to gotowy silnik gier są bezużyteczne, tak samo jakby powiedzieć że python to przecież język interpretowalny więc lepiej pisać w assemblerze albo kodzie maszynowym
@@domi6125 te 3 tygodnie temu poczułem się jak frajer z tego powodu, ale po godzinie pomyślałem "mam to w dupie" i "w sumie to typ może pocałować mnie w dupę" po czym wróciłem do Godota (w którym teraz siedzę) mając wywalone na to wszystko więc nie przejmój się :)
@@Strefiks I dobrze, bo jak ktoś chce zrobić grę, to nie robi silnika gry. To tak samo jakby kierowca wyścigowy miał zrobić samochód, bo wtedy lepiej go będzie rozumiał. Inną kwestią jest pisanie dobrego kodu i w tym filmie się z nim zgodzę.
powiem tak film bardzo przyjemnie zmontowany, bardzo fajnie że wstawiłeś tutaj rodaka o nazwie "aarthificial" ( twórcę Motion Canvas ) jak i to że Piotr używał Pythona czyli jak każdy wie najlepszego języka programowania ;)
Mam dla was taką rade. Nie uczcie się z poradników/kursów to tylko strata czasu. Czytajcie dokumentacje, jak czegoś nie wiecie wpisujcie to w google ale przed tym sami spróbujcie to naprawić sami. Tak samo jest z kodem który piszecie piszcie co umiecie jak nie wiecie próbujcie zrobić to sami jak nie wychodzi to wpisuj w google z czym masz problem i masz dużo odpowiedzi na to pytanie to tyle❤❤❤
Z najgłupszych rzeczy jakie zdarzyło mi się słyszeć w życiu te "rady" są w czołówce. 1. Niepotrzebne komponenty unity - od jakiegoś (dość długiego) czasu unity umożliwia pobieranie tylko tych paczek których potrzebujesz. Silnik nie zawiera wszystkiego co ma do zaoferowania, w czasie tworzenia sam musisz się określić czego potrzebujesz i pobrać odpowiednie paczki. 2. Silnik jest zły bo jego użytkownicy często nie mają umiejętności żeby go używać - tego nie trzeba komentować chyba🤣 3. Najlepszym wyjściem żeby napisać własną grę jest napisanie najpierw własnego silnika - absolutny hicior wśród głupich rad! chcesz zakodzić sobie mała gierkę na androida? Nie ucz się unity, lepiej poświecić 3 lata na pisanie silnika i 3 miesiące na napisanie gierki🤣 widać że chyba nie zdajesz sobie sprawy jakim wyzwaniem jest napisanie czegoś sensownego jeśli chodzi o silniki do gier w rozsądnym czasie
To samo można powiedzieć o wszystkich silnikach, a one właśnie po to są aby nie trzeba było pisaćcałej fizyki od nowa a skupić się na samej grze i oczywiście że nie jest to takie uniwersalne jak byś samemu wszystko napisał, ale wtedy jaki sęs ma kożystanie z silników? Myślę że autor nie rozumie po co są silniki gry
po spróbowaniu pisania bez silników zobaczyłem większy potencjał i możliwość zmiany wszystkiego, także zgadzam się z tobą (silnik to dobry wybór na początek, ale jak chce się bardziej poznać język lepiej zacząć bez silnika)
Co Ty w ogóle mówisz? Przecież niezależnie czy piszesz gry w unity czy UE5 to i tak musisz się nauczyć wzorca projektowego. "Ciężko napisać dobry kod w unity" - to jest najdziwniejsze co kiedykolwiek usłyszałem xDDDD A to w innym silniku czy języku łatwiej jest pisać dobry kod? Ten filmik brzmi jak tania reklama Phytona.xDDDDDDDDDDDDDDDDDD Jak zaczniesz o czymś nagrywać to najpierw spojrzyj na to z innej perspektywy. Ja w unity pracuje od 5 lat. I nie jedną grę zrobiłem. Czy w wolnej chwili czy dla jakiejś osoby w formie zlecenia. I unity ma swoje wady i zalety jak każdy inny silnik. To samo tyczy się języków. Javy też nikt nie lubi. A jakoś programistów tego języka jest dużo. To samo wracając do unity. Co ma do tego uruchamianie się długie samego silnika ? Albo to, że w unity gry są budowane z tych samych assetów kupionych na asset store? Wyłożysz kasę na grafików? Na osoby, które przygotują te modele? Bo prosto jest cokolwiek napisać czy powiedzieć. Dopiero zrobić. Jest wiele fajnych gier dobrze zoptymalizowanych z fajną ładną grafiką, które osiągneły sukces. I co najlepsze jest w tym co mówisz to : "Młodzi programiści kopiują kod i tyle. Bo nie umieją programować" albo "Młodzi programiści robią system eq z tutorialem, a nie próbują sami". A co jest w tym złego, że młody programista zajrzy do poradnika i zobaczy jak ktoś coś zrobił? Na tym to polega. To jest nauka. To tak samo jakbym się przyczepił do kogoś, że nie wie jak coś zrobić i korzysta ze stackoverflowa xDDD
Ja korzystam z pygame i według mnie na lepiej korzystać z takiego rozwiązania ponieważ programując w bez silników można programować w językach lub poprostu ucząc się ich ale potem lepiej korzystać z silników.
Nikt nie mówi o tym, że edytor unity jest po prostu przepełniony - ja, gdy uruchomiłem go poraz pierwszy i ostatni, nie wiedziałem co klikać, gdzie wejść - brakuje tu prostoty. Dodatkowo, według mnie, robienie wszystkiego w edytorze wizualnym jest po prostu nudne. Większą przyjemność sprawia mi robienie wszystkiego w kodzie.
ja kiedys robilem na telefony gry i to 3d. 2 lata pisalem proste "Snake 3d revenge" i musialem toolsy, edytory spritow itp.. Nigdy wiecej. Teraz unity 3d i mam wszystko pod reka prawie. Moge dograc co brakuje :).
Problemem jest bardzo często czas, a raczej brak czasu. Zrobienie dobrej gry z pomocą jakiegoś silnika może zająć kilka lat. Bez silnika to kilka lat więcej (na zrobienie własnego silnika). Dla początkującego ten czas to kilka razy dłużej z kilkukrotnym pisaniem wszystkiego od zera, gdy okaże się że jego amatorski silnik się do niczego nie nadaje. Moim zdaniem, jeśli ktoś chce zrobić grę, a jest kompletnie początkujący i nie wie nic co i jak, to niech koniecznie najpierw zacznie z jakimś silnikiem. Niech spróbuje zrobić cokolwiek w tym silniku i niech czyta dokumentację do wszystkiego co używa żeby zrozumieć co zostało zrobione w tym silniku, jak to działa i dlaczego tak to działa. Niech najpierw nabierze trochę doświadczenia i wiedzy, a dopiero potem po drugim/trzecim małym projekcie spróbuje zrobić coś swojego (z silnikiem lub bez). I niech ta jego docelowa gra będzie mała, żeby się nie porywał od razu na robienie Baldur's Gate'a w pojedynkę bo zajmie mu to 20 lat albo się po prostu nie uda.
@@Wigtor mi pobranie abandonware'a nie winno być problemem - potwierdzeniem jest posiadanie directora mx2004 oraz directora 11.5 Problemem będzie nauka języka oraz próba wymyślenia takowej gry
Jak bym opisał to Unity nie jest aż tak zły, Unity jest po prostu nie stabilny pod innymi względami, ale jeśli chodzi to łatwo się nauczyć Unity, ale w Unity CSharp nie jest prostym ale da się zrozumieć podstawy, a długość włączania zależy od dysków pracujących (polecam do tego SSD w tych czasach), jeśli chodzi o CSharp to najlepiej się nie uczyć ogólnego C# tylko te które jest pod Unity, bo zwykłe C# jest wymagające bardziej.
Ja zawsze nie chętnie podchodziłem do unity i podobnych. Wole wszystko napisać sam, mieć wolną rękę i wiedzieć co i jak działa. Bo tak to wyskakują co chwile errory których nie kumam, a sam kod jest jak filmie spaghetti. Osobiście zaczynam duży projekt w pygamie i mimo, że niektóre rzeczy musze robić sam tak jak ten parser mapy, tak czuje o wiele większą satysfakcje gdy dana funkcjonalność działa
Fajny film, nadal będę używał unity ale spróbuje coś zrobić bez silnika, żeby zobaczyć czy w ogóle umiem programować xd. A tak swoją drogą, to inspirowałeś się może zagranicznym youtuberem Hamza? bo format filmików masz podobny do jego starych materiałów i też widać, że interesujesz się samorozwojem, tak z ciekawości się pytam. Powodzenia z kanałem na youtube!
Tak, inspirowałem się m.in hamzą i kanałem bebekoriginal. Chcialem też nauczyć się lepiej montować, a takie animacje to najlepszy sposób, żeby to zrobić. Jako ciekawostkę mogę powiedzieć, że tydzień temu mniej zaawansowane intro robiłem w tempie nawet 8 godzin na minutę, a teraz to max 2
tak wsm to racja w unity programuje parę miesięcy i jedyne co sam zrobiłem to poruszanie sie a raczej tepanie sie po ziemi(zmieniałem x, albo y w update).Najlepiej samemu nauczyć sie paru języków i wybrać
Film zakłada, że każdy wybierający silnik jest kiddosem, który z dupy sobie pomyślał, że będzie robić gry, bo lubi grać w gry, a nie napisał w życiu nawet hello worlda XDD Taki jest target tego filmu, a ktoś z expem nie będzie opierał swojej decyzji na podstawie satyryczno bekowego filmu. Czyli forma przedstawiona w filmie trafia do dzieci chcących zrobić pierwszą grę, a w tym samym czasie omawiane zagadnienie to dla nich totalna abstrakcja XD Myślałem, że będzie coś w stylu contentu jak na kanale "Dani" - bekowo albo "Randy" - trochę bardziej merytorycznie. W Polsce nie ma takiego contentu i jest to kusząca nisza, a wystarczy po prostu przedstawić gam dev w formie zrozumiałej nawet dla totalnych laików. Ten film wygląda jak flexowanie się skillem na zasadzie machania psu kiełbasą przed pyskiem, a następnie zjedzenie jej samemu, bo 99,9% odbiorców tego filmu jest lata świetlne od napisania własnego renderera.
wsm chciałbym być jak randy, ale brakuje jeszcze brakuje mi dużo umiejętności w kwesti storytellingu, montażu i wgl charyzmy. Może kiedyś stworzę coś wartego twojej uwagi
2:40 jak mówisz że gry z Unity brzydko wyglądają to sobie zobacz na: TABS, People Playground, Secret Neighbor, Clustertruck, Teardown i Universe Sandbox
2:55 tu dosłownie opisałeś dlaczego lepiej używać unity na początku, niż pisać samemu fizykę i resztę od zera. Stawiasz na równi osobę, która dopiero uczy się, z kimś, który ma obcykanego choćby pythona. Trochę od innego poziomu takie dwie osoby zaczynają. Jak dla mnie najzwyczajniej w świecie silnik powinien być dopasowany do umiejętności takiej osoby, a jeśli ktoś totalnie pisze grę w konsoli, bez silnika, to jego sprawa, jeśli chce wszystko totalnie po swojemu zrobić to luzik. Ale niestety na dłuższą metę w takim pythonie ciężko jest zrobić grę fabularną, tudzież po prostu dłuższą. I tak, to prawda, że unity niestety wczytuje za dużo bibliotek naraz, wiem, bo pracuję na codzień w unity :)
Dodam, że nie jestem początkujący, potrafię sam napisać wiele skryptów, praktycznie wszystkie, czasem na internecie sprawdzam jak zapomnę sobie jakiejś składni czy nazwy. Kod spaghetti powoli po 3 latach programowania zanika :) Coraz więcej tego środowiska znam na pamięć i w unity czuję się jak w domu, wiem gdzie co leży. Gdybym miał zacząć teraz od robienia gier tylko dzięki bibliotekom w pythonie to poczułbym się jakby mnie ktoś wyrzucił na bezludnej wyspie z siekierą i powiedział "radź sobie", gdzie nie potrafię samodzielnie dzięki bibliotekom napisać fizyki do gry, systemu kolizji, czy choćby zrobić głupiej animacji kamerą. A wybrałem unity, bo genialnie nadaje się do robienia mojego ulubionego gatunku gier Sandbox-RPG z pięknymi oświetleniami, lekko spikselizowaną grafiką i wspaniałymi animacjami :)
Czasami mam wrażenie że Unity jest jak 2 kg szwajcarski scyzoryk w którym nie ma tego co potrzebuje XD tak w ogóle czy sama firma przypadkiem nigdy nie zrobiła konkretnej gry od A do Z na własnej technologii dlatego to co oferują jest takie umowne, nie było konkretnie do niczego użyte? Pamiętam jak robiłem levele na Source czy UE to jak usiadłem do Unity myślałem że tu chyba nic dobrze nie zrobię ani nie przetestuje XD
Wiem że stary, ale mam aspiracje by coś stworzyć (książkę/grę) i przypadkiem znalazłam twój kanał. Może to sprawi że zacznę działać. A co do spaghetti to od razu na myśl przyszedł mi twórca Yandere Simulator, którego kod gry to jest spaghetti i jeśli to było nawiązanie do tej gry to trafiłeś w punkt.
Człowieku w unity istnieją pakiety, jeśli czegoś nie używasz to po prostu to usuwasz. Jeśli potrzebujesz własnych rozwiązań to możesz to napisać XD np. własną fizykę lub zaimplementować gotowe systemy fizyki. Ten film to komplety absurd. Faktycznie unity potrafi się długo ładować, tak samo jak ue, godot szybciej (nie testowałem na większych projektach). Nikomu nie polecam tworzenie własnego silnika jeśli chce stworzyć grę a nie silnik. Inna beczka, że jest to błąd dev, że projekt długo się ładuje.
taki z ktorym masz najwiecej wspolnego. Jak musisz sie jakiegos nauczyc w szkole/na studiach/do pracy to bedzie najlepszy wybor. Tbh w kazdym zrobisz 2d/proste 3d bo nawet niezoptymalizowany kod wyciagnie to 60 fpsow. Jak nie masz nic wspolnego z programowaniem, a chcesz zaczac robic gierki to zaczał bym z pythonem lub c
ja mam bardzo dobre doświadczenia z JavaScript i silnikiem ct.js, ale pół świata chwali sobie Godot, więc pewnie coś w tym jest. W nim przyda się pewnie doświadczenie z Pythona.
Stary film, ale co mi tam napiszę komentarz. :D W Unity nigdy nic nie robiłem, chociaż za jakiś czas może to się zmieni, ale zawodowo jestem programistą, typowym backendowcem w .Net. Argumenty przedstawiopne w filmie gdybym miał przełożyć na swoje życie zawodowe powinny brzmieć mniej więcej tak "Nie pisz w .Netcie, bo (i tutaj dodaj jakiś argument, nie wiem nawet jakiś stricte związany z wydajnością czy cokolwiek). No i spoko, pewnie np. w C++ dałoby się napisać coś co działałoby szybciej, wydajniej, ale przewagą C# + .Net jest szybkość pisania takiego rozwiązania i to jest powód, dlaczego... Warto używać Unity i podobnych silników. :) Fajnie dla zajawki zrobić własny silnik, ale polecanie robienie tego komuś kto nie ogarnia unity jest niezbyt trafne, bo jak ktoś bezmyślnie przerabia tutoriale Unity, to tym bardziej nie zrobi porządnego własnego silnika. Ogólnie rozumiem Twoje podejście, ja kiedyś miałem podobne (co było przyczyną tego, że na przykład kręciłem nosem na system drag and drop przy robieniu aplikacji okienkowych, bo uznawałem to za drogę na skróty (ja jebie, z perspektywy czasu ale to było głupie xD), ale teraz wiem, że narzędzia są po to, żeby z nich korzystać. Aaa i lekko się doczepię jeszcze tego argumentu, że z gotowym silnikiem w portfolio idziesz i dostajesz pracę - nooo, nie do końca niestety. Może w jakiejś firmie, która utrzymuje swój silnik do gier tak, chociaż z prostym silnikiem 2d to raczej nie byłoby i tak jakimś ogromnym plusem, ale wszystko poza tą na prawdę niewielką niszą wygląda tak, że ktoś spojrzałby na kod, powiedziałby co najwyżej, że fajne, ale i tak ostatecznie kandydat z silnikiem w portfolio a bez umiejętności bardziej specyficznych biznesowo, czy bez projektów wykorzystujących bardziej "przydatne" umiejętności zostałby odrzucony. Oczywiście programować, to szerokie pojęcie, ale jakbyś na przykład chciał przyjść na staż / juniora w backendzie ASP .Net, to taki projekt byłby fajny, ale nie wnosiłby nic szczególnego, bo oczekuje się od kandydatów szczególnie przy tak zepsutym rynku, że będą znać potrzebne frameworki wykorzystywane do pracy (np. ASP .Net + Entity Framework), do tego często się oczekuje testów jednostkowych, podstaw devopsowania. Trochę brzmi to jak odklejka z mojej strony, bo w końcu Ty o grach, a ja o backendzie biznesówek, ale myślę, że w game devie poza pojedynczymi przypadkami mogłoby to niestety podobnie wyglądać, no chyba że aplikowałbyś mając prosty silnik 3d do firmy, która taki silnik utrzymuje, lub jakbyś aplikował mając również wykazane umiejętności w jakimś Unity czy Unreal Engine. :D Tak czy siak pozdro i czekam na gierkę, jestem ciekaw co z tego finalnie wyjdzie! :)
Wiem, że film nie jest najwyższych lotów i z perspektywy czasu scenariusz wyglądał by zupełnie inaczej, ale teraz już nic nie zrobię ;/ Ale abstrachując, mam parę pytań odnośnie .net Jeśli plany mi się nie zmienią, chciałbym do października dostać pracę jako programista. Powiem szczerze, że głównym celem jest szybkie znalezienie pracy, wysokie zarobki(w przyszłości), możliwości rozwoju oraz nie pisanie frontendu. Mój ulubiony język to niestety rust, który ma znikome oferty pracy, a ulubiona dziedzina programowania to te niskopoziomowe pisanie sterowników, opengl i cały embedded engineering. Pomimo wysokiego progu wejścia i wymaganych umiejętności nie przynoszą one wysokich dochodów i nie jest łatwo znaleźć w nich dobrą pracę. Zatem uznałem, że najlepszym rozwiązaniem jest zostanie programistą .net lub java, no ogólnie backendowym w stronę aplikacji biznesowych. Pierwsze pytanie to czy uważasz, że to dobry pomysł? To znaczy czy myślę w dobrym kierunki i należy wybierać dobrze płatne sektory programowania z wieloma ofertami pracy, żeby osiągnąć te cele. Czy może jednak iść w embedded, który mnie bardziej interesuje i ma bardzo wysoki próg wejścia (co gwarantuje, że żadne ai mnie nie zastąpi), ale za to z małymi możliwościami zarobku i znalezienia pracy. I jak tak się zastanawiałem nad językiem i technologią, to uznałem, że c# jest idealnym wyborem. Po pierwsze wiele technologii z tego co rozumiem jest standardem i nie ma miejsca na wybory frameworkow itp tylko dokładnie wiesz czego musisz się nauczyć (.net). Bo w takim NodeJS istnieje wiele frameworków i tak naprawdę nigdy nie wiesz, czy ten którego się akurat uczysz da ci pracę. Dlatego czy uważasz, że c# + .net to dobra droga, czy może cofając czas wybrałbyś coś innego typu java+spring No i ogólnie czy masz jakieś tipy, porady, widzisz, że czegoś ważnego nie rozumiem o branży... Szczerze widzę to tak, że masteruje c# i .net, piszę parę ciekawych projektów z wow effectem do portfolio i dostaję z bomby juniora na poł etatu, ale może się mylę. Mam bardzo szeroką ogólną wiedzę o informatyce i programowaniu, czy algorytmach dlatego tym się nie przejmuję. Ewentualnie jeśli wszystko pójdzie w dobrą stronę, to zacznę jakąś małą seryjkę na yt zostawania etatowym programistą, więc jak zobaczysz kiedyś jakiś film z tego to błagam o protipy ;). Nie wiem czy to co napisałem brzmi sensownie, bo jest zdecydowanie za późno na takie eseje, ale z góry dziękuję.
@@Wigtor O mordko, dzięki za odpowiedź, serio miło mi i się nie spodziewałem! :D Na starcie - nie przejmuj się "poziomem filmu", ja w pełni te argumenty przyjmuję, ale przedstawiłem ich kontrę, która według mnie jest sensowna. Widać, że jesteś mega geekiem i to się ceni. :) Co do pytań: 1. Wiesz co, wydaje mi się, że o ile nie będziesz się jakoś męczył w pisaniu backendu, to jak najbardziej spoko pomysł, zawsze możesz zwyczajnie czymś bardziej niskopoziomowym zajmować się po godzinach (nawet śledzę kilka kanałów, które akurat się kochają, nawet nie stricte w programowaniu ich, a po prostu całościowo od projektowania płytek po pisanie na jakieś różnorakie układy różnych programików) i uważam, że jako zajawka super sprawa! Niestety z zarobkami jak mówisz jest troszkę lipa, z resztą podobnie jak w game devie, ja w sumie sam gdyby game dev był łatwiejszy do wejścia i bardziej przystępny jak chodzi o zarobki, to nie wiem czy nie poszedłbym w game dev po prostu, a tak jestem backendowcem, ale muszę przyznać, że bardzo to lubię i z perspektywy czasu (można powiedzieć, że 2-3 lata, zależy jak liczyć doświadczenie, ale mniej więcej tyle) zaczynam wręcz czuć zaciągi takie biznesowe :P Chociaż z drugiej strony patrząc, widać po Tobie mega pasję, więc jakbyś miał możliwość pójścia w cos niskopoziomowego, to nie wiem czy też nie warto rozważyć. Warto na pewno rozważyć obie opcje, najważniejsze, że w razie czego mając pierwsze doświadczenie w branży łatwiej trochę zmieniać kierunek w jakim idziesz, ja na początku trochę z przypadku pracowałem na php + czystym js + html i css, a to wszystko wrzucone w silnik presta shop i nie było problemu przerzucić się na backend w c#, względnie dużo ofert miałem jak na aplikowanie na juniora w innej technologii, także zawsze po tym nawet lekko ponad roku możesz zmienić ścieżkę, szczególnie w młodym wieku to dobra rzecz, bo masz czas wytestować. :D Apropo drugiego pytania - nie polecam zdecydowanie javy + springa, od razu mówię, to jest tak niezjadliwe, że to hit haha. :D Sam szukałem pracy w tej technologii, nawet byłem na kilku rozmowach, ale jak dostałem rozmowę w .Netcie z polecenia i uznałem, że dam mu szansę, bo robiłem w nim coś małego na studiach, to po analizie wyszło mi, że w sumie to czego się uczyłem w springu kilkanaście tygodni, na przyzwoitym poziomie w .Netcie zajeło mi 2 tygodnie, o wiele bardziej przejrzysty jest jak dla mnie i tak jak mówisz jest dobrze ułożony. Z tego co zasłyszałem na rozmowach ostatnio czy w rozmowach też z programistami z dużo większym doświadczeniem, to czasem stosuje się coś, co nie jest w standardzie .Neta, ale i tak generalnie zazwyczaj większość rzeczy nie ma sensu zmieniać wzgledem standardu, co w innych językach nie jest oczywiste, co daje właśnie taką biznesową uniwersalność i pole do douczenia się jakichś rzeczy do stacka technologicznego, które będą dodatkwoym atutem, zamiast uczenia się trzeciego frameworku robiącego niemalże to samo, tylko dlatego, że nowa firma nie stosuje tego, którego używałeś. :D A apropo porad - na pewno projekty o których napsisałeś i masterowanie c# + .Net to podstawa. Też zależy w co chcesz iść, bo można w .Netcie pisać różne aplikacje, ale domyślam się, że chodzi Ci o backend API, także tutaj dodatkowo oczywiście dorzuciłbym Entity Framework, bo to się baaardzo często wykorzystuje, jak ogarniasz architekturę, to mega plus dla Ciebie, ale w czystym backendzie zazwyczaj stosuje się też architekturę warstwową + CQRS, także warto sobie to przećwiczyć, jeśli nie miałbyś jeszcze okazji, bo junior z tym to będzie szał wśród pracodawców imo, serio. :D Czy cos jeszcze? Hmm... Na pewno fajnie do apliakcji tak dodatkowo dorzucić jakąś integrację z API zewnętrznym, plus może wykorzystanie czegoś od Azure / AWS (jakieś kolejki, czy jakiekolwiek inne zasoby co udostępniają), ale to tak już totalnie dodatkowo, nie jest to wymagane, ale jest to mocne nice to have, bo często się korzysta z usług azure / aws, czasem z google w biznesie. Tylko trzeba uważać, żeby nie zapłacić za te usługi w razie czego, ale tam są raczej konta z darmowymi kredytami jakbyś się chciał pobawić. :D No i imo obowiazkowo jakbyś chciał się wyróżnić to ogarnij sobie chociaż na podstawowym poziomie pisanie testów jednostkowych chociaż + integarcyjnych oraz już tak totalnei nice to have, ale co się przydaje w pracy, czego od juniorów się często nie wymaga (od midów i seniorów już na bank), ale co jest dużym plusem, to chociaż podstawy kubernetesa i dockera, nie jest to stricte związane z pisaniem kodu, a bardziej z jego wdrażaniem i utrzymywaniem, ale niestety albo stety backend poszedł w taką stronę, że ostantio dosyć czesto programiści robią też pipeline'y do wdrożenia swoich serwisów na poszczególne środowiska, a docker + kubernetes to z jednej strony podstawy tego, ale z drugiej na tyle wystarczające, że poza nimi programista praktycznie nie musi nic więcej wiedzieć szczególnie na początku. Ja sam dostałem pracę bez znajomości tego, a teraz mogę przyznać, że znam dosyć dobrze oba narzędzia właśnie przez wymóg jaki jest w pracy. :D No i jak coś to jak chcesz możemy złapać się jak chodzi o kontakt, chętnie pomogę w Twoim procesie dostania pracy, zawsze chętnie służę radą. Sam nie jestem oczywiście alfą i omegą, moje doświadczenie też nie jest jakieś super ogromne, w pracy jestem midem (takim solidnym), ale byłem w sumie na wielu rozmowach, wiem z czym się je branża + sam też ostatnio zaczynam szukać pracy w innym miejscu, także chętnie zebrane doświadczenia przekażę Ci, aby Ci pomóc, bo wiem, jak czasami przesrane jest przebicie się przez gąszcz kandydatów. Jedno jest pewne - masz ogromną przewage, bo widać po Tobie pasję do programowania, najważniejsze żeby w procesie rekrutacyjnym zachować neutralność, pokazać co ciekawego zrobiłeś + wyciągać swoje atuty, a praca powinna znaleźć się dosyć szybko, bo na juniora kandydatów jest masa, ale niestety większość z nich to są ludzie po bootcampach, albo jakichś kursach z ToDo w porfolio i nie potrafiący wytłumaczyć czym jest klasa abstrakcyjna czy interfejs i jakie plusy daje. :D Jak chcesz daj jakiś kontakt do siebie, odezwę się i mogę śmiało w wolnym czasie podpowiadać co nieco, aby podzielić się swoim doświadczeniem w szukaniu pierwszej pracy jak i doświadczeniem stricte z już 2 lat przepracowanych w .Net, a 3 w IT, tak abyś mógł jak najgładziej wejść w branżę. :)
Dodatkowe informacje, kontrargumenty i podziękowania:
.
.
.
.
Zacznijmy od tego, że film to oczywiście satyra typowego użytkownika unity3d napisana żartem. Proszę nie brać tego w 100% na poważnie i nie wypisywać tysiąca kontrargumentów dlaczego nie mam racji. Zabezpieczając się przed najczęstszymi lub najciekawszymi, odpowiadam na kilka poniżej:
"Pracując w silnikach oszczędza się czas, bo wszystko jest już gotowe":
Teoretycznie tak, ale zanim użyjemy gotowych funkcji najpierw trzeba poznać jak działają i nauczyć się sposobu ich używania. Po za tym takie sklejanie kodu i funkcjonalności z różnych źródeł często utrudnia integracje z innymi elementami i sprawia, że na koniec i tak dużo rzeczy trzeba zrobić od nowa. Np. stawiasz drzewa w unity, chcesz dodać niszczenie siekierą i okazuje się, że musisz je postawić od nowa tym razem ze skryptem. Potem chcesz dodać, że się losowo respią i znowu musisz wszystkie zniszczyć itd itp..
"Jak ktoś nie potrafi dobrze danego języka to się w tym wszystkim zakopie":
Zwróciłem w filmie uwagę, że pisanie własnego silnika lub gry "from scratch" tworzy duży codebase. Takie programowanie NARZUCA naukę niektórych wzorców i patternów, dzięki którym nasz kod nie zamieni się w spaghetti. Sam robiłem dużo projektów w Unity (nawet moja gra mobilna jest w 100% na tym silniku). Po jakimś czasie wszystko było nie do rozczytania. Oczywiście można winić mój okropny kod i umiejętności, ale moim zdaniem to format skryptów sprawia, że piszemy w bardzo specyficzny sposób. Przez to każdy obiekt ma po parę skryptów, które często zawierają jedną funkcjonalność nieumożliwiając użycie jej w innych miejscach. Robi się kompletny syf (z doświadczenia wielu osób to mówie jak coś). Tworząc rzeczy samemu, jesteśmy odpowiedzialni za strukturę projektu. Jeśli wiemy, że coś będzie użyte wiele razy to piszemy to tak, żeby można to było zrobić. Wszystko da się dobrze zrobić w Unity, ale 99% użytkowników nie ma takich umiejętności.
"Jakakolwiek uwaga do kodu z odcinka":
Kod w devlogach ( a szczególnie wstawki gdzie kopiuję kod i troche zmieniam ) jest często specjalnie robiony w celach humorystycznych i nie występuje w codebasie gry
"Odrzucił pythona bo jest za trudny":
Odrzuciłem C bo jest za trudne i reszte języków bo tworzą spaghetti i łatwo się w nich zakopać
btw mam pomysł, żeby na uwagi @DevKacper odpowiedzieć w youtube shortcie, ale jeszcze nwm czy się zgodzi
W ramach sprawdzenia się w umiejętnościach programowania każdemu polecam napisanie własnego symulatora cząsteczek (particle system), bo to proste i przyjemne zadanie na około godzinę czasu. Możesz dodać dowolną funkcjonalność i napisać to w dowolnym języku lub stylu. W ten sposób okaże się czy jesteś prawdziwym programistą XD
Z góry chciałbym podziękować @Szyromix, za wskazanie paru rad dotyczących pomysłu na film. Również @bebekorginal, od którego ukradłem format historii i ściągnąłem styl montowania (lekka inspiracja) [Proszę nagraj coś nowego, bo świetnie się ogląda twoje najnowsze filmy].Oraz @DevKacper za feedback na temat devlogów i kontrargumenty
Takich silników jak np. Unity, u real używają często studio (mniejsze czy większe)
W filmie wspominam, że jak ktoś wie co robi to pozytywnie skorzysta z zalet silnika. Niestety przeciętny użytkownik nie ma wystarczającej wiedzy żeby nie robić głupich rzeczy. Wszystko trzeba brać oczywiście z dystansem bo film to satyra
Ja tam lubię powtarzać to co zobaczę w poradnikach na YT, książkach na temat Unity, blendera czy c# i jakoś nie jest mi z tym źle, wręcz przeciwnie, powtarzanie takiej "ubitej ścieżki", krok po kroku sprawia mi sporo frajdy. Traktuje to jako fajną zabawę, nie szukam wyzwania, nie próbuję nawet stworzyć gry. Można powiedzieć, że przerabiam te poradniki i książki dla samej przyjemności z przerabiania materiału. Dla samej ciekawości i przyjemności nauki nowego narzędzia. Dla mnie to wystarczy. Więc jeśli ktoś lubię sobie robić gry z poradników na yt, tworzyć "kod spagetti" itd, to niech sobie robi, skoro sprawia mu to przyjemność. Nie wiem po co ludzi do takiego czegoś zniechęcać. Dla niektórych ważna jest droga nie cel.
@@BiznesBear jak któś wie jak i ma 200 ludzi to myśle żę unreal naj.epszy z powody grafiki ale trzeba mieć komputer z nasa choć ostatnio małe studia sie przenoszą na godota pewnie z powodu gdscript
"btw mam pomysł, żeby na uwagi @DevKacper odpowiedzieć w youtube shortcie, ale jeszcze nwm czy się zgodzi" Zgoda :D
Jako game dev pracujący z Unity codziennie, powiem, że radzenie początkującemu programiście, by nie używał silników i gotowców, tylko pisał wszystko sam od 0, to najgorsza rada jaką słyszałem ever :D
Dlaczego?
@@Wigtor Pełna odpowiedź wymagałaby odniesienia się do każdego argumentu z filmu i wypowiedź byłby tak długa, że pewnie nikt by jej nie przeczytał.
W wielkim skrócie, jeśli chcesz robić gry, to chcesz się skupić na robieniu tej gry, nie na tworzeniu silnika. Jeśli ktoś nie rozumie co się dzieje w tutorialu do Unity, czy pisze kod spaghetti w prostych skryptach, to polegnie na tematach wymagających zaawansowanej wiedzy jak fizyka, rendering, system kolizji, optymalizacja performance'u itp. Pomijam już masę sytuacji, że jak ktoś np. stwierdzi, że jego gra na PC, bardziej się nadaje na telefony, musiałby zmienić wszystko w swoim napisanym na PC silniku. W Unity masz to out of the box.
Jeśli chcesz poćwiczyć programowanie i pobawić się w pisanie fizyki, super ćwiczenie. Jeśli chcesz pisać grę, ucz się z tutoriali i dowolnego gotowego silnika i rób grę. Jeśli nie potrafisz zrobić gry w gotowym silniku, szansa, że ją zrobisz lepiej, pisząc wszystko od 0, jest minimalna.
Podzielam to zdanie. Również pracuję w Unity i gdybym miał zaczynać od totalnego zera bez silnika to spędził bym parę lat na tworzeniu skryptów które nikomu nie są potrzebne. Większość branży siedzi na Unity lub Unrealu, więc jeśli ktoś na poważnie myśli o zdobyciu umiejętności potrzebnych do pracy przy grach, to powinien zapoznać się z którymś z tych dwóch silników. Nawet jeżeli jakaś firma ma własny silnik to odpowiadają za niego osobni programiści, którzy nie robią gier i jest to osobno specjalizacja. Pisanie silnika od zera gdy chcemy robić gry to sztuka dla sztuki i jako taka powinna być traktowana. Jako samorozwój gdy już mamy trochę doświadczenia i chcemy dowiedzieć się jak dokładnie działają pewne rzeczy, których cała branża używa na codzień.
Nie pytaj typa, bo gada do Ciebie głupoty. Taka prawda, żeby olać to Unity jak najszybciej. Przez to, że nowy Prezes jest Agentem Electronic Arts, a to są terroryści na kasę.@@Wigtor Oni Ci przedstawiają tylko dwie alternatywy, bo tak mają sprane łby, mądrzy w gębie. Unity nigdy nie używaj, szkoda nerwów na instalacje powtórne, zawieszanie się etc. Jak nie chcesz używać Unreal, to możesz CRYENGINE : ). Oni tak używają jakby byli wydawcami o zasięgu Wojewódzkim, a nawet o takim zasięgu nie są. Słuchaj się obszczymajtków to daleko nie zajedziesz.
prosta odpowiedź. NIE KORZYSTAJ Z NARZĘDZI RÓB SWOJE XDDDD. Przecież to jest dosłownie absurd nad absurdy. Dlaczego np. rolnik miałby korzystać z ciągnika skoro może zaprząść kobyłę i płóg i orać. ALbo lepiej nie weźmie płóg w łapy i sam to tara @@Wigtor
Ja zazwyczaj jak robię coś w Unity to najpierw myślę na jakiej zasadzie to ma działać, jak mi się nie udaję po wielu godzinach to szukam w dokumentacji. A na YT szukam filmów jak dana rzecz działa konkretnie i w jakim celu.
Pomimo że to satyra to szczerze narracja tego filmu jest trochę błędna. Skupiasz się na użytkowniku unity, a niekoniecznie samym silniku, o którym wspomniałeś parę razy, tylko to co podałeś za minus, można całkiem łatwo uzasadnić, np.
0:29 Silnik nie zawiera na start wszystkiego, tylko masz pakiety które możesz pobrać do projektu, ale nie musisz. Jedyne co unity wczytuje w nowym projekcie to to co jest wymagane do tego, by działała fizyka itp. a do bardziej skomplikowanych rzeczy trzeba użyć package manager'a. A jeszcze odnośnie 3:50 bo zahaczasz o bardzo podobny temat, polecając biblioteki. Tyle że jak narzekałeś na unity mówiłeś o tym że uczysz się konkretnego silnika. A używając biblioteki co robisz, wiesz jak działa ta biblioteka od środka czy tak samo uczysz się jak działa ta konkretna biblioteka a nie wszystkie inne. Jak narzekałeś na osoby oglądające poradniki, czy używając nowej biblioteki nie używasz google'a by dowiedzieć się czegoś czego o niej nie wiesz, czyli to na co narzekasz w przypadku unity?
4:10 tworzenie silniku jest trudniejsze zwłaszcza jeżeli chcesz uzyskać taki sam rezultat jak osoba z silnikiem, dosłownie mamy czasy w których osoba używająca UE5 jest w stanie zrobić w pół godziny grę, w której zrobienie czegoś podobnego zajęłoby naprawdę ogrom czasu tworząc własny silnik. Jako przykład mogę dodać to, że polecałeś napisanie własnego particle systemu, tylko ten sam czas możesz poświęcić na uczenie się vfx graph'a w unity i uzyskać znacznie lepszy efekt. W tym samym czasie.
Odnośnie plusów i minusów pisania własnego silnika polecam film code monkey "Why I'm glad I didn't use Unity" - Code Monkey Reacts. W całkiem dobry sposób to podsumowuje, oglądając film gościa który ma całkiem podobną opinie do ciebie.
A i odnośnie momentu 4:18 i 3:46. Czy ty odpaliłeś unity i zacząłeś z niego korzystać przez więcej niż 5 godzin, czy po prostu mówisz bzdety. Bo obu tych rzeczy możesz nauczyć się korzystając z unity lub unreal'a.
Spokojnie bracie, po co te nerwy. Oczywiście, że skupiam się na użytkowniku, a nie na silniku, bo taki był zamysł filmu i ma wzbudzić w oglądających pewne refleksje. Silnik zawiera za bardzo dużo bloatu na start. Po co mi fizyka 3D, renderer 3D, grafika 3D, dźwięk 3D w grze 2D? Dlaczego mam wbudowaną obsługę reklam na telefon, czy sterowanie dotykiem skoro go nie potrzebuję?
Biblioteki działają troszeczkę inaczej niż całe silniki. Przykładowo SDL ( z którego aktualnie korzystam na kanale) zawiera funkcję do tworzenia okna, funkcję do rysowania i funkcję do handlowania inputem. Nie uczysz się jak działa biblioteka od środka, czy jak jej powinno się używać. Gdy musisz stworzyć okno poprostu używasz istniejącej funkcji. Jest to taki skrót, żebyś nie musiał pisać wszystkiego od zera. Możesz ją zastosować w dowolnej strukturze, czy języku. Potrafiąc SDL'a pisałem gry w SFML'u Pygami'e i wielu innych bibliotekach np. citro2d na nintendo ds czy glib2d na Playstation Portable. Daj mi kogoś, kto ma dużo doświadczenia z unity i zerowe w unrealu i zobaczymy czy sobie poradzi.
Odnośnie końcowych momentu 4:18 i 3:46 to pracowałem w unity. Dużo i często. Wydałem grę na androida, która zarabia jakieś grosze do tej pory. I mam nadzieję, że nigdy do tego nie wrócę.
PS: Właściwie to "Why im'a glad i didn't use unity" to była lekka inspiracja do zrobienia tego filmu. Dodatkowo moja opinia niestety podparta jest moimi doświadczeniami, czyli tysiącami godzin spędzonych na programowaniu i tworzeniu własnych narzędzi. Jest duża szansa, że gdybym tego nie robił, to uważał bym inaczej. Możliwe, że tak samo jak ty.
PS2: Właściwie to napisanie particle systemu to 0.5-1godzina czasu tylko,ze ten czas możesz również wykorzystać na naukę hiszpańskiego, czy nowego języka programowania do pracy. Dziwny argument masz, bo czas zawsze można lepiej wykorzystać, a moim zdaniem takie wyzwanie jak to jest bardzo przyjemnym sposobem, dzięki któremu sprawdzisz się poza strefą komfortu i wiele się nauczysz.
Pozdrawiam
@@Wigtor Nie no jestem spokojny, po prostu czułem potrzebę napisania tego bo sam film wygląda mi bardziej nie na samą satyrę, a po prostu podawanie argumentów przeciw silnikom, które mają zostać udowodnione przez historyjkę. I z pierwszym kontrargumentem się nie zgadzam, jeżeli wybierzesz w unity że chcesz stworzyć grę 2D, to raczej wybierzesz albo 2D core, albo 2D (URP) które (właśnie to sprawdziłem) na start mają tylko rzeczy związane z 2D, dosłownie polecam sprawdzić samemu jeżeli masz pobrane unity. Tak samo jest z reklamami i sterowaniem dotykowym.
Overall, masz racje odnośnie robienia gier na starsze platformy jak psp czy właśnie ds. I tak sam do końca nie korzystałem nigdy z bibliotek, przez co moja wiedza o nich nie jest jakaś duża. Tylko czy to naprawdę jest takie ważne jeżeli takie unity już na sam start, pozwala ci portować może nie na psp, ale np. na xboxa, playstation czy switcha. Więc jeżeli nie obchodzi cię robienie gier na 15 letnie konsole to raczej nie widzę zbyt wiele minusów korzystania z unity. A odnośnie przenoszenia się z unity na unreala, oczywiście nie będzie to tak że osoba która znała unity od podszewki od razu zacznie robić nie wiadomo co. Ale i tak proces uczenia się unreala przejdzie znacznie szybciej, niż gdyby nie używać żadnego silnika. Bo dużo narzędzi i tak będzie w jakiś sposób podobna, a odnośnie pisania kodu to unreal ma blueprinty które podobno są serio świetne i bardzo intuicyjne. Więc basically wystarczy ci wynieść po prostu odpowiedni mindset do pisania kodu.
Jakby spoko tobie unity nie przypadło, ale mówienie, że robienie własnego silnika jest znacznie lepsze do robienia gier, niż użycie do tego silnika brzmi po prostu jak niedopowiedzenie. Bo niby spoko wiesz więcej na temat tego jak działa twoja gra, ale co z tego jeżeli druga osoba osiągnęła lepszy rezultat w krótszym czasie. Gdzie jedyne w czym twoja gra wygrywa to performance(ale to tylko wtedy jak wiesz jak nie robić spaghetti). Nie chcę powiedzieć że pisanie silnika i robienie gry na raz to coś znowu bardzo złego, ale mam wrażenie że od tego znacznie więcej osób się odbije. Zwłaszcza że nawet jeżeli chcesz robić gry i z tego wyżyć, to używanie silnika jest znacznie mądrzejsze. Bo i tak większość studiów korzysta albo z unity/unreal, niby dalej masz studia z autorskimi silnikami jak frostbite czy cryengine. Ale i tak ostatnio coraz częściej słyszy się o tym że duże studia przechodzą na unreala, np. cd projekt red lub bandai namco.
Odnośnie pisania particle systemu, przepraszam że nie sprecyzowałem, ale VFX graph to particle system w unity, który jest bardziej wydajną wersją unity particle system. Przez co uważałem że argument jest całkiem trafnym porównaniem.
Końcowo mogę powiedzieć, że prawdopodobnie kiedyś dzięki tobie też wyjdę poza banieczkę unity i spróbuje zrobić grę(lub jakiś program) nie korzystając z unity, ucząc się przy okazji c++ lub pythona. Z samej ciekawości odnośnie bibliotek i co można z nimi zrobić.
PS. Jeżeli walnąłem jakąś gafę jak z bibliotekami chcę przeprosić z góry i byłym wdzięczny za wskazanie mi błędu.
Więc no,
Miłego dnia
@@BocchiMan. Może jednak za bardzo cisne po tych silnikach. Również miłego dnia życzę
@@Wigtor Widzisz to co napisałem wyżej, zapomnij o tym pisanie własnego silnika jednak jest znacznie lepszą opcją, niż używanie unity(ale zawsze można użyć godota).
Moim zdaniem to nie zależy od tego czego używasz tylko jak tego używasz.
Tak samo jak moge wpisać w yt "Jak zrobić strzelanke w unity" i kopiować to co twórca filmu miał na myśli tak samo np moge wyszukać "Jak zeobić prostą baze danych w pythonie"
Gdy natomiast wyszukujesz rzeczy typu "Jak działa rigitbody w unity" albo "jak wczytać obrazki w pygame" to uczysz sie jak myśleć samodzielnie.
Chat GPT też nie zaszkodzi jeżeli pytasz sie go o drobne rzeczy a nie przepisujesz kod 1 do 1
Ale weź też to pod uwagę, że z tutoriala "jak stworzyć prostą strzelankę" możesz wyciągnąć wnioski, nauczyć się to co zrobiłem no i oczywiście zrozumieć jak działa taki cały system i na podstawie tego możesz myśleć o zrobieniu czegoś podobnego, ale jednak posiadając już przydatnś wiedzę
Umiejętności programowania to tylko mały element rzeczy potrzebnych do robienia gier. To jest rzecz, która się przydaje czy używasz jakiegoś silnika czy nie. Nie pisz własnego silnika, bo wymyślasz koło na nowo. Czemu nie wykorzystać swojego czasu do zrobienia czegoś, co będzie chociaż trochę nowe? Silników jest cała masa, i nie wszystkie są tak wypasione jak Unity czy UE5 ;) Część jest mała i lekka w sam raz pod małą lekką grę indie. W robieniu gier największym wyzwaniem są assety. Na gotowcach nie zrobisz nic sensownego, no chyba, że wymyślisz coś takiego jak Tetris, gdzie nie musisz mieć grafik, bo wszystko sobie narysujesz z prostokątów. Jeśli chodzi o gry, fajną zabawą jest zrobienie czegoś co praktycznie nie wymaga assetów, albo mogą być umowne. Zrobiłem kiedyś pac-mana, sudoku. Można te stare klasyki rozbudować o nową mechanikę i już jest coś ciekawego. Proste logiczne gierki są nawet grywalne i nie muszą mieć specjalnie grafiki. Wystarczy sobie ogarnąć temat gier retro, z 8-bitowców. Kopalnia pomysłów. Pixle jak woły i nagle okazuje się, że grafikę sobie sam narysujesz i to szybko. A silnik to tylko narzędzie. Nawet kod to tylko narzędzie.
Już abstrachując od faktu, że film to satyra i nie powinno się go brać na poważnie, to ciekawe spostrzezenie. To znaczy ja od zawsze widzialem gamedev od drugiej strony medalu - programowania. Nie mialem i prawdopodobnie nie bede mial nic wspolnego z grafiką czy innymi assetami. Przez to automatycznie będę przekazywał swoją opinię opartą na tych właśnie doświadczeniach. Zastanawiam się czym następnym razem (podczas tworzenia filmu o takiej tematyce) nie wziąć jakiejś artystycznej duszy do wypowiedzenia się. Co o tym sądzisz?
@@Wigtor Jeśli chodzi o gamedev, masa artystów potrzebna do czegokolwiek innego niż retro. Artysta od modeli 3D, czasem ogarniają też tekstury, artysta od grafik 2D (UI, uzupełniająca grafika), jedna z bardziej poszukiwanych umiejętności to tworzenie map.
Level design to zwykle najdroższa rzecz w grach. Najwięcej godzin na to idzie. Ludzie zaczynają przygodę z tym z reguły na scenie modderskiej, robiąc nowe mapy i misje do znanych tytułów. Prawdę mówiąc nie widziałem jeszcze dobrego wywiadu z level designerem. No może poza panem Romero, ale to stare czasy.
Miałem też problemy z dźwiękami do mojego Sudoku ;) Ciężko dobrać z darmowych gotowców coś co nie wkurza i jakoś pasuje do reszty. Z muzyką poszedłem na łatwiznę - darmowe chip-tune-ki z keygenów ;) Nie wszędzie pasują.
Co do kodowania, na tym najczęściej pojawiają się opóźnienia, ścinki i glitche. Zdecydowanie to nie jest temat dla początkujących, jasne, nawet ja robiłem proste gierki, ale proste. W czymś większym to już trzeba mieć te lata praktyki i kilka zatłuczonych klawiatur ;)
Już widzę jak ktoś kto nie umie programować, zacznie naukę od tworzenia gry bez jakiegoś silnika typu Unity / Unreal.
Ktoś kto nie potrafi programować tym bardziej będzie kopiował bez myślnie kod z różnych poradników do stworzenia takiego silnika - i tam tym bardziej sie zagubi, a nie znając wzorców projektowych kod bedzie jeszcze większym spagetti.
Przy unity czy unreal początkujący, małym nakładem pracy będzie widział zadawalające go efekty i progres, że coś w jego grze się dzieje: coś sie renderuje, może poruszać postacią itp. Gdzie przy tworzeniu czegoś takiego od podstaw pierwsze widoczne efekty będą widoczne po dużo wiekszym nakłądzie pracy i czasu - a efekty mogą nei być na tyle zadowalające i taka początkująca osoba może się zniechęcić.
Unity to narzędzie pozwalające na łatwy start dla osób zielonych, ale również potężne narzędzie dla zaawansowanych twórców. Mimo twoich argumentów i tak polecam Unity czy inne tego typu narzędzie dla osób którzy chcą zacząć naukę programowania na przykładzie stworzenia swojej pierwszej gry.
Nikt nie oczekuje od początkującego że będzie wiedział wszystko, a nawet kopiując kod i próbując naprawić błędy które powstały przy kopiowaniu, czegoś się uczysz, poznając coraz więcej i więcej silnika i tego jak się pisze i jak się powinno pisać skrypty.
Wzruszyłem się ];-D... .
ALE TO SIE DOBRZE ZESTARZAŁO XDDDDD
Widać ze nigdy nie miałeś styczności z programowaniem w Unity oraz z poważnym gamedevem. Jestem deweloperem kilkunastu gier na steamie oraz aktualnie pracuję przy projekcie AAA wlasnie w Unity. Wprowadzasz ludzi w błąd, 90% filmu jest nie prawdą, nie wiem skąd masz takie informacje xd
Dlaczego tak uważasz?
Bo pracuje w tej branzy od 7 lat i pierdolisz głupoty pod clickbaitowe tytuły@@Wigtor
@@nopepsi206 Liczyłem, że serio podasz jakieś argumenty, bo może kiedyś powstanie poprawkowe videło, ale się przeliczyłem. Też mogę powiedzieć, że pracuje w branży 7 lat, tylko że ja mam dowody, a nie rzucam argumentum ad personam gdzie popadnie. Miłego
Ciezko byłoby podać argumenty, bo bym Ci musiał napisać rozprawkę bo 90% filmu jest bullshitem wyssanym z palca xd, miłego@@Wigtor
@@Wigtorja ci napisze bo mi się w życiu nudzi
To, co krytykujesz tutaj, to użytkownicy, którzy próbują zrobić grę po raz pierwszy i nie mają zielonego pojęcia, jak się do tego zabrać, dlatego sięgają po poradniki zamiast eksplorować Unity samodzielnie. Straszna otoczka miniatury i tytułu sugerująca, że Unity jest złe, choć w filmie nie o to chodzi. Straszny clickbait - nie wiem, czy to konieczne. Z drugiej strony, jak można nauczyć się tworzyć gry w Unity, nie próbując tego praktycznie? Ktoś, kto nie zna podstawowych zmiennych, a chce tworzyć gry, nie zrobi tego bez oglądania poradników. Nauka języka, na przykład angielskiego, wymaga zapoznawania się i wkuwania znaczeń poszczególnych słówek. To samo tyczy się programowania - trzeba działać, działać i działać, aż w końcu nie trzeba będzie sięgać po poradniki, bo samemu się będzie wiedziało, co zrobić. Dlatego uważam, że film jest trochę mylny. Ten, kto chce osiągnąć wyższy poziom programowania, to zrobi, a kto będzie tylko kopiować kody, nie osiągnie niczego. W tym tkwi nauka. To moje zastrzeżenia dotyczące treści filmu, ale cały format, poczucie humoru i sposób wykonania są bardzo dobre. Życzę Ci sukcesów!
Bo jest złe, nadaje się dla frajeróvv. Przy Unity pozna się co to kurvvica... .
Eee, trochę niesprawiedliwa diagnoza. Duża część problemu, który opisujesz nie leży w silniku, tylko w sposobie uczenia się. Życiowa prawda brzmi - każdy Piotr był kiedyś Brajankiem. Nauka KAŻDEGO języka zaczyna się od oglądania poradników i kopiowania kodu. Nie ma nic złego w zaczynaniu od Unity, Clickteam Fusion czy nawet Scratcha, bo dają podstawowe pojęcie o tym, czym jest programowanie i pozwalają na skupieniu się na innych ważnych częściach tworzenia gry. Tworzenie własnego silnika ma sens tylko kiedy masz już dobre pojęcie o tym jak wygląda proces tworzenia gry.
XD
Dziwny zbiór fikołków myśliwych, nie zgadzam się z żadnym z wymienionych punktów
Ale bzdura w 4:09 ,no to powodzenia od 0 pisać grafikę, fizykę pod 3d i może obsługę VR, samemu bez bug'ów. Do tego trzeba mieć już jakieś dobre podstawy algebry i fizyki.
ale mnie zachęciłeś do zrobienia gry vr from scratch
tylko nie używaj gotowych bibliotek, napisz je sam - według tego co doradziłeś w filmie na temat silników gier. Zadasz pewnie sobie pytanie - dlaczego mam je pisać od nowa skoro już ktoś to zrobił? No i własnie to samo pytnaie powinieneś sobie zadać w postaci - po co istnieją gotowe rozwiązania typu Unity, UE, Godot, GameMaker etc. Film z tyloma bzdurami że to hit@@Wigtor
lol nie prawda. Trochę naciągnięty filmik 🙂
Ja używam unity ale większość skryptów pisze sam a jak potrzebuje pomocy to nie kopiuje lub bezmyślnie przepisuje tylko patrzę na czym polega ten skrypt
"Tak naprawdę podczas tworzenia w Unity nie uczysz się robić gier, uczysz się obsługiwać program Unity3D" Masz rację nie robi się w tym gier tylko programy szpiegowskie :O.
Nie prawda hackerze
"this aged well"
Już chciałem dać łapkę w dół ale pojawiłem się w filmie 4:39 więc zostawiam w górę :D
A tak serio to możliwe, że niedługo nagram film z tym, że z argumentami w drugą stronę tak już na poważnie xD
Właśnie miałem Ci podesłać czy nie chcesz odpowiedzi zrobić, ale uznałem, że tak poważny człowiek będzie zbyt zajęty ;o
czy ty serio stwierdziłeś że lepiej robić gry bez silnika tylko dlatego że unity ssie xD?
Chcesz stworzyć grę - nie używaj gotowych silników - napisz swój. Chcesz edytować grafikę - nie korzystaj z Photoshopa - napisz swój program graficzny. Głupszej logiki nie słyszałem.
na najnowszym filmie trochę to sprostowałem. Nie chodzi o to, żeby każdy pisał własny rendering 3d itp, ale jeśli ktoś potrafi programować i chce zrobić platformówke 2D, to silnik to trochę overkill. Change my mind
Po to są silniki aby tworzyć gry łatwo , szybko i skupiać się na samej grze a nie tworzyć własny silnik co wydłuza czas tworzenia 10-krotnie.
Nie jest przesadą. Dostajesz gotowe narzędzie i skupiasz się na tworzeniu gry a nie na tworzeniu narzędzia. To tak jakbyś chaciał stworzyć prostą grafikę i używał do tego Photoshopa albo Gimpa - też mógłbyś powiedzieć, że te programy są zbyt rozbudowane do prostej grafiki - ale nie musisz korzystać ze wszystkich ich funkcji - używasz tylko tych kótrych potrzebujesz. Tak samo jest z silnikami do gier. Nawet do prostych gier używa się silników nawet tych poteżnych bo to po prostu oszczędza czas i pozwala skupić się na samej grze.
Aż mi się ta pasta o chodzeniu po bułki przypomniała xd
faktycznie, do gier 2D można użyć c++, c#, python ale do gier 3D lepsze było by chyba unity, ale i tak zgadzam się
Unity jest dobre dla tych co chcą mieć choroby psychiczne. Od zawsze mówię, że Unreal to jest to : ). Do 3D gier alternatywa to CRYENGINE... .
spk, kazdy ma swoje zdanie, ja tam lubie unity?@@VladIDrago
>twierdzenie żeby ktoś z zerowym doświadczeniem w programowaniu rzucał się na głęboką wodę, i pisał grę bez silnika
xd
imo korzystanie z poradników i kopiuj-wklej kod na początku jest jak najbardziej ok - trochę gorzej jak mija jakiś czas, i ktoś się nie uczy języka ani api unity, tylko wszystko z poradników
dlatego też imo najlepiej rozpocząć korzystanie z unity dopiero jak się już chociaż trochę zna c#
Kto każe tworzyć gry bez umiejętności programowania? Bo ja bym tak nie robił
@@Wigtor też bym tak nie robił, ale w filmie nie było widać jakoby piotr znał już język programowania, tylko od razu poszedł w gamedev bez żadnego silnika
Chyba mylisz tworzenie gry z nauka programowania. Unity nie jest do nauki programowania tylko do tworzenia gier. Tworzenie gry na wlasnym silniku to glupota i pomimo, ze wole Unreal Engine to Unity jest rowniez bardzo dobrym narzedziem. Kazdy na poczatku przygody z programowaniem pisze spaghetti code i Unity nie z tym nic wspolnego. Niby ten filmik to miala byc satyra, ale chyba autor nie do konca zna znaczenie tego slowa.
Nie zgadzam się / ewentualnie to zależy. Film celuje w osoby tworzące gry 2D, bo 90% SKOŃCZONYCH projektów w godocie/unity to takowe. Silnik w takim wypadku to czysty overkill i wystarczy spojrzeć na ilosc fpsów - wiele gier korzystających z unity, które pobrałem wyciągały max 120 podczas gdy podobne gry napisane from scratch przebijają barierę 1000 klatek. Po drugie tworzenie gier według Ciebie może różnić się od tego jak postrzegają to inne osoby. Jeżeli uważasz, że to biegłe operowanie w edytorze jakiegoś silnika, level design, tworzenie assetów i marketing, to moim zdaniem brakuje Ci ważnego elementu - Rozwiązywania problemów. Tego nie da się nauczyć sklejając fragmenty istniejących rozwiązań znalezionych na forum unity, czy pobierając gotowy plugin. Tworząc grę samemu ponad 50% czasu będzie poświęcone na tworzeniu nowych mechanik, czy naprawianiu błędów. Bez skilli w programowaniu i problemsolvingu dokończenie projektu jest nie możliwe. Dlatego wiele twórców szufladkuje się w gotowe rozwiązania i dlatego dużo gier to kopie istniejących z innymi assetami. Takie jest moje zdanie, ale wynika z moich doświadczeń i z tysięcy godzin spędzonych na programowaniu oraz tworzeniu własnych narzędzi. Każde rozwiązanie jest odpowiednie dla innej grupy docelowej i mój film celuje w takich matematycznych świrów. Pozdrawiam
@@WigtorJak nie lubię współczesnych gier które same się przechodzą to też uważam że pisząc od zera dużo więcej się nauczy i o wiele bardziej potem się to przyda, tak jak mówisz większość gier 2D tworzonych w gotowym już silniku to gry tworzone bez żadnego pomysłu czy idei. ruclips.net/video/SaVX38SLKHk/видео.html ten materiał ma sześć lat, ale niewiele się zmieniło w tej kwestii zgadzam się praktycznie ze wszystkim co w nim powiedział.
Po miesiacu uzywania unity zaczalem nauke c++ i vulkana. Po roku mam swoja wlasna biblioteke do renderowania 2d i teraz tworze silnik 3d z interfejsem graficzym. Co prawda moj kod jest niskiej jakosci, a sporo rzeczy wymaga dopracowania, ale wciaz sie ucze. To byla jedna z lepszych decyzji w moim zyciu
Mega podziwiam! Moja zabawa z tworzeniem silników 3D kończyła się na nauce mnożenia macierzy xD
@@Wigtor Akurat temat macierzy jest dla mnie niezbyt zrozumialy. Rozumiem jakies podstawowe pojecie Model Projection View, ale poki co nie zaglebiam sie w ta czarna magie. Wszystkiego mozna nauczyc sie w trakcie rozwijania silnika, wiec sie nie poddawaj na czyms takim ;)
Ale bullshit, sorry ale nagranie wygląda jak marudzenie juniora który wypowiada się na tematy których nie rozumie.
senior sie znalazł; po napisaniu własnego silnika 3d oficjalnie mogę się wypowiadać w tematach silnika 3d pozdrawiam
XDD brat hejtuje unity a pozniej mowi o pythonie i pygame
Nie narzędzie, a technika czynią z Ciebie wojownika
@@Wigtor tylko weź pod uwagę że jest to niesamowicie niewydajne narzedzie i sugerowanie go a jednocześnie krytykowanie unity pod względem wydajności jest trochę dziwne
@@karroteu5000prawda, pyton jest mega niewydajny i nie nadaje się do gier
teraz powinien być dodatkowy, 5 rozdział: opłaty za instalację twojej gry...
No dobra, w sumie zastanawiałem się nad tym bo kompletnie nie mogę pospinać mojej gry, ba! nie mogę nawet zacząć. Mam kilka pytań:
1. Czy w takim razie, żeby lepiej odtworzyć realistyczną fizykę zachowywania się statku tak jak w np The Expanse lepszy będzie C++? (Mi się wydaje, że tak, ponieważ tak jakby daje szersze pole możliwości od C# ale czuję, że się mylę)
2. W jaki sposób zacząć myśleć nad tym projektem? Chcę zrobić symulator bitwy kosmicznej, żeby to wszystko wyglądało i działało jak w The Expanse.
Jeśli chodzi o fizykę 3D to ciężko Ci będzie to samemu napisać bez odpowiedniej wiedzy. Chyba, że masz jakieś poprzednie doświadczenia z taką pracą. W C# (czyli też w unity) jesteś w stanie zrobić dokładnie to samo co w c++ -> wniosek: Twórz w tym co bardziej lubisz / jest dla Ciebie mniej problematyczne. Jeśli nie potrafisz czegoś zrobić w unity jest spora szansa, że bez silnika/ w c++ też Ci nie wyjdzie. Pozdrawiam
pracuje przy silniku unity od 2 lat nie zajmuję się kodowaniem jednak wiedza jaką nabyłem przez te 2 lata pozwala mi naprawiać niektóre błędy w kodzie, to nie kwestia tego, że unity jest złe tylko tego, że ludzie nie starają się naprawiać błędów sami tylko chcą znaleźć gotowe rozwiązania w sieci albo porzucają projekt bo jest tak zbugowany. Jednak korzystanie z gotowych skryptów i kursów sprawiło że rozumiem kod w C# i potrafię na nim pracować, mimo że tak naprawdę zajmuje się level designem :). Podsumowując zależ jak kto podchodzi do nauki pisania :)
każdy silnik czy też język programowania ma swoje assety (biblioteki) zgadza się. Początkujący twórca będzie kopiował i wklejał to do swojego projektu i to jest błąd. Przed podjęciem tego kroku powinien zapoznać się z dokumentacją danego asseta i to ze zrozumieniem (dlaczego to tak działa a nie inaczej) żeby było wiadomo gdzie dany fragment kodu można wykorzystać, i podjąć stosowne kroki aby zapobiec ewentualnym błędom bądź usunąć taki jak wystąpi. Pozdrawiam
A może by tak użyć Unity tylko powstrzymać się od bezmyślnego kopiowania komponentów? Przecież pisząc w jakimś PyGame czy innej bibliotece, też możesz skopiować całą zawartość bez świadomości co zmienić, jak naprawić błąd - tylko takich źródeł będzie mniej. Argument dot. nauki komponentów na pamieć też jest kiepski. Większość z tego można sprowadzić do analizy matematycznej. Można używać fizyki, ale nie trzeba - wtedy albo 2d, albo 3d i tworzymy grę na komponentach fizycznych. Jeśli nie, można użyć tylko colliderów i raycastów, a jeśli nie to można z wszystkiego zrezygnować. Kopiowanie komponentów bez zrozumienia jest głupie. Ale równie bezsensowne jest pisanie swojego silnika. W komentarzach sporo osób z doświadczeniem to tutaj zauważyło. Jak chcesz się nauczyć, musisz rozwiązywać problemy - niezależnie gdzie one będą. Nie ma łatwiej drogi.
Skoro to takie ciężkie to może zrobić Unity w chmurze i płacić za dostęp do niej a potem ulepszyć samouczek tak żeby uczył i wyjaśniał.
ten film (jak go gdzieś w listopadzie zobaczyłem) zainspirował mnie do zrobienia gry nie w unity tak jak zwykle robiłem i powiem że to byłą najlepsza decyzja jaką mogłem podjąć. Nie będę musiał dawać zaliczki, prosty w debugowaniu, w 2 odgarnąłem wszystkie podstawowe rzeczy, kod jest prosty i wygodny. No żyć nie umierać!
Ja w unity dopiero się uczę i uważam, że samo unity nie jest problemem, problemem jest to, że dochodzisz do momentu, w którym nie wiesz i nie umiesz nic dalej zrobić, ALE wtedy odpalasz poradnik na youtube i okazuje się, że nie działa i znowu i znowu aż w końcu znajdujesz ten dobry i gratulacje nauczyłeś się odróżniać spoko rzeczy od syfu
Masz racje, wczytywanie wszystkich komponentów nie jest potrzebne dla początkującego game maker. Ale Unity pozwala oswoić się z programowaniem. Jeśli nie kopiujesz wszystkiego bez zrozumienia kodu to jest dobra droga żeby zacząć co kolwiek programować. Ja sam zaczynałem od Unity i dzięki temu mogłem skupić się na koncepcie gry. Jeśli robisz gry pod mobile to myślę że Unity jest przystępnym silnikiem z dużymi możliwościami. Jak zaczynałem programować na początku swojej przygody to moje kody wyglądały typu hello world albo prosty kalkulator. Nie wyobrażałem sobie wtedy że mogę stworzyć jaką kolwiek gre. Unity mi w tym pomogło a nie zaszkodziło.
- Pisanie gry od podstaw jest bardzo fajne - ja po stworzeniu w ten sposób gry, zrozumiałem jak można stworzyć świat, w którym można się poruszać i wchodzić z nim w interakcje, za pomocą słów, co zmieniło moje spojrzenie na Biblię i opisany tam sposób stworzenia świata.. :) ..Jednak użycie silnika przyspiesza znacznie napisanie "fajnej" gry, a w dzisiejszych czasach, czas też czasem ma znaczenie... :)
rel
Po filmie mam straszne poczucie zmarnowania prawie 10 miesięcy na naukę robienia gier w Godocie
To znaczy, że dobrze napisałem scenariusz filmu ;)
nah, argumenty pokroju unity to gotowy silnik gier są bezużyteczne, tak samo jakby powiedzieć że python to przecież język interpretowalny więc lepiej pisać w assemblerze albo kodzie maszynowym
@@domi6125 te 3 tygodnie temu poczułem się jak frajer z tego powodu, ale po godzinie pomyślałem "mam to w dupie" i "w sumie to typ może pocałować mnie w dupę" po czym wróciłem do Godota (w którym teraz siedzę) mając wywalone na to wszystko więc nie przejmój się :)
@@Strefiks I dobrze, bo jak ktoś chce zrobić grę, to nie robi silnika gry. To tak samo jakby kierowca wyścigowy miał zrobić samochód, bo wtedy lepiej go będzie rozumiał. Inną kwestią jest pisanie dobrego kodu i w tym filmie się z nim zgodzę.
powiem tak film bardzo przyjemnie zmontowany, bardzo fajnie że wstawiłeś tutaj rodaka o nazwie "aarthificial" ( twórcę Motion Canvas ) jak i to że Piotr używał Pythona czyli jak każdy wie najlepszego języka programowania ;)
Python najlepszy język programowania. Chyba dla tych, którzy żadnego innego nie znają ;)
To język dla troglodytów raczej xD
Mam dla was taką rade. Nie uczcie się z poradników/kursów to tylko strata czasu. Czytajcie dokumentacje, jak czegoś nie wiecie wpisujcie to w google ale przed tym sami spróbujcie to naprawić sami. Tak samo jest z kodem który piszecie piszcie co umiecie jak nie wiecie próbujcie zrobić to sami jak nie wychodzi to wpisuj w google z czym masz problem i masz dużo odpowiedzi na to pytanie to tyle❤❤❤
myślę, że ten film to bait aby wywołać emocje
Z najgłupszych rzeczy jakie zdarzyło mi się słyszeć w życiu te "rady" są w czołówce.
1. Niepotrzebne komponenty unity - od jakiegoś (dość długiego) czasu unity umożliwia pobieranie tylko tych paczek których potrzebujesz. Silnik nie zawiera wszystkiego co ma do zaoferowania, w czasie tworzenia sam musisz się określić czego potrzebujesz i pobrać odpowiednie paczki.
2. Silnik jest zły bo jego użytkownicy często nie mają umiejętności żeby go używać - tego nie trzeba komentować chyba🤣
3. Najlepszym wyjściem żeby napisać własną grę jest napisanie najpierw własnego silnika - absolutny hicior wśród głupich rad! chcesz zakodzić sobie mała gierkę na androida? Nie ucz się unity, lepiej poświecić 3 lata na pisanie silnika i 3 miesiące na napisanie gierki🤣 widać że chyba nie zdajesz sobie sprawy jakim wyzwaniem jest napisanie czegoś sensownego jeśli chodzi o silniki do gier w rozsądnym czasie
Co jak co ale ja używam scratcha😎
0:50 Blender: 😠
To chyba masz drewno pc ze ci tak wczytuje
raczej nie inaczej
Ja jestem coś pomiędzy Piotrkiem a brajankiem
To samo można powiedzieć o wszystkich silnikach, a one właśnie po to są aby nie trzeba było pisaćcałej fizyki od nowa a skupić się na samej grze i oczywiście że nie jest to takie uniwersalne jak byś samemu wszystko napisał, ale wtedy jaki sęs ma kożystanie z silników? Myślę że autor nie rozumie po co są silniki gry
Sens
Dla mnie wady silników przerosły ich zalety; wniosek: nie ma dla mnie sensu korzystanie z silnika, więc z niego nie korzystam. Miłego dnia
Tego argumentu nie da się podważyć, każdy ma swoje preferencje, dla mnie silniki gier są korzystne i z nich korzystam
Miłego dnia ;)
po spróbowaniu pisania bez silników zobaczyłem większy potencjał i możliwość zmiany wszystkiego, także zgadzam się z tobą (silnik to dobry wybór na początek, ale jak chce się bardziej poznać język lepiej zacząć bez silnika)
I tak wole unity od Ureala
A ten przewidział przyszłość
Do gier 2D to chyba faktycznie warto probować najpierw bez silnika. Polecam JavaScript i tworzenie gier na przegladarkę. Bardzo fajne wyzwanie.
Co Ty w ogóle mówisz? Przecież niezależnie czy piszesz gry w unity czy UE5 to i tak musisz się nauczyć wzorca projektowego.
"Ciężko napisać dobry kod w unity" - to jest najdziwniejsze co kiedykolwiek usłyszałem xDDDD A to w innym silniku czy języku łatwiej jest pisać dobry kod?
Ten filmik brzmi jak tania reklama Phytona.xDDDDDDDDDDDDDDDDDD
Jak zaczniesz o czymś nagrywać to najpierw spojrzyj na to z innej perspektywy. Ja w unity pracuje od 5 lat. I nie jedną grę zrobiłem. Czy w wolnej chwili czy dla jakiejś osoby w formie zlecenia. I unity ma swoje wady i zalety jak każdy inny silnik. To samo tyczy się języków.
Javy też nikt nie lubi. A jakoś programistów tego języka jest dużo.
To samo wracając do unity. Co ma do tego uruchamianie się długie samego silnika ? Albo to, że w unity gry są budowane z tych samych assetów kupionych na asset store?
Wyłożysz kasę na grafików? Na osoby, które przygotują te modele? Bo prosto jest cokolwiek napisać czy powiedzieć. Dopiero zrobić.
Jest wiele fajnych gier dobrze zoptymalizowanych z fajną ładną grafiką, które osiągneły sukces.
I co najlepsze jest w tym co mówisz to : "Młodzi programiści kopiują kod i tyle. Bo nie umieją programować" albo "Młodzi programiści robią system eq z tutorialem, a nie próbują sami".
A co jest w tym złego, że młody programista zajrzy do poradnika i zobaczy jak ktoś coś zrobił? Na tym to polega. To jest nauka. To tak samo jakbym się przyczepił do kogoś, że nie wie jak coś zrobić i korzysta ze stackoverflowa xDDD
zluzuj majty
Jak ktoś jest prawdziwym czadem to pisze gry na papierze. (to nie jest żart)
nie lubie unity lagodnie mowiac... ue5 niby ciezszy ale lepszy o wiele wedlug mnie
albo godot jest tez fajny
haha, ale i tak możesz zrobić "spróbowałem zrobić gre w unity **gówno**" ciekawe to by było
najlepszym silnikiem do gier to roblox studio imo
Ja korzystam z pygame i według mnie na lepiej korzystać z takiego rozwiązania ponieważ programując w bez silników można programować w językach lub poprostu ucząc się ich ale potem lepiej korzystać z silników.
Nikt nie mówi o tym, że edytor unity jest po prostu przepełniony - ja, gdy uruchomiłem go poraz pierwszy i ostatni, nie wiedziałem co klikać, gdzie wejść - brakuje tu prostoty. Dodatkowo, według mnie, robienie wszystkiego w edytorze wizualnym jest po prostu nudne. Większą przyjemność sprawia mi robienie wszystkiego w kodzie.
Przecież Unity to chyba najprostszy i najbardziej przejrzysty silnik jaki istnieje. Tam się po prostu nie da zgubić
ja kiedys robilem na telefony gry i to 3d. 2 lata pisalem proste "Snake 3d revenge" i musialem toolsy, edytory spritow itp.. Nigdy wiecej. Teraz unity 3d i mam wszystko pod reka prawie. Moge dograc co brakuje :).
Problemem jest bardzo często czas, a raczej brak czasu. Zrobienie dobrej gry z pomocą jakiegoś silnika może zająć kilka lat. Bez silnika to kilka lat więcej (na zrobienie własnego silnika). Dla początkującego ten czas to kilka razy dłużej z kilkukrotnym pisaniem wszystkiego od zera, gdy okaże się że jego amatorski silnik się do niczego nie nadaje.
Moim zdaniem, jeśli ktoś chce zrobić grę, a jest kompletnie początkujący i nie wie nic co i jak, to niech koniecznie najpierw zacznie z jakimś silnikiem. Niech spróbuje zrobić cokolwiek w tym silniku i niech czyta dokumentację do wszystkiego co używa żeby zrozumieć co zostało zrobione w tym silniku, jak to działa i dlaczego tak to działa. Niech najpierw nabierze trochę doświadczenia i wiedzy, a dopiero potem po drugim/trzecim małym projekcie spróbuje zrobić coś swojego (z silnikiem lub bez). I niech ta jego docelowa gra będzie mała, żeby się nie porywał od razu na robienie Baldur's Gate'a w pojedynkę bo zajmie mu to 20 lat albo się po prostu nie uda.
A co, jeśli ktoś by chciał stworzyć grę w silniku Adobe Flash w 2023 roku?
Jeśli chcesz zrobić grę flashową to nie masz innej opcji niż użycie adobe flash'a; Najpewniej możesz pobrać jakąs starą wersję czy coś
Trzeba przyznać, że było to dość wygodne narzędzie
@@Wigtor mi pobranie abandonware'a nie winno być problemem - potwierdzeniem jest posiadanie directora mx2004 oraz directora 11.5
Problemem będzie nauka języka oraz próba wymyślenia takowej gry
Jak bym opisał to Unity nie jest aż tak zły, Unity jest po prostu nie stabilny pod innymi względami, ale jeśli chodzi to łatwo się nauczyć Unity, ale w Unity CSharp nie jest prostym ale da się zrozumieć podstawy, a długość włączania zależy od dysków pracujących (polecam do tego SSD w tych czasach), jeśli chodzi o CSharp to najlepiej się nie uczyć ogólnego C# tylko te które jest pod Unity, bo zwykłe C# jest wymagające bardziej.
Ale wiesz że Unity używa "zwyklego" C#?
Ja zawsze nie chętnie podchodziłem do unity i podobnych. Wole wszystko napisać sam, mieć wolną rękę i wiedzieć co i jak działa. Bo tak to wyskakują co chwile errory których nie kumam, a sam kod jest jak filmie spaghetti. Osobiście zaczynam duży projekt w pygamie i mimo, że niektóre rzeczy musze robić sam tak jak ten parser mapy, tak czuje o wiele większą satysfakcje gdy dana funkcjonalność działa
Czekaj, narzekasz że silnik jest do bani, bo kod który SAM napisałeś jak spaghetti?
Fajny film, nadal będę używał unity ale spróbuje coś zrobić bez silnika, żeby zobaczyć czy w ogóle umiem programować xd. A tak swoją drogą, to inspirowałeś się może zagranicznym youtuberem Hamza? bo format filmików masz podobny do jego starych materiałów i też widać, że interesujesz się samorozwojem, tak z ciekawości się pytam. Powodzenia z kanałem na youtube!
Tak, inspirowałem się m.in hamzą i kanałem bebekoriginal. Chcialem też nauczyć się lepiej montować, a takie animacje to najlepszy sposób, żeby to zrobić. Jako ciekawostkę mogę powiedzieć, że tydzień temu mniej zaawansowane intro robiłem w tempie nawet 8 godzin na minutę, a teraz to max 2
teraz to akurat na serio nie powinno sie używać unity XD
Tym filmem przekonałeś mnie, żeby mój klon Minecraft zrobić jak GigaChady Mojangu w Javie. ;D
ja się uczę w pythonie podobno to przyszłość
Nie wypowiadaj sie jak sie nie znasz plus nie ladnie jest tak klamac..
jak powiesz coś z odpowiednio dużą pewnością siebie to staje się prawdą tftf
tak wsm to racja w unity programuje parę miesięcy i jedyne co sam zrobiłem to poruszanie sie a raczej tepanie sie po ziemi(zmieniałem x, albo y w update).Najlepiej samemu nauczyć sie paru języków i wybrać
skill issue
Wychodzi na to że unity to arduino dla twórców gier :D
Film zakłada, że każdy wybierający silnik jest kiddosem, który z dupy sobie pomyślał, że będzie robić gry, bo lubi grać w gry, a nie napisał w życiu nawet hello worlda XDD Taki jest target tego filmu, a ktoś z expem nie będzie opierał swojej decyzji na podstawie satyryczno bekowego filmu. Czyli forma przedstawiona w filmie trafia do dzieci chcących zrobić pierwszą grę, a w tym samym czasie omawiane zagadnienie to dla nich totalna abstrakcja XD
Myślałem, że będzie coś w stylu contentu jak na kanale "Dani" - bekowo albo "Randy" - trochę bardziej merytorycznie. W Polsce nie ma takiego contentu i jest to kusząca nisza, a wystarczy po prostu przedstawić gam dev w formie zrozumiałej nawet dla totalnych laików. Ten film wygląda jak flexowanie się skillem na zasadzie machania psu kiełbasą przed pyskiem, a następnie zjedzenie jej samemu, bo 99,9% odbiorców tego filmu jest lata świetlne od napisania własnego renderera.
wsm chciałbym być jak randy, ale brakuje jeszcze brakuje mi dużo umiejętności w kwesti storytellingu, montażu i wgl charyzmy. Może kiedyś stworzę coś wartego twojej uwagi
Wyobrażam sobie Janusza Janusz Chcę nauczyć się grać stworzyć grę 2d ale nie umiem pisać a piszę tylko o jakieś randomowe itemy
Chcę programować gry 3D ale przypadkiem jak w tej to jest tworzy przypadkiem lisza glica wirusa który popsuł mi komputer
2:40 jak mówisz że gry z Unity brzydko wyglądają to sobie zobacz na: TABS, People Playground, Secret Neighbor, Clustertruck, Teardown i Universe Sandbox
Tymczasem ten jeden z Gigachadów któremu widać przyrodzenie, a YT na to wgl nie reaguje (nigdy):
Kom dla zasięgu :)
Różne litery Wpisz różne litery i i bo nie umiał programować
2:55 tu dosłownie opisałeś dlaczego lepiej używać unity na początku, niż pisać samemu fizykę i resztę od zera. Stawiasz na równi osobę, która dopiero uczy się, z kimś, który ma obcykanego choćby pythona. Trochę od innego poziomu takie dwie osoby zaczynają. Jak dla mnie najzwyczajniej w świecie silnik powinien być dopasowany do umiejętności takiej osoby, a jeśli ktoś totalnie pisze grę w konsoli, bez silnika, to jego sprawa, jeśli chce wszystko totalnie po swojemu zrobić to luzik. Ale niestety na dłuższą metę w takim pythonie ciężko jest zrobić grę fabularną, tudzież po prostu dłuższą. I tak, to prawda, że unity niestety wczytuje za dużo bibliotek naraz, wiem, bo pracuję na codzień w unity :)
Dodam, że nie jestem początkujący, potrafię sam napisać wiele skryptów, praktycznie wszystkie, czasem na internecie sprawdzam jak zapomnę sobie jakiejś składni czy nazwy. Kod spaghetti powoli po 3 latach programowania zanika :) Coraz więcej tego środowiska znam na pamięć i w unity czuję się jak w domu, wiem gdzie co leży. Gdybym miał zacząć teraz od robienia gier tylko dzięki bibliotekom w pythonie to poczułbym się jakby mnie ktoś wyrzucił na bezludnej wyspie z siekierą i powiedział "radź sobie", gdzie nie potrafię samodzielnie dzięki bibliotekom napisać fizyki do gry, systemu kolizji, czy choćby zrobić głupiej animacji kamerą. A wybrałem unity, bo genialnie nadaje się do robienia mojego ulubionego gatunku gier Sandbox-RPG z pięknymi oświetleniami, lekko spikselizowaną grafiką i wspaniałymi animacjami :)
The forest jest zrobione na unity xD
bull shit... unity jest dla osób które potrafią programować, a nie dla początkujących, dla mnie ten silnik to błogosławieństwo.
Czasami mam wrażenie że Unity jest jak 2 kg szwajcarski scyzoryk w którym nie ma tego co potrzebuje XD tak w ogóle czy sama firma przypadkiem nigdy nie zrobiła konkretnej gry od A do Z na własnej technologii dlatego to co oferują jest takie umowne, nie było konkretnie do niczego użyte?
Pamiętam jak robiłem levele na Source czy UE to jak usiadłem do Unity myślałem że tu chyba nic dobrze nie zrobię ani nie przetestuje XD
Zrób serię jak zrobić bota discord
zacheciles mnie do uczenia sie jak zrobic wlasny silnik xD
Dawaj napisz go w rust - dodatkowy rigcz
@@Wigtorrust zly ?
@@TheBlackMaster rust dobry xD
moim zdaniem unity jest fajne ale byłoby lepiej gdyby można było programować w innych językach bo nie przepadam za c#
nie wiem co wy macie do tego unity. a propo czasu wczytywania to nauczcie sie programować i tworzyć dobre gry ;O
łeeeee chłop ma probelm do untuned 😭😭😭 hurdur (żart)
bo to jest żart
Wiem że stary, ale mam aspiracje by coś stworzyć (książkę/grę) i przypadkiem znalazłam twój kanał. Może to sprawi że zacznę działać.
A co do spaghetti to od razu na myśl przyszedł mi twórca Yandere Simulator, którego kod gry to jest spaghetti i jeśli to było nawiązanie do tej gry to trafiłeś w punkt.
a godot ?
Tak mnie to boli ze caly czas przepisywalem skrypty z poradników i pomimo wielu godzin spędzonych w unity nic nie zrobiłem i nic nie umiem
mam to samo
Człowieku w unity istnieją pakiety, jeśli czegoś nie używasz to po prostu to usuwasz. Jeśli potrzebujesz własnych rozwiązań to możesz to napisać XD np. własną fizykę lub zaimplementować gotowe systemy fizyki. Ten film to komplety absurd. Faktycznie unity potrafi się długo ładować, tak samo jak ue, godot szybciej (nie testowałem na większych projektach). Nikomu nie polecam tworzenie własnego silnika jeśli chce stworzyć grę a nie silnik. Inna beczka, że jest to błąd dev, że projekt długo się ładuje.
Jeśli to ten film to satyra warto by było to oznajmić w nazwie filmu, inaczej specjalnie wprowadzasz początkujących w błąd.
Według mnie lepiej zaczynać z ue5 uzywajac blueprintow
Pytanie, Pierwszy jezykdo tworzenia gier 2d moze prostych 3d to.... ?
taki z ktorym masz najwiecej wspolnego. Jak musisz sie jakiegos nauczyc w szkole/na studiach/do pracy to bedzie najlepszy wybor. Tbh w kazdym zrobisz 2d/proste 3d bo nawet niezoptymalizowany kod wyciagnie to 60 fpsow. Jak nie masz nic wspolnego z programowaniem, a chcesz zaczac robic gierki to zaczał bym z pythonem lub c
@@Wigtor Pozdrowinka
ja mam bardzo dobre doświadczenia z JavaScript i silnikiem ct.js, ale pół świata chwali sobie Godot, więc pewnie coś w tym jest. W nim przyda się pewnie doświadczenie z Pythona.
@@dafimperator POzdro
No nie wiem czy kod w Python wygląda jak "Spaghetti"
klamerki górą!
@@WigtorPreferencja!!
Dobry film odinstalowalem juz unity(ze wzgledu na ich polityke) ide robic gry na PSXa w samym C
Assembler lepszy, C jest dla noobów
:) pygame ahhh to prawdziwe wyzwanie wydajnosciowe jagby gra ktora uzywa pixel art'ow moze chodzic W 60-50 fps jesli zle sie ja zaprojektuje
HMMM... yan dev czy to ty?
A najlepszą lekcją z tego jest: nie ucz się wszystkiego od razu.
Siema, to ja Piotr.
Stary film, ale co mi tam napiszę komentarz. :D
W Unity nigdy nic nie robiłem, chociaż za jakiś czas może to się zmieni, ale zawodowo jestem programistą, typowym backendowcem w .Net. Argumenty przedstawiopne w filmie gdybym miał przełożyć na swoje życie zawodowe powinny brzmieć mniej więcej tak "Nie pisz w .Netcie, bo (i tutaj dodaj jakiś argument, nie wiem nawet jakiś stricte związany z wydajnością czy cokolwiek). No i spoko, pewnie np. w C++ dałoby się napisać coś co działałoby szybciej, wydajniej, ale przewagą C# + .Net jest szybkość pisania takiego rozwiązania i to jest powód, dlaczego... Warto używać Unity i podobnych silników. :) Fajnie dla zajawki zrobić własny silnik, ale polecanie robienie tego komuś kto nie ogarnia unity jest niezbyt trafne, bo jak ktoś bezmyślnie przerabia tutoriale Unity, to tym bardziej nie zrobi porządnego własnego silnika.
Ogólnie rozumiem Twoje podejście, ja kiedyś miałem podobne (co było przyczyną tego, że na przykład kręciłem nosem na system drag and drop przy robieniu aplikacji okienkowych, bo uznawałem to za drogę na skróty (ja jebie, z perspektywy czasu ale to było głupie xD), ale teraz wiem, że narzędzia są po to, żeby z nich korzystać.
Aaa i lekko się doczepię jeszcze tego argumentu, że z gotowym silnikiem w portfolio idziesz i dostajesz pracę - nooo, nie do końca niestety. Może w jakiejś firmie, która utrzymuje swój silnik do gier tak, chociaż z prostym silnikiem 2d to raczej nie byłoby i tak jakimś ogromnym plusem, ale wszystko poza tą na prawdę niewielką niszą wygląda tak, że ktoś spojrzałby na kod, powiedziałby co najwyżej, że fajne, ale i tak ostatecznie kandydat z silnikiem w portfolio a bez umiejętności bardziej specyficznych biznesowo, czy bez projektów wykorzystujących bardziej "przydatne" umiejętności zostałby odrzucony. Oczywiście programować, to szerokie pojęcie, ale jakbyś na przykład chciał przyjść na staż / juniora w backendzie ASP .Net, to taki projekt byłby fajny, ale nie wnosiłby nic szczególnego, bo oczekuje się od kandydatów szczególnie przy tak zepsutym rynku, że będą znać potrzebne frameworki wykorzystywane do pracy (np. ASP .Net + Entity Framework), do tego często się oczekuje testów jednostkowych, podstaw devopsowania. Trochę brzmi to jak odklejka z mojej strony, bo w końcu Ty o grach, a ja o backendzie biznesówek, ale myślę, że w game devie poza pojedynczymi przypadkami mogłoby to niestety podobnie wyglądać, no chyba że aplikowałbyś mając prosty silnik 3d do firmy, która taki silnik utrzymuje, lub jakbyś aplikował mając również wykazane umiejętności w jakimś Unity czy Unreal Engine. :D
Tak czy siak pozdro i czekam na gierkę, jestem ciekaw co z tego finalnie wyjdzie! :)
Wiem, że film nie jest najwyższych lotów i z perspektywy czasu scenariusz wyglądał by zupełnie inaczej, ale teraz już nic nie zrobię ;/
Ale abstrachując, mam parę pytań odnośnie .net
Jeśli plany mi się nie zmienią, chciałbym do października dostać pracę jako programista. Powiem szczerze, że głównym celem jest szybkie znalezienie pracy, wysokie zarobki(w przyszłości), możliwości rozwoju oraz nie pisanie frontendu. Mój ulubiony język to niestety rust, który ma znikome oferty pracy, a ulubiona dziedzina programowania to te niskopoziomowe pisanie sterowników, opengl i cały embedded engineering. Pomimo wysokiego progu wejścia i wymaganych umiejętności nie przynoszą one wysokich dochodów i nie jest łatwo znaleźć w nich dobrą pracę. Zatem uznałem, że najlepszym rozwiązaniem jest zostanie programistą .net lub java, no ogólnie backendowym w stronę aplikacji biznesowych.
Pierwsze pytanie to czy uważasz, że to dobry pomysł? To znaczy czy myślę w dobrym kierunki i należy wybierać dobrze płatne sektory programowania z wieloma ofertami pracy, żeby osiągnąć te cele. Czy może jednak iść w embedded, który mnie bardziej interesuje i ma bardzo wysoki próg wejścia (co gwarantuje, że żadne ai mnie nie zastąpi), ale za to z małymi możliwościami zarobku i znalezienia pracy.
I jak tak się zastanawiałem nad językiem i technologią, to uznałem, że c# jest idealnym wyborem. Po pierwsze wiele technologii z tego co rozumiem jest standardem i nie ma miejsca na wybory frameworkow itp tylko dokładnie wiesz czego musisz się nauczyć (.net). Bo w takim NodeJS istnieje wiele frameworków i tak naprawdę nigdy nie wiesz, czy ten którego się akurat uczysz da ci pracę.
Dlatego czy uważasz, że c# + .net to dobra droga, czy może cofając czas wybrałbyś coś innego typu java+spring
No i ogólnie czy masz jakieś tipy, porady, widzisz, że czegoś ważnego nie rozumiem o branży... Szczerze widzę to tak, że masteruje c# i .net, piszę parę ciekawych projektów z wow effectem do portfolio i dostaję z bomby juniora na poł etatu, ale może się mylę. Mam bardzo szeroką ogólną wiedzę o informatyce i programowaniu, czy algorytmach dlatego tym się nie przejmuję. Ewentualnie jeśli wszystko pójdzie w dobrą stronę, to zacznę jakąś małą seryjkę na yt zostawania etatowym programistą, więc jak zobaczysz kiedyś jakiś film z tego to błagam o protipy ;).
Nie wiem czy to co napisałem brzmi sensownie, bo jest zdecydowanie za późno na takie eseje, ale z góry dziękuję.
@@Wigtor O mordko, dzięki za odpowiedź, serio miło mi i się nie spodziewałem! :D
Na starcie - nie przejmuj się "poziomem filmu", ja w pełni te argumenty przyjmuję, ale przedstawiłem ich kontrę, która według mnie jest sensowna. Widać, że jesteś mega geekiem i to się ceni. :)
Co do pytań:
1. Wiesz co, wydaje mi się, że o ile nie będziesz się jakoś męczył w pisaniu backendu, to jak najbardziej spoko pomysł, zawsze możesz zwyczajnie czymś bardziej niskopoziomowym zajmować się po godzinach (nawet śledzę kilka kanałów, które akurat się kochają, nawet nie stricte w programowaniu ich, a po prostu całościowo od projektowania płytek po pisanie na jakieś różnorakie układy różnych programików) i uważam, że jako zajawka super sprawa! Niestety z zarobkami jak mówisz jest troszkę lipa, z resztą podobnie jak w game devie, ja w sumie sam gdyby game dev był łatwiejszy do wejścia i bardziej przystępny jak chodzi o zarobki, to nie wiem czy nie poszedłbym w game dev po prostu, a tak jestem backendowcem, ale muszę przyznać, że bardzo to lubię i z perspektywy czasu (można powiedzieć, że 2-3 lata, zależy jak liczyć doświadczenie, ale mniej więcej tyle) zaczynam wręcz czuć zaciągi takie biznesowe :P
Chociaż z drugiej strony patrząc, widać po Tobie mega pasję, więc jakbyś miał możliwość pójścia w cos niskopoziomowego, to nie wiem czy też nie warto rozważyć. Warto na pewno rozważyć obie opcje, najważniejsze, że w razie czego mając pierwsze doświadczenie w branży łatwiej trochę zmieniać kierunek w jakim idziesz, ja na początku trochę z przypadku pracowałem na php + czystym js + html i css, a to wszystko wrzucone w silnik presta shop i nie było problemu przerzucić się na backend w c#, względnie dużo ofert miałem jak na aplikowanie na juniora w innej technologii, także zawsze po tym nawet lekko ponad roku możesz zmienić ścieżkę, szczególnie w młodym wieku to dobra rzecz, bo masz czas wytestować. :D
Apropo drugiego pytania - nie polecam zdecydowanie javy + springa, od razu mówię, to jest tak niezjadliwe, że to hit haha. :D Sam szukałem pracy w tej technologii, nawet byłem na kilku rozmowach, ale jak dostałem rozmowę w .Netcie z polecenia i uznałem, że dam mu szansę, bo robiłem w nim coś małego na studiach, to po analizie wyszło mi, że w sumie to czego się uczyłem w springu kilkanaście tygodni, na przyzwoitym poziomie w .Netcie zajeło mi 2 tygodnie, o wiele bardziej przejrzysty jest jak dla mnie i tak jak mówisz jest dobrze ułożony. Z tego co zasłyszałem na rozmowach ostatnio czy w rozmowach też z programistami z dużo większym doświadczeniem, to czasem stosuje się coś, co nie jest w standardzie .Neta, ale i tak generalnie zazwyczaj większość rzeczy nie ma sensu zmieniać wzgledem standardu, co w innych językach nie jest oczywiste, co daje właśnie taką biznesową uniwersalność i pole do douczenia się jakichś rzeczy do stacka technologicznego, które będą dodatkwoym atutem, zamiast uczenia się trzeciego frameworku robiącego niemalże to samo, tylko dlatego, że nowa firma nie stosuje tego, którego używałeś. :D
A apropo porad - na pewno projekty o których napsisałeś i masterowanie c# + .Net to podstawa. Też zależy w co chcesz iść, bo można w .Netcie pisać różne aplikacje, ale domyślam się, że chodzi Ci o backend API, także tutaj dodatkowo oczywiście dorzuciłbym Entity Framework, bo to się baaardzo często wykorzystuje, jak ogarniasz architekturę, to mega plus dla Ciebie, ale w czystym backendzie zazwyczaj stosuje się też architekturę warstwową + CQRS, także warto sobie to przećwiczyć, jeśli nie miałbyś jeszcze okazji, bo junior z tym to będzie szał wśród pracodawców imo, serio. :D
Czy cos jeszcze? Hmm... Na pewno fajnie do apliakcji tak dodatkowo dorzucić jakąś integrację z API zewnętrznym, plus może wykorzystanie czegoś od Azure / AWS (jakieś kolejki, czy jakiekolwiek inne zasoby co udostępniają), ale to tak już totalnie dodatkowo, nie jest to wymagane, ale jest to mocne nice to have, bo często się korzysta z usług azure / aws, czasem z google w biznesie. Tylko trzeba uważać, żeby nie zapłacić za te usługi w razie czego, ale tam są raczej konta z darmowymi kredytami jakbyś się chciał pobawić. :D
No i imo obowiazkowo jakbyś chciał się wyróżnić to ogarnij sobie chociaż na podstawowym poziomie pisanie testów jednostkowych chociaż + integarcyjnych oraz już tak totalnei nice to have, ale co się przydaje w pracy, czego od juniorów się często nie wymaga (od midów i seniorów już na bank), ale co jest dużym plusem, to chociaż podstawy kubernetesa i dockera, nie jest to stricte związane z pisaniem kodu, a bardziej z jego wdrażaniem i utrzymywaniem, ale niestety albo stety backend poszedł w taką stronę, że ostantio dosyć czesto programiści robią też pipeline'y do wdrożenia swoich serwisów na poszczególne środowiska, a docker + kubernetes to z jednej strony podstawy tego, ale z drugiej na tyle wystarczające, że poza nimi programista praktycznie nie musi nic więcej wiedzieć szczególnie na początku. Ja sam dostałem pracę bez znajomości tego, a teraz mogę przyznać, że znam dosyć dobrze oba narzędzia właśnie przez wymóg jaki jest w pracy. :D
No i jak coś to jak chcesz możemy złapać się jak chodzi o kontakt, chętnie pomogę w Twoim procesie dostania pracy, zawsze chętnie służę radą. Sam nie jestem oczywiście alfą i omegą, moje doświadczenie też nie jest jakieś super ogromne, w pracy jestem midem (takim solidnym), ale byłem w sumie na wielu rozmowach, wiem z czym się je branża + sam też ostatnio zaczynam szukać pracy w innym miejscu, także chętnie zebrane doświadczenia przekażę Ci, aby Ci pomóc, bo wiem, jak czasami przesrane jest przebicie się przez gąszcz kandydatów.
Jedno jest pewne - masz ogromną przewage, bo widać po Tobie pasję do programowania, najważniejsze żeby w procesie rekrutacyjnym zachować neutralność, pokazać co ciekawego zrobiłeś + wyciągać swoje atuty, a praca powinna znaleźć się dosyć szybko, bo na juniora kandydatów jest masa, ale niestety większość z nich to są ludzie po bootcampach, albo jakichś kursach z ToDo w porfolio i nie potrafiący wytłumaczyć czym jest klasa abstrakcyjna czy interfejs i jakie plusy daje. :D
Jak chcesz daj jakiś kontakt do siebie, odezwę się i mogę śmiało w wolnym czasie podpowiadać co nieco, aby podzielić się swoim doświadczeniem w szukaniu pierwszej pracy jak i doświadczeniem stricte z już 2 lat przepracowanych w .Net, a 3 w IT, tak abyś mógł jak najgładziej wejść w branżę. :)
@@Wigtor dużo piszesz w Pythonie, nie pasowałby Ci Python + Django? Setki ofert pracy, przyjemnie się w tym pisze, zarobki też w porządku.
dobry film
dzięki