Tworzenie gry z dzieckiem - jakie technologie, żeby procentowało w przyszłości?


#1

Witam,
Mój syn (10 lat) jest bardzo zainteresowany programowaniem. Scratche i tym podobne ma opanowane nieźle, trochę podglądał i pomagał mi przy arduino, ale chce więcej - padł pomysł, żeby stworzyć grę 3D. Wiem, to bardzo enigmatyczne hasło, ale mamy trochę pomysłów, coś wybierzemy i wymyślimy.
O co chcę spytać?
Od pewnego czasu (prawie) nie programuję, nie wiem, co teraz “chodzi”. Nie boję się nauki nowego języka, czy narzędzia - tylko o ile to dla mnie będzie hobby, dla młodego może być kiedyś zawód.
Mam pewne doświadczenia sprzed lat - C/C++, OpenGL (sceny, przekształcenia, wyświetlanie modeli itd), Linux/Windows, webdev - ale nie wiem, czy to są dla młodego człowieka przyszłościowe rzeczy.
I proszę o podpowiedź: jaki wybrać język? Jakiś framework do gry (w tym jestem zielony - Unity?), na jakie inne technologie zwrócić uwagę?

Na pewno chcemy stworzyć coś trójwymiarowego, najchętniej multiplatformowego (linux/windows). Grafika: raczej bardzo proste modele, nie porywamy się na fotorealizm, raczej na małe “ludziki” poruszające się w trójwymiarowym (ale nieskomplikowanym, ot ściany, podłogi, może jakieś dodatkowe obiekty) otoczeniu.

Zadanie nie jest łatwe, ale nie mamy żadnych ograniczeń czasowych.
Proszę o wskazanie kierunków - nowoczesnych, z przyszłością.


#2

Są dostępne silniki Unreal i Unity.
Mają pełen zestaw narzędzi do 3d i biblioteki assetów w tym darmowe.
Są to duże kobyły, pisze się nie tyle sam silnik tylko bardziej mody do silnika.

UE4/5 ma system bloczków zwanych Blueprint gdzie można “programować” bez kodu.
A jak logiki jest za dużo można napisać swój kod w c++ i podłączyć do silnika.
Jest to specyficzny c++ zintegrowany z toolami Epica, ale ma całkiem niezłe wsparcie w Visual studio i sam kod silnika też jest darmowy jakby ktoś chciał poparzeć co tam się dzieje w środku albo przerobić, ale to trudne bo jest tego kodu dużo.

Unity jest trochę mniejszy. Kod ma zamknięty bez drogiej licencji. Za to logikę gry pisze się w C# w oparciu o podstawę dostarczoną przez silnik. Jest to też mocno specyficzny C# ale większość składni działa. Jest to tak naprawdę wrapper na klasy w c++ pod spodem. Ale nie ma takich bloczków jak w UE (znaczy są pluginy na store ale nie są defaultowe ani mocno wspierane) więc więcej logiki pisze się w normalnym kodzie. Ale robi się to na podstawie silnika, wpinając się w ustalone eventy i używwając podstawowych komponentów typu kolizja, sprajt, bryła 3d, animator itp.

Są silniki typu JavaScripcie typu phaser.io które są oparte na WebGL.
Demka widzę głównie w 2d, ale w teorii powinno się dać 3d skoro to webGL. Może jakiś inny silnik lepiej wspiera.

Unreal i Unity potrafią robić buildy WebGLowe które można osadzić na stronce internetowej.

Można też pisać od zera ale 3d jest trudne, i bez dodatkowych tooli bardzo mozolne do pracy.
Naklepanie importu z jakiegoś formatu, importu tekstur,systemu animacji to będzie bardzo dużo roboty zwłaszcza dla początkującego programisty. A na to jeszcze wchodzi cały system oświetlenia i renderingu. Nie rysowanie tego czego nie ma na ekranie, jakieś kolizje, organizacja i logika samej gry itp itd.

Proste rysowanie modelu to nawet nie jest początek gry… dlatego jeśli chodzi o stworzenie gry a nie zabawę podstawami grafiki 3d to raczej jakiś gotowy silnik na start i wtedy można się skupić na uczeniu się silnika i kodowaniu samej logiki gry.


#3

Bardzo dobre rady. Właśnie o to mi chodzi - jak się za to zabrać. Chcę, żeby młody zobaczył, jak to się w ogóle tworzy, za jakiego typu narzędzi się korzysta (fakt, sam się tez muszę nauczyć :slight_smile: ).
Samego kodowania się nie boję, jakieś tam pojęcie mam.
Nie myślałem o webGL, choć pomysł ciekawy. Jednak raczej zostanę przy tradycyjnym desktopowym sofcie.
O prostych modelach wspomniałem, żeby było jasne, że nie zamierzamy pisać HalfLife3 tylko prostą gierkę. Pewnie jakieś budynki - w postaci ścian z kolorem, pewnie nawet bez tekstur.
Zresztą to będzie “plansza” 3d, a nie fpp, ale to się jeszcze rodzi w głowach - daleko mamy do konkretów.

Mam świadomość, że modele i grafika w ogóle to jedynie “ubranko”. Pewnie zrobimy kupę rzeczy źle i będziemy zaczynać kilka razy, ale nie spieszy nam się :slight_smile: Na razie zbieramy pomysły, za konkrety zabierzemy się po wakacjach - póki co młody ma się oderwać od komputera :slight_smile:


#4

No jak piszesz własny kod to po miesiącu będziesz może miał prosty renderer,lepiej rozumiesz co tam jest pod spodem. Ale nic sensownego z tego nie zrobisz co stało koło gry. Bo gra wymaga tooli, to jak rysowanie w paincie vs w C++. Graficy rysują w paincie, painta pisze się w c++.

Jak odpalisz unity to po 5 sekundach wstawiasz model na planszę, układasz level z 50 modeli przeskalowanych. I przez miesiąc doczytujesz jak cokolwiek zrobić w unity, jak pisać gameplay, jak tweakować parametry kolizji i renderera. itd. Ale painta juz napisali, ty uczysz się go używać i dopisujesz pluginy z customowa logiką. (której będzie całkiem dużo bo gra to nie obrazek i logiki twórca silnika nie dostarczy)

Pytanie co jest ciekawsze.


#5

Dla mnie - pierwsza opcja. Dla młodego człowieka - coś co daje szybko efekt. Jeśli przez miesiąc będzie widział tylko kod to zwątpi. Jak zobaczy COŚ szybko, to potem sam będzie chciał pracować dalej.
Dokładnie taka droga jest mi potrzebna w tym przypadku.
Jak młody zobaczy efekt naszej pracy, to być może zrobimy kolejny projekt - inną metodą.

Do tego ja muszę być alfa i omegą, więc mam te dwa miesiące wakacji na zapoznanie się z podstawami :slight_smile:


#6

No uczenie się unity to też jest sporo roboty. ale masz już coś co wygląda na start i kombinujesz z logiką gry i konfiguracją.
Plus jest duzo tutoriali na których mozna poszukać porad jak coś zrobić.

Kod silnika od zera albo prawie zera przy bardzo specyficznych projektach się sprawdzi. Ale ma zero elastyczności. Jeśli chcesz zrobić grę to sprawna iteracja to podstawa.
Tak naprawdę w ten sposób robi się głównie własne silniki, ale nawet mały własny silnik to naprawdę dużo kodu. Więc tą drogą idą raczej doświadczeni albo zapaleńcy i poradników jest mniej.
Zwłaszcza od kąd można wziąć gotowy silnik i robić grę a nie silnik.

Btw robienie gry w takim unity to też nie jest prosta sprawa.
Więc realistycznie to w obu scenariuszach łatwo zwątpić.


#7

A i gry to jednak windows.
Silniki próbują jakieś rzeczy robić na linuksa ale to średnio działa…
Jak cross platformowość jest super istotna to może być bardzo pod górkę.


#8

Skoro tak mówisz… Przemyślę multiplatformowość, linuxy to raczej mój konik (i praca), stąd ten pomysł. Nie będę tego bronił jak niepodległości - choć kiedyś bez dużego bólu przeniosłem (niezbyt złożoną) aplikację C/C++/OpenGL z win na lin, skutecznie i bez strat. Ale łatwiej miałem o tyle, że napisałem w niej każdą linijkę i znałem od podszewki.

Wiem, że zwątpienie przyjdzie. Moja w tym głowa, żeby w razie czego pociągnąć samemu i zmotywować. Zobaczymy, co z tego wyjdzie.
Muszę tez ograniczyć plany podczas planowania, albo przynajmniej zostawić część rzeczy na kolejny etap, gdy będziemy już mieli coś działającego. W wyobrażeniu młodego pod koniec roku będziemy podbijać rynek steama co najmniej i mieć więcej userów niż CS i Fortnite razem wzięte :slight_smile: Ale te zapędy da się opanować :slight_smile:


#9

Warto żebyś zajrzał też tu: https://godotengine.org/


#10

Ja jestem takim typowym randomem, który chciał się nauczyć robić gry i właśnie wsiadłem na Unity na początek (mając bardzo małą wiedzę o programowaniu itd.) i to jest fajny silnik, który motywuje do samodzielnego działania, daje szybki feedback, jest prosty w obsłudze. Trochę własnych assetów, trochę darmowych, trochę kodowania i zrobiłem po jakimś czasie latającego 3d wróbla, który łapał muchy.
Jeżeli zatem interesuje cię zdanie kogoś na podobnym poziomie co twój syn, to polecam Unity.